Guide · · 6 min read
Write prompts that survive the next model
Most prompt tricks are workarounds for a specific model's weakness. When the model improves, the trick becomes dead weight.
By Manish
A great deal of prompt engineering is scar tissue. Someone found a model that ignored an instruction, added THIS IS VERY IMPORTANT in capitals, and it worked. Two model versions later the capitals are still there, doing nothing, copied into every template the team owns.
The prompts that keep working across upgrades are the ones that were never compensating for a bug in the first place. Telling those apart is a skill worth having, because model upgrades now arrive several times a year.
Why tricks stop working
Most prompt tricks exploited a specific weakness. The model did not reliably reason step by step, so you told it to. It ignored formatting instructions, so you repeated them three times. It refused reasonable requests, so you invented a role-play framing.
Labs fix these deliberately. Each fix is a small improvement to the model and a small deletion from your prompt library, except nobody does the deleting. The instructions accumulate, and eventually you have a four-hundred-word system prompt where eighty words are doing the work.
Dead instructions are not harmless either. They consume context, they occasionally conflict with each other, and in a few documented cases they actively degrade output on newer models that interpret them literally.
What ages badly
- Threats and bribes. Offering a tip, or claiming someone will be harmed, exploited alignment gaps that have largely been closed. These now do nothing and occasionally trigger a refusal.
- Forced step-by-step reasoning. Reasoning models already think before answering. Telling them to think again wastes tokens and can interfere with their own process.
- Elaborate output scaffolding. Long formatting instructions existed because older models drifted mid-response. Structured output modes solved that properly at the API level.
- Persona padding. You are a world-class expert with twenty years of experience moved the needle in 2023 and does approximately nothing now.
- Repetition for emphasis. Saying the same constraint three times was a workaround for weak instruction following.
- Jailbreak-adjacent framing. Hypothetical wrappers and fictional framings to get past refusals are patched continuously and make your prompt fragile by design.
What keeps working
Everything that supplies genuine information rather than applies pressure. The distinction is simple once you see it: does this line give the model something it could not otherwise know, or does it just insist harder?
- Context. Background, constraints, and facts the model has no way to infer.
- Examples. Two or three samples of the output you want, which communicate tone and format faster than any description.
- Explicit constraints. Length, audience, what to exclude, what to do when uncertain.
- Role definition where it carries real information. You are reviewing this for a security audience tells the model something. You are a genius does not.
- A stated fallback. What to do when the answer is not in the provided material, which is the single most valuable line in most production prompts.
If your prompt would help a competent new colleague do the task, it will survive the upgrade. If it only works on one model, you are on borrowed time.
The fallback instruction deserves its own section
Most production prompt failures are not wrong answers. They are confident answers to questions the model had no basis to answer, and they happen because nobody told it what to do when the information was missing.
One sentence fixes most of it. If the answer is not in the material provided, say so rather than inferring. That line is model-agnostic, it survives every upgrade, and it converts your worst failure mode from silent fabrication into a visible gap.
It is also the instruction most often left out, because during development you only test cases where the answer exists.
Keep a test set, and actually run it
Save ten real inputs and the outputs you were happy with. When a new model ships, or your provider forces an upgrade, run them and read the results side by side.
This takes fifteen minutes and it is the only reliable way to know whether your prompts still earn their complexity. Half the time you will find you can delete a paragraph and the output improves. That is the upgrade working, and without the test set you would never have noticed.
The other half of the time you catch a regression before your users do, which is worth considerably more than fifteen minutes.
Prune deliberately, once a quarter
Take your longest production prompt and delete one instruction. Run the test set. If nothing got worse, the instruction was dead, and it stays deleted.
Repeat until something breaks, then put that one back. Teams doing this routinely report cutting system prompts by half with no quality loss, and the shorter prompt is cheaper, faster, and considerably easier for the next person to understand.
The instinct to leave a working prompt alone is understandable and wrong. Prompts rot, silently, and the rot is invisible until you test for it.
Write for the model you will have
The trend is consistent and worth planning around. Models keep getting better at following plain instructions and less responsive to manipulation. Every year, the prompt that reads like a clear brief outperforms the prompt that reads like an incantation by a wider margin.
So write the brief. Be specific about the audience, supply the context, show an example, say what to do when unsure. That prompt worked on last year's model, works on this year's, and will very probably work on next year's, which is not something you can say about anything written in capitals.
Examples beat description, consistently
If you change one thing about how you write prompts, make it this. Two or three examples of the output you want communicate more than a paragraph describing it, and they degrade far more gracefully across model versions.
The reason is that description is interpretation and examples are specification. Write concisely and the model picks a length. Show three outputs of about eighty words each and it matches, without you having to name a number that will be wrong for some inputs.
Examples also encode the things you would struggle to articulate. Tone, how much hedging is acceptable, whether to use bullet points, how to handle an edge case. All of that transfers from a sample and almost none of it survives being described.
Pick examples that cover the range rather than three of the same easy case. One typical, one edge case, one where the correct answer is to decline.
Separate the instructions from the input
A prompt that mixes your instructions with the user's content is fragile in two ways. The model can confuse which is which, and content containing something that looks like an instruction can override yours.
Use whatever separation your provider supports. System messages for the instructions, clear delimiters around user content, and an explicit statement that content inside the delimiters is data to be processed rather than instructions to be followed.
This has always been good practice and it became essential once prompts started handling text from untrusted sources. It is also stable across models, because it is an architectural choice rather than a phrasing trick.
Version your prompts like code
Production prompts change, and teams frequently cannot say what changed or when. That makes debugging a regression close to impossible, because you cannot tell whether the model changed or the prompt did.
Keep them in version control with the rest of the application. Note in the commit why the change was made. When output quality shifts, you can then diff the prompt against the last known good version instead of guessing.
This sounds obvious and is skipped constantly, because prompts feel like content rather than code. They are configuration that determines application behaviour, which makes them code by every definition that matters.
The migration checklist
When a provider announces a deprecation, the work is smaller than it looks if you have the pieces in place.
- Run your saved test set against the new model and diff the outputs.
- Check anything relying on quirks, particularly output formatting the old model happened to produce reliably.
- Delete the instructions that were compensating for the old model's weaknesses, then re-test.
- Watch cost, since newer models sometimes price differently per token and reason for longer.
Teams with a test set do this in an afternoon. Teams without one find out through user complaints several weeks later, without knowing what changed, which is how a routine upgrade turns into a fortnight.
Find the right AI assistant for your writing
Compare the writing tools we have reviewed, with prices and honest pros and cons.