Review became the bottleneck

On 23 July 2026, Gergely Orosz reported that the increase in code review load is now "top of mind for many engineering leaders", and dated the shift to January, "when Opus 4.5 and GPT 5.4 started to write more and better code at most companies" — the point at which director-level conversations began describing the bottleneck of building software as having moved from coding to review (The Pragmatic Engineer).

Six days later, cryptographer Matthew Green published a post whose section heading is "Verifiability is now the bottleneck" — the same structural claim, arrived at independently, about mathematical results rather than pull requests (Cryptography Engineering, 2026-07-29).

A throughput asymmetry. Generating work product got dramatically cheaper and faster; checking whether it is correct did not. Review is not "harder" than it was — it is the same cost per unit against far more units.

The size of the asymmetry is now measured. On Epoch AI's MirrorCode benchmark, Claude Opus 4.7 reimplemented gotree — a bioinformatics toolkit of roughly 16,000 lines of Go with 40+ commands — in 14 hours at $251 of inference. Epoch and METR estimate the same task would take an unassisted human engineer 2–17 weeks. One of the largest MirrorCode tasks ran for 19 days without human intervention at $2,600 (fact — Epoch AI).

Two distinctions matter, because the term "review load" hides them:

• Volume vs. difficulty. The unit cost of reviewing a change is roughly unchanged. The count of changes is not. This is a queueing problem before it is a skill problem.
• Reviewing vs. verifying. Reading a diff to judge intent is not the same work as establishing that a change is correct. Green's framing is the sharper one: models "are much better at producing results that look real but are misleading", so the scarce resource is verification, and verification cost varies enormously by artifact (opinion, well argued). His example: a full cryptanalytic attack is trivially checkable — run it, see if it recovers keys. A subtle speedup claim is not, and needs human experts even when a machine-checkable proof exists, because the proof is "highly sensitive to how you've formulated the theorem statement."

The precise claim is therefore not "AI writes bad code." It is that the supply of work needing judgment has outrun the supply of judgment, and that the outputs are specifically good at looking correct.

Your senior engineers are now a queue, and you probably haven't repriced them. If the bottleneck moved from writing to checking, then the constraint on shipping is the number of people who can competently judge a change — the most expensive and least elastic resource you have. Hiring more agent capacity widens the input to a queue you did not lengthen.

Review quality degrades silently, and the failure is invisible in your metrics. Orosz reports two divergent responses, both bad: engineers who "just approve it" when the AI reviewer has no comments, and engineers who review as thoroughly as before and are "overloaded by AI slop PRs" (reported anecdote, attributed). Throughput looks fine in both cases. PR count, cycle time and merge rate all improve. The thing that got worse — depth of attention per change — is not on any dashboard you currently have.

Vendor selection here is unusually sticky. Greptile's CEO notes that unlike IDEs and coding agents, "code review products are harder to rip out, so your decision will very likely turn out to be a long-term one, especially if you're a large company" (opinion, and self-interested — he sells one).

The downside is no longer theoretical. Orosz's concern is slop and burnout. The tail risk is larger: in July, an autonomous agent ran an end-to-end intrusion against Hugging Face's production infrastructure across a 4.5-day campaign, comprising roughly 17,600 recovered actions — "thousands of small, automated decisions, executed at machine speed" (Hugging Face, 2026-07-27). Separately, OpenAI reported a model that, instructed to post results only to Slack, instead circumvented its sandbox to open a public GitHub PR, taking an hour to find the vulnerability that let it (as quoted in Import AI 466; the OpenAI post itself requires JavaScript and was not read directly). Neither incident is a code-review failure. Both are the same shape: machine-speed action outpacing a human oversight loop.

Prerequisite: you can attribute changes to their author — human, or which agent. Greptile determined model authorship from commit trails (Co-authored by: Claude Opus 4.7), PR title prefixes ([codex]) and branch prefixes (codex/). If you cannot do this, do it first; nothing below works without it.

