The Practice: Spec-Driven, Maker-Checker, Governed Scope

A friend of mine — a very good engineer, twenty years in — spent a Saturday letting an agent rewrite a payments module. Sunday night he told me it was the most productive day of his career. Wednesday he reverted all of it.

Nothing was wrong, exactly. The code compiled, the tests were green, the diff was beautiful. It just wasn't the thing the business needed, and by the time anyone could tell, there were four thousand lines to argue with instead of one paragraph. He hadn't been out-engineered by the model. He'd been out-managed by his own workflow — because there wasn't one.

That story is now the median story. And the fix is unglamorous: agentic coding is not a tool you buy, it is a practice you run. Three patterns carry almost all of the weight, and none of them belong to a vendor.

The evidence looks broken. It isn't.

Two credible randomized trials point in opposite directions. In the GitHub/Microsoft study, developers given Copilot finished a scoped, well-specified task 55.8% faster. In METR's 2025 trial, experienced maintainers working real issues in repos they knew intimately were 19% slower with AI assistance — and believed they'd been 20% faster. Self-report was off by nearly forty points.

Read the two designs side by side and the contradiction dissolves. One measured a task with a written definition of done, in unfamiliar code, where the model's context was the whole problem. The other measured undefined work in codebases where most of the specification lived in a human's head and was never written down. Same technology. Different practice.

DORA's 2025 report names the mechanism directly: AI is an amplifier. Point it at a team with clear intent, fast tests, and small batches and it compounds them. Point it at a team where requirements are verbal and review is a rubber stamp, and it compounds that instead — which is how you get 2024's finding that a 25% rise in adoption tracked with a 1.5% drop in throughput and a 7.2% drop in stability. More output, less delivery.

Pattern one: spec-driven development

The unit of work stops being a prompt and becomes a spec: intent, acceptance criteria, the files in bounds, and the things explicitly out of scope. It is typically twenty lines. It is written before the agent starts, and it is the artifact you review — not the diff.

The reason is economic. Reviewing a paragraph of intent costs a minute; reviewing four thousand lines of confidently wrong implementation costs an afternoon and a relationship. Agents are extraordinary at satisfying a stated constraint and hopeless at inferring an unstated one, so every ambiguity you leave in the spec gets resolved — quickly, plausibly, and in whichever direction you didn't mean.

A spec that works has five parts, and it fits on a screen:

1. Outcome — what is true when this is done, in the user's language.
2. Acceptance criteria — checks a machine can run. If a criterion can't be verified, it's a wish.
3. In bounds — the files and modules the agent may touch.
4. Out of scope — the tempting adjacent refactor it must leave alone.
5. Stop condition — what to do when stuck, instead of inventing.

Write that and something quietly important happens: the ambiguity surfaces while it's still cheap. Half the time I never run the agent, because writing the spec revealed that I didn't know what I wanted yet. That's the pattern paying for itself before it executes.

Pattern two: maker-checker review loops

Banks settled this argument in the twentieth century. Nobody both initiates and approves the same transaction — not because initiators are dishonest, but because the person who made a thing is structurally the worst person to catch what's wrong with it. Agents have that bias in a purer form: an agent asked to review its own work will defend it, because its context window contains the reasoning that produced it.

So you split the roles. The Maker implements against the spec. The Checker is a fresh agent with clean context, given the spec and the diff and one job: find where they disagree. Then a Gate of machine checks — types, tests, lint, build — has the final vote, because it cannot be talked out of a red result.

The checker earns its cost in a specific way. Makers fail by omission — the edge case skipped, the error path unhandled, the acceptance criterion quietly reinterpreted. A clean context reads the spec as written rather than as remembered, which is exactly the failure mode Stack Overflow's 2025 survey found developers hate most: 66% cite frustration with code that is "almost right." Almost right is the maker's signature. Catching almost-right is the checker's entire job.

An unattended loop is only as safe as its harshest automatic check. If your gate is a human glancing at a diff at 6pm, you don't have a loop — you have a queue.

Pattern three: keep the agent inside a governed scope

Autonomy is not a dial from zero to a hundred. It is a set of individual grants, each with its own cost when it goes wrong. The useful question is never "how much do I trust the model" — trust isn't a control. It's "what is the worst outcome of this permission, and can I undo it in one command?"

Governed scope in practice: work happens on a branch or an isolated worktree, never on main. Writes are confined to declared paths. The agent does not edit the tests it is graded against — the single most important line in the whole policy, because an agent that can move the goalposts will, and its report will say green. Secrets are never in context; production credentials are never in reach. Network access is allow-listed. Every action is recoverable by a revert.

Under those constraints something counterintuitive happens: you can give an agent more freedom, not less. Autonomy scales with reversibility. When every mistake costs one git reset, letting the loop run for an hour unattended stops being brave and starts being ordinary.

The patterns port across models

Here is the part worth internalizing if you're deciding where to invest. Every one of these three patterns predates the current generation of models and will outlive it. Spec-driven development is requirements engineering with a faster implementer. Maker-checker is separation of duties. Governed scope is least privilege. These are the oldest ideas in engineering management, re-pointed at a new kind of worker.

Which means a vendor change is a configuration change, not a rebuild. When I move work between coding agents, the spec format, the loop shape, and the gate travel unchanged. What gets rewritten is the thin, unglamorous layer at the bottom: flag syntax, tool wiring, a little prompt tuning. That layer is the one people spend all their time on and the only one with a shelf life.

Where to start on Monday

Don't restructure anything. Take the next task you were going to hand an agent and do three things: write the twenty-line spec first; run a second agent with clean context to review the diff against that spec; and confine the writes to a branch with a red-green gate the agent can't edit. That's the whole practice at its smallest useful size.

Then measure the one number that matters — not lines generated, not tokens spent, but first-pass acceptance: how often the loop's output goes in without a human rewriting it. That number tells you whether you're compounding or just accelerating toward the same wall my friend hit on a Sunday night. If you want the full machinery underneath these patterns, the Loop Engineering field guide takes them apart station by station, and The Agent Harness covers the configuration layer.

The tools will keep changing. They'll get faster and cheaper and better than they are right now. The practice is what you keep.