Code Review Checklist for Authors and Reviewers (2026)

Direct answer

A code review checklist should run in priority order - correctness, then security, then design, with style last because style belongs to a formatter and not a reviewer. Split it into an author pre-flight that makes the change reviewable and a reviewer pass that judges it. Delegate every mechanical item to tooling. This page ships four copy-pasteable checklists: general, security, performance, and database migration. Verified 2026-10-19.

Why a checklist beats reviewing from memory

Everyone thinks they review the same way every time. Nobody does. Attention drifts, the same three habitual comments come out, and the security question that mattered on Tuesday gets skipped on Friday. A checklist is not a bureaucratic ritual - it is a way to make coverage consistent regardless of mood, time pressure, or how much you like the author.

The best checklists are short, split by role, and ruthless about what they exclude. The single biggest mistake is loading a checklist with items a machine should own - spacing, import order, lint rules - which trains reviewers to skim past the whole thing. A checklist earns trust by containing only judgement calls a human has to make.

One honesty note up front, because this site does not do unsourced confidence: we could not find an independent study measuring whether code review checklists improve defect detection (checked 2026-10-19). The argument for them is mechanistic rather than empirical. What we do have hard data on is the thing at the top of the author checklist - PR size - and it is the strongest finding in our own dataset.

For a one-line definition to drop in a wiki, see the code review checklist glossary entry.

What order should a code review checklist run in?

Direct answer: Correctness, security, design, style. In that order, every time. Correctness first because a wrong change is worthless regardless of how clean it is. Security second because the cost of missing it is asymmetric. Design third because it governs future cost. Style last, and ideally never reached, because a formatter has already settled it. Verified 2026-10-19.

Order matters because attention is finite and runs out. If style is near the top, reviewers spend their freshest attention on the layer a machine already owns and arrive at the correctness questions tired.

Priority	Layer	Who should own it	What happens if a human owns it instead
1	Correctness and edge cases	Human, with AI first pass	Nothing - this is the job
2	Security and authorization	Human, with SAST and AI first pass	Nothing - this is the job
3	Design, naming, maintainability	Human	Nothing - this is the job
4	Tests actually asserting behaviour	Human, with AI test-gap analysis	Nothing - this is the job
5	Lint rules, unused vars, simple bugs	Linter in CI	Review comments that should have been a config file
6	Formatting, import order, quote style	Formatter on save	Merge conflicts, style arguments, lost reviewer goodwill

Everything from row 5 down is a tooling gap if it appears in review. See what is a linter for the four-layer model this ordering comes from.

The author pre-flight checklist

Half of a fast review happens before the reviewer opens the PR. Run this on yourself first:

### Author pre-flight - before I request review

Scope
- [ ] This PR does ONE thing. Refactors are split out from behaviour changes
- [ ] The diff is small. If it is over ~400 lines of meaningful change, I have a reason
- [ ] Generated files, lockfiles and vendored code are in separate commits or excluded

Self-review
- [ ] I read my own diff line by line, in the review UI, as if a stranger wrote it
- [ ] I understand and can defend every line, including the ones I did not write
- [ ] No debug logging, commented-out code, stray TODOs, secrets or test credentials

Description
- [ ] The title says what changed in one line
- [ ] The body says WHY, and what alternative I rejected
- [ ] Linked to the issue / ticket / incident
- [ ] Screenshots or terminal output for anything user-visible
- [ ] I named the risky files and told the reviewer where to focus

Verification
- [ ] Tests pass locally AND in CI
- [ ] I added tests for the new behaviour, not just for the happy path
- [ ] I ran the thing. Not just the tests - the actual thing
- [ ] Migrations, feature flags and config changes are called out explicitly

Reviewer
- [ ] The right person is requested - the one who owns this code, not the one who is online
- [ ] If this is urgent, I said so and said why

The self-review line is the highest-value item on this page. Reading your own diff as if a stranger wrote it catches a startling share of defects before anyone else spends a minute. The reviewer’s job is to check your work, not to be your first reader.

