Few-shot examples are a type system you haven’t written down
Every example in your prompt makes a claim about the shape of a correct answer. Three examples make three claims. If the claims disagree, the model, not you, decides which one is the real spec.
Ask a prompt engineer what their examples do and they’ll say “show the model the format.” That’s true and radically incomplete. Examples don’t just show format - they define it, with more force than any instruction, because they’re evidence rather than assertion. The model treats your examples the way a compiler treats type declarations: as ground truth about what this function returns.
§1The schema you implied
Put two examples in a prompt and you’ve made a set of implicit declarations: which fields appear, in what order, how long each runs, what tone the prose takes, whether edge cases get hedged. You never wrote this schema down. But it exists, it’s inferable, and the model infers it, including the parts you didn’t mean. If both examples happen to be about billing, “topic: billing” quietly joins the schema too.
There is no neutral example. Every shot either demonstrates a rule or amends one.
§2Inconsistent shots are type errors
# Examples $EXAMPLE refund_request - input:: I want a refund for order 4471. - good:: Started your refund for 4471. It lands in 3-5 days. $EXAMPLE angry_escalation - input:: This is the third time I've called! - good:: I hear you. Let me get a manager on the line now. - summary:: escalated to a human // structure/bad-example: only "- input::", "- good::", and "- bad::" // fields belong in $EXAMPLE angry_escalation - "- summary::" is neither.
When shots disagree, the model doesn’t average them - it picks a winner per request, weighting whichever example most resembles the incoming message. That’s why inconsistent examples produce the most maddening failure mode in prompting: intermittent format drift that no single transcript can explain. The bug isn’t in any example. It’s in the disagreement between them.
§3Examples override prose
When an instruction and an example conflict, the example wins most of the time - evidence beats assertion. “Always include a summary line” followed by an example without one doesn’t read as a rule plus a typo. It reads as a rule plus a documented exception, and the model will happily generalize the exception. The corollary cuts the other way too: a rule you can’t write an honest example for is a rule you don’t fully believe yet.
§4Writing shots like declarations
- Declare the schema first, then instantiate it. State the output shape as a rule; make every example a perfect instance. Examples demonstrate the spec - they never carry information the spec lacks.
- Vary exactly one axis per shot. Topic, difficulty, or tone - never several at once. An example that differs from its sibling in five ways teaches five lessons, four unintended.
- Cover the sad path on purpose. One shot where the right answer is “refuse and redirect” teaches boundaries better than three MUST rules.
- Diff on every edit. Examples rot faster than rules - each “quick example tweak” is a silent schema migration. Test it like one.
TypeGlish’s $EXAMPLE blocks are checked at compile time: each must carry a complete, consistent shape - a required - input:: and - good::, with - bad:: optional. A block that drops a required field or adds one it doesn’t define is a structure/bad-example error, caught before anything ships.