What prompt engineering actually is.
Prompt engineering is the practice of designing inputs to large language models so they produce reliable, high-quality, on-target outputs. It's part programming, part interviewing, part writing.
An LLM is a probability machine. It samples the most likely continuation of your text. Everything you put in front of it — your role assignment, the context you give, the structure you impose, the examples you provide — shifts those probabilities. The prompt isn't a request. It's a configuration.
"You are not asking the model. You are programming the distribution it samples from."
Why it matters now
- Cost — a tight prompt uses fewer tokens and avoids retries.
- Quality — the gap between a casual prompt and an engineered one is often the gap between a useless and a deployable answer.
- Reliability — engineered prompts make output consistent across runs, which matters the moment you put an LLM in a workflow.
- Portability — prompts engineered with structure transfer cleanly between models when you switch providers.
The six components of a great prompt.
Almost every world-class prompt has these in some form. Drop one and quality drops with it.
1. Role / Persona
Anchor the model in an identity. Be specific — "senior copy editor with 15 years at major broadsheets" beats "good writer" by a wide margin.
2. Context
What the model needs to know to do the job: the audience, the situation, the surrounding data, the constraints of the world the answer lives in.
3. Task
The actual instruction in imperative voice. One core task per prompt. If you have three, write three prompts.
4. Constraints
Length, tone, things to avoid, things to always include, language, formality. Constraints are what stop hallucinations and meandering.
5. Output format
Bullet list? JSON? Markdown table? 3 paragraphs of 50 words each? Be ruthless. Models will improvise format unless told.
6. Examples (few-shot)
One or two input→output pairs is the single highest-leverage move you can make. Examples teach faster than instructions.
// Universal skeleton
## Role
You are a [specific role with relevant expertise].
## Context
[What the model needs to know.]
## Task
[Imperative instruction.]
## Constraints
- [Length, tone, format, taboos.]
## Output Format
[Exact structure.]
## Example
Input: [...]
Output: [...]
## Now do this:
{{INPUT}}
Techniques, ranked by leverage.
Not all techniques are equal. These are the ones that consistently move the needle.
Zero-shot
Just the instruction, no examples. Fine for simple tasks. Falls apart on anything nuanced.
Few-shot prompting
Provide 1–5 input→output examples. The model pattern-matches your examples better than it follows your prose. If you only do one thing on this list, do this.
Chain-of-Thought (CoT)
Add "think step by step" or, better, walk through one example reasoning chain. Massively improves math, logic, and multi-step problems.
Role prompting
"You are a..." with specificity. Pulls the model into the relevant region of its training distribution.
Self-consistency
Run the same prompt N times with temperature > 0, take the majority answer. Brutal but effective for high-stakes tasks.
ReAct (Reason + Act)
Interleave reasoning steps with tool calls. The model thinks, acts, observes, repeats. Foundation of every serious agent.
Tree of Thoughts
Have the model explore multiple reasoning branches and prune. Heavy, but the right tool for genuinely hard problems.
Negative prompting
Tell it what NOT to do, explicitly. "Do not use the words synergy, leverage, or robust." Works.
Prompts that think.
For any task with reasoning, math, planning, or multi-step logic, you cannot just ask for the answer. You have to give the model space to work.
The think-then-answer pattern
First, think through the problem inside <scratchpad> tags.
Consider edge cases. List your assumptions.
Then provide your final answer inside <answer> tags.
This works because it gives the model tokens to compute with before committing. The "scratchpad" output you can discard; the answer is what you keep.
Decomposition
If a problem has 3 sub-problems, ask the model to identify and solve each separately, then synthesize. Keeps reasoning legible and debuggable.
Self-critique
Ask for an answer. Then ask the model to critique its own answer. Then ask it to revise based on the critique. Quality lifts noticeably.
"Reasoning is just giving the model permission to write more before deciding."
Per-model quirks.
Different models reward different structures. Same prompt, different results — sometimes drastically.
Claude
Loves XML tags. Use <role>, <task>, <context>, <examples>. Place the most important instruction first. Excellent at following long, nuanced prompts.
GPT-4 / 5
Markdown-first. ## headers, numbered lists, bullet points. Responds well to explicit "step 1, step 2" instructions and to "You are..." persona openings.
Gemini
Examples-first. Lead with 1–2 concrete input/output demonstrations before stating the task. Be explicit about format. Strong at multimodal — feed it images and PDFs directly.
Llama / open
Keep it tight. Effective attention is shorter. One example, clear task, exit. Works best with system prompts that establish role early.
Mistral
Direct, instructional. Likes clean markdown, dislikes role-play wrappers. Prefers brevity over verbose context.
Universal
Markdown sections, no model-specific syntax, explicit format spec, one example. Portable across providers when you don't know which one will run it.
Iteration and evaluation.
You don't write a great prompt. You iterate to one. Treat it like code: ship, observe, refactor.
The iteration loop
- Run the prompt on 5–10 representative inputs.
- Score each output against a rubric you write down. Be honest.
- Diagnose the worst output. Ask why it failed — missing context? wrong format? ambiguous task?
- Patch the prompt to fix that specific failure.
- Re-run. Make sure the patch didn't break the cases that worked.
Eval rubrics
Pick 3–5 axes that matter for your task: correctness, format adherence, tone, length, safety. Score each output 1–5 on each. Track averages over time.
LLM-as-judge
For scale, use a stronger model to score outputs from a weaker one against your rubric. Imperfect but tractable.
"The best prompt engineers are also the best at admitting their prompt is bad and fixing it."
Pitfalls and how to avoid them.
Vague roles
"You are an expert" is empty calories. Specify the domain, the seniority, the context. Specificity is the difference.
Compound tasks
Asking the model to do six things in one prompt produces mediocre output on all six. Split it.
No format spec
If you don't specify format, the model invents one. Expect inconsistency. Always state structure.
Implicit assumptions
If you assume the model knows your audience, your tone, or your taboos, it doesn't. Make every assumption explicit.
Over-prompting
Stuffing every constraint, edge case, and exception into one prompt creates noise. Cut what isn't load-bearing. Test.
Trusting the first run
The first output looks great because you have nothing to compare it to. Run the prompt 5 times — the variance is what tells you whether your prompt is reliable.
Ignoring the model
A prompt engineered for GPT-4 may flop on Gemini. Test on the actual model you'll deploy on.