Reviewer capacity is fixed and generation isn't, so any plan that scales review loses on arithmetic. The lever that actually works shrinks how much change needs a human at all.
By JP LeBlanc
Review is not the bottleneck. It's a symptom, and most of the tooling market spent this year treating the symptom as the disease. You cannot scale human review to match what agents generate, and every plan built on trying will lose, because reviewer attention is fixed and generation isn't. The lever that actually moves the number is different: shrink what has to enter the queue in the first place, by making enough of the work small and reversible that a human doesn't need to look at it at all.
Faros AI's 2026 telemetry, across roughly 22,000 developers, tells the story in three numbers that all point the same direction. Median code review time up 441.5% against a 33.7% rise in task throughput. Pull requests merged with zero review up 31.3%. Production incident ratio up 242.7%, according to the same dataset. LinearB's numbers across 8.1 million pull requests land the same way from a different angle: AI-assisted PRs running 400-plus lines at the 75th percentile against 157 for unassisted work, and 16-plus hours to reviewer pickup against roughly 200 minutes for unassisted changes.
Every one of those numbers points the same direction. Generation accelerated. Review didn't, because review runs on human attention, and human attention doesn't scale the way a model's output does. Nobody repealed the review policy at any of these companies. It just got outrun, quietly, one sprint at a time, until the queue was the thing everyone was managing instead of the work.
The standard fix is a second reviewer tier for high-risk changes, more senior eyes on the stuff that matters most. It buys a quarter, maybe. Senior reviewers have exactly the same fixed-capacity problem as everyone else, just at a higher hourly rate, and the queue in front of them grows at the same pace as before. Adding people to a queue whose input is growing faster than any hiring plan can match doesn't fix the queue. It just makes the queue more expensive.
The instinct under all of this, the reason the queue keeps getting bigger reviewer additions thrown at it, is that a signature at the bottom of a diff feels like safety. It never was the safety. It was a proxy for safety, cheap and roughly correlated back when one engineer produced one plausible change a day and a second engineer reading it was the best available check on that change. At agent volume, the correlation breaks, and the signature keeps arriving without meaning what it used to mean.
The actual question was never "did a human look at this." It's whether the change is cheap to be wrong about. Autonomy, and the review that gates it, should follow blast radius, not task type and not who or what authored the change. A one-line dependency bump and a schema migration that drops a column are not the same category of risk just because both arrived as pull requests, and treating them identically is how a team ends up demanding two human approvals on the bump while a genuinely dangerous change slides through on a Friday because it looked routine.
Shrink what enters the queue first. Most teams review everything by default and then wonder why the queue is red. Score changes by reversibility and route the reversible, low-blast-radius ones straight through a canary and a flag, no human in the loop at all. That's the lever with the right slope, because it's the only one of the four that reduces the queue instead of processing it faster.
Have agents review agent output before a person sees it. Not as a replacement for human judgment on anything that matters, but as a first pass that catches the mechanical class of defect, a missing test, an unhandled null case, a diff that touches more files than the ticket implied, before it costs a human's attention at all.
Move review earlier, onto the spec instead of the diff. For well-specified work, the artifact worth approving is the intent, not the four hundred lines it produced. Get the spec wrong and you've automated the mistake instead of catching it, but get the spec right and reviewing it once is cheaper than reviewing every diff it generates downstream.
Put a WIP limit on agents, the same rule that's applied to humans for a decade and almost nobody has extended to machines. Nobody starts new agent work while the review queue is red. It sounds almost too simple to be the fix, and it is the fix, because most teams have never once told an agent to stop generating.
The cheapest-looking move is to route around all four of these levers by asking your most senior engineers to review faster. It works for a sprint. Review time drops, everyone feels momentum, and then the escape rate climbs, because "faster" and "as careful" are the same tradeoff wearing a different name. Team composition built for a world where writing code was the scarce resource doesn't survive contact with a world where review is, and asking people to work harder inside the old structure is a way of postponing that fact, not resolving it.
The org that gets this right doesn't have a faster review process. It has less that needs one, which is a different kind of win and a better one, because it's the only version of this that keeps working as volume keeps climbing. I've made the harder version of this argument elsewhere: most of what a human signature catches, the machinery underneath it already catches better, and the signature that's left is mostly there for comfort.
Comfort has a price. At current volume, you can't afford to keep paying it per diff.