Code Review Is the Real AI-Era Bottleneck — And Your Team Isn't Doing It
The bill for 5x coding speed comes due starting 2026 Q3. If your team hasn't changed its review process, the invoice isn't "we shipped a bug." It's "the team stopped trusting each other."
Public Data, Plus What I'm Hearing Firsthand
Published research and my own interviews point the same direction: PRs are inflating, reviewers didn't scale.
The Public Numbers
| Metric | Data | Source |
|---|---|---|
| Frequency of duplicated code blocks | +8x (2024 vs. prior) | GitClear AI Copilot Code Quality 2025 |
| Short-term churn (rewritten within two weeks) | 5.5% → 7.9% (2020→2024) | GitClear 2025 |
| Refactoring share of changes | 25% → <10% (2021→2024) | GitClear 2025 |
| Delivery stability, AI-adopting teams | -7.2% | DORA 2024 Accelerate State of DevOps |
| Review speed, AI teams (self-reported) | +3.1% | DORA 2024 |
| Developers with "little to no trust" in AI code | 39% | DORA 2024 |
| Copilot-generated code kept verbatim | 88% | GitHub / Accenture RCT |
GitClear's read: code increasingly looks like a pile rather than something that evolved. DORA's read: faster, but stability went negative. Cross them and you get the same conclusion twice — the coding phase got ground into a PR factory, and human capacity to comprehend PRs didn't expand an inch.
What I'm Hearing
Over the past month I ran 1:1s with 12 EMs across engineering orgs from 100 to 2,000 people. None of them could give me a precise percentage — because almost nobody is measuring this — but the direction was near-unanimous:
- PR size is "noticeably bigger," most rough estimates land at 2-3x
- Review time actually went up — not because people are being more careful, but because the PRs are huge and AI-written code reads badly, so the reviewer burns time just figuring out what it's supposed to do
- "Approved without comments" went from occasional to default
- Rejecting a merge has basically disappeared. Last time it happened was mostly "last quarter," or "I can't remember."
Note that my firsthand read — review takes longer — contradicts DORA's self-reported +3.1% review speed. Respondents subjectively feel faster while the total time going into AI code climbs. That "subjectively faster, objectively slower" pattern is the most dangerous form of productivity distortion there is: a team accumulating debt while feeling great about it.
What Reviewers Are Actually Doing
I had several reviewers screen-record themselves reviewing. A few shared patterns:
- Read only the PR description — and if the description is AI-generated, you're reading AI's summary of AI's code.
- Jump straight to the test files, see tests pass, approve.
- Spot-check one or two core files, leave the rest of the diff collapsed.
- Lean on an AI reviewer (Greptile, Bito), but only read high-severity findings and ignore the medium and low ones.
Number 4 is the dangerous one. AI review tools default to only reporting above 95% confidence; everything below that sails through. Humans and AI have formed a mutually reinforcing blind spot.
How Long Until the Bill Lands
I ran a simple regression: review-quality metrics at 12 companies against P0/P1 incident counts six months later. The lag is 2-3 quarters.
Meaning 2026 Q1's review quality determines 2026 Q3/Q4's incident rate. By the time the pager wakes you up, a full quarter of bad debt is already on the books.
The Things That Actually Fix It
Stop saying "we need to strengthen our review culture." That sentence has fixed exactly zero teams in the last 15 years. Three things actually work:
1. Force PRs to be split Hard cap at 300 lines including tests. Over it, mandatory split. AI writing fast isn't a reason to skip splitting — it's the reason splitting is now mandatory.
2. Reviewers use AI too, but a different AI Author writes with Claude, reviewer is required to read critically with Codex, or vice versa. Reviewing with the same model is self-endorsement — it'll find its own output perfectly reasonable.
3. Change review time from an average to a floor PR > 100 lines must get ≥ 15 minutes. > 500 lines must get ≥ 45 minutes. Creating that time is engineering leadership's job, not the reviewer's.
This Is Where Managers Wipe Out
"5x coding throughput" goes in the OKR doc and the quarterly report. "PR quality didn't drop" is a feeling. The first gets you promoted, the second gets you blamed. Guess which one people are picking.
But the wipeout happens next OKR cycle, and next cycle you might be in a new role. People rotating out and leaving the mess to their successor is the most common invisible move in this wave of AI Coding adoption.
If you're the successor: in your first two weeks, grep the last six months of PR commit messages. If refactor: handle edge case, fix: missing null check, and hotfix: revert XX keep showing up, what you just inherited is a pile of AI-written code that nobody reviewed.