How Big Should a Pull Request Be? What the Data Says

Direct answer

Across 2,896 human-authored merged pull requests in 10 major public repositories, measured 2026-10-18, the median was 63 changed lines across 3 files. 74.3% were under 200 lines, 85.6% under 400. But size is a symptom. Coherence beats arithmetic: a 600-line change expressing one idea reviews better than five 120-line fragments nobody can evaluate alone. Set thresholds from your own distribution, not from a 2006 study.

How big should a pull request be?

Direct answer: Small enough that a reviewer can state what the change does after one pass. In practice that is 50 to 200 changed lines for most feature work. Our 2026 measurement of 2,896 merged pull requests found a median of 63 lines across 3 files, with 74.3% under 200 lines. Measured 2026-10-18.

The honest version of this answer is that the famous numbers everybody quotes are weaker than their reputation, and the real distribution is smaller than those numbers suggest.

Here is what we actually found.

Percentile	Lines changed (additions + deletions)	Files changed
p10	5	1
p25	18	2
p50 (median)	63	3
p75	205	6
p90	628	16
p95	1,352	32
p99	4,584	124
Mean	373	-
Max	67,213	-

n = 2,896 human-authored merged pull requests, 10 public repositories, created 17 Apr 2026 to 17 Oct 2026, collected via the GitHub GraphQL API on 2026-10-18. Method and limitations in How we verified this.

Three things in that table are worth sitting with.

The median is 63 lines, not 200. Real merged work in large, well-run repositories is much smaller than the guidance everybody repeats. If your team’s median is 300 lines, you are not near the recommended ceiling, you are at roughly the 80th percentile of major open source.

The mean is 373 and the median is 63. That ratio, nearly 6 to 1, is the whole problem with “average PR size” as a metric. A handful of codemods drags the mean somewhere no actual pull request lives. Never report a mean here. Report p50 and p90.

One in four pull requests touches a single file. 24.7% changed exactly one file. The modal unit of merged work is far closer to a patch than to a feature.

How large should a pull request be?

Direct answer: Large enough to be one complete thought, small enough that review attention does not thin out. We measured the thinning directly: inline review threads per 100 changed lines fell from 1.55 under 50 lines to 0.085 above 1,000 lines, an 18-fold drop in scrutiny density across 2,896 merged pull requests (2026-10-18).

Everyone asserts that reviewers skim big diffs. Almost nobody measures it. We did, by counting inline review threads against changed lines on every pull request in the sample.

PR size (changed lines)	n	Mean inline review threads	Threads per 100 changed lines	Merged with zero inline threads
Under 50	1,297	0.28	1.55	84.7%
50 to 199	856	0.84	0.79	66.1%
200 to 399	326	1.61	0.57	48.8%
400 to 999	219	2.11	0.33	42.9%
1,000 and over	198	3.15	0.085	52.0%

Collected 2026-10-18, human-authored merged pull requests only.

Read this table honestly, because it cuts both ways. Absolute scrutiny rises with size: a 1,000-line pull request gets a mean 3.15 inline threads against 0.28 for a sub-50-line one, and the rank correlation between size and comment count is positive (Spearman rho = +0.355, n = 2,894). Large changes are not ignored.

What collapses is scrutiny per line. A reviewer who leaves three comments on 4,000 lines has examined those 4,000 lines at roughly one-eighteenth the density they apply to a 40-line patch. That is the mechanism behind the rubber-stamp intuition, and it is now a number rather than a vibe.

The sharpest single figure: 52% of merged pull requests over 1,000 lines carried zero inline review comments. Over half of the largest changes in these repositories merged without a single line-level remark.

One caveat we will not bury. 69.8% of all human-authored merged pull requests in the sample had zero inline review threads, and 18.1% had no formal review event at all. Plenty of those are trivially correct one-liners, plenty are approved through bot workflows (Kubernetes uses Prow /lgtm comments, which do not register as review submissions), and plenty are maintainers merging their own work. Zero comments does not mean zero reading. The relative decline across buckets is the finding, not the absolute level.

Why the famous numbers deserve less deference than they get

Two figures dominate every page on this topic. Both are weaker than their reputation.

SmartBear’s Cisco study. SmartBear’s own page states that “developers should review no more than 200 to 400 lines of code (LOC) at a time” and that “a review of 200-400 LOC over 60 to 90 minutes should yield 70-90% defect discovery” (smartbear.com, verified 2026-10-18). The underlying Cisco program is from 2006. It predates GitHub pull requests as the default unit of work, predates CI running a full test suite on every push, predates static analysis as table stakes, and predates AI-assisted authoring by two decades. It is cited vastly more often than it is read, and almost always without the inspection-rate context that gives it meaning. It is not wrong. It is just not a 2026 measurement, and nobody who quotes it says so.

