DEV Community: Pyor

Code Review Statistics: Every Number Worth Citing (2026)

Othman Shareef — Wed, 11 Nov 2026 08:00:00 +0000

This page collects the code review statistics we cite across this blog in one place, each number attributed to whoever reported it, with a sentence of context and a caveat where one is due. No invented figures, no laundered secondhand claims: if a stat is vendor-reported or an author’s citation of someone else, that is stated. Use it as a reference; follow the links when a number matters to a decision.

The short answer: The pre-AI record says review works within limits: roughly 400 lines at a time, under 500 lines per hour, turned around within a business day. The AI-era numbers say those limits are being blown through: task completion 55% faster with assistants, churn and duplication rising, and reported defect rates and unreviewed merges climbing in the datasets Osmani compiles. Both halves are below, with sources.

Review effectiveness: the SmartBear and Cisco numbers

Review at most about 400 lines of code at a time. Per SmartBear, drawing on its study of code review at Cisco, defect discovery falls off beyond that ceiling. Caveat: SmartBear sells review tooling, and the underlying study is old, though no one has convincingly overturned it.
Inspect no faster than about 500 lines per hour. Same SmartBear guidance: reviewers who race through code stop finding defects. Speed reading a diff is indistinguishable from not reading it.
Keep review sessions to about 60 minutes. SmartBear again: attention decays past the hour mark, so long sessions produce worse review per minute, not more review.

These three numbers are the quantitative backbone of every argument for smaller pull requests, and they predate AI authorship entirely, which is what makes them so uncomfortable now.

Review speed: the Google standard

One business day is the maximum acceptable review turnaround. Google’s engineering practices state it directly: respond within one business day at the absolute maximum. Not an average, a ceiling.
Small changes are the explicit companion policy. Google’s small CLs guide treats change size as the lever that makes fast review possible: small CLs review faster, more thoroughly, and with fewer wasted round trips.

What review actually delivers: Microsoft and Google research

Understanding the code is the top challenge reviewers report. Bacchelli and Bird’s Microsoft Research study found that while managers expect defect discovery, reviewers themselves name understanding as the hard part, and knowledge transfer as a primary outcome. Review is a comprehension activity that sometimes finds bugs, which matches the wider evidence on defect discovery.
At Google, changes are small and one reviewer is typical. The Critique case study documents a converged practice: small changes, usually a single reviewer, and education named as an explicit function of review, not a side effect.

The AI shift: adoption and speed

Developers completed a task 55% faster with Copilot. Reported by GitHub from a controlled experiment (Peng et al.). Caveat: one benchmark task, and GitHub sells Copilot; but the direction has been replicated enough to take seriously.
About 76% of developers are using or planning to use AI tools. Per the 2024 Stack Overflow survey. Authorship changed for the majority of the industry; review capacity did not, which is the inversion in one line.

The AI shift: quality pressure

Code churn and duplication are rising alongside AI adoption. GitClear’s repository analysis reports downward pressure on code quality: more code rewritten shortly after merge, more copy-paste. Caveat: GitClear sells code analysis, and churn is a proxy, not a defect count.
Churn up 861%, defect rate from 9% to 54%, zero-review merges up 31.3%. These are Faros AI figures from an analysis of 22,000 developers, as cited by Addy Osmani in Agentic Code Review. Caveat: secondhand via Osmani, and startlingly large; treat the direction as the signal, not the decimals.
Roughly 4x the output for around 12% of the delivered value. Osmani’s reading of GitClear data in the same essay: raw generation volume is up far more than shipped value. Same caveat: one author’s synthesis of vendor data.

AI reviewers, measured

AI-assisted PRs carried about 1.7x the issues. Reported by CodeRabbit on open source PRs, alongside arXiv research showing review work concentrates on a small group of maintainers. Caveat: CodeRabbit sells an AI reviewer, so the framing serves it.
Of 47 AI review suggestions on 30 PRs: 31 were ESLint-catchable, 9 useful, 7 wrong. Cotera’s hands-on audit is small but rare in being independent, and it matches the broader accuracy picture: most bot output is linter-grade, a minority is gold, some is confidently wrong.
Four parallel AI reviewers produced 93.4% unique findings. Reported by Osmani in the same essay: different models barely overlap, which argues AI review results are high-variance samples rather than verdicts.

How to use these code review statistics

Two honest warnings. First, provenance varies: Google and Microsoft numbers come from published practice and peer-reviewed study; GitClear, CodeRabbit, and Faros figures come from vendors or vendor data read through an essayist. We link the reporter every time so you can weigh that yourself. Second, statistics justify tools too easily, including the ones we compared this week, including ours. The defensible chain is: the old numbers set human limits, the new numbers show volume exceeding them, and the conclusion is a process change, not any particular purchase.

A note on method, since this page exists to be cited: every figure above traces to a named reporter at a working link, and numbers we could not trace were left out entirely, which is why the page is shorter than the average stats roundup. If you quote one of these figures, quote the reporter with it. A stat that says 400 lines per SmartBear, or 861% per Faros as cited by Osmani, survives scrutiny; the same number floating free becomes folklore within two blog posts. And date your citations: the SmartBear limits have held for nearly two decades, but the AI-era figures are snapshots of a moving system, and the honest expectation is that several of them will look different within a year.

Frequently asked questions

How many lines of code should a review cover?

SmartBear, drawing on its Cisco study data, recommends reviewing at most about 400 lines of code at a time, at a rate no faster than roughly 500 lines per hour, in sessions of about 60 minutes. Beyond those limits, defect detection drops off. Most industry guidance on PR size traces back to these figures.

How fast should code reviews be turned around?

Google engineering practice sets the ceiling at one business day: a reviewer should respond within one business day at the absolute maximum, and faster is strongly preferred. Slow review is treated as a process defect because it stalls authors, grows diffs, and pushes teams toward rubber-stamping.

Has AI changed code review statistics?

Yes, sharply. GitHub reported developers completing a task 55% faster with Copilot in a controlled experiment, and Stack Overflow found about 76% of developers using or planning to use AI tools in 2024. On the other side, GitClear reports rising churn and duplication, and Osmani cites Faros data showing defect rates and unreviewed merges climbing.

The 9 Best Code Review Tools in 2026 (Honest Guide)

Othman Shareef — Mon, 09 Nov 2026 08:00:00 +0000

Disclosure before anything else: we build one of the tools on this list , Pyor, so read the whole thing accordingly. With that on the table, this is our honest map of the best code review tools in 2026: nine entries across four categories, each with what it is, who it fits, and the caveat the vendor page leaves out. For a deeper head-to-head on the GitHub alternatives specifically, see our earlier comparison.

The short answer: The best code review tools split into four jobs: platforms where PRs live (GitHub, GitLab, Gerrit), workflow changers that keep diffs small (Graphite), AI reviewers that post a first pass (CodeRabbit, Copilot code review), and review surfaces that make the reading itself faster (Stage, Pyor, or a local checkout). Pick by which job is actually your bottleneck.

Tool	Approach	Best for	Pricing model
GitHub built-in	PR reviews on the code host	Small diffs, default workflow	Included with GitHub
GitLab MRs	Merge requests with approval rules	Teams already on GitLab	Included with GitLab
Gerrit	Patchset-per-commit review	Commit-level discipline	Free, self-hosted
Graphite	Stacked PRs, merge queue, AI review	Teams adopting stacking	30-day free trial, then paid
Stage	AI chapters over the diff	Orientation in unfamiliar changes	Paid; details light as of this writing
CodeRabbit	AI review comments on the PR	Mechanical first pass	Free trial; free for open source
Copilot code review	AI first pass inside GitHub	GitHub-native teams	Copilot subscription
Pyor (ours)	Fast surface, AI triage not narration	Reading big diffs is the bottleneck	Free for individuals (AI on your own key); per-seat orgs
Local checkout	Pull the branch into your editor	One gnarly change	Free

The platforms: GitHub, GitLab, and Gerrit

GitHub built-in review is the default for a reason: zero setup, and every integration assumes it. It works well for small, focused PRs. The caveat is scale: large diffs paginate and collapse, and there is no triage, which is why teams eventually look elsewhere. GitHub is moving: it added native stacked pull requests in 2026, per InfoWorld, with GitHub itself admitting that large pull requests are hard to review.

GitLab merge requests add approval rules, required reviewers, and pipeline gates in one place. Best for teams already on GitLab; the review surface itself has the same wall-of-diff problem as GitHub. Gerrit is the veteran: every commit becomes a reviewable change with numbered patchsets and explicit vote labels, which is why large projects like Android still run on it. Caveats: an austere UI, a real learning curve, and you host it yourself.

The workflow layer: Graphite and stacked pull requests

