TL;DR · Key Takeaways
- Prompt engineering is not magic words. It is clear communication: telling the model exactly who it is, what you want, and what good output looks like.
- Four moves do most of the work: give a role, be specific about the task, show the format you want, and provide examples when format matters.
- The system prompt sets standing rules and persona; the user prompt is the request of the moment. Use the right one for the right job.
- Most bad output is a vague prompt, not a dumb model. Politeness, padding, and contradictory instructions waste tokens and muddy the result.
“Prompt engineering” might be the most oversold phrase in AI. For a while it was floated as a six-figure job title and a bag of secret incantations. Then, just as quickly, people declared it dead. Both takes miss the point. There is no magic spell, but there is a real and learnable skill, and it is far more boring and far more useful than the hype suggested: it is the skill of giving clear instructions. When AI output disappoints, the cause is usually not a stupid model. It is a vague request. Fix the request and the output often transforms.
Two voices: the system prompt and the user prompt
Before the techniques, one piece of plumbing pays for itself. Most AI systems take two kinds of instruction. The system prompt is the standing brief: who the model is, the rules it should always follow, the tone to keep. You set it once and it governs the whole conversation, like the job description you give an employee on day one. The user prompt is the individual request: the specific question or task right now. In a chat app you usually only touch the user prompt, but as soon as you build anything, the system prompt becomes your main lever for consistent behaviour.
The practical rule is to put durable instructions in the system prompt and momentary ones in the user prompt. “Always answer in British English, never give medical advice, keep responses under 200 words” belongs in the system prompt, where it applies to everything. “Summarise this email” belongs in the user prompt. Mixing them up, restating your standing rules on every single turn, is a common waste of effort and tokens.
The four moves that do most of the work
You can get most of the available gains from four habits. The first is to assign a role. “You are a meticulous copy editor” or “Act as a sceptical security reviewer” pulls the model toward the right register and standards before it writes a word. The second is to be specific. Replace “write about our product” with the audience, the length, the tone, the angle, and what to leave out. Vagueness is the single biggest cause of disappointing output, and specificity is its direct cure.
The third move is to specify the format. If you want a table, a JSON object, three bullet points, or a two-sentence answer, say so plainly, because left to its own devices the model will pick a shape that may not be the one you need. The fourth, for anything where format or style is fiddly, is to show examples, often called few-shot prompting. One or two worked input-output pairs teach the pattern faster and more reliably than any amount of description. Show the model a sample of exactly what you want and it becomes remarkably good at matching it.
A quick example shows how much work a single demonstration can do. Suppose you want support tickets sorted into “billing,” “bug,” or “feature request,” and described in plain words the model keeps adding explanations you do not want. Instead of arguing with it, show it the pattern once: “Ticket: I was charged twice this month. Category: billing.” Then give it the real ticket and stop. That lone example fixes the format, the brevity, and the label set all at once, and it does so more reliably than three sentences of instructions trying to describe the same thing. When you find yourself struggling to explain a format in words, that is usually the signal to stop describing and start demonstrating.
For harder tasks there is a fifth habit worth keeping in your pocket: ask the model to work step by step. For anything involving reasoning, math, or multi-stage logic, a line like “think through this step by step before giving your answer” measurably improves accuracy, because it lets the model lay out intermediate work instead of lunging at a final token. Here is a compact reference for the patterns that earn their keep.
| Pattern | What it does | Reach for it when |
|---|---|---|
| Role / persona | Sets tone, expertise, and standards up front | You want a consistent voice or rigor |
| Specific brief | Removes the model’s need to guess intent | Almost always |
| Format spec | Pins the structure (table, JSON, word count) | Output feeds another step or system |
| Few-shot examples | Teaches a pattern by demonstration | Format or style is hard to describe |
| Step by step | Surfaces reasoning before the answer | Math, logic, or multi-stage tasks |
| Delimiters | Separates your instructions from pasted data | You include documents or user text |
The anti-patterns that quietly cost you
Knowing what to stop doing helps as much as knowing what to add. The most common waste is empty politeness and padding. “Hi, I hope you can help me, I was wondering if you might possibly be able to” costs tokens and adds nothing; the model is not flattered and you are paying for every word. Just as costly is over-stuffing: cramming ten loosely related requests, three contradictory style notes, and a wall of background into one prompt, then wondering why the answer is muddled. The model tries to honour all of it and satisfies none of it well.
Two more are worth naming. One is the magic-phrase fallacy: tacking on “be accurate and do not hallucinate” and believing it does something. It mostly does not, because, as Part 11 covered, the model has no switch for truth to flip. The other is burying the actual request under a paragraph of preamble, so the one sentence that matters arrives late and competes with everything around it. Lead with the task, keep instructions tight and non-contradictory, and give the model room to do the thing rather than wade through your throat-clearing.
▾ Go Deeper (optional, for technical readers)
Why does the order of a prompt change the output? Because a model reads everything as one sequence and, like people, it weights the extremes. Instructions placed at the very start and the very end of a prompt tend to carry more force than the same instructions buried in the middle, the same primacy-and-recency effect behind the “lost in the middle” problem from Part 10. A practical consequence: in a long prompt, putting the core instruction up top and then briefly restating the key constraint at the end often improves adherence, because you are hitting both high-attention zones.
Delimiters matter for a different reason: ambiguity. When you paste a document into a prompt and then ask a question about it, the model has to figure out where your instructions end and the data begins. Wrapping the pasted content in clear markers, triple quotes, XML-style tags like <document>…</document>, or a labelled section, draws a hard line between “this is the material” and “this is what to do with it.” That single habit reduces a class of failures where the model mistakes part of your data for an instruction, and it is also a first, partial line of defence against prompt injection, where text inside the data tries to hijack the model. Structured prompting, in short, is mostly about removing ambiguity before the model has a chance to resolve it the wrong way.
This is Part 12, the start of Phase 3, in a 30-part walk from zero to the infrastructure behind production AI. The full map is on the Generative AI Complete Guide. The “magic phrase” point builds on Part 11 on why models make things up; newcomers can start at Part 1.
The Bottom Line
Prompt engineering deserves neither the worship nor the dismissal it has received. Strip the mystique and it is the ordinary skill of briefing someone well: give the model a role, say specifically what you want, show the format, and add an example when the shape is tricky. Keep durable rules in the system prompt and the request of the moment in the user prompt. Cut the padding, the contradictions, and the magic phrases that do nothing.
If there is one shift I would push, it is to stop blaming the model for vague results and start treating the prompt as the variable you control. That reframing turns prompting from guesswork into a craft you steadily get better at. Good prompting gets a lot from a model on its own, but it has a ceiling: it cannot give the model facts the model never learned. Clearing that ceiling is the job of the next part, where we let the model read your actual documents through retrieval.
References
- Prompt engineering guide (OpenAI)
- Prompt engineering overview (Anthropic)
- Chain-of-thought prompting (Wei et al., 2022)
« Part 11: why models make things up | Generative AI Complete Guide | Next: Part 13, RAG and grounding »
About The Author
