Releasing AI-generated code: the agent prepares, you approve

In a release process for AI-assisted software, a coding agent prepares the release and a person authorises it. The four steps that need that person are the merge to main, the production deploy, a production migration and a package publish.

The path runs from a branch to a pull request, through checks and review. Then come staging, a controlled rollout, monitoring and, if needed, a rollback. This part of the series joins the earlier parts into that one path. The tool behaviour below comes from each tool’s official docs, last verified on 11 October 2026; none of it was tested for this post.

The release path, and who owns each step

Every AI-written change follows the same road to production as a human one:

local change → branch → pull request → checks → review → merge
  → staging → production, flag off → gradual rollout → monitor
                                              ↘ rollback

Preparing a step and authorising it are different jobs. An agent that drafts the migration script has done useful preparation. An agent that runs it on production has made a release decision.

The right-hand column is the minimum. Your team may put more there; it should not put less. Earlier parts cover the rows in depth: the evidence in Part 4 and the gates in Part 10. Risk-first review is Part 11, and the dependency decision is Part 12.

Release approvals belong in platform settings

Telling an agent “never merge to main” is a request. A protected branch is a rule the platform enforces, whoever asks. So the right-hand column of the table belongs in platform settings. Part 6 covers production access and the difference between approval and enforcement.

Protected branches stop the merge

GitHub’s protected branch docs let you require “a specific number of approving reviews” and passing status checks before a merge. You can also require that “the most recent reviewable push must be approved by someone other than the person who pushed it”. Then a late push from an agent cannot ride in on an earlier approval.

The same page says branch protection rules “don’t apply to people with admin permissions” unless you turn on “Do not allow bypassing the above settings”. An agent that runs with an admin’s token inherits that bypass.

Environments stop the deploy

A GitHub environment is a named target, such as production, with its own protection rules. With required reviewers, a deploy job waits until one of up to six listed people or teams approves it. With the option to prevent self-reviews on, “users who initiate a deployment cannot approve the deployment job”. Environment secrets stay locked too: “a job cannot access environment secrets until one of the required reviewers approves it”.

An example deploy workflow looks like this; the deploy script is a placeholder for your own:

name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v7
      - run: ./scripts/deploy.sh

The environment: production line is the gate. If the production environment has required reviewers, the job pauses there until a person approves it, whoever or whatever pushed to main. The same docs say administrators can bypass environment rules by default. On the GitHub Free, Pro and Team plans, required reviewers only work in public repositories.

Package publishing can use the same gate. npm’s trusted publishing docs let you publish from CI with OpenID Connect (OIDC) instead of a long-lived token. You can name a GitHub environment for the publish, and the docs suggest you “Use deployment environments to add approval requirements”.

What five coding agents can do with a pull request

Cloud and CI coding agents work on a branch and hand you a branch or a pull request. The docs differ on who opens the pull request, and on what still needs a person:

Each row comes from that tool’s official docs, last verified on 11 October 2026; none was tested for this post.

Those hand-offs are each agent’s defaults; your repository settings decide the rest. A workflow that hands the agent more tools or a stronger token changes the picture. So does one that deploys on every push to main with no environment approval: the agent’s change goes out as soon as anyone merges it.

Release in small steps: staging, flags and canaries

Staging catches some of what tests miss: deploy config, environment differences, the services around yours. Production still differs from staging, so keep the production step small.

A feature flag separates the deploy from the release

A feature flag lets you deploy the code switched off, then turn it on later. Pete Hodgson’s feature toggles article on Martin Fowler’s site calls release toggles the most common way to follow one Continuous Delivery principle. That principle is “separating [feature] release from [code] deployment”. The same article describes long-lived “Kill Switches” that let operators switch off less important features when the system is under unusually high load.

Flags have a cost. The article says release toggles “should generally not stick around much longer than a week or two”. Some teams add a toggle removal task to the backlog as soon as a release toggle goes in. An agent that adds a flag can add that task in the same pull request.

A canary shows the damage on a small slice first

The Google SRE workbook’s canarying chapter defines canarying as “a partial and time-limited deployment of a change in a service and its evaluation”. The slice that gets the change is “the canary”, and the rest is “the control”. If the canary’s error rate drifts too far from the control’s, the workbook’s example pauses and rolls back.

Decide the stop signals before you release

Write the stop signals down before the rollout starts, while nobody is under pressure. The SRE book’s monitoring chapter names four golden signals: “latency, traffic, errors, and saturation”. Add the business signal the change touches, such as sign-ups or payments. An agent can draft the queries and thresholds. A person agrees them, and a person decides when to widen the rollout.

Write the rollback plan before the release

A rollback plan answers three questions: how do we turn it off, how do we go back, and what cannot be undone? The first answer is often the flag. The second is redeploying the previous version. The third is usually the database.

A migration that drops a column cannot be rolled back by redeploying old code. Martin Fowler’s parallel change pattern, “also known as expand and contract”, splits a breaking change into three phases: expand, migrate and contract. Add the new column first, move the code over, and drop the old column in a later release, once nothing reads it. Each release stays reversible.

