How to review a pull request when an AI wrote most of it

The AI produced 300 lines of code, it looks clean, the tests pass, and you’re about to hit merge. But you didn’t write it, you’re not sure you fully understand it, and “looks fine” has burned you before. Reviewing code you didn’t write is a different job than reviewing your own.

AI-generated code is confident and plausible, which is exactly the trap. Plausible is not the same as correct. Here’s how to review it properly.

Why this happens

When you review a teammate’s PR, you have context: you know they understood the ticket, you can ask them why they did something, and they’ll be around to fix it if it breaks. An AI gives you none of that. It generates code that pattern-matches to “correct-looking” without any guarantee it’s correct for your actual situation.

The specific danger is that AI code fails in ways that pass a casual look. It handles the happy path perfectly and silently drops the edge cases. It invents an API method that doesn’t exist. It adds a database query inside a loop that works fine with 10 rows and dies at 10,000. It writes an auth check that looks right and lets everyone through. None of these show up when you skim.

The tests passing doesn’t save you either, because the AI often wrote the tests too, and they test the same happy path the code handles. A green checkmark on AI-written tests for AI-written code is close to meaningless as independent verification.

So you review it like you’d review a stranger’s work: assume nothing, verify the parts that matter.

How to fix it

Don’t read the diff top to bottom hoping something jumps out. Work a checklist. Here’s one tuned for AI-generated code.

The review checklist

## Reviewing an AI-generated PR

### Understand it first
- [ ] Can I explain, in one sentence, what this change does?
- [ ] Do I understand every line, or am I trusting some of it blindly?
      (If I can't explain it, I can't review it. Ask the AI to explain,
       or rewrite the part I don't understand.)

### Security (highest priority)
- [ ] Any secrets, API keys, or passwords hardcoded in the diff?
- [ ] Are user inputs validated before use? (SQL, shell, file paths)
- [ ] Are auth/permission checks actually enforced, not just present?
- [ ] Does any endpoint expose data it shouldn't?

### Correctness beyond the happy path
- [ ] What happens with empty input? Null? A huge input?
- [ ] Are errors handled, or swallowed silently?
- [ ] Does it call any API method / function that actually exists?
      (AI invents plausible-sounding methods. Verify against real docs.)

### Data and performance
- [ ] Any database query inside a loop? (N+1 problem)
- [ ] Any query on a large table without an index?
- [ ] Could this change lose or corrupt data? (migrations, deletes)

### Fit with the codebase
- [ ] Does this duplicate logic that already exists elsewhere?
- [ ] Does it follow the patterns the rest of the code uses?
- [ ] Did it add a new dependency? Do we need it?

### Tests
- [ ] Do the tests check failure cases, or only the happy path?
- [ ] If the AI wrote both code and tests, did I add one test myself?

How to actually run it

Read the code before you read the description. The AI’s PR description tells you what it thinks it did. Read the diff first and form your own view, then compare. If they don’t match, that gap is where the bug lives.

Verify invented APIs. The fastest AI failure to catch: it calls a method that sounds real but isn’t. If the diff uses a library function you don’t recognize, check it exists in that library’s actual docs. This alone catches a surprising number of “why doesn’t this run” problems.

Trace one real request through the change. Pick a concrete example. A user with an empty cart. A signup with an email that already exists. Walk it through the new code by hand. AI code loves the main case and forgets the awkward ones.

Hunt for the silent catch. Search the diff for error handling that swallows problems:

# find catch blocks that do nothing useful
git diff main | grep -A2 'catch'

An empty catch {} or one that just logs and continues is often the AI hiding a failure it didn’t know how to handle. Those turn into “it just stopped working and there’s nothing in the logs” later.

Check the database queries. If the change touches the database, look for the two classic performance killers: a query inside a loop, and a query filtering on a column with no index. Both work fine in testing and fall over under real load.

Write one test yourself. If the AI wrote the code and the tests, add a single test for a case you think it might have missed: an edge case, a failure path, a weird input. Your independent test is worth more than ten the AI wrote to pass its own code.

The honest shortcut

You won’t run the full checklist on every one-line change. Scale it to risk. A copy tweak needs a glance. Anything touching auth, payments, user data, or database migrations gets the whole list, every time. When in doubt, treat it as high-risk, because those are the changes that hurt when they go wrong.

Or, we do it for you

A second set of experienced eyes on the changes that touch your data or your users is the cheapest bug prevention there is. If you’re merging AI-generated code with nobody reviewing it, our free audit looks at what’s already shipped and flags the risky patterns. For more on whether AI code is production-ready in the first place, see our post on Cursor AI-generated code in production.

FAQ

Can’t I just trust the AI if the tests pass?

Not when the AI wrote the tests. It tends to test the same happy path its code handles, so a green checkmark confirms the code does what the AI intended, not what you need. Passing tests are a signal, not proof. Add at least one test of your own for anything important.

What’s the single most important thing to check?

Security and data safety, every time. A cosmetic bug is annoying; a leaked API key, a missing auth check, or a migration that drops a column is expensive and sometimes irreversible. If you only have time for part of the checklist, do the security and data sections.

How do I review code I genuinely don’t understand?

Don’t merge it. If you can’t explain what a piece of code does, you can’t verify it’s correct, and you definitely can’t fix it when it breaks at 2am. Ask the AI to explain it line by line, simplify the part that’s too clever, or rewrite it into something you do understand. Code you don’t understand is a liability you’re signing up to own.

Does this slow me down too much to be worth it?

Scale the review to the risk. Most changes get a quick pass; the ones touching money, auth, or user data get the full checklist. Fifteen minutes of review on a risky change is far cheaper than the outage, data loss, or breach it prevents.