How to review an AI-generated pull request

The new senior engineer skill is reviewing AI-generated pull requests in under 10 minutes.

Not by being permissive. By knowing exactly what to look for. AI coding agents have predictable failure modes. The review pattern that catches those failure modes scales to the volume of PRs the AI can produce.

This post is the review checklist. The four things AI gets wrong reliably, the five-step review pattern that catches them, and how to decide whether to merge, request changes, or reject entirely.

If your team is shipping AI-generated PRs faster than you can review them well, the bottleneck is the review skill. This post is the upgrade.

The four things AI gets wrong reliably

AI coding agents have specific failure modes. Knowing them is the foundation of the review.

Failure 1: Over-engineering

The AI adds abstractions you didn't ask for. A simple feature gets wrapped in three layers of indirection. A utility function gets generalized into a configurable system. The code "feels" more sophisticated and is harder to maintain.

The cause: AI models trained on production-grade code have seen sophisticated patterns. When asked for a simple feature, they sometimes apply the patterns even when not needed.

The cost: maintenance burden, code that's harder for new engineers to understand, abstractions that turn out wrong.

Failure 2: Missing edge cases

The AI handles the happy path and skips the failure modes. The signup form works for valid inputs. It crashes on empty inputs, duplicate emails, malformed data.

The cause: the AI generates code for what was specified. Edge cases left out of the spec are left out of the code.

The cost: production bugs. The code "works" until users use it in ways the AI didn't anticipate.

Failure 3: Wrong abstractions

The AI uses patterns from its training data that don't fit your codebase. Your codebase uses Zustand for state; the AI generates Redux code. Your codebase uses Prisma; the AI generates raw SQL. Your codebase has a custom logger; the AI imports winston.

The cause: the AI has seen many codebases. It generates code from the most common patterns it saw, not necessarily the patterns in yours.

The cost: code that fights your existing patterns. Future engineers have to choose between two patterns. Inconsistency compounds.

Failure 4: Hallucinated dependencies

The AI imports packages that don't exist. Uses methods that aren't in the library. Calls APIs that aren't documented. The code looks plausible but doesn't run.

The cause: the AI has confident knowledge of common packages. For less common ones, it sometimes confabulates.

The cost: broken builds. Time spent debugging "why doesn't this work" before realizing the dependency was never real.

The five-step review pattern

The pattern catches the four failures in under 10 minutes per PR.

Step 1: Does it match the spec? (1 minute)

Open the CR or task spec. Open the PR diff. Read the diff.

Question: does the code do what the CR asked for?

If yes, proceed.

If the code does more than the CR asked (added abstractions, extra features), reject. Request the minimal version.

If the code does less than the CR asked (missing requirements), reject. Request the full implementation.

If the code does roughly what the CR asked but in a different way than specified, judge whether the deviation is reasonable. Sometimes the AI's interpretation is better than the human's spec. More often it's a sign of misunderstanding.

Step 2: Are edge cases handled? (2 minutes)

Read the CR's edge case section. For each edge case, find where it's handled in the code.

If all edge cases are handled, proceed.

If edge cases are missing, reject. Request the full edge case handling.

Common missed edge cases to look for even if they weren't in the CR:

Empty inputs.

Null values.

Network failures.

Timeouts.

Concurrent requests.

Rate limits.

Unauthorized access.

These should be handled even when the CR forgot to mention them.

Step 3: Does it fit existing patterns? (2 minutes)

Open three other files in the same area of the codebase. Compare patterns to the new code.

Question: are the new patterns consistent with the existing ones?

If yes, proceed.

If the new code introduces a new pattern (different state management, different data layer, different naming convention), ask why. Often it's the AI defaulting to its training patterns rather than your codebase patterns.

If the new pattern is genuinely better than your existing patterns, that's a legitimate refactor opportunity. But don't smuggle it into a feature PR. Either ship the feature in your existing patterns or open a separate refactor PR.

If the new pattern is wrong, reject. Request the version that follows your existing patterns.

Step 4: Hallucinated dependencies? (1 minute)

Scan the imports at the top of changed files. Open package.json. Check whether each imported package exists in dependencies.

For each external package: does the import path match a real export? You can paste into your search and verify quickly.

For each function call on an external library: is the function real? Pasting library.functionName signature into your search verifies in seconds.

For each API endpoint called: is the URL pattern correct?

If anything is hallucinated, reject. The AI confabulated. Request a fix with the real package or API.

Step 5: Tests? (2 minutes)

Are tests included? Check the diff.

If no tests, reject. Tests should be part of the PR.

If tests exist, run them locally if you can. Confirm they pass.

Read the test names. Do they cover the spec's acceptance criteria?

Read one test in detail. Does it actually test what its name claims?

If tests are inadequate (don't cover the spec, don't run, are clearly cargo-culted), reject. Request meaningful tests.

Total: 8 minutes

