cubic Alternative for Gating AI-Generated Pull Requests

cubic is an AI reviewer for GitHub pull requests. It comments on changes, generates fixes, checks linked Jira, Linear or Asana tickets against their acceptance criteria, and can auto-approve changes its policy treats as low-risk. You need an alternative when the gap is enforcement rather than review: a required check that fails closed, open questions sent to named people, and authority you raise in stages. If the gap is platform support (GitLab, Bitbucket, Azure DevOps), you need a different list, because cubic and Warpway both work only with GitHub.

What cubic does, according to its own docs

Everything in this section comes from cubic's site and documentation as of November 2026.

Review with codebase-wide context

The cubic homepage says every PR "is checked against your whole codebase and your team's rules," and that cubic flags changes that could break code elsewhere, including in other repositories. The key features page says cross-repo reviews check repositories you link, for shared APIs, schemas, docs or release work. It also lists:

• bug and security detection, posted as PR comments;
• incremental reviews that comment only on newly found issues;
• Ultrareview, a deeper review you request;
• PR summaries;
• an AI wiki that indexes the repository;
• custom agents written in plain language.

It also learns from feedback: when you react to a suggestion or correct it, "the AI remembers."

Background agents

cubic's background agents do two jobs. On a pull request, clicking "Fix with cubic" or tagging @cubic generates and applies a fix.

Separately, codebase scans (in beta, available on request) run agents across the whole repository on a schedule, biweekly by default. They look for business logic flaws, data integrity risks, hardcoded secrets, dependency CVEs and infrastructure-as-code misconfigurations. cubic assigns each finding to an owner from CODEOWNERS, or from git history when CODEOWNERS has no match, and can notify owners by email or Slack DM. It can file Jira, Linear or GitHub tickets and open one fix PR per finding. Pro and Max include scans for up to three repositories in a rolling 90-day window.

Acceptance-criteria checks

The issue tracker integration works with Linear, Jira, Asana and GitHub Issues:

1. It finds issue keys such as ABC-123 in the PR title or branch name.
2. It reads requirements from the issue: bullet lists, "Acceptance Criteria" sections and items starting with "Should", "Must" or "Can".
3. It compares the changed files against those requirements.
4. It posts a table showing which requirements are done and which are missing.

If the ticket has no description or requirements, the analysis doesn't run. The Jira page recommends writing criteria that are specific, testable and formatted as lists.

Auto-approval

Auto-approval is off by default and has three behaviors:

• Disabled.
• Shadow: reports what it would have approved, without approving.
• Live: submits real GitHub approvals.

When a review is clean and no rule blocks approval, cubic applies your chosen policy:

