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.
Before you begin
Section titled “Before you begin”- 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.
Put the agent in the PR review loop
Section titled “Put the agent in the PR review loop”-
Enable the vendor review integration.
Claude Code: managed Code Review (fastest start) or
claude-code-actionin your own CI (Bedrock, Vertex, or Foundry when traffic must stay on your cloud agreement). Cursor: Bugbot on the repository, plus/reviewor/review-bugbotbefore push. Codex:openai/codex-action@v1runningcodex execfrom a prompt file. -
Write
REVIEW.mdat 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. -
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.
-
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.
-
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.mdas part of that review. -
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
## PassesRun 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 hereReserve Important for findings that would break behavior, leak data,or breach a policy. Style and naming are nits.
## Cap the nitsReport at most five nits per review; summarize the rest as a count.
## Do not reportGenerated files under src/gen/ and anything CI already enforces.Hooks as approval gates
Section titled “Hooks as approval gates”Build-phase hooks allow or block with no human involved. A release hook asks: it pauses until a specific person approves.
-
List the human approval gates that must survive: change-management sign-off, release authorization, edits to protected paths.
-
Express each gate as a hook (or the closest Codex/Cursor equivalent) that can allow, ask, or block.
-
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.
-
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 authorizationcmd=$(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 fifiexit 0Exit 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.
-
Start with read-only judgment steps in the pipeline: triage a failed build, summarize a flaky test, draft the changelog (
claude -porcodex exec). -
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.
-
Sandbox agent jobs: containers, network policy, short-lived scoped tokens, no standing production credentials.
-
Expose deploy, status, and rollback through MCP, scoped per environment, so deployment power is an allowlist.
-
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.
-
Rehearse rollback in staging until it is a single command the agent can run. Maintain calls this path when a control band is breached.
Governance
Section titled “Governance”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.
Verify
Section titled “Verify”- 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.
Apply the play in your tool
Section titled “Apply the play in your tool”Return production evidence to planning
Section titled “Return production evidence to planning”Close the loop from production — Maintain.