Continuous Delivery with AI Assistance

You spent four hours building a feature in a single AI session. The diff is 1,200 lines across 18 files. You open a PR, and the reviewer’s first comment is “Can you break this into smaller PRs?” You cannot, because the changes are tangled together. The tests pass locally but fail in CI because you forgot to add the new environment variable. Now you are debugging CI while your feature sits in review limbo.

Continuous delivery is the antidote to big-bang feature branches. The principle is simple: ship small, verified changes as frequently as possible. AI makes this easier, not harder, because it can automate the repetitive parts of the delivery pipeline — writing commit messages, generating PR descriptions, running pre-merge checks, and even splitting large changes into reviewable chunks.

What You’ll Walk Away With

• A workflow for committing and shipping AI-generated changes incrementally
• Prompts for automated commit messages, PR descriptions, and changelog entries
• Strategies for integrating AI into your CI/CD pipeline
• Techniques for splitting large AI-generated diffs into reviewable PRs

The Incremental Commit Discipline

The single most impactful habit for continuous delivery with AI: commit after every successful task, not after the entire feature. If you are following the PRD-Plan-Todo methodology, each todo item should result in one commit.

Cursor

After each completed task, ask Cursor to commit with a meaningful message:

The rate limiter implementation passes all tests. Commit this change
with a descriptive commit message following our conventional commits
format (feat/fix/chore). Include what changed and why.

Cursor can run git add and git commit directly from Agent mode. For even faster flow, enable the Background Agent to handle commits while you move to the next task.

Claude Code

Claude Code excels at git workflows. After each task:

All tests pass. Commit this change with a conventional commit message.
Stage only the files related to the rate limiter task. Do not stage
unrelated changes.

For headless CI integration, Claude Code can commit automatically:

claude -p "Run the linter and tests. If they pass, commit with a descriptive message."

Claude Code also supports hooks that can auto-format code before every commit, ensuring consistent style without manual intervention.

Codex

Codex can commit and even create PRs directly:

All tests pass for the rate limiter. Commit the changes with a
conventional commit message. Then create a draft PR with a
summary of what changed and how to test it.

Codex’s GitHub integration shines here. From the App, you can push a commit, create a PR, and even request reviews in a single prompt. Cloud threads can handle the PR creation while you continue working locally.

Copy-paste prompt: Commit and verify

I've completed [TASK DESCRIPTION]. Before committing:

1. Run the linter (npm run lint)
2. Run the type checker (npm run type-check)
3. Run relevant tests (npm test -- --testPathPattern=[PATTERN])
4. If all pass, stage only the relevant files (not node_modules, .env, etc.)
5. Commit with a conventional commit message: type(scope): description
6. Show me the commit hash and summary

Do not push yet. I want to review the commit before pushing.

Automating PR Creation

Pull requests are where code review happens. The faster you can create a well-documented PR, the faster your code gets reviewed and merged. AI can generate PR descriptions that actually help reviewers understand the change.

Cursor

After pushing your branch, ask Cursor to create the PR:

Push the current branch and create a PR against main.

For the PR description:
1. Summarize what this PR does and why
2. List the key files changed with a brief explanation of each
3. Include testing instructions
4. Mention any deployment considerations (new env vars, migrations)

Use our PR template format.

Cursor can use the gh CLI to create PRs directly from Agent mode.

Claude Code

Claude Code’s PR workflow is battle-tested:

Push this branch and create a PR against main using gh.

Write the PR description covering:
- Summary of changes
- Key decisions and trade-offs
- Testing done (include test output)
- Deployment notes (migrations, env vars, feature flags)

Use conventional PR title format.

For CI integration, Claude Code can run in headless mode as part of your pipeline:

claude -p "Review the current diff against main. Generate a PR description." --output-format json

Codex

Codex has native GitHub integration for PR workflows:

Create a pull request for the current branch against main.

Include:
- Summary of what changed and why
- Files changed with explanations
- Test coverage information
- Any breaking changes or deployment requirements

Add relevant labels and request review from the team.

Codex can also be triggered from Slack or Linear to create PRs from issue descriptions, closing the loop between project management and code delivery.

Copy-paste prompt: PR description generator

Generate a PR description for the current branch. Run git diff main...HEAD
to see all changes. Structure the description as:

## Summary
[1-2 sentence overview of the change]

## Changes
[Bulleted list of key changes with file names]

## Testing
[How this was tested, include relevant test commands]

## Deployment
[Any deployment considerations: new env vars, migrations, feature flags]

## Screenshots
[If UI changes, note that screenshots should be added]

Splitting Large Changes

Sometimes an AI session produces a large change that should be multiple PRs. Instead of trying to untangle the git history manually, ask the AI to help you split it.

Cursor

The current branch has changes across the database layer, API layer,
and frontend. Help me split this into three separate PRs that can
be reviewed and merged independently:

1. PR 1: Database migration and model changes
2. PR 2: API endpoint changes (depends on PR 1)
3. PR 3: Frontend changes (depends on PR 2)

Create a new branch for PR 1 with only the database changes.

Claude Code

The current diff is too large for a single PR. Help me split it:

1. Run git diff --stat to see all changed files
2. Group files by layer (db, api, frontend)
3. Create branch feature/rate-limiter-db with only database changes
4. Create branch feature/rate-limiter-api with API changes
5. Create branch feature/rate-limiter-ui with frontend changes

Each branch should be independently testable. Start with the
database branch.

Codex

The diff on this branch is too large. Split it into stacked PRs:

1. Database layer changes (first to merge)
2. API layer changes (stacks on database PR)
3. Frontend changes (stacks on API PR)

Create separate branches for each. Make sure each branch's tests
pass independently. Create draft PRs with dependencies noted.

Codex’s worktree support makes this particularly smooth — each PR can be developed and tested in its own worktree without branch switching.

CI Pipeline Integration

AI is not just for writing code. It can help you maintain and debug your CI pipeline itself.

Copy-paste prompt: Debug a failing CI pipeline

Our CI pipeline failed on this PR. Here is the error output:
[paste CI log]

1. Identify the root cause of the failure
2. Determine if this is a code issue or a CI configuration issue
3. If code: fix it and push
4. If CI config: explain what needs to change in the pipeline
5. If flaky test: identify why it's flaky and propose a fix

Do not skip failing tests or add retry logic as a band-aid.

When This Breaks

Commits are too granular. Committing after every single line change creates noise. The right granularity is one logical change per commit — a single todo item, a bug fix, a refactor. If the commit message requires “and” to describe what changed, it is probably too big.

PRs are auto-merged without review. AI can create PRs fast, but speed is not a substitute for human review. Every PR should be reviewed by a human before merging to production. Use draft PRs for work-in-progress.

CI passes locally but fails in CI. The most common cause is environment differences. Ensure your CI environment matches your local setup (Node version, env vars, database state). Add a “CI environment check” step to your pipeline.

The AI generates incorrect commit messages. AI-generated commit messages can be too vague (“update files”) or too verbose. Include your team’s commit message conventions in your project’s CLAUDE.md, .cursor/rules, or AGENTS.md so the AI follows your format.

What’s Next

PRD to Plan to Todo The planning methodology that produces clean, incremental task lists for continuous delivery.

Human in the Loop How to review AI-generated PRs effectively without becoming a bottleneck.

Cost per Context Understand the cost implications of running AI in your CI pipeline.