The size line deserves data rather than folklore. Our harvest of 2,896 human-authored merged PRs across 10 repositories found a median of 63 changed lines across 3 files, with p75 at 205, p90 at 628 and p99 at 4,584 lines; 74.3% were under 200 lines (GitHub GraphQL API, 2026-10-18, published in how big should a pull request be). So the median real PR is already small. The problem is the tail.

And the reason the tail matters: inline review threads per 100 changed lines fall from 1.55 on PRs under 50 lines to 0.085 on PRs over 1,000 lines - an 18-fold drop in scrutiny density - and 52% of merged PRs over 1,000 lines carried zero inline review comments. Honest counterpoint from the same dataset: absolute comment counts rise with size (Spearman rho +0.355), so large PRs are not ignored, just reviewed far less per line.

One correction worth making, because this cluster repeats it constantly: there is no Google 200-line rule. Verified at google.github.io/eng-practices on 2026-10-18, Google’s actual text is “100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large.” The 200-to-400 figure people half-remember is SmartBear’s, it describes how much to review in one sitting rather than how large a change should be, and it comes from the 2006 Cisco program. Say so when you cite it. See pull request size best practices.

The general reviewer checklist

Direct answer: Work correctness first, then security, then tests, then design, and stop before style. Not every section applies to every PR - a docs change does not need the security pass. Depth should scale with blast radius, not with diff size. Verified 2026-10-19.

### Reviewer pass - general

Does it do what it claims
- [ ] The code matches the description. If not, one of them is wrong
- [ ] Edge cases: empty, null, zero, negative, max, unicode, very long, duplicate
- [ ] Off-by-one, boundary and loop-termination conditions are right
- [ ] Error and failure paths are handled, not just the happy path
- [ ] Errors are handled at the level that can actually do something about them
- [ ] No swallowed exceptions, no bare except, no ignored return values
- [ ] Concurrency: no shared mutable state without protection, no obvious races
- [ ] Idempotency where retries are possible - webhooks, queues, payment calls

Tests
- [ ] Tests assert behaviour, not that the code ran without throwing
- [ ] New logic and its edge cases are covered, not just the happy path
- [ ] Tests are deterministic - no reliance on wall clock, ordering, network or sleep
- [ ] A test fails if you revert the fix. (Ask the author if unsure. This catches a lot)
- [ ] Test names describe the scenario, so a failure is readable in CI output

Design and change cost
- [ ] Names reveal intent; the code reads without the PR description
- [ ] No needless complexity, no abstraction with exactly one implementation
- [ ] Fits existing patterns, or explicitly justifies deviating
- [ ] No copy-pasted duplication that should be shared - and no premature sharing of
      code in two domains that will diverge
- [ ] Public API / interface changes are deliberate and documented
- [ ] Nothing here will be impossible to delete later

Operability
- [ ] Logging is sufficient to debug this at 3am, and contains no secrets or PII
- [ ] Metrics or traces exist for anything that can silently fail
- [ ] Feature flags have a documented default and a removal plan
- [ ] Config changes are backward compatible with the currently running version

Not on this list, on purpose
- Formatting, import order, quote style, line length: the formatter owns these
- Lint rules and unused variables: the linter owns these
- Dependency CVEs: the SCA scanner owns these

Notice what is absent. If your reviewers still comment on formatting, you have a linter and formatter gap, not a review-discipline problem.

The security reviewer checklist

Direct answer: Broken access control first, because it is the category automated static analysis is structurally worst at and the one a human reviewer is uniquely positioned to catch. SAST covers injection and taint well. The human’s job in a security pass is the authorization question that depends on intent the scanner cannot read. Verified 2026-10-19.

### Reviewer pass - security

Authorization (do this first - SAST cannot)
- [ ] Every new endpoint / handler / resolver has an explicit authz check
- [ ] The check matches what its SIBLINGS enforce. A missing check is invisible
      unless you compare against neighbours
- [ ] Object-level authz, not just route-level: can user A read user B's record by ID?
- [ ] Tenant / org scoping is applied in the QUERY, not filtered after fetch
- [ ] Admin-only paths are actually admin-only, including any new bypass flag
- [ ] No authorization decision made on client-supplied data