Graphite now positions itself as an AI code review platform, but the durable idea is stacking: break a big change into a sequence of small dependent PRs, with a CLI, a stack-aware merge queue, and a PR inbox doing the bookkeeping. The research on small changes is firmly on its side. Honest caveats: stacking is a team-wide workflow change with a learning curve, it cannot shrink genuinely atomic changes (migrations, codemods), and you are adopting a platform, not a viewer. As of this writing it offers a 30-day free trial, no credit card required.

The AI reviewers: CodeRabbit and Copilot code review

CodeRabbit posts AI review comments directly on the PR across GitHub, GitLab, Azure, and Bitbucket, with diff summaries, configurable rules, and a feedback loop it calls Learnings. It is the most built-out of the bot reviewers, free for open source, with a no-card trial. GitHub Copilot code review does the same job natively inside github.com for teams already paying for Copilot. The shared caveat for the whole category: bots are a first pass, not a reviewer. Independent audits of AI review accuracy keep finding a large linter-grade and false-positive share, and every comment the bot posts is volume a human still triages.

The guided surfaces: Stage and Pyor

Stage bills itself simply as a better code review platform: AI organizes the diff into logical chapters with guidance, and everything syncs back to GitHub. If reviewers feel lost in unfamiliar changes, chaptering is a genuinely clever fix. Caveats: you are reading generated narration and trusting it, and public pricing detail is light as of this writing.

Pyor is ours, so the claims stay modest and checkable. It is a fast review surface for existing GitHub PRs: read, comment, approve, and merge in one window, with a file rail built for triage and diffs that stay navigable at any size. Where it uses AI, the AI organizes rather than narrates: it groups review-worthy changes apart from the noise, labels each group in one line, and drops short hints pointing at what deserves attention first. It does not generate summary prose you must read and then re-verify. Honest caveats: it is young, and it is a viewer, not a workflow platform: it does not create stacks and has no merge queue of its own (it adds PRs to GitHub’s merge queue when a repo uses one), though it now surfaces GitHub’s native stacked PRs so a stack stays navigable while you read. Free for individuals (AI on your own key), per-seat for organizations.

AI triage on a 47-file pull request. The groups are labelled and the mechanical ones are folded.

The free baseline: pull the branch locally

git fetch && git checkout remains the zero-dollar power move: full editor navigation, jump-to-definition, run the tests. Every paid tool on this list should be measured against it. The cost is friction: you stash your own work, lose inline commenting, and transcribe findings back by hand. Right for one gnarly architectural change; wrong as a daily default.

The best code review tools by situation

Diffs are too big and the team will change workflow: Graphite, or GitHub’s now-native stacking.
Diffs are too big and the workflow will not change: a better surface: Stage if you want narration, Pyor if you want triage and pointing.
Mechanical issues reach humans too often: CodeRabbit or Copilot code review as a gate, tuned aggressively for noise.
You need commit-level rigor and control: Gerrit.
One brutal change, once: pull it locally and keep your money.

A note on what this list deliberately leaves out: linters, static analysis, and security scanners. They are gates, not review tools; they belong in CI, where they run without spending anyone’s attention, and a healthy pipeline means your human reviewers and your AI reviewers never comment on anything a machine could have rejected for free. If a bot on this list is mostly restating linter findings, the fix is a linter, not a subscription.

Most of these compose. A realistic 2026 stack is a platform you already have, one bot as a filter, and one surface that makes the human read fast. The cheapest experiment is one reviewer trying one tool on one real PR this week: every entry here syncs back to the platform, so nothing about trying them commits your team to anything. Trial before you involve the whole team, and measure turnaround before and after so the decision is a number, not a vibe.

Frequently asked questions

What is the best code review tool overall?

There is no single winner because the tools solve different problems. Graphite restructures the workflow so diffs stay small. CodeRabbit and Copilot add an automated first pass. Stage and Pyor upgrade the reading surface. GitHub, GitLab, and Gerrit are the platforms underneath. Pick by bottleneck: workflow, mechanical checks, or the reading itself.

Are AI code review tools worth it?

As a mechanical first pass, yes: they catch obvious bugs and style drift before a human looks, and they are cheap to try. They are not a replacement for human review. Independent spot checks find a meaningful share of AI suggestions to be linter-grade or wrong, so treat bot output as a filter, not a verdict.

Do I need a separate tool if my team already uses GitHub?

Not necessarily. GitHub review is fine for small, well-scoped pull requests. Teams reach for extra tooling when a specific failure shows up: diffs too large to read on github.com, review turnaround stretching past a day, or bot and human comments drowning each other out. Adopt a tool for the failure you actually have.

GitLab vs GitHub Code Review: An Honest Comparison

Othman Shareef — Sat, 07 Nov 2026 08:00:00 +0000

GitLab vs GitHub code review debates usually turn into platform debates within three sentences, so let us keep this one narrow: what is it actually like to review a change on each? Both platforms review a branch against a target; GitLab calls the container a merge request, GitHub a pull request. The mechanics beneath those names have converged more than either marketing site suggests, but the remaining differences are real, a few are priced differently, and one or two only start to matter at certain team sizes. Everything here about GitLab traces to the current GitLab documentation as of this writing.

The short answer: The two review experiences are siblings: batched review comments, applyable suggestions, code owner routing, and iteration tracking exist on both. The honest differences: GitLab gates required approvals and blocking change requests behind Premium and Ultimate, while GitHub bundles equivalents into branch protection; GitLab tracks iterations as per-push diff versions; and self-hosting is a first-class GitLab path. If you are choosing a platform, review mechanics will rarely be the deciding factor.

GitLab vs GitHub code review, side by side

	GitLab merge requests	GitHub pull requests
Batched review comments	Start a review; pending comments publish together with one notification	Start a review; comments submit together as one review
Required approvals	Approval rules on Premium and Ultimate; optional approvals on Free	Required reviews via branch protection rules
Blocking requested changes	Premium and Ultimate; users with merge permission can override, flagged	Request changes blocks when required reviews are enabled
Code owner routing	CODEOWNERS backed approval rules	CODEOWNERS review requests and required approvals
Reviewer suggestions	Suggestions with multi-line and batch apply, all tiers	Suggested changes with batch commit
Iteration tracking	Diff versions recorded per push, comparable from a dropdown	Per commit diffs and changes since your last review
Self-hosting	GitLab Self-Managed and Dedicated	GitHub Enterprise Server

Approvals: rules vs branch protection

The biggest structural difference between the two platforms is where required review policy lives. GitLab models it as approval rules configured per project: minimum approval counts, reviewer categories, and rules backed by CODEOWNERS files. The catch is tiering: per the approvals documentation, approvals on GitLab Free are optional and do not prevent merging, while required approval rules are Premium and Ultimate features. GitLab also offers a setting to prevent authors approving their own merge requests. GitHub reaches similar ends through branch protection: required approving reviews, dismissal of stale approvals, and CODEOWNERS entries that both request reviewers automatically and can be made required. Neither approach is clearly stronger; GitLab centralizes the policy in rules, GitHub distributes it across branch protection and ownership files.

The reviewing itself: batches, change requests, suggestions

Reviewing feels familiar on both sides. GitLab reviewers start a review and accumulate pending comments that publish together, with a single email to everyone notifiable on the merge request; GitHub reviewers do the same with pending review comments. A GitLab reviewer on Premium or Ultimate can request changes and block the merge until resolved, with an override path for users who hold merge permission, flagged in the UI when used. For fixes small enough to hand back directly, GitLab suggestions mirror GitHub suggested changes: the reviewer proposes an edit in the diff thread, the author applies it from the UI, and the applied suggestion becomes a commit authored by the reviewer. GitLab supports multi-line suggestions and batching several into one commit, on every tier. This is the converged core: on either platform, the basic review loop is the same loop.

Iteration tracking and merge coordination

Where they diverge is in tracking a change as it evolves. GitLab records a diff version on every push, and reviewers can compare versions against each other or against the target from a dropdown on the Changes tab, per the diff versions documentation. The granularity caveat: versions are created per push, not per commit, so several commits pushed together share one version. GitHub tracks per commit instead and offers changes since your last review, which serves the same re-review need with different edges; neither is a full interdiff under force pushes, so returning reviewers on both platforms still lean on authors who iterate in clean, appendable commits. Past the review itself, GitHub has invested in landing coordination: merge queues serialize merges into busy branches so approved work does not break the target between approval and landing. GitLab has its own merge coordination features on paid tiers; teams with a busy default branch should compare current capabilities directly rather than trusting either camp’s summary, as this area shifts often.

Self-hosting and the honest answer

