Prompt engineering: how to write better AI prompts

Most bad AI output is not a model failure. It is an underspecified request. "Write a product description" contains no audience, no length, no tone, no format and no constraints — so the model fills all five gaps with the most average choice available, and returns something that reads like every other product description on the internet.

Prompt engineering is the unglamorous skill of closing those gaps. This guide is built around rewrites: three weak prompts, the specific reason each fails, and the version that works. If you only read one section, read that one.

What prompt engineering is

Prompt engineering is specifying a task precisely enough that the range of acceptable answers is narrow. It is closer to writing a brief for a contractor than to programming — and the failure mode is the same one you get from a vague brief: technically responsive, practically useless.

It is worth saying what it is not. It is not a set of magic phrases, and it is not stable across every model. What transfers between models is the underlying discipline: say who the answer is for, what it must contain, how it must be shaped, and what it must avoid.

The five parts of a prompt that works

Every prompt implicitly answers these five. You either answer them, or the model does.

1. Role — the perspective to write from. Useful when it is specific ("a technical reviewer checking this for factual errors"), useless when it is decoration ("a world-class expert").
2. Task — one verb, stated plainly. Summarise, rewrite, classify, extract, compare. Prompts that bundle four tasks produce a shallow pass at each.
3. Context — the material the answer must be based on. This is the single highest-leverage part, because anything you supply is far more reliable than anything the model recalls.
4. Output format — length, structure, and shape. "Three bullets, under 20 words each" is a specification. "Keep it brief" is a hope.
5. Constraints — what to avoid, what to do when information is missing, which sources are off-limits. The instruction to say "not stated" rather than guess prevents a large share of invented detail.

Three rewrites, before and after

Rewrite 1 — a product description

Before: "Write a product description for our new water bottle."

Why it fails: No audience, no length, no differentiator, no tone. The model has nothing to work with except the phrase "water bottle", so it returns generic copy assembled from a million other listings.

After:

Write a product description for an insulated steel water bottle, for a marketplace listing.

Audience: commuters who have had a bottle leak in a bag.
Length: 60–80 words.
Format: one opening line naming the problem it solves, then three bullets of concrete specifications.
Facts to use, and use only these: 750 ml, keeps drinks cold 24 hours, leak-tested lid, dishwasher safe, 380 g.
Tone: plain and factual. No superlatives, no "revolutionary", no exclamation marks.

The change that does most of the work is the fixed fact list. It gives the model something real to write from and removes the space in which it would otherwise invent a feature.

Rewrite 2 — summarising a document

Before: "Summarise this report."

Why it fails: Summarise for whom, and for what decision? A summary for a finance director and a summary for an engineer share almost no sentences.

After:

Summarise the report below for an operations manager deciding whether to approve next quarter's budget.

Include: the three findings with cost implications, any stated risk, and the recommended action.
Exclude: methodology and background.
Length: under 150 words.
If the report does not state a recommended action, write "No recommendation stated" rather than inferring one.

That last line is the important one. Without it, a missing recommendation gets filled in with a plausible invention — and it will read exactly like the rest of the summary.

Rewrite 3 — extracting structured data

Before: "Pull out the key details from these emails."

Why it fails: "Key details" is undefined, and the output shape will vary between runs, so nothing downstream can parse it.

After:

Extract these fields from each email and return a JSON array, one object per email, with no text before or after the JSON.

Fields: sender_name (string), company (string), request_type (one of: quote, support, complaint, other), deadline (ISO date or null).

If a field is not present in the email, use null. Do not infer values.

Naming the exact keys, constraining request_type to a fixed set, and specifying null for missing values turns free text into something a script can consume. Paste the result into the JSON formatter to confirm it parses before you wire it into anything — a stray line of commentary before the array is the most common reason this breaks in production.

Techniques that measurably help

• Show an example of the output. One worked input-and-output pair does more than three paragraphs of description. Two or three examples do more again, particularly for classification and formatting tasks.
• Ask for reasoning before the answer on multi-step problems. Requesting the working first, then the conclusion, improves accuracy on arithmetic and logic. It does nothing for simple retrieval or rewriting, where it just adds length.
• Specify the schema, not just the format. "Return JSON" gets you JSON with unpredictable keys. Naming the keys and their types gets you something parseable.
• Give it an exit. "If the answer is not in the text provided, say so" converts a class of confident inventions into a useful non-answer.
• Iterate on one variable at a time. Changing four things and seeing a better result teaches you nothing about which change caused it.
• Put long reference material before your instruction. With a large pasted document, instructions at the end are followed more reliably than instructions buried above it.

Things people believe help, but do not

• Politeness and pressure. "Please" and "this is urgent, my job depends on it" do not change capability. They add tokens.
• Stacked expert roles. "You are a world-class senior expert" is decoration unless it is followed by something specific about what that expert would check.
• Very long prompts. Past a point, additional instructions compete with each other and the model follows some and drops others. Precision beats volume.
• Reusing one prompt across every model. Formatting behaviour and instruction-following differ. Re-test when you switch.
• Asking the model to check its own facts. It will confirm its previous answer far more often than it will catch its own error. Verification has to come from outside — a source, a test, or a person.

How long should a prompt be?

Long enough to remove ambiguity, short enough that every line is doing work. In practice, useful task prompts tend to land between 50 and 200 words. Below that, something in the five parts is usually missing; well above it, instructions start to conflict.

Length matters for a second, more concrete reason: context windows are finite and priced. If you are pasting a long document alongside your instructions, the instructions compete for the same budget. Checking a reusable prompt template against the word counter is a quick way to see whether it has quietly grown to 600 words of overlapping guidance — which happens to almost every prompt that gets edited repeatedly over a few months.

Prompt engineering FAQ

Do these techniques work on every AI tool?

The five parts transfer everywhere, because they are about specification rather than about any model's quirks. Specific phrasings and formatting behaviour do not transfer, so re-test a critical prompt after switching models.

Why does the same prompt give different answers?

Because output is sampled from a probability distribution rather than chosen deterministically. Where the tool exposes a temperature setting, lowering it makes results more repeatable. See how generative AI produces an answer for the mechanism.

Should I write prompts in English?

Not necessarily, but current models are generally strongest in English because of training data volume. If output quality in another language is poor, testing the same prompt in English will tell you quickly whether the problem is your prompt or the language coverage.

Is prompt engineering a real job?

It has largely stopped being a standalone title and become a component of other roles — support, marketing, analysis, engineering. The durable skill is precise task specification, which was valuable before these tools existed.

How do I stop it inventing facts?

Supply the facts in the prompt and instruct it to use only those, then require an explicit "not stated" for anything missing. You cannot eliminate invention, but constraining the model to material you provided removes most of the opportunity.

What is the fastest way to improve a prompt I already have?

Add one worked example of the exact output you want. Across most task types that single change outperforms any amount of rewording the instructions.

Start here

Take a prompt you use regularly and check it against the five parts. In almost every case one is missing — usually the output format or the instruction for what to do when information is absent. Add that one part, run it again, and compare. That is the whole practice.