Code produced by an assistant tends to clear review comfortably and then cause problems in production. The pattern is consistent, and it follows from a mismatch between what review examines and where generated code goes wrong.
Review is largely a readability check
Human reviewers assess naming, structure, adherence to convention and whether the change appears to do what its description says.
Generated code is unusually strong on all of these, because it is producing the most typical form of the pattern it was asked for.
A reviewer's usual signals for concern — inconsistent style, unclear naming, an obviously awkward construction — are absent, so attention moves on.
The defects are in unstated assumptions
What generated code gets wrong is usually contextual: which errors this particular system considers recoverable, whether a value can be absent here, what the actual concurrency guarantees are.
None of that is visible in the diff, and a reviewer who does not already hold the context will not supply it.
The code is correct for a typical system of that kind and wrong for this one, which is the hardest category of error to spot by reading.
Volume degrades review quality
Assistants produce larger changes faster, and review attention per line falls as a change grows.
A three hundred line generated change receives less scrutiny per line than a thirty line handwritten one, and it is far more likely to contain something the author did not fully consider.
The author's own confidence is also lower than it appears, since they reviewed rather than reasoned their way to the result.
Error handling is the common failure point
Generated code frequently handles the expected path well and treats failure paths generically, catching broadly and logging rather than responding.
These paths are rarely exercised in testing, so the defect survives every gate and surfaces during the incident it was supposed to contain.
Reviewers skim error handling for the same reason: it looks conventional, and conventional is what it is imitating.
The review has to change shape
The practical adjustment is to review generated changes against intent rather than against style, asking what the code assumes and whether those assumptions hold in this system.
Requiring the author to state, in the description, which behaviours they verified rather than accepted moves the burden back to where the context lives.
Smaller changes help more than any tooling, because the constraint being hit is reviewer attention, and that has not increased alongside the rate at which code is now produced.