DEV Community: Pyor

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.

GitHub Merge Queue Alternatives: Trunk, Mergify, Aviator

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

We don’t sell a merge queue (we build Pyor, a review surface for GitHub pull requests, and when a repo uses GitHub’s merge queue, Pyor just adds PRs to it). Search for GitHub merge queue alternatives and every comparison on page one is written by Trunk, Mergify, or Aviator, explaining why you should pick Trunk, Mergify, or Aviator. So we wrote our own, and checked every feature and price in it against the vendors’ own docs and pricing pages in October 2026.

The short answer: GitHub’s native merge queue is enough when you have one busy branch, one CI pipeline, and either public org repos or GitHub Enterprise Cloud: it costs nothing and needs no extra app. Move to a third-party queue when you need what it lacks: private repos without Enterprise Cloud, batched CI that bisects failures, flaky-test handling, priority rules, or monorepo lanes. Mergify and Trunk both have free tiers for up to five people. Aviator’s queue starts at $20 per developer a month. Graphite’s queue comes with its $40 Team plan and fits teams that already stack PRs.

What GitHub’s merge queue already gives you

Start here, because the native queue is free and a lot of teams shopping for alternatives haven’t hit its limits yet. Per GitHub’s merge queue docs, each queued PR is tested on a temporary branch that holds the latest target branch plus everything queued ahead of it, and only what passes gets merged. You pick the merge method, a build concurrency between 1 and 100 merge_group runs, a minimum and maximum number of PRs to merge at once with a wait time, and a status check timeout. Turning off “only merge non-failing pull requests” lets a PR that failed checks merge when the last PR in its group passed, which the docs suggest for intermittent failures. The full walkthrough is in the GitHub merge queue, explained.

The third-party queues sell into the gaps, starting with availability. The docs say merge queues are available in public repos owned by an organization, or in private repos owned by organizations on GitHub Enterprise Cloud, so a private repo on the Team plan doesn’t get one. The docs also say merge limits don’t combine merge_group builds, so every queued entry runs its own CI. There’s no priority beyond moving a PR to the top of the queue, and that causes a full rebuild of every in-progress entry. And the docs describe no way to split one branch’s queue by path or build target, which is what monorepo teams ask for.

Trunk Merge Queue

Trunk Merge Queue has the most complete flaky-test story of the group, which makes sense since Trunk also sells a flaky-test product. Its optimizations page lists predictive testing (each PR tested against main plus everything ahead of it), batching that splits a failed batch in half until it isolates the culprit, and parallel queues built from impacted targets, which Bazel and Nx can compute for you and anything else can post through the API. For flakes it has optimistic merging (a passing PR later in the queue validates the ones ahead of it), pending failure depth (a failed entry waits for the runs behind it before it’s ejected), and quarantine through Trunk’s Flaky Tests product. Priority merging lets a hotfix go first, and direct merge skips retesting a PR that’s already up to date when the queue is empty. Trunk says it works with any CI that reports status checks to GitHub.

On Trunk’s pricing page, the merge queue is in every plan: Free covers up to five committers, Team adds unlimited committers and is billed per committer, and Enterprise is custom. The Team price is built by a calculator on the page (it itemizes $10 a committer for unlimited committers and $8 for extra test spans), so we couldn’t pin down a single merge-queue-only number. Check it against your committer count.

Mergify vs GitHub merge queue

Mergify is the one with the most knobs. It runs queue CI on draft PRs, with parallel checks (speculative runs, up to 128 per its docs), and batches that, on failure, split into at least two parts and keep splitting until a single PR fails on its own and gets removed. Priorities are set by label or rule. For monorepos, scopes come from file globs in the config, or are pushed from your build tool, with guides for Nx, Bazel, Pants, and Turborepo. Two-step CI runs light checks on the PR and the heavy suite only in the queue, which is a real saving if your full suite is expensive. It also has pause, scheduled freezes, stacked PRs, and flaky-test quarantine through its Test Engine product.

Mergify’s pricing is free for open source and for private teams of up to five users, then $21 per seat a month on Max ($18 billed yearly) for up to 100 users, with Enterprise custom and an on-prem option. Open source projects should read the plan table closely: the Free plan for small private teams includes batching, scopes, priorities, and two-step CI, and the Open Source plan doesn’t. It gets parallel checks, stacked PRs, and scheduled merges.

Aviator MergeQueue