Google’s “under 200 lines”. This one is simply misattributed. Google’s public engineering practices guide says: “100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large” (google.github.io/eng-practices, verified 2026-10-18). There is no 200-line rule in that document. The guide’s actual definition of right-sized is conceptual, not numeric: a CL that “makes a minimal change that addresses just one thing.” Google also explicitly carves out exceptions, including deletion of an entire file (“just one line of change”) and output from “an automatic refactoring tool that you trust completely.”

So the canonical source everyone cites for a hard number is, in its own words, arguing for coherence over arithmetic. That is the whole thesis of this page, and it has been sitting in Google’s documentation the entire time.

How much code should a pull request change?

Direct answer: As much as one coherent idea requires, and not one line more. A 600-line change with a single clear purpose reviews better than five 120-line fragments that cannot be evaluated independently. Optimise for whether a reviewer can state what the change does and why after one pass, not for the diff stat. Measured 2026-10-18.

Here is the failure mode that line-count rules create. A team adopts a 250-line cap. An engineer has a 700-line change. Rather than find the conceptual seam, they split by file: three pull requests of roughly 230 lines each, none of which does anything on its own. The reviewer now has to hold all three in their head simultaneously to evaluate any one of them, and the metric reports a win.

Mechanical splitting is worse than the large pull request it replaced. It converts one hard review into three impossible ones and hides the cost in a dashboard.

The test that actually works is a sentence test. Can you describe the change in one sentence, without the word “and”, without listing files? If yes, it is coherent at any size. If you need three sentences, it is three pull requests, even if the whole thing is 90 lines.

By that test, these are all legitimately one pull request regardless of line count:

• A rename applied across 400 call sites by an IDE refactor.
• A dependency upgrade with the resulting lockfile churn.
• A protobuf or OpenAPI schema change plus its regenerated clients.
• A framework migration where the intermediate states do not compile.
• Adding a single new endpoint with its handler, validation, and tests.

And these are multiple pull requests even when small:

• A bug fix plus “while I was in there” cleanup.
• A formatter run plus a logic change.
• Two unrelated fixes bundled because they are in the same file.

The second list is where most real review pain comes from, and it is invisible to a line-count gate.

When a large pull request is legitimate

Some large changes are not decomposition failures. The problem is that they are indistinguishable from decomposition failures in any metric you compute from the diff, so they poison the data.

We measured how much of a large pull request is actually machine-written. For a sample of 80 merged human-authored pull requests over 1,000 changed lines, we pulled the full file list and classified paths as generated, vendored, lockfile, snapshot, translation, or testdata.

Measure	Result
Median generated share of changed lines	0%
p75 generated share	0.4%
p90 generated share	51.8%
Contain any generated lines	27.5%
Majority (over 50%) generated	11.3%
Over 80% generated	6.3%
Aggregate across the sample	42.1% (156,372 of 371,392 changed lines)

n = 80 merged pull requests over 1,000 changed lines, sampled evenly across the 10 repositories, file lists pulled 2026-10-18.

The median large pull request is entirely hand-written. And 42.1% of all large-PR lines are generated. Both are true, and the gap between them is the point: a small number of enormous codegen pull requests (one Kubernetes change in the sample was 67,018 generated lines across 2 files) dominate any line-count total you compute. If you report mean PR size, or total lines reviewed, you are substantially reporting lockfile churn.

Categories that legitimately produce large diffs:

Codemods and automated refactors. One idea, mechanically applied. Reviewer verifies the transformation rule and spot-checks, as Google’s guide explicitly permits.

Lockfiles and vendored dependencies. Zero human judgement in the changed lines. The judgement is in the manifest change above them.

Generated artifacts. Protobuf stubs, OpenAPI clients, GraphQL types, database schema snapshots. Review the source of truth, not the output.

Migrations that lose meaning when split. Moving from one ORM to another, or a build-system swap, where every intermediate state is broken. Splitting produces a sequence of commits that do not build, which is worse.

Test fixtures and snapshots. A snapshot update after an intentional UI change is a diff you confirm, not a diff you read.

How to flag them so they do not skew your metrics:

1. Mark paths in .gitattributes with linguist-generated=true. GitHub collapses them in the diff by default and most review tools honour it.
2. Use one label with teeth. A single size-exempt or codemod label that your metrics pipeline filters on. One label, consistently applied, beats five that nobody uses.
3. Put the reviewer’s job in the description. “Files 1 to 3 are the transformation. The other 180 are its output. Review the transformation.” That sentence is worth more than any tooling.
4. Exclude exempt pull requests from the numerator and the denominator, so a codemod-heavy sprint does not look like a decomposition regression.

Best way to set pull request size limits

Direct answer: Never hard-block on line count. Set a soft warning at your own 75th percentile, add a documented exemption label for codemods and generated output, and track one team metric: the percentage of pull requests under threshold. Above 80% is healthy. Below 60% means coaching on decomposition, not a stricter rule. Verified 2026-10-18.

A hard gate converts a size problem into a gaming problem within about two sprints. The team learns to split by file boundary, the dashboard goes green, and review quality goes down. Treat the limit as a conversation starter, not a merge condition.

Step 1: measure your own distribution before you pick a number. The variance between well-run repositories is enormous, and it is driven by the nature of the codebase, not by discipline.

Repository	n	p50	p75	p90	p99	Under 200 lines	Under 400 lines	Over 1,000 lines
pandas-dev/pandas	291	33	63	120	280	96.9%	99.7%	0.3%
django/django	300	25	69	172	1,396	91.3%	95.0%	2.3%
nodejs/node	251	36	105	277	1,754	84.1%	94.4%	2.0%
home-assistant/core	284	46	181	511	4,675	75.7%	86.6%	4.9%
grafana/grafana	281	95	277	813	2,662	69.8%	81.9%	8.9%
rust-lang/rust	298	60	296	1,311	3,867	69.1%	79.9%	12.4%
vercel/next.js	295	103	267	789	2,920	68.5%	81.0%	9.2%
facebook/react	300	112	267	755	4,847	67.7%	85.0%	8.3%
kubernetes/kubernetes	300	137	279	766	9,985	64.7%	81.7%	7.0%
microsoft/vscode	296	143	455	1,131	9,789	57.4%	72.3%	12.2%

Human-authored merged pull requests, collected 2026-10-18.

pandas ships 96.9% of its work under 200 lines. VS Code ships 57.4%. Both are healthy projects with serious review cultures. Anyone who tells you 200 lines is the universal answer has not looked at two codebases. A data library with a mature API and a desktop application with a large UI surface have structurally different units of change.

Step 2: set the warning at your own p75, rounded. If your p75 is 205 lines (the sample-wide figure), a 250-line soft cap puts a label on roughly the top quartile, which is a volume of nudges a team can absorb. Setting it at your p50 generates noise on half of all pull requests and gets ignored within a month.

Step 3: track percentage under threshold, not average size. The mean is useless here (373 vs a median of 63 in our data). The metric that behaves well is a share:

Percentage of PRs under threshold	Read
Above 80%	Healthy. Leave the team alone.
60% to 80%	Watch it. Look at which teams or services drive the tail.
Below 60%	Coach decomposition. This is a skill gap, not a rule gap.

Below 60% is almost never a discipline problem. It is usually one of three things: engineers who have not been taught where the seams are, a codebase whose module boundaries force wide changes, or a review queue so slow that batching is rational. The third is the most common and the least often diagnosed, which brings us to latency.

What PR size does to review latency

Large pull requests wait longer to be picked up. They do not necessarily take longer to merge, which surprised us.

PR size (changed lines)	n	Median hours to first review	Median hours to merge
Under 50	460	3.9	36.8
50 to 199	363	5.8	48.2
200 to 399	118	7.6	56.4
400 to 999	65	16.8	41.1
1,000 and over	52	13.7	57.6

De-biased subsample, n = 1,058 (see method notes). Collected 2026-10-18.

Time to first review rises 4.3x from the smallest bucket to the 400-to-999 bucket. That is the queuing effect, and it is real: reviewers postpone the intimidating ones. Sample-wide, median time to first review was 5.3 hours and median open-to-merge was 48.1 hours.

But open-to-merge time does not increase monotonically with size. 400-to-999-line pull requests merged at a median 41.1 hours, faster than 200-to-399-line ones at 56.4. We will not over-explain a result from 65 pull requests, but the pattern is consistent with large changes being release-critical, pre-negotiated, or merged by their own author. The common claim that big pull requests always take longer end to end is not supported by our data. They take longer to get attention. What happens after that varies.

