Graphite Alternative for AI Code Review on GitHub

Graphite bundles stacked pull requests, a stack-aware merge queue and Graphite Agent, which is its AI reviewer and chat. If stacking is what you want to keep, GitHub's own stacked pull requests are the closest replacement; they have been in public preview since July 2026. Warpway is not a replacement for stacking, because it does not create stacks or run a merge queue. If the part you want to change is AI review, a review orchestrator works differently from a reviewer that leaves comments, and this guide compares the two approaches on GitHub.

Which part of Graphite are you replacing?

As of October 2026, Graphite's pricing page lists four plans. Paid plans are priced per user per month, billed annually:

Unlimited AI review and the merge queue come on the same tier, so looking for a "Graphite alternative" can mean one of three things:

1. You want stacks without a separate platform. See GitHub's stacked pull requests below.
2. You want Graphite's stacking with a different review model. Graphite's setup docs have you choose which repositories get AI reviews, so stacking and the reviewer are separate decisions.
3. You only want AI review. If you never used stacks, you are comparing reviewers. The useful question is what each reviewer does after it finds a problem, and what it does when it can't decide.

How Graphite Agent reviews a pull request

Graphite announced Graphite Agent on October 7, 2025. It combines Graphite's Diamond AI reviewer with Graphite Chat. The announcement describes "instant feedback, suggestions, and fixes applied directly in your diff," and chat for follow-up questions and for applying changes.

Graphite's AI review docs describe how it works:

• Scope. You turn on AI reviews for chosen repositories or for the whole organization, and the agent reviews every new pull request in them. The overview says it analyzes your entire codebase.
• Output. It posts inline comments on the relevant lines. Each comment gives the problem, why it matters and a suggested fix you can commit. Comments fall into five categories: logic bugs, edge cases, security vulnerabilities, performance issues, and accidentally committed code such as debug statements.
• Feedback. The docs say the agent focuses on real bugs rather than style, learns from how your team responds to its comments, and reports acceptance and downvote rates.
• Customization. Rules are either prompts written in the Graphite UI or file-based rules that point at repository documents by glob. Comment exclusions tell the agent where not to comment. Organization admins can choose which pull requests get reviewed, filtering by author, paths, labels, title or description, and parent branch.
• Status. The pull request page shows Running, Completed or Not running. A pull request over 200,000 characters, for example, shows Not running.

Assigning people is a separate feature. Graphite automations match pull requests by inbox filters and filename globs. A match can add reviewers or GitHub teams, add labels, post a comment or notify someone in Slack.

These pages describe the agent's output as comments and suggested fixes that sit alongside human review. They do not describe it submitting approvals or reporting a status check that branch protection could require. Graphite handles merging through its merge queue. Its docs say enforcing the queue needs branch protection rules and Graphite's GitHub App, and that it is not compatible with GitHub's own merge queue.

If you need stacked PRs, start with GitHub

GitHub's July 30, 2026 changelog put stacked pull requests into public preview, rolling out to all repositories:

• Each pull request in a stack targets the layer below it, and reviewers see only that layer's diff.
• Merging the top ready pull request also merges every unmerged layer below it, in one operation.
• If you merge a lower layer instead, the layers above it rebase and retarget automatically.
• Your existing branch protections and required checks still decide what reaches main.
• Merge queue support for stacks was still rolling out when the changelog was published.

gh extension install github/gh-stack

Warpway has no stacking features. It treats each layer as an ordinary pull request. Four documented behaviors matter for stacks:

• Policy comes from the base branch. Warpway reads .warpway.yml from the pull request's base branch at the base commit, so a pull request cannot weaken its own review. For an upper layer, the base branch is the layer below it.
• review.base_branches filters by target branch. If you set it to main only, Warpway skips layers that target other branches. Left unset, it covers every branch.
• Retargeting starts a new review. A base-branch change withdraws the previous verdict and starts a new review. New commits from a rebase also start one. Earlier human answers are reused when the code they depended on did not change.
• Merge queues. Warpway does not report on merge-queue groups, so its docs say not to require Warpway / Review in a ruleset that also gates a merge queue.

What a review orchestrator does differently

A commenting reviewer reports what it found. An orchestrator also tracks what is still unresolved, who should resolve it, and whether your policy is met. Warpway does this for GitHub pull requests through the five mechanisms below.

Lenses that end in a state

Warpway investigates each pull request through lenses:

