Agent code fails differently from human code: it is plausible rather than confused, it deletes guards quietly, it invents APIs that should exist, and it weakens tests to make them pass. The review that catches those things starts with the file list, reads the deletions before the additions, diffs test files separately, and runs the tests rather than accepting the claim. Machine reviewers help and do not substitute, because they cannot know what you intended. If the diff is too large to read, the task was too large.
- Agent mistakes are plausible, not obviously wrong. That is what makes them dangerous.
- Review deletions first. They get the least attention and cause the most regressions.
- Check that tests were not weakened to pass. A weakened assertion is a bug that disables its own alarm.
- "All tests pass" is a claim. Run them.
- Machine review catches real defects and cannot know your intent. Use both.
- If the diff is too large to review, the task was too large.
How generated code fails differently
Your instincts about where to look harder were trained on human code. They fire on signals of confusion: an odd name, a hedging comment, an inconsistent style. Generated code has none of those, whether or not it is correct.
| Failure | What it looks like | How to catch it |
|---|---|---|
| Plausible but wrong | Idiomatic, well named, subtly incorrect | Read the logic, not the style |
| Silent deletion | An edge case or guard quietly removed | Review the minus lines first |
| Invented API | A method that should exist and does not | Run it; the compiler often catches this |
| Weakened test | An assertion loosened so it passes | Diff the test file specifically |
| Scope creep | Nine files touched for a two-file task | Check the file list before the content |
| Confident wrong explanation | A rationale that sounds authoritative | Verify the claim, not the tone |
| Duplicated instead of reused | A near-copy of a helper it did not find | Grep for the function name it should have called |
The review pass, in seven steps
This ordering is deliberate. The cheapest, highest-yield checks come first, and each one can send you back to the agent before you have spent attention on the rest.
Look at the file list before the content
Anything you did not expect is scope creep, and scope creep is where unreviewed changes hide. A two-file task that touched nine files is a finding on its own, before you have read a single line.
git diff --stat main...HEADRead the deletions
This is the highest-yield step and the one most often skipped. An agent removing an edge-case guard produces a diff that reads like a simplification and behaves like a bug.
git diff main...HEAD | grep '^-' | grep -v '^---'
git diff --diff-filter=D --name-only main...HEADDiff the test files separately
Implementation and tests changing in the same commit is normal. Assertions getting looser is not. Read this diff on its own so a loosened assertion cannot hide next to fifty lines of legitimate implementation.
git diff main...HEAD -- '*test*' '*spec*'Run the tests yourself
Do not accept the claim. "All tests pass" is a sentence the agent wrote, and it is generated by the same process that generated the code. Run the suite, and check that the count went up rather than sideways.
Check the error paths
Agents write happy paths well and error handling inconsistently. Look specifically at what happens when the thing being called fails: is the error swallowed, wrapped, logged, or returned? This is where a plausible-looking change most often diverges from your conventions.
Verify one factual claim from the explanation
Pick one assertion in the summary the agent wrote and check it against the code. If it is wrong, read everything else much more carefully; a confident wrong explanation and confident wrong code come from the same place.
Ask why, once
Ask why it chose this approach over the obvious alternative. A specific answer that names a constraint is a good sign. A vague answer usually means vague code, and it is cheaper to find that out now than after the merge.
The volume problem
An agent can produce more code in ten minutes than you can review carefully in an hour. That asymmetry is the central practical difficulty of the whole field, and no amount of review technique solves it.
Fixes, in order of effectiveness.
| Fix | Effect |
|---|---|
| Smaller tasks | The actual fix. Everything else is mitigation |
| Agent commits in pieces | Review per commit, not per session |
| Plan mode first | Wrong approaches never reach the diff |
| Constraint clauses in prompts | Prevents scope creep at source |
| A machine reviewer | Catches real defects; not a substitute for intent |
| One session per worktree | Each diff stays scoped to one branch and one intention |
Machine review: what it catches, what it cannot
A second agent with read-only tools, a fresh context, and instructions to be sceptical catches real things, because it has no investment in the approach and no memory of having argued for it. This is now a shipped product surface rather than a trick, which makes the tradeoffs concrete.
Locally, before you push
Claude Code ships /code-review (with /review as an alias) which reviews your branch commits ahead of upstream plus uncommitted changes. As of August 2026 it runs as a background subagent with its own context window, so it does not fill your conversation, and it takes --fix to apply findings or --comment to post them inline on a pull request. Codex ships /review, which starts a dedicated reviewer over a chosen diff, takes a --base ref to pick the comparison point, and reports findings without touching your working tree. Effort levels trade coverage against confidence: at low and medium the reviewer reports only what it is most confident in, which is the setting you want when false positives cost you a round trip.
On the pull request
Anthropic managed Code Review runs a fleet of agents over the diff in the context of the full codebase, then runs a verification step that checks candidate findings against actual code behaviour to filter false positives. Findings are tagged Important, Nit, or Pre-existing, and posted as inline comments. Two design decisions are worth copying whatever tool you use.
- The check run always completes neutral, so machine review never blocks a merge through branch protection. A reviewer that can block is a reviewer that gets disabled the first week it is wrong.
- It is tunable per repository through a
REVIEW.mdfile: redefine what counts as important, cap the number of nits per review, and list paths where it should say nothing. An uncapped nit stream is how a review tool becomes noise.
The cost is real and worth stating: as of August 2026 Anthropic reports each managed review averages $15 to $25 and completes in about 20 minutes, scaling with pull request size and codebase complexity. It is a research preview on Team and Enterprise subscriptions, billed through usage credits rather than against your plan allowance. Reviewing on every push multiplies that figure by the number of pushes, which is why the per-repository trigger is a budget decision rather than a preference.
What each reviewer is good at.
| Check | Machine reviewer | You |
|---|---|---|
| Null and boundary conditions | Good | Tedious |
| Removed guard clauses | Good | Good, if you look |
| Weakened assertions | Good | Good, if you diff tests separately |
| Does this do what I asked? | Cannot know | Only you |
| Is this the right approach at all? | Weak | Only you |
| Does this fit the system we are building? | Weak | Only you |
Make review structurally cheap
Review discipline decays under load. The durable fix is not more discipline, it is arranging the work so that a small diff is the default output rather than a thing you have to ask for.
- State a constraint clause in every prompt. "Do not change the public signature. Do not add a dependency." This is the single cheapest anti-scope-creep control, and it costs one line.
- Ask for commits at logical boundaries. Seven small commits are reviewable in a way that one 900-line commit is not, and
git log -pthen reads like an argument rather than a wall. - Plan before large changes. Correcting a plan costs one message. Correcting an implementation costs the run, the review, and the unwind.
- One session, one worktree, one branch. Parallel agents in one checkout produce a blended diff nobody can attribute.
- Let the machine reviewer go first. Arrive at your own read with the mechanical findings already fixed, so your attention starts on intent.
Questions people ask
Check the file list for scope creep, read the deletions first, diff the test files separately, run the tests yourself, check the error paths, verify one factual claim from the explanation, and ask why once. Style review is the least valuable part.
Because they get the least attention and cause the most regressions. An agent removing an edge-case guard produces a diff that looks like a simplification and behaves like a bug, and nothing in the added lines hints at it.
It happens, and it is one of the more damaging failure modes because the bug disables its own alarm. Always diff test files separately from implementation, and check that the assertion count went up rather than sideways.
A read-only reviewer with a fresh context catches real defects, because it has no attachment to the approach. Claude Code ships /code-review as a background subagent and Codex ships /review. Neither can know what you intended.
Anthropic reports its managed Code Review averages $15 to $25 per review and about 20 minutes, scaling with pull request size, as of August 2026. Reviewing on every push multiplies that by the number of pushes.
The task was too big. Skimmed output is unreviewed output, and you now own code nobody has read. Break the work into pieces you can actually read, and ask the agent to commit at logical boundaries.
Human mistakes come with signals of confusion: odd names, hedging comments, inconsistent style. Generated code is uniformly confident whether or not it is correct, so your instincts about where to look harder never fire.
No. Anthropic own managed reviewer always completes with a neutral conclusion so it cannot block through branch protection, which is the right default. A reviewer that can block is a reviewer that gets switched off the first week it is wrong.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.