Pull Request Review Best Practices: The 2026 Playbook

Direct answer

Review in this order: correctness, security, design, style last, and let a formatter own style entirely. The 2026 change is that a machine usually comments first, which means your first configuration decision is severity gating, not review assignment. c-CRAB (arXiv 2603.23448) found four review agents collectively matched only 41.5% of 234 validated human comments, so AI review supplements the human pass rather than replacing it. Verified 2026-10-18.

Pull request review best practices

Direct answer: Keep changes small, review correctness before style, label every comment blocking or non-blocking, respond within a published first-response target, and give the mechanical layer to tools. In 2026 add one more: configure severity gating on your AI reviewer before you turn it loose, because unfiltered machine comments crowd out the human pass. Verified 2026-10-18.

Most pull request review guidance is sound and twenty years old. Be kind, be specific, keep diffs small, separate nitpicks from blockers. None of that has stopped being true. What has changed is the composition of the review itself: on a large share of pull requests in 2026, the first comment on the diff is written by a machine, and a meaningful share of the diff was written by one too.

Almost every best-practice page in this category still assumes two humans and a diff. That assumption is now wrong often enough to matter, and it is the gap this playbook fills.

Here is the practice set, ranked by how much damage its absence causes.

Practice	Why it matters	Owner
Small, coherent changes	Comment density falls 18x from sub-50-line to 1,000-line pull requests (our data, 2026-10-18)	Author
Review order: correctness, security, design, style	Attention depletes. Spend it where a machine cannot help	Reviewer
Formatter and linter own all style	Removes the entire class of comment that causes bikeshedding	CI
Every comment labelled blocking or non-blocking	Authors cannot otherwise distinguish “this corrupts data” from “I’d name it differently”	Reviewer
Published first-response target	Median time to first review in our sample was 5.3 hours; p90 was 162.7	Team norm
Severity gating on the AI pass	Default-everything configs bury the two findings that mattered	Tech lead
Author triages bot comments before requesting review	Stops machine output from becoming the review record	Author
Escalate on a timer, not on temperature	Two round trips, then a call	Team norm

The rest of this page works through each of those, with the evidence behind them and what to configure.

For the broader discipline including feedback technique, review metrics and team anti-patterns, code review best practices is our deeper companion piece at roughly 8,000 words. This page is specifically about the pull request review loop and what AI changed about it.

What should our team include in pull request reviews?

Direct answer: Four things, in priority order: correctness including failure paths, security of untrusted input and authorisation, design fit with the surrounding system, and test quality. Deliberately exclude formatting, naming conventions and import order, because a formatter in CI should make those comments impossible. Everything on your list should be a judgement a machine cannot make. Verified 2026-10-18.

The most common defect in a team’s review standard is that it is too long. A 40-item checklist does not get applied; it gets skimmed and then ignored, and the team concludes checklists do not work.

Include these.

Correctness, including the paths nobody tests. Does the code do what the description says? Boundary conditions: empty, null, zero, maximum, unicode, concurrent. Error paths, not just the happy path. Loop termination and off-by-one. Shared mutable state.

Security on the two axes that actually produce incidents. Untrusted input reaching a dangerous sink (injection, deserialisation, path traversal), and missing or wrong authorisation checks. Authorisation is the one AI reviewers are worst at, because whether a given endpoint should check a permission is a property of your product, not of your code.

Design fit. Does this change match how the rest of the system does the same thing, or does it invent a second way? If it invents one, is the reason stated? This is the highest-value human judgement in review and the one most often skipped under time pressure.

Test quality, not test presence. Does the test assert behaviour, or does it assert that the code ran? Would it fail if the implementation were wrong? Coverage percentage answers neither question.

Exclude these.

Formatting, spacing, brace style, import order. Owned by Prettier, Black, gofmt, rustfmt. If a human is commenting on these, fix CI.

Naming conventions that a linter can express. If you can write the rule, write the rule.

Anything you have argued about twice. The second time an argument recurs, the outcome belongs in the style guide or the linter, not in another thread.

This split is not about politeness. It is about where the finite resource goes. Our measurement of 2,896 merged pull requests found a mean of 0.28 inline review threads on changes under 50 lines. Reviewers are not generating many comments. Each one you spend on import order is one not spent on the authorisation check.

For a copy-pasteable version split by role, see our code review checklist.

How to review a pull request effectively

Direct answer: Read the description and the tests first, then the diff in dependency order rather than file order, then run the code if the change is risky. Work correctness to style, stopping when your attention goes. Timebox to 60 minutes maximum per sitting, which is SmartBear’s published ceiling, and split anything that needs longer. Verified 2026-10-18.

