Ask an engineer to review a 40-line change and they'll find the bug. Ask them to review a 1,000-line change and they'll write "LGTM" and move on. That instinct is backed by the largest study of code review ever run, and it should change how your team sizes pull requests.
Key Takeaways
- SmartBear studied 2,500 reviews across 3.2M lines at Cisco over 10 months, the largest code-review study ever (SmartBear/Cisco).
- Defect detection peaks at 200–400 lines and falls off past ~400, where reviewers get overwhelmed (SmartBear/Cisco).
- Kept to under 60–90 minutes at 300–500 lines per hour, a review catches most of the defects present; go faster and you catch fewer.
- Small PRs aren't politeness; they're the mechanism that makes review actually work.
What the Largest Study Found
SmartBear, working with Cisco, spent 10 months analyzing 2,500 code reviews covering 3.2 million lines of code (SmartBear/Cisco). The headline: defect-detection effectiveness is highest when a review covers roughly 200 to 400 lines. Past about 400, reviewers get overwhelmed and start missing defects. The reviewer didn't get lazy. Their attention got swamped.
The study also found a pace effect. A review kept under 60 to 90 minutes, moving at a steady 300 to 500 lines an hour, catches most of the defects that are actually there. Teams that blow through more than 500 lines an hour catch fewer, and a review that runs much past 90 minutes hits diminishing returns, because focused attention doesn't last much longer than that.
| Review characteristic | Effect on defect detection |
|---|---|
| 200–400 lines | Peak effectiveness |
| Over 400 lines | Reviewers overwhelmed, more missed |
| 300–500 lines/hour | Steady, catches the most |
| Over 500 lines/hour | Detection drops |
Why Big PRs Fail Review
A large pull request fails in two ways at once. First, attention: nobody holds 800 lines of logic in their head, so past a point the reviewer skims. Second, social: a huge PR represents a week of someone's work, so the reviewer feels pressure to approve rather than send it back. The result is a rubber stamp. The change ships, the bug ships with it, and everyone believes it was reviewed. Google's own code-review guidance tells engineers to keep changes small for exactly this reason (Google Engineering Practices).
A Concrete Version
An engineer batches a feature into one 1,200-line PR on Friday. The reviewer opens it, scrolls for ten minutes, decides it "mostly looks fine," and approves it so the person isn't blocked over the weekend. The one subtle off-by-one in the middle sails through, because a 1,200-line review is exactly where the study says attention gets swamped. Now split that same work into six 200-line PRs over the week. Each one gets a real read, the reviewer stays inside the 60-minute attention window, and the off-by-one gets caught on Tuesday in the PR where it lives. Same code, very different outcome.
The Honest Counterpoint
Small PRs have a real cost, and pretending otherwise is why some teams resist them. They mean more review overhead, more context-switching for reviewers, and sometimes an awkward stretch where a feature is split across several merged-but-dark PRs behind a flag. For a genuinely atomic change, a mechanical rename across 40 files, forcing a split is theater. The rule isn't "every PR under 200 lines no matter what." It's "keep the reviewable logic small," and lean on feature flags and stacked PRs so small doesn't mean half-broken.
What This Means for Distributed Teams
Review size matters more, not less, when your team is distributed, because you lose the tap-on-the-shoulder "walk me through this." A tight PR is self-explaining; a giant one needs a synchronous call across time zones to review well, which often just doesn't happen. Small, well-scoped PRs are part of what makes remote code review work, and they pair naturally with the async-first habits distributed teams rely on. See available engineers.
Frequently Asked Questions
What's the ideal code review size?
Around 200–400 lines, reviewed in under 60–90 minutes. SmartBear's Cisco study found defect detection is highest in that range and drops sharply beyond 400 lines.
Why do large pull requests get worse reviews?
Two reasons: reviewers can't hold that much logic in their head so they skim, and a large PR creates social pressure to approve rather than send back a week of work. Effectiveness peaks at 200–400 lines and drops past that as attention gets swamped.
How fast should code review go?
Steadily, at about 300–500 lines per hour. Teams that exceed 500 lines/hour miss more defects, and attention fades past roughly 60–90 minutes per sitting.
How do I keep PRs small without shipping half-features?
Use feature flags and stacked or incremental PRs so each change is small and reviewable while the feature stays dark until it's complete.
The Bottom Line
The largest study of code review is blunt: effectiveness peaks around 200–400 lines and falls off past 400, where reviewers get overwhelmed, and no amount of diligence beats the attention limit. Keep pull requests small, review them in one focused sitting, and you turn code review from a rubber stamp back into a real defect filter.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
