A Model Upgrade Is a Breaking Change. Treat It as One

Your team depends on a library. A new major version comes out. Nobody on a competent team runs update and ships to production on faith — there is a changelog to read, a test suite to run, a migration to plan. Everyone understands that a dependency change can break things, because that lesson has been paid for many times.

Now the dependency is a model, and every reflex the team built up goes quiet. The provider releases a newer version. It benchmarks higher. Someone updates a version string, or the provider migrates you automatically, and the change reaches production with none of the ceremony a library bump would have triggered. There is no diff to review, because your code did not change. Only the thing your code was built on did.

This is the most under-appreciated risk in shipping AI features, and it comes from a category error: teams treat the model as infrastructure, like a runtime, when it behaves like a dependency, like a library your whole product is compiled against.

Why “Better” Can Be Worse

The trap is that the new model is genuinely better on average, and that average is measured on tasks that are not yours. Public benchmarks reward broad general capability. Your feature cares about one narrow slice of behaviour, on your data, in your format, with your edge cases — and a model can improve on the aggregate while regressing on your slice.

A model that got better at open-ended reasoning may have become more verbose, and now overflows the length limit your summariser depended on. A model with improved “helpfulness” may hedge where yours needed a decisive classification. A model retrained on newer data may have shifted its default assumptions in exactly the domain you rely on. None of that appears in the benchmark score, and none of it appears in a diff, because there is no diff.

The Four Silent Inputs

The model version is the obvious one, and it is only a quarter of the exposure. An AI feature's behaviour is a function of four inputs, and none of them typically passes through code review:

• The model version. Provider-side updates, sometimes on their schedule rather than yours.
• The prompt. A wording change made to fix one case shifts behaviour on a hundred others you were not looking at.
• The retrieved context. The documents fed to the model, and the data underneath them — which drifts as the source changes, with no deployment of any kind on your side.
• The available tools. A change to what the model can call, or to what those tools return, moves the outputs that depend on them.

Anyone versioning only the first two — and most teams version only the prompt — is exposed on the rest. The unifying property is that all four can change the product's behaviour while the application code sits untouched and every conventional signal stays green.

The Guard: A Regression Eval

You already have the instrument, if you built a golden set. A regression eval is simply running that set against the proposed new configuration before it ships, and comparing against the current one.

The comparison has to be case by case, not score against score, because this is exactly where an aggregate number lies to you. Consider a realistic result:

The headline moved from 91% to 93% and every instinct says ship it. But four cases that used to work now fail. If one of them is in your critical subset — a summary that now leaks a name, a classification that now hedges on a safety call — the upgrade is a regression no matter what the average did. Aggregate scores hide this by design, because new passes numerically absorb new failures. Only the case-by-case diff surfaces it.

Making It Scrum Work

The reason model upgrades cause incidents is almost never that the team lacked the skill to test one. It is that the upgrade was never treated as work in the first place — it happened in the gaps, outside the Sprint, as a config tweak nobody sized. The fix is to drag it back inside the framework where the team's existing discipline can reach it.

A model or prompt change is a Product Backlog item. It has acceptance criteria: the regression eval shows no unacceptable losses on the golden set. It gets refined, sized, and forecast like anything else. This alone prevents most upgrade incidents, because it converts an invisible event into a visible one the team has agreed to do.

Provider-forced migrations are a planning input, not a surprise. When a provider announces a deprecation date, that is a known event with a deadline — precisely the kind of thing that belongs on the Product Backlog early rather than arriving as an emergency the week it takes effect. A Scrum Master who surfaces these before they bite is doing impediment removal in its most literal form.

The four inputs get versioned together. If the team cannot say which model version, which prompt, which context source, and which tool set produced the current behaviour, it cannot reason about a change to any of them. This is a working agreement worth making explicit, and it connects directly to the provenance requirement in your Definition of Done.

Where This Sits in the Larger Picture

An upgrade that ships without a regression eval is a textbook generator of verification debt: behaviour changed across the product, nobody verified the change, and the cost arrives later as an incident nobody connects back to a version string that moved weeks ago. The regression eval is what keeps a routine dependency update from silently becoming an unexamined rewrite of how your features behave.

What to Do Next Sprint

1. Write down the four inputs for one live feature: model version, prompt, context source, tool set. If you cannot, that is the first finding.
2. Make the next model or prompt change a Product Backlog item with a regression eval as its acceptance criterion.
3. Run the eval case by case, not score against score. Look specifically at what regressed, and hold the critical subset to zero losses.
4. Check your providers' deprecation schedules and put any forced migration on the Product Backlog now, not the week it lands.