Few-shot prompting: teach AI by example

The fastest way to teach AI exactly what you want is not to describe it. It is to show it. Two or three concrete examples of the output you are looking for produce dramatically better results than the same instructions in words.

This technique is called few-shot prompting, and it is one of the highest-leverage tricks in the entire prompting toolbox. It is also dramatically underused by beginners, who try to describe the desired output with adjectives and end up frustrated when the model produces something close but not quite right.

This article walks through what few-shot prompting is, when to use it, and how to do it well — with worked examples.

Why examples work better than descriptions

Try this thought experiment. Suppose you want me to describe my company's tone of voice for marketing copy. I could say "friendly but professional, warm but not casual, confident but never arrogant, plain English but not dumbed down." After reading those four phrases, you would probably nod and then produce something quite different from what I actually wanted.

But if I instead showed you three short paragraphs we have written that I think hit the tone — and explained nothing — you would have a much clearer sense of how to write in that voice. You could probably reproduce it on the first try.

This is exactly how the model experiences your instructions. Adjectives like "friendly," "professional," and "confident" are vague. Concrete examples are specific. The model can pattern-match against examples; it has to interpret against adjectives.

This pattern has been studied in the literature on in-context learning — large language models are typically much better at generalising from a handful of examples than from descriptions of the same behaviour. It is partly why "show, do not tell" was always the right writing advice.

When to reach for few-shot

Some situations where examples will save you more than any other prompting trick:

Matching a specific tone. "Write in our company voice." If you cannot define the voice in three crisp adjectives, show two or three examples instead.

Producing consistent formatting. Anything where the output needs to look the same every time — product descriptions, error messages, API responses, weekly reports, status updates. Show the format, do not describe it.

Niche or unusual outputs. "Write a Twitter thread the way [a specific person you follow] writes them." "Generate headlines for an internal tool blog." "Write code comments the way our team writes them." These have specific conventions that are hard to articulate.

Replicating a style for translation, summarisation, or rewriting. "Rewrite this in the same style as these three examples I'll show you."

Anything you keep correcting in the same way. If you find yourself editing the model's output in the same direction every time — making things shorter, swapping a word, tightening structure — give it examples of the fixed version.

The basic structure

A few-shot prompt has three parts: a brief instruction, two or three examples, and the new task.

Generate a one-line product description for a B2B SaaS tool. Match the style of these examples.

>

Example 1: Product: ProjectHub Description: A shared workspace for project teams who are tired of switching between five tools to do one job.

>

Example 2: Product: TimeFlow Description: A time-tracking app for people who hate time-tracking apps.

>

Example 3: Product: ClearStack Description: A reporting tool that turns spreadsheets into decisions.

>

Now write one for: Product: PromptDesk Description:

The model will produce something that matches the style: short, opinionated, slightly cheeky, and structured around a specific complaint or audience. Without the examples, you would have got something generic. With them, you get something that fits.

Three worked examples

Let's walk through three real situations where few-shot transforms the output.

1. Bug report comments in your team's style

Suppose your team writes Jira tickets in a specific way — short, focused on user impact, no jargon. You want AI to draft tickets that match.

Draft a Jira ticket description following the format below.

>

Example 1: User logging in via Google sees a brief flash of the wrong language before the UI updates. Happens consistently on Chrome desktop. Not blocking, but feels janky.

>

Steps: 1. Sign out 2. Sign back in with Google 3. Observe initial page flicker

>

Expected: language stays consistent Actual: brief flash of (apparent default) English

>

Example 2: Export to CSV button returns an empty file on weekly reports >1000 rows. Smaller reports export correctly.

>

Steps: 1. Open weekly report with 1000+ rows 2. Click Export → CSV 3. Open downloaded file

>

Expected: full data Actual: file is 0 bytes

>

Now draft one for: Issue: Users on Safari say the mobile menu won't close after they tap a link. Refresh fixes it. Looks like a focus-trap issue.

