I let AI write most of my code. So when someone asks me how to review AI-generated pull requests, my answer starts with a review I barely had to think about.
In my post on who will maintain AI-generated code, I told the story of a Go library my team inherited at Kooora. None of us knew Go, every AI-assisted fix turned into another round of guesswork, and we ended up rewriting the whole thing in TypeScript.
Here’s the part I left out: Claude wrote the rewrite. And reviewing that pull request was the easiest review of the whole saga.
We still didn’t know Go. We didn’t need to. We knew exactly what the library was supposed to do, so the review came down to one question: does the new code do that?
That’s the idea behind this checklist. You can review code you didn’t write, in a style you wouldn’t have picked. You can’t review code when you don’t know what it’s for.
Same Checklist, Different Weights
Good code review hasn’t changed. Google’s published review guide asks about design, functionality, complexity, tests, naming, and comments, and every one of those still applies when an agent wrote the code.
What changes is where the mistakes hide. In December 2025, CodeRabbit compared 470 open-source pull requests, 320 of them co-authored by AI, and found about 1.7 times as many issues in the AI pull requests. Logic and correctness problems were 75% more common. Error-handling gaps nearly doubled. Performance problems like excessive I/O showed up close to eight times as often.
Two caveats. CodeRabbit sells an AI code review product, and it identified AI pull requests from signals in the PR, so some of the “human” ones may have had help. I couldn’t find a newer edition.
One finding went the other way: spelling mistakes were more common in the human pull requests. An agent won’t misspell receive. It will happily receive the wrong thing.
So keep the list, and move your attention:
| Spend less time on | Spend more time on |
|---|---|
| Typos and spelling | Whether it does what was asked |
| Formatting (let your formatter and linter handle it) | Changes nobody asked for |
| Whether it compiles | Error paths and edge cases |
| Boilerplate that copies existing patterns | New dependencies |
| Style nitpicks your tools already flag | Security, and whether the tests prove anything |
Before You Open the Diff
Most wasted review time comes from reading a diff before you know what it’s supposed to do. Three checks come first.
- Write the intent in one sentence. If the description doesn’t let you, send it back before reading a line. That sentence is what you review against, just like our Go rewrite.
- Check the size. Agents make big diffs cheap to produce and expensive to read. Google’s guide tells authors to keep changes small and says a reviewer can reject a change for being too large, and for nothing else. DORA’s 2025 research counts working in small batches among the practices that make AI pay off.
- Find out what the agent was told. The ticket, the prompt, the plan. If the agent misread the task, the code can be perfect and still wrong.
The Checklist to Review AI-Generated Pull Requests
1. It does what was asked, and nothing else
Agents like to tidy up. A bug fix arrives with renamed variables, a reformatted file, and a helper “simplified” along the way. Every extra change is something you now have to review, and none of it was in the ticket.
Watch for missing code too. An agent that can’t make something work sometimes removes whatever is in the way. I’ve also watched one copy a pile of unused fields from a similar plugin into mine, which I wrote about in my post on AI and software jobs.
For every file in the diff, ask: does the task explain why this file changed?
2. The tests prove something
Read the tests before the code. Then check:
- Do they test the behavior that was asked for, or just repeat what the code happens to do?
- Is the thing being tested mocked out?
- Were existing tests deleted, skipped, or loosened to get a green build?
- Is there at least one test for a failure case?
A passing build means the code agrees with its tests. When the agent wrote both, that agreement is cheap.
3. The unhappy paths are handled
Error-handling gaps were nearly twice as common in the AI pull requests CodeRabbit studied. Trace what happens when input is empty or missing, when a network call times out, and when a step fails halfway through a batch.
Look for errors that get caught, logged, and then ignored. Look for default values that quietly hide a failure. Code that never crashes isn’t the same as code that works.
4. Every new dependency is real and needed
AI models sometimes invent packages. In a USENIX Security 2025 study, researchers generated 576,000 code samples with 16 models and found hallucinated package names at least 5.2% of the time for commercial models and 21.7% for open-source ones.
Worse, 43% of the made-up names came back in every one of ten repeat runs. That’s what attackers count on: register the name a model keeps inventing, fill it with malware, and wait. The attack is called slopsquatting.
Those were 2024-era models, and newer ones probably do better. The check takes a minute anyway:
- Does the package exist, and is it the one you think it is?
- Who maintains it, how old is it, and does anyone else use it?
- Does the project already have a dependency, or the standard library, that does this job?
- Does the lockfile diff contain anything you didn’t expect?
5. The security basics hold up
Veracode has tested more than 100 models over four years. In its 2026 report, the average security pass rate was 56%, barely changed from its first report, and roughly 44% of coding tasks produced a security flaw.
Veracode tested raw models with no security instructions, and it sells security scanning. Read that as a reason not to trust by default, not as a forecast for your codebase.
For any change that touches user input, logins, or data access:
- Is input validated before it’s used?
- Is the new endpoint behind the same permission checks as the ones next to it?
- Are secrets anywhere in the code, the config, or the logs?
- Is a database query built by gluing strings together?
I wrote recently about AI finding security flaws faster than we can patch them. The same tools are also writing some of those flaws.
6. It looks like the rest of the codebase
Readability was the biggest gap in the CodeRabbit data, more than three times as common in AI pull requests. In practice that means code that’s fine on its own and foreign in your project: a helper that duplicates an existing one, a different error-handling style, names that don’t match.
Search the codebase for the function the agent just wrote. There’s a decent chance you already have it.
Here’s the whole list in a form you can paste into a pull request template:
AI-generated PR review
- [ ] I can state the intent in one sentence
- [ ] The PR is small enough to review in one sitting
- [ ] Every changed file is explained by the task
- [ ] No unrelated renames, refactors, or deleted code
- [ ] Tests check required behavior, not current behavior
- [ ] No tests deleted, skipped, or weakened
- [ ] Failure cases handled: empty input, timeouts, partial failures
- [ ] No errors swallowed silently
- [ ] Every new dependency exists, is maintained, and is needed
- [ ] Input validated; permissions match neighboring code
- [ ] No secrets in code, config, or logs
- [ ] No duplicate helpers; matches existing patternsPro Tip: Before reviewing, ask the agent to list every file it changed and why. Then compare that list with the actual diff. Anything in the diff that isn’t on the list is your first question.
When the Pull Request Is Yours
Half the people reading this are on the other side. The agent wrote the code, and your name goes on the pull request. Reviewers will treat it as yours, so treat it that way before they see it.
- Read the diff, not the summary. The agent’s summary says what it meant to do. The diff says what it did.
- Run it. A passing test suite isn’t the same as watching the feature work.
- Cut what you didn’t ask for. Revert the drive-by refactors before someone else has to point them out.
- Split anything too big. If you wouldn’t want to review it, don’t ask a colleague to.
- Write the description yourself. What changed, why, and how you checked it. If you can’t write that, the pull request isn’t ready.
When AI writes most of your code, as it does mine, this pass is where the engineering happens.
What a Checklist Can’t Fix
Volume. If agents double the number of pull requests and the number of reviewers stays the same, every checklist gets skimmed. CodeRabbit blames part of the quality gap on exactly that: review processes weren’t built for this much code, and tired reviewers miss things.
AI review bots can take the first pass on formatting, naming, and obvious bugs. They can’t tell you whether this was the right change to make. That still needs a person who knows what the code is for.
Which brings me back to the Go library. We couldn’t read the original, and it didn’t matter, because we knew what correct looked like. Every item on this list is a way of asking the same question: does this do what we needed, and nothing we didn’t?
Frequently Asked Questions
Should AI-generated pull requests be reviewed differently?
Use the same checklist, with different weights. Spend less time on typos and formatting, and more on intent, scope, error handling, dependencies, security, and the quality of the tests.
Can an AI code reviewer replace a human reviewer?
Not completely. Review bots are useful for a first pass on style and obvious bugs, but they can’t judge whether the change matches what the team actually needed.
What is slopsquatting?
An attack where someone registers a package name that AI models tend to invent, then fills it with malicious code. Anyone who installs the suggested package without checking gets the malware.
How big should an AI-generated pull request be?
Small enough to review in one sitting. Google’s guide doesn’t set a hard line count, but it advises smaller than you think and lets reviewers reject changes for size alone.
