The short answer: Agentic code review is reviewing code whose author cannot explain itself. Classic review validates a colleague’s reasoning; agentic review reconstructs reasoning that was never written down. The adaptations that follow from that one difference: capture intent at generation time, tier review rigor by blast radius instead of reviewing everything identically, treat tests with suspicion when the same model wrote them, and keep one rule absolute: a human owns the merge.

The data says the process already broke

Osmani’s essay compiles the numbers, and they are stark. He cites a Faros analysis of 22,000 developers reporting code churn up 861%, defect rates jumping from 9% to 54%, and zero-review merges rising 31.3%. GitClear’s data, in his reading, shows roughly 4x the raw output for around a tenth of that in delivered value. Whatever error bars you put on any single figure, the direction is consistent with what maintainers and the research record already showed: teams did not decide to stop reviewing. Volume overwhelmed a process designed for human-paced authorship, and the process failed silently.

The author is absent, so intent must be captured

When a colleague writes a confusing change you ask them why. When an agent writes it, the “why” lived in a prompt session that is gone. Developers are hitting this wall in the wild: a recent r/devops thread asks, verbatim, whether anyone else has lost the reasoning behind an AI-generated Terraform change after the session ended. The fix is procedural, not clever: the person who ran the agent writes the intent down while it still exists. What was asked for, what the agent chose, what was rejected, what is untested. That is author self-review upgraded from good manners to load-bearing infrastructure, because it is the only place the missing context can come from.

Tier the rigor, or fatigue will tier it for you

Osmani’s most practical frame is that review intensity should follow three variables: blast radius (what breaks if this is wrong), longevity (throwaway script or load-bearing system), and ownership (solo project or shared codebase). A config tweak in a prototype and a change to a payment path do not deserve the same reviewer attention, and pretending they do is how teams end up giving everything the same shallow glance. The honest version is explicit tiers: automated gates plus sampling at the bottom, full human verification with the AI-code checklist at the top. Review attention is the scarce resource; spend it where mistakes are expensive.

Watch the tests watching the code

The failure mode Osmani flags that deserves its own alarm: agents modifying tests until they pass. When the same model writes the implementation and the assertions, green CI stops meaning what you think it means. Reviewers of agent PRs should read test diffs first and treat any test relaxation (deleted assertions, widened tolerances, skipped cases) as the highest-signal lines in the change. We will go deeper on this in a dedicated piece; for now, the rule of thumb is that in an agent PR, the tests are part of the claim, not part of the evidence.

A human owns the merge

Every adaptation above rolls up to one boundary that should survive any amount of automation: accountability does not transfer to a model. Review bots can pre-filter (we have argued for exactly that division), sampling can replace exhaustive reading on low-risk tiers, but the merge button is a human act by a person prepared to answer for the change in production. As Osmani put it in the LinkedIn discussion around his essay: reading code has always been the skill, and it is about to be the skill. The teams that hold that line while their tooling accelerates are the ones whose review process survives contact with the agent era.

The uncomfortable part for tooling (ours included, disclosure: we build Pyor) is that none of this is solved by adding more generated text to the PR. It is solved by making the irreducible human read fast enough to keep up: triage, provenance, risk-first ordering. That is the bar any review tool should be judged against now.

Frequently asked questions

What is agentic code review?

Agentic code review is the practice of reviewing code written wholly or largely by AI agents. It differs from classic review because the author cannot explain its intent: the reviewer reconstructs missing reasoning rather than validating a colleague’s. In practice it means tiered rigor by risk, explicit provenance, and a human who owns the merge.

Should every agent-written change get a full human review?

No, and pretending otherwise is how teams end up rubber-stamping everything. The workable pattern is tiered: throwaway and low-blast-radius changes get sampling or automated gates, while long-lived code and risky paths (auth, payments, data) get full human verification. What matters is choosing the tier deliberately instead of by fatigue.

Does agentic review replace the reviewer?

It changes what the reviewer does. Less line-by-line defect hunting (automation absorbs much of that), more judgment: does this match intent, does it fit the system, is the blast radius acceptable. Accountability does not transfer: a human owns the merge, because someone must answer for the change in production.

The map: Greptile’s edge is whole-codebase context: a graph index plus a swarm of agents that reason across files. Its alternatives are other bots (CodeRabbit, the most built-out; GitHub Copilot code review, cheapest if you already pay for Copilot) and a non-bot approach (Pyor, a review surface whose AI triages the diff instead of commenting). Its $30-per-seat credit pricing is a real factor.

What Greptile is genuinely good at

Greptile calls itself the AI code reviewer, and its distinguishing move is context. Instead of reading only the diff, it builds a graph index of your codebase and runs a swarm of agents in parallel, so a review can reason across files. That is why it is good at multi-file logical bugs, the kind a single-file bot walks right past, alongside style, security, syntax, and logic checks on GitHub and GitLab across many languages. Pricing is transparent and part of the decision: 30 dollars per seat a month including 50 credits (one credit is one review), then 1 dollar per extra review, free for qualified open source with discounts for pre-Series-A startups. If cross-file reasoning is what you need, that context is a real reason to keep it.

The reasons to look around are the category-wide ones and the pricing one. A bot is a first pass, not a reviewer (it does not know your intent and shares blind spots with the code’s author, human or model), and the credit model means cost scales with review volume. We cover the trust question in do code reviews find bugs and the noise cost in review alert fatigue.

CodeRabbit: the most built-out bot

CodeRabbit is the closest like-for-like alternative if you want a bot but not Greptile’s pricing model. It posts AI review comments across GitHub, GitLab, Azure, and Bitbucket, reviews in the IDE (VS Code, Cursor, Windsurf) and from a CLI as well as on the PR, and adds bug detection, architectural-impact notes, one-click “Fix with AI”, summaries with walkthroughs and diagrams, 40-plus linters and security scanners, and a feedback loop it calls learnings. It is SOC 2 Type II with zero data retention after review, free to try with no credit card, and free for qualified open source. It does not advertise Greptile’s whole-codebase graph, but for breadth of platform and features it is the mainstream pick.

GitHub Copilot code review: cheapest if you already pay

GitHub Copilot code review is the value alternative for GitHub-native teams. The AI first pass is included in Copilot Pro (10 dollars a month), Pro+ (39 dollars a month), Business (19 dollars per user a month), and Enterprise (39 dollars per user a month), so if you already pay for Copilot, there is no new bill. Two caveats before you count on it: it is not in the free tier, it is disabled by default so an admin must enable it and turn on GitHub AI Credits billing, and review usage by non-licensed users bills to the org as AI Credits. It will not match Greptile’s cross-file depth, but if breadth of context is not your need, it is the lightest and cheapest bot to switch on.

Pyor: the different approach

Every alternative so far posts comments on the PR. Pyor does not, on purpose. It is a review surface for existing GitHub pull requests, web first with a macOS and Windows desktop app, where you read, comment, approve, and merge in one window, with a file rail built for triage, folder-level viewed tracking, focus mode, and threads that survive a force-push. Where it uses AI, the AI organizes the diff rather than narrating it: it groups files by complexity, labels each group in one line, and points you at what deserves attention first, with an optional walkthrough. It does not generate the comment volume a bot produces. If the honest issue with Greptile is that even a smart bot still hands you more text to read, that is the disagreement Pyor is built around, and we make the case in what AI should do in code review.

Honest caveats: Pyor is young, it is a review surface and not a workflow platform, and it does not offer Greptile’s whole-codebase graph analysis, because it is not trying to be a reviewer bot at all. It is the answer when reading is the bottleneck, not when you want an automated cross-file audit. Free for individuals; paid per-seat for org features.

The credit model deserves its own moment, because it is the sharpest difference from a flat-rate bot. At 50 reviews per seat each month, a heavy reviewer on a busy repo can exhaust the included credits and start paying a dollar per extra review, while a light reviewer leaves most of them unused. That is neither good nor bad on its own; it just means Greptile rewards you for modelling your real review volume before you buy, in a way a flat per-seat bot does not. If your volume is spiky or hard to predict, a predictable subscription like CodeRabbit or Copilot code review can be easier to budget, and that tradeoff, not raw capability, is often what actually decides the switch.

At a glance

Tool	Approach	Best for	Pricing
Greptile	AI reviewer with whole-codebase graph	Multi-file logical bugs	$30/seat/mo, 50 credits; $1 per extra
CodeRabbit	AI comments across four platforms	A built-out, configurable bot	Free trial; free for open source
Copilot code review	AI first pass native in the PR	Teams already paying for Copilot	Included in Copilot (from $10/mo)
Pyor (ours)	Review surface, AI triages not comments	Reading big diffs is the bottleneck	Free for individuals; per-seat orgs

How to choose among Greptile alternatives

• Cross-file context earns its keep? Greptile’s graph is the reason to stay.
• Want a bot without the credit model? CodeRabbit is the built-out alternative.
• Already paying for Copilot? Copilot code review is the cheapest first pass.
• More text is the last thing you need? Pyor triages the diff instead of adding to it.

They all sync to GitHub, so try one on a single real PR first. For the wider bot comparison see CodeRabbit alternatives, and for the native option see GitHub Copilot code review alternatives.

Frequently asked questions

What is the best Greptile alternative?

It depends on what you value in Greptile. If it is the AI-reviewer-bot pattern, CodeRabbit is the most built-out alternative and Copilot code review is the cheapest if you already pay for Copilot. If whole-codebase context is not the point and reading big diffs is, Pyor takes a different approach and triages the diff instead of commenting.

Is Greptile worth $30 per seat?

If whole-codebase context earns its keep, often yes. Greptile prices at 30 dollars per seat a month including 50 review credits, then 1 dollar per extra review. That credit model is worth modelling against your PR volume. Teams that mostly need a lighter first pass may find CodeRabbit or Copilot code review cheaper for their usage.

What makes Greptile different from other bots?

Its differentiator is context. Greptile builds a graph index of your codebase and runs a swarm of agents in parallel, so a review can reason across files rather than just the diff. That helps it catch multi-file logical bugs a single-file bot misses. The tradeoff is its credit-based pricing and one more vendor in the loop.

You do not have to take our word for it. In April 2026 GitHub shipped Stacked PRs, and the announcement is a quiet confession: “Large pull requests are hard to review, slow to merge, and prone to conflicts. Reviewers lose context, feedback quality drops, and the whole team slows down.” That is the platform describing its own review surface.

The short answer: Reviewing on github.com is a default, not a decision. The web diff was built to host and browse code, so it does the reading parts badly: big files hide behind “Load diff,” you lose your place between visits, threads detach from the code, and there is no triage. You can fix this without leaving GitHub: keep the PRs there, move the act of reviewing to a surface built for it, and sync everything back.

GitHub is a host that grew a review tab

The pull request was a distribution mechanism first: a way to propose and merge a branch. Review was bolted on, and it shows in the priorities. The diff paginates and collapses to protect the page, not your understanding. There is no notion of which files matter, so a lockfile and the one file that changes behavior get equal billing. The whole thing is tuned for browsing a change, which is a fundamentally different task than reconstructing and judging one.

The concrete failure modes

This is not an aesthetic complaint. The web diff actively taxes review in specific, repeatable ways (several catalogued in this critique of the GitHub review UI):

• “Load diff” is where files go to die. The exact files heavy enough to collapse are the ones most worth reading, and the click-to-expand friction means they get skimmed or skipped. The UI hides the risk by default.
• You lose your place. Come back to a PR after lunch and there is no reliable record of what you already read. On a 40-file diff, re-orientation eats the session.
• Threads drift from the code. A reviewer comments, you push a fix, and whether they consider it resolved stays ambiguous. Re-review, the interdiff problem, is where the most time quietly disappears, and the web diff has the weakest tools for it.
• No triage. Every file is presented as equally important, so the reviewer does the sorting by hand, every time, by scrolling.