The model will produce a ticket that matches the exact structure and tone, every time. Without the examples, you would get a slightly more verbose, slightly more formal version.

2. A brand-voice rewrite

Suppose you have a draft email and want it rewritten to match a brand voice. Telling the model "be warmer" produces uneven results. Showing examples produces consistent ones.

Rewrite the email below to match the voice of these examples. The voice is: direct, no corporate filler, slightly self-aware, never says "synergy" or "leverage."

>

Example 1: "We pushed the release back by a week. The autoscaling change was bigger than we thought. New ship date: Friday the 22nd."

>

Example 2: "Quick favour — could you sanity-check this draft? Specifically the second section. I think it's overreaching but I can't tell."

>

Example 3: "Heads up: I'm going to push back on the deadline in tomorrow's meeting. The math doesn't work and I'd rather flag it now than miss it."

>

Rewrite this in the same voice:

>

[paste your draft]

The model will produce something that sounds like the examples, not like generic corporate prose. You can save this prompt as a Custom GPT and reach for it any time you want a quick brand-voice rewrite.

3. Structured extraction

Suppose you have invoices in PDF and you want the model to extract them into a clean format. The classic move is to upload one, paste an example of the desired output, then ask for the rest.

Extract data from invoice PDFs in this exact JSON format.

>

Example:

>

Input: [invoice PDF where vendor is "Lufthansa", date is 2026-04-12, total is 423.50 EUR, line items are flight + bag fee]

>

Output: json { "vendor": "Lufthansa", "date": "2026-04-12", "currency": "EUR", "total": 423.50, "line_items": [ {"description": "Flight TLL-LHR", "amount": 387.00}, {"description": "Checked bag", "amount": 36.50} ], "category": "Travel" }

>

Now extract from this invoice: [attach new PDF]

You get clean, consistent output. Without the example, you would get JSON that varied in structure across invoices, which is a nightmare downstream.

Common mistakes with few-shot

Three mistakes to watch for:

Examples that contradict each other. If your three examples vary in style, the model will not know which to follow. Pick a tight, consistent set.

Too few examples. One example is often not enough — the model may treat it as a one-off. Two is usually the floor; three is the sweet spot for most tasks. More than five rarely helps and starts to eat your context window.

Examples that include errors you do not want copied. The model will faithfully copy whatever pattern your examples contain — including a typo, an awkward phrasing, or a structural choice you made by accident. Clean your examples before sharing them.

A particularly subtle mistake: showing examples of input but not output. "Here are three articles I want you to write headlines for: [three articles]." That is zero-shot, not few-shot. The model has not seen what a good headline looks like. Compare:

Here are three articles with the kind of headlines I'd like. Match the style:

>

Example 1: [article] → Headline: "..." Example 2: [article] → Headline: "..." Example 3: [article] → Headline: "..."

>

Now write a headline for: [new article]

The pair (input → output) is the unit of few-shot. Without the output side, the model has nothing to learn from.

How to build a library of examples

Once you start using few-shot, you will accumulate sets of "examples that worked." Keep them. Save them in:

• Custom GPTs / Claude Projects — paste the examples into the instructions field, and they live there permanently.
• A text snippet manager (TextExpander, Raycast, Espanso) — shortcuts that expand into your examples.
• A notes file organised by use case ("brand voice examples," "ticket format examples," "headline examples") that you can paste from quickly.

Six months of building this library and you will have a personal toolkit that no off-the-shelf "prompt pack" can match — because it is calibrated to your specific work.

The takeaway

When you can describe the output, describe it. When you cannot — when the output style is something you would recognise but cannot quite articulate — show two or three examples instead. Two minutes of finding good examples will save you twenty minutes of correcting the wrong-style output that no description would have prevented.

Examples beat adjectives. Almost no one does this. The few people who do consistently get better AI output than the people who write longer, cleverer descriptions. Try it on your next prompt where the style matters — and watch what happens.