Skip to content
Warpway

Review orchestration for GitHub pull requests

Humans should review uncertainty, not code.

AI investigates every PR, clears what it can, and routes the decisions it cannot make to the right person.

Install on GitHubRead the docs

New repositories start in Assist: Warpway routes questions but never blocks a merge. Gating and auto-approval are opt-in.

In the example review

lines changed
1,056
lines shown to a person
23
decision asked
1
An example Warpway review of pull request 481 in four steps: before, after, the Slack answer, and the outcome.
ExamplePR #481Add role management to the admin console

  1. Before

    Review PR #481 — +837 / -219

    One reviewer is asked to read every changed line.

  2. After

    • Correctness: Cleared
    • Security: Waiting on a human
    • Testing: Cleared
    • Backward compatibility: Cleared
    • Database safety: Cleared

    1 human decision required

    Should role revocation invalidate active sessions immediately?

    23 relevant linesRouted to Security.

  3. Slack

    Security SME:Yes, revoke immediately.

  4. Outcome

    Security re-evaluated: implementation does not meet requirement.

    Finding: revoked roles stay valid for up to 15 minutes because the permission cache is not invalidated.

    Warpway / ReviewReview policy not satisfied: 1 finding.

Illustrative example. Your lenses, people and policy decide the real flow.

Slack consultation

Ask the person who knows, even if they don’t write code.

Some questions are business decisions. Warpway sends them as a plain-language Slack message to the person most likely to know, with only the context needed to answer.

  • Buttons for the expected answers. One tap records a structured decision. Free-text replies work too.
  • It says why you were asked. Every message names the reason: an owner, CODEOWNERS, a linked ticket.
  • Vague answers get one follow-up. “Sounds fine” is not recorded as a decision. A precise question is.
  • Wrong person? Say so. “I am not the right person” reroutes the question instead of dropping it.
  • No diffs in Slack. The code stays behind a signed link to the task, not in the message.
An example Slack direct message from Warpway to a product owner about pull request 486, with answer buttons, an ambiguous reply, Warpway’s follow-up question and the recorded answer.
Direct messageExample
  1. WarpwayAPP10:42

    Warpway needs your input for PR #486

    When a subscription is cancelled, should unused credits be deleted immediately?

    Current implementation deletes them.

    I could not find a requirement specifying the intended behavior.

    Why you: you own the linked ticket BILL-212 (subscription cancellation).

    • Delete credits
    • Preserve credits
    • Needs discussion

    Open detailsI am not the right person

  2. Priya10:51

    Sounds fine.

  3. WarpwayAPP10:51

    To record this unambiguously: when a subscription is cancelled, should unused credits be deleted or preserved?

    • Delete credits
    • Preserve credits

    Priya chose Preserve credits. Recorded: unused credits survive cancellation. Product Semantics is re-evaluating PR #486.

In GitHub

One check. One summary. A policy you can read.

Results land where your team already works: a single check bound to the head commit, one summary comment edited in place, and the deterministic policy state behind both.

Merge gating
Warpway / ReviewAction required · bound to head commit 3f9c2e1Example
  • Correctness
  • Security
  • Product Semantics — waiting on Priya
  • Testing
  • Backward Compatibility

Human tasks: 1 open / 2 resolved

Review policy not satisfied: 1 human task remains.

One check per pull request, always bound to the exact head commit. Native line annotations appear only for concrete findings.

How it works

Investigate broadly. Escalate narrowly.

Every eligible pull request gets the same seven steps, and every step leaves a record you can inspect later: what was planned, what was found, who was asked and why.

