Structured Instead of Vibe-Coding: Deterministic Practice in Nondeterministic Systems

Why nondeterministic agents demand a doubly deterministic counterweight — Functional Programming on the technical axis and a rigorous process on the procedural one.

1. The Problem: Nondeterminism as a System Property

Agentic systems are not deterministic machines. The same prompt produces different outputs, the same task leads to different solution paths. This is not a malfunction but a system property.

"An LLM is nondeterministic — there is no sure or consistent output for a given input. Although the output is based on probabilities and isn't purely random, the user doesn't get to see what those probabilities are." — Jay Alammar & Maarten Grootendorst: Common Sense Guide to AI Engineering, p. 34

The first article in this series drew a consequence for the code: If the agent is nondeterministic, the code it calls and generates must be all the more deterministic — that is the rationale for Functional Programming as a foundation.

This article extends the conclusion by a second dimension: Not only the code must be deterministic, but also the practice. The more nondeterminism a system produces, the more determinism the human and the process must contribute as a counterweight. The nondeterminism does not disappear — it is contained within a deterministic framework.

2. Vibe-Coding: Why It Is Radioactive Waste

Vibe-coding describes the practice of issuing a prompt, adopting the generated code, and moving on — without a plan, without atomic commits, without review. The code "somehow works," so it is accepted. The approach is guided by feeling ("vibe"), not by a traceable structure.

The result is not just waste, but radioactive waste: It looks usable at first but keeps radiating invisibly. Knowledge is lost, decisions cannot be reconstructed, and follow-up costs accumulate with every further step.

❌ Vibe-Coding: Progress Without a Trail

• Issue a prompt, adopt the code, move on.
• No atomic commits — changes blend together.
• No review — no one checks the decision.
• No traceable plan — the "why" exists only in the head, until it is forgotten.
• Success is measured by feeling, not by reproducible states.

✅ Structured Practice: Every Step Is a Trail

• A refined plan before implementation.
• Every card is an atomic, reviewable commit.
• Review as a gate before integration.
• Decisions are documented in the commit, the card, and the plan.
• Success is measured by traceable, recoverable states.

The decisive difference lies not in speed but in traceability. Vibe-coding produces states that no one can explain anymore — and thus knowledge that never existed.

Case Study: Six Weeks in the Vibe Frenzy

For six weeks, development runs continuously in vibe mode. Over three sprints, dozens of tickets are "completed" — from the outside it looks like peak output. Every sprint review shows green check marks.

Work is done with the Claude.ai chat subscription instead of an API key — contrary to the project guidelines. The consequence: no visible cost signal. With API usage, the exponentially rising token consumption would have surfaced early and made the growing complexity visible. Rising token costs per task are an early indicator of increasing degeneration — this warning signal is entirely absent.

Over time, progress stalls. Changes that used to take minutes now cost hours. The decisive observation: The moment the problem is noticed is not the beginning but the end. The degeneration has long since taken place; it only becomes visible once it can no longer be ignored.

Then comes the unwinding. Step by step the work is rolled back — and one effectively lands back at the starting point. The six weeks of work are virtually lost.

This state is radioactive because it can no longer be explained what happened. There are no atomic commits, no review, no traceable plan — on top of that, a guideline violation that should have been avoided from the start. What remains is no usable knowledge, but a non-reconstructable state.

It is precisely this escalation that the two axes of determinism prevent: Functional Programming and a rigorous process with atomic commits, a review gate, and early signals.

3. The Two Axes of Determinism

Determinism does not arise in a single place. It needs two complementary axes: a technical one (how the code is structured) and a procedural one (how work is done).

The technical axis is the subject of the series so far: Pure functions and immutability make the behavior of a function predictable, categories and functors give transformations formal guarantees, and monads as a protocol encapsulate effects deterministically. FP patterns for agent systems assemble these building blocks into concrete architectures.

Monads are the most effective tool here: They shift complexity out of the control flow into data structures. Instead of try/except and scattered if/else chains, a Result monad encapsulates success and failure in an explicit, composable type. The effect remains visible and traceable — the exact opposite of hidden state.

