In short
Prompt engineering in production is not clever wording — it is specification discipline plus measurement. A durable prompt states the outcome before the background, supplies real source material, names constraints explicitly, defines the exact output structure, and is paired with a fixed evaluation set that reveals when a model update has changed behaviour underneath you.
The part that transfers
Most published prompt advice is folklore: phrasings that worked once, on one model, for one task. Model updates invalidate it constantly.
What actually transfers is unglamorous and stable: be specific about the outcome, supply the real material, name the constraints, and define the output structure. That is ordinary specification discipline — the same thing that makes a good ticket or a good brief.
A vague brief always produced bad work. The change is that it now produces bad work faster and in greater volume.
The four parts of a prompt that holds up
Outcome first. State what you want before the background. Models weight early instructions heavily, and burying the ask under three paragraphs of context reliably produces answers to the wrong question.
Real source material. Paraphrasing what a document says instead of supplying it is the most common cause of confidently wrong output. Give it the actual text.
Explicit constraints. Length, audience, tone, what to exclude, what must not change. Unstated constraints are not inferred; they are invented.
The exact output shape. Not "give me a summary" but the fields, the order, the format. If code will consume the output, specify a schema and validate against it — never trust that structure survived.
Structure beats phrasing
For anything running more than a handful of times, the shape of the prompt matters more than its wording.
Separate the stable from the variable. A fixed instruction block plus a variable input block. This is easier to reason about, and it lets the stable portion be cached — which on most platforms bills at a fraction of the standard input rate.
Ask for a plan before the output on complex tasks. It surfaces misunderstandings while they are still cheap, and gives you something to correct that is not the finished artefact.
Make refusal a valid answer. Explicitly permit "the material does not contain this." Without it, a helpful model fills gaps — and gap-filling is where hallucination enters production.
One prompt, one job. A prompt doing four things fails in four ways and is impossible to debug. Chain focused steps instead.
The thing almost nobody builds
Build a fixed evaluation set before you tune anything. Twenty to fifty real inputs with what a good answer looks like for each.
This matters more than any prompt technique, for a reason teams discover painfully: providers update models underneath you. A prompt tuned for months can change behaviour without any change on your side. Without an evaluation set you find out from a user.
It also converts prompt work from taste into measurement. "This feels better" becomes "this scores better on the cases we care about," which is the difference between engineering and vibes.
Record the model version and parameters with every result. When something changes, you need to know what.
Failure modes that only appear at scale
Drift. Behaviour shifts after a provider update. Only an evaluation set catches it.
Prompt injection. If any part of the prompt contains text you did not write — a user's document, a scraped page, a retrieved passage — that text may contain instructions. Everything from an untrusted source is data, not instructions, and that boundary must be structural, not a polite request in the system prompt.
Context exhaustion. Long conversations and agent runs quietly drop the earliest content, so instructions established at the start stop applying. If something must always hold, it belongs in the system instruction, not the first message.
Format drift on edge cases. A prompt returning clean JSON for 200 inputs will eventually return prose with an apology. Validate the structure and handle the failure; do not assume.
Cost creep. Output tokens typically cost several times input. Verbose formats are expensive at volume — often the cheapest optimisation available is asking for less.
How to work on this as a team
Keep prompts in version control, reviewed like code. Note why an instruction exists — most contain a line addressing a failure nobody remembers, and it gets deleted as clutter.
Have one owner per prompt. Prompts edited by everyone regress steadily as each person fixes their case and breaks another's.
And start with the cheapest model that passes your evaluation. Teams default to the frontier tier and pay several times more than the task needs. Measure first, upgrade only against evidence.
If you want help putting evaluation and guardrails around model features already in production, book a call.
Common questions
What is prompt engineering?
The practice of writing model instructions that produce reliable, reviewable results. In production it consists mostly of specification discipline — stating the outcome, supplying real source material, naming constraints, and defining the exact output format — rather than clever phrasing.
How do I stop a prompt breaking when the model updates?
Build a fixed evaluation set of twenty to fifty real inputs with expected outcomes, and record the model version and parameters with every result. Providers update models underneath you, and an evaluation set is the only way to detect behavioural drift before your users do.
What is prompt injection and how do I prevent it?
Prompt injection is when text from an untrusted source — a user document, a scraped page, a retrieved passage — contains instructions the model then follows. Prevent it by treating all such content as data rather than instructions, enforced structurally in how the prompt is assembled, not by asking the model in a system prompt to ignore instructions.
How do I reduce the cost of prompts in production?
Cut output tokens first, since output typically costs several times more than input — request tighter formats. Then separate the stable portion of the prompt from the variable portion so the stable part can be cached at a reduced rate. Then use the cheapest model that passes your evaluation set rather than defaulting to the frontier tier.