How reviews work

  1. A review plan for the exact commit

    Warpway summarizes what changed, which subsystems and risks are involved, and plans the review for that head commit: which lenses apply, which rules and context matter, which tools each lens may use. Required lenses cannot be planned away.

    Review plan

  2. Lenses investigate the code, not just the diff

    Each lens checks one concern, such as security or database safety, with read-only repository tools: reading files, finding references, history and blame, related tests, CI status and linked issues.

    Lens results

  3. Every conclusion cites evidence

    Code ranges, tool output, CI and runtime results, requirements and human answers are stored with where they came from. An arbiter checks that the evidence supports each claim and never turns Incomplete into Cleared.

    Evidence

  4. What AI cannot resolve becomes one bounded question

    A human task states the exact question, why it matters, why AI could not decide, the evidence so far, the relevant lines and the answers it expects. Vague asks like “review security” are rejected.

    Human task

  5. Routed to the person most likely to know

    Owners, CODEOWNERS, configured teams and review history pick who to ask, and the reason is shown. Engineers are mentioned on the pull request (with a reviewer request when your settings allow it); product, legal or operations experts get a Slack direct message.

    Routing decision

  6. Deterministic policy, not a model, decides

    Code evaluates your policy from stored results: required lenses resolved, no open required tasks, no blocking findings, CI passing. Anything incomplete stays a blocker.

    Policy state

  7. One check and one summary on the pull request

    Warpway / Review reports on the exact head commit, and a single summary comment is edited in place. A new commit starts a new run; a superseded run can finish but cannot publish.

    Warpway / Review

Lenses

Eight lenses out of the box. Yours on top.

Each lens ends in exactly one state: Cleared, Issue found, Human decision required, or Incomplete. Incomplete never quietly becomes Cleared.

  • Correctness

    Logic errors, edge cases, error handling, concurrency where relevant, and behavior that does not match intent.

    Required on every PR

  • Security

    Authentication, authorization, tenant isolation, injection, data exposure, secrets, trust boundaries and privilege escalation.

    Required on every PR

  • Testing / Reliability

    Coverage of changed behavior, failure paths, retries, race conditions, rollback and recovery, and regression tests.

    Required on every PR

  • Architecture / Maintainability

    Dependency boundaries, abstractions, coupling, duplication and architecture conventions.

    Advisory

  • Backward Compatibility

    Public APIs, persisted data, schemas, events, SDKs, clients and feature-rollout compatibility.

    Required when it applies

  • Performance

    N+1 queries, memory growth, expensive loops, network calls, serialization and hot-path regressions.

    Advisory

  • Product Semantics

    Whether behavior matches the ticket or specification, and whether a business decision is missing.

    Required when it applies

  • Database Safety

    Destructive migrations, locks, table rewrites, data loss, transaction semantics and rollout safety.

    Required when it applies

Custom lenses for what only your team checks

Write your own instructions, where the lens applies, the evidence it must gather, who owns its questions, whether AI may clear it and whether a person must always sign off. Every edit is versioned, and each review records the version it used.

