How to Review AI-Written Code

Why AI-written code needs its own review habits

AI-written code fails differently from human code: it is fluent, consistent in style and often wrong in ways that look right. It rarely has typos. It does invent function names, quietly change behavior you didn’t ask about, and handle the happy path well while skipping the edge cases. You’re accountable for anything you merge, whoever or whatever wrote it.

The review checklist

1. Does it solve the problem you actually asked about?

Read the task, then read the diff, before reading the code in detail. Check that every changed file belongs to the task. Agents sometimes “improve” unrelated code, rename things or reformat files, which hides the real change and adds risk. Ask for unrelated changes to be reverted.

2. Run the tests yourself

Don’t accept “all tests pass” as a claim; run them. Then check the tests themselves:

• Do new tests fail without the change? A test that passes either way proves nothing.
• Did the AI weaken, skip or delete existing tests to make them pass? Look for removed assertions, new skip markers and loosened expected values.
• Are edge cases covered: empty input, very large input, invalid input, concurrent access, time zones?

3. Check that every API, option and package exists

Assume nothing the model mentions exists until you’ve seen it in the official docs or the type checker accepts it. Models produce plausible method names, configuration options and parameters from older versions.

New dependencies need extra care. Research on code-generating models has found they frequently suggest package names that don’t exist, and attackers can register those names. Before adding any new package:

• confirm it’s the package you think it is, on the official registry, from the expected publisher
• check its age, maintenance and download history
• ask whether you need it at all; a few lines of code can be safer than a dependency

4. Look hard at security

Give security-relevant code a slower, line-by-line read. Focus on:

• Input handling: SQL built with string formatting, shell commands built from user input, unescaped HTML, path traversal in file names
• Authentication and authorization: checks that are missing on new endpoints, or that check the wrong user
• Secrets: keys hard-coded “for now”, secrets written to logs, overly broad file permissions
• Cryptography: home-made crypto, weak randomness for tokens, disabled certificate checks

The OWASP ASVS is a good checklist for what “secure” means in a web application. Run your usual static analysis and dependency scanning on AI-written code exactly as on human code.

5. Read the error handling and logging

Check what happens when things go wrong, not just when they go right. AI code often catches exceptions broadly and carries on, returns default values that hide failures, or logs too little to debug and too much to be safe (personal data, tokens).

6. Keep diffs small enough to read

If you can’t review the whole diff carefully in one sitting, it’s too big. Ask the assistant to split the work into a sequence of small changes, each with its own tests and commit. Small diffs are where review actually catches problems.

7. Make sure you understand it

Don’t merge code you couldn’t explain to a colleague. Ask the assistant to explain any part you don’t follow, then check the explanation against the code and docs. If it’s still unclear, rewrite it in a form you do understand.

Make the AI do part of the review

Use the assistant to review its own work, but don’t let that replace your review. Useful prompts:

• “List every assumption you made that isn’t stated in the task.”
• “What inputs would break this code? Write tests for them.”
• “Review this diff for security issues against the OWASP Top 10. Quote the lines.”
• “Which changes in this diff aren’t required for the task?”

Put your team’s review expectations in your project rules file, for example “Bug fixes must include a test that fails before the fix”, so the assistant meets them before you start reading.