The strongest genuinely review-adjacent reason to pick GitLab is control of the platform: GitLab Self-Managed and Dedicated are first-class, documented deployment paths, and the entire review feature set above runs on them. GitHub’s answer is Enterprise Server, which trails cloud features by some interval. If your review process must run inside your network, GitLab has treated that constraint as core for longer. And now the honest answer about migration: if you are weighing GitLab vs GitHub, the review models should probably not decide it. They are close relatives. What differs is everything around them: CI, pricing, hosting constraints, ecosystem, and where your contributors already are. Decide on those, then invest in review discipline on whichever platform wins, because the discipline transfers and the platform loyalty does not. (Disclosure: we build Pyor, a review client for GitHub pull requests, so our stake in this comparison is on record.)

A practical closing note for teams doing the evaluation: run the trial on your own code, not the demo project. Import one busy repository, wire up the approval rules or branch protections you actually intend to enforce, and have two or three reviewers work a real week of merge requests or pull requests through it. The differences that matter, notification noise, how re-review feels after a rebase, whether the approval gates fit your compliance story, only show up under a real workload. Both vendors document their review features well; the fetched pages linked throughout are the right starting points, and both products change fast enough that any static comparison, this one included, deserves a freshness check before you commit.

Frequently asked questions

Is GitLab or GitHub better for code review?

The day to day review experience is closer than partisans admit: both batch review comments, both support applyable suggestions, both route reviewers through CODEOWNERS style rules. GitLab puts more approval machinery behind paid tiers; GitHub leans on branch protection. Choose on platform factors like CI, hosting, and pricing, because the review models rarely decide it.

Do GitLab approvals actually block merging?

Depends on tier. On GitLab Free, approvals are optional and do not prevent merging without approval. Required approval rules, including minimum approval counts and CODEOWNERS backed rules, are Premium and Ultimate features. A reviewer requesting changes also blocks merging on those tiers, though users with merge permission can override it, and the override is flagged.

Does GitLab have an equivalent of GitHub suggested changes?

Yes. GitLab suggestions let reviewers propose code edits in diff threads with a Markdown syntax; authors apply them from the UI, which creates a commit authored by the suggesting reviewer. Multi-line suggestions and batching several suggestions into one commit are supported, and the feature is available on all tiers including Free.

Gerrit vs GitHub: Two Code Review Models Compared

Othman Shareef — Thu, 05 Nov 2026 08:00:00 +0000

Gerrit vs GitHub is one of the longest running arguments in code review, and it stays interesting because the two tools disagree about what a review even is. GitHub reviews a branch. Gerrit reviews a commit, and keeps every revision of it. From that one difference flow most of the practical consequences: how iteration is tracked, how approval works, and how much ceremony a contributor has to learn. Both models are defensible. The right question is which failure you would rather live with.

The short answer: Gerrit reviews individual commits as changes with numbered patch sets, scored labels, and configurable submit rules; GitHub reviews branches as pull requests with approvals and threads. Gerrit is stronger at iteration: the patch set lineage makes re-review a delta read, and the one commit unit pushes changes to stay small. GitHub is stronger at everything around review: ubiquity, ecosystem, and contributor familiarity. Pick by which strength your team actually lacks.

Two units of review: change vs branch

In Gerrit, the unit of review is a change: per the Gerrit user guide, a change consists of a Change-Id, metadata like owner and target branch, one or more patch sets, comments, and votes, where each patch set is a git commit. Authors push commits for review to a special refs/for/<branch> namespace, which is how Gerrit distinguishes review uploads from direct pushes. GitHub’s unit is the pull request: a branch containing however many commits, compared against a base branch, with reviews and threads attached to the whole. The Gerrit project describes its patch based workflow as closer to the mailing list model used by Git itself and the Linux kernel, and that lineage shows: one commit, iterated until it is right.

Where Gerrit shines: patch set lineage

When an author reworks a Gerrit change, the amended commit becomes the next numbered patch set on the same change, keyed by its Change-Id. Nothing is overwritten; the iteration history sits alongside the review. That is a native answer to the interdiff problem: a returning reviewer reads what changed since their last pass instead of re-reading the whole diff, which on GitHub takes deliberate workarounds and degrades badly under force pushes. The user guide also notes that after a rebase, reviewers see the delta against the current target branch HEAD, so lineage survives even as the base moves. The second quiet advantage is size discipline: because the unit of review is one commit, the model itself pushes toward small, atomic changes rather than relying on reviewers to ask for them.

Scored labels and submit rules

GitHub approval is close to binary: approve, comment, or request changes, with branch protection deciding how many approvals are enough. Gerrit votes on labels with scores, and the submit rule is explicit: a change can only be submitted when it has the highest value on each review label and no veto vote at the lowest value. In the default setup, as of this writing, the Code-Review label runs from a blocking low score to the familiar +2 that permits submission. Projects can define custom labels and custom submit rules, which turns merge criteria from convention into configuration: a Verified label fed by CI, a sign-off label for a security team, and so on. GitHub can approximate much of this with required status checks and CODEOWNERS, but in Gerrit the gate is the data model rather than an overlay.

Where GitHub wins: everyone is already there

The case for GitHub is not mechanical, it is gravitational. Nearly every developer you hire or attract as a contributor already knows the pull request flow, while Gerrit asks them to learn Change-Ids, refs/for pushes, and amend driven iteration before their first upload. The ecosystem gap compounds: Actions, apps, integrations, and a decade of tooling assume PRs. Gerrit is not without an ecosystem; the project advertises a plugin architecture with over a hundred community plugins and a REST API, and it anchors some of the largest review installations anywhere, with Android, Chromium, and Qt among its flagship users. But those are organizations that chose review rigor over onboarding ease and staffed accordingly. For an open source project that lives on drive-by contributions, that trade usually points the other way.

Gerrit vs GitHub: how to choose

	Gerrit	GitHub
Unit of review	A change: one commit, iterated as patch sets	A pull request: a branch of commits
Iteration history	Every revision kept as a numbered patch set	Commits and force pushes on the branch
Approval model	Scored labels with configurable submit rules	Approvals and requested changes, plus branch protection
Blocking a merge	Any veto vote on a label blocks submission	Required reviews and status checks
Hosting	Self-hosted, or GerritHub on top of GitHub repos	github.com or GitHub Enterprise
Learning curve	Change-Ids and refs/for take real onboarding	Familiar to nearly every developer

Pick Gerrit if your bottleneck is review rigor: you want enforced small changes, explicit submit criteria, and first-class re-review, and you can afford the onboarding tax, as Android and Chromium evidently can. Pick GitHub if your bottleneck is participation: external contributors, fast hiring ramp, ecosystem leverage. Research on review at scale, including Google’s study of its internal tool Critique, suggests the process around the tool matters more than the tool: small changes, fast turnaround, and clear expectations are what make review work. Gerrit encodes those norms in software; on GitHub you supply them as culture and tooling. (Disclosure: we build Pyor, a review client for GitHub pull requests, so we live on the GitHub side of this fence.)

There is also a middle path worth knowing about before you commit either way: the Gerrit project points to GerritHub.io, a hosted service that runs Gerrit review on top of GitHub repositories. It lets a team keep its code and contributors where they are while trialing the patch set workflow on real changes, which is a far better evaluation than any comparison table, this one included. If the lineage and the submit rules earn their keep in that trial, migrate deliberately. If they do not, you have learned which discipline you were actually missing, and that discipline can usually be rebuilt on the platform you already have.

Frequently asked questions

Is Gerrit better than GitHub for code review?

For review mechanics, Gerrit has real advantages: every iteration is kept as a numbered patch set, so re-review means reading the delta, and scored labels with submit rules make merge criteria explicit. GitHub wins on everything around the review: familiarity, ecosystem, and hiring. Most teams are better served by the platform their contributors already know.

Can I use Gerrit together with GitHub?

Yes. The Gerrit project points to GerritHub.io, a hosted service that runs Gerrit review on top of GitHub repositories, so code can live on GitHub while review happens in Gerrit. It is a practical way to trial the patch set workflow without migrating hosting, though your contributors still need to learn the Gerrit review flow.

What is a patch set in Gerrit?

A patch set is one revision of a change, and each patch set is a git commit. When an author reworks code after feedback, they amend the commit and push again; Gerrit uses the Change-Id footer to attach the new commit to the same change as the next numbered patch set, preserving the full iteration history side by side.

Code Review Burnout: Signals, Causes, and Fixes

Othman Shareef — Tue, 03 Nov 2026 08:00:00 +0000

Code review burnout has a shape, and it is not evenly distributed. On most teams a small share of engineers does most of the reviewing, quietly and without a line item anywhere. They are the people whose approval everyone wants, whose queue never empties, and whose calendars absorb the cost. When they wear out, the failure is silent: reviews slow down, then hollow out, and the team discovers the problem months later as a quality regression nobody can quite date.

The short answer: Reviewer fatigue concentrates: a few trusted people carry most of the load, AI generated volume is making their queues deeper, and the failure mode is silent decline in review quality rather than a visible outage. The signals are rising latency, rubber-stamp approvals, and review avoidance. The fixes are structural, not personal: rotate assignment deliberately, budget review capacity honestly, and tier rigor so deep attention goes where mistakes are expensive.

