Prompt engineering patterns

Six or seven patterns do most of the work. Once you know them, "prompt engineering" stops feeling like incantations and starts feeling like UX design.

What prompt engineering actually does

A prompt is the briefing the model gets before it answers. Same model, same question, two different briefings — and you'll get two very different answers. Prompt engineering is the small set of repeatable moves that shift the briefing from vague to crisp: showing examples, asking for step-by-step reasoning, locking the output format, separating data from instructions.

It is not a bag of magic tricks. The patterns map directly to how you'd brief any junior teammate — the only weird part is that the teammate is a statistical text predictor that takes you very literally.

That's the whole concept. Below: the seven patterns that do most of the work, plus the anti-patterns that look clever but don't help.

When you'd reach for it

Whenever model output is going somewhere downstream and quality matters:

• Extraction — pulling structured fields (vendor, total, dates) out of free-form documents.
• Classification — assigning categories or labels with consistent edge-case behaviour.
• Customer-facing assistants — establishing tone and scope through the system prompt.
• Anything with a defined output schema — JSON for code, Markdown for docs.

You wouldn't reach for heavy prompt engineering on one-off creative or exploratory queries — for those, just ask. The work pays off when you're running the same prompt thousands of times.

The patterns that move the needle

1. Zero-shot vs. few-shot

Zero-shot: just describe the task. Works for common tasks. Few-shot: show 1–10 worked examples first. Almost always better when the task has a specific format, edge cases, or domain-specific style.

Extract company names from each line.

Input: Apple released a new iPhone.
Output: Apple

Input: Microsoft and OpenAI extended their partnership.
Output: Microsoft, OpenAI

Input: <new line>
Output:

2. Chain-of-thought (CoT)

Tell the model to think step by step before answering. Materially improves accuracy on reasoning tasks.

A train leaves Paris at 09:00 going 80 km/h. Another leaves Lyon at 09:30 going 100 km/h
in the opposite direction. Paris and Lyon are 460 km apart. When do they meet?

Think step by step, then give the final answer on a line starting with "Answer:".

Modern reasoning models (Claude with extended thinking, OpenAI's o-series) automate CoT.

3. Role / persona prompting

Establish the role explicitly:

"You are a senior staff engineer specialising in distributed systems. Be terse, technical, and skeptical."

Reliably tilts the output style.

4. Structured outputs

Don't ask the model to write JSON in free-form. Use the API's structured-output feature — JSON mode, tool-calling with a schema. The provider constrains generation server-side.

5. XML / delimited inputs

Multiple inputs? Tag them clearly:

<context>…retrieved docs…</context>

<question>What's the refund policy?</question>

Models follow these reliably (Claude was post-trained heavily on XML). Also makes prompt injection harder.

6. Self-consistency

Run the same CoT prompt several times at non-zero temperature, take the majority answer. Useful when there's one right answer but the path is variable.

7. Iterative refinement

Two passes: draft, then critique-and-revise. Cheap quality boost on writing tasks.

Where it bites in real life

Under the hood (optional)

A real-world invoice extractor stacks several patterns: role + rules in the system prompt, a few worked examples, structured-output schema, low temperature. Below is what that looks like assembled. Skip if you don't code — you've already met every pattern in the lesson.

SYSTEM = """You are an AP clerk extracting invoice data.
 
Rules:
- Output exactly the JSON schema provided.
- If a field is missing, set it to null. Never guess.
- Currency must be ISO 4217 (e.g. "USD", "EUR", "GBP").
- Dates must be YYYY-MM-DD.
 
You will see worked examples first, then the real invoice."""
 
EXAMPLES = [
    {"role": "user",      "content": "<invoice>...</invoice>"},
    {"role": "assistant", "content": '{"vendor":"Acme Corp","total":1234.50,...}'},
    # ... 3 more pairs
]
 
response = client.messages.create(
    model="claude-sonnet-4-6",
    temperature=0,
    system=SYSTEM,
    tools=[{"name": "extract_invoice", "input_schema": INVOICE_SCHEMA}],
    tool_choice={"type": "tool", "name": "extract_invoice"},
    messages=[*EXAMPLES, {"role": "user", "content": new_invoice}],
)

Frequently asked questions

Does prompt engineering still matter with newer models?

Yes. Better prompts improve reliability, structure outputs, and reduce rework even with strong frontier models.

Do I need coding skills for prompt engineering?

No. Core prompt patterns are useful for non-coders, product teams, and engineers.

Further reading

• ChatGPT vs Claude for work (2026) — choose tools by workflow fit.

• Anthropic — Prompt engineering overview — definitive guide.

• OpenAI — Prompt engineering — equally thorough.

• Lilian Weng — Prompt Engineering — academic-leaning deep dive.

• Anthropic Cookbook — runnable examples of every pattern above.

• Chain-of-Thought Prompting — Wei et al. 2022 — the paper that put CoT on the map.