The human merge gate

Every serious account of running coding agents at volume arrives at the same arrangement, and it is worth being precise about why. A person approves every merge. Not because the output is unreliable — often it is fine. Because somebody has to be able to answer for what is running, and answering for something requires having read it.

The gate is not about trust#

The framing that causes trouble is treating the gate as a temporary measure — something to be relaxed as confidence grows. Under that framing every good week is an argument for loosening it, and the question of who owns the code never gets answered, it just gets deferred.

The framing that holds is ownership. Agent output is a proposal — which is why the review agent never approves either. The person who approves and merges it owns it afterwards and is responsible for it, exactly as they would be for a change a colleague wrote. That sentence is not about how good the model is; it stays true at any quality level, because the thing being allocated is accountability and accountability does not have a confidence threshold.

A second requirement follows from the first and is easier to lose: the team has to be able to understand the code. Not admire it — understand it. Which makes comprehensibility a merge requirement rather than a preference, and makes small reviewable changes a structural need rather than a style guide entry. A change nobody on the team can explain has failed the gate even if every test passes.

The numbers say this is what people actually do. Across Jellyfish’s benchmark of 99 million pull requests from more than 1,300 companies, the leading adopters have 48% of their pull request throughput opened by autonomous agents — and the median company merges 0.7% of pull requests with no human involved, with even the leaders of that particular practice at around 3.5%. Enormous proposal volume; almost nothing merging unread.

Attention scales with risk, not volume#

Holding the gate does not mean spending equal attention everywhere, and pretending otherwise is what breaks it. A dependency bump with a green build and no API change does not deserve the reading a change to token validation deserves. The way to make that difference operational is to have every change arrive already classified — a risk label and a short self-review note from the agents that produced it — so a reviewer can decide where to spend the next twenty minutes before opening the diff.

Some categories are exempt from the scoring, and it matters that the list is explicit rather than inferred.

The pattern in the left column is that none of those risks is proportional to the size of the change. That is precisely why a size cap is a poor instrument on its own: the one-line auth change is small, and small is not the property that matters.

Rubber-stamping is the real failure#

Here is how the gate fails in practice, and it is not by being removed. It is held, formally, while the volume behind it rises until reading everything properly stops being possible. Approvals keep happening. They stop meaning anything. Nobody decided this and no policy changed.

Which reframes review capacity as the factory’s actual limit. When agents produce the changes, the constraint moves from writing to reading, and a system that generates faster than it can be read accumulates a queue of stale branches that begin conflicting with each other. Throttling generation to review capacity is a legitimate design decision — not an admission that the automation underperformed.

The direction of travel among large operators is the same. DORA’s 2025 report, across roughly 90% adoption of AI tools, finds that AI raises throughput and raises instability at the same time, and that it functions as an amplifier: strong teams get stronger, struggling teams get their existing problems faster. A merge gate is one of the things that decides which of those a team is. And METR’s randomised trial is the reason not to trust the internal signal — sixteen experienced developers, 246 tasks, 19% slower with AI, convinced afterwards they had been 20% faster. If the people inside the loop cannot feel the difference, the gate cannot be tuned by feel.

So it gets measured. Unreviewed-merge rate as a guardrail that must stay at zero. Human review effort per accepted change, so the cost of the gate is visible. Change failure rate alongside lead time, because lead time alone will happily improve while quality falls. And, separately from all of it, the agent share of merged changes tracked as a diagnostic and never as a target — the moment that percentage becomes a goal, the cheapest way to move it is to generate more low-value changes, and the thing that would have caught that is the one measurement most teams skip.

The gate assumes the change in front of it is honest about what it does. The case where it is not — where the instruction came from the text the agent was reading — is prompt injection in a pipeline.