The hard part of reviewing AI code is that it looks good. Even formatting, sensible names, tidy structure. Everything that normally signals care comes free here.
So the usual fast heuristics stop working and you need a different order of checks.
Check the edges before the logic
The main logic is usually right. Defects live at the boundaries:
- empty array, empty string, zero
- negative numbers where positives were assumed
- very large values and overflow
- concurrent access and repeated invocation
- what happens when an external call fails
These are exactly the cases the model did not cover, because you did not mention them.
Look at what was deleted, not only what was added
A dangerous agent habit during refactoring is quietly dropping something that looked redundant. A check that seemed superfluous but guarded a rare case. Error handling that never fired in tests.
Read deleted lines in the diff at least as carefully as added ones.
Require a failing test before the fix
If an agent is fixing a bug, the order should be: a test that reproduces the problem and fails, then the fix, then the same test passing.
That is the one piece of evidence an explanation cannot fake. Models describe what they did very well, and a description is not a verification.
Do not mistake confidence for correctness
A model states a right answer and a wrong one with identical composure. Code carries no uncertainty signal.
If the explanation sounds convincing and you did not run it, you did not check it.
Cap the size of a change
A ten-file diff reviews worse than five two-file diffs. True of human code as well, but sharper here: relationships between files change wholesale and are harder to hold in your head.
Splitting the task is cheaper than untangling a large diff.
Three process rules
- The author of a change is the human who submitted it. They answer for it.
- Agents do not merge on their own, under any configuration.
- Spend is visible per key, so you can see where rework eats the budget.
The last one sounds financial but is really a quality metric: many iterations means the task was framed badly.
In short
A tidy appearance means nothing. Check the boundaries, read the deletions, require a failing test before the fix, and keep changes small.