Code review evolved around two assumptions: the author can explain why they did it that way, and producing the change cost them something. Agent-written code breaks both, and most review processes have not noticed.
Short answer: the defects move. Agent code is syntactically clean, idiomatic and confident, so the classic review signals (sloppiness, obvious confusion, weird formatting) stop firing. What you get instead is code that is locally correct and globally wrong: duplicated helpers, invented conventions, hallucinated interfaces, and misread requirements delivered with total assurance. Review has to hunt for those specifically, and it has to survive ten times the volume.
What changes about the author
Three things, and each breaks a different part of the process.
They cannot explain the reasoning. “Why did you do it this way?” is the most useful question in code review and there is nobody to ask. You can ask the agent, and it will generate a plausible justification for a decision it may have made for no reason at all. That answer is not evidence. Treating it as evidence is the single most common mistake teams make here.
The cost of production is near zero. A human writing two thousand lines thought about it for a day. An agent writing two thousand lines thought about it for ninety seconds. The implicit signal that volume equals consideration is gone, and with it the reviewer’s instinct that a large change deserves a large amount of care from someone.
They do not learn from the review. Reviewing a colleague’s work compounds: they internalise it. Reviewing an agent’s work does not, unless the correction lands in an instruction file. Any correction you make only in a comment thread will be made again next week.
Where the defects actually cluster
This is the part worth internalising, because it redirects where you look.
Duplication. By a distance the most common. The agent writes a date formatter, a retry wrapper, a validation helper, all of which already exist two directories away. It did not look, or it looked and the search did not surface them. Individually harmless, collectively how a codebase turns into six ways of doing one thing.
Invented conventions. It picks a naming scheme, an error style, a file layout, on the spot, differently each session. Every one looks reasonable in isolation. The result is a codebase with no consistent voice.
Confidently wrong interfaces. A method that does not exist on that library, a config key that was never valid, an argument order from an older major version. This has improved but it has not gone away, and it looks exactly like correct code.
Misread requirements. The most expensive category. The change is well written, well tested, and solves a slightly different problem than the one you described. The tests pass because the agent wrote tests for what it built.
Ignored edge cases at the boundary. Empty input, concurrent access, partial failure, the timezone. Agents do the happy path well and the corners inconsistently.
Notice what is missing from that list: syntax errors, obvious logic bugs, unformatted code. The old review targets have largely been automated away, which is exactly why reviewers who keep looking for them feel like everything is fine.
Why plausible is the failure mode
Human error is usually visible as error. Someone was confused, and the confusion shows in the code.
Agent error is fluent. The wrong thing is written in the same confident, idiomatic style as the right thing, with a sensible name and a reasonable-looking comment. There is no surface signal distinguishing “this is correct” from “this is a plausible-sounding invention”.
So the reviewer’s usual heuristic, read until something feels off, stops working. Nothing feels off. You have to check specific things deliberately rather than scanning for smells, which is slower and requires knowing what to check.
How do you review a change you did not have time to read?
Volume is the practical problem, and the answer is not to read faster.
Make the machine do the mechanical pass first. Static analysis, type checking, Semgrep rules for your own patterns, secret scanning on every diff. Anything a tool can catch should never reach a human reviewer, and this matters far more when the volume is ten times higher.
Review the diff against the requirement, not against itself. The question is not “is this good code” but “is this the change I asked for”. Read the description first, form your own idea of what should have changed, then look at what did. Divergence is the finding.
Read the tests before the implementation. Agent-written tests describe what the agent believed the requirement was. If the tests are testing the wrong thing, the implementation is wrong too, and you found it in a tenth of the time. More on this in verifying agent work.
Grep for duplication before reading anything. Take the names of new functions and search the repository. This one habit catches the most common defect in under a minute.
Insist on small diffs. The single most effective control. An agent will happily produce a two-thousand-line change; you are allowed to refuse it. Ask for the same work in six pieces and each is reviewable. The Google engineering practices guide is still correct on this and the reasoning applies with more force here.
Where to spend the attention you have
Not uniformly. Triage by consequence.
Read every line of anything touching authentication, authorisation, money, personal data, cryptography, or concurrency. The OWASP Top Ten is the standing list of what goes wrong, and agent-generated code is not immune to any of it. Where the code interacts with model input or tool output, the LLM-specific top ten is the relevant reference.
Skim, verify by test for pure refactors, mechanical renames, and anything with strong type coverage where the compiler is doing the checking.
Read the interface, trust the body for well-tested pure functions. Check the signature and the tests, spot-check the implementation.
That allocation is defensible and it is what people do implicitly anyway. Making it explicit means the high-consequence code actually gets the attention instead of being averaged in with the boilerplate.
Feed the corrections back
The habit that makes all of this compound instead of repeat.
When you reject something for a reason that will recur, the fix does not go in the review comment. It goes in the instruction file, or into a lint rule, or into a test. A comment corrects one change. A rule corrects every future change.
The rough test: if you have made the same review comment twice, you have found a missing rule, not a bad change.
The honest position
Agents raise the floor and they do not raise the ceiling. Boilerplate, mechanical refactors and well-specified changes come out better and faster than most people would produce by hand. Subtle, high-consequence, context-dependent work does not, and it arrives looking exactly as confident as the easy stuff.
Review is where that difference gets caught, which means review is now the constraint rather than authoring. Teams that treat it as a formality because the code looks clean will find out the expensive way. The related decision, what infrastructure the change quietly commits you to, usually passes review unremarked: the infrastructure your agent picks for you covers why that matters more than the code does. And for the mechanics of why the agent produced what it produced, what an AI coding agent actually is.