How to review AI-generated pull requests: a 12-point checklist

To review an AI-generated pull request well, check intent and evidence before style. Start with the plan and the ticket, read the tests before the code, look hard at anything touching auth, data or money, and run the change yourself. AI-written code usually looks tidy. The bugs hide in assumptions, weak tests and missing checks, not in formatting.

Here's the checklist, and why each item is on it.

Why AI pull requests need a different eye

The standard doesn't change. The failure patterns do.

• In CodeRabbit's December 2025 analysis of 470 open-source pull requests, AI co-authored PRs had about 1.7x more issues than human-only PRs (10.83 vs 6.45 per PR). Logic and correctness issues were 75% more common (CodeRabbit, 2025 (opens in a new tab)). CodeRabbit sells code review and notes it can't be certain every "human" PR was human-written, so treat the exact ratio with care. The direction is consistent with other research.
• In Veracode's 2025 testing, 45% of AI-generated code samples failed security tests and introduced an OWASP Top 10 (opens in a new tab) vulnerability. Java was worst at a 72% failure rate (Veracode, 2025 (opens in a new tab)).
• 66% of developers say their top frustration with AI is output that is "almost right, but not quite" (Stack Overflow, 2025 (opens in a new tab)).
• GitClear's 2025 research found that in 2024, copy-pasted lines outnumbered moved (refactored) lines for the first time (DevClass coverage (opens in a new tab)). Duplication is quiet debt that a quick review misses.

Put simply, AI code fails confidently. It compiles, it's well named, the tests are green, and it's still wrong. Your review has to be built for that.

The 12-point checklist

Before you read the diff

1. Does the PR solve the ticket that was asked? Re-read the ticket, then the PR description. Agents sometimes solve a nearby problem very well. Check the acceptance criteria one by one.

2. Is the plan sound? If the agent wrote a plan (good ones do), read it first. A wrong approach is cheaper to reject here than after reading 400 lines. YTS attaches its plan to every ticket's timed record for exactly this reason.

3. Is the PR small enough to review properly? If it touches unrelated files or runs to thousands of lines, send it back and split the ticket. Nobody can verify a giant diff, human or machine.

Read the tests before the code

4. Do the tests actually test the change? Look for tests that assert something trivially true, mock the very thing they claim to test, or only cover the happy path. Green tests that prove nothing are the most common way a bad AI PR gets merged.

5. Were existing tests changed or deleted? Any edit to an existing assertion needs a reason in the PR description. "Updated the test to match the new output" can mean "hid the bug".

6. Are edge cases covered? Empty input, nulls, large values, time zones, concurrency, permissions. Ask: what would break this in production on a bad day?

Then read the code

7. Does every API, package and function actually exist? Check imports and calls against your real dependencies and their versions. Invented methods and outdated signatures look completely plausible in a diff.

8. Does it follow your codebase's patterns, or invent new ones? A second HTTP client, a new date library, a fresh helper that duplicates one you already have. Each is small. Together they're the duplication GitClear measured.

9. Is error handling real? Look for swallowed exceptions, catch-all blocks that log and continue, and retries without limits. AI code often handles errors in a way that hides them.

Security and data

10. Is every input validated and every query safe? Check for injection, missing output encoding (cross-site scripting was one of Veracode's worst categories), unsafe deserialization and path handling. Treat anything near auth, payments or personal data as high risk by default.

11. Did it touch secrets, permissions or config? New environment variables, widened permissions, logging that could print tokens or personal data, disabled checks "to make the tests pass". All of these need an explicit yes from a person.

Before you approve

12. Did you run it? Pull the branch and use the feature, or at least read the agent's test output and screenshots. Approving based on the diff alone is how "almost right" ships.

How to make AI pull requests easier to review

The best review is the one you barely need. Most of that work happens before the PR exists.

• Write tickets with acceptance criteria. The clearer the finish line, the less the agent guesses.
• Keep tests fast and runnable from the command line. The agent uses them to check itself.
• Require a plan and a summary on every PR. What changed, why, how it was tested.
• Keep the agent PR-only. It should never be able to merge. YTS never merges on its own.
• Use AI review as a first pass, not the last. Automated review catches patterns. A person who knows the product catches wrong intent.

Google's code review guidance (opens in a new tab) still applies in full: the reviewer's job is to keep the codebase healthier over time, whoever wrote the change.

When you don't have time to review

This is the honest bottleneck. An agent can open PRs faster than a small team can review them, and DORA's 2025 research (opens in a new tab) found AI adoption still has a negative relationship with delivery stability. More output without more review is how that happens.

If review capacity is your constraint, you have three options. Slow the agent down to your review speed. Keep its work to low-risk tickets. Or add reviewers. YTS offers the third as YTS Review, where a senior engineer from our team reviews every PR YTS opens before it reaches you.

Copy this checklist

1. Solves the ticket as asked
2. Plan is sound
3. Small enough to review
4. Tests test the change
5. No unexplained test edits
6. Edge cases covered
7. Every API and package is real
8. Follows existing patterns, no duplication
9. Errors are handled, not hidden
10. Inputs validated, queries safe
11. No secret, permission or config surprises
12. You ran it

New to agents? Start with what an AI software engineer actually is and how agents differ from assistants.