Continuous Delivery with AI Assistance

Continuous delivery with AI agents keeps every change small enough for automated checks to prove it: one agent task becomes one commit, each pull request stays inside a size budget that CI enforces, and the pipeline decides whether a change ships. Agents raise the volume of change, so batch size becomes the control that protects stability.

You spent four hours building a feature in one agent session. The diff is 1,200 lines across 18 files, and the reviewer’s first comment is “can you split this?”. You cannot, because the migration, the API and the UI are tangled in the same commits. The pull request waits two days, and when the nightly build goes red, the agent’s quickest fix is to delete the failing test.

This page is for developers who drive agent sessions and tech leads who set the team’s merge rules. It covers the delivery discipline itself. The neighbouring pages go deeper on the evidence a pull request must carry, reviewing it without reading every line, and rolling it out safely.

Why do small batches matter more when agents write the code?

Agents make large diffs cheap to produce and expensive to verify. Three independent measurements point the same way:

DORA, 2025 report (Google Cloud, 2025-09-23): “we observe a positive relationship between AI adoption on both software delivery throughput and product performance” and “AI adoption does continue to have a negative relationship with software delivery stability.” The report names the mechanism: “Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability.”
DORA AI Capabilities Model (Google Cloud, Nathen Harvey and Allison Park, 2025-12-10): working in small batches is one of the seven capabilities, because “AI can easily generate massive blocks of code, which are hard to review and test.”
DX (Justin Reock, 2026-06-17): median pull request size “nearly doubled, growing from 44 lines to 72 lines per pull request between July 2025 and June 2026”, in a report drawing on data from over 400 companies.

Faros AI’s vendor telemetry (April 2026, 22,000 developers) shows the same trade in one report: task throughput per developer up 33.7%, pull request size up 51%, and bugs per pull request up 28.7%. The lesson for delivery is that batch size is a setting you control, and the pipeline has to hold it in place, because an agent will not.

What you get from continuous delivery with agents

A commit-per-task rule you put in CLAUDE.md, AGENTS.md or a Cursor rule, so every session produces reviewable history.
A deterministic GitHub Actions check that fails a pull request over its size budget, with no agent and no secrets in the job.
Prompts to split an oversized diff into stacked pull requests, write release notes from a commit range, and triage a red build without weakening the tests.
The gates that let a change ship on evidence instead of a line-by-line read, and the measures that show the discipline is holding.

How does continuous delivery change when an agent writes the code?

The practices are the classic ones. What changes is who breaks them and which gate catches it.

Practice	What an agent does without a rule	The gate that holds it
Small batches	Keeps going until the whole feature is done, then commits once	Commit-per-task rule plus a pull request size check in CI
Short-lived branches	Builds on a branch for hours while `main` moves	One task list per branch, merged the same day
Every commit releasable	Leaves half-finished work between commits	Tests, types and lint run before each commit
Deploy is not release	Ships new behaviour straight to every user	Feature flags and a canary (progressive delivery)
Fast feedback	Treats a red build as a problem to hide	A triage prompt that forbids skipping or loosening tests
Traceable releases	Writes “update files” as the commit message	Conventional Commits in the rules file, release notes from the commit range

Commit after every agent task, not after the feature

The habit that makes the rest possible is one completed task, one commit. If you plan with the artifact chain, each task in plan.md produces one commit, and three to five tasks make one pull request. The rule has to live in the agent’s instruction file, because a prompt you forget to type is not a rule.

Add the commit rule to the instruction file your tool reads (the tabs below show where).
Start each session from one task in the plan, not from the whole feature.
When the task’s checks pass, let the agent commit, then start the next task.
Open the pull request when the tasks for one reviewable slice are done, not when the feature is done.

Put the rule in CLAUDE.md at the repository root. From v2.1.277 on the latest release channel, Claude Code also reads AGENTS.md when there is no CLAUDE.md, so a team that shares one file with Codex can keep it there.

## Commits
- Commit after each completed task from plan.md, never after several.
- Before committing, run `npm run typecheck`, `npm run lint` and the tests for the files you changed. Do not commit on a failure.
- Stage only the files that belong to the task. Never stage .env files or generated build output.
- Use Conventional Commits: `type(scope): summary`, one logical change per commit. If the summary needs "and", it is two commits.

Put the same rule in AGENTS.md at the repository root; Codex reads it at the start of every session in a trusted project; since 0.150.0 an untrusted project’s AGENTS.md is not loaded (/init creates a starter file). Run interactive sessions with codex -s workspace-write -a on-request, so routine edits and test runs happen inside the sandbox and Codex asks before any command that needs to leave it.

## Commits
- Commit after each completed task from plan.md, never after several.
- Before committing, run `npm run typecheck`, `npm run lint` and the tests for the files you changed. Do not commit on a failure.
- Stage only the files that belong to the task. Never stage .env files or generated build output.
- Use Conventional Commits: `type(scope): summary`, one logical change per commit.

