How to Review a Coding Agent's Diff

An agent's summary tells you what it meant to do. The diff tells you what it did. Review the diff, and read it in an order that puts the risky parts first, because an agent's diff can be long and reads equally confident in its strong and weak parts.

This page gives that order, the git commands for each step, a checklist you can copy, and the review commands Claude Code and Codex ship with as of September 2026. The order is editorial judgment. The commands come from the vendors' docs.

Start from evidence, not the summary

Before you open a single file, get the agent to show its work. Anthropic's best-practices page says to have Claude show evidence rather than assert success: the test output, the command it ran and what it returned. Reviewing evidence is faster than re-running everything yourself.

Then run the check yourself anyway. If the summary says the tests pass and your terminal disagrees, the summary is wrong. That one rerun catches the cheapest class of error there is.

Look at the shape before the lines

Get the size and spread of the change first:

git status --short          # every changed, added and untracked file
git diff --stat             # lines added and removed per file
git diff --stat main...HEAD # the same for a branch, against main

In a session, /diff does the same job. In Claude Code it shows the working-tree changes, including Claude's edits, in a panel or viewer (interactive mode docs). In Codex it shows staged changes, unstaged changes, and files Git isn't tracking yet (Codex slash commands).

The shape answers the first question: is this the change you asked for? Compare the file list with the task or the approved plan. Any file you didn't expect gets a reason before anything else gets your attention. Untracked files matter here. A new helper module or a stray debug script won't show up in a plain git diff.

Check four things first

Read these four areas before the feature code. Each one can make a correct-looking change unsafe, and each is quick to isolate.

1. Tests

git diff -- '*test*' '*spec*'

Look for three things. A deleted or skipped test (.skip, xit, @pytest.mark.skip). An assertion that was loosened, such as an exact value turned into toBeTruthy() or a snapshot re-recorded without explanation. And new tests that only restate the implementation. A test written in the same session as the code can check that the code does what it does, not what you wanted. If a test changed and the task wasn't about that test, ask why.

2. Deletions

git diff --diff-filter=D --name-only   # files deleted
git diff | grep '^-' | grep -v '^---'  # every removed line

Removed lines are where behavior quietly disappears: an input check, an error branch, a permission check, a comment explaining a strange but necessary workaround. Agents clean up code they consider unused. Confirm it really was unused, for example with a search for the removed function's name.

3. Dependencies

git diff -- package.json package-lock.json requirements*.txt pyproject.toml go.mod

Every new package is code you didn't read, running with your app's permissions. Check that the package is the one you think it is, spelled right, maintained, and actually needed. Look for version bumps nobody asked for. A lockfile diff that is much bigger than the manifest change usually means a range was widened or the lockfile was rebuilt, and that deserves a look.

4. Config, CI and secrets

git diff -- '.github/' '*.yml' '*.yaml' '*.toml' '*.json' '.env*' Dockerfile

Config changes have wide effects and short diffs. Look for weakened lint or type settings, a disabled CI step, loosened CORS or auth settings, a changed build output, and anything that looks like a key. Anthropic's list of actions its auto-mode classifier blocks by default includes disabling CI checks and commits that would send secrets outside the repository (permission modes). Those are the same things worth catching by eye.

Then read the feature code

With the risky areas cleared, read the rest the way you'd read a colleague's pull request, with a few agent-specific habits:

• Check the edges, not the happy path. The main flow is the part the task described, so it's the part most likely to be right. Read the error handling, empty inputs, and authorization.
• Look for duplication. Search for a new helper's job elsewhere in the repo. An agent that didn't look before it wrote can add a second version of something you already have.
• Watch for scope creep. Renamed variables, reformatted files, and "while I was here" refactors make the diff harder to review and hide the real change. Ask for them to be reverted and sent as a separate change.
• Read comments skeptically. A comment that explains what the code does is noise. A comment that claims something about behavior elsewhere needs checking.

Use the built-in reviewers as a second pass

Both tools ship a reviewer. Treat it as a second reader, not a replacement for you.

Sources: Claude Code commands, Codex code review, and Codex CLI commands, read September 26, 2026. Codex also reads a ## Code Review Rules section in AGENTS.md for its GitHub reviews (AGENTS.md guide).

The reviewer works best in a fresh context. The session that wrote the code has already convinced itself the code is right. Anthropic's best-practices page recommends a verification subagent for exactly that reason, so the agent doing the work isn't the one grading it. It also warns that a reviewer asked to find gaps will usually find some. Tell it to report only issues that affect correctness or the stated requirements.

Make the agent explain its own change

The agent that wrote the diff is also the fastest way to understand it, provided you ask questions that have checkable answers. Some prompts that work in either tool:

For each file in git diff --stat, give one sentence on why it changed.
Flag any file that isn't required by the original task.

List every line you deleted that changed behavior, and why removing it is safe.

Which of the tests you added would fail if I reverted your change to src/search.ts?
Run them against the reverted file and show me.

What did you assume about the input that isn't checked anywhere?

The third prompt is the most useful. It turns "I added tests" into a claim you can verify: revert the source change, run the new tests, and confirm they fail. A test that passes on both versions tests nothing about the change.

Treat the explanations as leads, not proof. An agent explaining a change will describe its intent fluently even where the code doesn't match. When the explanation and the diff disagree, the diff wins.

A checklist to copy

## Agent diff review

- [ ] Reran the check myself (tests, typecheck, build) and it passes
- [ ] File list matches the task or plan; every surprise file explained
- [ ] Untracked files reviewed (git status --short)
- [ ] No tests deleted, skipped, or loosened without a reason
- [ ] New tests fail when the source change is reverted
- [ ] Every deleted line checked; removed code really was unused
- [ ] No new or bumped dependency I haven't looked up
- [ ] No config, CI, lint, or auth setting weakened
- [ ] No secrets, keys, or local paths in the diff
- [ ] Error handling and edge cases read, not just the happy path
- [ ] No unrelated refactors or reformatting mixed in
- [ ] I can explain every change in my own words

The last line is the real gate. If you can't explain a change, you can't maintain it, and whoever gets paged later won't be able to either.

Where this fits

The review is only as good as the task that came before it. A diff from a well-scoped task is small enough to read in one sitting. The Copilot lab on this site applies the same discipline to a single bug: write two failing tests, then review the exact version check in the patch. For judging agents beyond single diffs, see how to evaluate AI agent performance and reliability.

Previous in the series: Plan mode and agent-sized tasks. Next: Git workflows with coding agents.