Prompt engineering has accumulated an impressive amount of mystique. People write about it as though it were a specialist discipline with its own tools and jargon — temperature settings, chain-of-thought reasoning, persona injection, token counting. Most of it is overhead that obscures a simpler truth: the techniques that produce good AI outputs are exactly the techniques that produce good writing generally.
This article strips away the ritual and describes the actual principles.
Clarity before cleverness
The fundamental move is straightforward. The best improvement you can make to a prompt is to make it more specific.
A vague prompt produces a generic output because the AI has no information to narrow down the answer space. “Write an email” yields a press-release-sounding generic. “Write a follow-up email to a customer who was quoted £450 for a boiler service two weeks ago, reminding them to decide, keeping it friendly and direct, assuming they are busy and probably get a lot of email” produces something that sounds like an actual email from an actual business.
The difference is not in the magical phrasing. It is in the amount of constraint. You have supplied context the model would otherwise guess at.
The four things worth including in almost any prompt are the role, the audience, the constraints, and an example.
Role: what are you writing as? A journalist. A product manager. A technical support agent who specialises in home networking. A historical fiction writer set in the 1920s. Not everything needs a stated role, but if you are asking for something in a particular voice, stating it beats hoping the model guesses it.
Audience: who is this for? An engineer reading a research paper expects different language and depth than a schoolteacher explaining the topic to twelve-year-olds. The model performs better when you name the audience explicitly.
Constraints: what are the actual boundaries? Under 100 words. Three bullet points maximum. Explain it without using technical jargon. Include a call to action. Published in a UK publication. These are not flavour — they are critical structure. Every constraint you omit is a choice you are trusting to luck.
Example: show what good looks like. This is the highest-leverage move available. Paste in three sentences from a similar piece you’ve written, and the model will match the structure, length, and tone far more closely than it would from a written description. Most people skip this step because they assume it is obvious, and then wonder why the output sounds generic.
The things that don’t matter as much
Politeness. People sometimes add “please” and “thank you” to prompts as though they are talking to a person. The model responds identically. You can be polite if you enjoy it, but it changes nothing about the output.
Tone markers. Phrases like “You are a helpful assistant” or “Your job is to be creative” are noise. The model already knows it is an assistant. If you want creative output, ask for creative output in specific terms.
Emoji and formatting tricks. These circulate on social media as somehow unlocking better performance. They do not. They are placebo, and the time spent formatting is better spent describing the problem more clearly.
Temperature and other settings. For most users these are irrelevant. “Temperature” controls randomness; set it to zero for factual work, higher for brainstorming. That is the entire principle. Tweaking it to 0.73 because you read that somewhere changes nothing.
Iteration beats perfection
The first output is almost never the finished product. Telling the model what is wrong with it and asking for a specific change is usually faster and better than rewriting the prompt from scratch.
“That’s too formal for our brand” → output improves. “Cut the second paragraph and mention the warranty” → output improves. “Say why this matters to someone who is not technical” → output improves.
Three to five rounds of iteration, each with specific feedback, produces vastly better results than trying to engineer a perfect prompt first time. This is not a bug in your prompting. It is how writing works.
Hallucinations, and why they happen
Language models generate text by predicting the next word based on everything that came before. They do not look things up and they do not know whether something is true. When they output a plausible-sounding fact that is wrong, this is called hallucination.
The mistake is treating this as rare or surprising. A model that generates text word by word will occasionally generate confident nonsense. It is not a failure state; it is the baseline behaviour.
Three things reduce the frequency. First, specify that you want factual accuracy and state the stakes — “this will be published, so verify everything” changes the output. Second, give the model sources to work from — “based on the attached report” or “using only information from…” — and it will stick to those. Third, ask it to note uncertainty — “if you are not confident in a fact, flag it” — and then actually read the flags.
None of these eliminate hallucination. They change the incentives slightly. The only reliable defence is human review, and if the stakes matter, plan on spending that time.
When more context helps, and when it hurts
Adding context usually improves output. The model has more information to work with. But at some point adding more context makes the output worse, because the model loses focus.
The inflection point is roughly 2,000 words of context. Below that, more usually helps. Above that, it depends on whether the new information is relevant. Adding a 5,000-word technical spec when you are asking for a summary is noise. Adding a paragraph of background about your company when you are asking for company copy is signal.
One useful pattern: if you are pasting in a long document, add a line asking the model to extract or focus on a specific part. “Look for decisions that affect the timeline” or “what changed from the previous version?” This acts as a filter and keeps the model focused.
The one setting that actually matters
Most systems let you choose the model you are using. There are usually three or four options, ranging from fast-and-cheap to slow-and-capable.
Use the fastest capable model for routine work and the most capable model for anything where quality matters. The speed difference is meaningful — a fast model returns in seconds, a capable one in thirty. The cost difference is much larger. A capable model often costs five to ten times as much per token.
For brainstorming, drafting, summarisation and routine tasks, the fast model almost always suffices. For anything requiring nuance, reasoning, or low error tolerance, the capable model earns its cost on the first use.
This is the single setting where your choice materially affects the output, and it is the one people least often think about.
A simple prompt template
You do not need a template, but here is one that works for a wide range of tasks:
You are [role]. Write [task] for [audience]. Constraints: [limits]. Here is an example of the tone and style: [paste sample]. Additional context: [what they need to know].
For example:
You are a senior product manager at a B2B SaaS company. Write an email to a customer whose contract renews in 30 days, prompting them to decide. The customer has used the product for three years and has never complained. Keep it to under 200 words, friendly and direct, one clear call to action. Here is an email we sent before that worked well: [paste]. We want to emphasise the new reporting feature added in version 4.2.
Three minutes of thoughtful writing in the prompt saves half an hour of editing the output.
The meta-skill
The actual skill of working with AI is not prompt engineering. It is clear thinking. People who write good prompts are people who have already thought through what they are asking for. The prompt is just where that thinking becomes visible.
If you cannot write a clear prompt, the problem is not the tool. It is that you have not yet worked out what you actually need.