A specific sequence, in the order that wastes the least attention.

1. Read the description before the diff. If you cannot tell what the change is supposed to do, that is the first comment, and you should stop there. Reviewing a change whose intent you are guessing at produces comments about the implementation of something that should not have been built.

2. Read the tests next. Tests are the author’s own statement of what the change does. If the tests and the description disagree, you have found something before reading a single line of implementation.

3. Read the diff in dependency order, not file order. GitHub sorts alphabetically, which is almost never the order the change makes sense in. Find the entry point, follow the call. For a layered change, read the schema or interface first.

4. Run it, if the blast radius justifies it. For anything touching auth, payments, data migration, or a public API, pull the branch. Most reviewers never do this and most of the time that is correct. For the top 5% of changes by risk it is the only review that counts. Note that Anthropic’s Code Review, by documented design, never builds or runs your code (verified 2026-10-18), so this remains entirely a human job no matter which tool you buy.

5. Make the pass in priority order. Correctness, then security, then design, then style. When your attention runs out, stop and say so: “I reviewed the handler and the migration carefully, I skimmed the tests.” An honest partial review is more useful than a dishonest complete one, and it tells the author where to ask for a second pair of eyes.

6. Stop at 60 minutes. SmartBear’s guidance, derived from the Cisco program, recommends an inspection rate under 500 lines per hour and sessions no longer than 60 minutes (smartbear.com, verified 2026-10-18). Treat 60 as the ceiling, not the plan.

One thing to drop: the habit of reading the whole diff before commenting. Comment as you go. A reviewer who reads 900 lines and then writes comments from memory writes worse comments than one who writes them in place.

Pull request review checklist for developers

Direct answer: Two short lists, one for the author before opening and one for the reviewer. The author’s job is to make the change cheap to review; the reviewer’s job is to judge it. Keep both under a dozen items, keep style off both, and delete any item that has never caught anything. Verified 2026-10-18.

Author, before requesting review:

- [ ] I read my own diff line by line and understand every line
- [ ] The change is one coherent idea I can state in a sentence without "and"
- [ ] The description says what changed and WHY, and flags the risky files
- [ ] Tests pass, and new behaviour has a test that would fail without the change
- [ ] Generated files, lockfiles and codemod output are called out as such
- [ ] I triaged every AI reviewer comment: fixed, replied, or dismissed with a reason
- [ ] No debug logging, commented-out code, secrets, or stray TODOs
- [ ] If any of this code was AI-generated, I verified it does what I think it does

The last two lines are the 2026 additions, and they are the ones that get skipped.

Reviewer, in order:

Correctness
- [ ] Does what the description claims, including failure paths
- [ ] Boundary conditions: empty, null, zero, max, concurrent, unicode
- [ ] No obvious race or shared-state mutation

Security
- [ ] Untrusted input validated before it reaches a sink
- [ ] Authorisation checked where the product requires it
- [ ] No secrets in code, config, or logs; new deps pinned and plausible

Design
- [ ] Matches how this system already solves this problem, or says why not
- [ ] No premature abstraction, no copy-paste that should be shared

Tests
- [ ] Assertions test behaviour, not execution
- [ ] Deterministic: no reliance on timing, ordering, or network

Nothing about style. That is deliberate and it is the single highest-impact edit most teams can make to their existing checklist.

The honest caveat about the author checklist. The self-review line is the highest-value item here, and it is the one AI-assisted authoring most erodes. When you generated the code, reading your own diff is not re-reading your own thinking, it is reading someone else’s work for the first time. Budget for that. Our guide to reviewing AI-generated code goes deeper.

Pull request review guidelines that catch bugs without slowing releases

Direct answer: Attack latency, not thoroughness. Publish a first-response target rather than a merge target, cap round trips at two before a synchronous call, make non-blocking comments explicitly non-blocking, and scale review depth to blast radius. Our 2026 data found median time to first review at 5.3 hours but a p90 of 162.7 hours. The tail is the problem, not the median. Verified 2026-10-18.

Teams that try to speed up review usually try to review less carefully. That is the wrong lever, because thoroughness is not what is slow. Waiting is what is slow.

Guideline	Mechanism	What it costs
Publish a first-response target, not a turnaround target	First response unblocks the author; full approval does not need to be fast	Nothing. It is a norm, not a process
Two round trips, then a call	Caps the worst case. Most multi-day reviews are 4+ shallow exchanges	15 minutes of synchronous time
Label every comment blocking or non-blocking	Authors stop treating preferences as gates	One prefix per comment
Scale depth to blast radius	A copy change and a payments change do not get the same pass	Requires judgement, not policy
Author triages the AI pass first	Human opens a pre-cleaned diff	Shifts work to the author, who has the context
Approve with comments, when the comments are non-blocking	Removes an entire round trip	Requires trust. Build it

