Reviewing a teammate's code and reviewing an agent's code look similar and are not. The agent fails in different places, never argues back, and can hand you a thousand lines before lunch.
TL;DR
- Agents fail differently from humans — fluent, confident, and wrong in subtle ways.
- Volume goes up; your review process has to scale without rubber-stamping.
- Review the spec and the tests as hard as the code.
- The reviewer is now the primary quality gate, not a second opinion.
How agent code fails differently
Human reviewers built their instincts on human mistakes. Agents break those instincts:
- It looks right. Agent code is syntactically clean and idiomatic, which lulls reviewers into skimming. The bugs hide in logic and context, not style.
- It is confidently wrong. An agent does not signal uncertainty the way a junior dev's tentative PR does. Wrong and right look equally assured.
- It invents. Plausible-but-nonexistent APIs, subtly misremembered semantics, edge cases silently ignored.
- It does not push back. A human who finds your spec ambiguous asks. An agent guesses and moves on — so the ambiguity surfaces as a defect in review, not a question before.
The danger of agent code is not that it looks bad. It is that it looks great and is wrong underneath.
What to actually review
Shift attention to where agent code breaks:
- Logic and edge cases, not formatting. The compiler and linter handle style; you handle correctness.
- The boundaries. Empty inputs, failures, limits, concurrency — the places agents quietly assume the happy path.
- Fit with the system. Does it use the existing patterns, or reinvent them? Agents reach for generic solutions over your conventions.
- The claims. Does this API exist? Does this function behave the way the code assumes? Verify, do not trust.
Review the spec and the tests too
If an agent built from a spec, the spec is upstream of the code's correctness — a vague spec produces a confidently wrong implementation. Review it. And scrutinize agent-written tests especially hard: an agent can write tests that pass by asserting the wrong behavior, giving you false confidence. Tests that merely mirror the implementation prove nothing.
Scaling review without rubber-stamping
Volume is the trap. When an agent produces ten PRs a day, the temptation is to skim and approve. Defenses:
- Keep changes small and single-purpose so each is genuinely reviewable.
- Automate the mechanical checks — lint, types, tests, security scans — so human attention goes to judgment.
- Use a second agent for a first pass, but never as the final gate. AI review catches some classes of issue and misses others; it does not absolve the human.
The reviewer's new seniority
Code review used to be a second opinion on work a human already vetted by writing it. With an agent author, the reviewer is the quality gate — often the first human to think hard about whether the change is correct. That makes review one of the highest-leverage activities on the team, and review skill one of the most valuable things an engineer can have.
Slow down on the review even as the agent speeds up the writing. That is where correctness now lives.