Decision-Gated Development: when the bottleneck moves from execution to decision

The shift

For sixty years, writing software was expensive and deciding was cheap. Every method we built follows from that. We estimate, plan, prioritise, and break work down, because execution is the scarce resource that has to be allocated with care.

AI agents inverted that relationship. Writing a hundred correct lines now costs almost nothing. Deciding which lines to write is where everything is spent. The bottleneck moved from execution to decision, and most teams are still optimising the old bottleneck.

The symptom is easy to spot. A team that adopts agents first produces a lot, then finds itself reviewing code it never thought through, arguing after the fact about architectural choices already implemented, and discovering structural decisions a machine made implicitly at three in the morning. Volume goes up, control goes down.

Decision-gated development treats this with a simple inversion. The decision becomes an artefact, and it passes a human checkpoint before anything gets written.

Three rules, and nothing else

The method fits in three rules. Their value is not sophistication, it is that they hold up.

First rule. By default, plan, do not implement. Every work session produces a plan, not code. Implementation is only allowed when explicitly requested. When in doubt, plan. This rule looks bureaucratic until you measure what it prevents: code written on a misunderstood intent that will have to be undone.

Second rule. A plan is not an idea. An idea is free and lives in an inbox. A plan is the product of an exploration: it names the exact files, the hookup points to reuse, the rules it must not break, the tests to write. It is actionable without further exploration. The bar is precise, decision-complete rather than detail-complete. The plan locks in the choices, which age well; it leaves the mechanical residue to implementation, which ages fast.

Third rule. A single human gate, and it cannot be bypassed. An unapproved plan does not get implemented. The control is not a code review after the fact, it is a decision validation before the fact. That is where, and only where, a human is irreplaceable.

What the method enables, and why it runs against intuition

Planning parallelises, implementation does not

This is the most useful reversal. You can run as many concurrent planning sessions as you want, they never collide, because they only produce written decisions. Implementation, however, stays carried by a single writer at a time, because two agents editing the same file overwrite each other silently.

Intuition says the opposite. We instinctively assume thinking is sequential and producing parallelises. With agents, it is the reverse.

The plan becomes the unit of review, not the diff

Reviewing a six-thousand-character plan that states the files touched, the hookup points reused, and the tests to write takes a few minutes. Reviewing the matching diff takes much longer, and above all arrives too late: by the time a bad architectural choice shows up in a diff, it has already been written.

Freshness becomes a first-order problem

An approved plan ages. The code shifts underneath it. Hence a step nothing replaces: before implementing, cheaply verify that the named files and hookup points still exist as described. Checking a precise plan costs minutes; deriving an approach from an idea costs a whole exploration.

This step is not decorative. Over these seventeen days it intercepted several plans whose premise had turned false between writing and execution, including one about to destroy data while believing it was fixing it.

Case study: seventeen days of registry

The figures below come from a real registry, measured on 28 July 2026, over seventeen days of continuous existence since its creation. A first measurement had been taken on 21 July, at eleven days: between the two, volume more than doubled (260 to 565 plans) without the method itself changing a single rule. The pace itself accelerated, not just the volume: roughly 24 plans a day over the first eleven days, roughly 51 a day over the next six (see Figure 3). That is a data point too: a method that holds under growing load, not only at launch.

Measure	Value
Plans written	565
Plans implemented then closed	477
Plans abandoned	31, 26 of them never claimed for implementation
Plans awaiting approval or their turn	57
Upstream ideas and reports never turned into plans	144 (out of 482 entered in the registry)
Archived plan revisions	167
Median plan size	5,693 characters

Three lessons read directly off these figures.

Thirty-one abandoned plans, twenty-six of them without a single line of code ever written. This is the method’s yield, measured conservatively: those twenty-six were never claimed for implementation, so zero code was produced with certainty; the remaining five were claimed then abandoned, most often because the freshness pass that precedes every implementation found a false premise before anything substantial got written. Each of these thirty-one represents an exploration carried out, a decision made, and work that never happened because someone understood in time that it should not.

A hundred and forty-four upstream items out of four hundred and eighty-two entered in the registry, never turned into plans. The gap measures the selection. An idea is not a plan, and most ideas never become one: they stay readable, dated, and reopenable on a precise signal, should one arise.

A hundred and sixty-seven revisions. An approved plan that gets substantially rewritten is no longer the approved plan. The control then has to run again, or it controls nothing. This is the method’s most subtle failure mode, and the one that shows up most silently: a dashboard that displays ready work that no longer is.

The three ways the method degrades

A method is judged by its failure modes, not its successes.

A gate that becomes a rubber stamp

If the approver signs off without reading, all that is left is the bureaucracy without the benefit. The only remedy is size: a plan that fits on three screens actually gets read; a fifteen-screen plan gets signed unread.

A plan that describes an intention rather than deciding one

The symptom is easy to spot: the plan names no file, no hookup point, no test. It sells a direction. The approver then believes they are validating a decision, when they are validating a wish.

A registry that lies by omission

This is the worst case, because it produces no visible error. A board that shows as available work that no longer is, a report source that only gets half-read, a counter that reads zero because it counts the wrong thing. Nothing breaks, and trust in the instrument erodes without anyone noticing.

The link to enterprise transformation

This method is the engineering counterpart of a broader framework, the Junyr Method™, which describes how a company moves through its AI transformation across five maturity tiers.

Both answer the same question at two scales. The Junyr Method™ asks: as AI takes over execution, who decides, on what basis, and with what guarantees? Decision-gated development answers at the level of an engineer’s workstation: keep the decision, delegate the execution, and make the checkpoint explicit rather than implicit.

The Junyr Method™ is tool-independent. This engineering method is too: it requires a registry, a precision bar and a human gate, not a particular piece of software.

What I am not claiming

The method says nothing about the quality of the code produced, the choice of agents, or the architecture. It replaces neither tests nor review. It treats a single problem, the shifted bottleneck, and it only has value for teams that have actually run into it.

It has a real cost. Writing a six-thousand-character plan for a three-line fix is absurd, and nobody should do it. The method earns its keep once the volume produced exceeds review capacity. Below that, it is ceremony.

In one sentence

The bottleneck is no longer execution, it is decision. What deserves a registry, a gate and a signature is no longer the code, it is the choice.

To install this governance loop (a plan registry, a human gate, verified execution) in your AI projects, see the Junyr Method™ and the AI Express Audit & Roadmap.

Going further

• In the same series: We removed Git from a production product, the account of the switch this registry comes from, Vibe coding is dead: enter UltraCoding, the production line that implements the plans, and Agentic systems engineering: the human in the loop, the “the agent proposes, the human commits” principle applied to every agent.

Paul-Antoine TUAL, AI Transformation Leader · Croissance et Transitions (SAS) · Junyr Method™ · Junyr Mail™ · Junyr Agents™

---

Sources

The registry figures (565 plans written, 477 shipped, 31 abandoned including 26 never claimed for implementation, 57 awaiting approval or their turn, 144 out of 482 upstream ideas never turned into plans, 167 archived revisions, median size 5,693 characters) come from Junyr’s development registry, read on 28 July 2026, seventeen days after its creation. A first measurement had been taken on 21 July 2026 (260 plans, eleven days). For external context (removing Git, spec-driven development, forges built for agents), see the bibliography of “We removed Git from a production product”.