How to review an AI coding agent's changes before you commit

Coding agents write a lot of code quickly, and all of it lands in your working tree. The habit that keeps that safe is the same one you would use for a colleague's pull request: review before it is committed. Here is a review routine that takes a few minutes and catches most of what goes wrong.

Start with a branch you can throw away

Review is easiest when the agent's work is separate from everything else. Give each agent its own branch, ideally in its own git worktree, so its changes never mix with yours and discarding them is one command. Then the whole review is one diff:

git diff main...agent/login-fix --stat   # what changed, by file
git diff main...agent/login-fix          # the changes themselves

1. Get the overview first

Before reading any code, look at the shape of the change with git status and git diff --stat. Ask:

• Did it touch files that have nothing to do with the task?
• Are there new files you didn't expect, such as scripts, fixtures or config?
• Did a lockfile change? A changed package-lock.json or Cargo.lock means new or upgraded dependencies, which deserve a look on their own.
• Is the size about right? A one-line bug fix that changes 400 lines needs explaining.

2. Read the diff by hunk

Interactive staging turns reading into deciding:

git add -p    # y to stage a hunk, n to skip, s to split it

Whatever you stage, you have read and accepted. Whatever is left over gets a second look, or goes back to the agent. A terminal UI makes this faster: lazygit stages lines and hunks with a key, and tig is a quick read-only browser.

3. What to watch for

• Weakened tests. An agent asked to make tests pass may loosen an assertion, skip a test or delete it. Read changes under tests/ first.
• Swallowed errors. A new empty catch, an unwrap_or_default() or a broad except that hides the original failure.
• Invented APIs. Calls to functions or options that don't exist in the version you use. The type checker catches some; read the rest.
• Secrets and local paths. Tokens, .env values, or /home/you/... paths copied into code or config.
• Scope creep. Unrequested refactors, renames and reformatting that bury the real change. Ask the agent to split them out.

4. Run it yourself

An agent saying the tests pass is not the same as the tests passing on your machine. Run the test suite, the linter and the type checker yourself, and try the change by hand if it touches anything a user sees. It takes a minute and catches the cases where the agent ran a narrower command than you would.

5. Commit in small, described steps

Commit what you have reviewed, with a message saying what changed and why. If the agent did several things, make several commits. Small commits are easier to revert when something turns up later, and the history tells you which changes came from which task.

Review beside the agent in Hive

Hive puts this routine next to the agent. Enable the review integration and Ctrl+Space G opens lazygit, tig or git diff in a split beside the focused agent, in its own directory or worktree:

# ~/.config/hive/config.toml
[integrations.review]
enabled = true

[integrations.git_status]
enabled = true   # main ~3 ↑2 under every project in the sidebar

With git status on, the sidebar shows changed files and unpushed commits for every project, so uncommitted agent work doesn't sit unnoticed in a repository you haven't opened today. And because the sidebar marks an agent done when it finishes while you are elsewhere, you know when there is something to review. See review and git status.