Code review checklist for AI-generated code: what to check before you merge

AI assistants can write a function in seconds, but deciding whether that code is correct, secure and maintainable still falls to a human. This article is a practical code review checklist you can apply before merging AI-generated code. The goal is not to reject the code, but to make it something the team understands and can own.

The problem behind this list is described in our article on knowledge debt: the code exists, but nobody knows why it works the way it does. This piece complements that one. Instead of diagnosis, it gives concrete checks you can run on every pull request.

Split the PR and prove you can explain the code

An AI tool can change dozens of files in a single request. A pull request too large to review is, in practice, a pull request that was not reviewed. Start by checking the size of the change.

• One PR, one purpose. A feature, a refactor and a dependency update do not belong in the same PR.
• Separate renames and formatting from logic changes. The reviewer must be able to see the real behavior difference.
• Delete code you did not ask for. AI often adds unused helpers, extra abstractions and duplicated blocks.

The explanation test: the person opening the PR should be able to explain the code to a colleague without asking the AI. If they cannot answer these questions, the code is not merged: how does this code behave for a given input? Why was this approach chosen, and what was the alternative? What breaks if this line is removed? Someone who cannot explain the code cannot fix it when it fails in production.

Derive tests from the requirement, not from the code

AI frequently writes both the code and its tests. Those tests tend to confirm what the code does, not what the requirement asks for. You end up writing the same mistake twice. Derive tests from the requirement instead.

1. Turn the requirement into acceptance criteria: "given this input, this result is returned".
2. Write test scenarios from the acceptance criteria without reading the implementation.
3. Add edge cases: empty input, null, very large values, two simultaneous requests, an unauthorized user.
4. Prove the test can actually fail. Break the code on purpose and watch the test go red.

Green tests alone are not enough. Assertions that verify nothing and heavily mocked tests look green while giving no confidence. Ask what each test actually measures.

Check dependencies, secrets and security

When AI suggests code, it also adds packages. Every new dependency is a new risk the team takes on.

• Does the package really exist, and is it the right one? AI can suggest packages that do not exist or have look-alike names. Verify the name against the official source and do not ignore the risk of installing a malicious package through a typo.
• Check the license, maintenance status and last release date. Was a heavy dependency added for a small job?
• Is the lock file change visible in the PR, and does it match what you expect? Run a dependency scanner for known vulnerabilities.
• Is there an API key, token or password in the code, test files or sample configuration? Real values pasted into a prompt may have ended up in the code.
• Run secret scanning in pre-commit and in CI. If you suspect a key leaked, deleting it is not enough: rotate it. It stays in git history.
• Is all user input validated? Are authorization checks done on the server? Is there a concatenated query open to SQL or command injection?

For a broader list, see our vibe code to production security checklist.

Error handling, logging, performance and data integrity

AI-generated code usually works on the happy path. Problems appear on the failure path, under load and under concurrency. Review these four areas separately.

• Error handling: empty catch blocks that swallow errors, and generic messages that answer everything the same way, are not acceptable. An error must be handled or propagated. External calls need a timeout, bounded retries and a clear failure path.
• Logging: is there enough context to debug a failure (request ID, operation name)? Passwords, tokens and personal data must not be written to logs.
• Performance: look for database queries inside loops (N+1), lists without pagination, filters without an index and needless recomputation. Code that works with 10 local records will run against millions in production.
• Data integrity: are multiple writes inside one transaction? If the same request arrives twice, do duplicates appear (idempotency)? Can the migration be rolled back? Does a delete destroy data permanently?

Architecture decision records and merge criteria

AI makes architectural decisions silently: a new layer, a different state management approach, another library. To make them visible, keep a short architecture decision record (ADR): context, the decision, rejected alternatives and consequences. A few sentences are enough, and it lives permanently in the repository. Six months later, the answer to "why did we do it this way" is there.

Use these criteria for the merge decision:

1. The PR has a single purpose and a reviewable size.
2. The author can explain the code without asking the AI.
3. Tests are derived from the requirement and cover edge cases.
4. New dependencies are verified, and there are no secrets in the code or the history.
5. Error handling, logging, performance and data integrity questions have answers.
6. Any decision that affects the architecture is recorded.

If one item fails, there are three options: fix it, split it or reject it. Merging with "we will look later" moves the debt into production. In high-risk areas such as payments, authentication and personal data, require a second human reviewer.

Frequently Asked Questions

Does AI-written code need a separate code review process? No separate process is needed, but the same process should be applied more strictly. Because the author did not build the logic themselves, the explanation test and deriving tests from requirements matter even more.

Can I merge if the tests pass? No. If the tests were also written by AI, they may only confirm what the code does. Make sure the tests come from the requirement and that they actually fail when you break the code.

Can I use AI to do the code review? As a first pass, yes. It helps catch obvious mistakes and missing checks. The merge decision, however, belongs to a human who is accountable for it.

What should I do if I committed a secret by accident? Revoke the key immediately and issue a new one (rotate). Removing it from the file is not enough, because it stays in git history and in any clones. Then investigate how it leaked and add secret scanning.

If you want to prepare an AI-generated codebase for production, or build this review discipline in your team, take a look at our vibe-code-to-production service and send your situation through the quick quote form.