If your percentage-under-threshold is low, check first-review latency before you blame decomposition skills. When review takes two days, batching work into one larger pull request is a rational response to a slow queue, and no amount of coaching will out-argue the incentive.

How to split a pull request that feels indivisible

Most oversized pull requests are oversized because the author did not see the seam, not because the work was atomic. Four techniques cover nearly everything.

Stacked diffs. The definitive answer to “I would block myself.” You open a chain of small dependent pull requests and keep building on top while the lower ones are in review, rather than waiting for each merge. This removes the single most common justification for a large pull request. Our full guide: what are stacked diffs. Graphite is the best-known tooling for it, and it now shares an owner with Cursor following the 19 Dec 2025 acquisition.

Feature flags, to decouple deploy from release. If the code path is not live, incomplete work is safe to land. You can ship a feature across eight small pull requests over two weeks, each independently reviewable, with the flag flipped only at the end. This is the highest-leverage technique on the list because it converts a sequencing constraint into a configuration value.

Sequence by contract: schema, then API, then client, then tests. Each layer has an interface a reviewer can evaluate on its own terms. The migration can be reviewed by someone who knows the database; the client change by someone who knows the UI. Splitting by layer also routes each piece to the right reviewer, which cuts first-review latency.

Separate mechanical from semantic, always. A formatter run, an import reorder, or a rename belongs in its own pull request, every time. Mixing them means the two lines that matter are buried in 400 that do not, and our density data says those two lines will not get a comment.

For the full mechanics and target numbers, see pull request size best practices, which this article supersedes as the primary reference.

How AI review tools behave as pull requests grow

Automated review changes the economics of a large pull request, but not evenly, and every tool has a different failure mode at scale. Documented limits as of 2026-10-18:

Tool	Documented size cap	How cost behaves as the diff grows	Note
GitHub Copilot	No cap. The 300-file / 20,000-line limit was removed 27 Aug 2026	AI Credits at $0.01; private repos also consume Actions minutes since 1 Jun 2026	Cap removal invalidates any Copilot benchmark run before Sept 2026
CodeRabbit	150 files on Free and Essentials, 300 on Team and above	$0.25 per reviewed file overage; on-demand usage reviews hard-stop above 300 files	The file cap, not the line cap, is the binding constraint
Greptile	No published file cap	Credits are per author and do not pool; Apex depth costs 10 credits per review	Indexes the full repository rather than reading the diff alone
Claude Code review	No published cap	Anthropic publishes $15 to $25 per review in token cost	Anthropic claims 84% detection on PRs over 1,000 lines at under 1% false positives. Vendor-published, unreplicated
Macroscope	No published cap	$0.05 per KB reviewed, $0.50 floor; cost scales linearly with diff size	Re-reviews are billed each time
cubic	No file cap; reviewed-line allowances of 40K / 80K / 160K per dev by tier	Allowance-based, so one codemod can consume a developer’s monthly budget	SOC 2 Type I only, verified 2026-10-18
Gitar	No published cap	Core $20/user/mo annual, Pro $40, both capped at 50 users	No published third-party benchmark of review quality. Gitar sponsors this site; the caveat applies regardless

Two things to take from that table.

File caps bite before line caps do. Our p99 pull request touched 124 files, and 8.4% of all pull requests touched 20 or more. CodeRabbit’s 150-file limit on Essentials will catch real codemods in most repositories, and that constraint appears in almost no comparison page.

More context is not automatically better review. SWE-PRBench (arXiv 2603.26130, independent, 350 human-annotated PRs) reports that model performance degrades as context grows, which the authors attribute to attention dilution. That is a direct tension with the “just index everything” pitch, though retrieval over an index is not the same operation as stuffing a 5,000-line diff into a prompt. For how the tools differ at scale, see AI code review for a large codebase, and for testing it on your own repository, how to evaluate an AI code reviewer.

And the limit worth stating plainly: no AI reviewer makes a 5,000-line pull request a good idea. It makes a 5,000-line pull request surveyed. A machine pass does not restore the human attention our density table shows evaporating at scale. It is a floor, not a substitute. More on that division of labour in pull request review best practices.

How we verified this

