How to Review AI-Generated Code: A Checklist That Catches Real Bugs

AI coding assistants have changed the economics of writing code. They have not changed the economics of being responsible for it. In the Stack Overflow 2026 survey, nearly half of developers said they trust AI output when they can verify it easily, and only 6.6% would trust it for important decisions. That gap is where your job now sits: reviewing is the skill that scales.

Here is a checklist for doing it properly.

Why AI code needs its own kind of review#

Human mistakes tend to be obvious: typos, missed cases, inconsistent style. AI mistakes are different:

• Fluent and confident. Wrong code looks right, with tidy names and comments.
• Plausible inventions. It may call a function or flag that doesn't exist, or use an API from the wrong version.
• Local correctness, global blindness. It solves the snippet in front of it without knowing your conventions, your data, or the other module that already does this.
• It tends to say yes. It will implement what you asked even when the request was a bad idea.

A 2025 randomized trial from METR found experienced developers took 19% longer with AI tools while believing they were faster. A small study of early tools, so not a verdict, but it is a reminder that review time is easy to underestimate.

The checklist#

1. Do you understand every line?#

If you can't explain it, don't merge it. Ask the assistant to explain parts you don't follow, then check the explanation against the documentation, not against the assistant.

2. Does everything it references actually exist?#

Check imports, function names, config keys and CLI flags. Hallucinated APIs are the classic failure, and the compiler or type checker catches many of them, so run both before reading closely.

3. Is it the right version of the right library?#

Models learn from older code. Look for deprecated calls and patterns from a previous major version. For frameworks that change quickly, compare against the current documentation.

4. What happens on the unhappy path?#

Look at the code for:

• Empty input, null, huge input, unicode
• Network failure, timeouts, partial responses
• Concurrent calls and duplicate submissions
• Off-by-one errors in loops, pagination and date ranges

Generated code usually handles the example case well and the rest poorly.

5. Security, always#

• Input handling. Is user input validated? Is any of it concatenated into SQL, a shell command or a file path?
• Authorization. Does every route check that this user may touch this record, not just that someone is logged in?
• Secrets. Nothing hard-coded, nothing logged.
• Dependencies. Did it add a package? Confirm it is real, maintained and the right name, since typo-squatted packages are a known supply chain attack.

# What to catch
query = f"SELECT * FROM users WHERE email = '{email}'"        # injectable

# What to want
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

6. Does it fit the codebase?#

Is there already a helper for this? Does it follow your error handling, naming and folder structure? Duplicated logic is common in AI-written code because the model didn't see the existing function.

7. Are the tests real?#

Be suspicious of tests the assistant wrote for its own code. Check that they:

• Fail when you break the behaviour (change the code and see)
• Assert on outcomes, not on the implementation
• Cover the edge cases from step 4

A test that always passes gives false confidence, which is worse than no test.

8. Is the change the right size?#

Assistants like to rewrite more than you asked, renaming things and reformatting files. Keep diffs small and focused. If a change touches twenty files, split it.

9. Run it#

Don't review by reading alone. Run the code, hit the endpoint, open the page, try to break it. Reproduce the original bug before you trust the fix, then check it is gone.

Habits that make review easier#

• Ask for small steps. One function or one change at a time is far easier to check than a whole feature.
• Write the test first. Give the assistant a failing test and let it make it pass.
• Put your conventions in writing. A short project instructions file listing your stack, style and don'ts improves output and makes review quicker.
• Own the commit. Your name is on it. "The AI wrote it" is not an excuse a production incident accepts.

The takeaway#

Producing code is getting cheap. Knowing whether it is correct, safe and fits the system is not, and it is increasingly where a developer's judgement is worth paying for. A good reviewer with an AI assistant is faster than either alone. A careless one just ships more bugs, sooner.

Sources#

• Stack Overflow survey finds developers wary of AI tools (IT Brief)
• METR's study on how AI affects developer productivity (DX)