What research says about “ideal” PR size

There is a substantial body of research on pull-request and code-review size. Across both empirical studies and industry engineering guidance, the evidence consistently favors smaller, focused changes, although there is no universal line-count threshold that applies to every codebase or type of change.

One of the most frequently cited empirical studies is the 2006 Cisco/SmartBear research published in Best Kept Secrets of Peer Code Review. The study found that review effectiveness was strongest for relatively small changes and recommended keeping reviews under 200 lines of code (LOC) where possible and not exceeding 400 LOC. Its practical recommendation was approximately 100–300 LOC reviewed over 30–60 minutes. The study also found that reviewer effectiveness declines as review sessions become longer, particularly beyond roughly 60–90 minutes (SmartBear/Cisco study; Tekin summary).

Google’s publicly documented engineering practices reach a similar conclusion while emphasizing that line count alone should not determine whether a change is appropriately sized. Google states that “100 lines is usually a reasonable size for a CL [changelist], and 1000 lines is usually too large,” while explicitly noting that there are no hard-and-fast rules. The number of files involved and, more importantly, whether the change represents one self-contained conceptual unit also matter. Google’s general advice is to err on the side of writing changes that are smaller rather than larger (Small CLs — Google Engineering Practices).

More recent aggregated industry data supports the same general relationship. Smaller PRs tend to be reviewed more quickly, while larger changes and changes distributed across many files require more reviewer effort and can increase merge time. Cubic’s aggregation of PR research, for example, reports that smaller changes tend to move through review faster and cites evidence that a roughly 50-line change has a lower probability of being reverted than a substantially larger change. These figures should be treated as aggregated industry evidence rather than as a single controlled experiment (Cubic — Does PR size actually matter?).

Taken together, these sources support a practical guideline rather than a rigid rule: aim for small, self-contained PRs, often in the range of roughly 100 – 400 changed lines, and carefully reconsider changes that grow beyond approximately 500 – 1000 lines.

Before vs. After AI Coding Tools

The issue has become more important with the rapid adoption of AI-assisted software development. Recent datasets suggest that higher AI usage is associated with larger pull requests and greater code output, even though these observational studies do not by themselves establish that AI is the sole cause of the increase.

SourceComparisonFinding
DX (getdx.com), 400+ organizationsMedian PR size, July 2025 → June 202644 → 72 lines (+64%). During the same period of rapidly increasing AI use, DX’s Q2 2026 self-reported measure estimated that developers delegated substantially more coding work to AI tools.
Jellyfish + OpenAI, 500+ companiesModeled 0% → 100% AI adoptionAdditions per PR increased from 74.8 → 88.4 (+18.2%).
Jellyfish + OpenAI, 500+ companiesBottom AI-adoption quartile → top AI-adoption quartileAdditions increased from 64.8 → 72.1 (+11.2%), while net additions increased from 44.1 → 50.5 (+14.5%).

DX analyzed data from more than 400 organizations and found that median PR size increased from 44 lines in July 2025 to 72 lines in June 2026, a roughly 64% increase. DX also reported a major increase in AI-assisted development over this period. Importantly, its AI metric was based on self-reported data and is interpreted as an estimate of the share of coding workload delegated to AI tools, rather than a literal measurement of what percentage of all committed code was written by AI (DX — AI-authored code has nearly doubled).

A separate analysis by Jellyfish, conducted with OpenAI and using data from more than 500 companies, found a similar association between AI adoption and PR size. Across the modeled range from 0% to 100% AI adoption, additions per PR increased from 74.8 to 88.4 lines, or 18.2%. Comparing companies in the bottom and top AI-adoption quartiles, additions increased from 64.8 to 72.1 lines (+11.2%), while net additions increased from 44.1 to 50.5 (+14.5%) (Jellyfish — AI-Assisted Pull Requests Are 18% Larger).

One plausible explanation is that AI lowers the effort required to generate new code. The Jellyfish results are consistent with this hypothesis: the increase among higher-AI-adoption companies was concentrated primarily in net-new additions, while the increase in deletions was substantially smaller. However, the authors also acknowledge that multiple factors could contribute to the observed changes, so these results should be interpreted as associations rather than proof that AI directly causes larger PRs.