Input and output
- [ ] All external input validated at the boundary, with an allowlist not a denylist
- [ ] Parameterised queries only. No string concatenation into SQL, shell, or LDAP
- [ ] No unsafe deserialization of untrusted data
- [ ] Output encoding appropriate to the sink - HTML, attribute, JS, URL
- [ ] File paths from user input are canonicalised and confined to a base directory
- [ ] Server-side requests to user-supplied URLs are allowlisted (SSRF)

Secrets and data
- [ ] No hardcoded credentials, tokens or keys - including in tests and fixtures
- [ ] Secrets come from the secret manager, not from env defaults in code
- [ ] Nothing sensitive in logs, error messages, URLs or analytics events
- [ ] PII handling matches the data classification for this system
- [ ] New data at rest is encrypted if the classification requires it

Dependencies and supply chain
- [ ] New dependencies are justified. Could this be 20 lines instead?
- [ ] New dependencies are maintained, popular enough to be scrutinised, and pinned
- [ ] The lockfile changed consistently with the manifest - no unexplained drift
- [ ] No typosquat-shaped package names
- [ ] CI workflow changes do not expose secrets to forked-PR triggers

Session and crypto
- [ ] No hand-rolled crypto. Named primitives from a maintained library
- [ ] Tokens have expiry; sessions are invalidated on privilege change
- [ ] Rate limiting / lockout on anything authentication-adjacent
- [ ] Timing-safe comparison for secrets and tokens

The authorization section is at the top for a reason. Broken access control is the vulnerability class deep static analysis is structurally worst at, because whether a missing check is a bug or a deliberately public endpoint depends on intent the scanner cannot read. It is also the class an AI reviewer with repository context is genuinely good at, because comparing a new handler against its siblings is a reasoning task. See AI code review for security, SAST vs DAST and what is CodeQL for what the deterministic layers do and do not cover.

The performance reviewer checklist

Direct answer: Look for complexity that scales with data you do not control - N+1 queries, unbounded result sets, work inside loops that touches the network. Most performance defects in application code are not algorithmic, they are a query or a request that should have been one and is now one per row. Verified 2026-10-19.

### Reviewer pass - performance

Data access
- [ ] No N+1 queries. Is there a query inside a loop, or a lazy-loaded relation
      accessed per item?
- [ ] Every query that can return many rows has a LIMIT or pagination
- [ ] New queries have an index that supports them. Check the WHERE and ORDER BY
- [ ] No SELECT * on wide tables being pulled across the network
- [ ] Bulk operations are batched, not one round trip per item
- [ ] Transactions are as short as possible and do no network I/O inside

Work in the request path
- [ ] Nothing synchronous and slow in a user-facing path - email, PDF, third-party API
- [ ] External calls have timeouts. All of them. Including the ones in libraries
- [ ] External calls have a retry policy with backoff, and a circuit breaker if hot
- [ ] Caching has an explicit invalidation story, not just a TTL and hope

Algorithmic and memory
- [ ] Complexity is acceptable for realistic input size, not for the test fixture
- [ ] No loading an unbounded collection into memory - stream it
- [ ] No accidental quadratic behaviour from a nested lookup that should be a map
- [ ] Large payloads are streamed, not buffered

Front end, if applicable
- [ ] No new render-blocking resource on a critical path
- [ ] Bundle impact of a new dependency is known and acceptable
- [ ] Lists that can grow are virtualised or paginated

Verification
- [ ] Any claim about performance has a number attached, measured not estimated
- [ ] The measurement was taken at production-realistic scale

The last item is the one reviewers skip. “This should be faster” is not a review finding, it is a hypothesis. Ask for the number.

The database migration reviewer checklist

Direct answer: Backward compatibility first. A migration that is not compatible with the currently deployed application code breaks production during the deploy window, not after it. Then locking behaviour, reversibility, and whether it was timed at production row counts rather than against a dev database. Verified 2026-10-19.

This is the highest-value checklist on the page and the one most teams do not have, because migration defects are the subset of code review failures that cannot be rolled back cheaply.

### Reviewer pass - database migration

Backward compatibility (the one that causes outages)
- [ ] This migration is compatible with the CURRENTLY DEPLOYED application code,
      because both will be live simultaneously during the deploy
