That 4,000-Line PR? Everyone's Pretending to Review It.

TL;DR: Past a certain diff size - and the research puts that size far lower than anyone wants to hear - code review stops happening and starts being performed. The approval still arrives; the defects still ship; everyone involved knows, and nobody says it, because the alternative is blocking a teammate for a week. Four thousand lines is the shape of the problem, not your number; your repo will give you yours in about ten minutes. The cure isn't braver reviewers. It's changing what's allowed to arrive in the queue.

It lands on a Thursday afternoon. Branch name: feature/checkout-rework-final-v2. Forty-one files, a diff your browser hesitates to render, and a description that says "big one, sorry". You watch what happens next, because it's the most honest ritual in your engineering org: the PR sits untouched for two days - nobody wants to be the one who opens it - and then someone senior blocks out "review" time, scrolls at a speed no human reads at, leaves two comments about naming, and approves.

Merged. Reviewed, says the audit trail. And every person involved knows that's not what happened.

Past a certain size, review physically stops working

This isn't a diligence problem, and the research has been embarrassingly clear about it for years. The SmartBear/Cisco study (about 2,500 reviews across 3.2 million lines of code) found reviews catch 70-90% of defects when done well, and that "done well" has hard physical limits: at most 200-400 lines of code per sitting, with defect detection dropping sharply once review speed passes roughly 500 lines per hour. A reviewer facing 4,000 lines has two options: spend a full day doing it properly, or do what humans do with impossible tasks. Satisfice, skim, sign.

Bacchelli & Bird's Microsoft study explains the mechanism: understanding the change is the central challenge of review. Understanding doesn't scale linearly with diff size. A diff ten times bigger isn't ten times harder to hold in your head; it's past the point where holding it in your head is available at all. What survives at that size is pattern-matching on the surface: naming, formatting, the two files the reviewer happens to know cold. Which is exactly the review you got.

And the damage isn't only quality. Giant PRs are queue poison:

• They wait longest for pickup. Nobody volunteers to face the monolith, so it sits, inflating exactly the wait that already dominates review time. Google's study of ~9M reviewed changes shows the other end of the trade: small changes get first feedback in under an hour, with the overall median for the entire process under 4 hours. Pickup time is where big PRs go to age, and they're a fat contributor to reviews taking so long in general.
• They train your team into approval theater. Every performed review lowers the bar for the next one. Rubber-stamp culture rarely starts with laziness; it starts with diffs that made real review impossible and a team that adapted.
• They hide risk in bulk. A 4,000-line PR that breaks something gives you 4,000 lines of suspects and one revert that takes half the feature down with it. The case for small PRs isn't aesthetic. Batch size is the variable behind reviewability, debuggability, and revertability all at once. Oversized batches are also how sprint work becomes an all-or-nothing bet that rolls over when the bet loses.

For calibration: LinearB's benchmarks across 8.1M+ pull requests band elite teams under 100 changed lines per PR, with more than 228 flagged as needing focus. Not 4,000. Not 1,500. One hundred. The gap between that band and your repo's reality is the size of the pretending.

The free cure: change what's allowed to arrive

You can do all of this before ever buying a tool, and it works even if you never buy one.

1. Get your real size distribution. git log --shortstat or your git host's API: changed lines per merged PR, last three months, p50 and p90. Ten minutes. The p90 is the number to say out loud in the next team meeting. Most teams have never seen theirs, and the reaction is usually the whole meeting's agenda.
2. Find your performed reviews. For your ten largest recent PRs, compare diff size with time-from-pickup-to-approval. Approval in minutes on thousands of lines isn't review; it's a signature. No names, no blame. The point is establishing that the org's system currently makes real review impossible at the sizes it produces, which is a scoping problem upstream of any reviewer.
3. Agree a soft cap with named exceptions. Pick a threshold in the neighborhood of the published bands (400 lines is a defensible start), and pre-approve the legitimate exceptions: generated code, lockfiles, renames, formatting sweeps. Those get reviewed shallowly, honestly, with mechanical bulk separated from hand-written logic so the logic still gets real eyes.
4. Teach slicing by dependency. Interface first, implementation second, adoption third, each PR independently buildable and revertable. Authors fear splitting costs time; in practice small PRs get picked up and merged faster, and a clear description does more for a reviewer's understanding than any amount of scrolling. This is standard review craft; the cap just makes it the default instead of a virtue.

How you'd actually see this in Busfactor

A size cap is a policy, and policies decay: the exceptions multiply, the p90 creeps back up, and nobody re-runs the ten-minute analysis until the next postmortem. Busfactor watches the shape continuously from your GitHub data. Its struggled-PR detection uses five deterministic signals (open duration, review rounds, comment weight, re-work loops, worst stalled wait) judged against your org's own recent percentiles, not a number pulled from the air, so the PRs that fought their way in surface with receipts: the diff size, the wait, the rounds, one click from the delivery trace showing exactly where each one stalled. Oversized PRs light this list up, and the verdict lands where it belongs - on scoping and batching as a system - never on whoever wrote the code.

The honest limits: Busfactor counts what git shows. Lines, files, waits, rounds. It cannot judge semantic reviewability: a 900-line mechanical rename is easier to review than 90 lines of concurrency logic, and no line-count heuristic will ever say otherwise, so the signals are framed as questions with evidence, not convictions. It also can't see the design conversation that maybe happened before the PR. A huge diff that was pair-programmed and design-reviewed upstream is less scary than it looks, and only your team knows which one that was. The tool's job is to make sure the question gets asked with numbers on the table.

The door

Run the ten-minute size query this week and read your p90 out loud at the next team meeting - it's free, and it will start the only conversation that actually shrinks diffs. Then, if you want the pretending caught as it happens instead of at the postmortem: get your org's free read. Your repo already knows which reviews were theater. You may as well know too.