The math went first. Faros telemetry puts hard numbers on what agent-heavy teams already feel: they produce 98% more PRs, 154% larger, and those PRs wait 4.6x longer for a reviewer to even pick them up.
Twice the PRs. Two and a half times the size. Nearly five times the wait before a human even opens the diff.
The pull-request review model, where one busy human reads a diff, understands it, and approves it, didn’t bend under agent volume. It snapped. And the industry’s answer so far has mostly been to tell humans to read harder.
That won’t work, and most of us already know it. The fix for the verification bottleneck is not humans reading more diffs. It is building verification capacity as a system, the way we once built CI. Humans stop reviewing code. They start reviewing evidence.
The bottleneck moved downstream and put on a disguise#
The generation problem is solved. An MIT study of more than 100,000 developers found code volume up roughly 180% while shipped software rose only about 30%. The constraint is no longer producing code. It is getting code to a state anyone is willing to put in production.
And here is the part that should sting. A LinearB study of 8.1 million PRs across 4,800 organizations found developers feel 20% faster while merged-to-production time is actually 19% slower. Everyone is typing less and waiting more. The keyboard got fast. The gate stayed human-sized.
I wrote before that AI made code cheap to produce, not cheap to own. This is that gap, matured into a full-blown organizational failure mode. Ownership starts at the review gate, and the review gate is where the whole pipeline now piles up.
The human GIL is a correct diagnosis and a terrible strategy#
Martin Fowler named the problem precisely: the human is the Global Interpreter Lock for agents. Everything the fleet produces serializes through one person’s attention. His advice: don’t launch more agents than you can properly review. Two weeks later he quoted Charity Majors on what happens when you ignore that: “when you ship code faster than engineers can read it… reliability degrades, institutional knowledge evaporates.”
They are right about the failure mode. Zoom out two years and the curve is even steeper: The Pragmatic Engineer reports teams running agents now ship five times more pull requests than they did two years ago, at triple the size, and the same writeup carries a Meta account-takeover vulnerability as the cautionary tale of what merges when volume outruns comprehension. Nobody serious disputes the diagnosis.
But “slow down” is a holding pattern, not a strategy. It caps your engineering organization’s output at the reading speed of its most conscientious reviewers. Forever.
We have seen this exact shape of problem before. Twenty-five years ago the bottleneck was testing. Releases piled up behind manual QA cycles, and the industry’s first instinct was the same one it has now: test harder, run longer QA cycles, slow the releases. That instinct lost. We built CI instead. Nobody today asks a release manager to hand-run the regression suite, and nobody calls that recklessness. We turned verification from a human virtue into a system property.
Bryan Finster put it bluntly: AI broke traditional code review, and the answer is to restructure it rather than heroically read more diffs. I’d go one step further. The review gate has to become something else entirely.
The review gate becomes an evidence gate#
Here is the reframe I’ve landed on after living with agent fleets in production.
Stop asking humans to verify code. Ask the system to produce evidence, and ask humans to judge it. The evidence gate replaces “a person read the diff” with “the change arrived with machine-verified proof”: failing-then-passing tests, a reproduced bug, validation runs, scope and regression checks. The human rules on the two things machines can’t: intent and architecture.
Call it evidence-based review. The diff is the claim. The evidence is the proof. The human is the judge, not the fact-checker.
Concretely, evidence looks like this:
- Reproduction. A bug fix ships with the bug demonstrated failing before the change and passing after it. Not “trust me.” A recorded, re-runnable repro.
- Adversarial tests. Tests written to break the change, ideally by a different agent than the one that wrote it. Author-written tests are a conflict of interest whether the author is a human or a model.
- Validation runs. The change exercised in a real environment, end to end, with the output attached.
- Scope discipline. Proof the diff touches only what the claim says it touches. Agents love to “improve” three unrelated files on the way through.
- Regression and blast-radius checks. What else depends on this path, and what happened when the suite ran against it.
None of that requires a human minute. All of it can be produced by the same class of machinery that produced the code. In my own organization, that is the bar I hold the autonomous systems that investigate bugs and write fixes to: a change that arrives without its evidence isn’t “waiting for review.” It isn’t done.
And this is measurable, not hand-wavy. Cognition’s FrontierCode benchmark is the first to score agent PRs on whether a maintainer would actually merge them: correctness, test quality, scope discipline, regression safety, judged by criteria built with more than twenty senior open-source maintainers. Every frontier model passes fewer than half of the hard tasks (the leaderboard leader clears the field by about twelve points and still lands under 50%). Two lessons in one number. First: agents have not earned blind trust, so the gate stays. Second: merge-worthiness can be scored by a machine. If a benchmark can grade correctness, test quality, and scope discipline, your pipeline can demand them.
If your best engineers are your validation layer, you built the system backwards#
LeadDev documented what agent velocity is doing to the people downstream of it: mid-level engineers silently absorbing unmeasured “invisible validation work,” with one org losing three of them in six to eight weeks while the team shipped 40% faster, right up until the production incidents arrived. A survey of 2,147 engineers found 71% often feel like a middleman between AI output and actual results.
I believe every word of it. I’ve watched the pattern form: the diligent engineers become the org’s immune system, quietly re-verifying everything the agents produce, unmeasured and unthanked, while the dashboard celebrates throughput.
But notice what that actually is. It is not proof that agents don’t work. It is proof that the organization deployed generation capacity without deploying verification capacity, and then made its most conscientious humans eat the difference. The invisible validation work exists because the visible validation system doesn’t.
That’s not diligence. That’s a design flaw with a burnout rate.
The evidence gate is the answer to the middleman problem, not a competitor to it. Every hour a mid-level engineer spends manually confirming that an agent’s fix actually fixes the bug is an hour the system should have spent producing a repro automatically. Humans reviewing evidence instead of re-deriving it is not just faster. It is the difference between judgment work, which builds engineers, and verification drudgery, which burns out exactly the people you need to become your next seniors.
Verification is a system you build, not a virtue you demand#
If this sounds like the Agentic Overwatch tier model, that’s because it is the same shape. Code review is simply the first engineering ritual to move into the Agent Operations Center. The evidence gate runs in the same three tiers:
Tier 1, evidence production. Agents and deterministic tooling. Every change automatically generates its repro, its adversarial tests, its validation run, its scope and regression report. This is CI’s grandchild: not “did the tests pass” but “here is the complete case for this change.”
Tier 2, adjudication. Agents reviewing agents. A second system cross-examines the evidence: are these tests real or decorative, does the repro actually exercise the bug, did the diff sprawl beyond its claim. Weak cases get bounced back before a human ever sees them.
Tier 3, judgment. Humans. Intent: should this change exist at all? Architecture: does it belong here, shaped like this? Consequence: what’s the blast radius if the evidence lied? These questions don’t scale with lines of code, which is exactly the point. Human attention should never have been scaling with lines of code in the first place.
Fowler is right that human attention is the lock. So stop routing everything through it. Route claims and proofs through it, at the altitude where human judgment actually operates, and let the machinery below grind through the volume the way CI grinds through test matrices.
What to do Monday morning#
Measure the validation tax. Ask your mid-level engineers how many hours last week went to verifying agent output that nothing tracked. The number will unsettle you. Good. Invisible work stays broken precisely because it’s invisible.
Define evidence requirements per change class. A bug fix ships with a reproduction. A refactor ships with regression proof. A dependency bump ships with a blast-radius report. Write it down like you once wrote down test-coverage rules. No evidence, no review slot.
Build the evidence harness before you scale the fleet. Every agent lane you launch without automated evidence production is another engineer conscripted into middleman duty. Verification capacity first, generation capacity second. Most orgs did it in exactly the wrong order, which is how we got here.
Retrain the reviewer role. Your reviewers stop being line-by-line readers and become adjudicators: they rule on whether the evidence supports the claim and whether the change deserves to exist. That is a promotion, not a demotion. It is also the Tier 3 skill your whole agent operation will run on.
The teams that keep the human as the interpreter lock will spend the next two years choosing between capped velocity and quiet reliability decay, while their best people burn out doing verification work no dashboard sees. The teams that build the evidence gate get the volume and the trust.
Code review isn’t dying. It’s being promoted, from reading the work to judging the case.
Stop reviewing code. Start reviewing evidence.
How is your team handling review under agent volume? Whether you’re drowning in diffs or already building the evidence machinery, I want to hear what’s working. Find me on X, LinkedIn, or Telegram.