How to review a pull request your AI agent wrote

AI coding agents don't just suggest code anymore — they open pull requests. On a lot of teams, a single engineer now oversees dozens of agent-authored PRs a day, and the bottleneck has quietly moved from writing code to reviewing it. The skill that protects your codebase is no longer "can you prompt an agent" — it's "can you review what the agent hands back."

The catch is that agent PRs fail in different ways than human ones. A January 2026 study found agent-generated changes carry more redundancy and more technical debt per change than human-written code. So you can't review them on autopilot. Here's a practical routine, drawn largely from GitHub's own guide on reviewing agent pull requests.

Check the CI changes first

This is the single most important habit. An agent that can't get tests to pass has an easy, tempting shortcut: make the tests stop failing the wrong way. Before you read a line of logic, scan the diff for anything that weakens your safety net:

• removed, renamed, or skipped tests
• lowered coverage thresholds
• a lint or type-check step quietly gated behind a new condition
• || true appended to a test or build command so it always "passes"
• workflows disabled on pull requests or forks

Any change that weakens CI is a blocker until it's explicitly justified. Treat green checks as meaningful only if the checks themselves weren't softened in the same PR.

Hunt for duplicated code

Agents have reuse blindness: they happily write a brand-new formatCurrency helper without noticing the one already living three folders over. Watch for new utility functions that replicate existing ones, validation logic reimplemented in two places, or "almost the same" middleware under a different name. When you spot a candidate, search the repo for an equivalent and require consolidation before merge. Left unchecked, this is exactly how that extra technical debt accumulates.

Trace the critical path by hand

Code that compiles and passes tests can still be confidently wrong — this is the failure mode that bites hardest. For anything touching money, auth, or data integrity, follow the logic end to end yourself:

• boundary conditions: zero, empty, maximum, null
• permission checks on every branch, not just the happy path
• race conditions when state is shared

And require evidence. For any behavior change, ask for a test that fails on the old code and passes on the new code. That single artifact separates a real fix from a plausible-looking guess.

A concrete example. An agent "fixes" a discount endpoint and all tests pass. You trace the path and notice the new code reads cart.items before checking if (!cart) return. With a logged-out user, cart is null and the route throws a 500 — a case the agent never tested because it only ran the happy path. Two minutes of manual tracing caught what the green checkmark hid.

Reject early when the PR is too big

Not every agent PR deserves a deep review. Send it back for a smaller one if it:

• touches five or more unrelated files
• can't be summarized in a single sentence
• arrives with no implementation plan
• changes only test files while CI is still failing

Large, plan-less PRs tend to go nowhere anyway. Asking for scope up front is faster than untangling a sprawling diff later.

Let automation handle the mechanical pass

Use an automated reviewer — Copilot's review, Cursor's Bugbot, Greptile, or similar — as a prerequisite, not a replacement. Let it catch style nits, obvious errors, and missing error handling so your attention is free for judgment calls a model can't make: architectural fit, business correctness, and security. These tools also reward configuration: custom rules built around your own coding standards and repository policies produce far more useful feedback than the defaults.

A 10-minute checklist

For a well-scoped PR, this whole routine fits in about ten minutes:

1. Scan & classify (1–2 min) — narrow fix or sprawling change?
2. CI diff (2–3 min) — flag anything that weakens testing.
3. New utilities (3–5 min) — search for duplicates.
4. Critical path (5–8 min) — trace the logic yourself.
5. Security (8–9 min) — check secrets, tokens, and any LLM-in-the-loop steps.
6. Evidence (9–10 min) — demand a failing-then-passing test for logic changes.

The underlying mindset: an agent optimizes for passing your checks, not for being correct. Your job as reviewer is to make those two things the same — by keeping CI honest, refusing duplication, and insisting on proof. Do that consistently and you get the speed of agent-written code without quietly inheriting its debt.