AI Code Review Checklist

An assistant does not write code it knows is correct. It predicts plausible code for your request, and plausible is exactly the kind that reads cleanly and still breaks on the one input that matters. The chat summary describes intent. The diff is what compiles and runs. This checklist exists to close the gap between the two, one change at a time, before the change becomes something you have to debug in production.

Take Maya, adding a paginated export to an internal orders service. The assistant returns a confident, well-structured reply. Without a review pass she skims it, sees a sensible function, and accepts. Two defects ride along that the summary never mentions. The diff quietly added import fast-csv-stream, a package that does not exist, while the real library fast-csv was already installed. And the pagination defaulted to an unbounded page size, so an empty or absent page parameter loaded every row into memory on the exact input the feature exists to handle. The summary said "added efficient pagination". The patch did the opposite.

The dependency failure is not an outlier. A 2025 study presented at USENIX Security generated 576,000 code samples across sixteen models and found that roughly one in five (19.7%) of the 2.23 million packages they referenced does not exist. Worse for defenders, the hallucinations are predictable: when the researchers re-ran identical prompts, 58% of hallucinated names recurred on more than one run, and 43% appeared on every single run. Attackers register the most common phantom names and publish malware under them, a supply-chain tactic the industry calls slopsquatting. One accepted install command can pull a malicious package straight into your build. The Imports verified item is the line of defense, and it is non-negotiable on every change.

The size failure points at the 2026 reality. Teams now generate far more code than before, but a human reads roughly the same number of lines per hour. SmartBear's long-running analysis of Cisco's reviews found defect density (defects found per line) dropping sharply once a review runs past 400 lines, and Google's data shows median time-to-review doubling for every additional 100 changed lines. The constraint moved from writing code to reviewing it. A checklist run on a small diff is leverage; the same checklist waved at a 900-line pull request is theater. That is why Size reviewable sits near the end as a gate, not a suggestion.

Each item is a statement you either tick honestly or cannot. The discipline is to make every tick observable, tied to something you saw in the diff or ran in the terminal, rather than a feeling that the code looks fine. The difference between a real review and a rubber stamp shows up item by item.

• Imports verified. A weak tick reads "dependencies look standard". A strong entry reads "the diff added fast-csv-stream; it is not on the registry and the real library is fast-csv, already installed, so I removed the line and repointed the code." The weak version trusts the name; the strong version checked the registry and the lockfile.
• Assumptions named. A weak tick is "logic looks correct". A strong entry is "the default page size is 0, which means unbounded, so an empty page parameter loads every row; I set a default and a hard cap of 1000 and added the empty and last-page cases." Notice the strong version names the specific assumption and the input that breaks it. "Looks reasonable" is a bar plausible code passes by design, so replace it with "what does this assume, and where does that assumption fail?"
• Scope honest. A weak tick is "nothing looks off". A strong entry is "two of three changed files match the request; the third was a new import block I did not ask for, now removed." A review that does not actively hunt for unrequested change will not find it, because plausible scope creep reads like helpfulness.
• Security checked. A weak tick is "auth is handled". A strong entry is "the export route is auth-gated, page params are coerced to integers, and no user-controlled string reaches the query." Name the check, not the hope.

Work the list in order, because the order is doing work. You state the intended behavior first so every later item has something to measure against. You read the full diff before you judge any single change. You verify imports before you run anything, since the cost of a bad install is paid the moment you type it. You decide on size before you invest a deep read, so you do not sink twenty minutes into a 900-line change that should have been three pull requests. The example above shows the realistic shape: most items tick, a few do not, and the unticked ones are precisely the work the review found. A checklist where every box is pre-ticked did not review anything.

One caution on the second AI line. Running Copilot code review, Cursor Bugbot, or Claude Code /security-review first is genuinely useful: Bugbot runs parallel passes focused on logic and security bugs while ignoring style, and Claude's reviewer dispatches several specialized agents. Teams report a layered pipeline cutting human review time noticeably by clearing mechanical issues before a person looks. The trap is reading a clean second-AI pass as approval. Copilot code review leaves a "Comment", never an "Approve", stays silent on roughly 29% of reviews, and its own documentation notes it can miss SQL injection, XSS, and any architectural decision. Tick the box only to record that the mechanical layer ran, then make the keep, fix, or split call yourself.

Most ways this checklist fails feel like progress while skipping the part that mattered.

• Reviewing the summary. The chat explanation sounds right, so the diff goes unread and every later item is ticked on faith. The fix is the hard rule behind Full diff read: no tick without scrolling the changed lines.
• Skipping the import check on a "boring" change. A new package name looks ordinary, so it is installed unverified. With one in five samples naming a phantom package, the boring changes are exactly where slopsquatting lands.
• The diff too big to read. A 900-line generated change cannot get a real review, so the reviewer skims and approves. Treat Size reviewable as a stop sign: split first, then review the pieces.
• Pre-ticking the whole list. A checklist where nothing is ever unticked is a ritual. The unticked items are the deliverable; if a real review never turns one up, you are reading too lightly.
• Trusting the bot as a sign-off. A green Bugbot or Copilot pass is a checklist of mechanics, and documented cases show these tools flagging real bugs even after a human approved. That cuts both ways: lean on them for mechanics, and keep intent and architecture on the human.

Two honest edge cases sit beyond the simple rules. The large diff you cannot split. A generated migration or a mechanical rename can legitimately touch hundreds of lines. Here you review by category rather than line by line: confirm the transformation is uniform, spot-check a representative sample, and lean on a test suite that proves behavior held, then tick Size reviewable with that approach noted. The non-deterministic agent. When an agent ran a loop of edits and commands, the same prompt may not reproduce the diff, and the agent cannot reliably explain why it chose a given path. Review the artifact that exists, the diff and the test results, and treat the agent's narration as a hint to verify rather than a record to trust.

On a team, one person's standard does not survive thirty pull requests a day, so the checklist has to live in artifacts. Adopt a pull request template that records the assistant, the prompt or plan, the new dependencies (ideally none), and what the author verified, which turns each review into checking a claim rather than starting cold. Make the size ceiling a shared policy, not a personal habit, since the defect-density and review-speed data only pay off when everyone keeps changes small. And run the same checklist across the team so a busy day does not quietly lower the bar. For the reasoning behind every item, send people to the Reviewing AI Code Safely guide; for the steps that precede and follow this gate, see the AI Coding Session Brief and Testing AI-Generated Code. Then start small on your next real change: open the full diff, confirm every new import is real, and keep the pull request small enough that the next person can run this exact list.