The tail is where the damage is. In our de-biased subsample of 1,058 merged pull requests, median time to first review was 5.3 hours, 75th percentile 32.4 hours, and 90th percentile 162.7 hours, roughly a week. A median of five hours sounds healthy and hides the fact that one pull request in ten waits a week for a first look. Report p90 on review latency. Reporting the median will make a broken queue look fine.

Slow review causes big pull requests, not the other way round. When review takes two days, batching work into one larger change is a rational response to the queue. If your percentage of pull requests under threshold is poor, measure first-response latency before you coach anyone on decomposition. We go through the size side of this in how big should a pull request be.

AI code review best practices for pull requests

Direct answer: Run the machine pass before a human opens the diff, make the author triage it, and configure severity gating first. The independent evidence says it is a floor, not a replacement: c-CRAB found four review agents collectively matched 41.5% of 234 validated human comments, best single tool 32.1%. No disinterested party has published a false-positive rate for any shipping commercial reviewer. Verified 2026-10-18.

This is the section most pages in this category do not have, and it is the one that has actually changed since 2024.

What the independent evidence says

Every number below is attributed to whoever produced it, because in this market that is the whole story.

Benchmark	Who published it	Finding	Conflict status
c-CRAB (arXiv 2603.23448, v3 dated 7 Apr 2026)	NUS / Zhejiang, one author lists SonarSource	Union of 4 agents matched 41.5% of 234 validated comments. Claude Code 32.1%, Devin 24.8%, PR-Agent 23.1%, Codex 20.1%. 184 PRs, 67 repos	Disclosed below. SonarQube is not among the four tools tested
SWE-PRBench (arXiv 2603.26130)	Independent / foundryhq.ai	8 frontier models at 15 to 31% detection on diff-only. Publishes per-model false-positive rates: Claude Sonnet 4.6 lowest at 0.227, Llama 3.3 70B highest at 0.417. Performance degrades with more context	Not selling a reviewer
CR-Bench (arXiv 2603.11078)	Nutanix	GPT-5.2 single-shot: 27.01% recall at 3.56% precision. Reports a signal-to-noise ratio explicitly because “false positives are costly”. 584 instances, 174 verified	Not selling a reviewer
Martian Code Review Bench	Martian (sells model routing)	CodeRabbit 51.2% F1 / 49.2% precision on ~300k PRs (3 Mar 2026). Open-sourced	Closest thing to a neutral leaderboard
CRBugBench (arXiv 2610.13668)	CMU + Microsoft Research	claude-opus-5 at 79.6% pre-merge recall@5, $2.97/task; human+agent 82.1%. Reports no precision at all	Microsoft co-authored, using copilot-cli as the harness
GitHub ReviewBench	GitHub (vendor) but dataset and runner public at review-bench.ai	219 PRs, 187 repos, 19 languages, sampled from 103.9M PRs. 96.6% agreement with independent human checkers	Auditable vendor research, a category of its own
Entelligence benchmark 2026	Entelligence, which sells a reviewer	Entelligence #1 at 47.2% F1 aggregate	Self-published, self-winning
Greptile internal vs Augment re-run	Both vendors	Greptile scored Greptile 82%. Augment scored Greptile 45% F-score on the same 5 repos, after rebuilding the answer key: “We expanded and corrected the golden comments by reviewing each PR manually”	Both vendor-run. The gap is partly a different answer key, not purely self-dealing
Anthropic Code Review	Anthropic	84% bug detection on PRs over 1,000 lines, under 1% false positives, ~7.5 issues per large change, $15 to $25/review	Vendor-published and unreplicated. An unreplicated sub-1% FP claim is extraordinary

Conflict disclosure for c-CRAB. Verified at source on 2026-10-18 against the v3 author block: five of six authors are academic (National University of Singapore, Zhejiang University), but Ridwan Shariffdeen lists SonarSource as his affiliation. The paper carries a disclaimer that its conclusions do not represent SonarSource policy. Sonar sells SonarQube and acquired Gitar on 21 May 2026, and Gitar is a paid sponsor of aicodereview.cc. SonarQube is not among the four tools c-CRAB evaluates, which blunts the conflict considerably. We call out vendor-funded benchmarks everywhere else on this site, so we call out this one too. The paper’s own abstract states that “the existing review agents taken together can solve only around 40% of the c-CRAB tasks” (read at arXiv on 2026-10-18).

