AI Code Review Checklist for Teams: 9 Checks I'd Enforce

An AI code review checklist for teams should spend very little human time reading code line by line. Assistants such as Cursor, Claude and Copilot produce diffs that read fluently and compile, so reviewers skim and approve. My thesis is to make the author supply evidence, let machines reject what they can, and save human attention for behavior, design and risk.

The short answer: review the evidence, not the diff

A fluent diff is not a correct diff. Reviewers who approve on fluency are reviewing the assistant's tone, not the change.

My rule is simple. The author supplies the evidence: intent, verification and scan results. The reviewer spends attention only on what automation cannot judge.

The checklist has four layers in a fixed order: author declaration, automated first pass, human review of behavior and design, then security and release safety. The order is cheapest-first. Anything a machine can reject should never reach a person, and anything only a person can judge should reach a reviewer who is still fresh. The common failure is a human spending 40 minutes on formatting that a linter would have rejected in seconds.

That ordering is not novel. Michaela Greiler's write-up of a Google code review study describes authors looking through their own diff and running a static analysis tool (Tricorder) before sending changes to a reviewer. At least one reviewer must then approve. That describes one company's process. It does not prove the ordering reduces defects, but it shows the cheap-first pattern is how a very large engineering organization (the page cites 25,000 engineers) already works.

Here are the four layers, so you can adopt them in stages rather than all at once.

1. Author declaration: intent, scope and AI provenance in the PR template

This layer is a PR template with five required fields. It suits any team where more than one person uses AI assistants. It matters most when juniors and seniors prompt differently, because reviewers cannot otherwise tell which lines were reasoned about.

Check 1: Require five fields before review starts

<div class="video"><iframe src="https://www.youtube-nocookie.com/embed/58MR03s0ev8" title="Learn 80% of AEO in 19 Minutes" loading="lazy" allowfullscreen></iframe></div>

## Problem (one sentence)
## Files deliberately not touched
## Verification (commands run and their output, not "tested locally")
## AI involvement (which files or functions, which tool, how edited)
## Rollback (how to undo this, and what undoing costs)

The strength is behavioral. Most "AI slop" PRs fail at the declaration stage, because the author cannot state the intent without rereading the code. A one-sentence problem statement is a cheap test of whether anyone understood the change.

The "not touched" field matters more than it looks. Assistants edit adjacent code freely, and an explicit list of files the author chose to leave alone makes scope creep visible.

The limitation is honest: provenance fields are self-reported. They shape behavior and give reviewers a risk signal, such as "this whole module was generated, read it harder". They are not an audit. I would never use them to police individuals, because the moment people fear the field, they stop filling it in truthfully.

Check 2: Cap PR size

I'd set about 400 changed lines per PR. That number is my judgment call, not a figure from the sources here, so tune it to your team. The reasoning holds regardless: assistants make oversized PRs effortless to produce, and reviewer attention does not scale with the diff.

Example: an author submits a 900-line change. Split it into three PRs of roughly 300 lines each: schema and migration, service logic, then API wiring. Each gets its own declaration, and each can be rolled back alone.

When not to apply the cap: exclude generated lockfiles, snapshots and mechanical renames from the count. A cap that blocks a harmless rename teaches people to game the cap.

2. Automated first pass: linters, scanners and an AI reviewer bot

This layer is a set of required CI checks that pass before a human is assigned. It is for every team, and it is the first layer to build. It has the lowest cost and the highest rejection rate.

Check 3: Make the mechanical gates required

The baseline gates are:

• Formatter and linter.
• Type check.
• Unit tests with a coverage-diff gate (the coverage tool and its settings depend on your stack).
• Dependency and image scanning.
• Secret detection.

Gate on the diff, not the whole repository. A coverage gate on the total number lets a large legacy codebase hide an untested AI-generated module.

For images, I run Trivy on every image in CI. A minimal gate looks like this:

trivy image --severity HIGH,CRITICAL --exit-code 1 registry.example.com/app:pr-1234

Flag names and defaults can change between versions, so confirm them in the Trivy documentation for the version you pin. The risk of this gate is alert fatigue: if it blocks on unfixable findings, people add ignores. Keep an expiry date on every ignore.

Scanning only helps if someone owns the result. Same-day CVE response across Kubernetes clusters works because a finding has a named owner, not because a scanner exists.

Check 4: Verify that new dependencies exist and deserve trust

Language models can recommend package names that do not exist or that nobody maintains. I do not have a source here for how often, so treat the failure as plausible rather than measured. The check is cheap to automate anyway.

For every dependency added in the diff, CI should confirm that the name resolves on the registry, then surface its age and maintainers for the reviewer. With npm, for instance, npm view <name> fails for a missing name. A freshly registered package with a name that looks like a typo of a popular one deserves a human look before merge. This is also why the "AI involvement" field should list any dependency the assistant suggested.

Check 5: Treat an AI reviewer bot as advisory

An AI reviewer bot is optional and often paid. Its real strength is breadth on routine issues. Zemith, which sells an AI platform, says such tools can handle routine checks for style, syntax and common errors so developers can focus on logic and architecture. That is a vendor claim, and a plausible direction, not evidence of how well any bot performs.