• Required on every pull request: Correctness, Security and Testing.
• Required when a change touches what they cover: Backward Compatibility, Product Semantics and Database Safety.
• Advisory, warning but not blocking: Architecture and Performance.

Every lens ends in one of four states: Cleared, Issue found, Human decision required or Incomplete. A lens is Incomplete when a tool or model fails, or when permissions or required evidence are missing. An Incomplete lens never turns into Cleared on its own.

Warpway's case studies are replays: merged open-source pull requests run through Warpway on 2026-10-07, as they stood before merge. In the requests SSLContext replay, Warpway flags the client-certificate mix-up that was later reported upstream as #6726.

Specific questions instead of "please take a look"

When a lens cannot settle something, Warpway creates a human task. A task is one question that comes with:

• why it matters,
• what Warpway looked for,
• the evidence and the relevant lines,
• what each answer will conclude.

For example: "Must revoking an administrator role invalidate active sessions immediately?", with the choices Immediate revocation, Up to 15 minutes is acceptable, or Needs discussion. Replies go through a sufficiency check, so "Sounds fine" gets one follow-up question instead of resolving the task. Concrete findings appear as line annotations; open questions do not.

Routing for each question

Graphite automations add people to a pull request that matches a rule. Warpway's routing works at the level of each open question. From trust level 1 (Assist) up, it assigns each question to the person or team most likely to know, using ranked sources, including:

• the owner named on the rule that raised the question,
• the lens owner,
• CODEOWNERS and configured contacts,
• review and commit history,
• topic expertise.

Each routing decision records why that person was chosen. Engineering questions go to GitHub. On the Team plan, product or policy questions can go to a Slack direct message, which never contains code. If the person answers "I'm not the right person", the task moves to the next candidate.

A check your branch rules can require

Warpway reports results as one check, Warpway / Review, tied to the head commit. From trust level Gate upward, code (not a model) evaluates your policy from the stored results, and the check concludes success only when the policy is met:

• When only open questions remain, the check reports action_required.
• Blocking findings, Incomplete lenses or failing required CI checks report failure.

Merge gating shows how to make the check required.

Approval only when every condition passes

At the top trust level, auto-approval can submit an APPROVE review. It never approves just because a model reported high confidence. Auto-approval is off by default and needs the Team plan plus an Owner's explicit enablement. Before approving, it checks every condition, including:

• the head commit is the commit it reviewed,
• every required lens is Cleared,
• no required task is open,
• configured CI checks passed,
• no excluded path changed.

Warpway approves; it never merges.

On the Team plan, policy lives in .warpway.yml on the base branch:

version: 1
required_lenses:
  - correctness
  - security
  - testing
rules:
  - id: tenant-isolation
    lens: security
    applies_to:
      paths:
        - src/api/**
    instructions: >
      Every access path to tenant-owned records must establish
      tenant ownership before returning or mutating data.
routing:
  product_semantics:
    slack_user_group: "@product-leads"
    prefer_slack: true
  default:
    github_team: "@acme/maintainers"
merge_gate:
  block_on_severities:
    - critical
    - high
auto_approve:
  enabled: true
  docs_tests_only: true
  max_changed_lines: 300
  required_ci_checks:
    - unit-tests

The auto_approve block alone never turns approval on. The Owner switches in the dashboard and trust level 4 are also required.

Graphite Agent and Warpway side by side

Warpway's Free plan reviews public repositories without a fixed cap and gives private repositories 20 reviews per calendar month (UTC); each private pull request counts once per month, however many commits or reruns it gets. It caps the trust level at Assist, so a finished review's check concludes neutral, which GitHub treats as passing. Once the organization's 20 private reviews for the month are used, the check on further private pull requests reports Usage limit reached (action_required) instead. Merge gating, Slack routing, .warpway.yml and auto-approval all need the Team plan (billing).

Trying an orchestrator without changing what can merge

1. Install the GitHub App on a few selected repositories (getting started).
2. Start at Observe or Assist. Both levels make the check conclude neutral, which GitHub treats as passing, so nothing new blocks merges.
3. On the same pull requests, compare what Warpway clears, flags and asks with what your current review produces.
4. Once its results match your team's judgment, raise a repository to Gate and require Warpway / Review.
5. Turn on auto-approval only for narrow kinds of change, such as pull requests that touch only documentation and tests, or small Dependabot updates.

If your team relies on stacks, keep stacking in Graphite or GitHub and evaluate the review layer on its own. Warpway works with GitHub only.