The Code Review Checklist Seniors Actually Use

TL;DR: A useful code review checklist is ordered by leverage: understand → correctness → tests → blast radius → security → evolvability. It deliberately excludes style (machines do that) and it fits a 200-400 line PR; no checklist survives a 1,500-line diff. Below: the checklist, and the reasoning that makes each item stick.

Most code review checklists fail the same way: twenty items, pasted into a template, checked by nobody after week two. They fail because they list virtues instead of questions in priority order, and because they ask humans to verify things machines verify better. Here is the version that survives, with the evidence for why it's shaped this way.

Why order matters: what review actually finds

Two research results define what a checklist should optimize for.

First: Mäntylä and Lassenius classified the defects found in code reviews and discovered 75% are evolvability defects: structure, naming, and clarity problems that don't change what the software does, only how expensive it is to change next month. Only ~25% are functional bugs. A checklist that's pure bug-hunt optimizes the minority case.

Second: when Bacchelli and Bird studied review at Microsoft, they found the central difficulty of reviewing is understanding the change itself, and that review's measured outcomes lean heavily toward knowledge transfer and better solutions rather than defect counts. Most bad reviews come from a reviewer judging code they hadn't understood. Laziness is rarer than you'd think.

Hence the ordering below: comprehension first, the irreversible stuff in the middle, the 75% category last-but-never-skipped, style nowhere.

The checklist

0. Preconditions (before you read a line)

• Is it reviewable at all? More than ~400 changed lines of real logic → ask for a split, don't attempt heroics. SmartBear's research caps effective review at 200-400 LOC and 60-90 minutes; beyond that you're skimming with extra steps. Ballooning diffs are how PRs get stuck.
• Is CI green and lint clean? Never spend human attention on what a machine already flagged.

1. Understand

• Can you state, in one sentence, what this change does and why? If not, your first comment is a question.
• Read the ticket/description before the diff. Review the intent against the implementation; diffs alone show you what changed, never what should have.
• Start from the entry point (route, handler, public function), not from the top of the file list.

2. Correctness

• Walk the failure paths: what happens on null, empty, timeout, partial failure, double-invocation? Happy paths review themselves; the bugs live in the branches nobody demoed.
• Boundaries: off-by-one, timezone, encoding, pagination edges, concurrent access to anything shared.
• Does the change do what the ticket asked, and nothing extra that nobody asked for?

3. Tests

• Do the tests test behavior someone depends on, or do they restate the implementation? A test that breaks on every refactor is a maintenance cost dressed up as a safety net.
• Would these tests have failed before this change? A bug fix with no failing-test-first is a bug fix on faith.
• Is the risky part covered (the branch, the edge, the failure path) or just the easy assertions?

4. Blast radius

The irreversible-mistakes section. Slow down here even when everything else is clean:

• Migrations: reversible? Safe on a table of production size? Deployable without downtime?
• Contracts: does this change an API, event shape, or shared schema someone else consumes? Who breaks, and do they know?
• Rollback: if this deploys and misbehaves, is turning it off a flag-flip or an incident?
• Config and deps: new dependency, changed default, touched auth or payment path? These deserve a second look regardless of diff size.

5. Security (when the diff touches its surfaces)

• Input from users or external systems: validated, bounded, escaped?
• Authorization checked at the resource, not just the route?
• Secrets out of code, out of logs? Any PII newly logged or stored?

6. Evolvability - the 75%

• Will the next person - six months from now, without the ticket open - understand this? That person is the review's real client.
• Names tell the truth? A function called validateUser that also creates a session is a future incident report.
• Duplication introduced that will now drift in two places?
• Is the shape right: logic in the layer where the next feature will look for it?

This is the section teams skip when rushed, and it's the majority of review's measured value. It's also where the tone rules matter most: comment on the code, offer the alternative, and say what's good, because praise is signal too.

7. What's deliberately absent: style

Formatting, import order, naming conventions: if a human can comment on any of it, your tooling has a gap. Fix the linter, not the author. AI reviewers increasingly cover the mechanical middle ground too (see the honest breakdown in AI code review tools), which frees human review for the parts above that machines still miss.

Using it without becoming a bureaucracy

• Run it as a mental sweep. Nobody ticks boxes; the order is the habit. After a few weeks, "understand → correctness → tests → blast radius → security → evolvability" is just how you read a diff.
• Scale depth with risk. A copy change gets pass 0 and a merge. A migration gets the full sweep twice.
• Timebox honestly. One sitting, 60-90 minutes max. Can't finish? The PR is too big. That's feedback for the author, and the small-PR playbook is the fix.
• The checklist can't fix a broken pipeline. If PRs wait days for pickup or one senior reviews everything, start with the best-practices hub - a great checklist executed after a three-day queue is still a slow review.

A checklist won't make a bad reviewer great. It makes a decent reviewer consistent, and consistency, applied at 200-400 lines a sitting, compounds into a codebase that more than one person can safely change.