GitHub PR、lazygit 與 Hermes IDE 審查智能體程式碼時，各自看不到甚麼

• Book: Ship It — the pragmatic startup tech stack
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

The agent runs for forty minutes and reports back: done. You open the diff. Fourteen files changed, one commit at the end, and somewhere in the middle a lockfile moved and a CI workflow gained a step.

Which of the agent's replies did that? Was it the one where you said "fix the test", or the one where it decided the test runner needed upgrading? The diff can't tell you. A diff knows files and lines. It doesn't know about turns.

Where you read an agent's work decides what you catch. This post compares three places: GitHub's pull request view, lazygit in your terminal, and the Review Desk in Hermes IDE. I build Hermes, so weigh the third section with that in mind. The PR view wins more of the comparison than you might expect from me.

Four questions for any review surface

Every review tool answers the same four questions, with different amounts of detail.

1. Granularity. What is the smallest unit you can look at on its own: the branch, a commit, a hunk, or the agent turn that produced the change?
2. Feedback. When you find a problem, how does your comment get back to whoever wrote the code, and is that an agent or a person?
3. Risk signals. Does the tool point at the changes that deserve a second look, like a lockfile, a CI workflow or a secret?
4. Review to merged. How many steps between "this looks right" and the change sitting on your main branch?

With a human author, question 1 barely matters. A person commits in chunks that mean something. An agent often doesn't commit until the end, or commits whatever is on disk, so a single commit can hold a dozen turns of trial and error.

Branch, hunk or turn: the unit you review in sets what you can isolate.

GitHub's PR view: built for teams and CI

The pull request page is where team review happens, and nothing else in this comparison replaces it.

Granularity. Since a December 2025 public preview, the new "Files changed" page lets you "review all commits, a subset of commits, or a single commit" without leaving the page, with C opening the commit filter if single-key shortcuts are on. Inside that, GitHub's review guide has you go file by file and tick Viewed. If the file changes after you tick it, it is unmarked again, which matters when an agent keeps pushing. The floor is the commit. If the agent squashed ten turns into one commit, the PR shows one commit.

Feedback. You can comment on a line or a range, propose a suggested change, and submit the review as Comment, Approve or Request changes. Agents that live on GitHub read those comments. GitHub's Copilot coding agent responds when you mention @copilot on a pull request, and from the Files changed tab you can use Fix with Copilot on one comment or Add to batch for several. It "only responds to comments from people who have write access to the repository." Claude Code GitHub Actions does the same for @claude in PR comments and reviews, once the workflow is installed. If your agent runs on your laptop instead, the comment sits on GitHub and you carry it back to the terminal yourself.

Risk signals. This is where the PR view is hard to beat for a team. Protected branches can require a number of approvals, a review from code owners, and passing status checks, and can dismiss stale approvals when new commits arrive. For dependencies, dependency review adds a rich diff of manifest and lockfile changes to Files changed, with vulnerability and license data. The dependency review action that enforces it works on all public repositories; private ones need GitHub Code Security or Advanced Security.

One trap is worth checking in your repo. Files marked linguist-generated in .gitattributes are, per GitHub's docs, "hidden by default in diffs":

# .gitattributes
package-lock.json linguist-generated

That line is reasonable for humans, who rarely edit a lockfile on purpose. For an agent that might bump a dependency on its way to fixing a test, it folds away the line you most wanted to see.

Review to merged. It is slow next to a local merge, and on purpose: push, wait for CI, wait for a reviewer. That wait is the point when other people depend on the branch.

lazygit: hunks and lines, at terminal speed

lazygit is a terminal UI for git, and it is very good at the part of review that is about shaping changes.

Granularity. Its unit is the hunk and the line. Version 0.66.0, released October 5, moved staging into the main view: "press space to stage a hunk or range of lines." The same release added "Build custom patches directly from a commit's diff." You can also mark a commit "so that any other commit you select will be diffed against it" (README). The current release is 0.66.1, from October 11.

For agent work, that means you can pull a bad hunk out of a commit, stage the good half of a file, and split one huge commit into three that make sense. Neither of the other two tools edits history this directly.

Feedback. lazygit has no review comments. You read, you decide, and you type the feedback into the agent yourself. One bridge arrived in 0.66.0: "Open the selected diff line in the branch's pull request," so you can jump from a line in your terminal to the same line on GitHub and comment there.

Risk signals. None built in. It shows you everything at the same weight, so the lockfile looks like any other file. Its custom command system lets you add your own checks, but you write them.

Review to merged. Fast. Merge, rebase, squash, all on your machine with a few keys. Press z to undo the last action, but note the README's caveat: undo "uses the reflog," so it can't bring back working tree or stash changes.

Hermes Review Desk: by turn, before a PR exists

Hermes is a desktop app that runs coding agents such as Claude Code and Codex, each in its own terminal and its own git worktree (README). Its Review Desk works from a different unit: the agent's turn.

Granularity. Hermes saves every agent turn, so you can diff or restore any single turn, with undo (README). A strip under each session, labelled "Agent replies" since 2.3.1 (October 13, 2026), shows one chip per reply with the lines it changed; click one to see its changes or restore your files to that point. The Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) shows changes by turn or by file. So you can find the reply that moved the lockfile and restore your files to the point before it.

Feedback. You leave line comments in the Review Desk, and Hermes sends a line comment "back to the agent that wrote it" (README). For an agent running on your own machine, neither of the other tools closes that loop for you.

Risk signals. The Review Desk shows changes with risk flags (README). That gives you a pointer to where to look first.

Review to merged. Land "commits, opens a pull request or merges locally in one step, into the branch the task started from, and can be undone" (README). Undo data for a landed task is kept for 14 days (release notes). Your own checks can decide when a task is done.

Each line comment is routed to the agent session that wrote that line.

The Review Desk is a single-person, local review. It has no approvals, no code owners, no required checks on a shared branch, and no CI history. Turn history exists only for sessions run in Hermes; a branch an agent pushed from somewhere else is just commits. In a task with extra folders, the replies strip tracks changes in the main project only (2.3.1 notes). And the turn view tells you which reply changed a line, not why the agent did it; you still read the transcript for that.

Side by side

Use them in order

They don't compete as much as the table suggests. They sit at different points in the life of a change.

1. While the agent is still working, review by turn. That is when "restore to before turn 7 and tell the agent why" is cheap, and the comment reaches the right agent without a copy-paste. Hermes does this; so does reading git diff after every turn, if you have the patience.
2. Before you push, shape the history. If the result is one blob of a commit, lazygit's hunk staging and custom patches turn it into commits a teammate can follow.
3. Once others are involved, open the PR. Approvals, code owners, required checks and dependency review belong there, and they protect the branch from you as much as from the agent.

If you work alone on a side project, step 3 may be a formality. On a team, it isn't optional, and no local tool should pretend otherwise. Hermes's Land step can open the pull request for you.

Where do you review agent code today, and what slipped past you because of it? Tell me in the comments.

If this was useful

I build Hermes IDE: it is free to download, source-available under BSL 1.1, runs on macOS, Windows and Linux, and isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor. If reviewing by turn sounds useful, try it on your next agent task and star it on GitHub or open an issue when something doesn't match what I wrote here. If the PR-and-CI step is where your small team still improvises, Ship It covers the road from localhost to production: CI/CD, hosting, auth, payments and monitoring, picked for a team without a platform department.