Most "the model is unreliable" bug reports are not model bugs. They are unspecified behaviour. A model handed loose instructions fills the gaps differently on every call, and from the outside that looks like randomness.
The gap between a feature that needs human review on 40% of outputs and one that needs it on 5% is almost never a bigger model. It is four things the prompt failed to state.
The Four Fields Every Working Prompt Has
Role. Who the model is acting as. "You are a support specialist who classifies incoming email" tells it what knowledge to draw on, what tone to use, and what level of detail is appropriate. A senior financial analyst and a friendly support rep produce different output from identical input.
Task. The specific action, stated concretely enough that two different people reading it would expect the same result. "Classify this email as billing, technical, general inquiry, or spam" instead of "handle this email".
Constraints. The rules, including what to do when the model is unsure. "Respond with only the category name. If unsure, default to general inquiry." Undefined edge cases are where answers diverge most, so this is the field that buys you the biggest consistency win.
Format. How output should be structured. "Return JSON with fields category, confidence 0-100, and summary, one sentence max." Without this the model picks its own formatting, and it picks a different one tomorrow.
Miss any one of these and you get unpredictable output. The role prevents generic assistant behaviour, the task prevents rambling, the constraints prevent edge case failures, and the format prevents parsing headaches downstream.
The Money Version Of The Same Argument
Take 10,000 support tickets a month running through an AI classifier. A prompt that needs human review on 40% of responses leaves 4,000 tickets for a person. Tighten it to a 5% error rate and that is 500. At $8 per manual resolution, the difference is roughly $28,000 a month, bought entirely with better instructions rather than a better model.
That is why a well-engineered prompt on a cheap model regularly beats a vague prompt on an expensive one. The model matters. The instructions matter more.
Pick The Technique To Match The Task
Zero-shot, no examples, is right for tasks with heavy representation in training data: sentiment, translation, plain summarization. It is the cheapest in tokens and it works better than people expect.
Few-shot, 2 to 5 examples, is what you reach for when the nuance is easy to show and hard to describe. Sarcasm versus genuine complaint. A category boundary that is partly subjective. Quality of examples beats quantity: five examples that all look alike wastes four of them, so cover the obvious case, the tricky case, and the one where the right answer is not obvious.
Chain-of-thought, asking for reasoning before the answer, earns its tokens on multi-factor decisions and anything requiring synthesis across parts of the input. "Think step by step" is the crude version. A named framework works better: identify the relevant factors, evaluate each against the criteria, weigh conflicts, then state the conclusion.
Treat Prompts Like Code
The teams getting real value do not write prompts, they maintain them. Versioned, tested, measured. The cheap version of that discipline is keeping 20 to 30 real inputs with known-good outputs next to the prompt file. When quality feels off, you rerun the set and you know in two minutes whether the model changed or your prompt drifted. Without that, you are guessing, and you will usually guess wrong.
Takeaway
Before blaming the model, read your prompt and check whether it states a role, a task, its constraints, and an output format. Most inconsistency lives in whichever of those four is missing.
If you want the longer version with worked examples, the full prompt engineering guide covers anatomy, the core techniques, testing, and building a production prompt library.
