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 the risky parts first. An agent's diff can be long, and it sounds just as sure of itself in the weak parts as in the strong ones.

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. Reading that is faster than redoing all of it 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 easiest mistake there is to catch.

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 change that looks right unsafe, and each is quick to pull out and read on its own.

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 things quietly stop working: 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 it's the package you think it is, spelled right, still maintained, and actually needed. Look for version bumps nobody asked for.

The lockfile records the exact version of every package that gets installed. If its diff is much bigger than the change to the main dependency file, a version range was probably widened or the whole lockfile was rebuilt. Either one deserves a look.

4. Config, CI and secrets

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

Config changes are short and reach everything. Look for weaker lint or type settings, a disabled CI step, looser CORS settings (which other sites may call your app) 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 yourself.

Then read the feature code

With the risky areas cleared, read the rest the way you'd read a colleague's pull request, plus a few habits that matter more with agents:

• 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 duplicates. 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 extra changes. 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 with suspicion. 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 session, not the one that wrote the code. That session has already convinced itself the code is right. Anthropic's best-practices page recommends a separate verification subagent (a second agent with its own clean slate) 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, as long as you ask questions whose answers you can check. 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 small, clear task is short 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.