The patterns that work

Pattern 1 — Few-shot examples

The simplest and most powerful pattern. Instead of describing what you want, you show the model two or three examples of the input and the output you want. The model picks up the pattern far more reliably than from a description.

Use it when: the task is repetitive, the desired output has a specific style or structure, or you cannot easily describe what you want but can demonstrate it.

Task: classify customer-support emails by urgency.

Without examples (zero-shot):
"Classify the following support email as Urgent, High, Normal,
or Low."
→ Result is variable. The model's idea of "urgent" may not match
yours.

With examples (few-shot):
"Classify the following support email as Urgent, High, Normal,
or Low. Examples:

Email: 'I can't log in and my exam starts in 20 minutes!'
Classification: Urgent

Email: 'My invoice from last month seems to have the wrong VAT
number — can someone check?'
Classification: Normal

Email: 'Could you confirm whether team plans include the
analytics export feature?'
Classification: Low

Now classify this one:
Email: [paste the new email here]
Classification:"
→ The model now classifies the way YOU classify, not the way
some generic notion of urgency would.

Two or three examples are usually enough. More can help marginal cases. Beyond five or six, additional examples start producing diminishing returns and can over-constrain the model.

The failure mode: if your examples are inconsistent, the model picks up the inconsistency and produces inconsistent classifications. Curate your examples carefully.

Pattern 2 — Chain-of-thought

For problems that require multi-step reasoning — arithmetic, logic, planning, complex analysis — telling the model to "think step by step" or to show its working produces meaningfully better answers. This is the technique that started the "reasoning models" wave in late 2024.

Use it when: the task has multiple logical steps, the model has been making careless errors, or you want to be able to inspect its reasoning to catch mistakes.

Without CoT:
"A bookshop has 240 books. 35% are fiction. Of those, 20% are
hardback. How many hardback fiction books are there?"

Even capable models sometimes slip on a problem like this.

With CoT:
"A bookshop has 240 books. 35% are fiction. Of those, 20% are
hardback. How many hardback fiction books are there?

Solve this step by step. Show each calculation, then give the
final answer on a separate line."

→ The model now:
   Step 1: 35% of 240 = 84 fiction books
   Step 2: 20% of 84 = 16.8 hardback fiction books
   Answer: approximately 17 (or 16.8 if fractional books are allowed).

You can now spot if any step is wrong, instead of just trusting
the final number.

Modern reasoning models (Claude's extended thinking, OpenAI's o-series, Gemini's reasoning modes) effectively do this automatically. But explicit chain-of-thought still helps with general-purpose chat models on complex tasks.

The failure mode: chain-of-thought can produce long, plausible-sounding reasoning that is nevertheless wrong. The model can fabricate a step. Check the reasoning, not just the final answer.

Pattern 3 — Structured output

If you want the model to produce output you can use programmatically — feed into a spreadsheet, paste into a database, parse with a script — ask for it in a structured format. JSON, CSV, YAML, Markdown tables. The model handles these formats reliably.

Use it when: the output needs to be processed by code or another system, you are running the same task many times and want consistent shape, or you want to extract specific fields from unstructured input.

"Given the customer email below, extract the following fields
and return them as JSON:
- customer_name (or null if not mentioned)
- product_name
- issue_category (one of: technical, billing, feature_request,
  complaint, other)
- urgency (one of: urgent, high, normal, low)
- suggested_next_step (one short sentence)

Return only the JSON. Do not include any other text.

Email:
[paste the email here]"

→ Result:
{
  "customer_name": "Anya Patel",
  "product_name": "Premium plan",
  "issue_category": "billing",
  "urgency": "high",
  "suggested_next_step": "Confirm refund eligibility and reply within 24h"
}

This is now usable in a spreadsheet, in a workflow, or in
another tool.

The failure mode: occasionally the model adds explanation text before or after the JSON, which breaks parsers. The fix is to instruct it explicitly: "Return only the JSON. Do not include any other text or commentary."

Pattern 4 — Decomposition

For complex tasks, instead of one big prompt that tries to do everything, break the work into smaller prompts that each do one thing. The smaller prompts produce more reliable results, are easier to debug, and are easier to recombine.

Use it when: the task has multiple distinct sub-tasks (research, then analyse, then write), the model is producing inconsistent quality across parts of one big response, or you need to inspect or fix intermediate outputs.

Bad: one big prompt
"Research the three main UK-based AI chip companies, compare them
on funding, technology, team size, and partnerships, and write me
a one-page memo with a recommendation on which is most worth
watching."

This is too much. The model will rush some parts and over-explain
others.

Better: four smaller prompts
1. "List the three most-prominent UK-based AI chip companies in
   2026. For each, give me name and one-sentence description."
   → review/correct the list

2. "For [company X], summarise: latest funding round (year, amount,
   lead investor), core technology, team size, three biggest
   partnerships. Cite sources where possible."
   → repeat for each of the three companies; review each

3. "Compare these three companies on the four dimensions above.
   [paste the structured summaries from step 2.]
   Produce a comparison table."
   → review

4. "Based on the comparison above, draft a one-page memo for a
   senior strategist. Conclusion-first. The recommendation should
   be the most-watchable company and why."
   → review

Each step is checkable. If step 2's facts are wrong, you fix them before they pollute steps 3 and 4. This is more time-consuming than a single prompt but produces dramatically better results for non-trivial tasks.

The failure mode: decomposition without quality-checking each step gives you wrong intermediate results that cascade into wrong final results. The pattern works because of the quality-checking at each step, not just the breakdown itself.

Pattern 5 — Negative examples

Showing the model what you do not want is sometimes more useful than showing it what you do want. Particularly for tone, style, and avoiding AI clichés.

Use it when: the model keeps producing a style you don't want despite positive instructions, you have seen specific bad outputs you want to head off, or you are debugging a prompt that "almost works".

"Rewrite this product description in a clear, direct, professional
voice.

Examples of voices to AVOID:

AVOID: 'Get ready to be absolutely blown away by our revolutionary
new platform that's going to transform the way you work!'
(too much hype)

AVOID: 'The product enables users to optimise their workflow through
seamless integration of best-of-breed capabilities.'
(corporate jargon)

AVOID: 'This is honestly the simplest solution we could think of. It
just works. We hope you like it.'
(too informal, undermines the product)

Aim for the level of: a confident colleague describing what the
product does to a smart friend, neither hyped nor falsely modest.

Here is the product description to rewrite:
[paste it here]"

Negative examples take more space than positive instructions, but they are far more effective at heading off the specific failure modes you have seen the model produce.

The failure mode: too many negative examples make the prompt long and over-constrained. Use them surgically — for the two or three things the model would otherwise definitely get wrong.

Combining the patterns

The patterns are not mutually exclusive. Real prompts often combine three or four of them. A classification task might use few-shot examples (Pattern 1), structured JSON output (Pattern 3), and one negative example to head off a common misclassification (Pattern 5). A complex analysis task might use decomposition (Pattern 4) with chain-of-thought inside each step (Pattern 2).

Knowing the patterns by name and purpose lets you reach for the right one when you need it, instead of randomly trying things until something works.

Looking ahead

Lesson 4 is about what happens when a prompt does not work. How to iterate. How to debug. How to A/B test two prompts against each other. How to build a personal prompt library that compounds your skill over months and years.