Why Small Pull Requests Win (The Data)

TL;DR: The evidence for small pull requests is some of the strongest in software engineering: reviewers find 70-90% of defects at 200-400 lines, and detection collapses when they're pushed faster than 500 lines per hour. Small PRs get picked up sooner, read properly, and merged the same day. The skill isn't reviewing harder; it's cutting work so it ships in reviewable slices.

"Keep your PRs small" is the advice everyone nods at and nobody follows. Average PR size quietly climbs until a 1,400-line diff titled "auth refactor + fixes" lands in someone's queue on a Friday. So let's do this properly: the actual numbers, why the failure is sharper than most people think, and the practical craft of slicing work, because "just make it smaller" is not a technique.

What the research says about pull request size

The canonical numbers come from SmartBear's study of a Cisco Systems team (roughly 2,500 reviews across 3.2 million lines of code). Three findings matter:

1. Reviewers should handle no more than 200-400 lines of code at a time.
2. At that size, a careful 60-90 minute review yields 70-90% defect discovery.
3. Defect density drops significantly when reviewers move faster than 500 lines per hour.

Field data agrees. LinearB's benchmarks, 8.1 million+ PRs across 4,800 teams, put elite teams at under 100 changed lines per PR, with anything past 228 lines in the "needs focus" band. The best-performing teams in the largest available dataset are not writing less code. They're shipping it in smaller pieces.

Why defect detection collapses in big diffs

Here's the part the averages hide: a big PR doesn't get a proportionally longer review. It gets the same review, spread thinner.

Nobody blocks out three hours for a 1,500-line diff. The reviewer opens it, scrolls, spot-checks a few files that look important, and approves - an effective rate of thousands of lines per hour, far past the threshold where SmartBear's data shows defect detection falling off. The dangerous output isn't the missed bug. It's the approval: a big PR exits review with the same green checkmark as a small one, so the codebase now contains 1,500 barely-read lines that everyone downstream treats as reviewed.

Big PRs are a lie the process tells itself: you pay for review, skip its benefits, and keep the receipt.

And recall what review is actually for. 75% of what reviews catch is evolvability - clarity, structure, maintainability - which is precisely the feedback that requires actually reading the code. A skim catches the typo in the constant. It does not catch "this abstraction will hurt us for two years."

Small PRs are faster, not just safer

The speed effect compounds through the whole pipeline:

• Pickup. A small diff fits in the gap between meetings, so it gets picked up instead of postponed. In Google's study of ~9 million changes, small changes received initial feedback in under an hour; a big diff sits until a free afternoon materializes, which is how a PR ends up stuck in review for a week. Pickup time is where big PRs quietly bleed days.
• Rounds. Review feedback on a small PR is a 20-minute fix-and-repush. On a big PR, round one produces 30 comments, the rework takes two days, and round two starts from scratch because the reviewer's mental model expired.
• Merges and rebases. A PR open for a week drifts behind main; conflicts compound; the rebase becomes its own project. Small PRs merge before main can move underneath them.

Every one of those delays has a payroll number attached: the cost of slow code reviews is mostly the cost of large batches waiting in queues.

How do you actually keep pull requests small?

The constraint is real: features aren't 90 lines. The craft is decomposition, shipping a big change as a sequence of small, individually-safe steps:

1. Separate the mechanical from the meaningful. Renames, file moves, formatting, dependency bumps: each goes in its own PR that a reviewer can approve in two minutes because it's mechanical. Never let a rename hide inside a logic change; it turns 40 real lines into a 600-line diff.
2. Refactor first, then change. The classic two-step: PR one reshapes the code with zero behavior change (tests prove it); PR two makes the now-small behavioral change. Both are easy reviews. The fused version is neither.
3. Build behind a flag. You don't need the feature complete to merge - you need each slice safe. Land the data model, then the logic, then the UI, dark until the flag flips. This is how large systems ship large features in under-100-line increments.
4. Stack when slices depend on each other. A chain of three 150-line PRs, each reviewable alone, beats one 450-line PR. Reviewers see a narrative instead of a wall.
5. Cut scope at the ticket, not the PR. Most monster PRs were conceived as monsters: "implement settings page" becomes 2,000 lines because the task was 2,000 lines. If tasks routinely produce unreviewable diffs, the planning granularity is the bug.

When is a big PR fine?

An honest ceiling needs honest exceptions. Generated code, lockfiles, vendored dependencies, a tool-executed rename or formatter sweep - mechanically huge, cognitively tiny. Say so in the description ("everything is generated except schema.ts - review that"), and point the reviewer at the lines that matter.

The exception that isn't fine is the organic monster: scope that grew mid-flight, a refactor tangled into a feature, "while I was in there" commits. That PR needs triage and a split, and its author needs a planning conversation, not a bigger review budget.

The one-number takeaway

If your median PR is a few hundred lines and climbing, no review process will save you: the best practices all assume a diff a human can hold. Track your PR size distribution, not the anecdotes: one look at the p75 usually explains a team's entire review pain. Shrink the batch, and pickup, depth, and merge speed improve without anyone being asked to work harder.

Small PRs are not a style preference. They're the difference between review that happens and review that's performed.