Reviewing PRs locally vs. in the browser: when to pull the branch

Every team has one: the reviewer who refuses the web diff, pulls the branch, and reads the change in their editor. They’re usually among the best reviewers on the team, and they’re paying a real tax for it. Some of the strongest engineers we know review this way; this piece is about what they’re getting, what it costs, and when each mode actually wins.

What local review actually buys you

• Navigation. Go-to-definition, find-references, the call hierarchy: the diff shows what changed; the editor shows what the change touches. For judging a refactor or an API change, that difference is the review.
• Execution. Run the tests, poke the feature, profile the hot path. The web diff asks you to trust; the checkout lets you verify.
• Your tools. Your keybindings, your linters, your search. Reviewing in an environment tuned over years beats any vendor’s viewer for raw reading throughput.

What it costs

• Context switching. Stash or commit your work, switch branches (or maintain a second worktree), restore state afterward. gh pr checkout makes the fetch cheap; nothing makes the interruption cheap.
• The transcription tax. Findings live in your head and the PR conversation lives in the browser. Every comment means re-finding the file and line on github.com and reconstructing your thought. This is where local reviewers quietly lose their time advantage, and why their feedback sometimes arrives as one big comment instead of anchored threads.
• No shared state. Viewed-file tracking, resolved threads, suggested changes: the collaborative review machinery doesn’t follow you into the editor.

A decision rule that holds up

Pull the branch when the review question is architectural or behavioral: does this design hold, does this actually work, what does this break elsewhere. Stay in the diff when the question is local correctness: is this logic right, are the edges handled, is it consistent. Mixed PRs (most large ones) often deserve both: a browser pass for triage and threads, a checkout for the two files where the real decision lives.

The gap both modes leave

Notice the shape of the trade: one mode has the context (editor) and the other has the conversation (browser), and review needs both. That gap is the design brief we started Pyor from: a native review app with diff ergonomics built for reading (file triage, viewed tracking that includes whole folders, focus mode, a diff that keeps your place at any size) and the full review loop: inline threads, approvals, and merge, synced with GitHub. It talks to GitHub directly from your machine, so the privacy posture matches local review: your code never passes through our servers. Free for individuals. It won’t replace the checkout for “does this design hold” (nothing replaces running the code), but it retires the checkout you were doing just to read comfortably.

If you take one habit from this

Make the mode a deliberate choice per-PR instead of an identity. The reviewers who do this best aren’t “local people” or “browser people”; they ask what does this change need from me? and pick the cheapest surface that delivers it. The one identity worth keeping: never approve a change you couldn’t explain to the next reviewer, wherever you read it.