There is a widely shared belief in engineering teams that smaller PRs are better. Most experienced engineers have encountered some version of the advice: keep PRs small, make them focused, one concern per PR. The advice is usually given without much supporting data, which means teams have varying levels of conviction about it and varying actual PR size practices despite nominally endorsing it.
What does the data actually say? And where does the tradeoff sit between PR size and review quality?
The Relationship Between Size and Review Time
The most consistent finding in research on code review is that review time scales non-linearly with PR size. Small PRs are not just faster to review; they are disproportionately faster. A 500-line PR doesn't take roughly five times as long to review as a 100-line PR. It takes ten to fifteen times as long.
The reason is cognitive load. A small PR allows the reviewer to hold the entire change in working memory during the review. A large PR exceeds working memory capacity, forcing the reviewer to repeatedly re-read earlier sections to maintain context when evaluating later ones. The additional time is not proportional to the additional lines -- it is proportional to the number of context reloads required.
In our early-access data, the inflection point was around 200 lines of changed code. Below that threshold, median review time was under 2 hours. Above it, review time increased sharply, with the sharpest transition happening between 200 and 400 lines.
The Relationship Between Size and Finding Rate
Review time tells you how long reviewers spend. It doesn't directly tell you how well they review. Finding rate -- the number of actual issues identified per 100 lines of changed code -- is a better proxy for review quality.
The counterintuitive finding here is that finding rate does not stay constant as PR size increases. It decreases. A 500-line PR does not yield five times as many findings as a 100-line PR, even though it theoretically contains five times as much code to scrutinize. The finding rate drops, often substantially, as PR size grows.
The explanation is the same cognitive load dynamic. When reviewers are working through a large PR, they spend their attention on understanding what the code does rather than on evaluating whether it's correct. Comprehension and evaluation are both cognitive work, but they compete for the same resource. Large PRs tilt the balance toward comprehension and away from evaluation.
Where the Tradeoff Actually Lives
If small PRs are faster to review and catch more bugs per line reviewed, why don't all teams enforce small PR sizes? The answer is that small PRs impose costs on the author that are real even if they're less visible in the metrics.
Task decomposition time. Breaking a large refactoring into a series of small PRs requires planning -- figuring out which pieces can merge independently without leaving the codebase in an inconsistent state. This is not free time. Senior engineers can do it quickly; junior engineers may struggle to find valid decomposition points.
Stacked PR overhead. When a change naturally decomposes into a sequence of dependent PRs (PR B depends on PR A being merged), managing that dependency adds coordination overhead. The author must track the merge order; reviewers must understand the context of PR B without seeing PR A already merged.
Feature flag and incremental deployment requirements. Some features genuinely cannot be deployed incrementally without infrastructure support. Enforcing small PRs for large features without corresponding infrastructure (feature flags, dark launches) creates PRs that add code but don't ship behavior, which is awkward to review and maintain.
Practical Calibration
The optimal PR size for a given team and codebase is not a universal constant. It is a function of reviewer familiarity with the codebase, the complexity of the domain, and the available infrastructure for incremental deployment.
Teams with dense test coverage and experienced reviewers who know the codebase well can handle larger PRs with less degradation than teams with thinner coverage and reviewers who are newer to the code. The 200-line inflection point is an average across contexts; some teams can maintain review quality to 400 lines, others see degradation starting at 150.
The practical recommendation is to measure rather than guess. Track PR size, review time, and post-merge defect rate together. If large PRs in your team's specific context show the same patterns -- longer review times and higher defect escape rates -- the tradeoff is real and the size limit is worth enforcing. If your team's data shows healthy review quality across larger PRs, calibrate to that baseline.
What the data consistently does not support is the belief that a good reviewer can compensate for PR size through effort and attention. The cognitive load effect is not a discipline failure. It is a structural property of how human working memory functions. The most experienced reviewer in the company will have a lower finding rate on a 600-line PR than they would on the same code split into three 200-line PRs. That is the tradeoff. Process design should account for it.