A practical checklist for reviewing AI-generated code

Generated code fails differently

Code from an assistant is usually readable, well named and superficially correct. That is exactly why it slips through review: it looks like the work of someone careful. The failures are not in the syntax, they are in the assumptions — a function that handles the happy path beautifully and silently returns null for everything else.

The practical consequence is that you should not review generated code the way you review a colleague's. Read it for what is missing rather than what is wrong. The five-minute scan below finds most of it.

The patterns worth searching for

These are the recurring defects. A text search finds them faster than a careful read, and a search does not get tired.

• Credentials in source: api keys, tokens and passwords assigned to a literal. Rotate anything you find, even in a private repository.
• eval, new Function and innerHTML: three ways to turn a string into executable behaviour. Generated code reaches for them to avoid writing a parser.
• Silent failure: empty catch blocks and bare except clauses that swallow an error and return a default.
• Unbalanced or truncated output: the model stopped mid-function. Count your brackets before you count your blessings.
• Loose equality and truthiness checks: == where === was meant, and if (value) where value could legitimately be 0.
• Copy-paste duplication: the same twelve lines twice, with one character changed. Extract it or one copy will rot.
• Debug residue: console.log, debugger, TODO and FIXME markers that were scaffolding for the model, not for you.
• Untrusted HTTP: a hardcoded http:// endpoint that will be blocked as mixed content, or worse, silently accepted.
• Plausible but invented APIs: a method that does not exist on the library version you actually have. Check imports resolve.
• Over-broad error handling: catch (e) { return true } is a bug pretending to be resilience.
• Comments that restate the code instead of explaining the decision — a sign the shape was guessed, not chosen.

Read the boundary, not the body

The highest-value review minutes are spent at the edges of a function: where input arrives, where a promise resolves, where a network call fails. Generated code is strongest in the middle, where the logic is linear, and weakest at the boundaries, where the real world intrudes.

Ask three questions of every function you did not write yourself: what happens if this argument is undefined, what happens if this request times out, and who else calls this. If the code cannot answer all three, it is not finished.

When it is worth a specialist

Anything that touches authentication, payment, personal data or a shell deserves a reviewer who does that work professionally. The reason is not that automation is weak — it is that the cost of a miss is asymmetric. One leaked key outweighs a month of clean deploys.

For everything else, the checklist above plus a run through the offline console will get you to a defensible place. Ship it, and keep the report.