The Pull Request Nobody
Wants to Review

You've seen it. A pull request appears in the queue: 47 files changed, +2,341 −891. The title is something like 'Implement user settings and fix related issues.' The description is three sentences. It's been open for four days.

Someone will eventually approve it. Not because they reviewed it thoroughly. Because they opened it, scrolled for ninety seconds, felt the familiar pressure of not wanting to be the person blocking the release, and clicked approve.

This is not a discipline problem. It's a systems problem. Large pull requests don't fail because engineers are lazy — they fail because the cognitive demands they place on reviewers make meaningful review functionally impossible.

What actually happens when a large PR lands

Code review has an effective working memory limit. A reviewer can hold a mental model of maybe 200–400 lines of changes before the model starts to collapse. Beyond that, they're no longer reviewing — they're skimming for obvious errors and hoping the tests cover the rest.

This isn't a failure of effort. It's a failure of context. To review a change meaningfully, you need to understand what it's trying to do, what it touched to get there, and what the downstream effects are. That's easy for 80 lines. It's nearly impossible for 2,000 — especially when those 2,000 lines span a bug fix, a refactor, a new feature, and three unrelated cleanup commits.

The cost isn't review time. It's feedback delay.

The conventional argument against large PRs focuses on review time — the bigger the diff, the longer it takes to merge. That's true, but it's the smallest part of the problem.

The real cost is feedback delay. When you batch three weeks of work into one PR, you're not just asking for a review — you're asking for a verdict on three weeks of assumptions. If the architectural decision you made in week one was wrong, you find out in week four, after you've built everything on top of it. The rework isn't just the wrong code. It's the right code you wrote on top of the wrong code.

Small, focused PRs get reviewed faster not just because they're shorter, but because reviewers can engage with them fully. A 150-line PR with a clear scope gets meaningful feedback. That feedback arrives while the author still has the context to act on it quickly. The iteration loop stays tight.

What PR size is actually measuring

A consistently large PR size is usually a symptom of one of three things: the team hasn't learned to decompose work into shippable slices; the author is uncomfortable shipping incomplete work and waits until everything is 'done'; or the codebase makes incremental changes hard because everything is tightly coupled.

1. 01If it's a decomposition problem: practice writing the smallest version of a feature that can be reviewed independently. Not the smallest version that works end to end — the smallest slice that moves the codebase in the right direction.
2. 02If it's a completeness problem: feature flags exist for this. Ship the backend wiring behind a flag. Review the UI component separately. The code reaches production — and gets reviewed — without being visible to users until it's ready.
3. 03If it's a coupling problem: that's the more expensive fix, but the large PR is giving you early signal. Treat it as a diagnostic, not just a nuisance.

The other side: what good review actually looks like

Small PRs make good review possible — they don't guarantee it. Reviewers also have a responsibility to engage with what they're given, not just approve to keep the queue moving.

Good review asks: does this code do what it claims to do? Does it do anything it doesn't claim to do? Is this the right place for this logic? Would I be able to debug this at 2am? It doesn't ask: does this match my personal style preference? Would I have implemented this differently?

The most useful review comment is the one that changes the outcome of the code. The least useful is the one that changes the variable name. Both take roughly the same effort to write. One of them matters.

The one number worth tracking

If your team tracks anything about pull requests, track time-to-first-meaningful-comment, not time-to-merge. Merge time is influenced by too many factors outside the reviewer's control — priorities, blockers, calendar. Time to first meaningful comment measures whether review is actually happening.

A team where PRs get a real response within a few hours, regardless of size, is a team where authors get early signal, catch wrong turns quickly, and build the habit of writing code that's easy to explain. That compounds.