CI/CD for AI: eval gates that catch a bad prompt

TL;DR: Normal CI assumes the same input gives the same answer every time. AI does not work like that. So you put prompts and datasets in Git, score behaviour instead of matching strings, and block a deploy on the score. Start with one golden set and two metrics.

Your build is green. Your prompt still got worse.

That is the whole problem in one line. Normal CI checks that code compiles and functions return the right type. It assumes the same input gives the same answer every time. AI breaks that on day one.

A model can give two different answers, both correct. A test looking for an exact string fails both. So you need a different gate.

What actually changes

Not much, and that surprises people. The shape stays the same: source, build, test, deploy. What changes is what runs through it.

Prompts become code. Datasets become code. Model settings become code. All of it sits in Git with the same review as anything else. If a prompt edit changes what your agent does, it needs a diff someone can read.

GitHub calls the next bit Continuous AI: agent jobs that run in the repo like a CI job, but for work that needs judgement. It runs beside your pipeline. It does not replace it.

Split the work this way:

• Checks with one right answer stay in normal CI. Linting. Type checks. Builds. Dependency scans. No agent needed.
• Checks that need judgement go to an agent. Does this doc match the code? Does this answer match what the user asked?
• Agents get read access by default. They only act, like opening a pull request, when you grant that permission on purpose.
• A person signs off on anything touching money, user data or live content. That stays true until you have enough eval history to trust the gate.

Where eval gates sit

AWS lays this out well for serverless AI. Treat prompts, agent config and model settings as versioned assets. Not as text in a dashboard somewhere.

Here is the shape:

1. Source. Prompts, eval definitions, model config and infra templates live with the code.
2. Build. Package the agent logic and tool definitions with a version tag tied to a commit.
3. Test and score. Run your golden set against the build. Score behaviour. Do not just check it did not crash.
4. Check the infra. Confirm permission limits, rate limits and resources match what you declared.
5. Promote on a number. Staging to production needs a passing score, plus a human for risky changes.
6. Smoke test after deploy. Ten fast queries. Catches what the eval set missed.

The eval file is the piece that changes everything. Once your golden set is versioned like code, you can bisect a regression. A broken string match never gave you that.

How to build a gate that works

Exact matching punishes an AI for being right in a new way. Galileo makes the case for scoring instead, and they are right.

Start with a golden set. Real user traces beat made-up examples every time. Then pick metrics that mean something to your product:

• Made-up answers. How often does the model claim something its tools never said?
• Tool choice. Does the agent pick the right tool, or just a tool?
• Did it follow the brief? Does the output obey the system prompt?
• Speed and cost per run. A right answer that costs ten times more is still a regression.

One run tells you almost nothing. Outputs move around. Run each case a few times and look at the spread, not one sample. That is the difference between a real signal and statistical noise.

Tip: set two thresholds, not one. A hard one that blocks the deploy. A soft one that flags the build for a human. Keep the hard block for safety and cost. Let a person call the rest.

Then keep the same metrics running after you ship. Your test suite becomes a live guard. It catches model drift as it happens, not at the next release. If you want the test-tier detail underneath this, the three tiers for LLM unit testing post covers what to run on a commit, on a PR, and overnight. For getting those tests written in the first place, see AI test generation.

Keeping deploys repeatable

AI behaviour already moves for reasons you do not control. Adding infra drift on top is how a safe prompt change becomes an outage nobody can trace.

AWS treats prompts and model config as real infrastructure, not loose files near the code. Tools like Cloudemon go further and let you declare the whole AI stack, models, agents and eval gates, in one YAML file that plans and applies like Terraform does.

A few calls come up on nearly every build:

• Serverless or containers. Serverless scales well for spiky work but makes long chats harder. Containers give you control over cold starts and cost you more ops time.
• Cheaper models in dev. Run the small model in dev and staging. Save the good one for where accuracy pays.
• Gates per environment. Dev can auto-deploy. A prompt change in production needs sign-off, same as a schema change.
• Hard spend caps. A looping agent turns into a five-figure bill overnight. Rate limits stop that.
• Tenant isolation. Multi-tenant AI needs real data boundaries at the infra layer, not in app code.

Get this right and a rollback is just a redeploy of a known state. Not a scramble to remember what the prompt used to say.

Ship it slowly, on purpose

Sending a new AI feature to all your traffic on day one is a bet you do not need to make.