Aviator MergeQueue is part of a larger suite (review routing, releases, a stacked PRs CLI). It has three queue modes: sequential by default (its docs point out that a 30-minute suite caps you at about 48 merges a day), parallel mode, where each PR gets a bot PR holding everything ahead of it, and a no-queue mode that keeps the merge rules without the guarantee. Batching requeues a failed batch as smaller bisected batches. For flakes there’s optimistic validation, which waits on up to three entries before ejecting a failure, plus a flaky test management feature in beta that reruns tests that pass on retry. A skip_line label moves a PR to the front, and a non-destructive setting lets running builds finish instead of resetting the queue. Affected targets split a monorepo into independent queues, but you compute the targets yourself (bazel-diff, Nx, or top-level folders) and post them to Aviator’s API.

On Aviator’s pricing page, the free tier doesn’t include MergeQueue. Team is $20 per developer a month with a 14-day trial and includes parallel queues, batching, and flaky test handling for up to 10 repos. Affected targets need Scale at $50 per developer a month. Enterprise is custom and can be self-hosted.

Graphite merge queue

The Graphite merge queue is built around stacks. Stacked PRs added together are validated in parallel, and with fast-forward merge on, the queue lands them without rerunning CI. Its optimizations add parallel CI across stacks and batching, which is in private beta behind a support request, with bisection or full parallel isolation on failure. A fast-track option jumps a single PR to the front, though it still rebases and reruns CI. The docs list no dedicated flaky-test handling (they warn that flaky tests cause evictions) and no monorepo scoping. You also have to disable GitHub’s merge queue to use it, though Graphite can instead feed PRs into GitHub’s queue through its external merge queue integration, without the stack-aware optimizations.

On Graphite’s pricing page, the merge queue is in the Team plan at $40 per user a month billed annually; the $20 Starter and free Hobby plans don’t list it. That’s a lot to pay for a queue if your team doesn’t stack PRs, but if it does, Graphite’s is the only queue here designed around stacks from the start. The rest of what Graphite bundles is in Graphite alternatives, and the stacking side, including GitHub’s own preview, is in GitHub stacked pull requests.

GitHub merge queue alternatives at a glance

Queue	Batching	Flaky tests	Monorepo	Price
GitHub native	Group sizes, but one CI run per entry	Optional: let a failed PR ride a passing group	One queue per branch	Free; private repos need Enterprise Cloud
Trunk	Yes, bisects in halves	Optimistic merging, pending failure depth, quarantine	Parallel queues from impacted targets	Free up to 5 committers; Team per committer
Mergify	Yes, splits until the culprit is alone	Quarantine and auto-retry	Scopes from globs or build tools	Free up to 5 users; $21/seat/mo
Aviator	Yes, bisected batches	Optimistic validation, flaky test management (beta)	Affected targets (Scale plan)	From $20/dev/mo; $50 with affected targets
Graphite	Private beta	None documented	None documented	Team plan, $40/user/mo annual

When GitHub’s native queue is enough

If your repos are public under an org or you already pay for Enterprise Cloud, CI is fast enough that one run per queued PR doesn’t hurt, your tests rarely flake, and you jump the queue a couple of times a month at most, stay native. You skip installing another GitHub App with write access, and you don’t take on another dashboard or bill. If you’re not sure you need a queue at all, read what is a merge queue, and if you only need PRs to land themselves once they’re green, auto-merge may be the whole answer.

Switch when one of these is a weekly cost: the queue isn’t available on your private repo, CI minutes for the queue are a real line item (batching), a flaky test ejects good PRs and restarts everything behind them (Trunk, Mergify, Aviator), unrelated teams in a monorepo wait on each other (Trunk, Mergify, or Aviator’s Scale plan), or your team stacks PRs and wants them landed as a unit (Graphite, or the stack support in Mergify and Aviator).

What we left out

Vendor comparison pages make claims about each other that we couldn’t check. Mergify’s and Trunk’s pages both say GitHub’s queue builds its own merge commit, so the SHA that was tested can differ from the SHA that lands, and Trunk links that to an April 2026 incident. GitHub’s docs don’t address it, so we’re reporting it as their claim. The same goes for third-party listings that quote a Trunk free tier limit of 100 merged PRs a month: that limit isn’t on Trunk’s own pricing page.

A queue keeps main green. It can’t tell you whether anyone read the diff, and that part is still on the reviewer, which is the layer we work on. Pyor (free for individuals, $7.99 per seat a month for orgs) has no queue of its own. When a repo uses GitHub’s merge queue, Pyor adds the PR to it.