None of these is fatal on a 30-line PR. All of them compound on the large, AI-authored diffs that now arrive several times a day, which is exactly why GitHub itself reached for stacking.

“But everyone is already on GitHub”

This is the real objection, and it rests on a conflation. Leaving the github.com review experience is not the same as leaving GitHub. Your code, your pull requests, your CI, your permissions, your merge: all of it stays exactly where it is. The only thing that moves is the surface where a human reads the diff and leaves comments, and every serious review tool syncs those comments, approvals, and merges straight back to the PR. Your teammates who never leave github.com see a perfectly normal review. You just did the reading somewhere that respects your attention.

Where to review instead

There is no single answer, and we wrote an honest comparison of the options. The short version:

• Pull the branch. git fetch && git checkout gives you full editor navigation and the ability to run the code. Unbeatable context, real friction; best for the one architectural change that needs it, covered in local vs. browser review.
• An AI-guidance layer (for example Stage) narrates the diff into chapters. Useful when orientation is your bottleneck, at the cost of more generated text to read and trust.
• A dedicated review surface (this is what we build with Pyor, disclosure) keeps the diff but fixes the reading: triage the files that matter, mark whole folders viewed, scope the diff to a single commit so re-review costs only the delta, and run the whole read-comment-approve-merge loop in one window. AI organizes the diff (groups by complexity, one-line labels, hints) rather than narrating it. Free for individuals, synced to GitHub.

How to actually stop

You do not need a migration or a team meeting. Pick your next genuinely large PR, the kind you would normally dread in the web diff, and review it somewhere else once. Pull it locally, or open it in a dedicated surface, leave your comments, and let them sync back. One real PR is enough to feel the difference between a tool that hosts your code and a tool that helps you understand it. If reviewing has quietly become the slowest part of shipping, the surface you do it on is the cheapest thing you can change.

Frequently asked questions

Does this mean leaving GitHub entirely?

No. Keep your code, PRs, CI, and permissions on GitHub. The argument is narrower: stop doing the act of reading and judging the diff inside github.com's web UI. Every serious alternative syncs comments, approvals, and merges back to GitHub, so the PR still lives where it always did.

Isn't the GitHub review UI fine for small PRs?

Largely, yes. For a 30-line change the web diff is quick and the friction never shows up. The case for reviewing elsewhere grows with size and frequency: it is the 800-line, 40-file, AI-authored PRs arriving several times a day where the surface starts costing you real review quality.

What should I review code on instead?

Three honest options: pull the branch and read it in your editor (best context, high friction), an AI-guidance layer like Stage (a narrated map over the diff), or a dedicated review surface like Pyor (triage, viewed-state, commit-scoped diffs, synced back to GitHub). Try one on a single real PR before committing the team.

The map: GitHub Copilot code review is the cheapest AI first pass if you already pay for Copilot. Its alternatives split two ways: dedicated bots that go deeper (CodeRabbit across four platforms, Greptile with whole-codebase context), and a non-bot approach (Pyor, a review surface whose AI triages the diff instead of posting comments you still have to read).

What GitHub Copilot code review does well

GitHub Copilot code review gives you an AI first pass natively inside the PR, no extra vendor, no new surface. Its advantage is almost entirely economic and logistical: if your team already pays for Copilot, review is included in Copilot Pro (10 dollars a month), Pro+ (39 dollars a month), Business (19 dollars per user a month), and Enterprise (39 dollars per user a month). For a GitHub-native team that already has seats, nothing is cheaper to switch on. Two frictions are worth stating plainly before you rely on it: it is not in the free tier, it is disabled by default so an admin must enable it and turn on GitHub AI Credits billing, and review usage by non-licensed users bills to the org as AI Credits. If those apply, the alternatives below can be simpler to reason about.

The other reason to shop around is depth. Like any bot, Copilot review is a first pass, not a reviewer, and its analysis is scoped tightly to the change in front of it. As we argue in what AI should do in code review, the value of an AI pass is in what it lets a human skip, not in the comment count.

CodeRabbit: a deeper, multi-platform bot

CodeRabbit is the most built-out bot in the category and the natural step up if Copilot review feels thin. It posts AI review comments across GitHub, GitLab, Azure, and Bitbucket, reviews in the IDE (VS Code, Cursor, Windsurf) and from a CLI as well as on the PR, and adds bug detection, architectural-impact notes, one-click “Fix with AI”, change summaries with walkthroughs and diagrams, 40-plus linters and security scanners, and a feedback loop it calls learnings. It is SOC 2 Type II with zero data retention after review, free to try with no credit card, and free for qualified open source. If you want more coverage and more configurability than the native option, CodeRabbit is the mainstream upgrade.

Greptile: whole-codebase context

Greptile attacks the exact limitation of a single-diff bot: it builds a graph index of your codebase and runs a swarm of agents in parallel so a review reasons across files, which is where multi-file logical bugs hide. It covers GitHub and GitLab and many languages, and its pricing is transparent: 30 dollars per seat a month including 50 credits (one credit is one review), then 1 dollar per extra review, free for qualified open source with startup discounts. If your frustration with Copilot review is that it misses issues spanning several files, Greptile is the alternative built around that problem. The tradeoff versus Copilot is cost and one more vendor, against materially more context. Independent takes on how far to trust any bot are in AI code review accuracy.

Pyor: the non-bot approach

Every option so far posts comments on your PR. Pyor deliberately does not. It is a review surface for existing GitHub pull requests, web first with a macOS and Windows desktop app, where you read, comment, approve, and merge in one window. Where it uses AI, the AI organizes the diff instead of narrating it: it groups files by complexity, labels each group in one line, and drops short steering hints so you review the important code first, with an optional walkthrough that orders the whole change. It does not add a wall of generated comments you then have to triage, which is the opposite of what a bot does. The bet, spelled out in this piece on the review bottleneck, is that AI should reduce what you read, not add to it.

Honest caveats: Pyor is young, it is a review surface rather than a workflow platform, and it is not a same-category swap for a bot. If what you want is AI comments on the PR, keep Copilot review or move to CodeRabbit or Greptile. If the bot output itself is the problem, Pyor is the different answer. Free for individuals; paid per-seat for org features.

A practical note on cost, since it is the main reason Copilot review wins or loses a comparison. The included-with-Copilot framing only holds for licensed seats; the moment non-licensed users trigger reviews, that usage bills to the org as GitHub AI Credits, and the admin-enable step means the feature can be quietly off when you assume it is on. For a small team where everyone holds a seat, none of that matters and Copilot review is the obvious default. For a larger org with occasional reviewers, model the credits before you commit, because a dedicated bot with a flat per-seat price can end up both cheaper and easier to reason about. Match the billing shape to how your team actually reviews, not to which logo is already in your settings.

At a glance

Tool	Approach	Best for	Pricing
Copilot code review	AI first pass native in the PR	Teams already paying for Copilot	Included in Copilot (from $10/mo)
CodeRabbit	AI comments across four platforms	Deeper, configurable first pass	Free trial; free for open source
Greptile	AI reviewer with whole-codebase context	Multi-file logical bugs	$30/seat/mo, 50 credits; $1 per extra
Pyor (ours)	Review surface, AI triages not comments	When bot output is the problem	Free for individuals; per-seat orgs

Choosing among GitHub Copilot code review alternatives

• Already paying for Copilot and it works? Stay; nothing is cheaper to enable.
• Want more depth and platforms? CodeRabbit is the mainstream step up.
• Missing multi-file bugs? Greptile’s whole-codebase context targets that.
• Tired of triaging bot comments? Pyor triages the diff instead of adding to it.

They all sync to GitHub, so try one on a single real PR before committing the team. For the bot side in more detail see CodeRabbit alternatives, and for the platform angle see Graphite alternatives.

Frequently asked questions

What is the best GitHub Copilot code review alternative?

It depends on the gap you feel. If Copilot review is too shallow, dedicated bots like CodeRabbit and Greptile go deeper, with Greptile adding whole-codebase context. If the problem is that a bot adds comments you still have to triage, Pyor takes a non-bot approach and triages the diff itself instead of posting review comments.

Is GitHub Copilot code review good enough?

For many teams, yes, especially if you already pay for Copilot, since the review is included from Pro upward. It is a solid mechanical first pass native to the PR. You look for alternatives when you want deeper multi-file analysis, broader platform coverage, or when the admin-enable and AI Credits billing add friction you would rather avoid.

Why is Copilot code review not free?

It is included in paid Copilot plans (Pro, Pro+, Business, Enterprise) but not the free tier, and it is disabled by default. An admin must enable it and turn on GitHub AI Credits billing. Review usage by non-licensed users bills to the org as AI Credits, so cost can grow with how widely you use it.

The short answer: The division of labor the evidence supports: AI belongs upstream of human review: helping the author ship a cleaner PR, and running as a quiet, high-precision pre-filter. Humans own the downstream (judgment, intent, accountability), and what they need there isn’t more generated text to read; it’s a surface that makes reading the actual code fast. Put AI where mistakes are cheap (before the PR), keep humans where mistakes are expensive (the approval).

Upstream: where AI earns its keep

• At authoring time: the agent that wrote the code drafting its own tests, the author using a model to interrogate their diff before anyone else sees it. This is self-review with a power tool, and every defect caught here costs nobody’s attention but the author’s.
• As a pre-filter in CI: after the deterministic layer (linters, types) has taken everything decidable, a tuned-quiet AI pass on the risky paths. The Cotera numbers cut both ways: most suggestions duplicated a linter, but nine real catches in thirty PRs, before any human looked, is real money, provided the seven wrong ones didn’t cost the bot its credibility.
• As the author’s explainer, not the reviewer’s: generating the “why” and the review map for the description, where the author can verify it before publishing. Generated context the author vouches for is context; generated context pushed straight at the reviewer is homework.

Downstream: what we refuse to automate

The approval is a human act (“I understand this well enough to co-own it”), and the research has been clear for a decade that review’s deepest value is shared understanding, not defect yield. That value is produced by the reading itself. An AI summary that replaces the reading doesn’t speed the review up; it hollows it out. And when the summary is wrong (the category’s signature failure), it hollows it out convincingly.

Why Pyor ships no AI summaries

So when people ask where the AI features are in Pyor, this is the answer: the product is the downstream half of the division. File triage that puts the three files that matter first; commit-scoped diffs so re-review costs only the delta; threads that survive force-pushes; focus mode; one window from read to merge. No generated prose between you and the diff, because our read of the evidence is that the prose is a tax, and because everything upstream can be done by tools that already exist, including the model you already pay for. We’d rather be the best place the human part happens than the fifth bot leaving comments.

The test for any AI review feature

One question sorts the catalog: does this need to be verified by the person it’s shown to? If yes, it spends reviewer attention and must out-earn its verification cost, a bar most generated commentary misses today. If no (because the author verified it upstream, or because it’s deterministic), it’s a free win. That test is vendor-neutral, model-agnostic, and it will still be the right question when the models are better than they are this year.

Frequently asked questions

Will AI eventually do the whole review?

It will keep absorbing the mechanical share. But an approval is a human taking ownership of a change on behalf of a team. That’s an accountability act, not a defect scan, and delegating it entirely means nobody on the team understands the system they ship. We’d bet on the mechanical share shrinking toward zero while the judgment share becomes the whole job.