The task "Add per-client rate limiting to POST /api/orders" from plan.md is done.
Before committing:
1. Run npm run typecheck, npm run lint, and npm test -- src/api/orders.
2. If anything fails, fix the code, not the test, and run the checks again.
3. Run git status and stage only the files this task touched. Do not stage .env, dist/ or lockfile changes you did not intend.
4. Commit with a Conventional Commits message: feat(orders): <summary>, plus a body that says why.
5. Print the commit hash and the output of git show --stat HEAD.
Do not push. Do not start the next task until I confirm.

Enforce a pull request size budget in CI

A rule in an instruction file fails silently when the agent ignores it. A CI check does not. The workflow below counts changed lines against the base branch, leaves out lockfiles and test snapshots, and fails when the total goes over the budget. It runs no agent and reads no secret, so it is safe on pull requests from any branch.

name: PR size budget
on:
  pull_request:
    types: [opened, synchronize, reopened, labeled, unlabeled]
permissions:
  contents: read
jobs:
  size:
    runs-on: ubuntu-latest
    if: ${{ !contains(github.event.pull_request.labels.*.name, 'size-exception') }}
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 0
          persist-credentials: false
      - name: Fail when the diff exceeds the budget
        env:
          BASE_REF: ${{ github.base_ref }}
          BUDGET: '400'
        run: |
          set -o pipefail   # a failed git diff must fail the check, not count as 0 lines
          changed=$(git diff --numstat "origin/${BASE_REF}...HEAD" -- . \
            ':(exclude)*.lock' ':(exclude)package-lock.json' ':(exclude)*__snapshots__*' \
            | awk '$1 != "-" { total += $1 + $2 } END { print total + 0 }')
          echo "Changed lines (without lockfiles and snapshots): ${changed} of ${BUDGET}"
          if [ "${changed}" -gt "${BUDGET}" ]; then
            echo "::error::This pull request changes ${changed} lines. Split it into stacked pull requests, or add the size-exception label and explain why in the description."
            exit 1
          fi

The budget of 400 lines is a starting point, not a researched threshold. Set it from your own history: take the median size of the pull requests your team merged last quarter and start a little above it. The size-exception label is the escape hatch for generated migrations and bulk renames; the tech lead owns it, and every use is visible in the pull request.

Two limits keep this an honest gate. On the pull_request trigger GitHub runs the workflow file from the pull request’s merge ref, so a branch can raise BUDGET or delete the check in the same diff; add /.github/ to CODEOWNERS and require code-owner review in branch protection, so a change to the workflow needs the tech lead’s approval. And a job skipped by the label counts as passed for a required check, while anyone with triage access, the pull request’s author included, can add a label. GitHub has no per-label permission, so the label is a visible exception, not a control: the code owner who reviews the pull request decides whether it stands.

Split an oversized agent diff into stacked pull requests

When a session has already produced a 1,200-line branch, do not ask a reviewer to absorb it. Have the agent cut it into layers that each pass the checks on their own. The prompt is the same in all three tools; the difference is only where you run it. To run the split in a separate checkout, start the session with --worktree in Codex and with claude --worktree <name> (-w) in Claude Code; in Cursor, use a git worktree (running agents in isolated worktrees).

This branch is too large to review. Split it into stacked branches off main:
1. Run git diff --stat main...HEAD and group the files into layers: database migration and models, API, then UI.
2. Create feature/orders-db with only the first layer. Run the full test suite there. If it fails, move the missing dependency into this layer rather than skipping tests.
3. Create feature/orders-api on top of feature/orders-db, then feature/orders-ui on top of feature/orders-api, running the tests on each.
4. Keep every branch under 400 changed lines, excluding lockfiles and snapshots. If a layer is still larger, propose a further split and stop.
5. For each branch, print the diff stat, the test result, and a two-line pull request summary that names the branch it depends on.
Do not push and do not delete the original branch.

Let the pipeline, not a reader, decide whether a change ships

Small batches make each change checkable. The gates make the check automatic. A change is ready to merge when four things are true, and none of them requires a human to read every line:

Deterministic checks pass: type check, lint, and the test suite, including new tests that fail on the old code.
The oracle is unchanged, or the change is justified: no deleted, skipped or loosened tests without a stated reason (protecting the oracle).
A review agent found no blocking issue, run against the diff with written review criteria.
The evidence bundle is complete: spec link, acceptance results, risk class and rollout plan, checked by CI (the evidence bundle).

A human approves according to the risk class the bundle declares. Low-risk changes merge on green gates; high-risk ones (authentication, payments, migrations, public API) go to a named owner, who reads the evidence and the flagged hotspots. The six-step triage for agent pull requests defines who reads what.

Before you push, run /code-review in the session to review the branch locally. For a deeper cloud-hosted pass, claude ultrareview runs a multi-agent review of the current branch from the shell and prints the findings; on Pro and Max plans it is billed per run after a few free runs. Teams on Team or Enterprise plans can turn on the managed Code Review (research preview) on GitHub, which reads a repository-root REVIEW.md for review-only instructions. Review automation in Claude Code covers the setup.

Before you push, run codex review --base main for a non-interactive review of the branch, or codex review --uncommitted for work you have not committed yet. On GitHub, commenting @codex review on a pull request asks for a review there. Code review with Codex covers the setup.

