PR Size tracks the number of lines added, modified, and deleted in each pull request. Research consistently shows that smaller pull requests receive more thorough reviews, merge faster, and introduce fewer defects. Monitoring this metric encourages teams to decompose work into reviewable increments and avoid risky large-batch changes.
Lines of code changed per pull request. Optimal: 200–400 lines.
AMPLIFIED: Atomic cross-project changes (e.g., updating a shared API and its consumers) produce massive PRs. Stacked PRs are the primary mitigation; without them, PRs touching multiple services become unreviewable, drastically reducing defect detection.
AMPLIFIED via vicious reinforcing loop: developers learn each PR submission costs a full day of latency → batch more changes → larger PRs → more review rounds → more TZ delays → more batching. This is the #2 problem after review latency.
Batching pressure increases at scale. Graphite data shows PRs with >3 files double merge time. Developers batch more when review cycles are slow.
+100 lines → +25 min review. ~50-line PRs merge 40% faster.
>1,000 lines → 70% lower defect detection.
Larger PRs take longer at every stage.
Larger changes conflict more with queued PRs.
Undetected defects reach production. Size warnings → 35% fewer defects.
Larger PRs take longer to write, review, and merge. 200-line PR = 1 day. 2000-line PR = multiple days.
Devs batch changes to minimize flaky gate exposure.
Slow pipelines incentivize batching into fewer, larger PRs.
Slow reviews → fewer, larger PRs to reduce round-trips.
Expensive runs incentivize batching.
Frequent deploys → no need to batch.
Devs batch cross-team changes to minimize coordination rounds. Updating a shared API + 15 consumers in one PR.
Atomic changes to shared libs + all consumers create enormous PRs.
Devs batch more changes per PR to minimize costly cross-TZ round-trips. Each submission costs a full day.
154% larger PRs from AI batching. AI enables generating more code faster, leading to bigger PRs.