The concentration problem

Review load pools around expertise. The fastest, most useful reviews come from the people who know the code best, so assignment tools and human habit both route requests to them, and every good review earns them the next one. Open source shows the extreme version: maintainers of popular projects field unbounded inbound from an unbounded contributor pool, and maintainer burnout is a documented, recurring reason projects stall. Company teams run the same dynamic at smaller scale. Microsoft’s research on modern code review found that understanding the code is the central challenge reviewers face; that kind of comprehension work does not parallelize, does not survive fatigue, and cannot be delegated to whoever happens to be free.

AI multiplied the volume

Whatever equilibrium teams had, assistants broke it. Code generation got dramatically cheaper; careful reading did not. Addy Osmani’s agentic code review essay collects the numbers behind that asymmetry, and we have written about the resulting review bottleneck before: when authoring accelerates and review does not, the queue grows in front of exactly the people already carrying the most of it. The concentration problem and the volume problem multiply rather than add: the deeper queue lands on the same few desks, so the reviewers most likely to burn out are precisely the ones the new volume finds first. Burnout risk is no longer a culture nicety. It is the constraint on how much of that new volume a team can safely absorb.

The signals of code review burnout

Fatigued reviewers rarely announce it; the metrics whisper it first. Three signals, all trends rather than incidents:

Rising latency. Google’s norm of responding within one business day makes a useful baseline: when a previously prompt reviewer drifts from hours to days, something is being traded away.
Rubber-stamps. Approvals that arrive faster than the diff could be read are fatigue wearing a productive costume: the ritual continues after the attention has run out.
Avoidance. Requests reassigned, snoozed, or left until the author gives up and finds someone else. Reviewers almost always protect themselves quietly before they ever complain out loud.

SmartBear’s peer review research gives the physiological floor under all three: review effectiveness drops after about an hour, which is why a reviewer running back-to-back sessions all day is not doing eight hours of review. They are doing two, spread thin across eight.

Fix one: rotate the load

The structural fix is to stop letting assignment follow the path of least resistance. Deliberate reviewer assignment spreads requests past the two obvious experts: round-robin within an ownership area, pairing a primary expert with a secondary learner, and load caps that make it normal to say a queue is full. Rotation costs something real, because the less familiar reviewer is slower at first. That cost is the investment: every rotation grows the pool of people who can review that code, which is the only durable cure for concentration.

Fix two: capacity honesty and tiers

Rotation redistributes the load; it does not shrink it. The second fix is admitting that review capacity is finite and budgeting it like anything else that is finite, which is the argument of review capacity planning: count the review hours the team actually has before committing to the volume it will absorb. Then spend those hours unevenly on purpose. A dependency bump with green CI does not need the same scrutiny as a change to the payment path, and pretending it does is how the payment path ends up reviewed by someone running on fumes. Tiered rigor is not lowered standards; it is standards applied where mistakes are expensive, by reviewers still fresh enough to enforce them.

One more fix deserves a mention because it costs nothing: make review work visible. Most teams can name their top reviewers but have never counted their review hours, because the work happens between the tasks that get tracked. Put review load on the same dashboard as everything else. A reviewer carrying triple the median load is either a staffing decision the team should make on purpose or a slow-motion resignation letter, and the difference is whether anyone is looking.

Burnout in review is a systems failure that presents as a personal one. The reviewer who got slow and cranky is downstream of an assignment graph that funneled everything through them and a plan that never counted their hours. Fix the graph and the budget before the exit interview does it for you, and the people, given an honest workload, tend to recover on their own.

Frequently asked questions

What are the early signs of code review burnout?

Watch trends, not incidents. Review latency creeping up week over week, approvals arriving faster than the diff could plausibly be read, and quiet avoidance such as reviews reassigned, snoozed, or left to someone else. Any one of these can be noise. All three moving together on the same person is the pattern worth acting on.

Why does review load concentrate on a few people?

Because review assignment follows knowledge, and knowledge concentrates. The people who know the codebase best give the fastest, highest quality reviews, so tooling and habit route ever more requests to them. Success makes it worse: every good review makes the next request more likely. Without deliberate rotation, the equilibrium is a handful of overloaded experts.

Does AI generated code make reviewer burnout worse?

It raises the ceiling on demand. Generation got dramatically cheaper while careful reading did not, so the queue in front of the same few reviewers grows faster than before. Teams that do not spread the load or tier their rigor tend to discover the problem as quality incidents, after the fatigue has already set in.

Context Switching in Code Review: The Interruption Tax

Othman Shareef — Sun, 01 Nov 2026 08:00:00 +0000

Context switching in code review is the tax nobody itemizes. Ask engineers why pull requests are so hard to review and they will point at diff size and missing context, and they are right. But the cost that actually shapes a reviewer’s week is the switch itself: the request that lands mid-task, the mental state rebuilt after every detour, the large diff you re-enter for the third time and re-learn from scratch. Review is not expensive because reading code is slow. It is expensive because of what each round of reading evicts.

The short answer: Review requests behave like interrupts, but you do not have to service them like interrupts. Treat review as scheduled work: batch requests into two or three daily review blocks, keep turnaround inside one business day, and leave place-keeping anchors so a paused review resumes in seconds. Handled this way, reviewer focus and review latency stop being a trade-off. The same calendar protects maker time and meets the SLA.

Review requests are interrupts

An incoming review request has every property of an interrupt: it arrives asynchronously, it carries someone else’s deadline, and it politely asks you to drop what you are doing. Google’s engineering practices guide resolves the tension explicitly. It asks reviewers to respond within one business day at most, because slow reviews stall authors and breed ever larger follow-ups. The same page tells reviewers not to interrupt a focused coding task to do a review; finish what you are doing and pick reviews up at a natural break point. Those two instructions only coexist if review is scheduled work rather than reactive work. The interrupt framing is a choice the team makes, not a property of the request.

Context switching in code review scales with diff size

The re-orientation cost is not constant; it scales with how much state the review requires. A ten line fix can be reviewed cold in a minute. A forty file refactor demands the same slow build-up every time you open it: what the change is for, which files you already covered, which thread you were pulling when you stopped. That is why large pull requests suffer disproportionately from interruptions: every exit throws away expensive state, and every re-entry buys it back at full price. SmartBear’s peer review research points the same direction: effectiveness falls after about an hour of reviewing, and reviewers should take on no more than around 400 lines at a time. A review you cannot finish in one sitting is a review you will pay for at least twice.

Batch into review blocks

The fix is boring and it works: stop treating the queue as a stream and drain it on a schedule. Two or three fixed blocks a day, thirty to sixty minutes each, placed at natural seams like post-standup and post-lunch, absorb the review load of most senior engineers without touching deep work. The seams matter as much as the blocks: a review slot that starts where focus already broke costs nothing extra, while the same slot dropped into the middle of a maker afternoon costs the whole afternoon. Inside a block, a few rules keep the batch honest:

Order the queue by staleness, oldest request first, so nothing quietly rots.
Finish or checkpoint each review before opening the next; two half-reviews cost more than one complete one.
Right-size what you accept per block. One large diff or several small ones, not both.
Leave the block on time. An unfinished review with good anchors beats an overrun that eats your afternoon.

An SLA you can keep without live interrupts

Teams usually adopt reactive reviewing out of fear of missing the review SLA, but the arithmetic favors blocks. Two blocks a day put the worst case response at roughly half a working day, well inside a one business day target, and the median far lower. What batching needs to stay safe is an escape hatch: an explicit escalation channel for genuinely blocking reviews, used rarely and honored promptly. That converts the SLA from a vague pressure to respond instantly into two clear promises: routine reviews within the next block, escalations at the next break point. Authors get predictability, which they value more than speed; reviewers get whole mornings back.

Keep your place in the diff

Batching shrinks the number of switches; place-keeping shrinks the price of each one. The humble viewed files checkbox is the most underrated review feature on GitHub precisely because it turns re-entry from an archaeology dig into a checklist: everything checked is done, the first unchecked file is where you resume. Pending review comments work the same way; a half-formed note to yourself marks a thread you meant to finish pulling. The last trick is manual: before leaving a block, write one line about where you stopped and what you suspected. (Disclosure: we build Pyor, where a paused review keeps its viewed files and unsent comment drafts for when you come back.)

None of this makes review free. It makes the cost visible and then schedules around it, which is all anyone does with any interrupt. Authors can help from their side too: a clear description, a suggested reading order, and a diff sized for one sitting all lower the state a reviewer has to hold, and therefore the price of every switch. The teams that treat reviewer attention as a budgeted resource ship reviews faster than the teams that treat it as an always-on service, and their reviewers still have the focus left to catch what the review was for in the first place.

Frequently asked questions

