Skip to content

Deploy: review in both directions, gate production

The deploy stage gives every pull request repeatable, ranked agent review while preserving human accountability for merge and production. Automated passes check bugs, security, and specification compliance; branch protection and environment approvals ensure that neither the authoring agent nor a confident review can cross the release gate.

Traditional: Review capacity was planned around human output. A PR waits for a reviewer to read all of it. Review quality varies with load. The author chases while the backlog grows.

AI-native: All PRs get an identical set of review passes, with findings ranked by severity. Human attention moves up a level: does the change do what the plan intended, and is the risk acceptable?

Reviewing each line by hand made sense when a person had written it. It cannot keep up once agents write most of the diff. Human review is reserved for regulated and critical code; everything else is agent-reviewed first.

  • An updated project instruction file from Build
  • Skills if review passes enforce written policies
  • Branch protection that requires a code owner’s approval

Prerequisites: Claude / Cursor / Codex in the PR loop, and hooks as approval gates, before you automate anything through those gates.

  1. Enable the vendor review integration.

    Claude Code: managed Code Review (fastest start) or claude-code-action in your own CI (Bedrock, Vertex, or Foundry when traffic must stay on your cloud agreement). Cursor: Bugbot on the repository, plus /review or /review-bugbot before push. Codex: openai/codex-action@v1 running codex exec from a prompt file.

  2. Write REVIEW.md at the repo root.

    Divide it into the passes the organization cares about: bugs and logical errors; security; compliance against spec.md, plan.md, and design principles. Define what counts as Important versus a Nit, and what to skip.

  3. Set the human threshold.

    Findings do not approve or block a PR on their own. Branch protection still requires a code owner. If you want to gate merges on findings, read the severity counts the check run publishes.

  4. Let the agent address review comments on its own PRs.

    Tagging the bot on a comment should produce a fix commit. Wrap the loop in a slash command or skill that sweeps unresolved comments and failing checks until the PR is green and waiting only on code owner approval. The agent that wrote the code has no route to approve it.

  5. Feed review findings back into the instruction file.

    When a review flags a mistake for the second time, the correction goes into CLAUDE.md / rules / AGENTS.md as part of that review.

  6. Once a month, tune the setup.

    Rate findings so the reviewer improves. Cap Nit volume in REVIEW.md. Exclude generated paths and anything CI already enforces.

Example REVIEW.md:

# Review instructions
## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles
## What Important means here
Reserve Important for findings that would break behavior, leak data,
or breach a policy. Style and naming are nits.
## Cap the nits
Report at most five nits per review; summarize the rest as a count.
## Do not report
Generated files under src/gen/ and anything CI already enforces.

Build-phase hooks allow or block with no human involved. A release hook asks: it pauses until a specific person approves.

  1. List the human approval gates that must survive: change-management sign-off, release authorization, edits to protected paths.

  2. Express each gate as a hook (or the closest Codex/Cursor equivalent) that can allow, ask, or block.

  3. Put team hooks in git. Put non-negotiable hooks in managed settings owned by the platform or IT admin, where individual engineers cannot switch them off.

  4. When a hook stops an action, the reason and the route to approval appear in the agent’s output.

Claude Code example (.claude/hooks/production-gate.sh behind a PreToolUse matcher on Bash):

#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
if [ -z "$RELEASE_APPROVAL" ]; then
echo "Production deploys need a release authorization." >&2
exit 2
fi
fi
exit 0

Exit code 2 blocks the action; the message goes to the agent.

Cursor: encode the same gate as a beforeShellExecution hook in .cursor/hooks.json. On Enterprise, also set team and enterprise-managed hooks in the dashboard so Cloud Agents pick them up.

Codex: there is no hook VM identical to Claude Code. Combine sandbox (workspace-write versus danger-full-access), approval_policy, and a CI job that refuses production deploy credentials to the agent identity.

For how these controls compose at production scale, see How Anthropic secures its AI-native SDLC.

  1. Start with read-only judgment steps in the pipeline: triage a failed build, summarize a flaky test, draft the changelog (claude -p or codex exec).

  2. Add write steps behind existing gates: fix lint, update generated docs, address review comments. Anything the agent writes arrives as a PR. The agent has no route to push to main.

  3. Sandbox agent jobs: containers, network policy, short-lived scoped tokens, no standing production credentials.

  4. Expose deploy, status, and rollback through MCP, scoped per environment, so deployment power is an allowlist.

  5. Tier autonomy by environment. In a disposable local or development sandbox, the agent may run the deployment procedure within scoped credentials. For production, the agent prepares evidence; the release manager authorizes promotion; controls outside the model enforce the gate. Staging follows its own documented risk class.

  6. Rehearse rollback in staging until it is a single command the agent can run. Maintain calls this path when a control band is breached.

The governing principle: the agent may act up to the production gate and cannot pass it.

  • Branch protection turns anything the agent writes into a PR.
  • The production deploy hook blocks the release until a named release manager authorizes it.
  • Each non-interactive run acts under the agent’s own identity, so the pipeline log separates what the agent did from what the engineer who triggered it did.
  • Per-environment permission tiers set how much the agent may do on the way to the gate.

Separation of duties is preserved because the agent that wrote the code has no way to approve it. The PR is the audit record.

  • A PR opened by an agent received an automated review pass within minutes.
  • Merging still requires a human code owner.
  • A production deploy command without RELEASE_APPROVAL (or the Cursor/Codex equivalent) is blocked.

Leading indicator: time to first review; share of review comments resolved without a human touching the branch.

Lagging indicator: defects and vulnerabilities caught before merge versus those escaping to production; DORA measures the CI system already emits.

Close the loop from production — Maintain.