The math doesn't work

Code generation scales with the number of AI agents you run. Review scales with the number of senior engineers you have. Those curves diverge fast.

A CTO running multiple AI agents in parallel reported processing over 1,000 PRs per week. He wasn't exaggerating for effect. That's the actual volume when you give agents autonomous coding capability on a real codebase. The review queue doesn't grow linearly. It compounds.

A director at a tier-1 bank summed it up: "We fixed the writing code problem. Now we've created a reviewing code problem."

What happens when review can't keep up

Reviewers skim. When the queue is 40 PRs deep, nobody reads every line. Approval becomes a quick scan for obvious problems. Subtle issues - removed guard clauses, widened access patterns, missing error escalation - pass through unnoticed.

Seniors burn out. The people most qualified to catch problems are also the most in demand. If every AI-generated PR needs a senior engineer's judgment, senior engineers spend their entire day reviewing instead of building. The team's most valuable members become its bottleneck.

Rubber stamp culture forms. When reviews are required but reviewers don't have time, the review becomes a checkbox. It still shows up in the audit trail as "reviewed and approved," but it caught nothing. This is worse than no review, because it creates the illusion of verification.

Merge quality drops quietly. There's no dramatic failure. Things just gradually get worse. More production incidents. Longer debugging sessions. Growing portions of the codebase that nobody fully understands. By the time the trend is visible, months of unverified changes have already shipped.

What doesn't scale

Adding more reviewers. Reviewing AI code requires deep system context. You can't hire your way out of a review bottleneck because new reviewers need months to build that context. And by the time they have it, the codebase has moved.

Splitting reviews across more people. This distributes the load but fragments the context. Each reviewer sees a slice of the changes but nobody sees the full picture. Cross-cutting issues - an auth change in one PR that conflicts with a data contract change in another - fall through the gaps between reviewers.

Telling reviewers to be more careful. When AI generates 10x the volume, asking reviewers to be more thorough is asking them to drink from a fire hose more carefully. The intent is right. The capacity isn't there.

What changes the equation

The teams handling this well aren't choosing between "review everything" and "trust the AI." They're making review risk-proportional.

That means automated triage before a human looks at anything. A low-risk formatting change doesn't need the same attention as a change that touches authentication logic. But that triage can't be left to the PR author or the AI that generated the code. The risk classification has to come from the change itself: what structurally changed, how many files are affected, which boundaries were crossed.

When risk classification is objective and automatic, seniors spend their judgment where it actually matters. A review queue of 40 PRs becomes 5 that need real attention and 35 that have been verified at the structural level. That's the difference between a bottleneck and a workflow.