Few-Shot Prompting: Examples That Fix Bad Output

Few-shot prompting is the fastest fix for output that is technically correct and completely unusable. You asked for a professional tone and got LinkedIn slop. You asked for a product description and got a paragraph that could describe anything. The problem is not the model. You described the output instead of showing it.

The term comes from the research literature — the 2020 paper that named it showed that models learn tasks from examples given in the prompt itself, with no retraining. Four years later it is still the highest-leverage technique available to a non-technical user, and most people still do not use it.

Zero-shot, one-shot, few-shot#

The decision is about whether a correct answer shape exists. If there is a house format, show it. If you are exploring, do not anchor the model to anything.

Why examples beat adjectives#

"Professional but approachable" is a phrase four people will interpret four ways. So will a model. It has read millions of documents that were described that way and will produce their average.

Two paragraphs of your actual writing carry sentence length, rhythm, vocabulary, how you open, how you handle objections and what you never say. None of that survives compression into adjectives. This is why the single best asset you can build for AI work is a small library of your own best outputs.

How to pick examples#

The examples define the pattern, so choosing badly poisons everything downstream.

Pick your best, not your most recent. The model matches quality as well as format.

Make them diverse. Three examples of the same scenario teach the model to expect that scenario. Vary the input, keep the output shape constant.

Keep them short. Trim to the part that carries the pattern. Long examples waste context and bury the instruction.

Include an edge case if one matters. If your format changes when there is no price, show one example with no price.

Check them for the flaws you hate. If two of your three examples open with a rhetorical question, the output will too.

A real marketing example#

Weak prompt:

Write product descriptions for our catalogue in a professional,
engaging tone. About 50 words each. Here are the products: ...

Few-shot version:

Write product descriptions matching these examples exactly in
structure, length and voice.

INPUT: Merino base layer, 200gsm, 4 colours, 89 EUR
OUTPUT: Merino at 200gsm, the weight that works from October
to April. Four colours, all of which survive a wash cycle you
forgot about. 89 EUR, and it will outlast three synthetic
layers at half the price.

INPUT: Rain shell, 3-layer, taped seams, 240 EUR
OUTPUT: A three-layer shell with taped seams, which is the
boring detail that decides whether you stay dry. 240 EUR.
Not the lightest jacket we sell. The one you will still own
in five years.

Now write descriptions for: [your products]

The second version produces usable copy on the first attempt. The first version produces something you rewrite.

When few-shot is the wrong choice#

Creative exploration. If you want angles you have not thought of, examples anchor the model to what you already do. Go zero-shot first, pick a direction, then add examples to execute it.

When your examples are bad. No examples beats bad examples. If the only samples you have are the copy you are trying to escape, write one good one by hand first.

Very long inputs. With a large document already in context, examples compete for attention. Prefer a short explicit format spec.

Tasks where correctness matters more than shape. For analysis and reasoning, structure the thinking instead. See chain-of-thought prompting.

Few-shot for classification#

The underrated use. If you are tagging support tickets, scoring leads or routing enquiries, examples are far more reliable than definitions:

Classify each message as: BILLING, TECHNICAL, SALES, SPAM.

"My card was charged twice" -> BILLING
"The export button does nothing on Safari" -> TECHNICAL
"Do you have a plan for 50 seats?" -> SALES
"Increase your DA with our backlinks" -> SPAM

Classify: [messages]

Two examples per category, edge cases included, and accuracy climbs sharply. This is the pattern behind most of the useful AI automations I build for clients, and it slots straight into an n8n workflow.

Building your example library#

The teams that get the most from this technique treat examples as an asset, not as something they retype. Here is how to build one in an afternoon.

Step 1: pick the five outputs you produce most. Emails, product descriptions, social posts, briefs, reports. Anything you write more than twice a month.

Step 2: find the best real example of each. Not the most recent, the one you would show a new hire as the standard. If none exists, write one properly once. That hour pays for itself within a week.

Step 3: strip identifying details. Replace client names and figures with realistic placeholders so the examples can be shared across the team without a privacy conversation.

Step 4: label the pattern. Above each example, write one line on what makes it good: "opens with the objection, one number, no adjectives." That line helps the humans as much as the model.

Step 5: store it where the model reads it automatically, not in a document somebody has to remember to paste.

Review the library quarterly. Examples age: one written for last year's positioning will quietly drag every output back toward last year's positioning.

Mistakes that ruin few-shot prompts#

• Inconsistent formatting between examples. If one uses a dash and another uses a colon, the model picks one at random.
• Examples that contradict your instructions. The examples win. Always. Fix the examples, not the instruction.
• Too many examples. Past five or so, you are spending context without gaining accuracy for most tasks.
• Unbalanced classes in classification. Six SPAM examples and one BILLING teaches a bias you did not intend.
• Leaving client data in examples. Anonymise. Examples get copied into shared prompts and travel further than you expect.

Make it permanent#

Once a set of examples works, it should never be retyped. Store it where the model reads it automatically: a Claude Project with the examples attached, or a Skill that carries the examples inside the procedure. That is the step that turns a good afternoon into a team standard.

The full workflow — context, examples, constraints, evaluation — is laid out lesson by lesson in my free prompt engineering course, and Anthropic's prompt engineering docs are the best free reference for going deeper. If your team needs this applied to your own briefs rather than to examples from a blog, that's what my AI training packages do.