Prompt engineering
Prompt engineering is the practice of writing clear instructions, examples and formats so language models produce reliable results. Learn the techniques that work.
Overview
Prompt engineering is the craft of writing the text you send to a language model so that it does what you want, reliably. A prompt can contain instructions, background, examples, the input to work on and a description of the output format. Small changes in any of these can change the result a great deal. Prompt engineering is the habit of making those choices deliberately and testing them, instead of guessing.
It is the cheapest way to change a model's behaviour. No training, no new data pipeline, no new infrastructure. You edit text and run it again. That makes it the first tool to reach for in almost every application, from a one-off script that summarises emails to a production system that classifies millions of support tickets.
A good analogy is briefing a capable new colleague who knows nothing about your company. If you say "sort out the report", you will get something, but probably not what you meant. If you say who the report is for, what decision it supports, what format to use, what to leave out, and show a past example you liked, you will get close to what you wanted on the first try. A prompt is that briefing.
What it is
Most effective prompts are built from a small set of parts. Not every prompt needs all of them.
| Part | Purpose | Example |
|---|---|---|
| Role or context | Sets the situation and audience | "You are reviewing contracts for a small business owner." |
| Task instruction | States exactly what to do | "List every clause that sets a payment deadline." |
| Constraints | Rules and limits | "Use only the text provided. Do not guess." |
| Examples | Show the desired pattern | Two input and output pairs |
| Input data | The material to work on | The contract text, clearly delimited |
| Output format | Shape of the answer | "Return a JSON list with fields clause and deadline." |
| Reasoning request | Room to think before answering | "Work through the clauses first, then give the list." |
In chat-based APIs these parts are usually split between a system message, which holds standing instructions, and user messages, which hold the current task.
Where it came from
Prompting as a way of controlling models became central with GPT-3. The 2020 paper "Language Models are Few-Shot Learners" from OpenAI showed that a large model could perform new tasks from a handful of examples placed in the prompt, without any weight updates. This was called in-context learning, and it made the wording and examples of a prompt a primary design surface.
In 2022 several important techniques were published. Chain-of-thought prompting from Google researchers showed that asking for intermediate steps improved reasoning. Self-consistency sampled several reasoning paths and voted. ReAct interleaved reasoning with actions such as searches, which became the basis of the ReAct loop used by agents. Also in 2022, instruction tuning with human feedback, as in OpenAI's InstructGPT work, made models follow plain instructions far better, so prompts could become more direct and less like puzzles.
Since then the field has matured. Providers publish prompting guides. Tools such as promptfoo test prompts against datasets, and frameworks such as DSPy optimise prompts automatically. The wider practice of assembling everything a model sees is now often called context engineering.
How it works
Step 1: Define success first
Write down what a good output looks like before writing the prompt. Collect ten to fifty real inputs and, where possible, the expected outputs. Without this, you cannot tell whether a change helped.
Step 2: Write a clear, direct instruction
State the task in plain words. Say who the output is for and why. Models follow explicit instructions better than hints. "Write three sentences for a busy executive" beats "keep it short".
Step 3: Separate instructions from data
Wrap input material in clear delimiters, such as XML-style tags or headed sections. This prevents the model from confusing your document with your instructions, and it limits the effect of instructions hidden inside data. See prompt injection defence.
Step 4: Add examples where the pattern is subtle
Examples, also called shots, show tone, format and edge cases faster than description. Use a few varied examples, not many near-copies. This is the idea behind few-shot learning.
Step 5: Specify the output format
Ask for a precise structure. If code will parse the result, use the provider's structured outputs feature or a strict JSON schema rather than relying on wording alone.
Step 6: Give room to reason when needed
For multi-step tasks, ask the model to think before giving the final answer, and keep the final answer in a separate, easy-to-parse section. Reasoning models do much of this by themselves.
Step 7: Test, compare and iterate
Run the prompt on your test set. Look at failures, change one thing at a time, and run again. Keep prompts under version control, like code.
Key concepts and terms
| Term | Meaning |
|---|---|
| System prompt | Standing instructions applied to every turn |
| Zero-shot | Asking for a task with no examples |
| Few-shot | Including a small number of worked examples |
| In-context learning | A model adapting to a task from the prompt alone |
| Chain of thought | Asking for intermediate reasoning steps |
| Delimiters | Markers that separate instructions from data |
| Prompt template | A reusable prompt with slots for variable input |
| Prefill | Starting the model's reply for it, to steer format |
| Temperature | A sampling setting that controls randomness |
| Prompt regression | A quality drop caused by a prompt or model change |
A worked example
An illustrative online shop wants to label incoming customer emails as refund, delivery, product question or other. They have 200 labelled emails for testing.
First attempt:
"Classify this email: {email}"
Accuracy on the test set: about 71 per cent. Outputs varied: "This is a refund request", "Refund", "REFUND - customer unhappy".
Second attempt, with a clear instruction and format:
"Classify the customer email inside the email tags into exactly one category: refund, delivery, product_question or other. Reply with the category name only."
Accuracy: about 84 per cent. Output format is now consistent.
Third attempt, adding definitions and three short examples, including a tricky case where a customer asks about delivery of a replacement after a refund:
Accuracy: about 92 per cent.
Fourth attempt, switching to a JSON schema with an enum of the four labels plus a one-line reason field, enforced by the API:
Accuracy: about 93 per cent, and zero parsing errors.
The numbers here are made up for illustration, but the pattern is typical. Most of the gain came from being explicit about the task and the format, then from well-chosen examples. Each change was measured against the same 200 emails.
Strengths and limitations
Strengths:
- Fast and cheap to change, with no training needed.
- Works with any model, including closed APIs.
- Easy to review, version and roll back.
- Often enough to reach production quality on well-defined tasks.
- Builds understanding of how the model behaves.
Limitations:
- Results can shift when the model version changes.
- Long prompts cost tokens on every call.
- Cannot add knowledge the model lacks; retrieval or tools are needed.
- Hard to guarantee behaviour on rare edge cases.
- Without a test set, improvements are guesswork.
How it compares with alternatives
| Approach | What changes | Cost to try | When it wins |
|---|---|---|---|
| Prompt engineering | Text of the request | Very low | First step for any task |
| Context engineering | All content assembled per call | Low to moderate | Agents and RAG systems |
| Automatic prompt optimisation, for example DSPy | Prompts tuned by an algorithm against a metric | Moderate | Pipelines with clear metrics |
| Prompt tuning | Learned soft prompt vectors | Moderate, needs model access | Open models, many similar tasks |
| Fine-tuning with LoRA | Model weights | Higher | Stable, high-volume tasks where prompts plateau |
Practical guidance and best practices
- Start with a test set and a metric before you start editing.
- Be explicit and specific. Say what to do, not only what to avoid.
- Explain the reason behind important rules; models generalise better from reasons.
- Separate instructions, examples and data with clear structure.
- Use a few diverse examples that cover edge cases.
- Enforce output structure with schemas when software reads the result.
- Change one thing at a time and keep a record of results.
- Re-test prompts whenever you upgrade the model; see evals.
- Keep prompts in version control and review them like code.
Common mistakes
- Vague instructions such as "make it better", with no audience or criteria.
- Piling on capital letters and threats instead of clear explanations.
- Using examples that are all similar, so the model copies their surface form.
- Mixing untrusted user text with instructions, without delimiters.
- Judging a prompt on two or three hand-picked inputs.
- Writing very long prompts full of rules the model already follows.
- Assuming a prompt that works on one model will work the same on another.
Frequently asked questions
Is prompt engineering still needed with stronger models?
Yes, though it looks different. Stronger models need fewer tricks, but they still need a clear goal, the right information and a precise output format. The emphasis has shifted from clever wording to clear specification and testing.
How many examples should I include?
Often two to five well-chosen examples are enough. More can help on subtle formats but cost tokens and can cause the model to copy surface details. Measure with your test set.
Should I tell the model it is an expert?
A role can help set tone and focus, especially when it describes the audience and context. On its own, a role line rarely fixes a weak instruction. Clear task details matter more.
What temperature should I use?
For extraction, classification and other tasks with one right answer, use a low value. For brainstorming or creative writing, a higher value gives more variety. Check your provider's defaults and recommendations.
How do I stop the model adding extra text?
Ask for the exact format, give an example, and if possible use structured outputs or a JSON schema. Prefilling the start of the reply, where supported, also helps.
When should I move from prompting to fine-tuning?
When the task is stable, you have many examples, and careful prompting has plateaued below your quality, cost or latency target. Fine-tuning can also shorten prompts for very high-volume use.
Glossary
- Prompt: the full text input sent to a language model.
- Instruction: the part of a prompt that states the task.
- Shot: one worked example inside a prompt.
- Schema: a formal description of the required output structure.
- Template: a prompt with placeholders filled at run time.
- Sampling: how the model picks each next token from its predictions.
- Injection: hostile instructions hidden in input data.
- Evaluation set: fixed inputs and expected outputs used to compare prompts.
Summary
Prompt engineering is the practice of writing clear, structured instructions, examples and format specifications so a language model produces the intended result. It became central when GPT-3 showed in-context learning in 2020, and grew with chain-of-thought, self-consistency and ReAct in 2022. Today it is less about tricks and more about clear specification, separating instructions from data, enforcing output structure and measuring every change against a test set. It is the first and cheapest lever in any AI application, and it works best alongside context engineering and, when needed, fine-tuning.
Related
It belongs to LLM concepts in my stack, under Generative AI and LLMs. Others in the same group: