Code review was designed for a world where writing code was the slow part. A developer spent a day on a change, and a colleague spent half an hour reviewing it. That ratio is gone. A coding agent can produce a 600-line pull request in ten minutes, and the developer who started it may have read less of it than the reviewer is about to.

The result, in many teams, is a review queue that grows faster than anyone can read, and a quiet temptation to approve anything that passes CI. That is how subtle bugs, security holes and unmaintainable code get in: not because AI writes bad code all the time, but because it writes plausible code at a volume that overwhelms the process meant to catch the bad parts.

This cheatsheet is about adapting code review to that reality: the evidence, the rules for authors, a checklist for reviewers aimed at AI-specific failure modes, where AI reviewers help, and the team policies that keep humans accountable for what gets merged.

1. What the evidence says

Source Finding Implication for review
DORA 2025, State of AI-assisted Software Development (September 2025) AI adoption among software professionals reached about 90%. AI use was linked to higher delivery throughput but also to higher delivery instability. The report's central message: AI is an amplifier of the existing system, good or bad. More changes flow through the pipeline. Review and testing determine whether that means more value or more incidents.
METR randomized trial (July 2025) Experienced open-source developers working on real tasks in mature repositories they knew well took 19% longer with AI tools allowed, while believing afterwards that AI had made them about 20% faster. Feeling productive is not evidence. Measure lead time and quality, not impressions.
Veracode GenAI Code Security Report (July 2025) Across 80 coding tasks and more than 100 models, generated code introduced a known security weakness in 45% of cases. Security review cannot be skipped because "the AI knows best practices".
Bacchelli and Bird, Microsoft (ICSE 2013) Finding defects is the main stated reason for code review, but much of its real value is knowledge transfer, team awareness and alternative solutions. If nobody on the team understands merged code, review has failed even if there are no bugs.
Cisco code review study (reported by SmartBear) Reviewers find defects best in batches of 200-400 lines, at under 500 lines per hour, for no more than 60-90 minutes at a time. Large AI-generated PRs exceed what humans can review well. Split them.

The pattern across all of these: AI changes the economics of writing code, not of understanding it. Review is where understanding happens, so review is now the constraint that matters.

2. Rules for authors: you own what you submit

The single most important policy: the person who opens the pull request is its author, regardless of who or what typed the code. "The AI wrote it" is not an explanation for a bug, any more than "the compiler accepted it" was.

Before opening the PR

  • Read every line. If you would not be able to explain a line in review, you are not ready to submit it.
  • Run it. Tests passing in CI is the minimum; also exercise the feature yourself.
  • Remove what you did not ask for. Agents add helpful extras: refactors of nearby code, new dependencies, extra config, reformatted files. Revert anything outside the task.
  • Check the tests are real. Generated tests often assert what the code does, not what it should do. Some mock the very thing they claim to test.
  • Keep it small. One logical change per PR. Aim for something a reviewer can read carefully in under an hour, roughly 200-400 lines of meaningful change. Generated files, lock files and snapshots do not count, but should be called out.

The PR description

Section What to write
Why The problem or ticket, in one or two sentences
What changed The approach, and the main files or modules touched
How it was produced Whether an AI assistant or agent was used and for what parts (generation, tests, refactor). A short note is enough.
How it was verified Tests added or run, manual checks, screenshots or logs
Risks and open questions What you are least sure about. Point the reviewer at it.
Out of scope What you deliberately did not change

Disclosure is not about blame. It tells the reviewer where to look harder. A note like "error handling in sync.py was generated and I am least confident about the retry logic" saves the reviewer an hour.

3. Reviewer checklist for AI-generated code

AI-generated code fails differently from human code. It is rarely sloppy-looking. It is usually clean, confident, well-commented and occasionally wrong in ways that look right.

Correctness and intent

  • [ ] Does the change solve the actual problem in the ticket, or a slightly different, easier one?
  • [ ] Are edge cases handled: empty inputs, None, time zones, Unicode, very large inputs, concurrency?
  • [ ] Are errors handled, or swallowed? Watch for broad except Exception: pass, default values that hide failures, and silent fallbacks.
  • [ ] Does the code use APIs that exist, with the right signatures and in the version you actually depend on? Hallucinated or outdated APIs are a classic AI failure.
  • [ ] Do comments and docstrings match what the code does? Generated comments can describe the intended behavior rather than the real one.

Tests

  • [ ] Would the tests fail if the feature were broken? Mentally break the code and check.
  • [ ] Do tests cover the risky paths, or only the happy path?
  • [ ] Were existing tests modified or deleted to make the change pass? This deserves an explicit explanation in the PR.
  • [ ] Are mocks hiding the behavior under test?

Security

  • [ ] Input validation, output encoding, parameterized queries. SQL injection and cross-site scripting were among the common weaknesses in generated code.
  • [ ] No secrets, tokens or credentials in code, tests, fixtures or logs.
  • [ ] Authorization checks present on every new endpoint or action, not just authentication.
  • [ ] New dependencies: do they exist, are they the intended packages (watch for look-alike names), are they maintained, and are they needed at all?
  • [ ] Safe handling of files, paths, shell commands and deserialization.

