Instructions vs. examples
The two channels for telling a model what you want, what each is best at — and the crucial rule that when they conflict, examples usually win.
You have two channels for specifying behavior: instructions (describe what you want) and examples (show what you want). They're not interchangeable, and misusing them causes a whole family of mysterious failures.
What each channel is best at
- Instructions excel at rules and boundaries: 'never mention competitors', 'refund limit is $200', 'output must be valid JSON'. Crisp, enumerable, checkable. (JSON: a simple text format software can read — Module 2 introduces it; for now just copy the shape shown.)
- Examples excel at the unstatable: tone, formatting nuance, how to handle ambiguity, where the line sits between 'complaint' and 'inquiry'. Things you'd struggle to write as rules but recognize instantly.
- Instructions are cheap to change — edit a line. Examples are heavier: each one costs tokens on every single call, forever.
The precedence rule nobody tells you
When instructions and examples disagree, the model usually follows the examples. It is an imitation engine before it is a rule-follower. If your instruction says 'reply in formal English' but your three examples are breezy and contraction-filled, you'll get breezy. If your instruction says 'output JSON only' but an example includes a chatty preamble, expect preambles.
A prompt evolves: someone edits the instructions but not the old examples. The two now disagree, the examples silently win, and the team concludes 'the model ignores instructions'. It doesn't — it obeys the stronger signal. Audit rule: every time you change an instruction, re-read every example for contradictions.
Seeing it in the triage project
Classify this customer email as one of: COMPLAINT, INQUIRY, RETURN_REQUEST, ORDER_STATUS, OTHER. Rules: any email that mentions damage is COMPLAINT, even if it also asks a question. Example 1: "My order arrived with a cracked bowl — can I get a replacement?" → RETURN_REQUEST Email to classify: "The trivet showed up scratched. Do you have it in black?"
Run this. The instruction says damage → COMPLAINT; the example demonstrates damage → RETURN_REQUEST. Most models follow the example. Fix the example, and the rule starts working. This is the whole lesson in one artifact.
The division of labor for the rest of this course: instructions carry the rules, examples carry the style and the boundary cases — and a regular audit keeps them agreeing. Module 3 covers choosing and ordering examples; Module 5 gives you the eval harness that catches disagreements automatically.