Contact us

The Pull Request That Was Too Big to Review Properly

by Eric Hanson, Backend Developer at Clean Systems Consulting

The Review Nobody Actually Did

A PR arrives with 47 files changed and a 2,400-line diff. It's a "refactoring plus the new feature." The reviewer opens it. They scroll through the first ten files and feel the familiar resistance — the cognitive overhead of holding the context of a large, multi-concern change. They spend ninety minutes nominally reviewing. They approve it. They caught three minor naming issues. They didn't catch the race condition in the concurrent order processing logic. They didn't catch the missing index on the new query. They couldn't — there was too much to hold at once.

This is not a failure of diligence. It is a structural failure. The human capacity for careful review is not linear with PR size. After about 400 lines, review quality degrades significantly. SmartBear's research on code review quality showed that reviewers find roughly 70-80% of defects when reviewing under 200 lines of code per hour, dropping substantially beyond that.

A 2,400-line PR at that rate takes over twelve hours of focused review. Nobody actually spends twelve hours on a PR review.

Why PRs Get Large

Large PRs don't usually start as intentionally large. They grow:

Scope creep during implementation: You're building the feature and you see a refactoring opportunity. You clean it up. Then you notice a related area that could also be improved. By the time the feature is done, the PR also contains two refactors.

Delayed review cycles: PRs that sit without review for days while the author continues developing accumulate more changes. The review debt grows faster than reviewers can address it.

"While I'm in here" additions: Related functionality that gets bundled because the author is already familiar with the area. Logically adjacent but review-burdening.

Missing pre-split discipline: The original task wasn't broken into reviewable chunks before implementation started.

The Hard Ceiling and How to Stay Under It

The goal is PRs under 400 lines of changed application code. (Dependency lockfiles, generated code, and migration files count differently — they're usually noise.) Under 400 lines, a careful reviewer can fully engage with the change.

The practices that make this achievable:

Separate refactoring from feature work: A refactoring PR and a feature PR that both touch the same code can be submitted and reviewed sequentially. The refactoring PR is context for the feature PR. Each is smaller and more focused.

Commit-first, then PR: Working in small commits and opening PRs from those commits rather than from an extended development session prevents the accumulation problem.

Stacked PRs: A series of PRs where each one depends on the previous. PR 1: data model changes. PR 2: service layer using the new model. PR 3: API endpoint. PR 4: tests. Each is independently reviewable. Some teams use Graphite or similar tools to manage PR stacks.

Draft PRs for early feedback: Opening a draft PR when the feature is 30% done allows reviewers to flag architectural concerns early, before the full implementation is complete and expensive to change.

What to Do as a Reviewer When the PR Is Too Big

You don't have to approve large PRs to get them merged. Options:

Request a split: "This PR has two distinct concerns — the refactoring and the feature. Can you split them into separate PRs? The refactoring one can merge first." This is a legitimate review comment.

Review in batches: Review one logical section, comment on it, and explicitly note that you'll review the rest in a follow-up. This paces the review and provides faster feedback on completed sections.

Focus on the highest-risk areas first: The core business logic change is worth the most attention. The configuration changes and the utility function additions are worth less. Explicit prioritization of review attention is better than uniform shallow coverage.

The Author's Responsibility

Authors are responsible for making their PRs reviewable. This means:

  • A description that explains the change at a high level, not just "fixed the thing"
  • A guide to which files to review first and what the logical structure of the change is
  • Separation of concerns within the PR — refactoring in separate commits from feature work, so reviewers can follow the sequence
  • Explicit callouts of areas that are higher-risk or that need focused attention

A PR that is hard to review is a PR that hasn't been fully authored yet.

The Practical Takeaway

Set a team norm: PRs over 400 lines of application code require a note explaining why it couldn't be split, and a review guide in the description. For your own PRs, before you open them, ask: can I split this into two reviewable pieces without losing coherence? Usually the answer is yes. Split it. Your reviewer will actually review it.

Scale Your Backend - Need an Experienced Backend Developer?

We provide backend engineers who join your team as contractors to help build, improve, and scale your backend systems.

We focus on clean backend design, clear documentation, and systems that remain reliable as products grow. Our goal is to strengthen your team and deliver backend systems that are easy to operate and maintain.

We work from our own development environments and support teams across US, EU, and APAC timezones. Our workflow emphasizes documentation and asynchronous collaboration to keep development efficient and focused.

  • Production Backend Experience. Experience building and maintaining backend systems, APIs, and databases used in production.
  • Scalable Architecture. Design backend systems that stay reliable as your product and traffic grow.
  • Contractor Friendly. Flexible engagement for short projects, long-term support, or extra help during releases.
  • Focus on Backend Reliability. Improve API performance, database stability, and overall backend reliability.
  • Documentation-Driven Development. Development guided by clear documentation so teams stay aligned and work efficiently.
  • Domain-Driven Design. Design backend systems around real business processes and product needs.

Tell us about your project

Say Hej

Our offices

  • Copenhagen
    1 Carlsberg Gate
    1260, København, Denmark
  • Magelang
    12 Jalan Bligo
    56485, Magelang, Indonesia

More articles

Trust-Based Management vs. Micromanagement in Remote Teams

Managing remote teams comes with unique challenges. The approach you take—trust versus micromanagement—can make or break productivity and morale.

Read more

Why Senior Contractors Charge €70-€120 per Hour

Senior contractors don’t charge more for time—they charge for reducing mistakes and accelerating outcomes. What looks expensive upfront is often the cheapest decision in the long run.

Read more

Why the Best Senior Backend Developers You Have Never Heard of Are Based in Southeast Asia

The strongest contractors most Western startups have never worked with aren't hard to find. They're just not in the places founders usually look.

Read more

Your Docker Image Has More Inside It Than You Think

Most developers have a rough sense of what's in their Docker image, but very few have actually inspected it. What you find when you look closely — sensitive files, debug tools, unused binaries — is usually a surprise.

Read more