The Review Bottleneck Is Real — and Getting Worse
In April 2026, GitHub launched Stacked PRs into private preview — a native workflow for breaking large changes into chains of small, dependent pull requests. The timing wasn't accidental. As GitHub's Sameen Karim stated plainly: "The bottleneck is no longer writing code — it's reviewing it."
This is a problem most engineering teams already know intuitively but rarely measure. The data, however, is stark.
What the Numbers Say
An analysis of over 50,000 pull requests across 200+ teams found that PRs over 1,000 lines have 70% lower defect detection rates than smaller ones. Extra-large PRs average 4.2 hours of review time but produce only 1.8 meaningful comments — fewer than small PRs reviewed in under an hour.
The pattern is consistent: as PR size increases, reviewer fatigue sets in. Human working memory can track roughly 7±2 pieces of information simultaneously. A 1,000-line diff across multiple files overwhelms that capacity, and reviewers shift from deep analysis to shallow pattern-matching. The result is the infamous "LGTM 👍" — a rubber-stamp that lets bugs through.
Security data reinforces this. Research from over 50,000 repositories found that organizations resolving PR-detected findings fix issues in 4.8 days on average, while the same class of finding from a full repository scan takes 43 days. Catching problems at PR time works — but only when PRs are small enough for reviewers to actually engage.
AI Is Making This Worse Before It Gets Better
AI coding agents are accelerating the creation side of the equation dramatically. Anthropic found that substantive review comments on PRs with over 1,000 changed lines rose from 16% to 84% after teams adopted automated review tooling. That improvement is encouraging, but it also reveals how little scrutiny those large PRs were getting from humans alone.
The volume problem is real. AI-assisted code output is growing fast, and review processes built for human-speed development are buckling under the weight.
The Fix Isn't Just Tooling
Stacked PRs — whether via GitHub's new native feature, third-party tools, or disciplined branching strategies — address the structural problem. Facebook recognized this back in 2007 when Evan Priestley built Phabricator's Differential, specifically because he was "spending a lot of time waiting for code review to happen."
But tooling alone isn't sufficient. Teams need to treat review time as real engineering work, not overhead squeezed between feature tasks. Managers need visibility into which PRs are stale, which carry risk, and where reviewers are overwhelmed.
This is one of the reasons we built Code Board's PR Risk Score — an automatic heuristic assessment based on diff size, CI status, merge conflicts, and sensitive file changes. It gives reviewers a signal before they open the diff, so they can prioritize attention where it actually matters.
The Takeaway
Keep PRs under 400 lines. Break features into logical layers. Use risk signals to focus human attention. And stop treating code review like a checkbox — it's where quality actually happens.
Top comments (0)