Stop reviewing code on GitHub

Here is the uncomfortable part: most teams review code on github.com not because it is the best place to read a change, but because it is where the change happens to live. Those are different things. GitHub is an excellent place to host pull requests. It was never designed to be the place you review them, and in 2026 the seams are showing.

You do not have to take our word for it. In April 2026 GitHub shipped Stacked PRs, and the announcement is a quiet confession: “Large pull requests are hard to review, slow to merge, and prone to conflicts. Reviewers lose context, feedback quality drops, and the whole team slows down.” That is the platform describing its own review surface.

GitHub is a host that grew a review tab

The pull request was a distribution mechanism first: a way to propose and merge a branch. Review was bolted on, and it shows in the priorities. The diff paginates and collapses to protect the page, not your understanding. There is no notion of which files matter, so a lockfile and the one file that changes behavior get equal billing. The whole thing is tuned for browsing a change, which is a fundamentally different task than reconstructing and judging one.

The concrete failure modes

This is not an aesthetic complaint. The web diff actively taxes review in specific, repeatable ways (several catalogued in this critique of the GitHub review UI):

• “Load diff” is where files go to die. The exact files heavy enough to collapse are the ones most worth reading, and the click-to-expand friction means they get skimmed or skipped. The UI hides the risk by default.
• You lose your place. Come back to a PR after lunch and there is no reliable record of what you already read. On a 40-file diff, re-orientation eats the session.
• Threads drift from the code. A reviewer comments, you push a fix, and whether they consider it resolved stays ambiguous. Re-review, the interdiff problem, is where the most time quietly disappears, and the web diff has the weakest tools for it.
• No triage. Every file is presented as equally important, so the reviewer does the sorting by hand, every time, by scrolling.

None of these is fatal on a 30-line PR. All of them compound on the large, AI-authored diffs that now arrive several times a day, which is exactly why GitHub itself reached for stacking.

“But everyone is already on GitHub”

This is the real objection, and it rests on a conflation. Leaving the github.com review experience is not the same as leaving GitHub. Your code, your pull requests, your CI, your permissions, your merge: all of it stays exactly where it is. The only thing that moves is the surface where a human reads the diff and leaves comments, and every serious review tool syncs those comments, approvals, and merges straight back to the PR. Your teammates who never leave github.com see a perfectly normal review. You just did the reading somewhere that respects your attention.

Where to review instead

There is no single answer, and we wrote an honest comparison of the options. The short version:

• Pull the branch. git fetch && git checkout gives you full editor navigation and the ability to run the code. Unbeatable context, real friction; best for the one architectural change that needs it, covered in local vs. browser review.
• An AI-guidance layer (for example Stage) narrates the diff into chapters. Useful when orientation is your bottleneck, at the cost of more generated text to read and trust.
• A dedicated review surface (this is what we build with Pyor, disclosure) keeps the diff but fixes the reading: triage the files that matter, mark whole folders viewed, scope the diff to a single commit so re-review costs only the delta, and run the whole read-comment-approve-merge loop in one window. AI organizes the diff (groups by complexity, one-line labels, hints) rather than narrating it. Free for individuals, synced to GitHub.

How to actually stop

You do not need a migration or a team meeting. Pick your next genuinely large PR, the kind you would normally dread in the web diff, and review it somewhere else once. Pull it locally, or open it in a dedicated surface, leave your comments, and let them sync back. One real PR is enough to feel the difference between a tool that hosts your code and a tool that helps you understand it. If reviewing has quietly become the slowest part of shipping, the surface you do it on is the cheapest thing you can change.