Small releases help too. In the SRE workbook’s words, “Smaller, self-contained release artifacts make it cheaper and easier to roll back”. You can ask the agent to split a large change into smaller pull requests.

Release notes and a changelog the agent can draft

Release notes suit an agent, because the facts sit in the merged pull requests and the diff. GitHub’s automatically generated release notes list the merged pull requests, the contributors and a link to the full changelog. That list is a starting point. Users need to know what they will notice and what they have to do.

Keep a Changelog says it plainly: “Changelogs are for humans, not machines.” It groups changes by type: Added, Changed, Deprecated, Removed, Fixed and Security. New entries go in an “Unreleased” section at the top until the release. An agent can keep that section current on every pull request. A person reads it before the tag goes out.

Two prompts: prepare the release, plan the rollback

Both prompts are examples and rely on no tool-specific feature. Neither lets the agent merge, deploy, tag or publish.

Prompt 1: prepare a release candidate

Use Prompt 1 when a release’s pull requests are merged or ready, and you want the release pack before you decide.

Task: prepare a release candidate for <the pull requests or changes in
this release>.

Your job is to prepare the release, not to perform it.
Keep the investigation to the commits, pull requests and files this
release needs.

Prepare:
1. A summary of what changed and why, linked to each pull request.
2. A changelog entry under "Unreleased", grouped as Added, Changed,
   Deprecated, Removed, Fixed and Security.
3. Draft release notes for users: what they will notice, and any
   action they must take.
4. Every database migration, and whether it can be reversed.
5. New or upgraded dependencies.
6. Config, environment variable and feature flag changes.
7. The evidence: which checks ran, their results, what is unverified.
8. A risk list: what could break, and how we would notice.

Write drafts to the working tree only, or return them in your reply.
Do not commit or push.
Never merge, create or push a tag, deploy, publish a package, or run a
migration against any shared or production environment. A person does
those steps.
Do not run destructive commands or make other external changes unless
I explicitly authorise it.
Never print, expose or commit secret values.
If two reasonable attempts fail, stop and report the failure rather
than repeatedly guessing.

End with "Ready for human release review" or a list of blockers.

The last line gives you a clear yes or no to act on.

Prompt 2: plan the rollback

Use Prompt 2 on any release that touches data, config or a public interface.

Task: write a rollback plan for <the release or pull request>.

Read only what the plan needs: the diff, migrations, config and
feature flag changes, and the deploy workflow.

Report:
1. How to turn the change off without a deploy (a flag or kill
   switch), if one exists.
2. How to redeploy the previous version.
3. For each database migration: is it reversible, what is the reverse
   step, and what data could be lost. Mark any step that cannot be
   undone.
4. Whether the previous version still works with the new schema. If
   not, propose an expand and contract order instead.
5. The signals that should trigger a rollback, with thresholds to agree
   before release: errors, latency, traffic, saturation, and any
   business signal this change touches.
6. Who decides, and how we confirm the rollback worked.

Do not run any rollback, migration or deploy command.
Do not change production, staging or any shared environment.
Do not commit, push, merge, tag or publish.
Do not run destructive commands or make other external changes unless
I explicitly authorise it.
Never print, expose or commit secret values.
If two reasonable attempts fail, stop and report the failure rather
than repeatedly guessing.
Mark anything you could not verify as unverified.

A release checklist for AI-assisted changes

An example checklist to copy into your pull request template or release ticket:

RELEASE CHECKLIST: AI-ASSISTED CHANGE

□ Change is on its own branch, in a pull request
□ Required checks passed; none skipped or weakened
□ Evidence recorded: what ran, results, what is unverified
□ Risk-first review approved by a person
□ New dependencies approved by a person
□ Migrations reviewed; reverse step or expand and contract plan written
□ Rollback plan written
□ Feature flag off by default, or a staged rollout planned
□ Stop signals and thresholds agreed before release
□ Release notes and changelog entry read by a person
□ Merge approved by a person, enforced by branch protection
□ Production deploy approved by an environment reviewer
□ Each rollout stage watched before the next one
□ Flag removal task added

Quick answers

Can an AI coding agent deploy to production?

An AI coding agent can deploy to production only if its credentials or a workflow it can trigger allow it. A safer setup lets the agent prepare the release, and puts the deploy behind an environment that needs a person’s approval.

Can a coding agent merge its own pull request?

A coding agent’s pull request still waits for a person in the documented setups. GitHub says the Copilot cloud agent “cannot approve or merge a pull request”, and Cursor says nothing merges until a person reviews it. Branch protection with required approvals enforces that for any agent.

What should a coding agent never do in a release without approval?

A coding agent should not merge to main, deploy to production, run a production database migration or publish a package without a person’s explicit authorisation. It can prepare all four: the pull request, the release candidate, the migration script and the release notes.

What is a feature flag in a release process?

A feature flag, also called a feature toggle, is a switch in the code. It lets you deploy code turned off and turn it on later for some or all users. It separates the deploy from the release, and gives you a fast way to turn a bad change off.

How do you roll back an AI-generated change?

An AI-generated change rolls back like any other: turn off its feature flag, or redeploy the previous version. Database changes are the hard part, so plan them in expand and contract steps, where each release can still be reversed.

More on AI coding is in the AI category.