One correction worth carrying. The widely quoted “40 to 70% false positive rate” attributed to c-CRAB is not in that paper. No false-positive rate is reported for any reviewed tool. The phrase “false positive” appears twice, both conceptual, and the instance in section 4.2.1 concerns tuning the authors’ own comment classifier, not the tools under test. If you see that figure cited, it is a miscitation.

And the line that frames all of the above: no party without a commercial stake has published a false-positive rate, precision figure or noise measurement for any shipping commercial AI code reviewer. SWE-PRBench and CR-Bench publish false-positive data, but they measure bare models in fixed harnesses, not products you can buy. That distinction is the entire state of the evidence in October 2026.

Severity gating is the first lever, not the fifth

The default configuration on most AI reviewers is to post everything. That is the single worst setting, because it produces the failure mode that kills adoption: the team learns to collapse the bot section unread, and the two findings that mattered go with the ten that did not.

Configure gating before you configure anything else.

Tool	The gating lever	Behaviour
Greptile	Confidence scores attached to findings	Threshold them. This is the cleanest gating primitive in the market
Claude Code review	REVIEW.md read from the base branch, plus three admin-set depth tiers (Quick / Standard / Deep) per repo	Base-branch config means a pull request cannot alter its own review rules. Never approves or blocks
Cursor Bugbot	BUGBOT.md, resolved by walking up from the changed files	Per-directory rules without a central config
CodeRabbit	Natural-language review instructions in repo config	Encode your checklist as standing rules. 150-file cap on Essentials, 300 on Team and above
Gitar	Confidence fallback	Low-confidence findings become thread suggestions rather than blocking findings. Sonar’s own material says a green build is “evidence, not proof”. Sponsor of this site; no published third-party benchmark
DeepSource	Deterministic static analysis runs before the AI agent sees the code	5,000+ rules filter the mechanical layer out first. Now a Harness product (acquired 9 Sept 2026)

Verified 2026-10-18.

A starting configuration that works for most teams:

1. High severity only, posted inline. Blocking nothing. For the first month, the machine has no merge authority at all.
2. Medium severity collapsed into the summary comment, not inline on the diff.
3. Informational suppressed entirely. You can turn it on later. You will not.
4. After one month, audit what the gate suppressed. If the suppressed bucket contained real defects, loosen by one notch. If it did not, you have your answer.

Do not let the tool block merges until you have run that audit. A reviewer with no published independent false-positive rate should not have veto power over your main branch.

How to stop AI comments crowding out human judgement

This is the practical risk and it is not hypothetical. Our measurement of 2,896 merged pull requests found that 69.8% carried zero inline human review threads and 18.1% had no review event at all. That is a lot of empty space. Drop an unfiltered AI reviewer into it and the review record becomes overwhelmingly machine-authored, which looks like more review and is less.

Four countermeasures, in order of effect.

The author triages bot comments before requesting human review. This is the whole ballgame. If the bot posts nine comments and the author resolves seven before a human arrives, the human sees two. If nobody triages, the human sees nine and starts collapsing threads.

Never let the AI pass satisfy the approval requirement. Anthropic’s Code Review will not approve a pull request by design, which is the correct default. For tools that can approve, turn it off.

Keep the machine out of the design conversation. AI reviewers are weakest at exactly the thing humans are best at: whether this change fits the system, whether the abstraction earns its keep, whether the product should behave this way at all. c-CRAB’s authors note that agent reviews “often consider different aspects from the human reviews”, which is an argument for complementarity, not substitution.

Measure human comment rate before and after adoption. If your inline human threads per pull request fall after you install an AI reviewer, you did not add a layer, you replaced one. That is the number to watch, and almost nobody watches it. How to evaluate an AI code reviewer sets out a 14-day protocol for measuring this on your own repositories rather than trusting a vendor benchmark.

Reviewing AI-generated code is a different job

When the author did not write the code, two assumptions underneath traditional review break.

The first is that the author understands the change. Review has always leaned on the author as the first line of defence, and self-review catches a large share of defects before a reviewer spends a minute. When a model wrote the code, self-review is first-read, not re-read.

The second is that the code is wrong in human ways. Human bugs cluster around fatigue and edge cases. Model output tends to be locally plausible and globally wrong: an API that does not exist, a library version that does not have that method, a pattern lifted from a different framework, a function that handles the stated case correctly and the unstated one silently. These are harder to spot by skimming precisely because they read well.

Practical adjustments: insist the author states which parts were generated, check imports and API surfaces against the actual dependency rather than trusting them, and be more suspicious of code that looks unusually clean. Full treatment in how to review AI-generated code.

How we verified this