Design and maintainability

  • [ ] Does it reuse existing helpers, or re-implement them? Duplicated logic is one of the most common side effects of generated code.
  • [ ] Does it follow the codebase's conventions and architecture, or a generic pattern from elsewhere?
  • [ ] Is there unnecessary abstraction (factories, interfaces, config options nobody asked for)?
  • [ ] Is the diff limited to the task, or does it include unrelated "improvements"?
  • [ ] Will the next person understand it without the prompt that generated it?

Operational

  • [ ] Logging, metrics and error messages good enough to debug this in production?
  • [ ] Performance: N+1 queries, unbounded loops, loading whole files or tables into memory?
  • [ ] Migrations: reversible, safe on large tables, compatible with the running version during deploy?
  • [ ] Feature flag or rollback plan for risky changes?

4. How to review a large AI-generated change

Sometimes a big change is legitimate: a migration, a new module, a framework upgrade. A workable approach:

  1. Ask for a split first. Many large PRs can be broken into preparatory refactors, the core change and follow-ups. Agents are good at splitting their own work when asked.
  2. Start from the description and tests, not the diff. Understand what it claims to do and how it proves it.
  3. Review the interfaces before the implementations: public functions, API contracts, database schema, config. Mistakes there are expensive later.
  4. Read the riskiest parts line by line, skim the mechanical parts. The author's "risks and open questions" section tells you where to focus.
  5. Pair-review for very large changes. Walk through it with the author live. It is faster than 80 comments, and it reveals quickly whether the author understands the code.
  6. Time-box. After about an hour, stop, leave comments, and continue later. Review quality drops sharply with fatigue.

5. AI reviewers: useful, but not the approver

AI code review tools (bots that comment on PRs, or an assistant you ask to review a diff) are now common. They are good at some things and bad at others.

AI reviewers are good at AI reviewers are weak at
Catching typos, obvious bugs, missing null checks Knowing whether the change does what the business needs
Spotting inconsistent naming and style Understanding unwritten team conventions and history
Flagging common security patterns Judging architecture and long-term trade-offs
Summarizing large diffs for the human reviewer Knowing what is missing from the change
Being available instantly, at any hour Being accountable for the result

Practical rules:

  • Use AI review as a first pass, before human review. Let it catch the mechanical issues so humans can focus on intent and design.
  • A human approves. Branch protection should require at least one human approval for merge. An AI review comment is input, not a sign-off.
  • Tune the noise. A bot that leaves 30 low-value comments per PR teaches people to ignore it. Configure it to focus on what your team cares about.
  • Same model, same blind spots. If the code was generated by a model, a review by the same model tends to agree with it. A different model or tool, and above all a human, catches more.

6. Team policies that work

Policy Why
Author owns the code, regardless of how it was written Accountability does not move to a tool
Short disclosure of AI use in the PR description Tells reviewers where to look; normalizes honest reporting
PR size limits (soft, e.g. 400 changed lines excluding generated files) Keeps review effective
At least one human approval required by branch protection No unreviewed code reaches main
CI gates are not optional: tests, linters, type checks, security scanning, dependency checks Automated checks scale with volume; humans do not
Extra review for sensitive areas (auth, payments, data deletion, migrations) via code owners Risk-based review effort
Agents work on branches, never merge themselves Humans stay in the loop at the point of no return
Project instructions file (AGENTS.md, CLAUDE.md or similar) with conventions, commands and do-nots Better first drafts mean less review effort

One policy to avoid: banning AI-generated code outright. It does not stop usage; it stops disclosure, which makes review harder.

7. Metrics to watch

If you change how you review, check the effect with data, not impressions.

Metric What it tells you Warning sign
PR size (median changed lines) Whether changes stay reviewable Rising steadily since AI adoption
Time to first review Whether the review queue is keeping up Growing week over week
Review depth (comments per PR, time spent) Whether reviews are real Approvals in minutes on large PRs
Change failure rate and rework (DORA) Whether quality holds as throughput rises Throughput up, failure rate up too
Reverts and hotfixes traced to recent PRs Escaped defects Clusters around large or agent-generated PRs
Duplicate code and churn (code rewritten soon after merge) Maintainability Rising duplication, short-lived code

Review these quarterly with the team. The goal is not to prove AI good or bad, but to find where the process needs to adapt.

Why this matters

  • Review is the new bottleneck. AI made writing code cheap; understanding it is still expensive.
  • Ownership does not transfer to tools. Whoever opens the PR answers for every line.
  • AI code fails plausibly. Hallucinated APIs, swallowed errors, tests that test nothing and duplicated helpers look fine at a glance.
  • Small PRs, honest descriptions and strong CI scale with volume; heroic reviewers do not.
  • AI reviewers are a first pass, not a sign-off. A human approves what reaches main.

Final Thoughts

Teams that get real value from AI coding tools are not the ones generating the most code. They are the ones that kept their feedback loops honest: small changes, real tests, careful review and fast rollback. DORA's description of AI as an amplifier fits code review exactly. A team with a healthy review culture gets faster and stays safe. A team that was already rubber-stamping now rubber-stamps ten times as much.

So treat review as the engineering practice it always was, not a formality before merge. Ask authors to own and explain their changes, keep pull requests small enough to read, let automation and AI handle the mechanical checks, and spend human attention where it matters: on whether this change is right, safe and understandable by the next person who has to change it.

Sources