- [ ] Column drops and renames are split across releases: add new, dual-write,
      backfill, switch reads, stop writing old, THEN drop
- [ ] No NOT NULL added without a default, or without a verified-complete backfill
- [ ] No type narrowing without a verified data audit
- [ ] Enum / constraint additions do not reject rows the old code still writes

Locking and duration
- [ ] Known lock behaviour for this operation on THIS database engine and version
- [ ] Index creation uses the concurrent / online variant where available
- [ ] Timed against production-scale row counts, not a dev database with 400 rows
- [ ] Long migrations run outside the deploy, as a separate controlled job
- [ ] Statement and lock timeouts are set so a stuck migration fails fast

Reversibility
- [ ] A down migration exists, OR a documented forward fix exists and is tested
- [ ] Rollback of the APPLICATION is safe against the new schema
- [ ] Destructive steps are in their own release, after the new code is proven

Backfill
- [ ] Backfill is batched, resumable, and does not hold one long transaction
- [ ] Backfill progress is observable, and it can be paused
- [ ] Row counts before and after are checked, not assumed

Blast radius
- [ ] Replica lag impact considered for large writes
- [ ] Downstream consumers - ETL, analytics, search indexes - are accounted for
- [ ] Anything irreversible has a named human approver, not just a passing CI check

Two notes on process rather than content. Migrations are the clearest case for a CODEOWNERS-based second reviewer on a specific path rather than a blanket two-reviewer rule. And it is worth knowing that no product in our tracking does CODEOWNERS-based routing of individual findings (verified 2026-10-18) - that is a genuine market gap, so the routing has to be done with path-based review requirements rather than by the review tool.

What to delegate to tools

A human reviewer is expensive and their attention is finite. Spend it on correctness, security and design, and let automation own the mechanical layer.

Concern	Owner	Why
Formatting, style, import order	Formatter (Prettier, Black, gofmt)	Deterministic, zero judgement, ends arguments by fiat
Lint rules, unused vars, simple bugs	Linter (ESLint, Ruff, golangci-lint)	Free to run, same answer every time, auditable
Known-vulnerable dependencies	SCA scanner	A database lookup, not a reasoning task
Injection and taint paths	SAST	Needs a dataflow graph, not a reader
First-pass logic and edge cases	AI reviewer	Fast, cheap relative to a human, catches the obvious
Correctness, authorization, design	Human reviewer	Requires intent, context and accountability
Irreversible operations	Named human approver	A passing check is not accountability

An AI reviewer runs the mechanical and first-pass parts of these checklists automatically, so the human opens a change that has already been triaged. This is the single best use of the technology, because it attacks the largest measurable chunk of PR lifetime. Our dataset of 2,189 merged PRs found open-to-first-review at p50 8.7 hours but p90 212 hours, p95 482 hours and p99 1,300 hours, while first-review-to-merge is only 6.7 hours at p50 and first-approval-to-merge is 1.1 hours. The median PR spends 52.7% of its open-to-merge life waiting for the first human (verified 2026-10-18, pull request review time). A bot that comments in four minutes collapses the tail.

CodeRabbit posts a PR summary and inline suggestions within minutes, pairs an LLM with 40-plus open source linters, and accepts custom review instructions in natural language - so you can encode parts of these checklists as standing rules. Current pricing: Essentials $24/dev/mo annual covering 1 linked repository, Team $48 covering 5, Advanced $72 covering 10 (verified 2026-10-18). The repo cap is the most consequential constraint for multi-repo teams and most comparisons omit it. Also note CodeRabbit is no longer free for private repos - free accounts get 1 private PR review per hour, summary only. See CodeRabbit pricing and CodeRabbit custom rules.

Greptile indexes the whole repository and reviews each PR with that context, which helps on the “does this fit existing patterns” and cross-file correctness items a diff-only reviewer cannot judge. Pricing: Starter free for 1 active dev with 50 credits/mo, Pro $30/seat/mo where a seat is any dev who received a review, and credits are per author and do not pool (verified 2026-10-18). See Greptile pricing.