Isn’t refusing AI summaries just contrarian positioning?

It’s a falsifiable bet: that reviewers are net-faster reading well-presented code than reading AI prose about the code plus the code (since the prose must be verified against the code anyway, when it matters). If models become reliable enough that their summaries don’t need verification, the bet loses and we’ll revisit. The evidence today (false positives as the category’s #1 complaint) says it holds.

The map: Graphite bundles three things: stacked pull requests, an AI reviewer, and a merge queue. The stacking is its moat. If you want stacking elsewhere, GitHub’s native stacked PRs are in private preview. If you want the AI review alone, CodeRabbit, Greptile, or Copilot fit. If you want a faster review surface without a platform, Pyor is the different approach.

What Graphite is genuinely good at

Graphite now calls itself the AI code review platform, but its durable idea is stacked pull requests: you break a large change into a sequence of small, dependent PRs, and Graphite makes the bookkeeping bearable with a CLI and a VS Code extension, a stack-aware merge queue, a PR inbox, a modernized PR page, and Slack, CI, automations, and insights around it. On top of that sits an AI reviewer and Graphite Chat, a conversational reviewer. The case for it is the research on pull request size: small changes review better, full stop. It offers 30 days free, no credit card, synced with GitHub. If your team can adopt stacking, it attacks the root cause that most other tools only manage the symptoms of.

The honest caveat is the same thing that makes it powerful: stacking is a team-wide workflow change with a real learning curve, and you are adopting a platform, not a viewer. That is exactly why people look for alternatives, so let us split them by intent.

If you want the stacking workflow: watch GitHub native

The most interesting alternative to Graphite’s core feature now comes from GitHub itself: native stacked pull requests entered private preview in 2026, with GitHub acknowledging that large pull requests are hard to review. That matters because the biggest friction with third-party stacking is that it lives outside the host; a native implementation removes that seam. The honest status: it is private preview, not generally available, and Graphite is far more mature today, with the merge queue and inbox that a bare stacking primitive does not include. If stacking is why you are on Graphite, it is worth keeping while you watch the native feature graduate. Background on the pattern is in reviewing large pull requests.

If you mainly want the AI review: dedicated bots

If Graphite Chat and its reviewer are what you actually use, a dedicated bot is a lighter adoption than a platform. CodeRabbit posts AI review comments across GitHub, GitLab, Azure, and Bitbucket, with summaries, 40-plus linters and scanners, IDE and CLI reviews, and a free program for open source. Greptile builds a graph index of your codebase and runs a swarm of agents in parallel for whole-codebase context, priced at 30 dollars per seat a month including 50 review credits. GitHub Copilot code review does the first pass natively if you already pay for Copilot, though an admin must enable it and it bills through AI Credits. All three are the same job Graphite’s reviewer does, without moving your workflow onto a new platform. The category caveat holds: a bot is a first pass, not a reviewer, as we cover in do code reviews find bugs.

If you want a better surface without a platform: Pyor

There is a third intent Graphite does not directly serve: you do not want to change your team’s workflow or add a bot, you just want reviewing itself to be faster. That is what Pyor is for. It is a review surface for existing GitHub pull requests, web first with a macOS and Windows desktop app: read, comment, approve, and merge in one window, with a file rail built for triage, folder-level viewed tracking, focus mode, and threads that survive a force-push. Where it uses AI, the AI organizes rather than narrates: it groups files by complexity, labels each group in one line, and points you at what deserves attention first, with an optional walkthrough. It does not generate summary prose you must read and re-verify.

Honest caveats: Pyor does not replace Graphite’s moat. There is no merge queue, and its own stacked-PR support is in private preview, not shipped. If stacking is the reason you adopted Graphite, Pyor is not a swap for that. It is the answer when the reading is the bottleneck and a whole platform is more than you want. Free for individuals; paid per-seat for org features.

One nuance worth calling out: these alternatives are not mutually exclusive with Graphite, or with each other. A team can keep Graphite for stacking and still point a lighter surface at the occasional large, atomic change that stacking cannot shrink, migrations and codemods being the usual examples. The research favouring small diffs does not make every big diff avoidable; some changes are legitimately one unit, and you still have to read them. That is the seam where a triage-first surface earns its place next to a stacking platform rather than replacing it, and it is why we describe Pyor as a different approach rather than a head-to-head Graphite competitor. The point of the map is to match the tool to the bottleneck you actually have, not to crown one winner.

At a glance

Tool	Approach	Best for	Pricing
Graphite	Stacked PRs, merge queue, AI reviewer	Teams adopting a stacking workflow	30 days free, then paid
GitHub native stacking	Stacked PRs inside the host	Stacking without a third party	Private preview
CodeRabbit	AI review comments across platforms	A multi-platform first pass	Free trial; free for open source
Greptile	AI reviewer with whole-codebase context	Multi-file logical bugs	$30/seat/mo, 50 credits
Pyor (ours)	Review surface, AI triages not narrates	Faster reading without a platform	Free for individuals; per-seat orgs

How to choose among Graphite alternatives

• Stacking is why you are here? Keep Graphite; watch GitHub’s native preview mature.
• Only using the AI reviewer? Swap to CodeRabbit, Greptile, or Copilot and drop the platform.
• Reading is the real pain? Pyor upgrades the surface without changing your workflow.
• Want both stacking and a bot? Graphite still bundles them best today.

Because they all sync to GitHub, the cheapest test is one reviewer on one real PR. For a broader view, our CodeRabbit alternatives piece covers the AI-bot side, and the GitHub PR review alternatives roundup maps the whole field.

Frequently asked questions

What is the best Graphite alternative?

It depends on why you use Graphite. For the stacking workflow, GitHub native stacked PRs are in private preview and worth watching, though Graphite is more mature today. For the AI reviewer alone, CodeRabbit, Greptile, or Copilot code review fit. For a faster review surface without adopting a platform, Pyor takes a different approach.

Is Graphite worth it for the AI review alone?

Usually not by itself. Graphite ships an AI reviewer and Graphite Chat, but its real value is the stacked-PR workflow and merge queue. If you only want AI comments, a dedicated bot like CodeRabbit or Greptile is a lighter adoption than moving your team onto a whole platform for the reviewer feature.

Can I get stacked PRs without Graphite?

Partly. GitHub added native stacked pull requests in private preview in 2026, and the git tooling to stack branches has always existed; Graphite mainly removes the bookkeeping pain. If you want stacking as an ergonomic daily workflow today, Graphite is still the most complete option, with the native feature maturing behind it.

The short answer: Three data points frame the squeeze: roughly three-quarters of developers use or plan to use AI tools (Stack Overflow, 2024); research on OSS review workloads shows a small fraction of contributors carries most review work; and CodeRabbit’s analysis reports AI-assisted PRs showing about 1.7× more issues than human-written ones. Cheap generation, concentrated review, lower average quality: pick any two and you have friction; all three is burnout.

Why “just review faster” fails hardest here

A company can hire reviewers or set policy; a volunteer maintainer can only spend evenings. The generated PR’s signature failure (locally plausible, globally wrong, as we cataloged in our AI-code checklist) is maximally expensive in exactly this setting, because rejecting it convincingly requires the project-specific context only the maintainer holds. A contributor spent four minutes; the explanation of why it’s wrong takes forty. Multiply by a queue that refills itself and the rational outcomes are the bad ones: rubber-stamping, ghosting, or quitting.

What projects are actually doing

• Disclosure requirements: state what was AI-assisted, so reviewers know which failure modes to prioritize.
• Proof-of-understanding gates: describe what you changed and why, show it ran; PRs whose authors can’t answer follow-up questions get closed without guilt.
• Tightened contribution funnels: issues-first workflows, maintainer-approval before large PRs, temporary limits on new contributors when the queue floods.
• AI pre-filtering: ironically, AI review bots make more sense here than anywhere: a first pass that rejects the obviously broken protects volunteer attention, provided it’s tuned quiet enough to stay credible.

The norm that matters most

Every durable fix above reduces to one principle: the author absorbs the review cost they used to externalize. Read your own diff before submitting (the self-review pass), write the why, declare the provenance, keep it small. That norm was good manners in 2020; in the agent era it’s the difference between a commons that scales and one that eats its volunteers. Maintainers, for their part, deserve tooling that makes the irreducible human read as cheap as possible, which is the problem we work on at Pyor, free for individual use, maintainers included.

Frequently asked questions

Should open source projects ban AI-generated contributions?

Outright bans are hard to enforce and discard genuine value. The policies gaining traction instead: mandatory disclosure of AI assistance, proof the contributor ran and understood the change, stricter templates, and the right to summarily close PRs that show no human judgment. The target is unreviewed-by-author code, not AI per se.

Does this affect companies too, or just open source?

The same asymmetry (generation is cheap, review is scarce and concentrated) exists inside companies. Open source just shows it first and louder, because maintainers are volunteers with no manager to absorb the pressure and contributors face zero cost to submit.

The map: CodeRabbit is a mature, multi-platform AI reviewer. Its closest alternatives are Greptile (whole-codebase context), GitHub Copilot code review (cheapest if you already pay for Copilot), and Graphite (a reviewer bundled with stacked PRs). Pyor is the different bet: a review surface whose AI triages the diff instead of commenting on it.

What CodeRabbit is actually good at

CodeRabbit calls itself the leader in AI code reviews, and the breadth backs the swagger. It runs across GitHub, GitLab, Azure DevOps, and Bitbucket, reviews inside the IDE (VS Code, Cursor, Windsurf) and from a CLI as well as on the PR, and layers in bug detection, architectural-impact notes, one-click “Fix with AI”, change summaries with walkthroughs and diagrams, and 40-plus linters and security scanners behind a YAML config. It pulls Jira and Linear context, adapts to your feedback through what it calls learnings, and generates unit tests and docstrings. It is SOC 2 Type II with zero data retention after review, free to try with no credit card, and free for qualified open source. If you want one mature bot to cover many platforms, that is a strong reason to just keep it.

The reason people still shop around is the reason that applies to the whole category: a bot is a first pass, not a reviewer. It does not know your intent, it can share blind spots with whatever generated the code, and every comment it posts is volume a human still triages. We wrote about that tension in reviewing AI-generated code and about the noise cost in review alert fatigue.

Greptile: the same bot, with whole-codebase context

Greptile is the most direct like-for-like swap. It bills itself as the AI code reviewer and its differentiator is context: it builds a graph index of your codebase and runs a swarm of agents in parallel so a review can reason across files, not just the diff in front of it. That makes it better at multi-file logical bugs, the kind a single-file bot misses, alongside the usual style, security, syntax, and logic checks, on GitHub and GitLab. Pricing is a real consideration and unusually transparent: 30 dollars per seat per month including 50 credits (one credit is one review), then 1 dollar per extra review, with a free tier for qualified open source and discounts for pre-Series-A startups. If CodeRabbit feels too shallow on large, interconnected changes, Greptile is the upgrade to try.

GitHub Copilot code review: cheapest if you already pay for Copilot

GitHub Copilot code review does the AI first pass natively inside the PR. The pitch is purely economic: if your team already pays for Copilot, the review feature is included in Copilot Pro (10 dollars a month), Pro+ (39 dollars a month), Business (19 dollars per user a month), and Enterprise (39 dollars per user a month). It is not in the free tier. Two frictions are worth knowing before you count on it: an admin has to enable it (it is off by default) and turn on GitHub AI Credits billing, and review usage by non-licensed users bills to the org as AI Credits. If everyone already has a seat, it is the lowest-effort bot on this list. If they do not, the credits math can surprise you.

Graphite: reach for it if you also want stacking

Graphite calls itself the AI code review platform, and it does ship an AI reviewer plus Graphite Chat, a conversational reviewer. But adopting Graphite only for the bot undersells it and oversells the switch. Its real moat is stacked pull requests (a CLI and VS Code extension) with a stack-aware merge queue, a PR inbox, and Slack and CI automations around it. The durable idea is that small changes review better, which the research on pull request size supports. If you want an AI reviewer and a workflow that keeps diffs small, Graphite is the bundle. If you only want the bot, Greptile or Copilot is a lighter lift. It offers 30 days free, no credit card, synced with GitHub.

Pyor: a different approach, a review surface that triages

Here is where we stop being another bot. Pyor is not an AI reviewer that comments on your PR; it is a review surface for existing GitHub pull requests, web first with a desktop app for macOS and Windows. You read, comment, approve, and merge in one window. Where it uses AI, the AI organizes the diff rather than narrating it: it groups files by complexity, labels each group in one line, and drops short steering hints so on a big change you review the right code first, with an optional walkthrough that orders the whole thing. It deliberately does not generate prose summaries you have to read and then re-check against the code. That is the core disagreement with the bot category, which adds comments you then have to triage: as we cover in alert fatigue in code review, noisy AI review taxes attention rather than saving it.

Honest caveats: Pyor is young, it is a review surface and not a workflow platform (no merge queue; GitHub stacked PRs are in private preview, not here), and it is not a same-category swap for an AI reviewer. If what you want is a bot posting comments, one of the three above fits better. If your real pain is reading, this is the different answer. Free for individuals; paid per-seat for org features.

At a glance

Tool	Approach	Best for	Pricing
CodeRabbit	AI review comments across four platforms	A mature multi-platform first pass	Free trial; free for open source
Greptile	AI reviewer with whole-codebase graph context	Multi-file logical bugs	$30/seat/mo, 50 credits; $1 per extra
Copilot code review	AI first pass native in the PR	Teams already paying for Copilot	Included in Copilot (from $10/mo)
Graphite	AI reviewer bundled with stacked PRs	You also want a stacking workflow	30 days free, then paid
Pyor (ours)	Review surface, AI triages not comments	Reading big diffs is the bottleneck	Free for individuals; per-seat orgs

How to choose among CodeRabbit alternatives

• Want a mature bot across many platforms? Stay on CodeRabbit; the breadth is the feature.
• Bot missing multi-file bugs? Greptile’s whole-codebase context is the upgrade.
• Already paying for Copilot? Copilot code review is the cheapest first pass, minus the admin-enable and credits friction.
• Also fighting big diffs at the workflow level? Graphite’s stacking is the structural fix.
• Allergic to walls of AI text? Pyor triages the diff and points; you read the code.

They all sync back to GitHub, so the cheapest experiment is one reviewer trying one tool on one real PR this week. For the wider field beyond the bots, see our GitHub PR review alternatives roundup.

Frequently asked questions

What is the best CodeRabbit alternative?

There is no single winner because the job splits. If you want the same AI-reviewer-bot pattern, Greptile and GitHub Copilot code review are the closest. If you also want stacked PRs, Graphite bundles a reviewer. If your real bottleneck is reading big diffs, Pyor takes a different approach and triages the diff rather than commenting on it.

Is CodeRabbit still worth it?

Often yes. CodeRabbit supports GitHub, GitLab, Azure, and Bitbucket, ships IDE and CLI reviews, and runs a free program for open source. If you want a mature multi-platform bot as a mechanical first pass, it is a strong default. You look for alternatives when you want deeper context, lower cost, or less generated text to read.

Do these alternatives replace human review?

No. Every tool here sits on top of your existing pull requests and syncs back to the host. AI bots are a first pass that catches obvious issues before a human looks; a review surface makes the human read faster. Neither removes the reviewer. You still have to read the code, so the goal is to read the right code sooner.

The short answer: Noise doesn’t just dilute review; it retrains the reviewer. Each dismissed false positive lowers the attention paid to the next comment, until the bot’s genuine catches get the same reflexive skim as its nonsense. A reviewer, human or machine, is only as useful as its credibility, and credibility is a budget that bad comments spend.

The mechanism, not the moral

When a bot leaves nine comments on a PR and two matter, the author must spend their own judgment to find the two, which is precisely the work the bot was bought to reduce. Worse, the triage is repetitive: the same speculative concerns recur on every PR (“consider handling the case where this config is undefined”; it can’t be), so developers build the only rational defense: a mental filter labeled probably nothing. The team that built one popular reviewer documented this exact arc: they had to engineer nitpicking out of their own bot because noisy comments were burying the signal ones. We saw the same dynamic with human nitpicks; machines just produce them at scale.

Tuning for trust

• Deterministic first. Anything a linter or type checker can decide should never reach the AI layer: it’s free precision, and it shrinks the surface the bot can be wrong about.
• Narrow the bot’s beat. Security-sensitive paths, error handling, concurrency: places where a speculative flag is worth reading. Silence elsewhere is a feature.
• Demand confidence, suppress hedging. Most tools accept custom instructions; “only comment when you can name the failing input” filters out the twenty-speculative-reasons genre.
• Measure dismissal rate per bot, visibly. What gets measured gets tuned; a bot nobody audits drifts noisy.
• One reviewer’s voice, not three. Stacking multiple AI reviewers multiplies noise faster than coverage: their false positives don’t overlap; their true positives mostly do.

Protect the scarce resource

The thing alert fatigue actually destroys is the thing review runs on: reviewer attention. Every unit spent dismissing speculation is a unit not spent on the core files of the change. That’s the lens we’d apply to any addition to the review loop, our own product included: does it add attention (by making reading faster, by triaging what matters first) or does it tax attention and call the tax a feature? Tools that can’t answer that cleanly end up in the mental spam folder, no matter what their benchmark said.

Frequently asked questions

What dismissal rate means a review bot is too noisy?

There’s no published standard, but the ops world’s alerting experience suggests the bar is high: once a clear majority of a bot’s comments get dismissed without action, developers stop reading them carefully, at which point even its valid findings underperform. Track resolved-vs-dismissed per bot comment and treat a sustained slide as an incident in your review process.

Should we just turn the AI reviewer off?

Not necessarily: narrow it. Most tools accept path filters, severity thresholds, and custom instructions. A bot that only speaks on security-relevant paths and hard-error patterns, and stays silent elsewhere, keeps its credibility. The kill criterion is simple: if after tuning the team still skims past it, it’s costing more attention than it saves.

The short answer: The most honest independent data point we’ve found: Cotera’s evaluation of GitHub Copilot review across 30 real PRs: 47 inline suggestions, of which 31 would have been caught by their existing ESLint config with the right rules enabled, 9 were genuinely useful catches linting couldn’t make, and 7 were wrong or irrelevant. Read that as the category in miniature: mostly a linter with prose, a meaningful minority of real value, and a nonzero stream of confident noise.

What they’re genuinely good at

The 9-in-47 is real value, and it clusters: forgotten error paths, mismatches between a comment and the code below it, obvious-but-easy-to-skim bugs in tedious code, missed null cases in languages without strict checking. AI reviewers read every line with identical attention, the one thing humans reliably don’t do. As a mechanical first pass that runs before any human looks, that’s legitimately useful, which is the role we recommended in our tools comparison.

Where the noise comes from

• Linter overlap: the bulk of suggestions duplicate what deterministic tools already encode, except slower, non-deterministically, and phrased as a paragraph you have to read.
• Speculative findings: the most-echoed complaint in the bubble thread. Paraphrasing one commenter, it’s hard to stop the tool giving you twenty speculative concerns wrapped around the one real error.
• Missing context: the tool doesn’t know your schema invariants, your deliberate design exceptions, or the incident that explains the weird retry logic, so it flags exactly those things, repeatedly.
• Run-to-run variance: the same diff reviewed twice yields different comments, which corrodes trust in subtle ways a static analyzer never does.

The benchmark problem

Every vendor publishes accuracy numbers; the numbers disagree wildly; and each benchmark’s winner tends to be its publisher. This isn’t (necessarily) bad faith: catch rate trades against false-positive rate, so any tool can look like the leader by choosing where on that curve to measure. The only benchmark that predicts your experience is your own repo: take a dozen merged PRs whose bugs you later found in production, run the candidate tool on them, and count three things: real catches, linter-duplicates, and confident nonsense. An afternoon of that beats every comparison page, including this one.

The economics test

Dedicated AI reviewers run roughly $24 to $40 per seat monthly. The honest comparison isn’t “versus nothing.” It’s versus a tightened ESLint config (free, deterministic, zero hallucinations) plus the same model called directly in CI with your own rules. And one step further out: the bottleneck these tools address sits next to a bigger one: the speed at which humans can read and judge a change. That one doesn’t improve by adding more comments to triage; it improves by making the reading faster, which is the bet we took instead. More on that division of labor in the final piece of this series.

Frequently asked questions

Are AI code review tools worth paying for?

It depends what you’re replacing. If your repo lacks serious linting and CI, an AI reviewer adds value fast, but so would the linting. If your mechanical checks are already strong, the marginal real catches are fewer, and the per-seat price (typically $24 to $40/month) buys mostly a second opinion that needs verification. Trial it on your own merged PRs with known bugs before believing any benchmark.

Why do AI review benchmarks disagree so much?

Most published benchmarks are run by vendors, on test sets they chose, with scoring they defined, and each tends to crown its publisher. Catch rate also trades directly against noise: tuning a tool to flag more catches more and annoys more. Treat any single accuracy number as marketing until it’s reproduced on your codebase.

The short answer: An atomic commit is one self-contained logical step with a message explaining why. A PR built from them can be reviewed commit by commit: “rename (mechanical)” skimmed in seconds, “extract helper (no behavior change)” verified quickly, “change retry semantics” read with full attention. The reviewer’s effort lands exactly where the risk is, instead of being spread evenly across a flattened 800-line wall.

Why structure beats size

We’ve argued smaller PRs review better, but some changes are legitimately medium-sized, and the next lever after size is order. A flattened diff mixes the mechanical with the meaningful: the rename touches 30 files, the real semantic change touches two, and the reviewer must discover which is which line by line. Commit structure is the author telling the reviewer, credibly: these 30 files are the rename; trust them as a unit; spend yourself on these two. It’s the same triage we recommend reviewers do on their side, except the author, who knows the answer, does it once for everyone.

The recipe

• Separate refactor from behavior. The cardinal rule. “No behavior change” commits get verified structurally; behavior commits get scrutiny. Mixed, they poison each other.
• Mechanical bulk gets its own commit (renames, formatting, codemods, generated files), labeled as such in the message.
• Messages carry the why. As one HN commenter put it, commit messages are the developer docs for a change. “Switch to exponential backoff because the flat retry hammered the API during outages” reviews itself.
• Curate before requesting review. Your fifty “argh, forgot this bit” commits are fine while working. git rebase -i them into the story before asking for eyes. (During review rounds, switch to append-only fixups; see the interdiff piece.)

The squash debate, defused

“Why bother if we squash-merge anyway?” Because the commits’ job is during review: they’re the author’s table of contents for the reviewer. What main’s history looks like afterward (one squashed commit, or the curated sequence) is a separate policy decision with its own trade-offs (bisectability and revert granularity vs. a linear, tidy log). Both camps can be right at their own moment in the timeline. The only losing position is chaotic commits and a flattened review.

Reviewing commit-by-commit in practice

The workflow needs tool support to stick: stepping through commits, and scoping the diff to a single commit or a span when you need to re-check one chapter. GitHub allows per-commit viewing but loses your thread positions between scopes; it’s one of the flows we built deliberately into Pyor (ours, free for individuals): pick any commit or range in a PR and the diff re-scopes to it, threads intact. Author structures the story; reviewer reads it chapter by chapter; nobody re-reads the book.

Frequently asked questions

Atomic commits or squash-and-merge: which is right?

They answer different questions. Atomic commits make the PR reviewable round by round and step by step; what lands on main afterward is a separate policy choice. Many teams do both: structured commits during review, squash (or a curated history) at merge. The mistake is letting a squash-at-merge policy become an excuse for chaotic commits during review.

What makes a commit “atomic”?

One logical change that stands alone: it has a single describable purpose, the code (ideally) builds at that point, and its message explains why. “Extract retry helper (no behavior change)” is atomic. “WIP” and “fix stuff + refactor + new endpoint” are not.

Is this worth it for small PRs?

For a 50-line single-purpose PR, one commit is atomic, and you’re done. The craft pays off from medium size upward, and especially when a refactor travels with a behavior change: separating those two into commits is the difference between a 10-minute review and a 40-minute one.

The short answer: Yes, reviews find real defects, but defect-finding is the minority of their delivered value. Microsoft’s large-scale study found review comments more often address code improvement, understandability, and knowledge transfer than outright bugs; Google’s published account of its review practice frames the primary goal as maintaining codebase health and shared understanding, with defects as one benefit among several. Judge review as a bug net and it disappoints; judge it as the team’s understanding-transfer mechanism and it’s load-bearing.

What the studies actually say

• Microsoft (Bacchelli & Bird): across thousands of reviews, the study found developers expect defect-finding to be the top outcome, but observed comments skew toward improvements, style, and understanding. The biggest obstacle to finding deep defects is reviewers not understanding the change.
• Google (Sadowski et al.): their case study describes review converging on small changes reviewed quickly by usually one reviewer, with education and codebase consistency as explicit goals: a system tuned for understanding-at-scale, not maximal defect yield per review.
• The older inspection data (the Cisco study popularized by SmartBear) shows review can catch a substantial share of defects, but only under the conditions teams routinely violate: small scope, limited pace, fresh attention.

Both camps are right about the failure mode

The skeptics aren’t hallucinating: a rushed glance at a 1,500-line diff finds nothing, and calling it quality assurance is theatre. The defenders aren’t either: a real read of a scoped change catches the wrong-assumption bug no test suite was written to catch: tests verify what someone thought to verify; a reviewer questions the thinking. The variable isn’t whether review “works.” It’s whether the conditions for real review (size, time, and a surface that doesn’t fight you) were present.

The agent-era update

Two things changed since that research. Volume: authoring accelerated and review didn’t, so the conditions for real review are violated more often by default. And provenance: when an agent wrote the change, review is no longer a second pair of human eyes. It’s often the first, which raises the stakes of doing it honestly. The defect-finding share of review’s value is probably rising again, because generated code fails in ways tests written by the same model miss.

So: worth it?

Worth it: for the bugs it does catch, the worse designs it quietly prevents (knowing a human will read your code changes what you write), and above all for keeping the team’s understanding of its own system alive. That last one has no substitute, no bot replacement, and no shortcut. The actionable conclusion isn’t “review more” or “review less.” It’s create the conditions where review is real: small changes, honest re-review rounds, nits automated away, and reviewer attention treated as the scarce resource it is.

Frequently asked questions

Should we drop review for low-risk changes?

Calibrating rigor to risk is reasonable: many teams fast-track docs, config, and mechanical changes. But “low-risk” is exactly where untested assumptions hide, and review’s knowledge-transfer value applies to boring changes too. Lighten the process before you remove it.

Are AI reviewers a replacement for human review?

They replace a slice of it: the mechanical defect hunt. They don’t replace the parts research says humans uniquely deliver: judging intent, transferring context across the team, and a human taking ownership of the change. Use bots to clear noise so humans can do that part.

The short answer: The re-reviewer’s question is never “is this change good?” It’s “what changed since I last looked?” That answer is an interdiff: version N vs. version N−1 of the same PR. GitHub approximates it with “changes since your last review,” but the approximation breaks on rebases and force-pushes. Protect it with workflow (fixup commits during review rounds) or recover it with git range-diff.

Why re-review is uniquely wasteful

The first review amortizes: you build the mental model once and spend it on the whole diff. The re-review should cost only the delta: the author changed forty lines in response to comments. But if you can’t isolate those forty lines reliably, you pay the full model-building cost again, on code you’ve already read. Multiply by two or three rounds per PR and the second-review tax exceeds the first review. This is also where rubber-stamping sneaks in: “probably just the fixes” is the path of least resistance when the tooling can’t show you the fixes.

Where GitHub’s answer falls short

GitHub does offer “changes since your last review”, and when authors append normal commits, it mostly works. The gaps: it anchors to commits, so a rebase or squash force-push orphans the comparison; outdated comment threads detach from their lines; and there’s no view of how the shape of the change evolved (did the author restructure, or patch?). The thread above is full of Gerrit refugees for a reason: patchset-to-patchset comparison was a first-class feature there.

The workflow fix: fixups now, squash later

• During review rounds: authors append (git commit --fixup per addressed comment), never rewrite. Reviewers get an honest per-round delta.
• Before merge: git rebase -i --autosquash folds the fixups away; clean history and reviewable rounds both survive.
• When a rebase mid-review is unavoidable (conflicts with main): git range-diff old-base..old-head new-base..new-head compares the two versions as patches, surviving the rewrite. It is the closest thing Git ships to a true interdiff. (docs)

The tooling fix: scope the diff to what’s new

The general capability underneath all of this is scoping the diff to a span of commits: “show me only what changed in the commits since my review.” It’s the feature we leaned into with Pyor (ours, free for individuals): pick any commit range in a PR and the diff re-scopes to exactly that span, with review threads kept anchored, including threads on lines that later changed, which get pinned to the version they were written against instead of vanishing as “outdated.” The re-review becomes what it always should have been: read the delta, check it against your comments, approve with confidence.

Close the loop explicitly

However you get the delta, end the round crisply: re-resolve the threads that were addressed, say what you re-checked, and approve mentioning the rounds (“round 2 reviewed: migration fix verified”). Re-review is the part of the process most likely to be invisible work; making it visible is how it stays funded.

Frequently asked questions

What is an interdiff?

A diff between two versions of the same change (version 1 of a PR vs. version 2 after review feedback) rather than between the change and its base branch. It answers the re-reviewer’s actual question: what did the author modify since I last looked?

Why does force-pushing break re-review on GitHub?

GitHub’s “changes since your last review” compares commits. When the author rebases or squashes and force-pushes, the old commits no longer exist, so the comparison loses its anchor, and the reviewer is often left re-reading the whole diff. git range-diff compares the two commit ranges as patches, which survives the rewrite.

Should authors avoid force-pushing during review?

During an active review round, yes: append fixup commits so reviewers can see deltas, then squash before merge. Clean history and reviewable rounds aren’t in conflict; they just happen at different moments.

The short answer: Nitpicks are a triple tax: they crowd out logic review (style is easier to comment on, so it wins), they demoralize authors (feedback reads as fault-finding), and they add merge latency (a round-trip per bikeshed). The fix is structural: automate what a formatter can decide, label what remains (nit: = non-blocking, author may decline), and budget human attention for correctness and design.

Why nits win by default

It’s an attention-economics problem, not a character flaw. Evaluating logic requires reconstructing the author’s mental model (expensive). Spotting a naming inconsistency requires a glance (free). Under time pressure, reviewers produce what’s producible, and on teams where “thorough review” is measured by comment count, nits become how diligence is performed. (That performance problem is its own disease; see our piece on review theatre.)

Automate the automatable, ruthlessly

Every style rule a human enforces in review is a tooling failure. Formatters (Prettier, gofmt, Black) end whitespace and layout debates; linters encode naming and idiom rules; CI enforces both before a reviewer ever looks. The rule of thumb: if two reasonable people could be told the answer by a config file, the config file should do the telling. What’s left for humans is the stuff that genuinely needs judgment.

Label what remains

For judgment-call nits, severity must travel with the comment. Conventional Comments does this with prefixes: nit: (take it or leave it), question: (I might be missing context), issue: (this blocks). The author triages at a glance instead of treating every comment as a demand. Two norms make it stick: a nit: can be declined without justification, and approval is given with nits outstanding (“approve, two optional nits”) rather than holding the merge hostage to preferences.

Watch the bot, too

AI reviewers inherit the nit bias: style observations are the easiest tokens to generate. The team behind one popular bot wrote up the fix: they had to deliberately engineer nitpicking out, because noisy comments trained developers to ignore the bot entirely, including its real catches. The same applies to humans: a reviewer known for nits gets skimmed.

What to do with the attention you save

The point of killing nits isn’t kinder reviews; it’s reallocated reviews. The attention that was going to naming goes to the questions that prevent incidents: is this correct at the edges, is this the right shape, what happens under failure. That’s the review your authors actually want, and the one worth structuring your passes around. Style should be table stakes settled by machines; judgment is the part worth a human’s signature.

Frequently asked questions

Are nitpicks ever worth leaving?

Yes, when they’re about clarity a future reader will pay for (a misleading name, a confusing structure), not personal preference. The discipline is labeling them non-blocking (nit:) and accepting the author may decline. If a “nit” must be fixed before merge, it isn’t a nit: say why it blocks.

What tone should review comments use?

Comment on the code, not the person; prefer questions over verdicts when intent is unclear (“was X considered here?”); give the reason, not just the instruction. Prefixes like nit:, question:, issue: (Conventional Comments) carry severity so the author doesn’t have to guess what blocks.

Our AI review bot is the biggest nitpicker. What now?

Tune or replace it. Teams that shipped AI reviewers found nitpicky output erodes trust in all the bot’s comments, including the good ones; one team wrote up how they specifically engineered their bot to stop nitpicking. A bot that comments rarely and correctly beats one that comments always.

The short answer: Read your own diff in the review UI, not your editor, before requesting review. You’ll catch the leftover debug line, the accidental file, the misleading name, each costing you a keystroke instead of costing a reviewer a round-trip. Then write down the why and the where to look. Ten minutes, and your reviewer starts at the interesting part instead of the embarrassing part.

Why the diff view and not your editor

You’ve been staring at this code for days in the editor, so you see what you meant. The diff view shows what you did, in the exact frame your reviewer will see: the stray console.log, the formatting blast radius, the file that shouldn’t be there, the seven-line function that reads fine in context and cryptic in isolation. The medium switch is the point: it breaks author blindness the same way reading your writing aloud does.

The five-minute pass

1. Sweep for accidents: debug output, commented-out blocks, unrelated formatting, files that don’t belong, secrets and config meant for local only.
2. Read as a stranger: for each hunk, would someone without your week of context understand why this line changed? If not, comment it, rename it, or annotate the PR at that line yourself.
3. Check the seams: error paths, edge inputs, the one place you said “I’ll come back to this.” You remember where the bodies are; the reviewer has to dig.
4. Write the map: what changed, why, where the risk is, what you’re unsure about. “Start with applyBatch, the rest is wiring” is the most valuable sentence in any large PR.
5. Pre-empt the split question: if the self-review took ages or the map has two unrelated stories, split it now, before a reviewer asks.

Self-review changes the economics, not just the defect count

Every issue the author catches converts a public round-trip (comment → notification → context switch → push → re-request) into a private keystroke. Authors who self-review consistently get reviewed faster; reviewers learn whose PRs respect their time, and an analysis of a popular r/ExperiencedDevs question about slow reviews reached the same conclusion: authors control more of their wait time than they think. The polish is also contagious in the good direction: a clean, mapped PR makes a lazy LGTM feel out of place.

In the agent era, self-review is the accountability line

When an AI wrote the change, “the author read it first” stops being hygiene and becomes the whole ballgame: it’s the moment a human takes ownership. That’s why we built pre-PR review into Pyor (our tool, free for individuals): read your agent’s diff on your own branch, leave yourself notes, fix before anything becomes a pull request. Your reviewers receive code a human has vouched for, and our AI-code checklist gets shorter every time someone does it.

Frequently asked questions

Isn’t self-review redundant if a reviewer will look anyway?

No. It changes what the reviewer spends attention on. Defects found by the author cost a keystroke; the same defect found by a reviewer costs a comment, a context switch, a re-push, and a re-review round-trip. Self-review moves the cheap defects to the cheap finder, leaving reviewer attention for design and correctness.

How long should a self-review take?

For a normal-sized PR, five to fifteen minutes. If self-reviewing takes an hour, that is the PR telling you it’s too large: split it before requesting review.

Does self-review work for AI-generated changes?

It’s even more important there. When an agent wrote the code, the author’s self-review is the first time any human has read it. Sending it to a reviewer unread outsources your accountability, and reviewers can tell.

The short answer: Review theatre has two costumes: the rubber stamp (approve without understanding, because pushing back feels pointless) and the obligation nitpick (comment on formatting to prove you looked). Both come from the same root: reviewing after the decision is already made, on changes too big or too opaque to truly evaluate. Fix the incentives and the surface, not the reviewers.

What LGTM should mean in code review

LGTM means “looks good to me,” but in code review it should mean more than “I saw the diff.” A useful LGTM says: I understand the change, I checked the risky paths, and I am comfortable sharing ownership after merge. When teams use LGTM as a social shortcut instead, approval turns into a rubber stamp: fast, polite, and almost empty.

Why rational people rubber-stamp

Nobody decides to stop reviewing. The drift has mechanics. By the time a PR is up, the author has invested days; the feature is on a board with a date; the change is, as one engineer put it in a long-running debate about post-commit review, already a done deal: the reviewer isn’t in the hot path of the decision anymore, so pushing back feels like obstruction rather than contribution. Add a diff too large to genuinely evaluate (we’ve written about why size kills review), and approval becomes the only move that doesn’t make you the bottleneck. The stamp is rational. That’s what makes it dangerous.

The obligation nitpick is the same failure

The reviewer who can’t evaluate the logic but must demonstrate diligence reaches for what’s evaluable at a glance: names, formatting, comment style. The author gets busywork, the actual risk sails through untouched, and everyone involved can point at the thread as proof review happened. As a commenter on the Theatre thread put it, logic-and-architecture comments are the valuable ones, but nit comments are easier to write, so they win by default. (We go deeper on this in an upcoming piece on nitpicks.)

What approval should mean

The fix starts with making the stakes explicit. An approval is a statement: “I understand this change well enough to co-own it in production.” Not “I looked at it,” not “I trust the author.” Teams that adopt that definition (out loud, in their review norms) make rubber-stamping feel like what it is: signing a document you didn’t read.

• Let reviewers say what they actually did. “Reviewed the migration deeply, skimmed the call sites” is honest and useful; silent approval hides the gap.
• Make small PRs the norm so genuine evaluation is possible in the time people actually have. Theatre thrives on impossibility.
• Move review earlier. Feedback before the change is “a done deal” (on the design, or via pre-PR review of generated code) puts the reviewer back in the hot path, where pushing back is cheap.
• Kill the diligence-signaling channel. Auto-format, lint in CI, and label nits as non-blocking. When style can’t be the performance, attention goes to logic.

The surface matters more than teams admit

Here’s the uncomfortable observation from building a review tool: a lot of rubber-stamping is fatigue with the act of reviewing, not indifference to quality. When finding the three files that matter takes ten minutes of scrolling, the stamp wins. When triage is instant and the diff keeps your place, genuinely reading the change stops being heroic. That’s the bet behind Pyor (ours, free for individuals): make real review cheap enough that theatre loses its main excuse.

Frequently asked questions

Is a fast LGTM always rubber-stamping?

No. A 40-line, well-described change from someone who knows the area deserves a fast approval; speed and rigor aren’t opposites on small changes. Rubber-stamping is approving without understanding. The tell is whether the reviewer could explain the change to a third person afterward.

How do we measure whether our reviews are performative?

Look at outcome-shaped signals rather than activity: how often review actually changes the code (revision rate), whether defects are caught before merge vs. after, and whether comments cluster on style versus logic. All-approvals-no-changes over weeks is the classic theatre signature.

The short answer: Pull the branch when you need to navigate (jump to definition, find usages), run the change, or judge a refactor’s shape; the editor’s context is unbeatable. Stay in the browser for small, self-contained diffs where inline comments and speed matter more. The deciding question: do I need to see more than the diff shows? If yes, pull.

What local review actually buys you

• Navigation. Go-to-definition, find-references, the call hierarchy: the diff shows what changed; the editor shows what the change touches. For judging a refactor or an API change, that difference is the review.
• Execution. Run the tests, poke the feature, profile the hot path. The web diff asks you to trust; the checkout lets you verify.
• Your tools. Your keybindings, your linters, your search. Reviewing in an environment tuned over years beats any vendor’s viewer for raw reading throughput.

What it costs

• Context switching. Stash or commit your work, switch branches (or maintain a second worktree), restore state afterward. gh pr checkout makes the fetch cheap; nothing makes the interruption cheap.
• The transcription tax. Findings live in your head and the PR conversation lives in the browser. Every comment means re-finding the file and line on github.com and reconstructing your thought. This is where local reviewers quietly lose their time advantage, and why their feedback sometimes arrives as one big comment instead of anchored threads.
• No shared state. Viewed-file tracking, resolved threads, suggested changes: the collaborative review machinery doesn’t follow you into the editor.

A decision rule that holds up

Pull the branch when the review question is architectural or behavioral: does this design hold, does this actually work, what does this break elsewhere. Stay in the diff when the question is local correctness: is this logic right, are the edges handled, is it consistent. Mixed PRs (most large ones) often deserve both: a browser pass for triage and threads, a checkout for the two files where the real decision lives.

The gap both modes leave

Notice the shape of the trade: one mode has the context (editor) and the other has the conversation (browser), and review needs both. That gap is the design brief we started Pyor from: a native review app with diff ergonomics built for reading (file triage, viewed tracking that includes whole folders, focus mode, a diff that keeps your place at any size) and the full review loop: inline threads, approvals, and merge, synced with GitHub. It talks to GitHub directly from your machine, so the privacy posture matches local review: your code never passes through our servers. Free for individuals. It won’t replace the checkout for “does this design hold” (nothing replaces running the code), but it retires the checkout you were doing just to read comfortably.

If you take one habit from this

Make the mode a deliberate choice per-PR instead of an identity. The reviewers who do this best aren’t “local people” or “browser people”; they ask what does this change need from me? and pick the cheapest surface that delivers it. The one identity worth keeping: never approve a change you couldn’t explain to the next reviewer, wherever you read it.

Frequently asked questions

How do I check out a PR branch quickly?

With GitHub’s CLI: gh pr checkout <number> fetches and switches to the PR branch in one step. Add --detach to avoid creating a local branch you’ll forget to delete.

Do I lose the ability to comment when reviewing locally?

On vanilla setups, mostly yes: findings have to be transcribed back to the PR by hand, which is the biggest hidden cost of local review. Editor extensions (like the GitHub PR extension for VS Code) close part of the gap; dedicated review apps close more of it.

The short answer: Review requests get lost because GitHub notifications mix them with every mention, CI result, and issue update across every repo. The fix is a dedicated funnel: a filtered view that shows only what waits on you, a team SLA for first response (Google’s guidance: one business day, maximum), and scheduled review blocks so the queue gets drained on purpose instead of by guilt.

Why the default funnel fails

The notification stream is unranked and unbounded: a review request, the one item where a teammate is blocked on you, gets the same row as a bot comment. Email filters help until they file the request neatly into a folder nobody opens. And the morning sweep (“mark all as read”) is where review requests go to die. The structural problem: requests for your attention live mixed with information that merely mentions you.

Build a PR query inbox in GitHub

GitHub’s own search can build a serviceable PR query inbox; most developers just never wire it up. Bookmark these queries:

• is:open is:pr review-requested:@me archived:false: everything explicitly waiting on your review, across all repos.
• is:open is:pr reviewed-by:@me -review-requested:@me: PRs you reviewed that may have replied to you (re-review limbo, the second-biggest leak).
• is:open is:pr author:@me review:changes_requested: your own PRs blocked on your response; authors leak too.

The discipline is checking the views on a schedule, which is the next fix.

An SLA plus review blocks beats heroics

Google’s review-speed guidance is blunt: respond within one business day at the slowest, because slow review taxes the whole team’s velocity and morale. The workable pattern isn’t interrupting deep work for every request; it’s two or three scheduled review blocks a day (start of day, post-lunch) plus the SLA as a backstop. Predictability is the actual product: an author who knows the longest possible wait can plan; one staring at silence pings, escalates, or gives up.

The first response doesn’t need to be the full review: “looked at the description, I’m the right reviewer, full pass by 3pm” unblocks more than it sounds like it should.

Drain the queue by unblock value, not arrival order

When the block starts, don’t review oldest-first. Triage by what unblocks the most: PRs with no reviewer yet beat PRs with two; a teammate’s release-blocker beats a refactor; a re-review (author already responded) usually costs minutes and clears a thread someone is anxiously refreshing. Five minutes of queue triage routinely saves a teammate’s afternoon.

Tooling: this is a solved-shape problem

Everything above is workflow, and it works with bookmarks and a calendar. The tooling version is having the funnel built in, which is how we approached it in Pyor (our product, free for individuals): a pull-request dashboard for everything that matters to you (authored, assigned, awaiting your review), a comments inbox that gathers every thread and reply across repos into one feed, and a team view that ranks open PRs by how much you can unblock, surfacing the ones with no reviewer first. The queue stops being something you remember to check and becomes something you look at once and act on. For what to do when the PR you open is enormous, see reviewing large PRs.

Frequently asked questions

What’s a reasonable SLA for first review response?

Google’s engineering practices set the bar at one business day as the absolute maximum, and treat faster as materially better. Many teams aim for a few working hours for the first response, even if it’s “looked, will review properly after lunch.” The SLA is for responsiveness, not completed review.

Should reviewers be interrupted by every review request?

No. Interrupting deep work for every request trades one team problem for another. The standard compromise is scheduled review blocks (start of day, after lunch) plus an SLA that makes the longest possible wait predictable. Authors can plan around predictable; they can’t plan around silence.

The short answer: AI made writing code dramatically cheaper while the cost of understanding code stayed flat. That asymmetry moves the bottleneck from authoring to review, and no amount of “review harder” fixes a structural imbalance. The fixes are structural too: smaller changes, review pushed upstream of the PR, and a review surface that wastes none of the reviewer’s attention.

Amplifiers amplify both directions

There’s a line making the rounds in engineering leadership circles: AI is an amplifier: teams with strong practices get stronger, teams with weak ones get worse. Review is where that cashes out. A team that already wrote small PRs with good descriptions now ships even faster, because review keeps up. A team that tolerated 1,500-line mixed-concern PRs now produces them twice as often, and the review queue, not the roadmap, sets their velocity.

The failure modes are predictable. Diffs grow, because generating is cheap and splitting is work, the trend that made us write how big should a PR be? Reviewers rubber-stamp, because honest review of the incoming volume is impossible and something has to give. Or reviewers hold the line and become the constraint, absorbing the team’s frustration for doing their job. Pick your dysfunction.

“Just review less” isn’t the answer: understanding is the product

It’s tempting to conclude review is now overpriced ceremony: let CI and the AI reviewer bots gate merges. But code review was never only defect-hunting. Microsoft’s research on review at scale found its biggest delivered values include knowledge transfer and shared understanding, not just bugs caught. In the agent era that function gets more important: when a model writes the code, review is the moment a human takes ownership of it. Skip that, and you ship a system nobody on the team understands, a debt with compounding interest.

The three places to attack the asymmetry

• Shrink the unit of review. Size caps, stacked PRs, splitting norms: everything in the data says this is the highest-leverage move. Small changes are the one thing that makes every other fix cheaper.
• Move review upstream. The author (or their agent’s supervisor) reads the diff before it becomes a PR (pre-PR review), and an AI first pass clears mechanical noise. Human reviewers should see changes a human has already vouched for, with a checklist like our AI-code review checklist applied.
• Stop taxing the reviewer. If review is the scarce resource, every lost scroll position, collapsed file, and buried thread is waste of the exact thing you’re short on. This is the lever we work on at Pyor: making the irreducible human part (reading and understanding a diff) as fast as the surface allows, especially for the large PRs that keep coming.

The uncomfortable conclusion

Most teams’ effective shipping speed is now set by review throughput, not authoring speed, whether they’ve noticed or not. The teams that internalize that will redesign around it: smaller units, upstream review, surfaces that respect reviewer attention. The rest will keep buying faster code generation and wondering why the cycle time didn’t move. The bottleneck doesn’t care how fast you fill the queue.

Frequently asked questions

Won’t AI reviewers eventually close the gap themselves?

They’ll keep absorbing the mechanical share of review: bugs, style, obvious edge cases. But review is also the team’s understanding-transfer mechanism: a human vouching that the change is what the team intended. Outsourcing that entirely means nobody on the team understands the system, which is a different and worse bottleneck.

What’s the single highest-leverage fix?

PR size. Every line of evidence, from the Cisco review study to Google’s engineering practices, says small changes get reviewed faster and better. Most other fixes (self-review, AI first passes, better tooling) work best after size is under control.

The map: Four ways to escape the github.com review experience: prevent big diffs (Graphite’s stacked PRs), add AI guidance to the diff (Stage’s chapters, CodeRabbit’s bot reviews), upgrade the surface and let AI triage it (Pyor), or pull the branch and review locally (free, powerful, high friction). They’re mostly complementary, not exclusive.

Why teams look beyond github.com for review

GitHub is where the PRs live, but its review surface shows its priorities: it’s a code host first. Large diffs paginate and collapse, your place evaporates between visits, review requests drown in notification noise, and there’s no triage: every file gets equal billing whether it’s the core change or a lockfile. None of this is fatal for a 50-line PR. All of it compounds for the 2,000-line ones that keep arriving in the agent era.

Graphite: don’t have big PRs in the first place

Graphite is the workflow cure: stacked pull requests. Break a large change into a sequence of small, dependent PRs; their tooling (CLI, VS Code extension, stack-aware merge queue) makes the bookkeeping bearable, and an AI reviewer plus a PR inbox round out the platform. The case for it is the research: small changes review better, full stop. The honest caveats: stacking is a team-wide workflow change with a real learning curve, the cure doesn’t apply to changes that are legitimately atomic (migrations, codemods), and you’re adopting a platform, not a viewer. If your team has the discipline budget, it’s the structurally right answer. Free trial, then per-seat pricing.

Stage: let AI narrate the diff

Stage (YC-backed, launched 2026) takes the opposite bet: the diff stays big, but AI organizes it into logical chapters with guidance (what changed, what to double-check), plus an assistant that answers “what’s risky here?” with line citations. Everything syncs back to GitHub. If your reviewers’ bottleneck is orientation (staring at an unfamiliar change with no map), the chaptering is genuinely clever. Our honest reservation (and it’s now a difference of degree, since we ship AI triage too): Stage leans on generated prose you read and trust, chapters plus an assistant, and when the narration and the code disagree you still have to read the code. We keep our AI pointing at the code (groups, one-line labels, hints) rather than narrating it, so there’s less generated text standing between you and the diff. Reviewers who want a fully narrated guide may prefer Stage, and that’s fair. 14-day trial, then paid.

CodeRabbit and the AI-reviewer bots: a first pass, not a reviewer

Tools like CodeRabbit (and GitHub’s own Copilot review) post AI-generated review comments directly on the PR. As a mechanical first pass (obvious bugs, style drift, missed edge cases) they’re cheap and useful, and they run before a human ever looks. The limits are the ones we covered in reviewing AI-generated code: the bot doesn’t know your intent, shares blind spots with whatever generated the code, and adds comment volume that someone still has to triage. Adopt one to clear noise; don’t let “the bot approved” become culture.

Pyor: a fast surface, plus AI that organizes the diff

Our entry, so the claims stay modest and checkable: Pyor is a native review surface for existing GitHub PRs (read, comment, approve, and merge in one window, without opening github.com), web first with a desktop app for macOS and Windows. The thesis is that the raw act of reviewing is the bottleneck, so the surface gets the engineering: a file rail built for triage, folder-level viewed tracking, inline threads that stay put, focus mode, and a diff that stays navigable at any size.

Where Pyor uses AI, it organizes rather than narrates. It groups the files by complexity, labels each group in one line, and drops short hints that point you at the parts worth your attention first, so on a big PR you review the right code first (there’s a walkthrough mode that orders the whole thing for you). What it deliberately does not do is generate walls of summary you have to read and then re-check against the code. The AI points at the diff; it never stands in front of it. Free for individuals; paid per-seat for org features. The honest caveats: it’s young, and it’s a viewer, not a workflow platform (no stacking, no merge queue).

The free option: pull the branch

git fetch && git checkout remains a legitimate answer: full editor navigation, run the tests, zero dollars. The cost is friction: stash your work, lose inline commenting, transcribe findings back to GitHub by hand. It’s the power move for the gnarliest changes and overkill for the rest. We compare it properly in a future piece on local vs. browser review.

At a glance

Tool	Approach	Best when	Pricing
Graphite	Stacked PRs + merge queue + AI reviewer	The team can adopt a stacking workflow	Free trial, then per-seat
Stage	AI chapters + guidance over the diff	Reviewers need orientation in unfamiliar changes	14-day trial, then paid
CodeRabbit (and bots)	AI comments posted on the PR	Mechanical first pass before human eyes	Per-seat
Pyor	Native surface + AI that triages, not narrates	The reading itself is the bottleneck	Free for individuals; per-seat orgs
Pull locally	Full editor + run the code	One gnarly architectural change	Free

How to actually choose

• Team can adopt a new workflow? Graphite’s stacking attacks the root cause.
• Reviewers feel lost in unfamiliar changes? Stage’s chapters give them a map.
• Want mechanical issues caught before humans look? Add an AI reviewer bot.
• Drowning in big diffs but allergic to walls of AI text? That’s Pyor: the AI triages and points, you read the code.
• One brutal change, once? Pull it locally.

And since they all sync to GitHub, the cheapest experiment is one reviewer trying one tool on one real PR this week, no team buy-in required.

Frequently asked questions

Do these tools replace GitHub?

No. Every tool in this comparison sits on top of GitHub pull requests: comments, approvals, and merges sync back to GitHub. You can adopt any of them (or stop using them) without changing where your code lives.

Which alternative is best for large pull requests?

It depends on where you want to spend effort. Graphite prevents large PRs by making small stacked ones ergonomic. Stage and CodeRabbit add AI explanation on top of the diff. Pyor uses AI to triage the diff (group files by complexity, one-line group labels, steering hints) on a fast navigable surface, without generating prose you must read. Teams that can adopt stacking should; reviewers who still face big diffs need a better surface for them.

Can I try these without asking my whole team?

Mostly yes. Graphite, Stage, and Pyor all work for an individual reviewer on existing GitHub PRs without requiring teammates to change workflow. AI reviewer bots like CodeRabbit are repo-level: they post comments everyone sees, so that one is a team decision.

The checklist:

1. Intent match: does it solve the actual ticket, or a plausible nearby problem?
2. Hallucination scan: do all APIs, options, and imports actually exist?
3. Edge honesty: error paths, empty states, concurrency. Generated code loves the happy path.
4. Test the tests: do they assert requirements, or just mirror the implementation?
5. Codebase fit: does it duplicate an existing helper or invent a new pattern?
6. Security surface: injected strings, permissive defaults, secrets handling.
7. Provenance: did a human read this before requesting review?

1. Intent match comes first

The signature failure of generated code is being a correct answer to a slightly different question. It compiles, it’s idiomatic, the tests pass, and yet it implements a subtly different behavior than the issue asked for, because the prompt (or the model’s reading of the codebase) drifted. Before reading any implementation, re-read the requirement, then check the change’s observable behavior against it. Everything else on this list is cheaper to check than this, which is exactly why it gets skipped.

2. Verify that everything it calls exists

Models still invent: a config option that was never real, a method from a different library’s API, an import that resolves only in the model’s memory of an older version. Types and CI catch most of it. The dangerous remainder is the call that exists but does something different than the generated comment claims. If a usage looks unfamiliar, check the docs, not the comment above it.

3. Audit the edges, not the middle

Generated code is strongest on the happy path, because that’s where the training data lives. Spend your attention where it’s weakest: error handling that swallows instead of propagating, empty and null inputs, timeouts, partial failures, and any shared state. A quick heuristic: find every catch and every default value, and ask whether a human with context would have chosen it.

4. Test the tests

When the same model writes the code and its tests, the tests often assert what the code does, not what it should do: a tautology with good coverage numbers. Read the assertions against the requirement. The tell: tests with exact-value assertions copied from implementation output, and no test for the case the ticket was actually about.

5. Check codebase fit

Generators reach for the median solution from everywhere, not your conventions. Watch for re-implemented helpers that already exist, a third state-management pattern, or styles that fight the file around them. Industry analyses such as GitClear’s code-quality reports have flagged rising duplication and churn alongside AI adoption. Review is where that trend gets stopped, one duplicate helper at a time.

6. Sweep the security surface

Generated code inherits the average security posture of its training data, which is not a compliment. String-built SQL or shell commands, permissive CORS, broad IAM defaults, tokens logged “temporarily”. None of these are exotic; all of them show up in generated diffs regularly. If the change touches input handling, auth, or anything that executes, slow down there.

7. Ask whether a human read it first

The cheapest quality gate for generated code is upstream of review: the author reading their own diff before requesting eyes. Teams adopting agents are formalizing this as pre-PR review: reading the agent’s work on your own branch before it becomes a pull request. It’s a workflow we believe in enough to have built into Pyor (our product, free for individuals): review the agent’s diff locally, leave notes, land a cleaner PR. Your reviewers get changes a human has already vouched for, and this checklist gets shorter every time.

For the size dimension of the same problem (agents make big diffs cheap), see how big should a pull request be?

Frequently asked questions

Should AI-generated code be labeled in pull requests?

It helps. Knowing a change was largely generated tells the reviewer which failure modes to prioritize: plausible-but-wrong logic, invented APIs, tests that assert the implementation rather than the requirement. Many teams add a simple description field for it.

Can I use an AI to review AI-generated code?

As a first pass, yes. AI reviewers are decent at mechanical issues and obvious bugs, and they’re cheap. But they share blind spots with the generator and don’t know your intent. Use them to clear noise before human review, not to replace it.

Is AI-generated code lower quality than human code?

It’s differently distributed. Generated code is often locally clean and idiomatic while being wrong about intent or context. Industry analyses (e.g. GitClear’s year-over-year reports) have flagged rising code churn and duplication alongside AI adoption, signals worth watching in your own repo rather than taking on faith.

The short answer: Aim for under ~400 changed lines of code per pull request, and treat smaller as better. SmartBear’s study of peer review at Cisco found defect-detection ability drops beyond roughly 400 lines, and Google’s engineering practices push for small changes as the default. Count only lines a human must understand, lockfiles and generated code aside.

Where the ~400-line figure comes from

The most-cited data point in this debate comes from a large study of peer review at Cisco, popularized by SmartBear: reviewers’ ability to find defects degrades as the change grows, with ~400 lines as the practical ceiling and ~200 as the comfortable middle. It’s old data, gathered on human-written code, but nothing about human working memory has improved since, and it matches what reviewers feel: past a few hundred lines, you stop reviewing and start skimming.

Google’s public review guidance arrives at the same place from experience rather than measurement: small changelists get reviewed faster and more thoroughly, are less likely to import bugs, and are easier to roll back. Their reviewer docs treat “can this be split?” as a standard first question.

Why size matters more than ever

AI assistants lowered the cost of producing lines dramatically. In a controlled GitHub experiment, developers with Copilot finished a task 55% faster than the control group. Nothing comparable happened to the cost of understanding lines. When authoring accelerates and review doesn’t, PR size is the valve where the pressure shows up. Holding the size line is how a team keeps review quality while adopting AI tooling.

When it’s fine to break the rule

• Mechanical bulk: renames, formatting, codemods, lockfiles, generated artifacts. Reviewers verify legitimacy, not logic, so flag these in the description.
• Migrations and schema changes that lose meaning when fragmented.
• Coherence beats arithmetic: a 600-line change with one clear idea reviews better than five 120-line fragments nobody can evaluate alone.

The test isn’t the line count; it’s whether a reviewer can hold the idea of the change in their head. Size is a proxy: a good one, but a proxy.

How to split a PR that grew

• Refactor first, behavior second. The classic two-PR split: a no-behavior-change refactor that makes the feature diff small, then the feature.
• Slice vertically. One thin end-to-end path first (schema → API → UI for one case), then the variations.
• Land the leaves. Utilities, types, and tests that stand alone can merge ahead of the trunk change that uses them.

And when the big PR ships anyway

It will; agents are prolific and deadlines are real. For the review side of that problem, we wrote a separate field guide: how to review large pull requests. And if the bottleneck is the review surface itself, that’s the problem Pyor exists to fix: triage-first file rail, folder-level viewed tracking, and a diff that keeps your place at any size. (Our product; free for individuals.)

Frequently asked questions

Is there an official maximum PR size?

No standard body defines one. The most-cited guidance comes from SmartBear’s study of peer review at Cisco (keep reviews under ~400 lines) and Google’s engineering practices (small changes, reviewed quickly). Treat 400 changed lines as a soft ceiling, not a law.

Do generated files and lockfiles count toward PR size?

Practically, no. Reviewers scan them for legitimacy rather than reading them. What matters is the number of lines a human must actually understand. A 2,000-line PR that is 1,800 lines of lockfile is a small PR wearing a big coat.

My AI assistant produces large changes. Should I force-split everything?

Split when there is a real seam (refactor vs. behavior change, layer by layer). Don’t manufacture artificial fragments that can’t be understood alone; a coherent 600-line change can beat five incoherent 120-line ones. When a large PR is unavoidable, review it with triage and passes instead.

The method in brief:

1. Read the description and commits first. Never start at file one.
2. Triage: sort files into core logic, supporting changes, and mechanical noise.
3. Review the core deeply, in passes (correctness → design → style).
4. Mark files as viewed as you go; protect your place.
5. Timebox sessions (~1 hour) and split the review across them.
6. Say what you reviewed deeply and what you skimmed.

Step 1: Don’t start at file one

The diff is ordered alphabetically; your understanding shouldn’t be. Read the PR description, then the commit list; commits often reveal the change’s real structure (“refactor first, then feature”) even when the description doesn’t. If the description is missing the why, ask for it before you read a single hunk. That’s not pedantry; it’s the cheapest possible round-trip, and it improves every minute you spend afterward.

Step 2: Triage the files and find the three that matter

In almost every large PR, a minority of files carry the actual decision-making. Sort the file list into three buckets before reading anything closely:

• Core: new logic, changed behavior, anything touching state, money, auth, or concurrency. This is where your attention goes.
• Supporting: call-site updates, types, wiring. Scan for surprises, not for line-by-line correctness.
• Mechanical: lockfiles, generated code, renames, formatting. Verify they are what they claim (a “rename-only” file with a logic edit hiding inside is a classic), then move on.

Tests deserve a special mention: read them early, not last. Good tests are the best description of intended behavior you’ll get; missing tests for the risky path tell you exactly where to look hardest.

Step 3: Review in passes, not in one sweep

Trying to judge correctness, design, and style simultaneously is how reviewers burn out and miss things. Make separate passes over the core bucket:

1. Correctness: does it do what it says? Edge cases, error paths, off-by-ones, assumptions that don’t survive concurrency.
2. Design: is this the right shape? Will the next person extend it or fight it?
3. Style and nits: last, quickly, and labeled as non-blocking. The Conventional Comments convention (nit:, question:, issue:) keeps these from reading like blockers.

Step 4: Protect your place

Large-diff review fails as much from lost state as from lost attention. Mark files as viewed the moment you finish them. If your tool can mark whole folders viewed, use it to clear the mechanical bucket in one stroke. If you get interrupted (you will), the viewed markers are what makes resuming cost seconds instead of minutes.

Step 5: Timebox, then come back

SmartBear’s peer-review research puts the practical limits at roughly 60-minute sessions and no more than ~500 lines per hour. Past that, defect detection falls off. For a genuinely big PR that means the review is designed to span sessions. Plan it that way instead of discovering it at minute ninety.

Step 6: Report honestly

End with a review summary that says what you actually did: “Read auth flow and migration deeply; scanned call-site updates; trusted generated files.” It calibrates the author’s confidence, tells co-reviewers where to spend their attention, and keeps “approved” meaning something.

Where tooling earns its keep

Everything above works in any tool, and is less painful in a surface built for it. This is the use case we designed Pyor around: a file rail you can triage and group, folder-level viewed marking, inline threads that stay put, and a focus mode that collapses everything but the code. Full disclosure: we make it, and it’s free for individuals. If your method survives a 2,000-line PR but your tab doesn’t, that’s the gap it fills. For why PRs got this hard in the first place, see our earlier piece on the review bottleneck.

Frequently asked questions

Should I just ask the author to split a large PR?

Often yes: splitting is the best outcome when the PR mixes concerns. But ask early (before reviewing in depth), be specific about the seam, and accept that some changes (migrations, generated code, mechanical renames) are legitimately large and better reviewed with triage than split artificially.

How long should a review session be?

SmartBear’s peer-review research recommends sessions of about 60 minutes and not reviewing faster than ~500 lines per hour. For a genuinely large PR, plan multiple short sessions rather than one heroic one; defect detection drops sharply as fatigue sets in.

Is it okay to approve a large PR without reading every line?

Be honest about what you reviewed. Triage means most attention goes to high-risk files, while mechanical changes get a lighter scan, and that is legitimate. Approving code nobody read is not. Say in your review what you covered deeply and what you skimmed.

It wasn’t always. For most of software’s history the economics ran the other way: writing code was the slow, expensive part (hours or days of design, typing, and debugging per change), and reviewing that change was the comparatively quick read at the end. AI inverted the ratio. Code is now cheap to produce in volume, and on many teams reviewing a change takes longer than writing it did. The bottleneck moved from authoring to review, while our habits and tools are still built for the old ratio.

The short answer: Pull requests are hard to review for four compounding reasons: reading code is cognitively harder than writing it, diffs are too large to hold in your head, the “why” is missing from most PRs, and the review surface itself (a browser tab built for hosting code, not understanding change) fights you on all three.

Reading code is harder than writing it

When you write code, you build the mental model first and the code falls out of it. When you review code, you’re handed the output and asked to reconstruct the model in reverse. Microsoft Research’s study of code review at scale, Expectations, Outcomes, and Challenges of Modern Code Review, found exactly this: the number-one challenge reviewers report isn’t finding defects; it’s understanding the change in the first place.

That asymmetry is the root of everything else. A reviewer doing the job properly is doing archaeology: why this file, why this approach, what else does this touch? Every missing piece of context turns into either a round-trip question or a shrug-and-approve.

Diffs outgrew our working memory

Review effectiveness falls off a cliff with size. SmartBear’s analysis of peer review (drawn from a large study at Cisco) recommends keeping reviews under roughly 400 lines of code. Beyond that, the ability to find defects drops measurably. Google’s engineering practices push the same direction: small changes get reviewed faster, more thoroughly, and with less back-and-forth.

Meanwhile real-world PRs are heading the other way. AI assistants make it cheap to generate four hundred lines before lunch, and refactors ride along with features because splitting feels like overhead. The result: a forty-file diff where three files carry the actual change, and the reviewer has to find them by scrolling.

The “why” never made it into the PR

Most PR descriptions describe the what (“Add retry logic to sync”), not the why (“Sync fails on flaky hotel wi-fi; we retry 3× with backoff; the risky part is the idempotency assumption in applyBatch”). Without the why, a reviewer either reconstructs it from the diff (slow) or reviews superficially. Neither is the reviewer’s fault: nothing in the default workflow demands that context exist.

The review surface fights you

Here’s the part we think gets too little blame: the place where review happens. The standard web diff was designed for hosting and browsing code, and it shows. Files collapse and lose your place. There’s no triage: file one and file forty get equal billing. Comments vanish into resolved threads. Forty open tabs later, the review “session” is really an exercise in remembering where you were.

None of these is fatal alone. Together they tax exactly the thing review depends on: sustained attention on an unfamiliar change.

What actually helps

• Smaller PRs, enforced socially or by tooling. The single highest-leverage change, per both Google and the Cisco data above.
• Authors review first. A self-review pass catches the cheap stuff before it costs a reviewer’s attention, and writing the “why” down halves the archaeology.
• A review surface built for understanding. Triage the files that matter, keep your place, see every thread in context, and run the whole read-comment-approve-merge loop without losing state between tabs.

That last one is the bet we’re making with Pyor: a review app where the diff, the conversation, and the merge live in one window, and your code never leaves your machine. We built it because we were the reviewer dreading the tab. (Yes, that’s a product plug. It’s also the reason this blog exists, so we’d rather say it plainly.)

Frequently asked questions

Why do pull requests sit unreviewed for days?

Mostly because reviewing feels expensive: large diffs, missing context, and notification noise push reviewers to defer. Reducing PR size and giving reviewers a faster surface for understanding the change shortens the queue more than reminders do.

Is AI-generated code making review harder?

It shifts the bottleneck. AI assistants speed up authoring, so more code arrives per reviewer-hour, and diffs trend larger. The review side (human understanding) has not sped up to match.