The bottleneck was never writing the code.

Review cost is what actually limits throughput

An agent that produces ten pull requests a day against a large codebase has not saved anyone ten pull requests of work. It has moved the work: from writing, which one engineer does with full context, to reviewing, which another engineer does with none. Review without context is slower and less reliable than writing, so past a certain volume the team’s throughput goes down while its activity graph goes up.

The usual response is to make review faster — summarise the diff, comment on it automatically, rank it by risk. That helps at the margin, and it leaves the structure untouched: a human is still the first thing standing between a machine’s output and the main branch, on every single change.

So the agent proves it first

The alternative is to make the agent responsible for evidence, and to make that evidence a precondition rather than a decoration. In Delatura, a run works inside a disposable copy of the repository and has to pass verification before it produces anything a person can act on. If it cannot, the run stops. There is no branch, no preview, no pull request, and no reviewer pulled away from their own work to discover that the change did not build.

That single inversion is what makes the volume survivable. Reviewers stop being the filter that catches obvious failures and become the judgement layer for changes that already cleared a mechanical bar.

What the gate checks

The gate is not one test. It is the set of things that can be established without a human: that the change builds, that the existing suite still passes, that the behaviour the task asked for is actually exercised, and that the resulting application runs — verified against a live preview rather than asserted in prose. Each check records what it did and what came back, and that record travels with the diff.

The last part matters more than it sounds. A green check with no evidence is a claim. The reviewer’s question is not "did it pass" but "what exactly passed, on what, and when" — so the trail carries the tool calls the agent made, the commands it ran, which agent version executed, and the result of every check.

What it cannot catch

A verification gate establishes that a change does what it says mechanically. It does not establish that the change was the right thing to build, that its architecture fits, that a subtle security property still holds, or that the acceptance criteria in the ticket were the correct criteria. Those are judgement, and judgement is what you keep your reviewers for.

It also cannot save you from a task that was wrong at intake. An agent asked to silence an alert can pass every check by silencing the alert. The gate bounds the failure — it does not replace the thinking.

We would rather write that down here than have you discover it in month two.

Why it is enforced below the application

A gate that lives in application code is a gate that can be skipped by the next feature flag. The parts of this that matter are pushed as far down as they will go: tenant isolation into database policies, capability checks into the moment a tool executes, the audit trail into a table the application is not permitted to update or delete. Those are the properties that still hold on a bad day.