To run an agent as a CI job on every pull request, use the hardened setup in headless agents in CI. An agent job that checks out contributor code while an API key is in the environment can run that contributor’s hooks and MCP servers with your secret, so copy that page’s flags rather than writing the job from scratch.

Separate deploy from release with feature flags

Continuous delivery means main is always deployable, not that every merge reaches every user. Put new behaviour from an agent change behind a feature flag, deploy it dark, and expose it to a small share of traffic first. A merged change that turns out to be wrong then costs a flag flip, not a revert under pressure. The blast-radius budget per risk class, the canary analysis and the automatic rollback are on progressive delivery for agent-written changes.

Wrap the new per-client rate limiting in POST /api/orders behind a feature flag named orders-rate-limit, default off.
Use the flag client we already use in src/lib/flags; do not add a new dependency.
Add two tests: one proving the old behaviour with the flag off, and one proving the new behaviour with the flag on.
Add a line to the pull request description under "Rollout" naming the flag, its default, and who may turn it on.
Run the tests and show the output.

Write release notes from the commit range

Commit-per-task history with Conventional Commits is what makes release notes cheap. Give the agent a range and a format rather than “summarise the release”.

Generate release notes for git log v1.1.0..v1.2.0.
Group entries under Breaking changes, Features and Fixes, in that order.
For each entry, write one user-facing sentence (not the raw commit subject) and add the pull request number.
Under Breaking changes, list the migration step a user must take.
Skip chore, ci and test commits. Output Markdown only.
If a commit subject does not follow Conventional Commits, list it under "Unclassified" instead of guessing.

Triage a red build without weakening the tests

An agent is a useful first responder on a failed pipeline, provided the prompt rules out the shortcuts. Left alone, the fastest path to a green check is to skip the test, add a retry, or loosen an assertion.

CI failed on this branch. The log is below.
1. Identify the first real error, not the cascade after it.
2. Classify it: code defect, test defect, flaky test, or CI environment (versions, missing env var, service not ready).
3. For a code defect, fix the code and run the failing test locally to show it passes.
4. For anything else, explain the cause and propose the change, but do not apply it.
Do not skip, delete or loosen any test, and do not add retries. If the only way to green is changing a test, stop and tell me why.

<paste the CI log here>

How do you know continuous delivery is working?

Measure the flow, not the agent’s activity. Track these every sprint, from your Git host and deploy tool rather than from self-reports:

Measure	What it shows	Direction you want
Median changed lines per merged pull request	Whether batches stay small	Flat or down
Share of pull requests with the `size-exception` label	Whether the budget is real	Low, each with a reason
Lead time from first commit to production	Whether small batches actually flow	Down
Change failure rate	Whether speed costs stability	Flat or down
Failed deployment recovery time	Whether flags and rollback work	Down

The last three are DORA’s delivery measures; metrics frameworks defines them precisely and shows how to collect them. The tech lead owns the budget and reviews the exception list each sprint. If lead time falls while the change failure rate rises, the gates are too weak for the volume, which is the pattern the DORA report describes.

What breaks in AI-assisted continuous delivery, and how to recover

The agent commits once at the end anyway. The rule sits in the instruction file but a long session drifts past it. Recovery: keep sessions to one task, and let the size check reject the result; then use the stacked-branch prompt to split it.
The size check becomes a formality. Every large pull request gets the size-exception label. Recovery: require a sentence in the description for each exception and review the list each sprint; if exceptions cluster in one area, the plan’s tasks are too big there.
Green checks, weakened tests. An agent fix passes because an assertion was loosened or a test was skipped. Recovery: add a CI step that fails on removed or skipped tests unless the pull request states why, as described in protecting the oracle.
Stacked branches that do not build on their own. The database layer references a model that only exists in the API layer. Recovery: run the full suite on every branch in the stack before opening any pull request, which the split prompt above requires.
The review agent blocks the merge queue. The review job is a required check and the provider has an outage, so nothing merges. Recovery: give the job a timeout and a documented manual override, and keep the deterministic checks as the only hard gate.
Generated workflow YAML that references things that do not exist. An agent-written workflow pins an old action major, invents a marketplace action, or uses secrets.DEPLOY_KEY that was never set. Recovery: grep the file for every uses: and secrets. reference, pin actions to current majors (actions/checkout@v7 on 2026-09-26), set an explicit permissions: block, and run it once on a throwaway branch.
Passes locally, fails in CI. The agent’s environment differs from the runner: Node version, a missing environment variable, or a service that is not ready. Recovery: pin the runtime in the repository (for example, .node-version), and let the triage prompt classify the failure before anyone changes code.

Where to go next with continuous delivery

The evidence bundle What each agent pull request must prove, and the CI check that enforces it.

Reviewing an agent's pull request The six-step triage that replaces reading every line.

Progressive delivery Flags, canaries and automatic rollback as the net under merged agent changes.

Pipeline automation with AI Change-aware builds, flaky-test triage and progressive deploys in the pipeline itself.

The artifact chain The plan whose tasks become one commit each.

Deploy: gate production The lifecycle stage where review and production gates are wired together.