Code Quality and Review Effectiveness

The increase in code volume matters because several recent datasets also identify potential quality and maintainability concerns associated with AI-assisted development. These findings should again be interpreted carefully because the studies use different definitions, samples, and methodologies.

CodeRabbit’s late-2025 analysis examined 470 real pull requests: 320 AI co-authored and 150 human-authored. Its automated review system produced an average of 10.83 findings per AI-assisted PR compared with 6.45 per human-authored PR, or approximately 1.7 times as many flagged findings. Critical findings were reported to be approximately 40% higher and major findings approximately 70% higher in the AI-assisted group (Help Net Security summary of CodeRabbit research).

These results should not be interpreted as demonstrating that AI code contains exactly 1.7 times as many actual software defects. They show that CodeRabbit’s automated review methodology flagged approximately 1.7 times as many issues per PR in its AI-assisted sample, which is evidence of a quality difference but not equivalent to independently verified production defects.

GitClear’s 2025 research examined approximately 211 million changed lines of code from 2020–2024 and identified significant changes in development patterns during the period in which AI coding assistants became widely adopted. The proportion of changed lines categorized as copy/pasted increased from approximately 8.3% in 2021 to 12.3% in 2024, while refactoring-associated activity declined from approximately 25% to less than 10% over the same period (GitClear — AI Copilot Code Quality 2025 Research).

These trends are consistent with concerns that increased code generation may be accompanied by more duplication and less consolidation or reuse. However, because the GitClear data is observational and covers an industry-wide time period, it should not be interpreted as a controlled experiment proving that AI alone caused these changes.

More recent academic research provides another perspective. The paper More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-generated Pull Requests analyzes human and agent-generated pull requests. The researchers found significantly greater semantic redundancy in agent-generated PRs, with their average maximum-redundancy measure nearly twice that of human-authored PRs (arXiv 2601.21276).

Interestingly, the same research found that reviewer responses to agent-generated contributions tended to express more neutral or positive sentiment than responses to human-generated contributions. This raises the possibility that greater redundancy does not necessarily trigger correspondingly stronger negative reviewer reactions. However, the study does not establish that technical debt generally “slips through review”; that would require a stronger causal conclusion than its results support.

Bottom Line

The evidence supports two related but distinct conclusions.

First, the guidance on PR size has remained remarkably consistent. Research predating modern AI coding tools found that smaller changes are easier to review effectively, and major engineering organizations such as Google continue to recommend small, self-contained changes. The Cisco/SmartBear study recommended approximately 100–300 LOC per review and cautioned against exceeding 400 LOC, while Google considers approximately 100 lines reasonable and 1000 lines usually too large.

This does not mean that every PR over 400 lines is inherently bad. A 600-line change containing straightforward tests or generated code can be easier to review than a 150-line change containing complex business logic spread across many files. Conceptual scope and reviewer cognitive load matter more than a single numerical threshold.

Second, emerging evidence suggests that increased AI adoption is associated with larger PRs and higher volumes of newly generated code. DX observed median PR size growing from 44 to 72 lines across its cohort between July 2025 and June 2026, while Jellyfish found PR additions increasing by approximately 11–18% depending on the AI-adoption comparison used. Other industry and academic research has identified increased automated-review findings, greater code duplication, reduced refactoring activity, and higher semantic redundancy during the period of increasing AI adoption.

These findings do not yet prove that AI causes lower code quality or larger PRs in every engineering organization. The datasets are largely observational, use different definitions of AI-assisted code, and measure different aspects of software quality. Nevertheless, they point in a consistent direction: AI makes generating code easier and faster, while human review capacity remains constrained.

That makes established code-review practices arguably more important, not less important, in an AI-assisted development environment. Teams should continue to favor small, logically self-contained PRs, treat roughly 100 – 400 changed lines as a useful guideline rather than a hard rule, and scrutinize changes above approximately 500 – 1000 lines to determine whether they can be decomposed into independently reviewable units.

The key risk introduced by AI is therefore not simply “more code.” It is a potential mismatch between the rate at which code can now be produced and the rate at which humans can meaningfully understand and review it.

Sources

Leave a Reply