Review AI-Generated Code with a Checklist of What It Usually Gets Wrong

A practical approach

Step 1

Read the diff, not the chat summary. Check that every changed file belongs to the task and revert unrelated edits.

Step 2

Verify every external API, method and configuration option against the documentation for the version in your lock file.

Step 3

Check failure paths: invalid input, network errors, empty results, timeouts and permission failures.

Step 4

Look for security issues common in generated code: string-built SQL, missing authorisation checks, secrets in code and unsafe deserialisation.

Step 5

Run the tests, then read the tests: confirm they would fail if the feature were broken rather than simply mirroring the implementation.

Worked example

An assistant generates a file-upload endpoint that works in a quick manual test. Review with the checklist finds that it trusts the file extension from the client, writes uploads to a path built from the original filename and has no size limit. It also edited the shared logging configuration. Reverting the logging change, validating content type, generating server-side filenames and adding a size limit turned a demo into code that was safe to merge.

A mistake to avoid

Do not accept generated tests as proof of correctness without reading them. Tests written by the same assistant often assert what the code currently does, including its bugs, rather than what the feature should do.

Try it yourself

Take a recent AI-assisted change in your project and review it again with the five checks above. Note which category produced the most issues, and add that check to your team's pull-request template.

Your implementation checklist

• Every changed file belongs to the task
• External APIs are verified against the installed versions
• Failure paths and edge cases are handled
• Common security issues have been checked
• Tests would fail if the feature were broken