Not another “be specific!” article. Real techniques, real before/afters, and the failure modes that waste tokens quietly.
- Most prompts fail not because they’re vague β but because they’re missing one specific component. Usually it’s the output format or the success criterion.
- The five-part anatomy (role, task, context, constraints, format) fixes ~80% of prompt failures. The order matters.
- Few-shot examples outperform instructions alone in almost every test I’ve run. One good example beats three paragraphs of explanation.
- Model matters. The same prompt written for GPT-4o often needs rewriting for Claude or Gemini. They have meaningfully different response tendencies.
I’ve reviewed around 300 AI-powered workflows over the past 18 months β marketing tools, internal knowledge bases, customer support bots, code generation pipelines. The single most common problem, across all of them, wasn’t the model they chose. It was how they wrote prompts.
Not vague prompts. Vague prompts are the beginner problem. The workflows that frustrated me most were written by smart people who thought they were being specific β and were still getting inconsistent, off-format, or just subtly wrong outputs. Because they’d never been taught what a complete prompt actually looks like.
That’s what this guide covers. The anatomy. The techniques. And the failure modes that cost teams real time and money before anyone realizes what’s happening.
A prompt isn’t just an instruction. It’s a specification. And like any spec, it has components. Miss one and you’re hoping the model fills it in correctly β which it will, using whatever default it prefers, not whatever you actually need.
Most failed prompts I see are missing components 4 and 5. They nail the task β “write a product description” β and sometimes add context, but never say what the output should look like or what it shouldn’t do. Then the team gets frustrated when GPT-4o returns 400 words instead of 80, or uses bullet points when they needed prose.
Here’s what a complete prompt looks like in practice:
That prompt is longer than what most people write. It’s also much faster in practice, because it doesn’t produce a draft you have to rewrite three times. The time is in the spec, not the iteration.
There are probably 50 documented prompt techniques at this point. Most are variations on the same handful of ideas. These six are the ones I actually use β ranked by how often they’ve made a meaningful difference in output quality across the workflows I’ve audited.
Give the model one or two examples of exactly the output you want. Not descriptions of the output β actual examples. This is the single highest-leverage technique I’ve found, and it’s underused because people think it feels redundant. “Why would I show it what I want if I can just describe it?” Because examples bypass the ambiguity in descriptions. A model reading “confident but not aggressive” will interpret that differently than you intended. An example just shows it.
The example doesn’t have to be perfect. It just has to be representative. Even one mediocre example outperforms no example in most cases.
For anything analytical β categorization, problem-solving, evaluation β tell the model to reason through the problem before giving you the answer. “Think step by step” is the classic version. It works. The model produces fewer confident wrong answers when it’s asked to show its reasoning.
Without that first step, models jump to conclusions and then confabulate the justification. With it, the reasoning is usually sounder β and if it’s not, you can see where it went wrong.
This one feels counterintuitive. Why tell a model what not to do instead of just specifying what to do? Because models have strong defaults β patterns baked in from training β and sometimes the most efficient way to override them is to name them explicitly and say “don’t.”
Common defaults worth overriding: starting responses with “Certainly!”, using passive voice, adding unsolicited caveats, ending with “In conclusion,” using em dashes everywhere, padding short answers with context you didn’t ask for.
Specify the format with enough precision that the model can’t misinterpret it. “A short summary” is ambiguous. “A 50-word summary in a single paragraph, starting with the main finding” is not. For structured outputs going into code, specify JSON with exact field names and types.
That schema specification reduces parsing errors in production dramatically. And “no markdown backticks” is the most reliably ignored instruction unless you make it explicit. ESTABLISHED
Assigning a role (“You are a senior tax attorney…”) primes tone, depth, and vocabulary. It works best when the role implies a specific way of communicating that would be hard to describe directly. A “skeptical code reviewer” will question assumptions by default. A “patient kindergarten teacher” will simplify without being told.
The caveat: roles can hallucinate credentials. “You are a licensed financial advisor” doesn’t give the model accurate licensed-advisor knowledge β it just makes it sound more confident about its financial outputs. Use roles for tone and framing, not for knowledge you don’t have.
Write prompt β run it β identify exactly what went wrong β change one variable β run again. Most people change multiple things between iterations and can’t tell what fixed it. Treat it like debugging. Change one thing at a time. Document what you changed and why. Your fifth draft is usually much better than your first, but only if you learned something from each version.
The teams that do this systematically β with a test set of inputs and expected outputs β end up with dramatically more reliable prompts than the teams that iterate on vibes.
This is the thing that’s almost never covered in prompt guides, and it matters. Different models have meaningfully different response tendencies β defaults that affect how your prompts land.
| Tendency | GPT-4o | Claude Sonnet | Gemini 1.5 Pro |
|---|---|---|---|
| Default response length | Medium β tends to match prompt length | Longer β more caveats and context | Medium-long β comprehensive by default |
| Format compliance | Good β follows format specs reliably | Very good β especially with XML tags | Good β responds well to explicit schemas |
| Refusing edge cases | Moderate | More conservative on ambiguous cases | Moderate |
| Tone default | Helpful-neutral | Thoughtful, slightly formal | Informative, encyclopedic |
| Best format trick | Plain instruction | XML tags for structure (<output>, <reasoning>) | Explicit JSON schema |
If you’re writing prompts that need to work across multiple models (common in enterprise setups with vendor flexibility requirements), design for the most constrained model and relax for others. Claude’s XML-tag approach for structured output is worth learning β it’s remarkably clean.
These are the failure patterns I’ve seen repeatedly in production workflows β the ones that generate outputs that look plausible but are wrong in expensive ways.
You ask for a factual answer. The model gives you one. It’s wrong. It doesn’t say “I’m not sure.” It just states it. This happens most with specific numbers, dates, and proper nouns.
Your prompt specifies JSON. The model returns JSON for the first five requests, then adds a preamble sentence on the sixth. This breaks parsers. Happens more with longer conversations where system prompt context dilutes.
You have a long system prompt with multiple instructions. The model follows the first few and ignores the rest. Instructions buried in the middle of a long system prompt are less reliably followed than instructions at the beginning or end.
You ask for exactly five items. The model gives you six because “the sixth seemed too important to leave out.” Models are trained to be helpful, and “helpful” sometimes means exceeding your specification.
You stuff a long document into the context and ask a specific question. The model answers confidently using information from the wrong section of the document β or from training data instead of the document at all.
Iterating on prompts without a test set is guesswork. Here’s the lightweight version that works for most teams without requiring MLOps infrastructure:
Step 1: Write 10-15 representative input examples β a mix of typical cases and edge cases. Include inputs that should be refused or flagged if your use case has that requirement.
Step 2: Write the expected output or evaluation criteria for each input. This doesn’t have to be the exact output β it can be “should mention pricing,” “should not include competitor names,” “should be under 80 words.”
Step 3: Run your current prompt against all 15 inputs. Score each one against your criteria.
Step 4: Change one thing in the prompt. Run again. Compare scores. Keep the change only if it improved the average without breaking previously-passing tests.
That’s it. It’s not fancy. But it’s the difference between knowing your prompt is better and thinking it might be better. If you want tooling for this β Anthropic Console’s Evaluate feature and the prompt management tools covered in our tooling guide both support this workflow.
These aren’t magic. They’re starting points that cover the most common gaps. Adapt them to your use case β and run them through your test set before treating them as production-ready.
For deeper technique references: Anthropic’s prompt engineering documentation is the most rigorous public resource currently available, especially for Claude-specific behavior. OpenAI’s prompt engineering guide covers GPT-specific defaults well. And the fundamentals guide on this site covers the conceptual layer if you want to go deeper.
Does prompt length matter? Is shorter always better?
No. The right length is whatever it takes to specify the task completely. A 500-word prompt that eliminates 5 rounds of iteration is faster than a 50-word prompt that produces outputs you rewrite every time. That said, redundancy in prompts does confuse models β don’t repeat the same instruction in different places and expect double compliance. Longer is fine. Redundant isn’t.
Should I use system prompts or user-turn prompts?
System prompts are for persistent context and role/behavior specification β things that don’t change between requests. User-turn prompts are for the specific task and input. If you’re building a product, your role, constraints, and format specifications belong in the system prompt. The user’s actual request belongs in the user turn. Mixing them causes drift as conversations get longer.
How do I stop the model from making things up?
You can’t fully eliminate hallucination, but you can reduce it significantly. The most effective approaches: provide the source material explicitly and instruct the model to answer only from it; ask the model to express uncertainty when it’s not confident; use chain-of-thought to surface flawed reasoning before it reaches the output; and test with inputs where the right answer is “I don’t know” to verify the model doesn’t confabulate instead. Retrieval-augmented generation (RAG) is the structural solution for high-accuracy knowledge tasks.
My prompt works in testing but breaks in production. Why?
A few common causes: your test set wasn’t representative of real inputs; the model received a silent update between testing and production (this happens more than providers advertise); context window pressure from conversation history is diluting your system prompt’s influence; or real user inputs contain edge cases you didn’t anticipate. The fix is a more diverse test set and observability tooling that logs every production call so you can see exactly what the model received and returned.
What’s the biggest mistake non-technical people make with prompts?
Treating the model like a search engine β a short query expecting a perfect result. The other big one: not specifying the audience. “Explain how this works” produces a very different output than “Explain how this works to a non-technical founder who needs to make a budget decision about it.” The model needs to know who it’s talking to just as much as it needs to know what to say.
If you take nothing else from this guide: before you write your next prompt, ask yourself what you would hand to a very smart junior colleague who knew nothing about your project. What would they need to know to do this right on the first try?
That’s your context block. Add it. You’ll be surprised how often it’s the only thing standing between a mediocre output and a good one.
A prompt is a specification, not a wish. Write it like one.
Contact