Five steps, 1-2 minutes each. Total time: about 8 minutes for a focused review.

Most AI PRs fail one of the five checks. The check identifies the problem. The reject-and-request-changes loop runs until the PR passes all five.

After about a week of training the AI on your patterns, most PRs pass on the first attempt.

When to merge vs request changes vs reject

The decision tree:

Merge: passes all five checks. Tests run cleanly. Matches the CR. Fits the codebase.

Request changes: passes most checks but has specific fixable issues. Provide specific feedback on what needs to change. The AI iterates and resubmits.

Reject and rewrite: the implementation is fundamentally wrong. The AI misunderstood the spec, picked the wrong approach, or did something unfixable in a small revision. Reject the PR, update the CR with more context, ask the AI to start over.

The reject case is more common in the first week of working with an AI agent. As you tune the patterns it learns, rejects become rarer.

What the AI gets right reliably

Worth knowing what to trust, not just what to verify.

Mechanical refactors. Renaming, extracting functions, splitting files. The AI does these reliably.

Following existing patterns when given good examples. Show the AI 3 instances of your codebase's pattern. It applies the pattern.

Test generation when the spec is clear. The AI writes tests at the level of detail the spec implies.

Type definitions. The AI handles TypeScript types competently.

Documentation. The AI writes clear comments and README sections from working code.

Migration scripts. Database migrations following your existing patterns.

These don't need careful review. The AI handles them. Spend your review time on the failure modes.

The senior engineer skill

In the AI era, the senior engineer's review pace dramatically increases.

A traditional team of 5 engineers might produce 10-15 PRs per week. A senior engineer reviews those carefully over hours.

A team with AI coding agents might produce 50-100 PRs per week. A senior engineer cannot review them at the old pace and old depth.

The skill is fast pattern matching against the failure modes. Catch the issues that matter in minutes. Approve the ones that pass quickly. Don't try to perfect every PR.

This is uncomfortable for some senior engineers. The instinct is to deeply understand every line. With AI volume, deeply understanding every line becomes impossible.

The healthier pattern: understand the patterns the AI uses well, trust those, focus review on the specific failure modes, approve when they're absent.

The reviewers who develop this skill become high-leverage. The ones who don't become bottlenecks.

Common review anti-patterns

Things to avoid even if they feel right.

Approving without reading the diff. The AI is good but not perfect. Skipping review erodes quality.

Reviewing line-by-line for style. The AI follows your patterns if you trained it. Don't waste time on whitespace.

Requesting "small improvements" repeatedly. If the PR passes the five checks, merge it. Don't perfect.

Treating AI PRs more harshly than human PRs. The standard should be the same. The AI isn't a junior engineer to be patient with; it's not a senior engineer to be deferential to. It's a tool that produces code that needs review.

Treating AI PRs less harshly than human PRs. Same point inverted. Quality bar shouldn't drop because the AI produced it.

What this looks like at scale

A team running AI coding agents productively:

Each engineer reviews 10-20 AI PRs per day instead of writing the code themselves.

The AI is restricted to specific repositories and types of changes initially. Expanded as trust grows.

A code review queue and clear ownership for each repo's PRs.

Patterns captured in the CR template so the AI follows them.

Periodic "AI calibration" sessions where the team reviews recent rejected PRs and updates the CR guidance.

This is the shape of engineering teams that scale with AI. The headcount stays small, the throughput grows, the review skill is the bottleneck.

How Avery NXR makes PRs reviewable

Avery NXR generates PRs in your GitHub. They look like PRs any engineer might submit:

Clear PR title matching the CR.

Description that references the CR and summarizes the implementation.

Diff that's organized by file with logical commit boundaries if the change is large.

Tests included.

CI passes (or the AI tries again until it does).

The PR is a unit of work the reviewer evaluates. Same workflow as reviewing a human PR. Same skill applies.

The advantage Avery NXR provides: the CR structure forces good specifications. Good specifications produce reviewable PRs. The two reinforce each other.

The five-question pre-merge check

Before clicking merge, ask:

1. Does this PR do what the CR asked for? Yes/No.

2. Are the edge cases from the CR handled? Yes/No.

3. Does this fit the codebase's existing patterns? Yes/No.

4. Are the imports and dependencies real? Yes/No.

5. Do the tests cover the spec and pass? Yes/No.

Five yeses: merge.

Any no: don't merge.

This check takes 30 seconds if you've done the five-step review. It's the final gate before the code lands in main.

The closing thought

Reviewing AI-generated PRs is its own skill. Different from writing code. Different from reviewing human code.

The skill is learnable. The five failure modes are predictable. The five-step review catches them in under 10 minutes.

The engineers who develop this skill become the highest-throughput members of any team in 2026. The work shifts from writing to reviewing, but the volume of shipped code grows.

If your team is shipping AI-generated PRs and you're struggling to review them well, this is the pattern. Practice it for a week. The pace and accuracy compound.

avery.software