The Pull Request Size Law

There's a rule of thumb I've seen play out at every company I've worked at:

The time-to-merge of a PR doubles for every 100 lines of diff.

A 50-line PR merges in 2 hours. A 150-line PR merges in 4 hours. A 500-line PR merges in 16+ hours. A 2000-line PR merges in days, if at all.

It's not exactly geometric. But the curve is steep. And it has nothing to do with the code itself — it's about how reviewers behave.

Why size compounds

A 50-line diff fits in a reviewer's working memory. They read it once, comment, done.

A 500-line diff doesn't. The reviewer:

Skims first to get a shape
Comes back later for a real review
Loses context between sessions
Asks the author for a walkthrough
Approves things they didn't actually understand because saying "I don't get it" three times feels rude
Misses bugs because attention is finite

Every step adds latency and reduces quality.

The data

GitHub published research on this years ago. PRs under 200 lines:

Median merge time: ~3 hours
Defects-per-line found in review: 1x baseline

PRs over 1000 lines:

Median merge time: ~3 days
Defects-per-line found in review: 0.2x — reviewers find 5x fewer bugs per line

So your big PRs ship more bugs and ship slower.

What "small" means in practice

The natural target: under 200 lines of code change. (Not counting auto-generated files, lockfiles, or whitespace.)

Most engineers think their PRs are smaller than they are. Run the numbers — git diff --stat main..HEAD | tail -1 — and you'll often see 800+ lines you didn't realize you'd changed.

Things that bloat a "small" PR:

Unrelated cleanup ("while I'm here")
Adding tests in the same PR as the feature (split them)
Generated code (commit but acknowledge separately)
Refactoring tangentially related to the actual change

The standard objections

"My change can't be split."

Almost always wrong. The split is rarely "this feature in two halves." It's "the refactor that enables the feature, then the feature."

Pattern:

PR 1: Refactor existing code into the shape needed (no behavior change)
PR 2: Add new feature using the new shape
PR 3: Delete old code paths now that nothing uses them

Each PR is small, reviewable, and shippable independently.

"Splitting takes more time."

Yes, ~30 min. But it cuts merge time by 2-4 days. Net: faster.

"The reviewer wants to see the whole thing."

Then the reviewer is wrong, or the team's culture is wrong. A reviewer who wants 1000-line PRs is a reviewer who isn't actually reading them.

"It's all coupled."

Sometimes true. But ship the coupled change behind a feature flag. PR 1: scaffolding + flag, defaulted off. PR 2-N: implementation, still off. PR N+1: flip the flag.

Stacked PRs

For larger features that genuinely need a sequence: stack PRs.

main → pr-1: refactor → pr-2: new endpoint → pr-3: client update

Each PR is small. Reviewers can review each independently. Merge them in order.

GitHub's UX for this is mediocre. Tools like Graphite, Sapling, or git absorb make stacks reasonable.

The "quick fix" exception

A 5-line bugfix doesn't need to be split. Don't apply the rule mechanically.

The rule applies to feature work, refactors, and anything where reviewers need to actually understand the change.

What managers should do

If you manage engineers, make this metric visible:

Median PR size last 30 days
% of PRs over 400 lines

Pin it on a team dashboard. Don't punish people. Just make it visible. The number drops.

If a senior engineer pushes back ("my PRs need to be big"), that's a signal: they aren't structuring their work well. Or your codebase has poor seams. Either way, surface it.

What individual engineers should do

When you're about to push, run:

git diff --stat main..HEAD | tail -5

If it says "20+ files, 800+ lines": stop. Plan the split.

Spending 20 minutes refactoring your branch into three smaller PRs is the highest-ROI thing you'll do that day. It saves you from a 3-day review cycle.

The takeaway

Big PRs are a velocity killer disguised as productivity. Every time you bundle "while I'm here" changes into a feature PR, you've cost yourself a day. Small PRs feel slower (more overhead per change) but actually ship 5x faster. Internalize the size law and your team will outpace teams of equal skill.