A code review checklist for agent-authored code

The checklist I actually run is below, and then the reason each line is on it. The order matters more than the items: structure first, lines last. The January 2026 study GitHub cites in its guidance on agent pull requests, "More Code, Less Reuse", found that agent-written code carries more redundancy and technical debt per change than human code, and that reviewers feel better about approving it. Feeling good about a change is not evidence, so the list below asks for some.

The checklist

## Review checklist: agent-authored change
 
- [ ] Shape. I can say in one sentence what this change does to the system,
      and that sentence matches the title.
- [ ] CI. I read every diff under .github/ in full. No test was skipped,
      no threshold lowered, no job moved to a trigger that rarely fires.
- [ ] Config and permissions. New env vars, scopes, timeouts and retry
      settings are named in the description and are ones we want.
- [ ] Deletions. Everything removed has no live caller, and the removals
      are intentional rather than incidental.
- [ ] Duplication. The new helper, client or type does not already exist
      somewhere else in the repository under another name.
- [ ] One path. I traced the path this change exists for, end to end,
      including what happens when a step fails.
- [ ] Boundaries. Auth, tenancy, input validation and anything reading
      untrusted content are unchanged, or changed on purpose.
- [ ] Evidence. A test, a CI run or a screenshot proves this ran. The
      description alone does not count.
- [ ] Blast radius. Nothing outside the stated scope moved.

Nine boxes. On a change of the size agents produce, they take about ten minutes, which is the clock in how to review a 400-line pull request in ten minutes.

Why the first item is the shape, not the code

Every other item on the list assumes you know what the change is. That sounds like the easy part and it is the expensive part. LinearB's 2026 benchmarks, from 8.1 million pull requests, put AI-assisted pull requests at 408 changed lines at the 75th percentile against 157 for unassisted ones, and the file list of a 400-line change tells you where it lives rather than what it does.

So the first box gets a specific test: one sentence, and it has to match the title. If the title says "add rate limiting to the upload route" and your sentence is "adds rate limiting, plus a Redis client, plus a new metrics lane", the title was wrong and every assumption downstream of it was wrong too. This is the box a drawn pull request ticks for you: components in green, amber and red, with the untouched parts of the system still on the page for scale. It ticks the last box at the same time, because a change that reached outside its stated scope shows up as a component nobody mentioned, sitting in a lane the title never named.

Why CI comes before source code

GitHub lists CI gaming first among five red flags in agent pull requests. An agent optimises for the goal it was given, and "make the tests pass" has two solutions. The diff under .github/ is usually twenty lines, so reading it in full costs almost nothing, and it is the only part of a pull request that can make the rest of it lie to you. Read it before you trust a green check.

Configuration and deletions sit next to CI for the same reason. They are short, they read as boilerplate, and they are where the incident comes from. A timeout raised to thirty seconds, a scope added to a token, a retry loop with no ceiling: each is one line in the diff and a different system in production. A removed worker with one caller left behind does not fail in review; it fails at 3am.

Why duplication gets its own line

An agent writing a date formatter has no strong reason to look for the date formatter three directories away. Neither do you, if you are reading a diff, because a diff only shows what changed. GitHub's checklist gives this a full two minutes of its ten, and the "More Code, Less Reuse" finding is exactly this failure at scale.

The cheap version of the check is a search for two or three distinctive identifiers from the new code. The better version is looking at the change drawn against the system, where a new component landing beside an existing one that does the same job is a shape you notice without having to think of running the search.

Why one traced path beats six files skimmed

A checklist for agent code is a list of the things the agent had no reason to check. Coherence across a path is the main one. Agent-written code is locally plausible almost by construction, so its defects collect at the joins: a retry on a call that stopped being idempotent, an error caught one layer above where it could have been handled, a consumer that assumes ordering the producer never promised.

Trace one path, the one the pull request exists for, from entry point to whatever it writes. Include the failure branch. Two paths cost double and tell you less than one path plus the shape.

Why the boundary questions are worth a box of their own

"Is Vibe Coding Safe?" evaluated agent solutions against a security benchmark and found 61% of SWE-Agent with Claude 4 Sonnet's solutions functionally correct and 10.5% secure. Working and safe are that far apart, and the gap lives at boundaries: authentication, tenancy scoping, input validation, and anything that reads content a stranger controls. GitHub's fifth red flag is untrusted input reaching a workflow, which is the same boundary wearing a different hat.

You are not auditing the whole system in this box. You are checking whether this change moved a boundary, and whether it meant to. The question is narrow enough to answer from the file list plus one search, which is why it stays a box rather than becoming a separate review.

Why evidence is the last item and not the first

Because the description is free. A model that wrote 400 lines can write four confident paragraphs about them. Paragraphs are not proof. GitHub calls the failure hallucinated correctness and pairs it with agentic ghosting: the author was a process, so there is nobody in the thread to answer you.

A test that exercises the new path counts. A CI run counts. A screenshot counts. "Verified locally" does not.

What is deliberately off the list

Style, naming, formatting, import order, comment wording. A linter enforces those, and agents are good at them anyway. Adding them to a checklist trains you to spend your attention where the risk is not.

Also off the list: reading every line. If your process requires it, your process will lose to the queue, and the queue is where review is quietly disappearing. Faros AI found the share of pull requests merged with no review at all rose 31.3% under high AI adoption, which is what happens when the only offered option is the expensive one.

Where to keep it so it gets used

Put it in .github/pull_request_template.md so it renders in every description, and give your review tooling the same rules in the file it reads. Claude Code Review reads REVIEW.md from the repository root, and CLAUDE.md at every level of the directory tree, per Anthropic's documentation as of September 2026, and Cursor's Bugbot reads rules from .cursor/BUGBOT.md. Two of the boxes above, CI and duplication, translate well into those files. Write them as questions the reviewer must answer, since a rule phrased as a question is harder to tick without looking.

The first box translates into a diagram. PR Lens draws each pull request as animated architecture and data-flow diagrams and posts them as one comment inside the pull request, redrawn on every push: green for new, amber for changed, red and struck through for gone. It is open source, MIT licensed, and free for open source repositories.

For the specifics of the agent that wrote the change, Claude Code and Cursor background agents get their own playbooks, and the method underneath all of them is in the complete guide to reviewing AI-generated pull requests.