How to Set Up CI/CD With AI

Playbook

CI/CD is the machinery that runs your tests on every change and, when they pass, ships the code — so you stop deploying by hand at 11pm and hoping. It's also exactly the kind of config-heavy, YAML-shaped work that AI drafts quickly and where a small mistake stays hidden until it bites. The right model is a partnership: the agent writes the pipeline, you approve every stage, and nothing runs unchecked against your real repo or your real server. A pipeline is a robot with the keys to your production system; you review before you hand over the keys.

Step 1: Understand the three stages you're building

Before the agent writes anything, know the shape of what you're asking for. Almost every pipeline is three stages, and naming them keeps the agent honest.

• CI (test gate). On every push or pull request: install dependencies, build, run the test suite, and run any linters. This is the gate — if it's red, nothing proceeds. This stage alone is worth setting up even if you deploy by hand, because it catches broken code before it merges.
• Build. Produce the deployable artifact — a compiled binary, a container image, a bundled front end — once, cleanly, from the passing code.
• CD (deploy). Push that artifact to your environment. This is the stage that touches production, so it's the one that gets the most human control.

Step 2: Start with the test gate, and start small

Build the CI stage first and get it green before you automate any deployment. There's no point auto-shipping code you haven't gated on tests. Ask the agent for a minimal pipeline: check out the code, install, build, run tests, report pass or fail. Get that running on a real push and watch it work. A small pipeline that actually runs beats an elaborate one that half-works and that nobody understands well enough to fix. You can add stages later; you can't debug a sprawling pipeline you never understood in the first place.

Step 3: Have the agent draft, then read every stage

This is where the agent shines — pipeline config is fiddly, full of exact syntax and provider-specific keys it knows well. But you read the whole thing before it runs, because a pipeline mistake plays out against your real infrastructure. Here's the prompt we use:

Draft a CI/CD pipeline for <your CI provider> for a <stack> app.
Build it in reviewable stages, and explain what each does.

CI (runs on every push and PR):
- install deps, build, run the full test suite, run the linter.
- Fail the whole run if any of these fail. This is the gate.

BUILD:
- produce the deployable artifact from the passing code.

CD (deploy) — DRAFT ONLY, do not auto-enable:
- deploy the artifact to <target>.
- Require a MANUAL approval step before it runs.
- Include the rollback command as a comment.

Do not put any secrets in the file — reference them as secret
variables. Show me the config so I can review it before I
commit or run anything.

Step 4: Keep the human in the deploy loop

The core rule: the agent can draft the whole pipeline, and CI can run automatically, but the actual deploy to production waits for a human. Configure the CD stage with a manual approval gate — the pipeline goes green, then a person clicks "deploy." This is the difference between automation you control and automation that surprises you. Fully automated deploy-on-merge is a fine goal later, once the test gate is genuinely trustworthy and you've watched the pipeline behave for a while. Early on, a human presses the final button. Don't let a pipeline you just wrote ship to production unattended because it "looked right."

Step 5: Handle secrets correctly, from the start

Pipelines need credentials — deploy keys, registry logins, API tokens — and they must live in your CI provider's encrypted secrets store, referenced by name, never pasted into the YAML. This is the mistake to catch in review every single time: an agent that inlines a token "to test it" has just leaked a credential into your git history the moment you commit. Scan the config for anything that looks like a real secret before it's committed. A pipeline config is a public-ish file in your repo; treat it like one.

Step 6: Make the gate actually mean something

A green pipeline is only as honest as the checks behind it. If your test suite is thin, "CI passed" tells you the code ran, not that it works — and now you've automated shipping code that nobody meaningfully verified. So invest in the gate: make sure the tests that run actually cover the behavior that matters, and that the pipeline genuinely fails when they fail (an agent will occasionally write a step that swallows errors and reports success — check for that). The whole value of CI/CD is that green is trustworthy. A gate that's green no matter what is worse than no gate, because it manufactures false confidence.

Step 7: Test the pipeline by breaking it on purpose

Before you rely on it, prove the gate works. Push a change that intentionally breaks a test and confirm the pipeline goes red and blocks the deploy. Then push a passing change and confirm it proceeds. If a broken test sails through green, your gate is decorative and you've found that out safely instead of in production. This one deliberate-failure test is what earns you the right to trust the green checkmark.

CI/CD done right turns deployment from a nerve-wracking manual ritual into a boring, gated, repeatable step — with a human on the final trigger until the gate has earned full autonomy. The deploy stage here builds directly on deploying with AI, and for choosing the right model to draft your infrastructure config, the best AI for DevOps covers who to hand it to.