Review and ship

Shipping agent-written code safely rests on five controls built in order: an evidence bundle that CI enforces on every pull request, routing by risk class through code owners, a review agent that triages before a human decides, pipeline gates the agent cannot weaken, and progressive delivery with automatic rollback. Nobody reads every line of every diff; only high-risk changes get a human code reader.

This section is for developers who merge what their agents write and for tech leads who own the review policy. When agents open more pull requests than you can read, you either stall the queue or approve on trust; the pages below replace both with evidence.

Which review-and-ship guide fits your problem?

Your situation	Start with
Agent PR descriptions contain nothing verifiable	The evidence bundle
The review queue is the bottleneck	Agent PR review
You want separate review agents per concern	Layered pull-request review
PRs loop between agent and reviewer	A bounded review-fix loop
An agent edits CI, or the pipeline is slow	Pipeline automation
You merge changes nobody read line by line	Progressive delivery
Nobody has rolled back production in months	Rehearsed rollback
You must decide who approves production changes	Production approval
The agent writes Dockerfiles, manifests or Terraform	Containerization and infrastructure as code

This section follows testing and hands over to operations once the change is live.

In what order should you build the ship path?

1. Require an evidence bundle on every pull request. It maps each acceptance criterion to a check that ran and declares the risk class; CI fails the pull request when it is incomplete. See the evidence bundle.
2. Route by risk class through CODEOWNERS. low and standard changes are approved on the bundle; high changes (auth, money, schema, migrations, a loosened test) get a named code reader. See the risk-class policy.
3. Run a review agent before any human. It reports against a committed checklist; the human then runs the six-step triage in agent PR review.
4. Keep the pipeline out of the agent’s reach. Require checks and put code owners on .github/workflows/; see pipeline automation and protecting the oracle.
5. Ship behind a flag or a canary with automatic rollback, and rehearse the rollback. See progressive delivery.

Where does the review agent run in each tool?

The bundle, triage and risk classes are the same in every tool; only the review agent’s location differs.

Claude Code

In a session, run /code-review. In CI, run your committed checklist with claude -p and a read-only tool allowlist. For high changes, claude ultrareview 482 runs a cloud multi-agent review of pull request 482: three one-time free runs on Pro and Max, then typically $5 to $25 each. It is not available on Bedrock, Google Cloud, Foundry or with Zero Data Retention. The managed Code Review service (Team and Enterprise; generally available per Anthropic, checked 2026-10-16) reads a repository-root REVIEW.md. See review and ship with Claude Code.

Codex

codex exec review --base main -o review.md reviews the branch against main and writes the findings to a file (Codex CLI 0.157.1). For your own checklist, pass it as the prompt instead of --base; the two do not combine. On GitHub, comment @codex review on the pull request, and put the review rules in AGENTS.md. See review and ship with Codex.

Cursor

Bugbot reviews pull requests for bugs, security and code quality issues. PR Routing & Approval assigns reviewers by code ownership and can approve low-risk pull requests that meet your rules; make “no high risk class touched” one of them. See review and ship with Cursor.

In CI, the branch under review is untrusted

A review job that loads the branch’s agent settings runs its hooks and MCP servers with the job’s secrets. Load no project settings from the commit (--bare --setting-sources "" --strict-mcp-config for claude -p) and keep secrets out of the job. See headless agents in CI.

Copy-paste prompts for review and ship

Start with the audit: it shows which of the five controls your repository already has.

Copy-paste prompt: audit the ship path of this repository

Audit how a change in this repository gets from a pull request to production.
Read only: do not edit files, open pull requests or run deploys.

Check for each control and cite the file and line that proves it exists:
1. Evidence: a pull request template that asks for acceptance criteria mapped
   to checks, a risk class and a rollback path; a CI job that fails when the
   description is incomplete.
2. Routing: .github/CODEOWNERS entries for auth, payments, database migrations,
   tests and .github/workflows/.
3. Review: a committed review checklist or REVIEW.md that a review agent runs.
4. Pipeline: checks required on main; any workflow that deploys without them.
5. Delivery: flag or canary config; a rollback that needs no new build.

Output a table: control, status (present, partial, missing), evidence, and the
smallest change that would close the gap. List the gaps in the order above.

Run the second prompt on a finished branch, before you open the pull request.

Copy-paste prompt: can this branch ship?

Decide whether the changes on this branch against main are ready to ship.
Do not edit, commit, push or deploy.

1. Run the test, type-check and lint commands from package.json. Paste each
   command, its exit status and the commit SHA from git rev-parse HEAD.
2. List every behavior change as one sentence, and mark any the linked issue
   did not ask for.
3. List every changed test, snapshot, fixture, CI or lint file, and say whether
   it makes a check stricter, looser or neutral.
4. Propose a risk class: high if the diff touches auth, payments, schema,
   migrations or loosens a check; standard for other behavior changes; low
   for docs and copy.
5. Name the rollback: the flag to switch off, or the exact revert, and the
   metric and threshold that would trigger it.

End with SHIP, FIX FIRST (with the items), or NEEDS A CODE OWNER (with the
paths), and one sentence of reasoning.

How do you prove a change is safe to ship?

Each control leaves machine-produced evidence with a named owner: the bundle check on the head commit, the review-agent report with triage notes, a code owner’s reading for high changes, and canary or flag metrics inside a pre-set guardrail. The evidence bundle page lists who signs off on each. Track the escape rate by risk class and the share of bundles that pass on the first attempt; see metrics frameworks.

What breaks when agents ship code?

• Green checks from an older commit. Recovery: require the commit SHA with every result; trust CI over the agent.
• The agent loosens a test to pass the build. Recovery: give test and CI paths a code owner, and classify any loosened check as high.
• Every pull request escalates. Recovery: narrow sensitive paths to code where mistakes are costly and slow to detect.
• The rollback needs a build. Recovery: ship behind a flag or canary that aborts in seconds, and rehearse it.
• The review agent buries real findings in style comments. Recovery: limit it to production-relevant findings, ranked by severity.

Where to go next with review and ship

Start with the evidence bundle, then the agent PR review triage. If your team still reads every diff, see helping the team stop reading every diff and running the review queue.