Decision-gated development: approve the plan before writing code

The shift

When agents accelerate code production, the relative cost shifts towards choosing the change, checking its fit with the existing system and giving the team enough information to review it before it grows.

• Earlier methods allocate scarce human implementation capacity.
• Agents reduce writing time, but they do not remove the work of understanding dependencies and making trade-offs.
• More code increases review pressure when structural decisions remain implicit.
• Decision-gated development therefore turns the choice into a written artefact and places a human checkpoint before implementation.

Three rules for control before code

The method uses three operating rules to separate exploration, decision and code changes clearly.

• Plan by default: an exploration session produces a plan; implementation requires an explicit request.
• Make the plan decision-complete: it names files, integration points, constraints, tests and exclusions without pretending to fix every import or insertion line.
• Approve before writing: a human accepts, rejects or requests revisions before code changes begin; testing and code review remain necessary afterwards.

What separating planning from execution enables

Planning parallelises, implementation does not

Planning can run in parallel while each session produces an isolated artefact, whereas implementation must be serialised or divided between genuinely independent areas to prevent conflicts and inconsistent changes.

• Several agents can explore options, risks or subsystems without modifying the repository.
• Reviewers can compare, merge or reject their plans at the same checkpoint.
• Simultaneous changes to the same file, schema or contract require explicit coordination; one writer per area is the prudent default.

The plan becomes the unit of review, not the diff

The plan becomes the first unit of review because it exposes intent and architecture before they become code, while the resulting diff still needs its own review.

• Plan review checks scope, dependencies, integration points and the test strategy.
• Diff review checks implementation fidelity, actual effects and code quality.
• Catching a poor choice in the plan avoids its implementation cost; catching departures in the diff remains essential.

Freshness becomes a first-order problem

An approved plan remains valid only while its premises match the repository, so implementation begins with a freshness check and returns for approval whenever a substantive choice has changed.

• The implementer checks the named files, interfaces, schemas and assumptions.
• A mechanical difference can be resolved during implementation if it changes no decision.
• A change in scope, architecture or risk sends the plan back through the human gate.
• In the seventeen-day internal sample, this pass stopped a plan whose premise had become dangerous; the observation illustrates the mechanism without measuring its general frequency.

Case study: seventeen days of registry

This descriptive sample covers only Junyr’s internal development registry from 11 to 28 July 2026 and shows how items moved through that workflow without demonstrating performance in other teams or over a longer period.

• On day 11, the registry contained 260 plans, roughly 24 per day since its creation.
• On day 17, it contained 565; the 305 additions over the final six days amount to roughly 51 per day.
• This acceleration describes registry activity during the observed window; it proves neither a productivity gain nor the method’s future stability.

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

The three most useful signals in this internal sample concern stopping work before code, selecting between an upstream item and a plan, and renewing approval after a substantive revision.

• Stopped before code: 31 plans were abandoned; 26 were never requested for implementation, which establishes that no code was written for them, while the registry does not support the same claim for the other five.
• Upstream selection: 144 of 482 items, or 29.9%, never became plans; roughly three in ten is a substantial minority and does not support “most ideas” or a generalisation to other teams.
• Renewed approval: 167 revisions were archived; when a rewrite changes an approved decision, the new plan must pass through the gate again for its status to remain reliable.

Outcome-driven prioritization: composing the next wave

The gate decides whether a plan may be implemented at all, and outcome-driven prioritization decides which approved plans enter the next wave, ranked by the effect expected for end users and corrected by the effect observed after the previous wave.

• A wave is a batch of approved plans implemented, then promoted to production together; the batch of twelve plans promoted on 14 July, described in “We removed Git from a production product”, is one such wave.
• The pool is the set of approved plans waiting for their turn, part of the 57 plans counted as waiting in the table above.
• The ranking criterion is an end-user outcome: a task completed without assistance, an error that stops occurring, a feature actually used, a support request that disappears.
• Plans shipped per day measure output; the acceleration in figure 3 says nothing about the value users received.
• After promotion, the observed outcome is compared with the acceptance observations each plan named, and the comparison re-ranks the pool, returns a plan to the gate when its premise changed, or abandons a plan whose expected effect has vanished.

Wave size is the variable to optimise

