A Review Checklist for AI-Generated Pull Requests

AI coding assistants are now good enough that a pull request can arrive looking finished: tests included, a confident description, and a diff that compiles. That appearance is why these PRs need a slightly different review than one written slowly by a teammate who already knows the codebase.

The assistant does not know which shortcuts your team has already rejected, or which "small cleanup" will break a caller two repositories away. It will invent a helper that already exists, or paper over an edge case with a retry. That is not a reason to ban the tools. It is a reason to review the output as you would a fast, well-meaning contributor who has only just arrived.

1. Start with the problem, not the diff

Read the ticket or the pull request description first and write down, in a sentence, what should be true when this ships. Then skim the diff with that sentence in mind.

AI-generated changes often solve a slightly different problem than the one you asked for. The code may be tidy and the tests green, and still the behaviour you needed is only half there: the happy path works, the migration only covers new rows, or the API accepts a case the ticket said to reject. If you start with style and naming, you will spend your attention on the wrong layer.

If the description is vague ("improve error handling"), ask the author to restate the intended behaviour before you go further. That is cheaper than debugging a polished solution to the wrong brief.

2. Check that the change is as small as it claims

Assistants like to be helpful. A request to fix a null check sometimes comes back with a renamed module, a new utility file, and a formatting pass over a file that was not involved.

Ask:

• Does every file in the diff serve the stated problem?
• Are there refactors, dependency bumps or generated lockfile changes that were not requested?
• If the assistant added a new helper, does the same helper already exist in the project?

Anything extra should be removed or split into a separate pull request. Scope creep is harder to review and harder to revert.

3. Look for invented APIs, ignored conventions, and copied patterns that do not belong

This is the distinctive failure mode. Models will happily call a method that exists in a popular library but not in your version, import a package you do not use, or follow a folder layout from a tutorial.

Search the diff for new imports (and whether those packages are already in the project at the versions you expect); endpoints, environment variables and feature flags that are not already documented; logging, error types and naming that do not match neighbouring code; and comments that explain something obvious, or that describe code the assistant did not actually write.

Open the surrounding files, not only the changed lines. An assistant often matches the prompt snippet and misses the conventions three functions down.

4. Test the edges the assistant probably skipped

Green unit tests in an AI-generated PR are a weak signal on their own. Assistants are good at writing tests that confirm the code they just wrote, including the same mistaken assumption in both.

For each change, list the cases you would have tested by hand: empty input, a permission failure, a timeout, a concurrent update, a record already in a terminal state. Run those, even if only as a short manual script or one extra test during review.

Pay attention to error paths and to anything that touches money, personal data, or deletions. Assistants often implement the successful path carefully and treat failure as an afterthought.

5. Read the security and data surface as if it were new

A human author is usually cautious about logging request bodies or putting secrets in a test fixture, because they have been burned. An assistant does not have that memory.

Check for secrets, tokens or production data in tests and fixtures; new endpoints or jobs without the same authentication as their neighbours; user input that now reaches a shell, a query, a prompt, or a file path without the usual validation; and logs that might now include personal data.

This is also the moment to decide whether a dedicated AI code review tool belongs in the pipeline at all. Some are useful on large diffs, but they have the same blind spots as the assistant that wrote the code: they can miss context, and they can flood the PR with low-value comments. If you are comparing options, start from a shortlist and run the tool against a repository where you already know the bugs, rather than trusting a vendor demo. This comparison of AI code review tools is a reasonable place to build that shortlist. A bot review is a supplement to this checklist, not a replacement for it.

6. Require an author who can explain the change

The pull request should have a named human author, even if an assistant wrote most of the diff. That person should be able to explain why the approach was taken, what they verified, and what they left out.

If the author cannot walk you through the change without re-reading the diff line by line, it is not ready. Ask them to spend another pass: tighten the scope, add the missing tests, and describe the behaviour, risk and how it was checked.

The short version

Before you approve: confirm the PR solves the stated problem; cut anything outside that scope; check for invented APIs and missed conventions; test the edges yourself; read the security and data surface; and only approve when a human author can explain the change. The assistant can save hours of typing. It cannot take responsibility for what you merge.