Prompt Engineering That Works: Practical Patterns for Reliable AI Output
Stop writing wishes. Start writing specifications.

Stop writing wishes. Start writing specifications.

There is a moment familiar to anyone who has used an AI assistant seriously: you ask for something reasonable, you get back something technically responsive and completely useless, and you cannot quite say what went wrong.
Nine times out of ten, nothing went wrong with the model. The request simply did not contain enough information to have a single good answer. Write me a product description has a million valid completions, and you received one of them.
Prompt engineering has acquired a slightly ridiculous reputation, partly because of people selling lists of magic words. The real practice is far more mundane and far more useful: it is the discipline of specifying a task precisely enough that a competent stranger could do it.

Nearly every reliable prompt contains the same components. You do not need them all every time, but you should know which one you are leaving out.

Telling the model who it is writing as, and who is reading, resolves an enormous amount of ambiguity in one sentence. Explain this to a non-technical hospital administrator and explain this to a backend engineer produce genuinely different, appropriately different answers.
This is the single biggest lever. Models are far more reliable at transforming text you give them than at recalling text from training. Paste the transcript, the code, the policy, the customer email. A prompt that supplies its source material is a different class of tool from one that does not.
Summarise in five bullet points. Extract every date and the event attached to it. Rewrite at a sixth-grade reading level. Vague verbs like improve, optimise or look at invite the model to guess at your intent, and it will guess generically.
Length, structure, tone, what to include, what to leave out. If you need JSON, say so and show the shape. If you need exactly three options, say exactly three. Unstated constraints are not constraints.
One worked example teaches a format faster than three paragraphs describing it. This is called few-shot prompting, and it is disproportionately effective for anything with a fixed structure.
The difference is rarely subtle. Here is the same underlying request, written two ways.
| Weak prompt | Working prompt | |
|---|---|---|
| The ask | Write a product description for our app. | You are writing for our app store listing. |
| Material | (none supplied) | Feature list and three real customer quotes pasted below. |
| Task | Make it good. | Write 80 to 100 words, second person, one concrete benefit per sentence. |
| Constraints | (none) | No superlatives, no exclamation marks, do not mention competitors. |
| Result | Generic marketing filler | Something you can paste in with light edits |
Write the prompt as if the person receiving it cannot come back with clarifying questions — because that is exactly the situation. Every ambiguity you leave open will be resolved for you, in the most average way possible.
Complex work degrades badly in a single prompt. Splitting it into stages — first extract the facts, then analyse them, then write the summary — produces markedly better results, because each step is a simple task with a checkable output.
It also gives you a debugging surface. When the final output is wrong you can see which stage went off, instead of staring at one opaque failure.
Asking for JSON or a table rather than prose does two things: it makes the result machine-usable, and it constrains the model into being specific. Free prose lets it hedge; a field called risk_level does not.
Add an instruction like answer only from the text provided; if the answer is not there, say so. It does not eliminate fabrication, but it measurably reduces it and makes gaps visible instead of invisible.
For anything factual, retrieve the relevant documents and paste them in. This is the whole principle behind retrieval-augmented generation, and it applies just as much when the retrieval is you, copying a paragraph.

The teams that get consistently good results are not the ones with the cleverest phrasing. They are the ones who keep a small set of real test cases, run prompt changes against all of them, and keep the version that does better across the set rather than the one that fixed today's example.

A support team used a prompt to draft first replies to customer emails. It worked well until it did not — periodically an agent would notice a reply that was too casual, or that promised a refund policy the company did not have.
The prompt had been edited a dozen times by six people, each fixing one bad reply. Nobody had checked whether a fix broke anything else. It had become a pile of contradictory instructions.
They rebuilt it once, carefully, and kept twenty real emails as a test set. After that, every proposed change was run against all twenty before shipping. Quality stopped drifting — not because the new prompt was cleverer, but because changes were now measured instead of guessed.
Beware prompts that work brilliantly on the example in front of you. A prompt tuned on one input often overfits to it. Always check a new version against a handful of cases you have seen before, including the awkward ones.

Good prompting is task specification. Say who is writing and for whom, supply the material, use a precise verb, state your constraints and format, and show an example when the shape is unusual. Break big jobs into stages. Keep test cases and measure changes.
The skill that transfers is not prompt phrasing — it is the older, less glamorous ability to describe a piece of work clearly. Anyone who has written a good brief for a colleague already has most of it.
If your output is disappointing, resist the urge to try a different model first. Read your prompt back and ask what a careful stranger would still have to guess. Then answer that, and try again. To understand why these techniques work at all, see our explainer on how language models actually work.
Tap a star to share what you thought.
No ratings yet
It is the practice of specifying a task to an AI model precisely enough to get consistent, usable output. In practice it looks less like finding magic words and more like writing a clear brief: role, material, task, constraints and format.
Modestly, and mainly because it implies an audience and a register. A more useful version names the reader rather than the writer: 'explain this to a non-technical manager' constrains the output far more than 'you are an expert'.
As long as the information required, and no longer. Prompts fail more often from missing constraints than from brevity, but padding a prompt with irrelevant context measurably degrades output. Include what changes the answer; cut what does not.
Sign in to join the conversation.
Loading responses…
Have a story, idea, or something valuable to share? Join The Blog Story for free, publish your content, reach more readers, and earn a share of advertising revenue from eligible content.
Create quality content. Grow your audience. Grow your earning potential.
Including one or more worked examples of input and desired output in the prompt. It is the fastest way to teach an unusual format or a specific style, and it usually beats describing the same format in prose.
Because the model samples from a probability distribution rather than always taking the top choice. Setting temperature to zero, where the tool exposes it, makes output much more repeatable for factual and extraction tasks.
Yes, for anything with distinct stages. Extract, then analyse, then write produces better results than one instruction asking for all three, and it lets you see exactly which stage failed when something goes wrong.
Supply the source text, instruct it to answer only from that text and to say when the answer is absent, and verify anything consequential outside the model. Prompting reduces fabrication; it does not eliminate it.
Keep a small set of real test inputs and run every candidate prompt against all of them. Judging a change on the one example you were annoyed by is how prompts slowly get worse while appearing to get better.