Qodo pairs agentic PR review with automatic test generation, which directly supports the tests section - it proposes cases for uncovered paths. Flat team fee around $30/mo up to 30 users plus credits at $0.012 each pooled across the team, in packs of 2,500 / 5,000 / 20,000, with no rollover (verified 2026-10-18). See Qodo pricing.

Two entitlement facts that change how you wire the gate:

• GitHub Copilot’s code review can approve a pull request. GitHub’s docs, verified 2026-10-18: when approvals are enabled, Copilot “can submit an approving review that satisfies your repository’s required-approval rule the same way a teammate’s approval would.” Off by default, configurable at enterprise, org and repo level. A machine that can satisfy a required approval weakens a single-approval rule rather than strengthening it - relevant to any separation-of-duties control. Also, code review is included on Copilot Pro at $10; only Copilot Free is excluded. See GitHub Copilot code review.
• Anthropic’s Code Review never approves or blocks, which is the safer default for a regulated team. It is configured via a REVIEW.md read from the base branch rather than the PR’s own diff, so a PR cannot alter its own review rules (verified 2026-10-18). It went GA on 15 October 2026 for Claude Team and Enterprise. See Claude Code review.

For the wider field see best AI PR review tools and how to evaluate an AI code reviewer.

How many reviewers, and how do you keep it from becoming box-ticking?

Direct answer: One competent reviewer for most changes. Our data: 59.2% of merged PRs had exactly one approver, 14.5% had two, mean 1.08. Reserve two-reviewer rules for high blast-radius paths and enforce them with CODEOWNERS on those paths rather than as a blanket policy, because a blanket rule doubles waiting cost and produces diffusion of responsibility. Verified 2026-10-18.

Guardrails that keep a checklist from curdling into ritual:

• Not every section applies to every PR. A docs change does not need the security pass. Use judgement about which parts are relevant and say which you skipped.
• Depth should scale with blast radius, not diff size. A payment path deserves the full pass; a copy tweak does not. Match review depth to consequence.
• Separate blocking from optional. A genuine defect blocks the merge; a preference is a nitpick and must be labelled as one. Conflating the two is the top complaint authors have about both human and bot reviewers. See how to give code review feedback and pedantic code reviews.
• Keep it living. When a class of bug slips through, add one line. When an item has never caught anything in a year, delete it. A checklist that only grows is a checklist nobody reads.
• Never make it a form to fill in. The moment a checklist becomes a required comment template, it becomes a thing people paste without reading. Keep it a reference, not a gate.

For the surrounding process - when to request changes, how to handle disagreement, how to close out a review - see pull request review best practices and code review best practices.

How we verified this

Checked on 2026-10-19: internal link targets against the live content tree in this repository; and the absence of any independent study measuring whether code review checklists improve defect detection, which we state as a limitation rather than papering over.

Carried from the 2026-10-18 verification pass:

• Google’s engineering practices wording, verified at google.github.io/eng-practices: “100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large.” There is no 200-line rule. SmartBear’s 200-400 LOC / 60-90 min / 70-90% figures are real and verbatim on smartbear.com but come from the 2006 Cisco program.
• GitHub Copilot approval behaviour, verified in GitHub’s documentation: “When approvals are enabled, Copilot can submit an approving review that satisfies your repository’s required-approval rule the same way a teammate’s approval would.” Off by default. Also that code review is included on Copilot Pro ($10) and only Copilot Free is excluded, and that required_approving_review_count ranges 0-6 on GitHub while GitLab’s maximum is 100.
• Anthropic Code Review mechanics: GA 15 October 2026 to Claude Team and Enterprise, configured via REVIEW.md read from the base branch rather than the PR’s diff, never approves or blocks, never builds or runs your code.
• CodeRabbit pricing and the linked-repo caps (Essentials 1 repo, Team 5, Advanced 10, Enterprise 20), the September 2026 Pro-to-Essentials rename with prices unchanged, the loss of the free private-repo tier, and the 40-plus bundled linters.
• Greptile Pro at $30/seat/mo with per-author non-pooling credits and the “seat = any dev who received a review” definition.
• Qodo’s flat team fee with $0.012 credits pooled across the team and no rollover.
• That no product does CODEOWNERS-based routing of individual findings.

