How to Write Prompts That Work Across AI Models
Prompts do not port between models. Structure does. What survives a model change, what breaks, and how to find out in twenty minutes rather than in production.
Prompts do not travel. Structure does. The useful move in learning how to write prompts that work across AI models is to separate what you are asking for from how you are coaxing a particular model into giving it to you. The first layer ports cleanly. The second is where every migration breaks, and it is usually the part people are proudest of.
This matters more than it used to, because model retirements are routine and price differences between providers are large enough to be worth acting on. A prompt library welded to one model is a switching cost you pay later, usually at the worst moment.
What ports and what does not
Ports cleanly | Breaks on a model change |
|---|---|
A clear statement of the task | Threats, bribes, and all-caps insistence |
Explicit output format with an example | Exact token counts or character limits |
Relevant context and constraints | Provider-specific tags and delimiters |
Worked examples of input and output | Reasoning instructions that fight a reasoning model |
Definitions of terms you use unusually | Assumptions about default verbosity or tone |
Explicit statement of what to do when unsure | Jailbreak-adjacent phrasing tuned to one model |
The right column is not useless. It is just local knowledge, and it belongs in a clearly separated section of your prompt so you know exactly what to re-tune when you move.
How to write prompts that work across AI models, in four layers
Write every prompt in four parts, in this order, and keep them physically separate in your code:
Role and task. One or two sentences. What is being done and for whom.
Context. The material the model needs, clearly delimited from the instructions.
Constraints and output format. What must be true of the answer, with a small example.
Model-specific adjustments. Everything you added because this particular model kept doing something annoying.
When you switch models, layers one to three move unchanged and layer four gets rewritten. If you cannot tell which of your instructions belong in layer four, that is the finding, and it is worth an hour to fix before you need to migrate. Anthropic's system prompt guidance is a reasonable reference for how to keep role and task separated from context.
A practical test of whether your layers are clean: could you hand layers one to three to a colleague and have them understand the task without knowing which model you use? If layer three contains a sentence that only makes sense as a workaround, it belongs in layer four.
The four things that break most often
Output verbosity
Models differ substantially in default length. A prompt tuned to stop one model rambling will make another terse to the point of uselessness. Specify length in structural terms, three bullet points, one paragraph, a JSON object with these five keys, rather than in words or characters. Structural limits are understood consistently; numeric ones are approximated differently by every model.
Format compliance
Asking for JSON in prose works well on some models and produces markdown-fenced JSON with a preamble on others. Where the provider supports constrained decoding or a structured output mode, use it rather than asking politely, since that is a hard guarantee rather than an instruction. The patterns that hold up are in how to get JSON output from AI.
Reasoning instructions
Telling a model to think step by step helps a model that does not reason by default and can actively degrade one that does, by producing a redundant visible chain on top of its internal one. This is the single most common prompt to review when moving to a reasoning model, and chain of thought prompting covers when it is doing work and when it is decoration.
Refusal boundaries
Models draw different lines. A prompt handling security topics, medical wording, or anything adversarial may run cleanly on one and get refused on another. Keep a couple of borderline cases in your test set specifically to catch this, because a refusal in production looks like an outage to the person on the other end.
Test portability cheaply
You do not need an evaluation framework. You need twenty representative inputs, saved with the output you consider correct, and a script that runs them against any model and shows you the differences side by side. That is an afternoon of work and it converts every future model decision from a guess into a check.
Include the awkward cases deliberately: an empty input, a very long one, one with contradictory instructions inside the context, and one in a language you did not design for. Those four find more portability problems than twenty normal cases do.
Judge the results on whether the output is usable rather than whether it matches your reference word for word. Two different phrasings of the same correct answer are a pass. A correct answer in the wrong shape is a fail, because your code has to parse it.
Keep this set in version control next to the prompts themselves, which is the natural extension of versioning your prompts and makes the test set useful for testing a new AI model before switching.
Design the code around the seam, too
Portability is not only a prompt property. Three code-level habits make a model swap a configuration change rather than a project:
Keep the model identifier in configuration, not scattered through call sites.
Wrap provider calls in one thin adapter, so differences in parameter names and response shapes live in a single file.
Parse defensively. Strip markdown fences, tolerate a leading explanatory sentence, and fail loudly rather than silently when the shape is wrong.
That third one saves the most time. A parser that only accepts perfectly formatted output will break on any model change; one that tolerates the common deviations will survive most of them.
How far to take it
Full portability has a cost. A prompt written to run identically everywhere gives up the specific strengths of the model you actually use, and that is a real loss on hard tasks. The sensible position is portable by default, specialised deliberately: write the base prompt to be model-agnostic, add a small documented layer of model-specific tuning on top, and accept that the layer is disposable.
The exception is a prompt at the core of your product doing something genuinely difficult. There, tuning hard to one model is the right call, and the mitigation is to know it, write it down, and keep the test set current so you can measure what a move would cost rather than guessing.
FAQ
Do I need different prompts for every model?
No. Most of a good prompt is model-agnostic already. Expect to adjust output format enforcement and verbosity, and to leave the substance alone.
Do longer prompts port better than short ones?
The opposite, usually. Long prompts accumulate model-specific workarounds. A short, precise prompt with a clear output example is the most portable thing you can write, which is also the argument in how long a prompt should be.
What about prompts for local models?
Smaller local models follow complex multi-part instructions less reliably. Simplify structure and give more examples rather than more explanation, and expect the format-enforcement layer to need the most work.
How often should I re-test?
Whenever you change models, and periodically if you point at an alias rather than a pinned version, because an alias moves underneath you without any change on your side.
Do few-shot examples port between models?
Generally yes, and they are among the most portable things you can include. The number needed varies, with smaller models benefiting from more.
A worked example
Take a prompt that extracts supplier details from an invoice. The portable core is three sentences: you are extracting structured data from an invoice, here is the invoice text, return an object with these six fields and use null where a field is genuinely absent. That works on any model capable of the task, and it will still work on a model released next year.
The non-portable layer is everything you added afterwards: the instruction not to wrap the answer in a code fence, the reminder that dates in this corpus are day-first, the sentence telling it to stop apologising when a field is missing. Every one of those exists because a specific model did a specific annoying thing. Keep them in a clearly labelled block at the end, and when you move, delete the block and see which annoyances actually recur. Usually about half of them do not.
Writing for portability is not extra work once it is a habit. It is mostly the discipline of noticing when you are writing an instruction about the task and when you are writing an instruction about the model, which is a distinction worth carrying through the rest of prompt engineering.
The same front-loaded-context principle applies to a different task in how to prompt AI for a competitive analysis, where the two-stage approach solves a similar reliability problem.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
