Most pull request review still happens in a browser tab. You get a red/green diff, a file tree, and a comment box. That is enough to catch typos. It is a weak setup for catching design mistakes.
When you write code, you refuse to work without go-to-definition, hover types, and find-references. Then review starts and those tools disappear. The patch is treated like a self-contained document. It never is.
Code review with LSP puts that navigation on the diff itself. Same class of language intelligence you already trust. Pointed at a real checkout of the PR. So you read the change inside the review surface, not as a screenshot of someone else's branch.
What the browser actually hides
A web diff answers one question well: what lines changed in this file. Serious review asks other questions.
What is the real type of this value after the refactor?
Who else calls this function, and did the contract just shift under them?
Is this “new” helper a duplicate of something three packages over?
Does the deleted branch still matter to a path that is not in the diff?
None of that lives in the hunk headers. It lives in the graph of the repo. Without navigation, reviewers guess, scroll, open extra tabs, or skip the hard parts. On a 40-file PR, skip wins more often than we admit.
Hosted PR pages optimized for commenting on a patch. They did not optimize for understanding a system. Syntax colors and collapse buttons help a bit. They do not replace types, definitions, or callers on the branch you are about to approve.
LSP is not a nice-to-have for review
The Language Server Protocol is how tools expose definitions, types, diagnostics, and symbol search without reimplementing every language. Review is the same problem with worse stakes. You are reading someone else's change under time pressure, often in code you did not just write.
Point an LSP at the PR's workspace and the diff stops being a static screenshot. From a changed line you can:
Jump to the definition that actually ships in this branch
Hover the type after the author's edits, not after main
Search call sites when a signature moves
Open a nearby file that did not appear in the diff but decides whether the change is safe
That is the difference between “I read the patch” and “I understood the change.”
Why bolt-ons still leave a hole
The default response to a weak PR UI is to pile things on top of it. Faster inboxes. Stacked diffs. Merge queues. AI bots that comment on every line. Keyboard shortcuts in the browser.
Those help with triage and throughput. They do not answer “what does this symbol mean on this branch?” You can move through files faster and still approve a contract change you never traced. You can get a machine summary and still miss the caller three packages away.
Review quality tracks whether you can think in the codebase while you are inside the review. Queue cosmetics and auto-comments do not give you that. Symbol-aware reading on the PR workspace does.
What local diff review should mean
Local is not nostalgia for desktop apps. Local means the review tool clones the PR into a workspace and runs a language server against that tree. The diff is the map. The workspace is the terrain.
In practice a solid loop looks like this:
Open the PR and get a workspace ready in seconds.
Move file to file with the keyboard. Mark what you have covered.
From any suspicious line, jump to definitions, callers, and implementations on that branch.
Write comments where your understanding bottoms out, not where the UI makes commenting easy.
Publish the review back to GitHub in one pass.
AI can sit in that loop if it stays on demand. A useful agent digs for edge cases and drafts line-anchored notes you keep or toss. It should not flood the thread with generic summary noise. Judgment stays with the reviewer. The tooling does the legwork.
When LSP-backed review matters most
You do not need full navigation to approve a one-line copy change. You need it when the cost of a miss is high.
Large refactors where behavior moves across files
API and schema changes with callers outside the diff
Concurrency, auth, and money paths
Unfamiliar services where the author holds all the context
Teams drowning in diff volume from AI-assisted coding
That last point is the quiet shift. More code arrives per day. Browser-only review does not scale with “read harder.” It scales with better reading surfaces.
How this differs from “another code review tool”
Most comparison roundups lump everything under code review software. The category is too blunt. Workflow tools optimize queues, stacking, and merge policy. Bot tools optimize automated comments. A review app with LSP is solving a different job: stay inside the PR and still move through the codebase like a developer, not like a spectator.
If your team's bottleneck is “we cannot see the stack of PRs,” fix the inbox. If the bottleneck is “we approve changes we only half understood,” fix the reading environment.
A simple test for your current setup
Next review, pick one non-trivial function in the diff and time how long it takes to answer three questions without guessing:
What is the concrete type here on this branch?
Where is it defined?
What else calls it?
If the answer is a scavenger hunt across tabs, your process is training people to rubber-stamp. If the answer is a keystroke from the hunk, you can spend the time on the actual design argument.
Where Relu fits
Relu is a native macOS app for GitHub pull requests built around that test. Keyboard-driven review, a local workspace clone per PR, full LSP navigation on the diff, and an AI agent that only drafts comments you choose to keep. Writing code got fast. Reading did not. The fix is not louder automation. It is giving reviewers their tools back while the code is still the center of the screen.
If your team already feels the gap between how code is written and how PRs get read, start there. Demand go-to-definition in the review loop. Everything else is decoration on top of whether you can still think in the codebase.