Our own data, harvested from the GitHub GraphQL API on 2026-10-18 and published on this site:

• PR size and scrutiny (n=2,896 human-authored merged PRs, 10 repos, 104 bots removed, created 17 Apr to 17 Oct 2026): median 63 changed lines / 3 files; p75 205, p90 628, p99 4,584; 74.3% under 200 lines; inline threads per 100 changed lines falling from 1.55 to 0.085; 52% of 1,000+ line PRs with zero inline comments; absolute comment counts rising with size at Spearman rho +0.355. Per-repo spread is wide - pandas ships 96.9% of PRs under 200 lines, VS Code 57.4% - which kills any universal-threshold framing. Published in how big should a pull request be.
• Review latency (n=2,189 human-authored merged PRs, 12 repos, bot authors/reviewers and self-reviews excluded): open-to-first-review p50 8.7h, p75 66h, p90 212h, p95 482h, p99 1,300h; first-review-to-merge 6.7h at p50; first-approval-to-merge 1.1h; the median PR spending 52.7% of its open-to-merge life waiting for the first human; 59.2% of PRs with exactly one approver, 14.5% with two, mean 1.08. Published in pull request review time. Disclosed limits: only merged PRs are in frame, which biases latency down, and Kubernetes and Rust were excluded from the approver analysis as Prow and bors artifacts.

What we could not verify:

• No independent study measuring checklist effectiveness on defect detection (checked 2026-10-19). The case for checklists on this page is mechanistic reasoning, not evidence, and we label it as such.
• No independent false-positive rate, precision figure or noise measurement has been published for any shipping commercial AI code reviewer. SWE-PRBench and CR-Bench publish false-positive data, but for bare models in fixed harnesses rather than purchasable products. Anthropic’s own published figures for its Code Review (84% detection on 1,000+ line PRs, under 1% false positives) are vendor-published and unreplicated.
• No measurement exists of how often a human reviewer actually completes any given checklist section. The claim that attention runs out in priority order is reasoning from how people behave, not a study.
• The optimal number of reviewers. Our 1.08 mean describes what teams do, not what is optimal. We have no causal evidence that one is better than two.

Disclosure: Gitar is a paid sponsor of aicodereview.cc and was acquired by Sonar in May 2026. It is not recommended on this page because it is a fixing agent rather than a checklist tool, and it has no published third-party benchmark.

Recommendations

Criteria: what catches defects, what costs reviewer attention, and what the data actually supports.

If you adopt one thing from this page: the author pre-flight, specifically the self-review line and the one-thing-per-PR line. Both are free, both reduce review rounds, and PR size is the only item here with a measured effect in our own data.

If you adopt a second thing: the migration checklist. Migration defects are the subset of review failures you cannot roll back cheaply, and almost no team has a written list for them.

For the reviewer pass: run it in order - correctness, security, design - and stop before style. Put the security section’s authorization block first within that pass, because it is the category your SAST scanner is structurally worst at and your reviewer is uniquely positioned to catch.

For tooling: one AI reviewer posting a first pass within minutes, one linter and formatter in CI, one SAST and one SCA gate. CodeRabbit if you want the deterministic linter bundle and custom natural-language rules, mindful of the 1-repo cap on Essentials. Greptile if cross-file pattern consistency is your main gap. Anthropic Code Review if you need a reviewer that structurally cannot approve a PR.

For approval policy: one reviewer by default, CODEOWNERS-enforced second reviewer on auth, payments, migrations and infrastructure paths. And if you rely on a single required approval as a separation-of-duties control, turn Copilot’s approval capability off - a machine that can satisfy that rule defeats the control.

What not to do: do not turn the checklist into a required comment template, do not put style items on it, and do not cite the 200-line rule. It does not exist.

Further reading

• Pull Request Review Best Practices
• Code Review Best Practices
• How Big Should a Pull Request Be? Our Own Data
• Pull Request Review Time - Our Own Data
• How to Give Code Review Feedback That Lands
• How to Review AI-Generated Code
• 12 Common Code Review Mistakes
• Best AI PR Review Tools in 2026