PR review-time estimator
How long should this code review take, and how likely is it to catch the bugs? PR size predicts both — this calculator quantifies it.
Grounded in research
The thresholds come from three studies that all reach the same conclusion: review quality drops sharply past ~400 LOC, and becomes essentially impossible past ~800.
- Cohen 2006 (SmartBear) — review quality drops above ~200 LOC, sharply above 400 LOC.
- Bosu et al. 2017 (Microsoft)— PRs > 500 LOC have 2.3× higher post-merge defect-leak rate.
- GitHub 2023 data— median PR is 30 LOC; outliers > 1000 LOC get less time per line due to fatigue.
Your PR
Medium review — quality still good.
Within the size range where focused review works well. Make sure the PR has a clear description (what + why), groups related changes into atomic commits, and links to the story. Below 400 LOC is where Cohen 2006 research shows quality review remains effective.
How the estimate works
Base estimate is 0.6 minutes per line of churn (added + deleted), floored at 5 minutes — every PR takes at least that long to context-load.
Adjustments:
- Files changed: 1 minute per file (context-switching overhead).
- Cross-module: +20% (reviewer mentally switches between two domains).
- Tests included: –15% (the test acts as a spec; less re-reading needed to understand intent).
Total churn drives the tier: ≤ 100 lines is the sweet spot (Cohen 2006), ≤ 400 is still effective, ≤ 800 is risky, > 800 should be split before review.
Want this enforced in your workflow?
Stride's Verify module surfaces PR size warnings before merge, blocks PRs > 800 LOC by policy, and tracks per-team review cycle time as a DORA metric.
See quality gates