Search "how many lines should a pull request be" and you will find the same answer over and over: keep it under 400. Sometimes it is 200 to 400, sometimes "a few hundred". It is always stated as settled fact.
We wanted to know where it comes from. It turns out to be a short trip.
The source: one team at Cisco, in 2006
The number traces back to a study that SmartBear, a code review tool vendor, ran with a Cisco team. Over ten months, 50 developers on three continents had every change reviewed before it went into version control. The study collected metrics from 2,500 reviews covering 3.2 million lines of code, all run through SmartBear's own review tool.
The headline finding is that defect density dropped sharply once a review went past about 200 lines. SmartBear's current guidance turns that into advice: review no more than 200 to 400 lines at a time, because beyond 400 the ability to find defects diminishes.
That is a real study with real data. It is also where most of the evidence stops.
What it measured, and what it didn't
Defect density in this study means defects found per amount of code reviewed. So a drop past 200 lines means reviewers found fewer defects per line. SmartBear reads that as reviewers losing focus. We read it the same way.
What it cannot tell you is whether the code had fewer bugs, or whether the PR was a bad idea to ship. It measures how well people read, not how risky the change was.
A few more things worth knowing:
- It was one team, on one product, in 2006, reviewing in a dedicated tool before commit. A modern pull request on GitHub, with CI and a long discussion thread, is a different thing.
- Jason Cohen's write-up of the study says the statistical methods and the experimental controls are covered in the book, not in the article.
- The "70 to 90% defect discovery" figure that often rides along with the 400 lines is on SmartBear's page without a source attached.
- The company that published the number sells the tool that reviews code.
None of that makes the number wrong. It makes it a starting point, not a law.
The newer numbers, and why they seem to disagree
Two vendors publish more recent data, and at first glance they conflict.
LinearB's 2026 benchmarks cover 8,109,244 pull requests from 4,813 teams. They rate PR size at the 75th percentile: under 100 lines is Elite, 100 to 155 is Good, 156 to 228 is Fair, and above 228 needs improvement. Their page does not say whether size counts added lines, deleted lines, or both.
Graphite, in a 2023 post, argues the ideal median PR is 50 lines, with 25 to 100 as a range. They found 50-line changes were reviewed and merged about 40% faster than 250-line changes. Their revert chart, built from a sample of 10 million PRs, shows the least reverted PRs were 25 to 50 lines. The gap is small in absolute terms though: revert rates sit between roughly 1% and 1.6% at almost every size. Their users also skew toward small PRs, which they note themselves.
The two are not really fighting. LinearB reports the 75th percentile of a team's PRs. Graphite reports the median. Three quarters of a team's PRs under 100 lines and a median of 50 can both be true for the same team. They are two views of the same distribution.
Both vendors also sell tools that measure PR size and review speed. Neither number is wrong for that reason, but both come from people who profit when you care about the metric.
One more detail from the LinearB data is worth a note. In their breakdown, the 75th percentile PR is about 157 lines unassisted, about 293 for agent-written PRs, and about 408 for AI-assisted ones. They are clear that this is correlation, not cause. It does show that the "right" size depends on how the code was written.
What none of this shows
No source we found shows that a PR over 400 lines is more likely to ship a bug. The Cisco study is about review quality. The vendor data is about speed and reverts. Neither follows the code after it merges.
Size also counts lines, not review effort. A 2,000-line PR that moves a directory is easier to review than a 60-line change to a payment flow. Generated files, lockfiles and migrations inflate counts without adding load. Graphite's own revert chart has an odd tail too: PRs over 10,000 lines look slightly safer, which the author guesses is because the biggest changes are refactors.
What we would do with it
- Treat 200 to 400 lines as a reasonable ceiling for one review sitting, not a rule. It is the best-supported number, and it is about reading, not shipping.
- Measure your own median and your own 75th percentile. That is what the vendors report, and it is the only number that describes your team.
- Exclude lockfiles, generated files and pure moves from the count.
- When a change must be large, say what to read. A short "start here" note in the description does more than splitting a PR arbitrarily.
- Care about what is in the lines. A small PR that adds a branch-heavy function with no test is a bigger problem than a long one that is mostly deleted code.
That last point is why we built DebtDraft. It is a GitHub Action that leaves an updating comment on each pull request with a health score, and a view of just the lines that PR changed. We make it, so weigh our view accordingly.
So what is your number? How many lines do you keep a pull request to? At what number does a PR become overwhelming to you?
Top comments (0)