When examples beat instructions

You need every incoming support message classified as bug, billing, feature_request or other. You write the instruction carefully:

Classify this support message as bug, billing, feature_request or other.
Reply with only the category.

It works, mostly. Then you read the output and find Billing, "billing", feature request, and one reply that opens with "Sure! This message is about billing." That is four ways to break the parser you wrote around it.

You could keep sharpening the instruction: no capitals, no quotes, an underscore and not a space, no preamble. Or you could stop describing the output and show it:

Message: My card was declined again.
Category: billing

Message: The export button does nothing on Safari.
Category: bug

Message: Could you add dark mode?
Category: feature_request

Message: My card was charged twice this month.
Category:

The formatting problem disappears, because the model is now completing a pattern instead of interpreting a description. That is few-shot prompting: you demonstrate the mapping instead of describing it.

What few-shot changes

The intern-level course AI prompting: zero-shot Ruby taught you to specify precisely: the method signature, the return shape, the edge cases. That skill still matters here. Few-shot is what you reach for when the thing you need is hard to say but easy to show.

Examples are good at three things.

Format

Every example shows the output shape, down to the underscore. Nothing needs describing.

Implicit criteria

"Professional but not stiff" is a paragraph of instruction that different readers interpret differently. Three examples of your real tone settle it in a way no adjective can.

Boundary cases

Your team decided that "I was charged for a feature that doesn't work" is billing, not bug. That is a policy decision, and nothing about the language makes it so. One example encodes it.

Examples are not good at supplying knowledge. Showing three correct answers about your pricing doesn't teach the model your prices. That is retrieval, the subject of the three preceding courses. Few-shot shapes behavior; retrieval supplies facts. It is the same split as fine-tuning versus retrieval, at a much lower cost.

Zero, one, few

flowchart LR
  Z["Zero-shot: instruction only"] --> O["One-shot: + a single example"]
  O --> F["Few-shot: + several examples"]
  F --> D["Dynamic few-shot: examples chosen per request"]

The names only count demonstrations, and moving along the row doesn't improve results automatically. Each step adds input tokens to every request, and past a certain point it adds nothing but cost. Where the value stops is something you measure, and it is the subject of lesson 3.

The fourth box is where this course ends up. Instead of the same fixed examples for everyone, you choose examples per request, based on the input. That is a retrieval problem, solved with the vector search you spent three courses building.

The cost, stated plainly

Every example is input tokens on every request, forever:

instruction only                   ~50 tokens/request
instruction + 5 examples          ~400 tokens/request
× 100,000 requests/month          35,000,000 extra tokens/month

That is a real bill, and it is why few-shot is a trade and not a free upgrade. Two things make it cheaper than it looks. Prompt caching, from the RAG course, makes a stable example block much cheaper on repeat requests, once the cached prefix clears the model's minimum length (4,096 tokens on claude-haiku-4-5; shorter prefixes silently go uncached). And a good example set often lets a smaller model do the work: five examples in front of claude-haiku-4-5 often beat a bare instruction in front of a larger model, at a much lower per-token rate that can offset the extra example tokens.

What this course covers

1. When examples beat instructions (you are here).
2. The anatomy of a good example set.
3. How many examples, and which ones.
4. The three biases: majority label, recency, and common tokens.
5. When a schema replaces examples entirely.
6. Examples as data: building this in Rails.
7. Measuring, and keeping it from rotting.

Next: what separates an example set that works from one that quietly teaches the wrong thing.