Canary releases and shadow runs let you compare the new version against the old one on real traffic, without serving its answers to anyone. Feature flags roll a change back for one group in seconds, with no redeploy. That is a five-minute fix instead of a fire drill.

Your telemetry has to go past uptime:

• Quality scores per release version, not just response time
• Confidence scores where the model gives you one
• Prompt lineage, so you can trace any answer back to the exact prompt and model
• Rollback triggers wired to the same eval metric you used before the deploy

GitHub's read-only-by-default pattern helps here too. Every action an agent takes is logged against the permission that allowed it. That matters a lot at 2am when you need to know what the thing actually did. Agent observability and agent guardrails are worth a read if you are wiring this up now.

Tip: wire the rollback trigger to the same score as the gate. Two different quality metrics means an argument about which one is right, at the exact moment you need to move fast.

Four things you can try this week

You do not need a platform team to start.

1. A one-command deploy CLI. agentdeploy shows the minimal shape: init, dev, deploy, with session handling, tool sandboxing and spend caps built in. Useful even if you build your own, because it shows which guards belong at the CLI and which belong in the pipeline.
2. An AI config file. One `aiinfra.yaml` listing models, agents and gates means a new hire reads the whole stack in five minutes. Environment changes become a diff, not a Slack thread.
3. Eval gates in the CI you already have. A GitHub Actions job that runs your golden set and fails below a threshold. No new system needed.
4. A smarter merge queue. AI coding tools ship far more commits than a human team. More of those clashes are logic clashes, not text clashes. A queue that checks for logic overlap plus a fast post-merge smoke test catches what a normal merge check misses.

None of this is a rebuild. It is deciding which parts of your CI are fine and which parts need an AI-native version.

Do you need a dedicated pipeline?

Probably not on day one. Building one early just adds upkeep nobody asked for.

Three questions decide it. How often do prompts or models change? How directly does a bad answer reach a user? What happens if a regulator asks?

Prompts change weekly and answers go straight to customers? You need gating now. Model updates quarterly behind a human reviewer? A light eval step in your normal CI will hold for a year.

A first eval suite does not need to be big. A golden set of real cases, two or three metrics that matter, one hard threshold on safety or cost. That catches most of what would otherwise slip through quietly.

Here's the thing. The hard part is not the pipeline. It is designing the golden set, and that is a specific skill. Getting it wrong the first time costs more than help would have.

Where this lands in a real build

The same discipline runs through every AI build: version the prompts, gate every promotion on a score, define the infra so a rollback is a known state.

Multi-tenant platforms make the isolation question harder. Our work turning a vibe-coded MVP into a multi-tenant white-label AI SaaS is a good reference for that: tenant isolation at the database layer and tenant-level billing, designed in from the start rather than bolted on after the first billing complaint.

If you want the academic framing, the AI-Augmented CI/CD Pipelines paper covers agents working inside the pipeline. For the build side, how to build AI agents is the plainer starting point. And if you are still mapping the stages, our software delivery process post covers the parts that have nothing to do with AI.

We build custom AI platforms, agents, and the pipelines under them, gates included. Worth a chat if you are deciding whether to extend your CI or build something dedicated. Bring three things: how often your prompts change, what a bad answer looks like for your users, and whether you have any history an eval set could learn from. Start with AI app development.

Frequently asked questions

How can AI be used in CI/CD?

Agents can review pull requests, spot docs that no longer match the code, triage issues and write reports, all running beside your normal CI. The other half matters too: AI features themselves need eval gates in the pipeline to catch behaviour going backwards before it ships.

What is CI and CD in AI?

Continuous integration for AI means testing code, prompts, models and datasets together, using eval suites instead of exact-match tests. Continuous deployment means a build only goes live once it clears a behaviour threshold, with rollback tied to the same number.

Is AI replacing DevOps?

No. AI takes on the judgement work like triage and drift detection. Builds, linting and dependency scans still run through normal CI. Agent workflows run beside your pipeline, not instead of it.

What should we build first?

A small golden set of real cases and one or two metrics tied to a hard deploy threshold. Build it before an incident, not after. Most teams get this wrong by waiting.

How is testing AI agents different?

Normal testing checks for one fixed correct answer. Agent testing checks whether a changing answer stays inside an acceptable range across several runs. That is why you score behaviour instead of matching strings.