Writing Prompts That Survive a Model Upgrade

The upgrade you didn't ask for

At some point every prompt gets run against a model it wasn't written for. The provider ships a new version, the API defaults change, or someone swaps in a cheaper model to save cost. The prompt that used to work reliably now produces subtly wrong output, or worse, confidently wrong output that passes casual inspection. This is not a rare event. It is the normal lifecycle of any prompt that lives in production for more than a few months.

The instinct when a prompt breaks is to patch it: add another example, tighten the wording, insert a magic phrase that happened to nudge the old model into good behaviour. This works in the short term and creates a fragile artefact in the long term. The prompt accumulates model-specific superstition, the kind of thing that reads like folklore rather than instruction. I have seen prompts with lines that exist purely because someone once observed a particular model behaving oddly without that phrase, and nobody remembers why it is there or whether it still matters.

The alternative is to treat prompt writing the way I would treat feature engineering or evaluation design: assume the underlying system will change, and build for that assumption rather than against it. A prompt that survives an upgrade is not the most clever one, it is the one that depends least on the specific quirks of the model it was written on. Robustness over cleverness is not a slogan, it is a design constraint that changes how you write instructions.

Why clever prompts are fragile by construction

Clever prompts often work by exploiting something incidental about a model's training or tuning rather than something general about the task. A common example is over-specifying format through trick delimiters, unusual token sequences, or role-play framings that happen to trigger a particular behaviour in one model's instruction-following layer. These tricks work because the model has learned specific associations during fine-tuning, not because the instruction is genuinely clearer to a general-purpose language understander.

Consider a prompt that asks a model to output strict JSON by threatening consequences if it fails, or by wrapping the instruction in an elaborate persona ('you are a meticulous JSON compiler that never makes mistakes'). On an older, weaker model this framing might reliably improve compliance because the model was tuned on data where such framings correlated with careful output. On a newer model that already has strong native structured-output support, the same framing can do nothing useful and occasionally backfires, because the persona instruction competes with the model's own default formatting behaviour, producing extra commentary or malformed nesting that the older model never produced.

The deeper issue is that clever prompts are usually optimised against a small, informal sample of outputs you happened to look at. You tried three phrasings, one looked best on five test cases, and you shipped it. That is not evaluation, that is anecdote. The phrasing that won might have won by chance, or it might have won because it exploited a specific failure mode of that model version that a new version has already fixed or introduced differently. Without a proper held-out test set and without tracking which model version produced which result, you cannot tell the difference between a genuinely better instruction and a lucky one.

A worked example: extracting structured data

Suppose the task is extracting a customer's requested refund amount from a support email, returning it as a plain number. A clever prompt might read: 'You are an expert financial auditor. Extract the exact refund amount. Think step by step, then output ONLY the number, nothing else, or you will fail this task.' This works well on the model it was tuned against, scoring perhaps ninety-four correct extractions out of one hundred test emails.

A robust version of the same prompt separates three concerns that the clever version tangles together: the task definition, the output contract, and the edge case handling. It might read: 'Extract the refund amount mentioned in the email below. Respond with only the numeric value, using a full stop as the decimal separator and no currency symbol. If no refund amount is mentioned, respond with the word none.' No persona, no threats, no chain-of-thought instruction bundled in with the format constraint.

When you swap models, the clever prompt's score can drop sharply, say from ninety-four to seventy-eight out of one hundred, because the new model does not respond to the same social pressure and instead adds explanatory text before the number, breaking any downstream parser expecting a bare value. The robust prompt tends to hold closer to its original score, say ninety-one, because its instructions describe the task and the contract in terms that do not depend on a specific model's tuned response to persona framing or urgency. The gap between ninety-four and seventy-eight is the hidden cost of cleverness; the gap between ninety-four and ninety-one is the acceptable cost of change.

The practical lesson is not that personas or emphatic phrasing never help. It is that any technique whose benefit you cannot explain in terms of the task itself, only in terms of 'this seemed to make the model behave', should be treated as a liability that needs re-testing on every model swap, not as a permanent fixture.

Building prompts that are meant to be re-tested

The practical habit that follows from all this is to keep a small, fixed evaluation set for every prompt that matters, separate from the examples used to write the prompt in the first place. This is the same leakage discipline that applies to any model evaluation: if the same handful of cases both shaped your prompt and measured its success, your score tells you almost nothing about how the prompt will behave on new inputs, let alone a new model. Ten to twenty realistic, varied cases with known correct answers is enough to catch most regressions, and it costs little to maintain.

When an upgrade happens, rerun that fixed set before touching the prompt. If the score holds, you are done. If it drops, look at the specific failures rather than reflexively adding more instructions; often the fix is removing a brittle clause rather than adding a new one. Keep a short log of which prompt version and which model version produced which score, because without that record you will eventually be debugging a regression with no memory of what changed.

Finally, prefer instructions that describe the task in plain terms over instructions that describe a persona or an emotional stake. State the format contract explicitly and separately from the task description, and test edge cases like empty input, ambiguous input, and multiple valid answers, since these are exactly where model-specific behaviour diverges most after an upgrade. A prompt that reads like a clear specification rather than a spell will not be the most impressive thing in the room, but it will still be working next quarter, which is the only property that actually matters.