How often should reviewers check for new review requests?

Two or three fixed blocks per day is enough for most teams. Google recommends responding within one business day at most, and a morning plus afternoon block beats that comfortably. The exception is a genuinely blocking review someone explicitly escalates; treat those as true interrupts and pick them up at your next natural break point.

Does batching code reviews conflict with a review SLA?

No. Most review SLAs are measured in business hours or days, not minutes. Two daily review blocks give a worst case response of about half a working day, well inside a one business day target. Batching usually improves the SLA in practice, because review stops losing races against meetings and deep work and gets reserved time instead.

What is the fastest way to resume a half finished review?

Leave yourself a trail while reviewing. Mark files as viewed as you finish them, write pending comments even for half-formed thoughts, and end each session by noting the next file you meant to open. Re-entry then costs seconds. Without those anchors, resuming a large diff means re-reading files you already covered.

The Cost of Slow Code Review

Othman Shareef — Fri, 30 Oct 2026 08:00:00 +0000

The cost of slow code review rarely appears on a dashboard, which is exactly why it compounds. No invoice arrives for the pull request that sat four days. The bill shows up shredded into a hundred line items nobody attributes: a context switch here, a rebase there, a feature that shipped a sprint late, a senior engineer who quietly stopped asking for review on small things. Add the line items back together and slow review is one of the most expensive processes an engineering organization runs.

The short answer: Slow review is a compounding-interest problem, not a queue problem. Finished work sits idle, authors lose context and start something new, conflicts multiply, and every delay makes the eventual review harder, which makes the next delay longer. Google’s guidance names the damage plainly: velocity and morale. And in the AI era the failure mode is worse than waiting. Teams do not wait. They stop reviewing.

Counting the cost of slow code review

Start with inventory. A finished, unmerged change is completed work earning nothing, and every day in the queue is a day the business paid for software it cannot use. But idle inventory is the cheapest item on the bill. The expensive ones are what the delay does to everything around it.

Context evaporates first. Reviewing a change is largely reconstructing the intent behind it, and that reconstruction gets harder on both sides of the table as the diff ages. By day four the author has to re-load their own reasoning before they can even answer a question about it. Each review round now costs two context switches: the reviewer swapping in, the author swapping back. Meanwhile the author has started something new, so every comment arrives as an interruption to different work, and the response latency stretches accordingly.

Then the mechanical costs stack. Main moved while the branch waited, so conflicts and rebases multiply, and each rebase risks fresh mistakes in code that was already finished. Follow-up work stacks on top of the unmerged branch, coupling its fate to the queue. And under all of it runs the morale cost, which Google’s review speed guidance treats as a first-order harm, not a soft one: slow review damages both the velocity of the team and the developers waiting on it. People who learn that finishing work changes nothing stop hurrying to finish work. That lesson, once taught, is expensive to unteach.

There is also a selection effect that compounds quietly. When review is slow, the changes that suffer most are the careful ones: refactors, test improvements, dependency hygiene, all the work that is easy to defer and easy to abandon. Urgent fixes get escalated past the queue; virtuous maintenance dies in it. Over a few quarters the codebase records that bias. Slow review does not delay work uniformly; it filters out exactly the work that keeps future changes cheap.

The AI-era multiplier

All of this was true when humans wrote every line. What changed is the arrival rate. Code generation accelerated by an order of magnitude while review throughput stayed human, a mismatch we have written about before: the queue math that was merely unpleasant at human authoring speed becomes unpayable when every developer ships multiples of their former volume.

The evidence on what happens next is the alarming part, because the answer is not longer queues. Addy Osmani’s agentic code review essay cites a Faros analysis of 22,000 developers reporting zero-review merges up 31.3 percent, alongside defect rates jumping from 9 to 54 percent. When review becomes the bottleneck, teams do not throttle generation to match. They route around the bottleneck. The cost of slow code review, at AI throughput, is not slowness at all: it is the silent disappearance of review as a safety function, discovered later as a defect curve.

Cheap fixes first

The encouraging part of the bill is how much of it responds to process changes that cost almost nothing:

Set a first-response SLA. Most turnaround time is time when nobody was looking, and a one-business-day expectation attacks exactly that slice. It requires no tooling, only agreement.
Shrink the changes. Small diffs get picked up sooner, read faster, and approved in fewer rounds. Size is the one variable that shortens every stage of the pipeline at once.
Plan reviewer capacity. Review is real work that appears on nobody’s sprint, which is why it always loses to work that does. Budgeting review time explicitly turns the queue from an externality into a staffed function.

Tooling comes after process, and its honest job is narrow: make the read itself faster without making it shallower. That is the problem we work on at Pyor (disclosure: this is our product), but the ordering stands regardless of whose tool you use. Fix the queue with agreements, fix the diff with size, and only then buy speed for the reading. A team that does the first two often finds the third is smaller than it looked, because the cost of slow code review was never really about how fast anyone could read.

Frequently asked questions

What is the real cost of slow code review?

The direct cost is idle work: finished changes waiting in a queue. The compounding costs are worse: authors lose context and switch tasks, rebases and conflicts multiply, follow-up work stacks on unmerged branches, and reviewers face ever-larger diffs. Google engineering guidance is blunt that slow review harms both team velocity and morale.

What happens if review stays slow while AI speeds up coding?

The queue does not just grow; it gets bypassed. Addy Osmani cites a Faros analysis reporting zero-review merges up 31.3 percent alongside sharply rising defect rates. When review becomes the bottleneck, teams do not slow generation down to match. They quietly stop reviewing, and the safety function fails without ever announcing it.

What is the cheapest way to speed up code review?

Set a first-response expectation and make the queue visible. Most review delay is not reading time; it is time when nobody was looking. A one-business-day SLA, smaller changes, and explicitly planned reviewer capacity fix the bulk of latency before any tooling change. Measure elapsed time from request to first response, and start there.

How Long Should Code Review Take?

Othman Shareef — Wed, 28 Oct 2026 08:00:00 +0000

How long should code review take? The question hides two different questions, and teams that answer only one of them stay slow. The first: how quickly should a review start? The second: how long should the reading itself take once it does? The evidence gives usable numbers for both, and almost every chronically slow review process is failing the first question while agonizing over the second.

The short answer: Two numbers cover most of it: first response within one business day, and individual review sessions capped near 60 minutes at a pace no faster than about 500 lines per hour. Total elapsed time is a queue property, not a reading property; most review delay is time nobody was looking. Use the benchmarks to find sick queues and oversized changes, not to grade individual reviews with a stopwatch.

So how long should code review take?

Start with the queue. Google’s engineering guidance on review speed sets the outer bound plainly: one business day, maximum, for a first response to a review request, and the same document is explicit that slow review harms both team velocity and morale. Note what the bound governs: the response, not the completion. A clarifying question inside an hour beats a finished review three days later.

Then the read itself. SmartBear’s peer review analysis found reviewers should cover no more than about 400 lines per session, move no faster than roughly 500 lines per hour, and keep sessions to about 60 minutes, because defect detection drops measurably beyond each of those limits. Put the numbers together and the natural unit of review falls out: a change of a few hundred lines, read carefully in under an hour, started within a day of being requested.

The floor matters too. Google’s Critique study found changes there are typically small and get reviewed quickly, usually by one reviewer. Minutes-long reviews of small diffs are not corner-cutting; they are the system working. Duration should scale with size and risk, and at the small end the honest duration is genuinely short.

Elapsed time is not attention time

A pull request that was "in review for three days" may have received eleven minutes of human attention. Those three days decompose into: time waiting for anyone to look, time being read, time waiting for the author to respond, time waiting for the re-review. Only one slice is reading. The rest is queueing, and queueing responds to completely different fixes than reading does.

This distinction is the single most useful diagnostic for a slow process. If attention time is high, changes are too big or too murky, and the fix lives with authors. If elapsed time is high while attention time is low, the queue is unmanaged, and the fix lives with the team: expectations, notifications, and explicit ownership of the waiting pile. Measuring only total turnaround blurs the two failure modes into one useless number.

What stretches review time

Size. Reading pace is roughly linear until it collapses; past the 400-line neighborhood, comprehension degrades and reviewers start skimming. A diff that respects sane size limits fits in one session. A diff that ignores them costs a multiple, not an increment.
Rounds. Every round of comments and fixes re-enters the queue and pays the full waiting tax again. Three rounds at a day of latency each is three days gone, independent of any reading. Cheap re-review, of only what changed since last time, is how mature teams keep round two from costing what round one did.
Queue neglect. The largest slice of most turnaround time is nobody being on the hook for the waiting pile. That is what a review SLA exists to fix: not faster reading, but a shared expectation about when reading begins.

