Generated code fails differently from hand-written code. It is rarely sloppy and often subtly wrong — plausible structure, correct-looking names, an assumption nobody stated. Our review order reflects that.
1. Does it do the thing the ticket asked for?
Not "does it look right". We read the acceptance criteria and the diff side by side. The most common defect in agent-written code is a correct implementation of a slightly different requirement.
2. What did it touch that it shouldn't have?
Renamed helpers, reformatted neighbouring files, a helpfully "improved" utility used in six other places. We check the file list before the code. Anything outside the ticket's blast radius comes out of the change.
3. Where does it fail?
Every model-written path gets read for its unhappy cases: empty results, partial data, network timeouts, a second concurrent request. Generated code is optimistic by default because most of its training examples are.
4. Can the author explain it?
The engineer who submits the diff owns it. If they cannot describe why a query is shaped that way, it does not merge. This single rule has done more for our codebases than any tooling.
We do not review generated code more leniently than hand-written code. We review it in a different order.
What we automate
Type checks, lint, the test suite and a dependency diff run before a human looks at anything. If a change adds a package, that is a conversation, not a detail.
The result
Across the projects where we tracked it, review time on agent-assisted work fell once we adopted this order, because the cheap structural problems get caught in the first two passes and never consume a senior engineer's attention.