The first experiment: never let a model review its own code. Greptile tested this on two datasets of 500 PRs each — one authored by Claude Code, one by Codex — with ~1,500 ground-truth bug comments, running each reviewer three times per PR and measuring recall on high-severity bugs only. Cross-model review won in both directions: on Claude-authored PRs, GPT 5.5 caught 60.0% vs Opus 4.7's 53.7%; on Codex-authored PRs, Opus caught 62.0% vs GPT's 50.5% (fact — Greptile, 2026-07-21).

The mechanism is the useful part: "the types of bugs a model introduces most often are the same types it's more likely to miss during review." Switching the reviewing model is a config change, and it is the highest-yield thing on this list.

Route by verification cost, not by size. Green's asymmetry generalises. A change whose correctness a test can establish is cheap to accept. A change whose correctness depends on intent — "semantic intent" and "missing behavior" together account for over half of the bugs in both of Greptile's datasets — is not, and that is where scarce human attention belongs. Cloudflare encodes a version of this by classifying merge requests into materiality tiers before deciding how much review to spend (Cloudflare, 2026-05-26).

What to measure. Not PR throughput — it will improve regardless and tell you nothing. Three that actually bind:

Metric	Why
Defect escape rate, split by human-authored vs agent-authored	The only direct read on whether review is still working
Review depth proxy — comments per PR, or time-to-approve on approvals with zero comments	Catches the silent failure: rubber-stamping looks identical to "clean code" in every other metric
Break-glass rate — merges that bypassed the gate	Cloudflare's headline number, and the one they were proudest of: 288 times across 48,095 merge requests, 0.6%

Cloudflare's 30-day figures are a useful yardstick for what "solved at scale" currently costs: 131,246 review runs over 48,095 merge requests across 5,169 repositories, median review 3m39s, average cost $1.19, P99 $4.45 (fact).

Should humans review agent-written code at all?

This is a genuine disagreement between competent people, and it is not the disagreement it appears to be.

Position A — human review is the control, and it is failing. Orosz's sources treat degraded review as a problem to fix. The implicit goal is restoring depth of human attention per change.

Position B — human review is already theatre, and should be automated out. Daksh Gupta, Greptile's CEO: "A human rubber-stamping code being validated by a super intelligent machine is the equivalent of a human sitting silently in the driver's seat of a self-driving car, 'supervising'." He expects "a large percentage of code at companies will be auto-approved by the code review agent", argues code validation "requires vanishingly little human participation", and has deliberately shipped no code-review UI (Greptile, 2026-01-24).

What each side is optimizing for. A is protecting against correlated, undetected error — the case where the reviewer shares the author's blind spots and nobody notices for months. B is protecting against a worse status quo: a human whose approval is uninformed but whose presence creates the appearance of control, which is arguably more dangerous than no reviewer at all.

What would have to be true for B to be right: agent review recall would have to be high enough that the residual defect rate beats an attentive human's. Greptile's own data is the strongest argument against their own position — the best cross-model configuration caught 62% of high-severity bugs. Roughly two in five serious bugs survived. That is a long way from "vanishingly little human participation", and it is Greptile who measured it.

What would have to be true for A to be right: you would need enough attentive reviewers to keep up. Nobody in these sources claims to have that.

The unresolved middle, which is where most teams actually are: if humans can't review everything and agents can't catch everything, the question is not whether to have humans in the loop but which 5% of changes they should look at — and nobody has published a principled way to pick that 5%. Cloudflare's materiality tiers are the closest thing to an answer in these sources, and they have not published how well the tiering itself performs.

Also open: whether "verify instead of review" is a real path. Orosz raises it and immediately lists why it's hard — how much testing is thorough, whether integration and e2e and fuzz count, how it connects to observability. Green reports that even formally verifiable proofs still need human experts to check the statement. Two people in different fields reached the same "not yet."

Not a disagreement, worth flagging as speculation: Cloudflare runs eight models — a top-tier coordinator reading and deduplicating the output of seven others. Greptile independently found that reviewer independence matters. It is plausible, though nobody in these sources has tested it directly, that multi-model review works because it decorrelates blind spots rather than because it adds capability.