These three multiply rather than add. An oversized diff gets picked up later because reviewers defer the changes they dread, then produces more comment rounds because comprehension suffered, and each extra round pays the full queue tax again. That is why a single 2,000-line pull request routinely takes longer to merge than the same work split into five sequential changes, even though the split involves more total review events. The waiting compounds; the reading never had to.

Benchmarks are a health check, not a stopwatch

One warning before these numbers go in a dashboard. The moment one-business-day and 60-minute figures become individual performance targets, reviewers will hit them the only way that is always available: by reading less. A stopwatch culture produces fast, hollow approvals, which cost more than the latency they replaced. The benchmarks earn their keep at the distribution level, tracked alongside the rest of your review metrics: medians and tails across the team, trending over quarters, pointing at process problems rather than people.

So: respond within a business day, read in sub-hour sittings at a pace that lets you actually think, and treat any change too large for that as the thing to fix. Teams that hold those three lines stop asking how long review should take, because review stops being where the time goes.

Frequently asked questions

How long should a code review session last?

SmartBear analysis of peer review recommends keeping a single session to about 60 minutes, because defect detection measurably degrades as attention fatigues. If a change needs multiple hours of reading, that is a signal the change is too large, not a signal to power through. Split the review into sessions, or better, split the pull request.

How fast should I respond to a review request?

Within one business day, at the outside. Google engineering practice sets that as the maximum for a first response and treats faster as better. The response does not need to be the completed review: acknowledging the request, asking a clarifying question, or reviewing the first files all count. Silence is the expensive part, not partial progress.

Is a fast approval a bad sign?

Not by itself. Small changes legitimately review quickly; the Google Critique study found changes there are typically small and reviewed fast, usually by a single reviewer. The signal worth watching is fast approval on a large diff, which usually means the review did not happen. Judge speed against the size of the change, never speed alone.

Code Review vs QA: Where the Line Actually Is

Othman Shareef — Mon, 26 Oct 2026 08:00:00 +0000

Code review vs QA is a question about where verification lives. Code review evaluates the change itself: logic, design fit, maintainability, and shared understanding. QA verifies the behavior of the assembled system: real data, real integrations, real user journeys. Each catches what the other structurally misses.

The short answer: Review and QA are complements, not substitutes. Review catches code-shaped defects and design drift, and it spreads knowledge; research shows its comments skew toward improvement and understanding rather than bug hunting. QA catches emergent behavior no reader can simulate: integration failures, performance under load, broken journeys. Teams that drop either one must consciously relocate its function, or defects find the gap.

What code review catches that QA misses

A reviewer reads the diff, and reading finds things no test run ever will: the wrong abstraction that works today and calcifies tomorrow, the query that is correct but will not survive real table sizes, the security assumption nobody wrote down, the name that will mislead the next five people who touch the file. None of these fail a test. All of them cost money later.

The research record says review earns its keep mostly here, not in bug counts. Microsoft Research’s study of modern code review found that understanding the change is the top reviewer challenge, and that review comments skew toward code improvement and knowledge transfer rather than defect discovery. That is not review failing at its job; that is review’s actual job. We have covered what reviews really find in more depth: the honest answer is design quality and shared understanding first, bugs second.

What QA catches that review misses

No reviewer executes the system in their head reliably. The checkout flow that breaks only when the cart has a discounted item and an expired card. The API that degrades at the hundredth concurrent request. The migration that is fine on staging data and locks the table on production volume. The layout that collapses on one browser nobody at the company uses. These defects are emergent: they live in the assembled, running system, under real data and real concurrency, and they are invisible in any diff.

This is the structural line between the two practices. Review is static: it evaluates text. QA is dynamic: it evaluates behavior. A team can be excellent at one and blind through the other, and each practice is at its weakest exactly where the other is strongest. That asymmetry, not headcount politics, is why the two functions exist separately.

Code review vs QA in the AI era

The line used to be easy to hold because different humans wrote the code and the tests. Agents blur it: the same model now writes the implementation, the tests that pass it, and sometimes the edits that make failing tests pass. When that happens, the test suite stops being independent evidence and becomes part of the claim under review. A green run tells you the code agrees with itself.

Practically, that pushes a QA instinct into review: reviewers of AI-heavy changes should read the test diff first and treat deleted assertions, widened tolerances, and skipped cases as the highest-signal lines in the change. The reviewer is no longer just checking the code; they are auditing the definition of correct that the code will be judged against.

Teams that dropped QA, honestly assessed

Plenty of respected engineering organizations run no dedicated QA department, and it is worth being precise about what they actually did. They did not discover that review covers behavior. They relocated behavior verification: deep automated test suites, feature flags, canary deploys, fast rollback, and production observability good enough to catch regressions in minutes. The QA function survived; only the job title disappeared. That model works well for server-side software with gradual rollout and tolerant users, and it works badly for complex user journeys, cross-device frontends, hardware, and anything regulated, where discovering defects in production is either too slow or simply not allowed.

The failure mode to avoid is the cargo-cult version: drop QA, add nothing, and assume code review absorbs the difference. It cannot, for the structural reasons above. If your team is deciding where review ends and QA begins, the question is not which practice is better. It is: for each class of defect you ship, which mechanism is supposed to catch it, and does that mechanism actually exist?

Frequently asked questions

Is code review the same as QA?

No. Code review evaluates the change: logic, design fit, maintainability, and shared understanding of the codebase. QA verifies the behavior of the assembled system: real data, real integrations, real user journeys. Review reads code; QA exercises software. Each reliably catches problems the other structurally cannot, which is why treating them as interchangeable creates gaps.

Can code review replace QA testing?

Only if something else absorbs behavior verification. Teams that dropped dedicated QA and survived did it by investing heavily in automated tests, staged rollouts, feature flags, and production monitoring. Those are QA functions relocated, not eliminated. A team that drops QA and adds nothing is choosing to discover its behavioral defects in production.

Who should review tests, reviewers or QA?

Reviewers, and with more suspicion than they give the implementation. Tests encode the definition of correct behavior, so a weakened or rewritten test silently redefines what passing means. This matters most for AI-generated changes, where the same model often writes both the code and the tests that approve it, making a green suite weaker evidence.

Shift Left Code Review: Catch Problems Earlier

Othman Shareef — Sat, 24 Oct 2026 08:00:00 +0000

Shift left code review means moving review earlier in the development cycle: from a single inspection at the end to design review, draft pull requests, author self-review, and automated pre-review, so each defect is caught at the moment it is cheapest to fix.

The short answer: Shifting review left spreads scrutiny across the whole development cycle instead of concentrating it on the finished PR. The ladder runs: design review for direction, draft PRs for approach, author self-review for embarrassments, and an agent pre-review pass for mechanical findings. Each rung removes one class of problem from the final human read. None of them replaces it.

The cost curve of late defects

The argument for shifting left is arithmetic, not fashion. A wrong direction caught at the design stage costs a conversation. The same mistake caught in a finished pull request costs a rework round, a second review, and a bruised author. Caught in production, it costs an incident, a rollback, and some measure of trust. The defect is identical in all three cases; only the discovery date changed the bill. Review effort placed early buys more correction per hour than the same effort placed late, because early feedback arrives while the work is still soft.

The classic review process ignores this curve. It spends its entire budget at the most expensive point: after the code is written, polished, and emotionally finished. By then every comment is a demolition order. Google’s small CLs guidance attacks the same problem structurally: work split into small units early is work that can be reviewed, corrected, and merged before mistakes compound. Splitting is itself a shift-left move. You cannot split a change you have already welded together.

The shift left code review ladder

In practice, shifting left is a ladder of four rungs, each catching what the next one would catch too late:

Design review. A short written design, reviewed before any code exists, is the cheapest review your team will ever run. It catches wrong direction, duplicated effort, and missing constraints while changing course costs nothing. Most changes do not need one; the ones that touch architecture, data models, or public contracts almost always do.
Draft pull requests. Opening a draft PR at thirty percent done invites feedback on approach while the approach is still negotiable. The social contract is different: comments on a draft are steering, not judgment, and authors accept them far more cheaply.
Author self-review. Reading your own diff before requesting eyes, the way a reviewer would, removes the leftover debug code, the accidental file, the misleading name. Every one of those caught by the author costs seconds; caught by a reviewer, it costs a round trip and a little dignity.
Agent pre-review. An AI pass before the human one, doing the work machines are actually good at. The evidence says that work is substantial: Cotera’s analysis of 47 AI review suggestions across 30 pull requests found 31 were catchable by ordinary linters. That is noise a human reviewer should never have to spend attention on, and pre-PR is the right place to burn it off.

What shifting left does not remove

The tempting misread of shift left code review is that enough early gates add up to a merged PR with nobody reading it. They do not. The rungs remove direction errors, embarrassments, and mechanical noise; they do not exercise judgment about correctness, system fit, or blast radius. That judgment is the irreducible human part, and it matters more, not less, as generation gets cheaper. We made the longer version of this argument in the agentic code review piece: automation can pre-filter everything, and a human still owns the merge.