Lens reference
.warpway.yml
version: 1
lenses:
  hipaa_phi:
    name: HIPAA PHI Handling
    applies_when:
      paths:
        - src/patient/**
        - src/integrations/ehr/**
    instructions:
      - Confirm PHI is not written to application logs.
      - Confirm access remains tenant-scoped.
      - Confirm external processors are approved.
    required_evidence:
      - data_flow
      - logging_paths
      - external_services
    routing:
      slack_user_group: "@privacy"
    human_signoff:
      required_when_uncertain: true

Trust levels

Autonomy you raise one level at a time.

Each repository shows its trust level. A .warpway.yml can lower it, never raise it, and raising a repository to Clear or above takes an Owner. Auto-approve is off by default and only an Owner can enable it.

  1. Level 0

    Observe

    Run reviews and display results. No routing or gating.

    The check is always neutral and nobody is asked anything. Good for a quiet first week.

  2. Level 1

    Assist

    Create and route human tasks, including Slack outreach.

    Human tasks go to the right people on GitHub, and in Slack on plans that include it. The check still never blocks.

  3. Level 2

    Gate

    The Warpway / Review check blocks until required work is resolved.

    Make Warpway / Review a required check: it passes only when your policy is satisfied.

  4. Level 3

    Clear

    Lenses may be AI-cleared so reviewers focus on unresolved areas. Final approval stays human.

    Lenses that allow it can be cleared by AI, so reviewers spend time only on unresolved areas.

  5. Level 4

    Auto-approve

    Warpway may submit APPROVE when an Owner enabled it and every deterministic condition passes.

    Off by default. Only an Owner can turn it on, and every deterministic condition must pass.

Hard rules

What Warpway never does

These are built into the product and our policies, not settings you have to remember.

  • Approve because a model sounded confident

    Auto-approval needs an Owner to opt in and every deterministic condition to pass for the exact commit. A confidence number is never enough.

  • Let a pull request weaken its own review

    The policy for a review always comes from the base branch. A PR that edits .warpway.yml is still reviewed under the policy it is trying to change.

  • Show green when work is incomplete

    If a model call, a tool or a runtime check fails, the lens stays Incomplete and the check says so. If a usage limit stops the review, the check says Usage limit reached instead of passing.

  • Run commands a model wrote

    Runtime verification dispatches only the workflow profiles you approved, in your own GitHub Actions. No tool executes shell commands.

  • Send your diffs to Slack

    Slack messages carry a plain-language question and a signed link to the task details, never the diff.

  • Train models on your code

    Warpway does not train models on customer code, and OpenAI does not train on data sent through its API unless a customer opts in.

  • Match people by display name

    A Slack account is linked to a person only by an explicit link, a verified email match you enabled, or an admin.

  • Merge or push code

    The GitHub App can read code and write checks and comments. It has no permission to push commits or merge.

Questions

Does Warpway replace code review?

No. It changes what people review. Warpway investigates every eligible pull request and asks people only the questions it cannot settle, with the lines and evidence they need. Unless an Owner enables auto-approval, Warpway never approves a pull request: approval stays with your team.

Will it approve pull requests on its own?

Only at trust level 4, which is off by default and can be turned on only by an organization Owner. Before it submits an approval, Warpway checks every condition deterministically against the exact commit: required lenses resolved, no open required tasks, no blocking findings, CI passing, and your path and size rules. See Auto-approval.

Will it catch every bug?

No reviewer, human or AI, can promise that. Warpway shows what each lens investigated and what it did not, so you can see the coverage behind every result. When it cannot finish required work, the lens is marked Incomplete and the check never reports success.

Who answers the questions?

Whoever is most likely to know: rule and lens owners, CODEOWNERS, the people and teams you configure, and people who reviewed or changed that code. Product, legal and operations experts answer in Slack without a Warpway account, and anyone can answer “I am not the right person” to reroute. See Routing.

What if an answer is vague?

A reply like “Sounds fine” does not resolve a task. Warpway asks one precise follow-up, then records the exact answer, what it means, who gave it and where, and re-runs the affected lens.

What access does the GitHub App need?

Metadata (read), Contents (read), Issues (read), organization Members (read), Pull requests (write) and Checks (write). It cannot push code or merge. Runtime verification, if you turn it on, uses a separate app with only Actions (write). See GitHub permissions.

Is my code used to train AI models?

No. Warpway does not train models on your code, and our model provider, OpenAI, does not train on data sent through its API unless a customer opts in, which Warpway has not. See Model providers.

Can we configure it in the repository?

Yes, with a .warpway.yml file on the Team plan. It is always read from the base branch, so a pull request cannot loosen the rules it is reviewed under, and an Owner can lock settings for every repository. See Configuration as code.

Which languages does it support?

Lenses read any text-based source. Symbol and reference lookups are language-aware for TypeScript and JavaScript and fall back to text search for other languages.

Do you support GitLab or Bitbucket?

Not today. Warpway works with pull requests on GitHub.

Bring people in only where they are needed.

Install the GitHub App on the repositories you choose. Reviews start on the next pull request; nothing blocks until you turn on gating.

Install on GitHubRead the docs