Pull request size

How it is measured

Additions plus deletions across the diff. Simple, and the simplicity is why it travels: every code host reports it, no configuration is required, and nobody has to remember to label anything.

Two adjustments make it substantially more honest:

Exclude what nobody reads. Lockfiles, generated clients, snapshots, minified bundles, vendored dependencies and binary assets can multiply a diff by ten without adding a line a reviewer will look at. A package-lock.json update is not a 4,000-line change in any sense that matters.

Track file count alongside it. One file changed by 300 lines and 60 files changed by 5 lines each are the same number and completely different reviews. A rename sweep is enormous and trivial; a rewritten scheduler is small and hard.

Why it is worth watching

Pull request size is the closest thing code review has to a leading indicator. It is known at the moment a change is opened, before any of the outcomes it predicts have happened, which is what makes it actionable in a way that cycle time is not.

Here is what it looked like on the Coderbuds team's own repository across 431 pull requests merged in a recent 90-day window:

Median size across all of them was 241 lines.

The shape of that table is the finding, not the exact hours. Tiny and small are indistinguishable — a reviewer picks up either one in the same sitting. Medium roughly doubles. Then large is not a further doubling but a tenfold jump, because a change that size stops being something a reviewer fits into a gap and becomes something they have to schedule. That is one working day against three and a half.

The practical consequence: shaving lines off an already-small pull request buys almost nothing. Keeping one change out of the large bucket buys days.

What it misses

It says nothing about risk. A one-line change to a payment path deserves more scrutiny than a 400-line test refactor. Any team that reads size as a proxy for danger will systematically under-review its most dangerous changes.

It is trivially gamed. Once size appears on a dashboard, the incentive is to split. Splitting a coherent change into six pull requests that cannot be understood separately produces six small numbers and one much worse review, and the metric will report an improvement.

Mechanical changes distort it. A framework upgrade, a rename, or a formatter run touches thousands of lines that require no judgement at all. Without classifying that work separately, a single migration week will move a quarterly average and mean nothing.

Median hides the problem. Size distributions are heavily skewed. Most of the review pain sits in the top few per cent of changes, and a median is specifically designed not to show you those. Watch p75 and p90, or watch the count of changes above a threshold you have agreed.

How to read it well

Compare the team to itself. Cross-team benchmarks for pull request size are close to meaningless, because size depends on language, on the age of the codebase, and on how much generated code the stack produces.

Count changes over a threshold rather than tracking an average. "Four pull requests over 1,000 lines last month" is a sentence someone can act on. "Average PR size increased 6%" is not.

Check size against merge time on your own data before adopting anyone's target, including the one above. If your large changes merge as fast as your small ones, you have a review culture that already handles them and sizing is not your constraint.

And treat a rising median as a question, not a verdict. It can mean review discipline is slipping. It can equally mean the team stopped shipping behind feature flags, or absorbed a migration, or started building something genuinely bigger. The number tells you where to look, not what you will find.