Frequently asked questions

What is a good alternative to the GitHub merge queue?

Mergify or Trunk Merge Queue for most teams: both have a free tier for up to five people and add batching with failure bisection, flaky-test tolerance, priority rules, and monorepo lanes. Aviator MergeQueue fits teams that also want its review and release tools, from $20 per developer a month. Graphite’s queue makes sense if your team already stacks pull requests in Graphite.

Is the GitHub merge queue available on private repositories?

Only for organizations on GitHub Enterprise Cloud. GitHub’s docs say merge queues are available in any public repository owned by an organization, or in private repositories owned by organizations using GitHub Enterprise Cloud. A private repo on the Team plan, or any repo owned by a personal account, needs a third-party queue instead.

Mergify vs GitHub merge queue: what is the difference?

GitHub’s queue is free and built in, with one queue per branch, group sizes, build concurrency up to 100, and a jump-to-top that rebuilds everything behind it. Mergify adds batched CI runs that split on failure to find the culprit, label-based priorities, path or build-system scopes for monorepos, two-step CI, scheduled freezes, and flaky-test quarantine. It is free for up to five users, then $21 per seat a month.

Is Trunk Merge Queue free?

Yes for small teams. Trunk’s free plan covers up to five committers and includes the merge queue. Larger teams move to the Team plan, which is priced per committer, and Enterprise is custom. Every plan includes the same merge queue features, including batching, parallel queues, and anti-flake protection.

What Is a Merge Queue and Why Do Teams Use One?

Othman Shareef — Tue, 20 Oct 2026 08:00:00 +0000

A merge queue is an automated system that merges pull requests one group at a time, testing each against the latest state of the target branch first, so changes that pass CI in isolation cannot break the branch when combined.

The short answer: What is a merge queue buying you? Certainty that green means green. Instead of trusting checks that ran against an old version of main, the queue builds the merge result that would actually land, runs CI on that, and only then merges. GitHub describes it as automating merges into a busy branch while ensuring the branch is never broken by incompatible changes.

What problem does a merge queue solve?

The stale-CI problem. Your pull request passed its checks, but it passed them against the main branch as it existed when CI last ran. By the time you press merge, five other pull requests have landed. Git may combine everything without a textual conflict and still produce a broken result: your change calls a function someone else just renamed, or relies on behavior another merge removed. Nothing in branch protection catches this, because each change was green on its own. The manual fix is updating your branch and re-running CI before merging, but on a busy repository that becomes a race: by the time your re-run finishes, main has moved again. Teams end up with developers babysitting the merge button, or with a main branch that breaks weekly for reasons no single PR caused.

What is a merge queue doing under the hood?

Instead of merging immediately, an approved and green pull request is added to a queue. From there, per the GitHub merge queue docs, the process looks like this:

The queue creates a temporary branch containing the speculative merge result: the latest target branch, plus the queued pull request, plus any pull requests ahead of it in line.
Required CI checks run against that merge group, not against the stale branch.
Pull requests merge in first-in-first-out order, each only after its group passes.
If a group fails, the failing pull request is removed from the queue and the speculative merges behind it are rebuilt without it.

Batching is the efficiency trick: by testing several queued pull requests together in one merge group, the queue validates many changes with one CI run and keeps throughput high even when each run takes twenty minutes. Batch size and merge method are configurable per repository, so teams can tune throughput against CI cost.

Who needs a merge queue?

The queue earns its complexity in proportion to merge traffic. Signals that you have crossed the line: developers regularly click update branch two or three times before a merge sticks, main breaks from combinations of individually green changes, or merge order has become something people coordinate in chat. High-traffic monorepos and teams practicing trunk-based development hit this earliest, since everyone is landing small changes into the same branch all day. If that is you, our deep dive on the GitHub merge queue covers setup, CI wiring, and the operational sharp edges.

What does a merge queue not do?

A queue automates the last step, not the judgment before it. It does not review code, and it does not loosen required reviews; a pull request still needs its approvals and passing checks just to enter. It also does not decide that a pull request is ready, which is auto-merge territory; the two compose nicely, with auto-merge queueing the PR the moment review completes. And it cannot save you from flaky tests: a queue amplifies test unreliability, because one flaky failure now ejects a pull request and re-runs everything behind it. Green must mean green for the queue to mean anything.