The honest promise of shifting left is narrower and better: the final read gets faster and sharper because everything that could have been caught earlier already was. The reviewer opens a diff that is small, self-reviewed, mechanically clean, and pointed in a direction someone already agreed to. What remains is the part only a human could have done anyway.

Frequently asked questions

What does shift left mean in code review?

Shift left means moving review activity earlier in the development cycle. Instead of concentrating all scrutiny on a finished pull request, teams review designs before code exists, share draft PRs mid-flight, self-review before requesting eyes, and run automated pre-review before a human reads anything. Each step catches a class of problem at the moment it is cheapest to fix.

Does shifting review left replace the final human review?

No. Earlier review changes what the final read contains, not whether it happens. Design review removes direction mistakes, self-review removes embarrassments, and automated passes remove mechanical noise, so the human review at the end concentrates on judgment: correctness, fit, and risk. A change that skipped every earlier step makes that final read slower and worse, not optional.

Is pre-commit AI review worth it?

For mechanical findings, yes. In a Cotera analysis of AI review suggestions across 30 pull requests, 31 of 47 flagged issues were catchable by ordinary linters. Running that class of feedback before a human ever looks means reviewers spend their attention on design and correctness instead of formatting, naming, and obvious slips.

AI Code Review Pricing (2026): CodeRabbit, Greptile, Copilot

Othman Shareef — Fri, 23 Oct 2026 08:00:00 +0000

I went through every vendor’s pricing page this week (October 2026) because the numbers I had in my head were already wrong: CodeRabbit renamed Pro to Essentials, Cursor is dropping Bugbot’s seat fee for usage billing, and Copilot code review bills in AI credits plus GitHub Actions minutes. Below is AI code review pricing as the vendors state it today, what a 10-person and a 50-person team would pay, and the line item none of them put on the page: the time your reviewers spend reading the bot. (Disclosure: we build Pyor, which is on this list but isn’t an AI reviewer, so read the last sections with that in mind.)

The short answer: Checked October 2026 on each vendor’s own pricing page: CodeRabbit is $24 per developer a month billed annually ($30 monthly), Greptile is $30 per seat with 50 review credits, Copilot code review comes with Copilot Business at $19 per user, Graphite’s unlimited AI reviews start on its $40 Team plan (billed annually), and Cursor Bugbot is usage-based at about $1 to $1.50 a run. For 10 developers, those entry plans land between $190 and $400 a month before overages.

AI code review pricing at a glance

Prices are USD before tax, from each vendor’s own pricing page or docs, checked October 2026. I skipped the aggregator sites because they disagree with each other and with the vendors.

Tool	Model	Team price	Free tier	Past the cap
CodeRabbit	Per developer who opens PRs	Essentials $24/mo annual, $30 monthly; Team $48 or $60	Public repos	$0.25 per reviewed file
Greptile	Per seat plus review credits	Pro $30/seat/mo, 50 credits each	Starter: 1 developer, 50 credits/mo	$1 per extra credit
Copilot code review	Per Copilot seat plus AI credits	Business $19/user/mo; Enterprise $39	None (Free excludes review); Pro $10/mo	$0.01 per credit, plus Actions minutes
Graphite	Per user	Team $40/user/mo annual; Starter $20 (limited reviews)	Hobby: personal repos, limited reviews	Not published
Cursor Bugbot	Usage-based	About $1 to $1.50 per run (Cursor’s average)	Not on Free or Plus	Every run bills
Pyor (ours)	Per seat, not a reviewer bot	$7.99/seat/mo, Pyor AI included	Free for individuals	Monthly AI usage cap

CodeRabbit pricing

CodeRabbit charges per developer, and only for developers who create pull requests, which is a fair definition if half your org reviews but rarely authors. Essentials (the plan that used to be called Pro) is $24 a developer a month billed annually or $30 monthly, and covers review, chat, learnings, one-click fixes and pre-merge checks. Team is $48 annually or $60 monthly and adds unit test generation, Triage and custom pre-merge checks. Advanced is listed at $72 and adds security and blast-radius features, and Enterprise is contact sales.

The number to check is the hourly allowance: 5 reviews per developer per hour on Essentials, 8 on Team, 10 on Advanced, under a fair usage policy. Past that, reviews keep going as usage at $0.25 per reviewed file, and an admin picks automatic, on demand, or off and sets a monthly spending cap. Private repos get a 14-day trial and no free plan, while public repositories get free reviews. For the wider comparison see CodeRabbit alternatives.

Greptile pricing

Greptile is $30 per seat a month on Pro, with 50 credits per seat and $1 for every extra credit. Credits map to review depth: a base review costs 1 credit, a Plus review 3, and an Apex review 10, so 50 credits is 50 base reviews, about 16 Plus reviews, or 5 Apex reviews. A seat is “any developer who has gotten a review done by Greptile in that billing period”, so a contractor who opens one PR in March is a seat in March.

The free Starter plan covers one active developer with 50 credits a month and unlimited repos, which is a real option for a solo dev. Qualified non-commercial open source with an OSI-approved license is free, pre-Series A startups under $2M in trailing revenue get 50% off, and Enterprise (including self-hosting) is custom. More context in Greptile alternatives.

GitHub Copilot code review pricing

Copilot code review has no price of its own; it comes with a Copilot plan. For individuals that is Pro at $10 a month, Pro+ at $39, or Max at $100; Copilot Free does not include it. For orgs, GitHub’s docs list Business at $19 per granted seat a month with 1,900 AI credits per user, and Enterprise at $39 with 3,900. One AI credit is one cent.

Each review spends credits, and GitHub’s own estimate is $0.05 to $1 of credits per review on Lite effort and $0.25 to $5 on Balanced, rising with PR size and custom instructions. On top of that, the agentic review runs on GitHub Actions, so on private repositories it draws Actions minutes from June 1, 2026 (self-hosted runners do not). PR authors without a Copilot license can get reviews too, billed to the org as AI credits, but an admin has to turn on two policies first. If your team already pays for Copilot, the seat cost is already sunk; see Copilot code review alternatives for how it stacks up on depth.

Graphite pricing

Graphite is a whole PR platform (stacking, merge queue, insights) with an AI reviewer in it, so you are paying for more than review. Hobby is free for personal-account repos with limited AI reviews. Starter is $20 per user a month and Team is $40, both billed annually; Starter has limited AI reviews and Team has unlimited reviews and chat, plus the merge queue and automations. Enterprise is custom.

The pricing page has a 20%-off annual toggle but only shows the annual figures, never says what “limited” means as a number, and bills “per user” without defining a user. Team has a 30-day trial, so you can find out before you commit. If the platform pull is the concern, read Graphite alternatives.

Cursor Bugbot pricing

Cursor announced in May 2026 that it is removing Bugbot seat fees and moving to purely usage-based billing, with existing customers switching at their first renewal after June 8, 2026. Cursor puts the average run at $1.00 to $1.50 depending on PR size and complexity. Billing is per run, so a PR reviewed again after new pushes costs another run.

The pricing page marks Bugbot as included on Premium ($30 a month), Super ($100), Ultra ($200), Teams ($30+ per user) and Enterprise, and not on Free or Plus. It does not publish a per-review rate card, and the Bugbot docs say teams bill from prepaid credit, so you have to budget from your own run count.

What a 10-person and a 50-person team would pay

Assumptions, so you can swap in your own: every developer opens PRs (so every developer is a seat everywhere), annual billing where it is offered, list prices, no overages, and for Bugbot 20 runs per developer a month.

Plan	10 developers / month	50 developers / month
Copilot Business	$190	$950
CodeRabbit Essentials	$240 ($300 monthly)	$1,200 ($1,500 monthly)
Greptile Pro	$300 (500 credits)	$1,500 (2,500 credits)
Copilot Enterprise	$390	$1,950
Graphite Team	$400	$2,000
CodeRabbit Team	$480 ($600 monthly)	$2,400 ($3,000 monthly)
Cursor Bugbot (200 or 1,000 runs)	$200 to $300	$1,000 to $1,500
Pyor Teams (ours)	$79.90	$399.50

Overages are where these totals move. With the same 20 PRs per developer on Greptile using Plus reviews, each developer spends 60 credits against 50 included, and the 10 extra credits each add $100 a month for 10 developers and $500 for 50. On Copilot, Business includes $19 of credits per user, and at the top of GitHub’s Balanced estimate four big reviews use that up. Cursor lists Bugbot under its paid plans, so check whether your team needs a Cursor plan too; the table leaves that out.

Hidden costs: seats, caps and credits

