AI CodeOps

Release checklist for teams shipping AI-written code

Last updated

A release checklist in four stages, before the cut, the candidate, the deploy and after: gates, approvals, SBOM, rollback, and who signs off on each step.

Copy this list into your release ticket for each release. Replace [brackets], delete steps that don't apply, and delete this note.

  • Release: [version or name]
  • Release owner: [name]
  • Planned date: [YYYY-MM-DD]
  • Ticket or notes: [link]

1. Before the cut

  • [ ] Every change in the release is merged through a pull request with an approval from someone other than its author.
  • [ ] Every AI-assisted change in the release says so in its pull request, with the tool and the task.
  • [ ] No change in the release has an open finding of [high] severity or above.
  • [ ] Changes to pipelines, infrastructure, authentication and migrations were approved by their code owners.
  • [ ] Feature flags for unfinished work are off by default in production.
  • [ ] Release notes are drafted from the merged pull requests, not from memory.

2. Release candidate

  • [ ] The full test suite passed on the release commit itself, not on an earlier one.
  • [ ] Coverage is at or above the floor of [N]% for [the modules that have one].
  • [ ] The SBOM for the release commit is generated and reviewed (see the SBOM review checklist).
  • [ ] No dependency in the SBOM is under a license on the [disallowed license list].
  • [ ] No known vulnerability of [high] severity or above in the dependencies, or each one has a written exception.
  • [ ] Secrets scanning passed on the whole release diff.
  • [ ] Database migrations ran against a copy of production data, and their run time is known.
  • [ ] The candidate ran in [staging] for at least [N hours] with no new errors.

3. Deploy

  • [ ] The rollback plan is written down: revert the commit, turn off a flag, or roll back the deployment. The person who will do it knows it.
  • [ ] Migrations that can't be reversed are called out, with the plan if they go wrong.
  • [ ] The deploy is announced in [channel], with the release owner reachable for [the next N hours].
  • [ ] The deploy goes out the same way as every other one, through the pipeline. No manual changes on servers.
  • [ ] Health checks and the key dashboards are open while it rolls out.

4. After the deploy

  • [ ] Error rates and latency are back to normal within [N minutes].
  • [ ] The main user journeys work in production: [sign-in], [checkout], [the feature you shipped].
  • [ ] Release notes are published.
  • [ ] Anything that went wrong is written up, and an incident caused by an AI-assisted change gets a postmortem that names the review step or gate that should have caught it.
  • [ ] Evidence for the release is stored: the commit, the approvals, the test runs, the SBOM and the deploy log.

Sign-off

StepSigned byDateNotes
Before the cut[name][YYYY-MM-DD]
Release candidate[name][YYYY-MM-DD]
Deploy[name][YYYY-MM-DD]
After the deploy[name][YYYY-MM-DD]

Frequently asked questions

How is this different from a normal release checklist?

Most of it is the same. The difference is that it asks for evidence per change instead of trusting the summary, because AI-written changes arrive faster and with confident descriptions.

Who should sign off on a release?

The release owner named at the top, plus anyone the checklist names for a specific step. The person who signs a step is saying they checked it, not that someone told them it was fine.

Should a failed check always stop the release?

Stop on any failed gate in the candidate stage. For the rest, the release owner can accept a risk, but writes down which one and why in the release notes.

Cite this

AI CodeOps (2026). Release checklist for teams shipping AI-written code. https://aicodeops.dev/templates/release-checklist

This page and its downloads are licensed CC BY 4.0: copy and adapt them for your team, and link back to this page when you publish your version.