Frequently asked questions

Does a merge queue replace required reviews or CI?

No. It sits after them. A pull request still needs its approvals and passing checks to enter the queue; the queue then re-runs required checks on the speculative merge result. Think of it as a final gate that validates the combination, not the individual change.

What happens when a pull request fails in the merge queue?

It is removed from the queue rather than merged, and the queue rebuilds the speculative merges for the pull requests behind it without the failing change. The author fixes the problem and re-queues. Everything else keeps flowing, which is the point of the design.

Do small teams need a merge queue?

Usually not. The stale-CI problem grows with merge frequency. A team merging a few pull requests a day can just update branches before merging. Once merges start racing each other daily, or updating branches becomes a full-time chore, a queue starts paying for itself.

Graphite vs CodeRabbit for PR Reviews: An Honest Take

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

We sell neither Graphite nor CodeRabbit (we build Pyor, a review surface that sits next to both, so read this with that in mind). The two get compared as if they were the same kind of product, but Graphite is a pull request workflow and CodeRabbit is a review bot that joins the workflow you already have. We checked everything below against the vendors’ own pages and one open benchmark in October 2026, and where the sources disagree we say so.

The short answer: Graphite and CodeRabbit only overlap on one feature. CodeRabbit is a dedicated AI reviewer that comments on your PRs, on four git hosts, from $24 per developer a month. Graphite is a GitHub workflow platform (stacked PRs, a merge queue, an inbox) that also ships an AI reviewer, with unlimited AI reviews at $40 per user a month. On an open benchmark, CodeRabbit catches far more issues and Graphite stays quieter. Pick CodeRabbit if you want a bot, and Graphite if you want stacking.

What each one is for

Graphite is a pull request workflow platform for GitHub. Its core is stacked pull requests: a CLI and a VS Code extension that let you split a big change into a chain of small dependent PRs without the rebase bookkeeping. Around that sit a stack-aware merge queue, a PR inbox, Slack notifications, team insights, and an AI reviewer. Graphite’s homepage calls it “the AI code review platform”, but what your team adopts is the platform, and the reviewer comes with it.

CodeRabbit is a dedicated AI review agent. You install it, and it reviews every pull request with line comments, a summary, one-click fixes, and pre-merge checks. Per its docs it runs on GitHub, GitLab, Azure DevOps, and Bitbucket, in VS Code, Cursor, and Windsurf through an extension, and from a CLI before you commit. Your team branches and merges the same way it did before.

AI review quality on an open benchmark

Most “benchmarks” you will find for these two are run by a vendor, and the vendor tends to win. The one we trust most is Martian’s Code Review Bench, because its method and code are open source and Martian runs every tool itself rather than taking submitted results. It has two modes, and both include CodeRabbit and Graphite.

The offline benchmark uses 50 PRs from five open source projects (Sentry, Grafana, Cal.com, Discourse, and Keycloak) with human-verified “golden” comments, then has an LLM judge match each tool’s comments against them. In the snapshot dated September 8, 2026 (default judge and category profile), CodeRabbit scored 42.2% F1 with 59.5% recall and 32.6% precision. Graphite scored 14.1% F1: it made 12 correct comments and zero wrong ones, for 100% precision, but found only 7.6% of the known issues.

The live benchmark is the one we weigh more. It samples fresh merged PRs on GitHub where a bot commented, and counts a bot comment as useful when it matches a fix the developer made afterwards. Over December 25, 2025 to October 17, 2026, with the leaderboard’s filters cleared, CodeRabbit sat at 52.2% F1 (54.2% precision, 50.2% recall) across about 48,900 scored PRs. Graphite sat at 41.5% F1 (64.9% precision, 30.6% recall) across about 1,460. You only see Graphite once you clear the default volume filters, since it reviews far fewer public PRs than CodeRabbit does.

Both modes show the same trade. Graphite’s reviewer says little, and what it says is usually right. CodeRabbit says a lot more and catches a lot more, with more comments that go nowhere. Graphite’s own AI reviews page leans into that trade (it claims a negative comment rate under 5% in its own tests, without publishing the method). An older July 2025 test published by Greptile points the same way (CodeRabbit caught 44% of 50 planted bugs, Graphite 6%), but Greptile sells a competing reviewer and scored itself highest, so weigh it as a vendor claim.

