You are asked to review a 2,000-line GitHub pull request. How do you review it effectively?

## Start with the honest conversation Review quality falls off a cliff with size. A 2,000-line pull request will get a real reading of the first two hundred lines and a scroll for the rest, and everyone involved knows it. The first professional move is therefore to ask whether it can be split — and to make that ask specific rather than moralising: "the schema migration and the API change could land separately, and I could review each properly today" beats "PRs should be smaller". Sometimes the answer is genuinely no. A dependency bump touching a lockfile, a mechanical rename across a package, a generated client, a vendored library: these are large and unsplittable. In that case scope the review explicitly and say so in the review body — "I reviewed the hand-written changes in `api/` and `service/`; the generated client I spot-checked only" — because a review that silently implies full coverage is a false signal that outlives you. ## Establish intent before reading code Read the pull request description and the linked issue. If the description does not say what the change is for, ask before reviewing; you cannot judge whether code is correct without knowing what correct means. Then read the **tests first**. Tests state the intended behaviour in executable form, they show which cases the author considered, and their absence in a region is itself the finding. Starting in the tests also stops you from anchoring on implementation details before you know what the change is trying to do. ## Use the mechanics GitHub gives you **Commit by commit.** If the author curated the history — refactor, then behaviour change, then tests — the per-commit view converts one enormous diff into a sequence of small, intentional ones. If the history is thirty "wip" commits, this does not help, and that is worth saying kindly. **Hide whitespace changes.** A reformat mixed into a logic change is the classic hider; toggling whitespace off collapses it and leaves the real edit visible. **File filter.** Filter by extension or path to sweep mechanical changes in a batch — lockfiles, generated code, imports — so your attention is spent on the files where a defect can actually hide. **Viewed checkboxes.** Ticking each file as you finish lets you review across several sittings without losing your place, and GitHub re-opens a file if it changes after you marked it. **Batch, do not spray.** Start a review so comments stay pending, and submit once. Forty individual notifications is a hostile experience, and batching lets you delete the three comments that the last file answered. ## Prioritise what you look for With limited attention, spend it in order of what humans catch that tools do not: correctness on the edges (nulls, empty collections, boundaries, error paths), concurrency and ordering, security-relevant handling of input and authorization, data migration and rollback, and public interfaces that will be expensive to change later. Formatting, import order and lint rules should be automated; commenting on them by hand in a large review is spending your scarcest resource on the cheapest problem. ## Structure the output One review, and inside it a clear hierarchy. Put the one thing that matters — the design objection, the missing rollback, the unhandled failure mode — at the top of the review body, not on line 1,340 of file 27 where it will be found last. Label the rest: prefix optional remarks with something the team has agreed on (many use "nit:") so the author can triage in one pass instead of guessing which of your forty comments block the merge. Use suggestions for the mechanical fixes so the author clicks rather than parses prose. Ask questions where you are unsure rather than asserting; on a large change you are frequently the one missing context, and "what happens when this is empty?" costs nothing when the answer is "the caller guarantees it isn't". ## Choose a verdict you can defend If the approach is wrong, request changes early and say so before the author invests another week. If the code is sound with small issues, approve and mark which comments are optional — holding an approval hostage to nits is how review becomes a chokepoint. And if you could not review it properly, say that instead of approving; an unreviewed merge with your name on it is the worst outcome available. ## The systemic point A 2,000-line pull request is usually a symptom: no incremental delivery path, a branch that lived too long, or a feature that was never decomposed. Reviewing it well is the immediate job; raising the pattern afterwards — in retrospective, not in the review comments — is the durable fix.