AI Agents Can Prepare Releases But Must Not Cross Production Gates

Code Review Acceleration Does Not Remove Release Responsibility

Continuing the batch-import case study, the agent has completed upload, async tasks, validation, batched writes, and result queries, with related tests passing. It can quickly summarize the change: new interfaces and tables, permission modifications, migrations executed, and expected metric impacts. This information significantly lowers review cost, yet it cannot automatically answer critical questions:

Will the database migration lock tables or affect the old version?

Do new permissions expand data access scope?

Are queue backlog and database pressure within production budget?

After code rollback, how should already-written data be handled?

Who accepts the remaining risk?

Review and release are not a final code-style check; they are a responsibility transfer: local changes enter a shared environment, affecting real users, data, and dependencies.

Division of Labor: AI Review, Deterministic Checks, and Human Review

Three review types suit different problems:

AI Code Review — Better suited for: cross-file understanding, potential omissions, implementation-vs-design gaps. Main boundary: may be affected by context and model judgment.

Deterministic Checks — Better suited for: build, test, scan, contract, and policy gates. Main boundary: can only execute already-coded rules.

Human Review — Better suited for: business semantics, architectural trade-offs, residual risk, and authorization. Main boundary: should not repeat mechanical checks machines can stably perform.

The agent can help reviewers locate high-risk diffs — e.g., "interface allows partial success but task status lacks failure details" or "database migration missing compatibility window" — but these suggestions must be verified against code, design, and test evidence. An agent output of "no issues found" does not equal approval; it only means no issues were identified within its current context and check scope.

Different Environments Require Different Autonomy Levels

Development, test, staging, and production environments have different failure impacts, so the agent cannot have uniform permissions:

Local or isolated branch — Allowed automation: modify code, run tests, rebuild temporary data. Required boundary: no access to real sensitive data or production credentials.

Shared test environment — Allowed automation: deploy candidate versions, generate test data, run integration validation. Required boundary: prevent impact on other teams and shared baselines.

Staging environment — Allowed automation: execute release rehearsals, migration validation, and failure checks. Required boundary: data, dependencies, and permission scope must be controlled.

Production environment — Allowed automation: execute approved release steps and read-only diagnostics. Required boundary: high-risk actions require authorization, audit, and stop conditions.

Autonomy level should be determined by environment, action, and business risk together — not simply by "whether an agent is used." The same query action may be free in test but leak sensitive data in production; the same migration script may succeed on an empty database but be unsafe on production-scale data.

Production Permissions Must Be Short-Term, Minimal, and Auditable

Letting the agent use a shared admin account is the most direct and dangerous approach. Permission boundaries must be enforced in tools and platforms, not only in prompts; even if the agent misjudges, it should lack the capability to expand impact. Branch protection and release pipelines serve the same role: the development agent can submit candidate changes but cannot modify protected rules, bypass required checks, or forge approval records.

How Far Can the Agent Go in Release Preparation?

Within a controlled process, the agent can handle extensive pre-release work:

Generate impact analysis against design and change diffs.

Verify completeness of test, migration, security scan, and capacity evidence.

Produce release notes, observation metrics, and rollback conditions.

Execute deployment and migration rehearsals in staging.

Collect pipeline failure evidence and invoke controlled release tools per approval records.

These tasks concentrate human attention on genuine judgment points. However, the following decisions must never be made by the agent alone:

Modifying production gates to fit the current change.

Accepting unclosed high-risk defects.

Repeating side-effect operations when business state is unknown.

Expanding production permissions, data scope, or runtime limits.

Treating review suggestions as final approval.

Being well-prepared and having authority to approve are two different things.

Pre-Approved Runbooks Are Not Unlimited Authorization

A runbook is a reviewed operational playbook. For actions with stable steps, clear impact scope, verifiability, and abortability, the agent may execute after authorization. Example: when a batch-import task backlog exceeds a threshold, a pre-approved runbook may allow querying backlog and oldest task, checking dependency health, pausing new task intake, adjusting consumer concurrency within a defined range, then verifying backlog convergence.

It must not allow the agent to indefinitely add instances, clear task tables, or directly modify customer data without confirmed cause. Every runbook needs defined trigger conditions, required evidence, allowed actions, impact ceiling, verification method, abort conditions, and human escalation entry. When the current fault exceeds these conditions, the correct state is stop and escalate — not continue free reasoning.

Version Rollback Does Not Equal Business Recovery

After releasing a new batch-import version, if error rates rise, rolling back the application version may stop new defects. However, already-created tasks, written data, and emitted messages still exist. The agent can diagnose differences, prepare recovery checklists, and execute approved steps, but a tool returning success does not mean business is recovered. Final confirmation requires task status, database results, external receipts, and user impact verification.

Release Authorization Must Bind Current Evidence and Responsibility

A valid release authorization must at minimum specify: which artifact and configuration to release, which verification evidence is used, target environment, known risks, approver identity, and conditions that trigger stop or rollback. When code, migrations, permissions, or dependencies change, prior approvals cannot be reused automatically. The value of the production gate is not adding a button, but ensuring "can execute" and "allowed to execute" are not conflated.

Summary

Agents can make review, release preparation, and failure diagnosis faster, and can execute controlled steps under explicit authorization. But production system permissions and risk do not disappear because automation capability improves.

Agent负责准备和执行受控动作，
工具负责限制权限和留下证据，
责任人负责授权和接受剩余风险。

The next article will close the series: once a system enters production, how do metrics, incidents, and user feedback flow back into development — instead of staying in a report no one reads after the fix is done.