Pull request volume went up. Review UI did not. Most teams still read diffs in a browser tab built around scrolling, clicking, and a few shortcuts.
Keyboard-driven code review is not just learning GitHub hotkeys. It is a review workflow where the common moves stay under your fingers: next file, next hunk, jump to a symbol, mark a file covered, start a comment, and return to the same place after checking the code around a change.
That matters most on a large pull request. If every file change needs a pointer hunt or a new tab, reviewers spend energy on navigation instead of understanding the change.
What keyboard-driven code review actually means
A shortcut overlay on a mouse-first interface is still a mouse-first interface. You press a key, then go back to aiming at file names, buttons, and comment controls.
A keyboard-first review surface should let you:
Move from file to file without aiming at a sidebar.
Move between hunks and comments without losing your scroll position.
Mark a file as covered without leaving the review flow.
Start, edit, keep, or discard a comment without fighting focus.
Jump from a changed symbol to its definition or references, then return to the same hunk.
If those actions require repeated precision clicks, the tool is keyboard-tolerant, not keyboard-driven.
Where browser review starts to slow down
GitHub has useful pull request shortcuts. They can make a small change faster. But a shortcut list does not solve the deeper problem with large diffs.
Reviewers still need to find changed files, track what they have read, keep comment context, and understand symbols outside the patch. When a comment box steals focus or a definition opens in another window, the reviewer has to rebuild the same mental context.
That friction creates predictable shortcuts of its own. Reviewers skim generated files, read only the lines a bot flagged, or approve with “looks good” and plan to come back later. The interface makes deep reading expensive.
A keyboard-first review loop
Use this as a simple test on your next medium or large pull request:
Open the pull request and land on the first file you have not covered.
Move through the changed hunks without reaching for the mouse.
When a symbol looks unclear, jump to its definition or references in the local workspace.
Return to the same hunk and decide whether the behavior is correct.
Start a comment only when you have a concrete question or problem.
Mark the file covered and move to the next one.
Submit the review after the full pass, rather than publishing a stream of half-formed reactions.
Every step should be a short key sequence or a single action. If checking one definition forces a manual search for the original lines, you will skip that check when you are tired. That is how subtle issues survive review.
Why macOS reviewers benefit from a native surface
A native macOS app can treat the pull request as a working session instead of a web page. The local clone stays available for context. Keyboard commands can control review state. Code navigation can work like it does in an editor.
This does not mean every review needs a full IDE. The pull request still needs its own files, threads, review state, and publishing flow. The useful middle ground is a review surface with editor-grade navigation and PR-native collaboration.
That is also where on-demand AI fits better. Navigation can answer many basic questions faster than a generated explanation. AI can then help with the questions that need investigation, such as tracing a failure path or checking an edge case.
Keyboard speed is not the goal by itself
Faster movement is useful only if it leaves more attention for the hard parts of review.
Ask questions like:
Did this API change break a caller outside the diff?
Does the new helper duplicate an existing path?
Can an invalid input or permission case reach this code?
Does the test cover the behavior that changed, rather than only the happy path?
Keyboard navigation should reduce pointer logistics. It should not turn review into faster skimming.
Keyboard review and AI comments
AI can help reviewers investigate a change. It should not automatically fill the review thread.
A useful flow is simple: ask the agent about a selected change, read its suggestion in context, check the code yourself, then keep, edit, or discard the draft. The reviewer still decides whether the finding is accurate and useful to the author.
That human step matters. A possible issue may be intentional, handled by another layer, or part of a larger migration. A draft gives the reviewer room to add that context. Automatic comments create cleanup work.
How to audit your current review workflow
Watch your hands for ten minutes on the next non-trivial pull request:
How often do you use the mouse to change files?
How often do you lose a hunk after checking a definition elsewhere?
How often do you abandon a comment because the composer took focus?
How often do you reopen a file because you cannot tell whether you finished it?
If the answer is “constantly,” the problem may not be reviewer discipline. It may be the input model of the review tool.
What to look for in a keyboard-driven code review tool
File and hunk navigation. You can move through a large change without sidebar hunting.
Stable review state. Covered files and comment drafts are easy to see and resume.
Local code context. The changed code connects to the workspace around it.
Symbol-aware navigation. Go-to-definition and references work from the review surface.
Human-controlled AI. Agent suggestions stay drafts until the reviewer chooses to keep them.
PR-native collaboration. Comments, threads, and submission still map back to the pull request.
Where Relu fits
Relu is a native macOS app for reviewing GitHub pull requests. It combines keyboard-driven movement, a local workspace clone, LSP navigation, and an on-demand AI agent that only drafts comments the reviewer chooses to keep.
The point is not to make reviewers click faster. It is to keep the review close to the code, reduce the cost of checking context, and leave the final judgment with the person reading the change.