Prompting
A practical guide to prompt engineering
The same AI can give you a useless answer or an excellent one, depending on how you ask. Here are the techniques that reliably move you from the first to the second.
Talking to an AI is a skill, and a surprisingly quick one to learn. The AI has no idea what is in your head; it only responds to what you actually type. So the clearer your request, the better the result. Five habits do most of the work:
- Be specific. Say what you want, who it is for, how long, and in what tone. "Write a friendly 3-sentence reply to this customer" beats "reply to this".
- Give it the facts. Paste the email, the notes, the details. Do not assume it knows your situation.
- Show an example. If you want a certain style or format, show one good example of it.
- Ask it to think it through on harder problems: "explain your reasoning step by step".
- Iterate. Look at the answer, then say what to change. It is a conversation, not a vending machine.
Do these and you will get noticeably better results than most people, from exactly the same AI.
A prompt is your input to the model; prompt engineering is shaping that input on purpose. Because the model only has what you give it, small changes in wording and context change the output.
The core techniques
- Specificity: state task, audience, tone, length and format. Ambiguity is the main cause of bad answers.
- Context: provide the relevant material directly. This is often more important than clever wording, deciding what to include is context engineering.
- Examples (few-shot): one to a few worked examples steer style and structure. With no examples (zero-shot), rely on a clear instruction, which is enough for common tasks.
- Reasoning (chain-of-thought): for multi-step problems, ask it to work step by step; it measurably improves accuracy.
- Constraints: ask for a table, bullet points, or a fixed length when you need structure.
- A role (optional): "act as an editor" nudges tone, though clear instructions usually help more than a persona.
A simple recipe
- State the task and the goal.
- Give the needed context.
- Specify format and constraints.
- (Hard task?) Ask for step-by-step reasoning.
- Read, then refine.
Watch out for
Vague prompts invite the model to invent (hallucinate). The more you pin down the task and supply real context, the less room it has to go wrong, and always verify anything important.
Prompt engineering exploits in-context learning: a pretrained model adapts to a task from the prompt alone, without weight updates (Brown et al. 2020). The practical levers map to that mechanism.
Levers, and when they matter
- Instruction quality (zero-shot): with instruction-tuned models, precise specification does most of the work; zero-shot is the default for common tasks.
- Demonstrations (few-shot): most valuable for strict formatting, niche tasks, and eliciting reasoning; sensitive to example selection, ordering and label balance (documented recency/majority biases).
- Elicited reasoning (chain-of-thought): improves multi-step accuracy by adding test-time computation and an explicit scratchpad (Wei et al. 2022); variants include self-consistency (marginalise over sampled paths). Note reasoning models increasingly internalise this.
- Context engineering: as instruction-following improved, the binding constraint shifted from phrasing to what goes in the window, retrieval, ordering, compression, positional placement (models neglect mid-context content).
- Decoding controls: low temperature for deterministic/factual tasks, higher for ideation.
- Structured output: enforce schemas/JSON when software consumes the result; often separate a free reasoning phase from a constrained final emission.
The trajectory
The field is moving from phrasing tricks toward specification, context engineering and evaluation, deciding what to put in the window and measuring whether the output is correct, because robust systems are built on tested prompt templates and evals, not one-off cleverness. Persona and wording tricks yield diminishing returns as models improve; clear specification, grounding (retrieval/tools) and verification do not.