A wave is sized so that its outcome can still be attributed to its plans, because a wave that is too large blurs the reading and a wave that is too small wastes the serialised writing capacity.

• Group plans that touch the same area, to limit freshness conflicts, and separate plans whose effects would merge in the same measure.
• Place one or two plans with a high expected outcome in each wave rather than filling it with low-risk items that are easy to close.
• Read the outcome at a fixed interval after promotion, with the same measure from one wave to the next, so that ranks stay comparable.

What prioritization never does

Prioritization orders approved plans and never approves them, so a plan with a strong expected outcome still passes the gate and the freshness check before any code.

• The gate keeps responsibility for the decision; prioritization sets the rank and nothing else.
• The registry sample in this article counts plans and says nothing about outcomes; the ordering rule is therefore a design choice whose effect this article does not measure.
• A rank derived from a proxy, such as page views or plans closed, drifts back to output and must be replaced by an observation on the user.

The three ways the method degrades

The method ceases to control decisions when approval becomes automatic, the plan remains vague or the registry no longer represents the actual state of work.

• The gate must produce an attentive, traceable decision.
• The plan must contain enough precision to be actionable.
• The registry must depend on reliable states and sources.

A gate that becomes a rubber stamp

Approval without a proper reading adds delay without reducing risk, so the plan must be calibrated for a reviewer to examine it in practice.

• Match length to the change’s complexity and risk.
• Surface decisions, assumptions and irreversible consequences.
• Withhold approval when the necessary time or expertise is unavailable.

A plan that describes an intention rather than deciding one

A document that promises a direction without identifying change surfaces or expected evidence remains an idea even when it is labelled as a plan.

• Identify the affected files, services, contracts or data.
• Name the existing integration points to reuse and the rules to preserve.
• Define the tests or observations that will support acceptance.

A registry that lies by omission

An incomplete registry can display a plausible position while directing decisions towards stale work, a partially read source or a poorly defined measure.

• Link each status to a verifiable event instead of an implicit interpretation.
• Flag plans that are stale, superseded or awaiting renewed approval.
• Check registry measures periodically against their source artefacts.

The link to enterprise transformation

Decision-gated development brings one principle of the Junyr Method™ into engineering work: delegated execution requires explicit responsibility, decision criteria and appropriate controls.

• At repository level, the plan records the proposed change and the gate assigns the decision.
• At organisation level, the framework connects AI uses with responsibilities and suitable controls.
• Both approaches are independent of a particular tool and neither guarantees quality, security or compliance on its own.

What I am not claiming

The method addresses decision quality before code and should be proportionate to risk, because it chooses neither the agent nor the architecture and replaces no technical verification.

• Retain the required tests, code review, security controls and observability.
• Reduce or omit formal planning for a trivial, local and readily reversible fix.
• Increase precision and scrutiny as volume, dependencies, error cost or irreversibility grow.
• Rank approved plans by end-user outcome without letting the rank replace the gate, and without reading a measured effect into a sample that only counts plans.

The principle to retain

When code production exceeds a team’s capacity to decide and review, recording the choice, approving it and checking its freshness restores a control point before execution.

• The registry preserves the decision and its status.
• The human gate assigns responsibility before the change.
• Tests and review then establish what the implementation actually does.
• The end-user outcome measured after each wave orders the next one.

Position your organisation with a free Junyr AI maturity audit.

Going further

• We removed Git from a production product: the workflow change that led to this registry.
• UltraCoding: the production process that implements approved plans.
• Agentic systems engineering: the human in the loop: controlling which actions an agent can commit.

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

---

Sources

The statistics in this article come exclusively from two readings of Junyr’s internal registry and describe only that scope, while external context remains documented in the bibliography of “We removed Git from a production product”.

• 21 July 2026: 260 plans after the registry’s first eleven days.
• 28 July 2026: 565 written plans, 477 delivered, 31 abandoned including 26 never requested for implementation, 57 awaiting action, 167 archived revisions and a median length of 5,693 characters.
• Upstream selection on 28 July: 144 of 482 items, or 29.9%, never became plans; this denominator is separate from the 565 written plans.
• 14 July 2026: a batch of twelve approved plans, implemented on 13 July and promoted together the next day, the wave example used in the prioritization section, documented in the Git article.