Precision decides how much of your reviewers’ time the bot burns, and recall decides how much it saves them from missing. We cover why benchmarks disagree in how accurate AI code review really is. A two-week trial on your own PRs will tell you more than any of these numbers.

Pricing and free tiers in 2026

As of October 2026, Graphite’s pricing page lists annual prices only, and CodeRabbit’s lists annual prices with monthly prices in its FAQ.

	Graphite	CodeRabbit
Free	Hobby: personal repos only, limited AI reviews and chat	Free reviews on public repos; no free plan for private repos
Entry paid tier	Starter, $20/user/mo billed annually: org repos, AI reviews still limited	Essentials, $24/dev/mo annual or $30 monthly
Unlimited AI review	Team, $40/user/mo billed annually, which also adds the merge queue	No total cap; past an hourly per-developer allowance, $0.25 per reviewed file
Higher tiers	Enterprise, custom	Team $48 ($60 monthly), Advanced $72, Enterprise custom
Trial	30-day trial	14-day trial

For unmetered AI review on private org repos, Graphite starts at $40 a seat and CodeRabbit at $24. Graphite’s $40 also buys the merge queue and stacking workflow, so if you would not use those, you are paying for a platform to get a reviewer. Model CodeRabbit’s usage pricing before you commit: Essentials allows 5 reviews per developer an hour, and continued reviews bill per file, with an admin spending cap to stop surprises.

Workflow lock-in and who owns what

CodeRabbit is easy to leave. It is an app on your repos, so when you uninstall it, your PRs, branches, and merge process stay exactly as they were. You lose its configuration and the “learnings” it has collected from your team’s feedback. It also follows you across hosts, which matters if part of the org lives on GitLab or Bitbucket.

Graphite asks for more commitment, by design. The AI reviewer alone is not sticky: Graphite’s setup docs say it reviews all new PRs in the repositories you pick, with no stacking required. But $40 a seat is a lot to pay for the reviewer alone. You get your money’s worth when the team branches through the Graphite CLI and merges through its queue, and unwinding that means changing how everyone works. Its setup docs also only describe GitHub.

Graphite’s ownership has changed too. On December 19, 2025, Graphite signed a definitive agreement to join Cursor (the company is Anysphere). Both companies said Graphite would keep operating as an independent product, and Graphite’s post lists plans to combine its AI reviewer with Cursor’s Bugbot into one reviewer. Since then Graphite has shipped Cursor Cloud Agents inside Graphite (March 2026, for paid Cursor plans), and Cursor itself was acquired by SpaceX in August 2026. Graphite works the same today, but its reviewer may change shape, and its roadmap now follows Cursor’s.

If stacking is the draw, GitHub now ships native stacked pull requests in public preview, which we cover in GitHub stacked pull requests. Graphite is far more mature today, but it is no longer the only way to stack.

Who should pick which

Pick CodeRabbit if you want an AI first pass on every PR without changing your workflow, you are on more than one git host, or you want the reviewer that catches the most on the open benchmark and can live with more comments to triage.
Pick Graphite if your team will actually adopt stacked PRs and a merge queue. Stacking gets you smaller PRs, and the reviewer rides along as a quiet extra that rarely wastes your time.
Use both if you want Graphite’s stacking and CodeRabbit’s catch rate. Turn Graphite’s reviewer off on those repos, or you will read two bots on every PR.

If you are looking for a Graphite competitor because you only ever used the reviewer, you have the clearest case for switching: a dedicated bot does that job for less. Our Graphite alternatives and CodeRabbit alternatives posts map the rest of the field.

When neither is the bottleneck

On a lot of teams (ours included), the slow part of review is a human reading a big diff. The bottleneck shifted from producing code to reviewing it. A bot adds comments to read and stacking changes how PRs are cut, but if your PRs are a 20K-line migration that cannot be stacked, or agent-written changes that land faster than anyone reads them, a reviewer bot hands you one more layer of text, and you still have to read the code anyways.

That is the problem we built Pyor for (yes, this is the plug, kept short). Pyor is a review surface for GitHub PRs, on the web and as a desktop app for macOS, Windows, and Linux. It is not an AI reviewer, and its AI posts no comments: it groups and labels the diff and drops short hints so you read the code that matters first and skim the noise. It adds PRs to GitHub’s merge queue rather than running its own, and while it does not create stacks, it surfaces GitHub native stacks while you review. Pyor is free for individuals and $7.99 per seat a month for orgs, and it works next to either tool here. The feature-by-feature versions are in Pyor vs Graphite and Pyor vs CodeRabbit.

