Examples Are Fixtures You Ship on Every Request

The last lesson gave your feature a contract: role, constraints, output rules, written as clauses. Then you ship it, and a familiar frustration starts. The classifier keeps labeling angry-but-polite tickets as neutral. You sharpen the clause: "frustrated customers using polite language are still negative." Marginal improvement. You sharpen again, now with sub-bullets. The prompt grows; the boundary stays mushy.

Then you delete the paragraph, paste in three labeled tickets, and the problem mostly disappears. Everyone who works with these models hits this moment, and it's worth understanding rather than just cargo-culting, because the fix has a real cost model attached. The technique is few-shot prompting: worked input/output examples placed ahead of the live request. The backend frame that makes it click: examples are test fixtures, except they don't stay in your repo. They ship inside the payload, on the hot path, on every single request.

Why showing beats telling

Module 1's first lesson established the primitive: the model continues patterns. Instructions describe a behavior in prose the model must interpret; examples instantiate the behavior as a pattern the model extends. Three labeled tickets pin down format, tone, label boundaries, and edge handling simultaneously, because the pattern carries all four at once. Prose has to enumerate each dimension, and every sentence of enumeration is another clause competing for compliance.

This is old knowledge by LLM standards: the GPT-3 paper was titled "Language Models are Few-Shot Learners," and the effect has survived every generation since. Modern models need fewer examples than 2020's did, and instructions alone go further than they used to. What hasn't changed is where examples win: not for facts or hard rules, but for judgment boundaries and formats, the things that are easier to demonstrate than to define. Anthropic's multishot prompting guide reflects the same status: standard, first-line technique.

Instruction or example? A decision, not a style

Treat the choice as an engineering decision with a rubric, not a matter of prompt-writing taste:

The failure mode on each side is instructive. All rules and no examples yields the ever-growing clause pile from this lesson's opening. All examples and no rules yields a model that has inferred some pattern, but you don't know which one: maybe it learned "tickets mentioning refunds are negative" from fixtures you thought demonstrated tone. Rules anchor intent; examples pin the boundary. Production prompts almost always want both.

Choosing fixtures like a test suite

You already know how to pick good fixtures, because the discipline is test design:

• Cover the decision boundary, not the happy path. Three obviously-negative tickets teach nothing; the model handles those anyway. Spend your slots on the cases that were being misclassified: the polite-but-furious ticket, the sarcastic compliment.
• Include a hard negative. One example of "looks like X, is actually Y" does more boundary-setting work than two more centroids. Classic fixture design: the test that catches the bug you actually shipped.
• Diversity over volume. Five examples that are minor variations of each other define a narrower pattern than three that triangulate the space. Diminishing returns arrive fast; past a handful, you're paying tokens for repetition.
• Match production shape exactly. Fixtures that are cleaner, shorter, or better-punctuated than real tickets teach a distribution your traffic doesn't come from. Pull examples from real (sanitized) traffic, not from imagination.

Mechanically, examples can live in two places, and the choice matters enough to compare. As message pairs, each example is a fake user/assistant turn ahead of the live message; inline, examples sit as text inside one prompt block.

Treat the examples as typed data either way, because data can be validated, diffed, and (next lesson) versioned:

type FewShotExample = { input: string; label: Sentiment; note?: string };
 
// Fixtures as data, assembled as fake turns ahead of the live request.
export function withExamples(
  examples: FewShotExample[],
  liveTicket: string,
): Message[] {
  const turns = examples.flatMap((ex): Message[] => [
    { role: "user", content: `<ticket>${escapeTags(ex.input)}</ticket>` },
    { role: "assistant", content: JSON.stringify({ sentiment: ex.label }) },
  ]);
  return [
    ...turns,
    { role: "user", content: `<ticket>${escapeTags(liveTicket)}</ticket>` },
  ];
}

The token bill: fixtures ride the hot path

Here's where the fixture analogy stops being free. Test fixtures cost you at CI time; few-shot examples cost you on every production request, forever. Tokens are the resource you meter, and the bill is simple multiplication: five examples at 150 tokens each is 750 tokens per call. At a million calls a month, that's 750M input tokens spent re-teaching the model the same five facts.

Two mitigations, one architectural and one editorial. The architectural one: prompt caching. Both Anthropic and OpenAI discount input tokens that repeat as a stable prefix across requests, and cached input is charged at a fraction of the full rate (the economics lesson already leaned on this). Caching keys on prefix stability, which dictates your assembly order: static contract first, examples second, volatile per-request content last. One dynamic timestamp interpolated above your examples breaks the prefix and silently un-discounts every token below it.

// Assembly order is a caching decision, not a style choice.
// [ contract | examples ]  = stable prefix, cache-discounted after first use
// [ live input ]           = volatile tail, full price
const request = {
  system: renderSystemPrompt(triageContract),      // static
  messages: withExamples(EXAMPLES, ticket.body),   // stable turns, volatile tail
  maxTokens: 256,
};
// 5 examples x 150 tok = 750 tok/call.
// Uncached at $3/MTok: ~$2,250 per 1M calls just for fixtures.
// As a cached prefix (0.1x read rate): ~$225. Order pays 10x here.

The editorial mitigation: keep the set small and earn each slot. Three to five well-chosen examples is the working default; past that, measure before adding more, because each addition costs linearly and returns sublinearly. Whether example six actually moves accuracy is an evals question, and module 6 gives you the harness for it.

The prompt is now a compound asset

Step back and look at what the request side has become. A structured contract with clauses somebody argued about in review. A fixture set curated from production traffic, with a hard negative that encodes a real past bug. An assembly function that orders it all for cache economics, fences everything untrusted, and leaves slots for live data. That's not a string anymore; it's a small system, and every part of it can change behavior in production when edited.

Which raises the question the next lesson answers: where does this asset live, who reviews changes to it, and what happens when a change makes Tuesday's quality look worse than Monday's? The stack map promised prompts get treated like config that can take down prod. Time to pay that in full: versioning, deploys, and one-step rollback.

Key takeaways

• Few-shot examples are test fixtures that ship in the payload on every request: they demonstrate format, tone, and judgment boundaries that prose clauses define poorly.
• Rules vs examples is a rubric, not taste: hard constraints get instructions, format mimicry and judgment boundaries get examples, and most production prompts want rules anchoring a small example set.
• Pick fixtures like a test engineer: boundary cases over happy paths, one hard negative, diversity over volume, and shapes drawn from real traffic.
• A wrong example silently teaches the bug on every call. Review and re-review example sets like code; they never fail loudly.
• Examples cost tokens linearly forever. Order requests as static contract, then examples, then volatile input, so prompt caching discounts the fixture set instead of re-billing it per call.
• Three to five examples is the default; adding more is a measurable claim, and module 6's evals are how you measure it.