Our own data. The pull request statistics in this article come from a dataset we collected on 2026-10-18 via the GitHub GraphQL API: the 300 most recently created merged pull requests in each of facebook/react, microsoft/vscode, kubernetes/kubernetes, rust-lang/rust, nodejs/node, django/django, pandas-dev/pandas, vercel/next.js, grafana/grafana and home-assistant/core. After removing 104 bot-authored pull requests, n = 2,896 human-authored merged pull requests, created 17 Apr 2026 to 17 Oct 2026. Latency figures use a de-biased subsample of 1,058 that drops pull requests created in the trailing 14 days of each repository’s window, because ordering by creation date over-samples fast merges. Full method, percentile tables and limitations are in how big should a pull request be.

Benchmark provenance. c-CRAB author affiliations and version history were read at arXiv on 2026-10-18; the paper is arXiv 2603.23448, v3 dated 7 Apr 2026. The 41.5% union figure and the per-tool breakdown (Claude Code 32.1%, Devin 24.8%, PR-Agent 23.1%, Codex 20.1%) come from the paper body; the abstract’s own phrasing is “around 40%”. Dataset size verified as 184 pull request instances, 67 repositories, 234 validated review comments. SmartBear’s inspection-rate and session-length guidance was read at source on 2026-10-18.

What we could not verify.

• No independent false-positive rate exists for any shipping commercial AI reviewer. We looked. SWE-PRBench and CR-Bench publish false-positive data for bare models in fixed harnesses, which is not the same thing as a product you can buy. Anthropic’s sub-1% claim is vendor-published and has not been reproduced by anyone.
• We did not re-run any benchmark. Every figure in the evidence table is reported from its publisher, with the publisher named. Where two parties measured the same tool and disagreed (Greptile at 82% by Greptile, 45% by Augment), we report both and note that Augment rebuilt the answer key, so the gap is not purely self-dealing.
• “Copilot ranks #1 on ReviewBench” is third-party reported and we could not confirm it against a primary leaderboard. Martian ranks Copilot 4th. We report the discrepancy rather than picking.
• Our 69.8% zero-inline-threads figure undercounts review. Approvals with a summary comment, synchronous review, and Prow-style /lgtm workflows do not create inline threads. The figure measures line-level remarks, not whether anyone read the code.
• Benchmarks predating September 2026 may be stale for Copilot specifically, because GitHub removed its 300-file / 20,000-line review cap on 27 Aug 2026.

Recommendations

Criteria used: reduces escaped defects, does not increase time to first response, and survives contact with a team that does not want more process.

If you change one thing, change the order. Correctness, security, design, style. Then delete style from your checklist entirely and fix CI instead. This costs nothing, takes an afternoon, and immediately redirects every comment your team has to spend.

If you change two things, publish a first-response target and report p90 on it. Our data put median time to first review at 5.3 hours and p90 at 162.7 hours. Medians hide broken queues. The p90 is what causes engineers to batch work into larger pull requests, which then get reviewed at one-eighteenth the comment density.

Adopt an AI reviewer as a floor, with gating on from day one. High severity inline, medium in the summary, informational off, blocking nothing for the first month. The evidence does not support more than that: 41.5% collective detection in c-CRAB, 15 to 31% for frontier models in SWE-PRBench, 27.01% recall at 3.56% precision in CR-Bench. These are useful numbers for a free first pass and poor numbers for a gate.

Pick the tool on its gating primitives, not its benchmark. Every published benchmark in this market was run by someone with a stake, with the partial exceptions of SWE-PRBench, CR-Bench and Martian. Greptile exposes confidence scores. Claude Code reads REVIEW.md from the base branch and refuses to approve. CodeRabbit takes natural-language standing instructions but caps at 150 files on Essentials. DeepSource runs deterministic analysis before the model. Those are facts you can verify in an afternoon; a 47.2% F1 from the vendor that scored it is not.

Then measure your own. Run the 14-day protocol in how to evaluate an AI code reviewer on your repositories, with a pre-registered decision rule, and watch human comment rate as closely as machine comment rate. If the humans go quiet, the tool cost you something that does not show up on the invoice.

Further reading

• How Big Should a Pull Request Be? What the Data Says
• Code Review Best Practices for Engineering Teams - the deeper companion guide
• Code Review Checklist for Authors and Reviewers
• 12 Common Code Review Mistakes and How to Fix Each One
• How to Review AI-Generated Code
• How to Evaluate an AI Code Reviewer: A 14-Day Pilot Protocol
• Best AI Code Review Tools for a Large Codebase
• Pull Request Size Best Practices
• What Are Stacked Diffs? Stacked PRs Explained