The price of the verifier
Generation stopped being the constraint some time in 2025. Everything difficult about factories in 2026 is downstream of that.
The constraint on a factory is not how much code it can churn out but how quickly it can verify itprimary. Generation is a wide mouth; verification is a narrow neck; speeding up the mouth just deepens the pile at the neck.
From which the operative rule: you can hand a loop as much autonomy as you can cheaply and reliably verify, and not one inch moreprimary. Huntley calls the discipline of building for that constraint back pressure engineeringprimary.
Volume is not the problem
A surplus of pull requests is not a crisis. A surplus of bad pull requests isprimary — because each one consumes the scarce resource whether or not it turns out to be worth merging, and you cannot tell which is which without spending it.
This is why throughput numbers, on their own, say nothing. Stripe’s 1,300 agent-authored PRs a week is an impressive figure precisely because every one of them is reviewed and the review system was built to absorb themprimary. The same number without that back half would describe a queue, not a factory.
What review costs
Two numbers frame every factory budget, and they sit about three orders of magnitude apart.
| Item | Figure | What it rests on |
|---|---|---|
| Agent review, per pull request | ~$0.05reputable | Industry cost analyses; moves with token prices |
| Human review, per pull request | $15–25reputable | Same analyses; moves with salaries |
| Anthropic's review tooling, per PR | ~20 minprimary | Vendor's own measurement; lands at the top of the human band |
| Large PRs where it flagged an issue | 84%primary | Same, averaging 7.5 findings each |
| AI review comments that are false positives | 20–40%reputable | Practitioner measurements; the number that decides whether the cheap column is real |
| Growth in code output per engineer, one year | 200%primary | Anthropic; the generator of the backlog the tooling sells into |
The spread is what matters, not the decimals. Both ends move with token prices and salaries; the gap between them is structural.
Two adjustments before anyone reaches for the cheaper number.
First, quality. A finding that is wrong is not free: it costs a human the time to dismiss it, which is the resource you were trying to protect, and the false-positive band above is wide enough to swallow the saving. OpenAI published a utility model that makes the arithmetic explicit: a finding’s value is P(correct) × C_saved − C_human_verification − P(incorrect) × C_false_alarmprimary. Below some precision, adding review agents makes the bottleneck worse.
Second, the same vendors sell both sides, which the last row of the table says quietly: the company reporting the growth in output also sells the tool for the resulting backlog. Qodo raised $70M specifically to work on AI code verificationreputable. This is not an accusation — the bottleneck is real and someone should build for it — but the review market’s growth is not independent evidence that review is solved.
Verification debt
Werner Vogels’ term for what accumulates when the neck cannot keep up is verification debtprimary: the cost of AI-generated code that was merged but never properly checked.
The most useful measurement of it is the Sonar developer survey, 1,149 respondents, published in January 2026reputable. AI accounts for 42% of committed code. 96% of developers do not fully trust it. Only 48% always verify it before committing. And 38% say reviewing AI code takes more effort than reviewing human code.
Those four numbers describe a specific and uncomfortable state: near-universal distrust, roughly half-verified, at almost half of all committed code. Whatever is happening at the neck, it is not that people stopped worrying.
The security tail is measurable too. Apiiro reported AI-generated code introducing over 10,000 new security findings per month by mid-2025, a tenfold increase in six monthsreputable.
Why better models do not close the gap
The natural hope is that the neck widens on its own as models improve. There is a structural reason to doubt it.
Architectural quality has a cost function measured in months and years, which produces no tidy gradient to train againstprimary. A model can be trained toward “tests pass” because the signal is immediate and dense. It cannot easily be trained toward “this abstraction will still be the right one in eighteen months”, because that label does not exist at training time and will not exist for eighteen months.
So the things a verifier most needs to catch are the things least available as training signal. Model progress moves the floor up. It does not obviously move this particular ceiling.
Budget the verifier explicitly, as its own line, before you scale generation. Track cost per useful review rather than per review. If verification cost per change approaches what you saved on generation, the factory is net-negative and the answer is narrower, more testable tasks rather than more agents.