Each vendor counts a seat differently. CodeRabbit bills developers who create PRs, Greptile bills anyone who got a review that billing period, Copilot bills granted seats (plus unlicensed PR authors as AI credits if you enable it), and Graphite bills per user without defining one on the page.
Overages differ too. CodeRabbit switches to $0.25 per reviewed file after the hourly allowance, under a cap you set. Greptile charges $1 a credit, and deeper reviews burn 3 or 10. Copilot charges a cent a credit once the allowance is gone, or pauses until next cycle if admins block paid usage. Bugbot bills every run.
On private repositories, Copilot’s agentic review also uses GitHub Actions minutes, and larger hosted runners cost more per minute.
CodeRabbit and Graphite both advertise 20% off for annual billing, and Graphite only shows the annual price.
Some features sit one tier up: CodeRabbit keeps unit tests and Triage on Team, and Graphite keeps unlimited AI reviews on Team.

Free tiers for open source and individuals

For open source, CodeRabbit reviews public repos for free, Greptile is free for qualified non-commercial OSI-licensed projects, and Graphite’s Hobby plan covers personal-account repos with limited AI reviews. For a solo developer on private code, Greptile Starter (one developer, 50 credits) is the only free reviewer plan here, and Copilot Pro at $10 a month is the cheapest paid one. Copilot Free and Cursor Free and Plus include no AI review at all.

What reading the bot costs

None of these pages has a line for reviewer time, and from experience it is the biggest number. Back-of-envelope, with my assumptions in the open: 10 developers, 20 PRs each a month, a bot leaving 4 comments per PR, and a minute for a human to read each one, decide if it is real, then fix, reply or dismiss. That is 800 minutes, about 13 hours a month. At a loaded $100 an hour, that is roughly $1,300, more than any seat bill in the table above. Halve the comment count and the minutes and it is still about $325, the price of a subscription.

A comment that catches a real bug pays for a lot of minutes. I just want the comments that catch nothing counted too. You still have to read the code anyways, and the output is still on you, so a bot that adds text adds to the bill whether or not it is on the invoice. More on this in review alert fatigue and AI code review accuracy.

Where Pyor fits, and where it does not

Pyor (ours) is not an AI reviewer and does not post comments on your PRs. It is a review surface for GitHub pull requests, on the web and as a desktop app for macOS, Windows and Linux. Its AI groups and labels the diff to separate the noise from the important stuff, and drops short hints on the lines worth a look. The idea is to reduce what you review instead of adding to it.

Pricing, from our pricing page: free for individuals (the AI runs on your own API key or a linked ChatGPT subscription), and $7.99 per seat a month for organizations, with Pyor AI included under a monthly usage cap and a 30-day trial with no card. It does not replace a bot’s bug hunt, so plenty of teams would run one of the tools above for the first pass and Pyor to read what is left.

How to choose by budget

If you already pay for Copilot, turn on code review and watch the credit meter before you buy anything else.
If you want a predictable bill, CodeRabbit’s per-developer price with a spending cap is the easiest to forecast.
If you open few PRs and want depth, Greptile’s credits favor fewer, deeper reviews, so model your Plus and Apex usage first.
If you want the whole PR platform, Graphite Team bundles unlimited AI reviews with stacking and a merge queue.
If your usage is spiky, Bugbot’s per-run billing costs nothing in a quiet month.
If reading is the bottleneck, a reviewer bot won’t lower that cost. That’s the one Pyor is built for.

Pricing pages change often, so treat every number here as checked October 2026 and click through before you sign anything.

Frequently asked questions

How much does AI code review cost per developer?

Checked October 2026 on each vendor’s pricing page: GitHub Copilot Business is 19 dollars per user a month, CodeRabbit Essentials is 24 dollars per developer billed annually (30 dollars monthly), Greptile Pro is 30 dollars per seat with 50 review credits, and Graphite Team is 40 dollars per user billed annually. Cursor Bugbot is usage-based, and Cursor puts an average run at 1 to 1.50 dollars.

What does Greptile cost?

Greptile Pro is 30 dollars per seat a month with 50 credits per seat, then 1 dollar per extra credit. A base review costs 1 credit, a Plus review 3, and an Apex review 10. A seat is any developer who got a Greptile review in that billing period. The free Starter plan covers one active developer with 50 credits a month, and qualified non-commercial open source is free.

Is GitHub Copilot code review free?

No. Copilot Free does not include code review. It is included from Copilot Pro at 10 dollars a month and on Business (19 dollars per user) and Enterprise (39 dollars per user). Each review draws AI credits at 1 cent per credit, and GitHub estimates a typical review at 0.05 to 1 dollar of credits on Lite effort. Reviews on private repositories also use GitHub Actions minutes from June 1, 2026.

Which AI code review tools are free for open source?

CodeRabbit reviews public repositories for free. Greptile is free for qualified non-commercial projects with an OSI-approved license. Graphite’s free Hobby plan covers personal-account repositories with limited AI reviews. Copilot code review and Cursor Bugbot have no free review tier.

What Is a Rubber Stamp Code Review?

Othman Shareef — Thu, 22 Oct 2026 08:00:00 +0000

A rubber stamp code review is an approval granted without genuine evaluation. The reviewer clicks approve without reading the change carefully enough to catch a real problem. The ritual of review happens; the substance does not.

The short answer: Rubber stamping is approval without evaluation, and it is usually rational rather than lazy: oversized diffs, deadline pressure, and social norms make a hollow approve the path of least resistance. Detect it by comparing approval latency to diff size and by watching for zero-comment approvals on non-trivial changes. Fix the causes: smaller changes, explicit review tiers, and honest statements about what was actually checked.

Why capable reviewers rubber stamp

The lazy-reviewer explanation is comforting and wrong. Most rubber stamps are issued by conscientious engineers responding sensibly to a broken situation. SmartBear’s analysis of peer review found that defect detection drops sharply once a review passes roughly 400 lines of code, and that reviewers should move no faster than about 500 lines per hour. Do the arithmetic on a 2,500-line pull request and an honest read costs most of a workday. The reviewer’s calendar does not contain a spare workday. Approving is the only available move that unblocks a teammate, so they take it.

The second force is social. Blocking a change feels confrontational, especially when the author is senior or the deadline is close, and a culture that treats approval as the default turns review into a performance rather than a practice. The third force is incentive: review effort is invisible in most performance conversations, so the rational allocation of a scarce hour goes to work that is seen. None of these people decided to stop reviewing. The system decided for them.

How to detect a rubber stamp code review

The single most useful signal is approval latency measured against diff size. A 3,000-line change approved four minutes after the request was not read; at any credible reading pace that diff needs hours. The second signal is comment density: one review with zero comments means nothing, but a reviewer or a team that produces zero comments across many non-trivial diffs is not evaluating them. Both signals belong in your review metrics as distributions, not as per-person scorecards. The goal is finding a sick process, not shaming an individual.

One caution before you point the detector at anyone: fast approval of a small change is healthy, not suspicious. Google’s study of its Critique review system found that changes there are typically small and reviewed quickly, usually by a single reviewer. Speed only indicts a review when the size of the diff makes the speed impossible. Judge the pair, never the number alone.

Fixes that address causes, not symptoms

Telling people to review harder fails, because effort was never the constraint. The fixes that work remove the conditions that make stamping rational:

Shrink the unit of review. A change that fits inside one honest sitting gets a real read, because a real read is finally affordable. This is the highest leverage fix and the least glamorous.
Tier the rigor explicitly. A dependency bump, a copy change, and a payment-path modification do not deserve identical scrutiny. When the team declares lighter tiers openly, low-risk changes get fast approvals that are honest instead of fake, and attention concentrates where mistakes are expensive.
Normalize honest review statements. An approval that says "reviewed the API surface and error handling, did not run it locally" tells the team exactly what safety net exists. A bare green check pretends to a coverage it may not have. Partial review stated plainly beats total review performed falsely.

A rubber stamp is not a character flaw. It is a signed confession that the review system asked for more attention than anyone had, and the process paid the debt with fiction. Make honest review affordable, and people buy it.

Frequently asked questions

What does rubber stamping mean in code review?

Rubber stamping means approving a pull request without evaluating it enough to catch a real defect. The approval is genuine in the tooling and hollow in substance. It usually shows up as near-instant approvals on large diffs, zero comments on changes that plainly warranted discussion, and reviewers who could not summarize what a change does moments after approving it.

Is rubber stamping always bad?

The speed is not the problem; the dishonesty is. A quick approval on a trivial, low-risk change is proportionate review. The damage comes when a shallow glance gets recorded as a thorough evaluation, because the team then believes a safety check happened that did not. Explicit tiers and honest review statements keep fast approvals from becoming fake ones.

How do I stop my team from rubber stamping reviews?

Attack causes, not reviewers. Cap change size so a real read fits in one sitting, define review tiers so low-risk changes get legitimately lighter treatment, and normalize partial statements like "reviewed the API surface, did not run it". Then track approval latency against diff size at the team level to see whether the pattern is actually improving.