How to review large pull requests without losing your mind
Othman Shareef · June 12, 2026 · 7 min read
The 2,000-line PR is in your queue. You didn’t write it, you can’t hold it in your head, and “LGTM” is starting to look morally acceptable. It isn’t, but neither is pretending you’ll read forty files with equal care. Here’s the method we use to review large pull requests properly: triage, passes, and keeping your place.
Step 1: Don’t start at file one
The diff is ordered alphabetically; your understanding shouldn’t be. Read the PR description, then the commit list; commits often reveal the change’s real structure (“refactor first, then feature”) even when the description doesn’t. If the description is missing the why, ask for it before you read a single hunk. That’s not pedantry; it’s the cheapest possible round-trip, and it improves every minute you spend afterward.
Step 2: Triage the files and find the three that matter
In almost every large PR, a minority of files carry the actual decision-making. Sort the file list into three buckets before reading anything closely:
- Core: new logic, changed behavior, anything touching state, money, auth, or concurrency. This is where your attention goes.
- Supporting: call-site updates, types, wiring. Scan for surprises, not for line-by-line correctness.
- Mechanical: lockfiles, generated code, renames, formatting. Verify they are what they claim (a “rename-only” file with a logic edit hiding inside is a classic), then move on.
Tests deserve a special mention: read them early, not last. Good tests are the best description of intended behavior you’ll get; missing tests for the risky path tell you exactly where to look hardest.
Step 3: Review in passes, not in one sweep
Trying to judge correctness, design, and style simultaneously is how reviewers burn out and miss things. Make separate passes over the core bucket:
- Correctness: does it do what it says? Edge cases, error paths, off-by-ones, assumptions that don’t survive concurrency.
- Design: is this the right shape? Will the next person extend it or fight it?
- Style and nits: last, quickly, and labeled as non-blocking. The Conventional Comments convention (
nit:,question:,issue:) keeps these from reading like blockers.
Step 4: Protect your place
Large-diff review fails as much from lost state as from lost attention. Mark files as viewed the moment you finish them. If your tool can mark whole folders viewed, use it to clear the mechanical bucket in one stroke. If you get interrupted (you will), the viewed markers are what makes resuming cost seconds instead of minutes.
Step 5: Timebox, then come back
SmartBear’s peer-review research puts the practical limits at roughly 60-minute sessions and no more than ~500 lines per hour. Past that, defect detection falls off. For a genuinely big PR that means the review is designed to span sessions. Plan it that way instead of discovering it at minute ninety.
Step 6: Report honestly
End with a review summary that says what you actually did: “Read auth flow and migration deeply; scanned call-site updates; trusted generated files.” It calibrates the author’s confidence, tells co-reviewers where to spend their attention, and keeps “approved” meaning something.
Where tooling earns its keep
Everything above works in any tool, and is less painful in a surface built for it. This is the use case we designed Pyor around: a file rail you can triage and group, folder-level viewed marking, inline threads that stay put, and a focus mode that collapses everything but the code. Full disclosure: we make it, it’s free for individuals, and your code never leaves your machine. If your method survives a 2,000-line PR but your tab doesn’t, that’s the gap it fills. For why PRs got this hard in the first place, see our earlier piece on the review bottleneck.