How to Review AI-Generated Pull Requests: A 10-Step Checklist

Published 2026-11-03 · 8 min read · by AgentKit Co

An agent-written pull request usually looks finished. The code is tidy, the description is confident, and CI may be green. The problems sit in the places a quick skim skips: a test that was loosened so it passes, a permission check that disappeared during a refactor, a package nobody has heard of, a workflow file that now runs something new.

This page gives a review order that puts those places first, plus a checklist you can paste into your PR template. It was checked on 2026-11-03 against GitHub's Review AI-generated code tutorial and Copilot pull request review docs, Anthropic's Claude Code best practices and OpenAI's Codex command reference. These tools change often, so re-check anything you depend on.

1. Write down what the PR should change before you open the diff

Read the issue or your original prompt, then write one sentence: what behavior should change, and what must stay the same. GitHub's tutorial puts it as a question to ask yourself: "Does this code solve the right problem? Does it follow our conventions?"

If you can't write that sentence, the agent couldn't either. Send it back with a clearer task instead of reviewing a guess.

2. Check the size and scope first

Look at which files changed before you read any of them:

git fetch origin
git log --oneline origin/main..HEAD
git diff --stat origin/main...HEAD

On GitHub, gh pr diff <number> --name-only gives the same file list. A one-line bug fix that touched fifteen files, a lockfile and a CI config is a finding on its own. Ask the agent to split it, or to explain each file it touched.

3. Review the tests before the code

Agents are working toward a green run, and editing the test is often the shortest way to get one. GitHub's tutorial lists this under AI-specific pitfalls: "Watch for tests that are deleted or skipped, instead of fixed."

git diff origin/main...HEAD -- '*test*' '*spec*'

Look for:

• deleted test files or test cases
• new skip, xfail, .only or @Ignore markers
• expected values changed to match the new output
• assertions that got weaker, such as not.toBe(500) instead of an exact status
• mocks of the very function the test is supposed to check
• lowered coverage thresholds

If the agent wrote both the code and the tests, read one test closely and ask: would this fail if the logic were wrong?

4. Read every deleted line

Added code gets attention. Removed code often doesn't. An if that checked ownership, an early return, a throw, a WHERE clause or a rate limit can vanish because it got in the way of a passing test. Every removed guard needs a reason you agree with.

5. Check trust boundaries by hand

Don't hand these to a summary. Read them yourself:

• authentication and authorization on every new route, job, webhook or export
• ownership checks (is this user allowed to touch this record, not just this kind of record?)
• input validation and query building
• secrets, tokens or sample credentials in code, tests, logs or fixtures
• what gets logged, and whether it includes personal data

6. Verify every new dependency

GitHub's tutorial says to "check if suggested dependencies exist and are actively maintained" and to watch for "hallucinated or suspicious packages (such as packages that don't actually exist), or slopsquatting." It also says to review licenses, for example "AGPL-3.0 in a MIT licensed project."

For each new import, open the package page in the registry, check the exact name and publisher, and look at recent releases. Reject lockfile churn that the task doesn't explain.

7. Look for invented APIs and options

GitHub's list also includes "hallucinated APIs, ignored constraints, or incorrect logic." A method name that sounds right, a config option that doesn't exist, a flag from a different version of the library. If you don't recognise a call, look it up in the library's own docs before you approve. A green build doesn't prove an option does what the agent thinks it does.

8. Be careful with workflow files and CI runs

GitHub's docs say that by default, Actions workflows "will not run automatically when Copilot pushes changes to a pull request," because workflows "can be privileged and have access to sensitive secrets." They tell you to be "especially alert to any proposed changes in the .github/workflows/ directory" before clicking Approve and run workflows.

That advice applies to any agent's branch. Read changes to CI, deploy scripts, package.json scripts and pre-commit hooks before you let them run with your secrets.

9. Ask for proof, not a summary

"All tests pass" in a PR description is a claim. Anthropic's guide says to ask for "the command it ran and its output, or the screenshot," because "'All tests pass' on its own tells you very little." Look for a CI run of the relevant tests, or run them yourself:

gh pr checkout <number>
npm test   # or pytest, go test ./..., cargo test

If your repository requires approvals, note GitHub's rule for Copilot PRs: if you asked Copilot to create the PR, "your approval of a Copilot pull request won't count toward the required number. Another reviewer must approve."

10. Get a second review from something that didn't write the code

An AI reviewer is useful as a second pass, but it should start fresh. Anthropic's guide says Claude Code's /code-review "reviews the diff in a fresh subagent that never saw your conversation. It isn't swayed by the reasoning that produced the code." Other options:

Two cautions from the docs. GitHub's responsible use page says to use Copilot code review to "supplement human reviews, not to replace them," and that it "may not identify all of the problems that are present in code." Anthropic warns that "a reviewer that's asked to find problems will always find something," and adds "skip style" to its review prompt so you don't end up fixing findings that don't matter.

A read-only reviewer for Claude Code is one short file. This one is taken from Anthropic's guide:

---
name: reviewer
description: Reviews changed files against the spec they were built from. Use after implementing a feature, before opening the PR.
tools: Read, Grep, Glob
---
You're reviewing code you didn't write. Compare the changed files against the spec you're given,
check that every requirement is implemented and the listed edge cases have tests,
and report only the gaps that affect correctness. Skip style.

With only Read, Grep, Glob, it can't edit anything. Claude Code enforces that limit; it isn't just a request in the prompt. More reviewer and tester files are in our Claude Code subagent examples.

The checklist

Paste this into .github/pull_request_template.md or your review notes:

## AI-generated PR review
- [ ] I can say in one sentence what this PR should change and what it must not change
- [ ] File list matches the task (no unexplained CI, lockfile or unrelated module changes)
- [ ] Test diffs read first: no deleted cases, new skips, weakened assertions or changed expected values
- [ ] Every deleted guard, check, return or throw has a reason I agree with
- [ ] Auth, ownership and input validation checked by hand on every new or changed path
- [ ] No secrets, tokens or personal data in code, tests, fixtures or logs
- [ ] Each new dependency exists, is the intended package, is maintained and has a compatible license
- [ ] Unfamiliar APIs and options checked against the library's own docs
- [ ] Workflow, deploy and script changes read before approving CI runs
- [ ] Proof attached: CI link or command output for the relevant tests
- [ ] Second review from a reviewer (human or fresh-context AI) that didn't write the code

Stop the same problems at the source

Review catches problems after they're written. Your rules file can stop some of them earlier. When a review finds the same mistake twice, add a line where your agent reads it:

## Pull requests
- Never delete, skip or loosen a test to make it pass. If a test looks wrong, stop and say why.
- Don't add a dependency without naming it in the PR description and saying why it's needed.
- Don't edit files in .github/workflows/ unless the task asks for it.
- Put the test command you ran and its output in the PR description.

If the agent keeps ignoring rules like these, our troubleshooting guides cover why: AGENTS.md not working, CLAUDE.md not working and Copilot instructions not working. If it's stuck redoing the same broken fix, see AI coding agent stuck in a loop.

Want these rules ready to drop in? The free AGENTS.md generator writes a rules file with your test commands in a minute. The AI Coding Agent Config Kit has AGENTS.md templates for 12 stacks, Claude Code, Cursor and Copilot files, and a prompt that turns review comments into rules. The Claude Code Subagent Pack adds read-only code-reviewer and security-auditor subagents.

Keep reading