CI/CD for LLM Applications: Shipping Changes Without Breaking Production

If you ship changes to an LLM application, the non-determinism breaks the assumptions your CI/CD was built on, because the pipeline expects deterministic tests and the LLM application does not provide them, which means shipping changes safely requires adapting the pipeline to evaluate a non-deterministic system rather than test a deterministic one. The change that a traditional pipeline would clear or block on a deterministic test signal needs a different kind of validation for an LLM application, one that assesses the probabilistic behaviour rather than checking a binary pass. Building CI/CD that fits the LLM application, evaluating rather than testing, is what lets you ship changes without breaking production.

Why traditional CI/CD does not fit

Traditional CI/CD depends on deterministic tests: a test passes, produces a definite pass or fail, and the pipeline uses that signal to decide whether the change is safe to ship, which works because the system under test behaves deterministically, so the same test gives the same result and a pass means the behaviour is correct. An LLM application does not behave deterministically, which means the same test can pass or fail on different passes, and a single pass does not mean the behaviour is reliably correct, only that it was correct this time. The deterministic pass-or-fail signal that traditional CI/CD depends on does not exist for an LLM application, which breaks the pipeline’s core mechanism.

This matters because a change to an LLM application can regress its behaviour in ways a single test pass does not catch, and the traditional pipeline that ships on a single deterministic pass would ship a regression that happened to pass its one test pass. A prompt change that improves some cases and regresses others, a model change that shifts behaviour across the distribution, a modification whose effect is probabilistic, these are the changes that a deterministic pass-or-fail test cannot properly assess, because the change’s effect is on the distribution of behaviour, not on a single deterministic outcome. Traditional CI/CD does not fit because it validates changes through deterministic tests, and an LLM application’s changes affect a non-deterministic distribution that deterministic tests cannot properly validate, which means shipping LLM changes safely requires a different validation than the traditional pipeline provides.

Adapting the pipeline to non-determinism

Adapting CI/CD to LLM applications means replacing the deterministic test with evaluation of the non-deterministic behaviour, using the evaluation harness as the pipeline’s validation rather than deterministic tests. On every change, the pipeline operates the evaluation, scoring the changed system’s behaviour against the golden dataset to produce a quality signal, and uses that signal to decide whether the change is safe to ship, which is the evaluation-on-every-change that catches regression before it reaches production. The evaluation replaces the deterministic test as the pipeline’s gate, assessing the probabilistic behaviour the change affects rather than checking a single deterministic outcome.

The evaluation gate works differently from a deterministic test, because it produces a quality signal over a distribution rather than a binary pass, which means the pipeline’s decision is based on whether the evaluation shows the change maintaining or improving quality rather than on a single pass-or-fail. A change that regresses the quality score is caught and blocked, and a change that maintains or improves it ships, and this is the regression detection that lets a team ship LLM changes with confidence, because the evaluation catches the regression a change would introduce before it ships. The pipeline also has to version the prompts and configuration that determine the LLM application’s behaviour, treating a prompt change as a deployment that goes through the evaluation gate, because the prompt is a primary determinant of behaviour and a prompt change needs the same validation as a code change. Adapting CI/CD to the LLM application means evaluating changes against the behaviour distribution, versioning the prompts that drive behaviour, and gating on the quality signal, which is what fits the pipeline to a non-deterministic system.

The trade-off, and the residual non-determinism

The adapted pipeline costs more than traditional CI/CD, and naming that cost keeps it justified. The evaluation gate consumes compute, often model compute, to operate the evaluation on every change, more than operating deterministic tests, and it requires maintaining the golden dataset the evaluation operates against, which is ongoing work. This cost is the cost of validating changes to a non-deterministic system properly, and it is justified because the alternative, shipping LLM changes without proper evaluation, ships the regressions that a deterministic test or a manual check would miss, which surface in production as the failures the pipeline was supposed to catch.

The residual non-determinism is a nuance the adapted pipeline has to account for, because even with evaluation, the LLM application’s behaviour is a distribution, which means the evaluation gives a quality estimate rather than a guarantee, and a change that passes the evaluation gate can still behave differently in production than in evaluation. This is why the CI/CD gate is necessary and not sufficient, and why it pairs with the continuous evaluation and monitoring in production that catch the behaviour the pre-ship evaluation did not, the production monitoring that watches the shipped change’s actual behaviour. The adapted pipeline shifts more of the validation into production monitoring than a deterministic system needs, because the pre-ship evaluation cannot fully predict the non-deterministic production behaviour, which means shipping LLM changes safely is a combination of the evaluation gate before shipping and the monitoring after, not the pre-ship gate alone. Accounting for the residual non-determinism, by pairing the CI/CD gate with production monitoring, is what makes shipping LLM changes actually safe.

Where it almost broke

We shipped changes to an LLM application through a pipeline adapted from traditional CI/CD, which validated changes through tests that gave a pass-or-fail signal, and a change shipped that had passed its tests and yet regressed the application’s behaviour in production, because the tests had checked a deterministic outcome that happened to pass while the change had degraded the probabilistic behaviour across cases the single test pass did not cover. The deterministic-test pipeline had cleared a change that regressed the non-deterministic behaviour, because the pass-or-fail test could not assess the distribution of behaviour the change actually affected.

The correction adapted the pipeline to the non-determinism. We replaced the deterministic tests with evaluation against the golden dataset on every change, gating on the quality signal the evaluation produced rather than a pass-or-fail, so a change that regressed the quality was caught and blocked before shipping. We versioned the prompts that drove the application’s behaviour, treating prompt changes as deployments through the evaluation gate. And we paired the pre-ship evaluation with production monitoring, so the residual non-determinism that the pre-ship evaluation could not fully predict was caught by the monitoring of the shipped change’s actual behaviour. Changes started shipping without the regressions the deterministic-test pipeline had let through, because the pipeline now evaluated the probabilistic behaviour and monitored it after shipping. The lesson was that traditional CI/CD’s deterministic tests do not fit an LLM application, and adapting the pipeline to evaluate the non-deterministic behaviour and monitor it in production is what ships changes without breaking production.

Evaluate the change, monitor the deployment

The reframe that makes shipping LLM changes safe is adapting CI/CD to validate a non-deterministic system through evaluation rather than deterministic tests, and pairing the pre-ship evaluation with production monitoring. CI/CD for LLM applications replaces the pass-or-fail test with an evaluation gate that assesses the probabilistic behaviour a change affects, versions the prompts that drive behaviour, and accounts for the residual non-determinism by monitoring the shipped change in production. The traditional pipeline built for deterministic tests ships the regressions that a non-deterministic system’s behaviour hides from a single test pass.

The teams that ship LLM changes without breaking production are the ones that adapted the pipeline to the non-determinism, evaluated changes against the golden dataset on every change, gated on the quality signal, and monitored the shipped changes in production to catch what the pre-ship evaluation could not predict. Deterministic tests do not fit a system whose correctness is a distribution, and shipping on a single test pass ships the regressions that pass happened to miss. Evaluating the change before shipping and monitoring the deployment after is what fits CI/CD to an LLM application, which is what lets a team ship changes to a non-deterministic system without breaking production.