Reviewing AI-Generated Code: A Checklist for Developers

AI assistants produce code quickly and with confidence, which makes it easy to trust them too much. Generated code deserves at least the same scrutiny as code from a new teammate, and sometimes more, because the assistant cannot explain its true intent and may not know your system. This checklist helps you review it efficiently.

First: understand the change

Before examining details, answer three questions.

What problem does this code solve?
Do I understand every line, or at least every block?
Is this the simplest approach that fits our codebase?

If you cannot explain it, do not merge it. Ask the assistant to explain, or rewrite it more simply.

1. Correctness

Does it do what the requirement says, including the unusual cases?
Check edge cases: empty input, None, zero, negative numbers, very large values, Unicode text, time zones and leap days.
Are loops and conditions right? Look for off-by-one errors.
Are return values and error paths consistent?
Does it handle failures such as network errors or missing files?
Are the library functions real? Open the official documentation for anything unfamiliar. Assistants sometimes invent parameters.

2. API versions and deprecations

Training data can lag behind current releases.

Does the code use functions that are deprecated or removed in your version?
Does it mix syntax of different versions (for example, Django 2 style URL patterns in a Django 5 project)?
Check your dependency file for pinned versions and read the release notes when in doubt.

3. Security

Security issues are among the most important things to catch.

Injection: Are SQL queries built with string concatenation? Use parameterised queries or the ORM.
Cross-site scripting: Is user input escaped when rendered in templates?
Authentication and authorisation: Does each endpoint verify who the user is and what they may access?
Secrets: Are keys, passwords or tokens hard-coded?
File handling: Are upload names, paths and types validated?
Unsafe functions: eval, exec, pickle on untrusted data, shell commands with user input.
Cryptography: Is the algorithm appropriate? Avoid home-made crypto and weak hashes for passwords.
Dependencies: Are new packages necessary, maintained and trustworthy? Beware of non-existent package names suggested by an assistant, which attackers can register ("package hallucination").

Example of a common problem and its fix:

# Risky: user input placed directly in SQL
cursor.execute(f"SELECT * FROM users WHERE email = '{email}'")

# Safer: parameterised query
cursor.execute("SELECT * FROM users WHERE email = %s", [email])

4. Performance and resources

Are there database queries inside loops (the N+1 problem)?
Is the algorithm efficient for expected data sizes?
Are files, connections and sessions closed properly?
Is caching used sensibly, without stale data risks?
Does the code load everything into memory when streaming would be better?

5. Readability and design

Are names clear and consistent with the codebase?
Is the function doing one thing?
Is there duplicated logic that already exists in a helper?
Does it follow your project's structure and style guide?
Are comments useful, or just restating the code?
Is it over-engineered, with unnecessary abstraction or configuration?

6. Tests

Do tests exist for new behaviour, including failure cases?
Do the tests really assert something, or only run the code?
Would the tests fail if the code were broken? Try changing the implementation slightly and see.
Are test data and mocks realistic?

Generated tests often cover only the happy path, so add cases yourself.

7. Licensing and ownership

Does the snippet look copied from an open-source project? Search for distinctive lines.
Is your use compatible with the licence of the code and your project's policy?
Does your company allow AI tools and have rules about disclosing their use?

8. Data privacy

Does the code log personal data or secrets?
Does it send data to third-party services without consent?
Are retention and deletion handled?

A quick review routine

Read the description and the diff once without running anything.
Run the code and tests locally.
Try to break it with unusual input.
Go through the checklist above for the relevant items.
Ask the assistant to critique its own solution: "List possible bugs, security issues and edge cases in this code." This is a useful second opinion, not a substitute for your review.
Simplify and format using your linter and formatter.

Automating part of the checklist

Tools catch many issues faster than eyes:

# Python example
ruff check .            # linting and common bug patterns
black --check .         # formatting
mypy .                  # type checking
bandit -r app/          # security scanner
pip-audit               # known vulnerable dependencies
pytest -q               # tests

Add these to your continuous integration pipeline so every change, human or AI-written, passes the same gates.

Culture and process

Treat AI as a junior contributor: fast, tireless and in need of review. Agree in your team on when AI use is allowed, whether to mark AI-assisted commits and how much review they need. Keep responsibility clear: the person who commits the code owns it.

Frequently Asked Questions

Is AI-generated code less reliable than human code?

Not always, but its errors can be subtle and confident. It needs the same testing and review as any code.

Should I tell my team when code was AI-assisted?

Follow your team's policy. Transparency helps reviewers focus on the right risks.

Can another AI review the code?

It can catch some issues, but it can share the same blind spots. Use it as an extra check, not the final one.

What is the most common problem?

Plausible but wrong details: invented functions, outdated APIs, missing edge cases and insecure shortcuts.

Conclusion

Review AI-generated code for correctness, API accuracy, security, performance, readability, tests and licensing. Automate what you can, verify what matters and remember that you remain responsible for every line you ship.