90% of massive PRs ship without review in 2025—up from 83% in 2024. Large PRs get 20x less scrutiny.
No Review
for 1000+ line PRs
Based on 802,979 merged PRs | GitHub Archive / BigQuery | October 2025
In 2024, we found that 83% of massive PRs (1000+ lines) shipped without any formal code review. That was already alarming. In 2025, it's now 90%—a 7.7 percentage point increase.
2024
83%
no review (1000+ lines)
2025
90%
no review (1000+ lines)
The pattern is consistent across all size buckets: the bigger the PR, the less likely it is to receive any review. But the problem is most severe at the top.
| PR Size | PRs Analyzed | No Review % | Avg Comments |
|---|---|---|---|
| Tiny (<10 lines) | 214,830 | 85.8% | 0.03 |
| Small (10-50) | 163,088 | 84.2% | 0.15 |
| Medium (50-200) | 151,472 | 84.7% | 0.4 |
| Large (200-500) | 93,467 | 84.6% | 0.68 |
| XL (500-1000) | 55,948 | 85.1% | 0.94 |
| Massive (1000+) | 109,361 | 87% | 1.17 |
"90% of 1000+ line PRs ship without any code review—up from 83% last year. The rubber stamp problem is getting worse."
Even when large PRs do get reviewed, they receive far less attention per line of code. Tiny PRs receive 0.98 review comments per 100 lines. Massive PRs? Just 0.05. That's a 20x drop in scrutiny.
comments per 100 lines
comments per 100 lines
The phenomenon isn't surprising when you consider human psychology. Reviewing code requires sustained attention and mental effort. Large PRs trigger avoidance behaviors that lead to rubber-stamping.
Studies show attention declines sharply after 200-400 lines. Beyond that, reviewers shift from "finding issues" to "getting through it."
A 1000-line PR might take hours to review properly. Busy engineers often approve quickly to unblock the author and move on with their own work.
Large PRs often touch many files. Reviewers lose the mental model of how pieces connect, making it harder to spot subtle bugs or design issues.
"If they submitted this much code, they probably tested it thoroughly." Ironically, larger changes are more likely to contain bugs.
"Large PRs receive 20x fewer review comments per line of code. The biggest changes get the least attention."
Despite getting less scrutiny, large PRs still take longer to merge. The worst of both worlds: less review quality and slower cycle times.
| PR Size | PRs | Median Merge Time | Avg Merge Time |
|---|---|---|---|
| Tiny (<10 lines) | 62,735 | 13h | 63.2h |
| Small (10-50) | 46,768 | 16h | 60.8h |
| Medium (50-200) | 38,237 | 19h | 67.0h |
| Large (200-500) | 22,795 | 20h | 72.0h |
| XL (500-1000) | 13,126 | 22h | 78.2h |
| Massive (1000+) | 24,031 | 22h | 81.4h |
Small PRs aren't just a nice-to-have—they're the only way to get real code review.
The data is unambiguous: 90% of massive PRs ship without any review, and even when they do get reviewed, they receive 20x less scrutiny per line. The rubber stamp problem isn't a process failure—it's human nature. You can't train people to review 1000+ line PRs effectively.
The solution is structural: Set hard limits on PR size. Break large changes into stacked diffs. Treat 400+ line PRs as red flags that need special handling, not business as usual.
Enforce soft limits (warnings at 400 lines) and hard limits (block at 800 lines). Use GitHub Actions or merge queue rules to automatically flag oversized PRs.
Break large changes into a chain of small, reviewable PRs. Tools like Graphite, gh-stack, and spr make this workflow manageable.
When large PRs are unavoidable, require multiple reviewers. Use CODEOWNERS files to automatically request appropriate domain experts.
Renames, formatting, and dependency updates should be separate PRs that can be reviewed quickly. Don't mix them with feature work.
This analysis is based on 802,979 merged pull requests from GitHub Archive / BigQuery during October 2025. "No review" means no formal code review event was recorded. PRs were bucketed by total lines changed (additions + deletions). Review comments per 100 lines is calculated as (total review comments / total lines) * 100. For full methodology, see the complete study.
CodePulse shows you which PRs are getting rubber-stamped in your repos.