How do you write prompts that survive a model upgrade?

Why does my prompt stop working after a model upgrade?

Because most of what made it work was compensation for the old model's quirks. Once the quirk is gone, the workaround is noise, and noise changes behaviour. A prompt built on what you actually want survives. A prompt built on what you had to do to get it does not.

I run a lot of content work through models, and the upgrades that hurt were never the ones that made the model worse. They were the ones where the model stopped needing the scaffolding I had bolted on, and the scaffolding started actively misleading it.

So this is about which parts of a prompt are load bearing and which parts are scar tissue.

What does a model upgrade actually change?

More than people assume, and vendors say so directly. Anthropic's prompting documentation lists behavioural differences between generations explicitly, naming things like effort levels, how the model finishes long tasks, how thinking blocks should be passed back, tool call batching in agent loops, formatting and writing density.

Read that list again as an engineer rather than a user. Those are not cosmetic differences. Tool call batching changes the shape of an agent loop. Writing density changes output length. Any prompt that was tuned around the old behaviour of those things is now tuned around something that no longer exists.

The same documentation makes the scope of this clear by naming the models it covers as current, a list that in Anthropic's own words includes Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 5, Claude Sonnet 4.6 and Claude Haiku 4.5. That is a lot of concurrent versions, which means "the model" was never a single stable target.

Which parts of a prompt are durable?

The parts that describe the task, the audience, the constraints and what a good output looks like. Those are facts about your work, not facts about the model, and no upgrade can invalidate them.

A clear statement of the job survives everything. So does a list of things that must never appear in the output, and so does a worked example of a correct result. Those three carry most of the weight in every prompt I have that has lasted more than a few months.

Structure is durable too. Anthropic's own overview names XML structuring, role prompting, thinking and prompt chaining among its techniques, and structural choices like those tend to keep working because they are about organising information rather than about steering a specific model's habits.

Which parts are fragile?

Anything phrased as a correction. "Do not be verbose." "Stop apologising." "Actually follow the format this time." Each of those is a fingerprint of a behaviour you were fighting, and when the behaviour goes the instruction becomes a strange demand about nothing.

Threats and emphasis are the same category. Capital letters, repeated instructions, and increasingly desperate phrasing are all evidence that a previous model was ignoring something. They are rarely harmful, but they are dead weight, and they make the prompt hard to read when you need to debug it.

The most fragile thing of all is a hard coded workaround for a formatting bug. If half your prompt exists to stop one specific malformation, that half will be wrong the moment the malformation stops. Those sections need a comment explaining why they exist, so a future version of you can safely delete them.

Why do you need evaluations before you need a better prompt?

Because without them you cannot tell an upgrade from a regression. Anthropic's documentation is direct about this, stating that its prompt engineering guide assumes you have a clear definition of success criteria for your use case and some way to test against them empirically, and saying that if you do not, you should spend time establishing that first.

That is the most ignored instruction in the whole field. Almost everybody starts with the prompt, because writing prompts feels productive and writing tests does not. Then the model changes and there is no way to answer the only question that matters, which is whether the output got better or worse.

An evaluation does not have to be sophisticated. Twenty saved inputs and a written description of what a good answer looks like is enough to make an upgrade a measurable event rather than a feeling. I hold my own published work to a similar standard, which is why I check every factual claim against a source rather than trusting fluent output, something I have written about in why I verify every fact before publishing.

How should you structure a prompt so it can be repaired?

Separate the durable from the disposable, visibly. Task, audience, constraints and examples in one block. Model specific adjustments in another, clearly labelled as such.

That single change makes upgrades tractable. When a new version lands, you do not reread a wall of instructions trying to guess what still applies. You read the labelled block, delete what was fixing a problem that no longer exists, and test.

Version the thing as well. A prompt is code, it has behaviour, and it deserves the same treatment as anything else you would be upset to lose. If you cannot answer what changed between the version that worked and the version that does not, you are debugging blind.

What does the vendor documentation actually tell you to do?

Read the page for your specific model before the general advice. Anthropic states that each of the models it lists has its own prompting page, and that you should read the one for your model first, then the techniques that follow.

Its documentation is organised the same way, which is a useful signal in itself. Anthropic describes the page as being in three parts: model specific differences first, techniques that apply to all current models next, and migration guidance last, for prompts moving from earlier generations.

The practical implication is that migration is a documented activity rather than something you improvise. If a vendor has written a migration section, the correct first move after an upgrade is to read it, not to start tweaking adjectives.

How do you test an upgrade without breaking production?

Run both models against the same inputs and compare the outputs side by side before you switch anything. This is the cheapest insurance available and it takes an afternoon.

What you are looking for is not which output you prefer. It is where they differ systematically. If the new model consistently produces shorter output, that is a formatting decision you now need to make deliberately rather than discover in front of a client.

Then roll forward on the least critical job first. The work where a bad output costs you nothing is where you learn the new model's habits. Quality drift is easier to catch when you have somewhere safe to watch for it, and I have written about spotting it in what to do when an AI agent's output quality drifts.

When is the right answer a different model rather than a better prompt?

More often than prompt enthusiasts like to admit, and the vendor says so. Anthropic's overview states plainly that not every success criterion or failing evaluation is best solved by prompt engineering, and gives the example that latency and cost can sometimes be improved more easily by selecting a different model.

That is a genuinely useful piece of honesty from a company that sells prompting guidance. If your problem is speed or cost, rewriting instructions is the expensive path. If your problem is that the output is wrong in a way you can describe, prompting is the right tool.

The decision gets easier when you have written down what you are optimising for. Without that, every problem looks like a prompt problem, because the prompt is the thing you can edit.

What should you do next?

Take your most important prompt and mark every sentence as either a description of the task or a correction of a model behaviour. Then move the corrections into their own labelled section at the bottom.

Next, save twenty real inputs and write a short description of what a good output looks like for each. That is your evaluation set, and it is the thing that turns the next upgrade from a source of anxiety into a twenty minute check. Writing that specification well is a skill in itself, and it is the same skill as briefing a person, which I have covered in how to write a brief an AI agent can actually follow.

If you have a prompt doing real work in your business and you want someone to look at which parts of it are load bearing, reach out. It is usually a much smaller proportion than people expect.