The hard part of reviewing AI code is that it looks good. Consistent formatting, sensible names, a tidy structure. What normally signals careful work in someone else's code comes for free here.
So the usual quick heuristics stop working, and you need a different order of checks.
Boundaries first, logic second
The core logic is usually right. Defects sit at the edges:
- an empty array, an empty string, zero
- negative numbers where positive ones were assumed
- very large values and overflow
- concurrent access and repeated calls
- what happens when an external call fails
The model skips exactly these cases, because you never mentioned them.
Read the deletions as closely as the additions
Agents have a dangerous habit during refactors: quietly deleting whatever looked unnecessary. A check that seemed redundant but guarded against a rare case. Error handling that never fired in tests.
Read the deleted lines in the diff as carefully as the added ones.
Ask for a failing test before the fix
When an agent fixes a bug, the order should be this: first a test that reproduces the problem and fails, then the fix, then the same test passes.
Only that kind of proof cannot be faked with a nice explanation. Models describe their own actions very well, but a description is not a verification.
Confidence is not correctness
A model states a right answer and a wrong one with the same calm. Code carries no signal of doubt.
If the explanation sounds convincing and you never ran anything, you have not checked anything.
Keep changes small
A ten-file diff gets a worse review than five diffs of two files each. That holds for human code too, but the rule is stricter for agents: relationships between files change all at once, and they are harder to keep in your head.
Splitting the task is cheaper than untangling a large diff afterwards.
Three process rules
- The author of a change is the human who submitted it. They answer for it.
- An agent never merges on its own, whatever the settings.
- Spend is visible per key, so you can see where rework eats the budget.
The last rule sounds like a money matter, but it is really a quality metric: many iterations mean the task was framed badly.
In short
A tidy appearance proves nothing. Check the boundaries, read the deletions, require a failing test before the fix and keep changes small.