Frequently asked questions

Is Graphite or CodeRabbit better for AI code review?

If the AI reviewer is all you want, CodeRabbit. On Martian’s open Code Review Bench it catches far more of the issues developers actually fix, while Graphite’s reviewer is quieter and more precise but misses most of them. What you pay Graphite for is stacked pull requests and a merge queue, and the reviewer comes with them.

Is CodeRabbit a Graphite competitor?

Only on the AI review part. CodeRabbit is a dedicated review bot that plugs into GitHub, GitLab, Azure DevOps, or Bitbucket. Graphite is a workflow platform for GitHub built around stacked pull requests, a merge queue, and an inbox, with an AI reviewer as one feature.

Can you use Graphite and CodeRabbit together?

Yes. Graphite’s AI reviews are switched on per repository or per organization, and CodeRabbit installs as its own app, so a team can stack and merge with Graphite and let CodeRabbit post the review comments. You pay for both, and you read both if both are on.

Who owns Graphite now?

Graphite signed a definitive agreement in December 2025 to be acquired by Cursor (the company is Anysphere), and both said Graphite would keep running as an independent product. Cursor itself was acquired by SpaceX in August 2026. Graphite is still sold and priced on its own.

Interdiff Meaning: What an Interdiff Is in Code Review

Othman Shareef — Sun, 18 Oct 2026 08:00:00 +0000

An interdiff is the diff between two versions of the same change. Instead of re-reading a whole pull request after an update, you read only what the author changed between revision one and revision two.

The short answer: The interdiff meaning is easiest to see as a diff of diffs: version one of a patch said how the code should change, version two says it differently, and the interdiff shows exactly where the two disagree. It answers the only question a returning reviewer has: what is different since I last looked?

Why does re-review need an interdiff?

First review is well supported everywhere: you get a diff against the base branch and you read it. The second review is where tooling has historically gone quiet. The author pushed fixes, maybe rebased, maybe reworked a section you never commented on, and the platform shows you either the same full diff again or a per-commit view polluted by rebase noise. So reviewers face a bad menu: re-read everything (nobody does), read nothing and approve (everybody eventually does), or reconstruct the delta by hand. An interdiff replaces that menu with the right default: show me revision two minus revision one. We walk through the workflow consequences in our piece on re-reviewing pull requests with interdiffs; this article is just the definition underneath it. The cost of getting this wrong is quiet: the revision that introduces a bug is precisely the one nobody re-read, because it arrived after the hard first pass was already done. Reviewers approve version one carefully and version four on trust, and the delta between those two readings is where regressions live.

Interdiff meaning in git: the range-diff command

Git ships the idea natively as git range-diff, which compares two commit ranges, typically two versions of the same branch, and shows which commits correspond, which were added or dropped, and how each corresponding commit changed. After a force-push you can run something like git range-diff main old-tip new-tip and read precisely what the rework did, rebase and all. The name interdiff itself is older: a standalone utility of that name compared two patch files back when changes traveled as emailed patches, and kernel reviewers still routinely ask contributors to post a range-diff alongside v2 of a patch series.

Where do patchsets come from? The Gerrit heritage

Gerrit, the review system built around the Android project, made revisions first-class: every push to a change under review becomes a numbered patchset, and the UI lets a reviewer diff any patchset against any other. Comment positions carry across revisions, so a thread you opened on patchset 2 is still anchored correctly when you are comparing patchset 2 to patchset 5. That lineage is why review veterans talk about patchsets and interdiffs in the same breath: Gerrit demonstrated that re-review is a solved problem when versions of a change are modeled explicitly rather than as an afterthought.

What GitHub gives you, and where it falls short

GitHub approximates the interdiff. It can show changes since your last review, and viewed-file checkmarks reset when a file changes, which together cover the easy case: new commits appended to the same history. The approximation degrades exactly where you need it most. A rebase or force-push rewrites the commits the comparison was anchored to, comments go outdated, and the since-review view can fall back to showing you everything again. There is no patchset picker, no durable revision history to diff against. Until the platform models revisions properly, reviewers cover the gap with git range-diff locally or with review tools built around the returning reviewer (disclosure: our own Pyor is one attempt at that). However you get one, the test of a review tool is the second look, not the first.

A commit rail as the revision picker: select a commit and the diff re-scopes to that span.

Frequently asked questions