• Low-risk only (cubic's recommended default for most repositories): an approval agent decides, using cubic's built-in low-risk prompt;
• Custom: an approval agent decides, using your own prompt;
• Always: any clean review is approved.

Deterministic gates sit around the policy:

• open cubic issues block approval unless you allow chosen priorities;
• file globs and PR attributes can exclude PRs or allowlist them;
• on public repositories, PRs from external contributors are reviewed but not auto-approved by default;
• if cubic can't verify a PR's metadata, it doesn't approve.

GitHub branch protection still applies.

Limits and price

• Platform: GitHub only.
• Large PRs: when a PR has more than 200 eligible files, cubic reviews the 200 highest-priority ones. Automatic review has a 50,000 changed-line ceiling.
• Configuration: cubic.yaml is read only from the default branch.
• Price: the pricing page lists Team at $40, Pro at $99 and Max at $200 per developer per month on monthly billing. Each plan includes an allowance of reviewed lines, for example 40,000 per developer on Team.

What changes when review has to gate the merge

In the docs above, cubic's output on a PR is comments, a requirements table, an optional 1–5 merge confidence score (off by default) and, if you turn it on, an approval. Neither the review settings nor the cubic.yaml reference describes a status check that branch protection can require. If you need one, ask cubic directly. Three requirements usually push a team past comment-based review.

A required check that fails closed

An approval and a required check are different levers. If your branch requires one approval, any person's approval satisfies it, whether or not the AI agreed. A required status check has to pass no matter who approves. A check is also only as strong as what it reports when the reviewer itself fails, for example on a model timeout, a missing permission or a PR too large to read.

Warpway reports one check, Warpway / Review, bound to the exact head commit. At trust level 2 (Gate) and above:

• The check concludes success only when deterministic code finds your review policy satisfied. A model never decides that the policy passed.
• It concludes failure for open blocking findings, lenses that couldn't finish, failing required CI, invalid configuration or system errors.
• It concludes action_required when only human questions remain.
• When a model call fails or required context can't be loaded, the affected lens reports Incomplete and the check doesn't report success.
• A PR larger than review.max_changed_files (300 by default) is reported as not covered instead of being passed.

To enforce the check, add it to a GitHub ruleset and select the Warpway app as its source; merge gating walks through the setup. Policy is read from .warpway.yml on the base branch at the base commit, so a PR that removes security from required_lenses is still reviewed with Security required.

version: 1
required_lenses:
  - correctness
  - security
  - testing
routing:
  product_semantics:
    slack_user_group: "@product-leads"
    prefer_slack: true
  default:
    github_team: "@acme/maintainers"
merge_gate:
  block_on_severities:
    - critical
    - high
  required_ci_checks:
    - unit-tests
  fail_on_incomplete: true

Questions that go to a named person

AI-written PRs often stall on a fact nobody wrote down rather than on a bug. For example: should revoking an admin role end active sessions immediately? cubic's acceptance-criteria check helps when the ticket states the requirement. When the ticket says nothing, there is nothing for it to compare against.

Warpway's Product Semantics lens asks the product owner instead of guessing when the intended behavior isn't written anywhere Warpway can read. Every unresolved question becomes a human task with seven parts: the question, why it matters, why AI couldn't resolve it, the evidence so far, the relevant lines, the expected kind of answer, and what each answer will lead Warpway to conclude.

Routing picks the recipient in this order:

1. the rule's named owner, then the lens's owner;
2. CODEOWNERS;
3. configured Slack and GitHub contacts;
4. people who reviewed or recently changed the code;
5. the linked issue's assignee or author;
6. topic expertise;
7. a reviewer already on the PR;
8. the organization's fallback owner.

An Admin's routing correction ranks above all of these, and for non-engineering questions, such as intended product behavior, CODEOWNERS and code history rank below configured contacts, the linked issue and topic expertise. Each routing decision comes with a "why you" explanation. On the Team plan with Slack connected, non-engineers whose Slack identity is linked get the question in a Slack direct message, in plain language, without diffs and without needing a Warpway account.

Warpway checks each answer before counting it. A reply like "Sounds fine" gets one follow-up question instead of being recorded as a yes. "I'm not the right person" reroutes the task to the next candidate. By default, an unanswered task gets a reminder after 24 hours and moves to the next candidate after 72 hours. Admins can change both times. A required task that is still open keeps blocking the check.

cubic's codebase scans also assign owners, but to background findings; in Warpway, the question is a decision a specific pull request is waiting on.

Trust you raise in stages

cubic stages auto-approval: you can run it in Shadow before switching to Live. Warpway stages the whole review through trust levels:

The effective level is the lowest of the dashboard setting, any trust_level in configuration and your plan's cap, so configuration can lower a repository's level but never raise it. An Admin can raise a repository to Gate. Clear and Auto-approve need an Owner.

cubic's Low-risk only and Custom policies use an approval agent that applies a policy prompt, with deterministic gates around it. Warpway computes eligibility in code from stored results immediately before approving. Every required lens must be Cleared, no required task can be open, configured CI must conclude success, the commit must match exactly, and excluded paths and categories must be untouched. Warpway never approves because a model reported high confidence. Auto-approval lists all the conditions.

cubic and Warpway side by side

What Warpway does not do

• GitHub only. No GitLab, Bitbucket or Azure DevOps.
• No code changes. Its GitHub permissions are read-only for contents, so it can't push commits, create branches or open fix PRs. If one-click fixes matter to you, that's a cubic feature Warpway doesn't have.
• No scheduled codebase scans. It reviews pull requests only.
• No Jira, Linear or Asana integration is described in its docs. Lenses read the GitHub issues a PR links to.
• No merge-queue reporting. It doesn't report on merge-queue groups, so don't require its check in a ruleset that also gates a merge queue.
• Gating needs the Team plan. On Free, trust is capped at Assist and the check never blocks.
• It is new. There are no public customers or usage numbers to point to.

How to evaluate an alternative on your own PRs

1. Decide what you're replacing. If you like cubic's comments and fixes, you may only need a gate next to it. The guide to blocking merges on AI review findings covers the GitHub side.
2. Replay PRs you know were wrong. Pick three to five merged PRs that later caused a regression, and run each tool on them as they stood before merge. Warpway's case studies are replays of this kind. For example, in a replay run on 2026-10-07 of the requests 2.32 SSLContext change as it stood before merge, Warpway flags the client-certificate mix-up later reported as #6726.
3. Break it on purpose. Push an invalid config file, remove a permission or open a PR above the file limit, then check what each tool's output says. A gate should block, not go quiet.
4. Ask a question the code can't answer. Open a billing change with an empty ticket and see who, if anyone, is asked.
5. Start in non-blocking mode. Run cubic in Shadow, or Warpway at Observe or Assist, for a week or two before anything blocks or approves. If approvals are your end goal, this comparison of tools that approve PRs covers the trade-offs.