Never surprise with change

AI products have a change problem no traditional software had: the product’s behavior is the product. When a spreadsheet app redesigns its toolbar, your formulas still work. When an AI product swaps models or retunes a system prompt, everything downstream shifts — tone, refusal boundaries, formatting habits, the prompts a person spent weeks calibrating. And because every AI answer already varies, users experiencing a silent change can’t distinguish “the product changed” from “I got unlucky.” That ambiguity is corrosive in a way an honest breaking change never is.

The field has run this experiment publicly. Every major model transition — OpenAI’s GPT-4 to GPT-5 among them — produced waves of users insisting the product got worse, lost its personality, or stopped understanding them, loudly enough that companies restored access to older models. The lesson is not that the new models were worse; it’s that behavior is an interface, and changing an interface underneath people without acknowledgment reads as gaslighting even when the change is an upgrade.

The remedies are ordinary release craft, applied to behavior. Announce behavioral changes in-product, in behavioral terms — “responses will be more concise by default” — not as a version number in a changelog nobody reads. Give people a bridge: model pickers that keep the previous option available for a transition window, as ChatGPT does, convert a forced migration into a choice. And pin what people have customized: explicit instructions, saved preferences, and legible memories should survive an upgrade untouched, because those are promises the product made, not parameters it may retune.

Continuity also lives at the session scale. A long-running conversation that hits a context limit and silently forgets its first half is a shape-shift mid-relationship — the person is talking to something that no longer knows what they know it was told. Products handle this well by making continuity explicit: summarizing what’s carried forward, or surfacing persistent memory so the relationship visibly outlives any single session’s window. Losing context is sometimes unavoidable; losing it silently never is.

None of this argues for freezing the product. It argues for treating behavioral stability as part of the contract from Principle 1: what the system can do includes how it characteristically does it. Ship improvements relentlessly — but ship them the way you’d change anything people depend on: announced, bridged, and with the person’s accumulated investment carried across. The products that compound trust over years are not the ones that never changed; they’re the ones that never made anyone feel the ground move without warning.

The counter-case is operational and it is not weak. Frontier products ship model updates weekly; announcing every behavioral shift would bury users in changelogs nobody reads, and change-notice fatigue is as real as the silent-change problem. Bridges are brutally expensive — keeping legacy models available means running old inference fleets, supporting old safety profiles, and splitting your eval surface, which is why every provider eventually sunsets them. There’s a competitive argument too: in a field moving this fast, the team that spends a quarter building migration ceremony gets lapped by the team that just ships the better model, and most users genuinely don’t notice most changes — announcing them manufactures anxiety about diffs that would have passed silently. All true at the margins, and none of it excuses the center. The discipline isn’t “announce everything”; it’s “know which behaviors people have built on, and never move those silently.” Tone, refusal boundaries, formatting defaults, and anything a user explicitly customized are load-bearing walls. Repaint the rooms weekly; announce it when you move a wall.

The tell is in the noise after a release. Instrument behavioral-change complaints — “it got worse,” “it doesn’t sound like itself,” “it used to do this” — as their own ticket category and plot them against your deploy calendar; silent shape-shifts show up as spikes users can’t attribute, and a well-bridged release shows the same underlying change with a fraction of the noise. Run behavioral regression evals before every swap: replay a corpus of real user prompts (especially those tied to saved instructions and memories) against old and new, and score the drift on tone, format, and refusal boundaries — customized-behavior drift should be near zero even when general behavior improves. In production, watch legacy-model selection: a healthy bridge shows old-model usage decaying naturally over the transition window; usage that plateaus means the new default broke something real, and you just learned it from a dashboard instead of a churn report. Good looks like week-four retention through a major model transition matching the weeks around it. Ship a transition nobody can find in your retention curve and you’ve honored the principle.