An LLM feature can regress with no diff

A regression with no commit

The test suite is green. Nobody merged anything this week. And yet the summaries your product writes are longer than they used to be, the classifier sends more tickets to the wrong queue, and the first person to notice is a customer.

Nothing broke in the usual sense. What changed is a dependency you did not think of as one: the model underneath the feature. A model alias such as latest resolves to different weights over time. A provider retires the snapshot you were on and moves you to its successor. Someone adds one sentence to a system prompt to fix an edge case and shifts the behaviour everywhere else. None of it shows up in a diff, and none of it fails a unit test, because unit tests check code and the code did not move.

Why the usual safety net misses it

Most test suites around an LLM call do one of two things. They mock the model, which proves the code handles a canned answer and says nothing about the answers the model actually gives. Or they call the real model and assert something loose enough to pass every time, such as "the response is not empty", which cannot fail when behaviour drifts.

Both leave the same gap: there is no test whose failure means "the model now behaves differently on the inputs we care about". Without that test, drift is discovered the way outages were discovered before monitoring, from the outside, late.

Four habits that close the gap

Treat the model the way you already treat a database driver or a payment SDK.

Pin it. Call a dated model snapshot, never a moving alias, and make changing it a deliberate commit that someone reviews. A pinned version turns "the provider changed something" into "we changed something", which is a change you can test before it ships.

Check the shape of what comes back. If the feature needs a category, a score or a list, ask for structured output and validate it against a schema before using it. Parsing prose with string matching works until the model rephrases, and then it fails silently.

Keep golden tests. Collect a set of real inputs with the outputs you consider correct, and score each new model or prompt version against it. The point is not a perfect score: it is a score that moves when behaviour moves, so a regression shows up in CI instead of in a support queue.

Watch for drift in production. Even pinned, inputs change. Track a few cheap signals over time, such as output length, refusal rate or how often schema validation fails, so a change in the world is noticed as early as a change in the model.

The half most teams skip

Pinning and schemas are easy to adopt because they are code changes. The golden set is the part that gets postponed, because it means sitting down with real examples and deciding what "correct" looks like. It is also the only part that tells you a regression *happened*, rather than making it less likely. A team that pins its model but has no golden set has made upgrades rarer, not safer.

Start small: a handful of real inputs, chosen because they once went wrong or because they matter most, is worth more than a large synthetic set nobody looks at.

Putting it into practice

The AI Model Regression & Behavioral Drift Prevention Rules package these four habits as Cursor rules: one always-on rule for model pinning, and path-scoped rules for output contracts, golden tests and drift detection, so an AI coding assistant follows them where your LLM calls actually live. Its evaluation harness guide covers building the golden set and wiring it into CI.

If your agents also read untrusted content while they work, the related question of instructions hidden in that content is covered in your agent cannot tell instructions from what it reads.