8.4 Prompt engineering that survives users

What this is and why it exists

A prompt that works in your demo is a prompt tested on cooperative input. In production it meets people who are terse, confused, hostile, off-topic, or deliberately trying to make it misbehave, and the difference between a prompt and a prompt that survives that is not cleverness — it is contract design and regression testing. This topic treats a prompt as code, because that is what it is: it is versioned, it is tested, and a change to it can break something that worked yesterday.

The vocabulary

• System prompt — standing instructions that apply to every request.
• Role — the persona and scope the model is asked to operate within.
• Output contract — an exact specification of the shape the answer must take.
• Zero-shot — asking with no examples; few-shot — asking with a handful.
• Chain of thought — asking for the reasoning before the answer.
• Self-consistency — sampling several answers and taking the majority.
• Failure taxonomy — a catalogue of the ways a prompt goes wrong.
• Prompt regression test — a fixed set of cases run whenever the prompt changes.

The mental model

A good prompt has four parts, and the fourth is the one usually missing.

Role: who the model is acting as and, more importantly, what is out of scope. "You are a support assistant for this product; questions about anything else get a polite redirection" does more work than any amount of tone instruction, because it gives the model a rule for the enormous space of inputs you did not anticipate.

Instructions: what to do, in the order it should be done, stated positively. A list of prohibitions describes a shape by its outline and leaves the middle undefined; "answer only from the provided documents; if they do not contain the answer, say so" is a rule the model can follow, where "don't make things up" is a hope.

Examples: two or three, showing the hard cases rather than the obvious ones. Few-shot examples remain the highest-leverage trick per token in this whole topic — one example demonstrating exactly the format, the tone and the edge-case handling teaches more than a paragraph describing them. Include at least one example of the model declining or saying it does not know, because otherwise every example in the prompt is an example of answering, and the model has learned that answering is what happens here.

The output contract: the exact shape of the answer. Fields, types, what appears when a field is unknown, what to do when the request cannot be satisfied. This is the part most often omitted, and it is the part that decides whether your code can consume the output. The structured-output topic takes it further.

The four asking strategies, and what each costs. Zero-shot is cheapest and right when the task is common and well-specified. Few-shot costs tokens on every request and buys format and edge-case adherence — usually the best value. Chain of thought, asking for reasoning before the answer, helps on multi-step problems and costs output tokens and latency; note that with models trained to reason it is frequently already happening and asking for it again can be redundant. Self-consistency samples several answers and takes the majority, which raises accuracy on problems with a definite answer and multiplies the cost by the number of samples. Choose by whether the task has one right answer and by what an error costs, not by which sounds most sophisticated.

Prompts are code and belong under version control with the code. A prompt pasted into a text box, edited by whoever is on shift, is how a system changes behaviour with no diff, no author and no way back. Put them in files, template the variable parts, version them, review changes, and record which prompt version produced any output you keep. Unexplained regressions in these systems are very often a prompt change nobody recorded.

Then the part that separates prompt engineering from prompt fiddling: a failure taxonomy with tests. Cataloguing how a prompt fails turns an endless fiddle into a finite list you can work through.

The categories worth having, because they cover most of what arrives:

• Empty or nearly empty input — a single word, punctuation only, whitespace.
• Off-topic — a reasonable question about something else entirely.
• Malformed — truncated text, mixed encodings, an accidentally pasted log file.
• Adversarial — instructions in the input trying to override yours, requests to reveal the system prompt, attempts to make the system say something embarrassing.
• Ambiguous — genuinely admitting two readings, where the right behaviour is to ask.
• Out of scope but plausible — the thing the system nearly does, where the failure is confidently doing it badly.
• Volume and repetition — the same question fifty times, or an enormous input.

For each, write down what should happen. Then those cases become the regression suite, run on every prompt change, asserting on properties rather than exact text — that a refusal happened, that the schema is satisfied, that the system prompt did not appear in the output, that no answer was invented when the documents were empty.

Two more habits. Test with real user input as soon as you have any, because the failure modes you invent are politer than the ones that arrive. And when you change a prompt to fix one case, run the whole suite: prompts have no type system and no compiler, so a clarification added for one situation silently changes behaviour in another, and the suite is the only thing that will tell you.

A note on the adversarial category, which is developed in the safety topic. Instructions arriving inside user input, or inside a document your system fetched, are data and not instructions — and no wording of a system prompt makes that reliably true. Prompting reduces the problem; architecture, meaning what the model is permitted to see and to do, is what actually bounds it.

What you should now be able to explain or do

Write a prompt with all four parts, including the output contract. Say why scope in the role does more than tone instruction and why positive rules beat prohibitions. Choose examples that show hard cases, and include a declining example. Pick among the four asking strategies by task shape and error cost. Keep prompts in version control and record which version produced an output. Build a failure taxonomy across the seven categories and turn it into a regression suite asserting on properties. Say why prompting alone cannot solve the adversarial category.

Check yourself