Rolling back a prompt is not the same as rolling back a deploy

An engineering manager at a real estate software company walked me through an incident where the rollback made things worse. Their AI feature started producing bad output, the team followed instinct and rolled back to the previous deploy, and the feature got no better, because the bad behavior had not come from a code deploy. It had come from a prompt change that someone had made through a separate configuration system, one that did not go through the deploy pipeline at all. Rolling back the code reverted a bunch of unrelated changes and left the actual culprit, the prompt, exactly where it was. The team had a rollback button, they pressed it, and it reverted the wrong layer.

Behavior and code stopped being the same thing

For most of software history, a service’s behavior lived in its code, so reverting the code reverted the behavior. Rollback tooling was built on that identity. The last deploy is the last change, so rolling it back undoes the last change, and the behavior returns to what it was. Simple, dependable, and the basis of most incident response.

AI features break the identity between code and behavior. A large part of an AI feature’s behavior lives in the prompt, the model version, and the configuration, and those often change through paths that are separate from code deploys. A prompt gets edited in a config store. The model provider updates the model with no action on your side. A parameter gets tuned in a dashboard. Each of these changes the feature’s behavior without touching the code, which means rolling back the code cannot undo them. When the incident’s cause is one of these, the rollback button reverts a layer that was not the problem, and it can revert legitimate code changes along the way, adding new problems while leaving the real one untouched.

The team’s instinct is not wrong, it is out of date. Roll back the last change is still the right idea. The trouble is that the last change might not be a deploy, and the rollback tooling only knows about deploys. There is a whole category of behavior-affecting changes that the team’s rollback story simply does not cover, so during an incident they reach for the one lever they have, it pulls the wrong layer, and the incident continues while everyone wonders why the rollback did not help.

Give every behavior-changing layer its own rollback

The lesson is that anything which changes an AI feature’s behavior needs to be versioned and revertible, not just the code. If a prompt change can cause an incident, a prompt rollback has to exist, and the team has to know which lever to pull for which kind of change.

What teams do to make AI rollback actually work.

Version prompts and configuration the way you version code, with a history and a way to revert to a known-good state.
Track model versions explicitly, so you can pin a version and roll back to it when a provider update is the cause.
Record every behavior-changing event, prompt edits and config changes included, in one timeline, so the last change is findable regardless of which system made it.
Know which rollback reverts which layer, so on-call does not reach for the code button when the prompt is the problem.
Test that your rollbacks actually restore the prior behavior, since a rollback you have never exercised is a guess.

The goal is that for any change that can break the feature, there is a matching way to undo it, and the team knows which one to reach for. Right now, for many teams, the prompt can break the feature and only the code can be rolled back.

How we think about it at Density Labs

The rollback that reverts the wrong layer is a common and costly surprise during AI incidents. The team has real rollback tooling, it works exactly as designed, and it is designed for a world where behavior equals code. AI features moved a lot of behavior out of the code and into prompts, config, and the model itself, and the rollback story never followed, so during an incident the one lever they have pulls the layer that was not the problem.

When we help a team make an AI feature operable, we make sure every layer that changes behavior can be rolled back, and that the timeline of changes is unified, so on-call can find the last change and revert the right thing. It is a small amount of setup that turns a flailing incident into a clean one.

Rollback assumes the code is the change. For an AI feature, the change is often the prompt, and you can only revert what you versioned.