Most pull request reviews start with a diff in a browser. That is useful for seeing what changed. It is not enough for understanding why the change is safe.
A serious review often needs answers that are outside the changed lines:
- Where is this function or type defined?
- Which callers depend on its current behavior?
- What concrete type reaches this line on the pull request branch?
- Does a related implementation or test follow a different rule?
Code review with LSP keeps those answers close to the diff. You review a real checkout of the pull request, then use language-aware navigation to follow the change through the repository.
What LSP adds to pull request review
The Language Server Protocol gives editors a common way to expose language intelligence. Depending on the language server, that can include go-to-definition, hover types, find references, symbol search, diagnostics, and other code-aware actions.
In a review, these actions change the basic loop:
- Read a changed line in the diff.
- Jump to its definition or type.
- Check callers, implementations, or related tests.
- Return to the same hunk.
- Decide whether the behavior is correct.
Without that navigation, reviewers often open a separate editor, search by filename, lose their place, and eventually stop checking context. The problem is not a lack of effort. The path to the answer is too expensive.
Why a diff is not the whole review
A diff tells you which lines moved. It does not show the full system those lines participate in.
Consider a pull request that changes a method signature. The changed file may look correct, but the real risk could be in:
- a caller in another package
- an interface implemented by several types
- a test that still assumes the old return value
- a permission or error path outside the patch
- a configuration file that changes the runtime behavior
These details are why local context matters. The diff is the map of the change. The workspace is the terrain you need to inspect before approving it.
A practical LSP review workflow
1. Open the pull request in its own workspace
Use the pull request branch, not your local main branch. Types, definitions, callers, and tests need to match the code you are reviewing.
2. Read the changed files first
Start with the diff. Identify changes that affect behavior, contracts, data flow, or security. Do not jump into the whole repository before you know what questions the patch raises.
3. Follow uncertain symbols
When a symbol matters to the review, use go-to-definition, hover information, or find references. Check the implementation and the callers that rely on it.
4. Return to the original hunk
Investigation only helps if you can get back to the exact change without rebuilding your place. Keep the review state visible while exploring the surrounding code.
5. Comment on a concrete risk
Write feedback when you can explain the behavior that may be wrong, the case that is missing, or the question the author needs to answer. Do not comment just because a line looks unfamiliar.
6. Finish the pass before submitting
Keep investigation separate from the final decision. Review your notes, edit or discard weak comments, then submit one deliberate review.
Where LSP-backed review helps most
You do not need full code navigation for every one-line change. It matters most when the pull request:
- moves behavior across files or packages
- changes an API, schema, interface, or shared type
- touches authentication, billing, concurrency, or permissions
- comes from a part of the codebase the reviewer did not write
- contains generated or AI-assisted code that increases diff volume
- changes a function with callers outside the visible patch
These are the reviews where browser-only reading turns into tab management. The more context a change needs, the more useful it is to have that context in the review surface.
LSP is not the same as opening an IDE
An IDE gives you strong code navigation, but it does not automatically give you a review workflow. You still need to track changed files, review state, draft comments, threads, and the final decision.
A useful review surface combines both jobs:
- Diff-first reading. The changed lines remain the starting point.
- Workspace context. Related files are available on the reviewed branch.
- Symbol-aware navigation. Definitions, types, and references are one action away.
- Stable review state. You can investigate without losing your place.
- PR-native feedback. Comments and the final review still go back to the pull request.
That is different from checking out a branch in an editor and switching back to GitHub whenever you need to comment.
What about AI-assisted review?
AI can help investigate a focused question in the local workspace. For example, it can trace an error path, look for callers that handle a value differently, or draft a possible line-anchored finding.
It should not publish comments by itself. The reviewer needs to check the code, add context, and keep, edit, or discard the draft. Otherwise the review thread fills with suggestions that the author has to filter.
LSP and AI solve different parts of the job. LSP gives you direct access to the code's structure. AI can help investigate when the question spans several files. Neither replaces the reviewer's decision.
How to test your current review setup
Pick a non-trivial pull request and answer these questions from one review session:
- What is the concrete type at this changed line?
- Where is the symbol defined on this branch?
- Which callers use it?
- Can you return to the same hunk after checking?
- Can you keep review progress separate from code exploration?
If each answer requires a separate search, window, or browser tab, your review surface is making context expensive. If the answers are available from the hunk, you can spend more time judging the design and less time reconstructing the repository.
Where Relu fits
Relu is a native macOS app for reviewing GitHub pull requests. It combines a local workspace clone, keyboard-driven movement, full LSP navigation on the code, and an on-demand AI agent that only drafts comments the reviewer chooses to keep.
The goal is not to make reviewers scroll faster. It is to let them read the change in context without leaving the review surface. For the broader workflow, see how to review pull requests locally on macOS and the guide to keyboard-driven code review.
When a pull request changes behavior outside the visible diff, code review with LSP gives reviewers a shorter path to the answer. That makes a deliberate approval easier than a browser-only guess.