AI-generated code deserves the same review standards as human-written code, but it doesn't always fail in the same way. A person might leave a half-finished function and a TODO comment while an AI assistant is more likely to produce something polished, documented and completely wrong about one important aspect of design.
That polish changes the reviewer's job from only looking for broken syntax or untidy code to checking whether convincing code actually matches the system around it.
This checklist is designed for pull requests written partly or entirely with coding agents: Codex, Claude Code, Cursor, GitHub Copilot or anything else. Use it as a template, a prompt for an internal AI reviewer or a final self-review before asking a teammate for their time.
The core of it
Most AI-generated changes come down to a few passes: confirm the code solves the problem that was actually requested, verify its assumptions against real APIs and the conventions already in the repository, follow the data through the system, inspect the security and failure boundaries, and make the tests prove the behavior.
One rule sits beneath all of them: somebody on the team must be able to explain the implementation and its trade-offs without asking the generating tool. If nobody can, the team doesn't really own the change yet and can't hold responsibility for it.
1. Start with intent instead of syntax
Read the issue and pull request description before reading the diff. Write down, in one sentence, what should be true after the change.
For example:
A workspace administrator can revoke an invitation, but members of other workspaces cannot.
Now compare that sentence with the implementation. AI coding tools often solve the shape of a problem while missing some business constraints. You may get a perfectly competent “delete invitation” endpoint that checks whether the user is logged in but not whether they administer the relevant workspace.
Check the implementation against each acceptance criterion. Look for behavior that became subtly broader or narrower, requirements the agent invented and disagreements between what the interface requires and what the API actually does.
This is also why a useful pull request description matters. A diff can show what changed but it cannot reliably tell a reviewer why.
2. Verify every external fact
Language models are very good at producing code that resembles a library’s API. Unfortunately, “resembles” is doing some heavy lifting there.
Treat every newly introduced API, command-line flag, environment variable, framework option and cloud permission as a claim that needs verification. Open the documentation or source for the version installed in the repository. Confirm argument order, return types and error behavior because a method that exists in the latest documentation may not exist in the version your project actually uses.
Pay special attention to code that includes a confident explanatory comment. Confidence isn't a type check, especially for LLMs.
3. Compare it with the rest of the repository
Generated code is usually optimized for the prompt it received. Your codebase is optimized – or at least slowly negotiated – for conventions the prompt may not contain. The agent never felt the pain those conventions came from, so it rarely makes the architectural calls that only pay off years later.
To spot this, search for a similar implementation elsewhere in the repository. See how neighboring routes authenticate users, where validation normally happens, how transactions and errors are handled, and which testing helpers the project already uses. These patterns often encode constraints that were never in the agent’s prompt, and the agent can get them wrong when it can't simply copy an existing example.
Don't reject a different approach just because it's different, but make the difference deliberate. A new endpoint shouldn't introduce a second authorization system just because the AI assistant never saw the first one.
This is one reason reviewing only the diff is risky: the evidence needed to judge a change often lives in files that were not modified.
4. Trace the complete data flow
Follow one representative value from input to storage and back to output.
Suppose a change adds a timezone field. Follow it from the form through client validation, the request payload, API validation, the service layer and database, then back through serialization into the UI. Repeat the journey with the value missing and with it invalid. Generated changes often update six of those layers and still look complete during a happy-path demo.
As you trace it, watch for an old field name surviving in one layer, optional values becoming accidentally required, units changing and serialization dropping information.
5. Review security boundaries explicitly
Don't stop at "is this user authenticated?" Ask, "is this user allowed to perform this action on this specific resource?" Put the same instruction in AGENTS.md or other project context so the coding agent checks it too.
For every important read or write, identify the actor, the resource, its owning tenant and the permission required to touch it. In my experience, most authorization bugs become obvious once one of those relationships has no enforcement point.
Generated code isn't inherently insecure. It's just very good at repeating insecure patterns with clean formatting.
6. Attack the failure paths
The happy path is usually the part AI agents handle best. Spend your review time where things go wrong.
Walk through one inconvenient scenario instead of trying to think about every possible disaster at once. What happens if a database write succeeds but the following API call fails? Then consider atomicity, concurrency, timeouts and retries: can two requests update the same record, or can a queue deliver the same side effect twice? Empty, duplicated and unexpectedly large results are also productive tests because they expose assumptions hidden by normal data.
These are just examples of paths you can explore. The instinct for them usually comes with experience, but it's worth starting early.
7. Make tests prove something
Generated tests can be impressive: many mocks, long names, everything green and very little evidence that it actually adds reliability to your system.
A useful test should fail for the bug it claims to prevent. Temporarily reverse or remove the relevant implementation condition. If the test stays green, it isn't telling you anything.
A test should show that an unauthorized user is rejected, that validation prevents a write, that a retry can't create a second charge, or that a migration preserves existing values. Those assertions survive refactoring because they describe what the system promises, not how it happens to be implemented.
8. Remove generated clutter
AI assistants often leave comments that restate the next line, one-use abstractions that complicate the code and broad try/catch blocks that hide useful failures. They may also duplicate validation or add a dependency for a few lines of ordinary code.
Remove anything that doesn't improve correctness, clarity or maintainability. The goal isn't to hide that AI helped write the change, but to leave the codebase better than it was before.
A reusable PR checklist
Paste this compact version into your repository’s pull request template, or build a stack-specific one with the code review checklist generator:
### AI-generated code review
- [ ] I can explain the implementation and its trade-offs.
- [ ] I verified new APIs and configuration against the installed versions.
- [ ] I compared the change with existing repository patterns.
- [ ] I traced inputs, outputs and side effects across all affected layers.
- [ ] I checked authorization and tenant boundaries.
- [ ] I tested failure paths and edge cases, not only the happy path.
- [ ] Tests fail when the behavior they protect is broken.
- [ ] No secrets or sensitive data are exposed in logs or errors.
- [ ] New dependencies, migrations and generated comments are necessary.Go deeper on the risky parts
Use the focused guides when one part of the change needs more than a checklist:
- Review security risks in AI-generated code for authorization, injection, secrets, dependencies and infrastructure changes.
- Review a vibe-coded pull request when the change is broad and the author needs to recover its intent.
- Check AI-generated tests for weak assertions, over-mocking and shared assumptions.
- Split a large AI-generated pull request into changes a reviewer can understand and revert.
- Set up independent AI code review when a model or coding agent wrote the implementation.
The reviewer still owns the merge
AI can write code, propose tests and perform a useful first review. It can't accept responsibility for the result. The person approving the pull request remains the final boundary between plausible code and production code.
Use this checklist to make that responsibility manageable, not ceremonial. For the next step, set up a GitHub pull request review workflow with AI, learn how AI code review differs from static analysis, or create repository-specific checks with natural-language code review rules.