PR Size Analysis

The 1000-Line Threshold

Once you cross 1000 lines, code review effectively stops. 82.6% get zero formal review.

82.6%
No Review
372,485
Massive PRs
0.05
Comments/100 Lines
0.21
Avg Approvals

Based on 3,387,250 merged PRs | GitHub Archive / BigQuery | December 2024

The Cliff: What Happens at 1000+ Lines

Code review quality doesn't decline gradually as PRs grow—it falls off a cliff. At 1000+ lines, review comments per 100 lines of code drops from 0.91 (for tiny PRs) to just 0.05. That's an 18x reduction in scrutiny.

The Review Cliff: No Review % vs Comments per 100 Lines

Red bars show PRs with zero review. Purple line shows review depth.

<1010-5050-200200-500500-1K1000+PR Size (Lines Changed)6570758085% No Review00.250.50.751Comments/100 Lines80% threshold

372,485 Massive PRs: The Scale of the Problem

Out of 3,387,250 total PRs analyzed, 11% crossed the 1000-line threshold. That's 372,485 massive PRs merged in a single month—most of which were never really reviewed.

"83% of pull requests over 1,000 lines ship with zero formal code review."

PR SizePRsNo Review %Comments/100 LinesAvg Approvals
Tiny (<10 lines)998,20570.6%0.910.37
Small (10-50)763,79872.6%0.640.32
Medium (50-200)670,84974.7%0.410.3
Large (200-500)377,38176.5%0.250.28
XL (500-1000)204,53278%0.160.27
Massive (1000+)The Threshold372,48582.6%0.050.21

"372,485 massive PRs merged last month. Most were never really reviewed."

Why Reviewers Give Up

The 1000-line threshold isn't arbitrary—it's where human cognitive limits take over. Research on code review effectiveness consistently shows that attention and defect detection rates decline sharply as PR size increases.

Cognitive Overload

Working memory can hold about 7 items. A 1000-line PR touching 20+ files exceeds anyone's ability to maintain a coherent mental model. Reviewers switch from "understanding" to "scanning."

Diminishing Returns

Studies show defect detection rates drop by 70% after reviewing 200-400 lines. Beyond 1000 lines, reviewers are essentially skimming—looking for obvious issues while missing subtle bugs.

Social Pressure to Approve

Large PRs represent significant author investment. Reviewers feel pressure to approve rather than request major changes. The implicit message: "I've already written all this code."

The "LGTM" Escape Hatch

When faced with an overwhelming PR, the path of least resistance is a quick "LGTM" and approval. Our data shows massive PRs average only 0.21 approvals vs 0.37 for tiny PRs.

The Ideal PR Size Debate

If 1000 lines is too big, what's the right size? The data suggests a sweet spot between 200-400 lines—small enough to review thoroughly, large enough to contain meaningful changes.

What the Data Shows

200-400

Sweet spot: High enough review quality with reasonable throughput

500-800

Acceptable with extra care: Consider splitting if possible

1000+

Danger zone: Review quality collapses, split required

<50

Ideal for focused changes but may fragment larger features

Note: These guidelines apply to human-authored code. Generated code, migrations, and vendor updates may have legitimate reasons for larger PRs—but they still need appropriate review processes.

Breaking Up PRs: Practical Strategies

"Just make smaller PRs" is easy advice to give and hard advice to follow. Here are concrete strategies that actually work:

Stacked Diffs

Break large features into a chain of dependent PRs. Each PR builds on the previous one. Tools like Graphite, gh-stack, and git-branchless make this workflow manageable. Review each layer independently.

Feature Flags

Ship incomplete features behind flags. Merge small increments to main while the feature is disabled. This enables continuous integration without exposing unfinished work to users.

Incremental Delivery

Decompose work into independently shippable slices. Each PR should be deployable on its own without breaking anything. Refactoring PR, then interface PR, then implementation PR.

Separate Mechanical Changes

Renames, formatting changes, dependency updates, and generated code should be separate PRs. These can often be reviewed quickly or auto-approved, keeping the substantive changes focused.

Our Take

The 1000-line threshold isn't arbitrary—it's where human attention fails.

If your PR crosses 1000 lines, you're not asking for a review; you're asking for a rubber stamp. Break it up or accept that it's shipping untested. The data is clear: massive PRs don't get meaningful review—they get merged.

Related Research

Methodology

This analysis is based on 3,387,250 merged pull requests from GitHub Archive / BigQuery during December 2024. PRs were bucketed by total lines changed (additions + deletions). "No review" means zero formal PR review comments. For full methodology, see the complete study.

See your team's PR size distribution

CodePulse shows you which PRs are crossing the 1000-line threshold—before they merge.