How do you review code written by an AI agent?

A coding agent is an AI tool, such as Claude Code or Codex, that does more than suggest a line: it reads your project, edits several files, runs commands and often prepares a commit or a pull request on its own. That speed is the point, and also the risk. An agent can change twenty files in the time it takes you to read one, and its code usually looks clean whether or not it is correct.

So the review has to be deliberate. The good news is that you don't need to read every line with equal care. You need an order: look at what changed before how it changed, and check the things that are cheap to verify before the things that need judgment.

Why confident-looking code needs a checklist

A Stanford user study found that people who wrote security-related code with an AI assistant produced significantly less secure code than people without one, and were also more likely to believe their code was secure. The assistant in that study was an early model, but the lesson about human trust carries over: polished output lowers our guard. The same researchers saw fewer vulnerabilities from participants who were more skeptical of the assistant and worked harder on their prompts. A checklist is a simple way to stay in that second group.

Anthropic's guidance for its own agent points the same way: give the agent a clear target such as tests, and have a separate session, with a fresh context, review the work rather than letting the author grade itself.

The four-part review checklist

Only after these four pass is it worth reading the logic in detail: error handling, edge cases, naming and whether the approach fits the rest of the project.

A worked example in commands

Say an agent worked on a branch called agent/fix-login to fix a login bug. From the project folder, in a terminal:

# 1. Scope: which files changed, and how much?
git diff --stat main...agent/fix-login

# 2. Tests: what happened to the test files? Then run them yourself.
git diff main...agent/fix-login -- tests/
git switch agent/fix-login && npm test

# 3. Secrets: any likely credentials in the added lines?
git diff main...agent/fix-login | grep -inE '^\+.*(api[_-]?key|secret|token|password)'

# 4. Dependencies: did the package list change?
git diff main...agent/fix-login -- package.json package-lock.json
npm view some-new-package name version repository   # repeat for each new name

What to look for in the output:

• Scope. A login fix that touches the payment module or rewrites a configuration file deserves a question before anything else.
• Tests. Deleted assertions, a test marked "skip", or a test edited to expect the buggy output are red flags. A test that passes in the agent's report but fails on your machine means you were reading a story, not a result.
• Secrets. Any hit needs a human look. If a real key was committed, removing it in a later commit is not enough; treat the key as exposed and replace it.
• Dependencies. For each new package, confirm it exists in the official registry, has a real repository and history, and that the name is exactly the one you meant.

You can also hand the diff to a second agent session with a narrow brief:

You are reviewing a pull request written by another AI agent. Do not fix anything.
Task it was given: "Fix the login error when the email has capital letters."
1. List every changed file that is not needed for that task.
2. List any test that was deleted, skipped or changed to expect different output.
3. List any new dependency and any string that looks like a credential.
4. Name the two riskiest lines of logic and explain why.
Answer as a numbered list. Say "none found" when a section is empty.

What do agents most often get wrong?

The most common problem is scope creep: the agent fixes the bug and also "improves" nearby code, renames things or reformats files. Each extra change is a place for a new bug to hide, and it makes the real fix harder to review. Ask for small tasks, and say in your instructions which files are in bounds.

Second is tests that prove nothing. Under pressure to make tests pass, an agent may edit the test instead of the code, or replace real behavior with a stand-in called a mock. Anthropic suggests telling the agent explicitly not to modify the tests once you have approved them, and committing those tests first so any change shows up in the diff.

Third is invented or risky dependencies. Researchers who generated 576,000 code samples with 16 models found that, on average, at least 5.2% of the packages suggested by commercial models and 21.7% by open-source models did not exist. These are called package hallucinations, and they are dangerous because an attacker can publish malicious code under a name models tend to invent. Never install a package an agent named without checking it.

Finally, watch for quiet weaknesses: missing error handling, secrets read from the wrong place, and input that is trusted without checks. None of these looks wrong at a glance, which is exactly why the checklist comes before the reading.