The pull request was 1,140 lines. The description was four bullet points. It had been opened eleven minutes after the ticket was assigned.
I looked at it for forty minutes, approved it, and merged something I did not fully understand.
That was the week I started keeping numbers, and the numbers showed an AI code review bottleneck sitting in the middle of my team like a parked truck. We were producing more code than ever and shipping it slower than ever.
TL;DR
- The AI code review bottleneck is what happens when agents generate code faster than humans can approve it. The throughput gain doesn't reach production, it piles up in the review queue.
- On my team of six over one quarter: PRs opened per week went from about 31 to about 68. Median time-to-merge went from ~4 hours to ~14. P90 went from a day and a half to five days.
- AI code is harder to review than human code because it's uniformly plausible. There are no rough edges marking where the author was unsure, and no author intent to interrogate.
- What fixed it was social, not technical: a hard diff-size cap, a "what I actually verified" section, and refusing to review code the author can't explain in one sentence.
- Adding an AI reviewer bot did not fix it. It added a second stream of plausible text to read.
What is the AI code review bottleneck?
The AI code review bottleneck is the gap between how fast code can be written and how fast it can be accepted. Generation got roughly 5x cheaper in a year. Human attention did not get cheaper at all. So the constraint moved from the keyboard to the reviewer's eyes, and every "productivity gain" upstream just makes the line at that door longer.
You can watch this in your own repo in ten minutes. Pull PRs opened per week and median time-to-merge for the last six months and put them on the same chart. If the first line is going up and the second one is too, you don't have a velocity problem. You have a queue.
Why did merge time go up when we were shipping more code?
Because review capacity is fixed and queues are not linear. This is boring operations-research math that every engineering team rediscovers the hard way.
Three things compounded for us:
Arrival rate doubled. Same six people, twice the PRs. As a queue approaches full utilization, waiting time doesn't rise gently, it goes vertical. Going from "reviewers are 60% busy" to "reviewers are 90% busy" is not a 30% slowdown. It's a multiple.
PR size grew. Median diff went from around 90 lines to around 310. And review effort is superlinear in diff size. A 300-line PR is not three times the work of a 100-line one, because you also have to hold three times as much in your head simultaneously to spot an interaction bug.
Reviewers started batching. When there are two PRs waiting, you review them. When there are nine, you wait until you have a clear block of time. That block never comes, so PRs sit overnight. Overnight is where trust goes to die.
The nasty part is the feedback loop. Slow reviews make authors bundle more work into each PR (why open a small one if it'll sit for a day?), which makes reviews slower, which makes PRs bigger.
Why is AI-generated code harder to review than human code?
This is the part I underestimated. It isn't just volume. AI diffs are genuinely more expensive per line to read, for four reasons.
1. Uniform plausibility. Human PRs have tells. A weirdly named variable, a commented-out block, a function that's suspiciously longer than its neighbors. Those are the author's uncertainty leaking through, and experienced reviewers follow them like a scent. AI output is evenly confident everywhere. Line 12 and line 812 look equally considered, so your attention has nothing to grab. You end up reading uniformly, which means reading shallowly.
2. There's no intent to interrogate. The best review question is "why did you do it this way?" Against a human, the answer is either a good reason you didn't know about, or a visible flinch. Against a PR the author generated, you get a shrug, or worse, you get the agent's answer, which is whatever sounds most agreeable. The reviewer becomes the only source of judgment in the entire pipeline.
3. Volume without compression. An agent writes the version that works, not the smallest version that works. Extra abstraction layers, a helper called from exactly one place, defensive branches for conditions that can't occur. None of it is wrong. All of it is surface area you now have to read and maintain forever.
4. The tests agree with the code. If the implementation misunderstood the requirement, the generated tests usually encode the same misunderstanding. Green CI stops being evidence. It just tells you the code is self-consistent.
What actually fixed the AI code review bottleneck?
Nothing clever. Five rules, four of which are about human behavior.
A hard 400-line cap on diffs. CI labels anything bigger and the label blocks merge until a human writes one sentence explaining why the split wasn't possible. About one PR in fifteen gets an exception. The other fourteen got split, and splitting them turned out to be easy, because the agent that wrote them can also split them.
A "what I verified" block in the PR template. Three lines, and "the tests pass" is explicitly not allowed. It has to be things the author personally did: ran the endpoint with a bad payload, checked the migration on a copy of staging data, confirmed the old cache key still resolves. This one change did more than everything else combined. It's a speed bump between "the agent finished" and "I'm asking for your time."
The explain-back rule. A reviewer can point at any hunk and ask what it does. If the author can't answer in one sentence, the PR goes back. Not as punishment. It's just that if nobody in the conversation understands the code, the review is theater. Drive-by generation stopped within two weeks.
Review against the ticket, not against style. Our highest-yield review question became "what did this change that we didn't ask for?" Agents love an unsolicited refactor. Scope creep in an AI diff is invisible unless you're specifically hunting for it.
Split the commits by who decided what. First commit: the mechanical 80% the agent produced. Second commit: the judgment calls the human made on top. Reviewers read the second commit first. Ninety percent of the risk lives there, and it's usually thirty lines.
Median time-to-merge came back to about six hours. Not four. Six is what honesty costs.
What didn't work?
Adding an AI reviewer bot. I wanted this to work. What we got was more text to read, plus a subtle new failure: a PR with eight resolved bot comments feels reviewed. Ours flagged naming and missing docstrings with great enthusiasm and walked straight past an N+1 query in a loop that a human caught in nine seconds. It's fine as a linter. It is not a reviewer, because it has no stake in the system still working next quarter.
Adding more reviewers. Review does not parallelize across the same PR. Two reviewers on one diff produces one careful read and one skim, and neither of them knows which one they are.
"Just trust the tests." Covered above. The tests were written by the thing that misunderstood the requirement.
So why did AI make code review the bottleneck?
Because AI removed the constraint that was hiding it. When writing a feature took two days, review was a rounding error on the schedule and nobody measured it. Now writing takes twenty minutes, and review is the only step in the pipeline that still runs at human speed, so it absorbs all the delay that used to be spread across the whole cycle. The teams getting real speedups from AI aren't the ones generating the most code. They're the ones who noticed that acceptance, not authorship, is now the scarce resource, and who redesigned their process around making diffs cheap to read rather than cheap to write. Small PRs, stated verification, and a rule that you don't merge what nobody can explain.
What does your merge-time chart look like since your team started using agents? I'd genuinely like to know if anyone got a different result.
Top comments (0)