The limitation is correlated blind spots. If an assistant wrote the code and a similar model reviews it, they may share the same misconceptions. I would let the bot comment but never let it be the required approval. Count its comments that humans act on for a month. If almost none lead to changes, turn it down or remove it.

Practical rule: Anything a machine can reject goes into required CI; anything a model merely suggests stays advisory.

3. Human review: behavior and design

This layer is the part only a person can do. It suits teams with shared ownership, where someone will maintain the code next quarter. The reviewer reads intent first, tests second and implementation last.

Check 6: Read the problem and the tests before the code

Zemith's checklist starts functionality review with the ticket, user story or bug report, so the reviewer knows the original requirement. I agree, with an AI-specific twist. Read the tests before the implementation, because assistants often write tests that restate the implementation and therefore pass by construction.

Ask three questions of the tests:

• Would this test fail if the behavior were wrong, or only if the code were deleted?
• Does it cover the unhappy path, such as empty input, duplicates, timeouts and permissions?
• Does the "Verification" field show commands that actually ran, with output?

A cheap manual probe helps. Break one line of the implementation and see whether any test goes red. If none does, the tests are decoration.

Check 7: Judge fit with the existing system

Assistants solve the problem in front of them. They rarely know your codebase has a retry helper, an error type or a pagination convention already. The reviewer's job is to spot the duplicate helper, the new pattern that contradicts the old one and the abstraction nobody asked for.

A good review comment here is a pointer, not a style nit: "we already have this in the shared HTTP client; use it." The trade-off is that this layer is slow and cannot be automated. That is exactly why the earlier layers exist, and why a fresh reviewer matters.

4. Security and release safety

This layer applies to anything touching authentication, personal data or production traffic. Its strength is that it stops the expensive failures. Its limitation is that it needs named owners, because scanners find problems and do not fix them.

Check 8: Review trust boundaries and model output handling

Two separate risks live here. One is insecure code written by an assistant. The other is code you ship that consumes a model's output at runtime. The checklist should treat both.

On the first, a SoftwareSeni article claims in its title that vulnerabilities increase 2.74x in AI-generated code. I could see only the headline, not the method. Treat it as a clue that the risk deserves its own review step, not as a ratio to plan around.

On the second, OWASP's LLM05:2025 Improper Output Handling describes insufficient validation and sanitization of model outputs before they reach other components. Its examples map directly onto review questions:

• Is model output ever passed to a shell, exec or eval?
• Is model-generated SQL executed without parameterization?
• Is model output used to build file paths without sanitization?
• Is generated JavaScript or Markdown returned to a browser without encoding?

OWASP's mitigation is to treat the model as any other user and apply zero-trust validation. The earlier LLM02: Insecure Output Handling entry from the 2023/24 list covers the same risk under its original name and gives the same advice. Both are descriptions of risk, not proof of how common it is in your code.

For identity, my rule comes from managing identity as code with Keycloak and Terraform. Any change to authentication or authorization gets a named security reviewer, and token validation uses the identity provider's maintained libraries, never a hand-rolled version an assistant improvised.

A scope note: if your team trains or fine-tunes models, this checklist is not enough. NHI Mgmt Group's guide to NIST SP 800-218A points out that a model's security also depends on training data, weights and pipelines, none of which a code review sees. NIST describes the SSDF as a set of fundamental secure development practices, with SP 800-218A as the generative-AI community profile. Use those for model development.

Check 9: Prove the release can be undone

My release constraint is zero downtime on Kubernetes, which shapes this check. A change must be safe to run alongside the previous version, because during a rolling deploy both versions serve traffic.

Ask four things:

• Is the database migration backward compatible, so the old version still works after it runs?
• Is risky behavior behind a flag that can be switched off without a deploy?
• Does the "Rollback" field describe a path someone could follow at 3 a.m.?
• Has that path been exercised at least once in staging?

The risk of skipping this is subtle. An assistant will happily generate a migration that drops a column the running version still reads. The diff looks tidy, and the failure appears only mid-rollout.

Practical rule: Security review is a named owner plus specific questions about output handling, identity and rollback; a scanner report alone is not a review.

Set this week's rollout plan

1. Add the five-field PR template today. Make "Verification" require commands and output, and make "AI involvement" a neutral field, not a confession.
2. Audit your required CI checks. List what actually blocks merge, then add any missing gate from Check 3, scoped to the diff.
3. Add a dependency existence check. Fail CI when a new package name does not resolve, and show age and maintainers for the reviewer.
4. Set a PR size cap and exclusions. Start near 400 changed lines, exclude lockfiles and mechanical renames, and revisit after a month.
5. Turn on an AI reviewer bot as advisory only. Track how many of its comments lead to a change, and drop it if that number stays near zero.
6. Name owners for security and rollback. One person for auth and data changes, one rule that every PR states how it is undone.
7. Test the checklist on one real PR. Run it end to end, note which layer caught what, and roll back any check that produced noise without catching anything.