The technical axis alone, however, is not enough. Even perfectly functional code can become radioactive waste in vibe mode if no one documents why it came to be. That is why the second axis is needed.

4. The Procedural Axis: A Rigorous Process

The procedural axis answers the question: How does a change enter the system in a controlled way? The answer is a short, hard chain without shortcuts.

Terminology: Card vs. Ticket, Review by the PO Agent

To avoid a double naming, two levels are consistently distinguished here:

• Card denotes the local unit of work on the kanban board (in the sense of iKanbanAi). The term deliberately sets it apart from the Jira ticket, which in many organizations describes the higher-level, coarse-grained requirement. A card is finer: exactly one atomic, reviewable state.
• Review here explicitly means the inspection of the card by the PO agent — not a classic code review among humans, but the automated gate that a PO agent runs before integration.

1. Plan — The undertaking is formulated as a plan before code is written.
2. Refinement by the PO — The product owner sharpens the plan, decomposes it into cards, and ensures that each card makes sense on its own.
3. Card as the smallest unit — Each card (the local counterpart to the Jira ticket, only finer) describes exactly one completed state.
4. Card = atomic commit — A card corresponds to an atomic commit: a completed, reviewable state, no more and no less.
5. Review of the card by the PO agent as a gate — No state is integrated before the card has passed through the PO agent's review gate.

The equation card = atomic commit is the core. It enforces that every change is, on its own, understandable, verifiable, and reversible. If something goes wrong, the rollback affects exactly one commit — not six weeks of blended work.

Kanban makes this flow visible: Each card moves through clearly defined columns, work-in-progress stays bounded, and stalls become immediately apparent. Tools like iKanbanAi transfer this principle to collaboration with agents — the nondeterministic agent works within a deterministic, visualized framework.

The process is deliberately rigorous: It allows no exception, because every exception opens the door to vibe-coding again. Precisely because the agent is highly variable, the framework must be non-negotiable.

5. Knowledge Preservation: The Real Gain

The true value of this practice is not cleaner code but preserved knowledge. Plan, card, and atomic commit together form a seamless trail of the "why":

• The plan records which goal was pursued.
• The card records which concrete decision was made.
• The atomic commit records how it was implemented — isolated and reviewable.
• The review by the PO agent ensures that the decision was checked and understood beyond the card.

This directly addresses the core problem of vibe-coding. Vibe-coding loses knowledge because the "why" exists only fleetingly in the head and is overwritten with the next prompt. A structured process externalizes this knowledge into durable artifacts. Even if a state has to be rolled back, the trail remains: One knows what was attempted and why it did not work.

Traceability is the antidote to radioactivity. A state that is explainable does not keep radiating.

6. Summary & Checklist

Nondeterministic agents demand a doubly deterministic counterweight. Functional Programming secures the technical axis, a rigorous process the procedural one. Only both together prevent apparent progress from turning into total loss.

Checklist: Deterministic Practice with Agents

Technical axis (FP): - [ ] Pure functions: same input → same output, no side effects. - [ ] Immutability: no hidden mutation of shared data. - [ ] Explicit signatures as a contract between human and agent. - [ ] Monads instead of scattered control flow (encapsulate effects explicitly).

Procedural axis (Kanban/Commits): - [ ] A plan exists before code is written. - [ ] The plan is refined and decomposed by the PO. - [ ] Every card (local, finer than the Jira ticket) = one atomic, reviewable commit. - [ ] Review of the card by the PO agent as a non-negotiable gate. - [ ] Kanban visualizes the flow; early warning signals (e.g., token costs) are visible.

This checklist is the bracket over the entire series. Articles 01–04 justify and deepen the technical axis; this article adds the procedural one. FP alone is not enough, and a process alone is not enough. Only the combination makes working with nondeterministic agents reproducible — and preserves the knowledge that would otherwise be lost.

Sources

• Jay Alammar & Maarten Grootendorst: Common Sense Guide to AI Engineering, p. 34
• Eric S. Raymond: The Cathedral and the Bazaar, p. 30
• Scott Wlaschin: Domain Modeling Made Functional, p. 72
• David J. Anderson: Kanban: Successful Evolutionary Change for Your Technology Business, p. 15