What is the difference between an interdiff and git range-diff?

An interdiff is the concept: the difference between two versions of a change. git range-diff is the built-in git command that produces one, comparing two commit ranges and showing how each commit changed between them. Older tooling also had a literal interdiff utility for comparing patch files.

Does GitHub show an interdiff?

Approximately. GitHub can show changes since your last review, and its viewed-files checkmarks reset when a file changes. But a force-push rewrites history and can break that view, and there is no first-class revision picker like Gerrit patchsets, so the approximation fails exactly when rebases happen.

Why not just re-read the whole pull request?

Because full re-reads do not scale and reviewers do not actually do them. Faced with a 40-file PR updated for the third time, most reviewers skim and approve. An interdiff shrinks the third look to the handful of lines that changed, which keeps re-review honest.

What Are Stacked Pull Requests?

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

Stacked pull requests are a chain of dependent PRs where each one builds on the branch of the previous. A large change is split into small steps, reviewed independently, and merged from the bottom of the stack up.

The short answer: What are stacked pull requests solving? The conflict between how developers work and how reviewers read. Big features are built in sequence, but nobody reviews a 2,000-line diff well. A stack keeps the author moving on step three while steps one and two are under review, and every reviewer only ever sees a small, coherent piece.

How do stacked pull requests work?

Instead of one feature branch targeting main, you cut a chain: branch A off main, branch B off A, branch C off B. Each branch becomes a pull request whose base is the branch below it, so every diff shows only that step. Say you are adding an export feature: PR one adds the data model, PR two the API endpoint on top of it, PR three the UI on top of that. Review and merge run bottom up. PR one merges into main first; PR two is then retargeted onto main and merged; PR three follows. When a lower PR changes in response to review, the branches above it are rebased so the stack stays consistent. That rebase cascade is the tax the whole workflow lives with, and we will come back to it.

What are stacked pull requests for?

Small diffs get better reviews; that is one of the most consistent findings in review practice, and it is the core argument in our guide to how big a pull request should be. The problem is that real features are often irreducibly large. Without a stack, the author faces a bad choice: ship one huge PR that gets skimmed, or sit blocked waiting for each small PR to merge before starting the next. Stacking removes the wait. The author keeps building on their own unmerged work while review proceeds underneath, and each reviewer gets a diff sized for actual reading. It is the same instinct behind atomic commits, promoted from commit granularity to PR granularity.

What tools support stacking?

GitHub has begun building stacks in natively: as InfoWorld reported, GitHub added stacked pull requests specifically to speed up review of complex changes. Since 30 July 2026 it has been in public preview for every repository, no waitlist, though still labelled subject to change; we track the details in our deeper look at GitHub stacked pull requests. In the meantime the workflow is well served by third-party tools (Graphite is the best known) that automate the branch bookkeeping: creating the chain, restacking after changes, and retargeting PRs as lower ones merge. And plain GitHub works too, manually, for shallow stacks. The broader tool landscape is covered in our roundup of GitHub PR review alternatives.

What do stacks cost?

The honest ledger has three entries. First, rebase overhead: every change to a lower PR ripples upward, and without tooling you pay that in manual rebases and force-pushes. Second, review coordination: reviewers of PR three are looking at code built on unreviewed foundations, and feedback on PR one can invalidate work above it. Third, platform friction: force-pushing rebased branches can confuse review state, resetting what reviewers had already read. None of this is disqualifying, but it means stacks are a deliberate practice, not a free upgrade. Use them when the work is genuinely large and sequential, keep each layer independently understandable, and let the bottom of the stack merge fast. A stack whose base PR sits unreviewed for a week is just a big PR with extra steps.

Frequently asked questions

Can you create stacked pull requests on GitHub without extra tools?

Yes. Open each branch against the one below it instead of against main, then merge from the bottom and retarget as you go. It works, but keeping the stack rebased by hand gets tedious past two or three PRs, which is why dedicated stacking tools exist.

How is a stacked pull request different from a normal branch with many commits?

A multi-commit branch still lands as one pull request with one review and one merge. A stack splits the same work into separate PRs, each with its own reviewer, discussion, CI run, and merge, so review happens in small units while the work stays connected.

When are stacked pull requests not worth it?

When the change is already small, or when the pieces are truly independent and could just be separate unrelated PRs. Stacks pay off when work is large and sequential. If your team rarely reviews within a day, the coordination cost of a stack can exceed its benefit.