What we collected. On 2026-10-18 we queried the GitHub GraphQL API (gh api graphql, authenticated) for the 300 most recently created merged pull requests in each of 10 public repositories: facebook/react, microsoft/vscode, kubernetes/kubernetes, rust-lang/rust, nodejs/node, django/django, pandas-dev/pandas, vercel/next.js, grafana/grafana, home-assistant/core. That is 3,000 merged pull requests. We removed 104 bot-authored pull requests (GraphQL __typename == "Bot" plus a login pattern match), leaving n = 2,896 human-authored merged pull requests, created between 17 Apr 2026 and 17 Oct 2026.

Fields used. additions, deletions, changedFiles, createdAt, mergedAt, first reviews node submittedAt, reviewThreads.totalCount. “Lines changed” throughout is additions plus deletions. Percentiles are linear-interpolated.

The generated-code sample. We took 80 merged human-authored pull requests over 1,000 changed lines, sampled at a fixed interval across the full set, and pulled complete file lists via the REST pulls/{n}/files endpoint. Paths were classified as generated using a pattern list covering lockfiles, vendor/, zz_generated, _pb2, .snap, __snapshots__/, dist/, .min.js, third_party/, testdata/, locale and translation directories.

What we could not verify, and known limitations.

• Latency is biased in the raw sample. Ordering by creation date descending among merged pull requests over-samples pull requests that merged quickly. The naive median time to first review was 1.1 hours, which is not credible as a general figure. All latency numbers in this article come from a de-biased subsample (n = 1,058) that drops pull requests created in the trailing 14 days of each repository’s window. Treat them as directional.
• This is open source, not your company. OSS maintainers merge their own work, use /lgtm bot workflows, and have different incentives than a team with on-call. Do not read these percentiles as enterprise benchmarks. Read them as a correction to the 2006 figures, and then measure your own repository.
• Inline review threads undercount review. Approvals with a summary comment, synchronous review, and Prow-style /lgtm do not create review threads. “Zero inline threads” means zero line-level remarks, not zero reading. The comparison across size buckets is valid; the absolute level is not a quality score.
• No defect data. We measured scrutiny density, not escaped defects. We cannot tell you that an 800-line pull request ships more bugs, only that it receives roughly one-fifth the comment density per line of a 100-line one. Anyone claiming a 2026 size-to-defect-rate number from public data is extrapolating.
• Source verification. SmartBear’s 200-400 LOC and 70-90% defect-discovery figures were read at source on 2026-10-18. Google’s 100-line and 1000-line figures were read at google.github.io/eng-practices on 2026-10-18. We could not locate a primary Google source for the widely attributed “under 200 lines” rule, and we believe it does not exist. If you have one, we will correct this page.
• Raw collection and analysis were scripted; figures in this article are generated output, not hand-transcribed.

Recommendations

Criteria used: reviewability in one pass, measurability without gaming, and resilience to codemods and generated output.

If you want one number to start from, use 250 changed lines as a soft warning, with generated paths excluded. That sits just above the 205-line p75 of our sample, so it labels roughly the top quartile rather than half your pull requests. Move it after one month to your own p75.

Track percentage under threshold, never average size. Our mean is 373 and our median is 63. Any team reporting “average PR size” is reporting its lockfiles. Above 80% under threshold is healthy; below 60% is a coaching signal.

Before coaching decomposition, check first-review latency. Median time to first review in our de-biased sample was 5.3 hours, and it rose to 16.8 hours for 400-to-999-line changes. If your reviewers take two days, batching is rational behaviour and no rule will beat the incentive.

Adopt exactly one exemption label and wire it into the metric. Codemods, lockfiles, generated clients and framework migrations are legitimately large. 11.3% of the large pull requests we sampled were majority machine-written. If those are in your numerator you are measuring your build system.

Reach for stacked diffs or feature flags before you reach for a bigger pull request. The “I would block myself” argument is the most common justification for an oversized change and the easiest one to dissolve. See what are stacked diffs.

Do not buy an AI reviewer to make large pull requests safe. Buy one to raise the floor on every pull request. Check the file cap first: CodeRabbit stops at 150 files on Essentials, GitHub Copilot removed its cap entirely on 27 Aug 2026, and nobody independent has published a false-positive rate for any shipping commercial reviewer. For the human half of the process, read pull request review best practices and the deeper code review best practices guide.

Further reading

• Pull Request Review Best Practices: The 2026 Playbook
• Code Review Best Practices for Engineering Teams
• What Are Stacked Diffs? Stacked PRs Explained
• Pull Request Size Best Practices
• Best AI Code Review Tools for a Large Codebase
• How to Evaluate an AI Code Reviewer: A 14-Day Pilot Protocol
• Code Review Checklist for Authors and Reviewers