2.3 Prompt Engineering Techniques
2.3.1 Three Techniques, Three Different Jobs
Ask three different colleagues to complete the same unfamiliar task and they'll each ask you for something different. The person who's done it a hundred times just wants the instructions — they'll figure out the rest. The person who's never done exactly this wants to see one worked example so they know what "done" looks like. And the person facing a genuinely tricky judgment call wants to think out loud with you before committing to an answer. Claude behaves the same way across three prompting techniques, and Task Statement 2.3 is about recognizing which situation you're in before you reach for a technique.
Zero-shot is instruction only — you describe the task and Claude does it, no examples attached. It's the right default for simple, unambiguous tasks, and it's also the cheapest and fastest option, so it should be your starting point, not something you graduate away from reflexively. Few-shot adds a handful of worked input/output examples to the prompt — you're not just telling Claude what to do, you're showing it, which locks in a specific format or a hard-to-describe edge case far more reliably than prose alone. Chain-of-thought asks Claude to reason step by step before answering — either through explicit prompting ("think through this step by step") or through the model's extended-thinking capability from Lesson 2.1 — and it earns its place on tasks that genuinely require multi-step reasoning, math, or complex judgment.
| Technique | What it is | Best for |
|---|---|---|
| Zero-shot | Instruction only, no examples | Simple, unambiguous tasks — the default starting point |
| Few-shot | A handful of input/output examples | Locking in a specific format or edge-case behavior |
| Chain-of-thought | Reasoning step by step (explicit prompting or extended thinking) | Multi-step reasoning, math, complex judgment |
Three techniques matched to three different failure modes — none of them is a universal upgrade over the others.
The one idea to hold onto
Zero-shot, few-shot, and chain-of-thought are matched to task difficulty and ambiguity, not applied as a ladder you climb by default. Start from zero-shot; add few-shot when format/edge cases need demonstrating; add chain-of-thought when the task genuinely requires multi-step reasoning.
2.3.2 The Trap: Reaching for a Technique You Don't Need
Here's where the exam gets pointed. All three of these techniques cost something. Few-shot examples cost tokens on every single request — and there's a subtler cost too: over-anchoring, where the model latches onto surface features of your examples that weren't the point you were trying to teach. Chain-of-thought and extended thinking cost latency and billed output tokens. None of that is a reason to avoid them — it's a reason to use them only when the task's difficulty actually warrants the price.
Picture a simple sentiment classifier: is this one-line review positive or negative? Adding four worked examples and asking the model to reason step by step before answering doesn't make that classification meaningfully more accurate — the task was never ambiguous. It just makes every request slower and more expensive for a quality gain you can't measure, because there wasn't a real gap to close. Reflexively reaching for the fancier technique is the single most common misapplication the exam tests: more sophistication is not automatically more correct.
The technique should track the actual difficulty of the task, not a general instinct toward "more sophisticated is safer."
2.3.2 — Exam Trap
Adding few-shot examples or chain-of-thought reflexively — as if they're always an improvement — is the recurring distractor. Examples cost tokens and can over-anchor the model; CoT/extended thinking adds latency. Use each technique only when the task's difficulty genuinely warrants it, and default to zero-shot otherwise.
2.3.3 Clarity Beats Cleverness — And Positive Beats Negative
Technique choice is one axis of prompt design; how you WRITE the instruction is another, and it matters just as much regardless of which technique you're using. The first principle is unglamorous but decisive: instruction clarity beats cleverness. Be specific about the exact output you want and its exact format. A terse, clever instruction that leaves the desired shape of the answer to inference produces variance — different runs land in subtly different places, because you left room for the model to guess, and it will guess differently each time.
The second principle is about framing, not detail: positive instructions beat long negative lists. "Respond only in JSON matching this schema" tells the model exactly where to land. A long list of "don'ts" — don't add commentary, don't use markdown, don't include extra fields, don't explain your reasoning — only narrows what's forbidden; it never actually specifies the target. It's the difference between giving someone a destination address and giving them a list of streets not to turn down. One gets you there directly; the other leaves the actual route to guesswork.
- •✗ Vague/clever: "Summarize this well." ✓ Specific: "Produce a 3-bullet summary, each bullet under 20 words, covering only the decision, the owner, and the deadline."
- •✗ Negative list: "Don't add commentary. Don't use markdown. Don't include fields not in the schema." ✓ Positive instruction: "Respond only in JSON matching this schema: {...}"
- •✗ Assuming more detail is automatically clearer. ✓ Clarity comes from specificity and structure, not sheer length.
2.3.3 — Key Concept
Instruction clarity beats cleverness — be specific about the desired output and format. Positive instructions ("respond only in JSON matching this schema") beat long negative "don't" lists, which only narrow the forbidden space without specifying the actual target.
2.3.4 Placement: Where the Instruction Sits in a Long Prompt
There's a structural detail that matters specifically once your prompt includes long input material — a lengthy document, a big block of retrieved context, a transcript. With long inputs, the key instruction is more effective placed AFTER the material, near the end of the prompt, rather than before it. If the instruction comes first and then gets followed by thousands of tokens of document text, that instruction risks getting diluted by everything the model processes afterward before it starts generating a response.
Think of it as giving directions right before someone starts driving versus giving them at the start of a long briefing they'll sit through first. The directions given right before the drive are fresh and immediately actionable; the ones given at the start of a long briefing have to survive everything in between. So the pattern for long-input prompts is: material first, then the instruction, positioned right where the model is about to start producing its answer.
# Weaker for long inputs: instruction buried before a big document
Summarize the following in 3 bullets, focusing on financial risk.
<document>...12,000 tokens of contract text...</document>
# Stronger for long inputs: instruction placed after the material
<document>...12,000 tokens of contract text...</document>
Based on the document above, summarize it in exactly 3 bullets, focusing on financial risk.2.3.4 — Key Concept
With long inputs, place the key instruction AFTER the material, near the end of the prompt. This reduces the risk of the instruction being diluted by everything the model processes afterward before it starts generating.
2.3.5 Improve Prompts Like an Experiment, Not a Guess
Everything so far has been about writing a good prompt from scratch. The last principle is about improving one you already have, and it's the difference between engineering and superstition. Deliberate iteration means: change one thing at a time, measure the change against an eval set (the real subject of Domain 4), and keep what wins. A prompt edit you haven't measured against something is a guess dressed up as an improvement.
The failure mode here is changing several things in the same revision — rewording the instruction, adding an example, and reordering a section, all at once — and then seeing the output get better. Which change caused it? You genuinely don't know, and you can't reliably apply the lesson to the next prompt you write. Isolate one variable, run it against your eval set, and only then decide whether to keep it. This is slower per-edit but faster overall, because every kept change is actually understood rather than superstitiously carried forward.
- 1.Change ONE thing — a single instruction, a single example, a single reordering.
- 2.Measure the result against a fixed eval set, not a vibe check on a couple of examples.
- 3.Keep the change only if it wins on the measurement; discard it if it doesn't, even if it "felt" like an improvement.
- 4.Repeat — the next change is isolated from this one, so its effect stays attributable.
2.3.5 — Common Exam Traps
Assuming a longer or more detailed instruction is automatically clearer — clarity is about specificity and structure, not length. And iterating on several prompt changes in the same revision, which makes it impossible to attribute a quality change to any one specific edit.
Where this shows up on the exam
2.3 questions describe a task and ask which technique fits, or describe a prompting mistake (reflexive few-shot/CoT, a negative-list instruction, an instruction buried before a long document, multiple simultaneous changes) and ask for the fix. Match technique and phrasing to the actual difficulty and structure of the task — don't default to the more elaborate option.
Key Takeaways
- ✓Zero-shot (instruction only) is the right default for simple, unambiguous tasks — start here, don't graduate away from it by default.
- ✓Few-shot (a handful of worked examples) earns its token cost when a format or edge case is hard to describe in prose; it can also over-anchor the model.
- ✓Chain-of-thought (explicit step-by-step prompting or extended thinking) earns its latency cost on genuinely multi-step reasoning, math, or complex judgment.
- ✓Adding few-shot or CoT reflexively to a simple task is the recurring exam trap — more sophistication is not automatically more correct.
- ✓Instruction clarity beats cleverness (be specific about output and format); positive instructions ("respond only in JSON matching this schema") beat long negative "don't" lists.
- ✓With LONG inputs, place the key instruction AFTER the material, near the end, so it isn't diluted by everything processed before generation begins.
- ✓Iterate deliberately: change one thing at a time and measure against an eval set — an unmeasured multi-change edit can't be attributed to a specific cause.
Check Your Understanding
Test what you learned in this lesson.
Q1.A team classifies short, unambiguous product reviews as positive or negative. To "improve accuracy," an engineer adds four few-shot examples and asks the model to reason step by step before answering. What is the likely outcome?
Q2.An instruction reads: "Don't add commentary. Don't use markdown. Don't include extra fields. Don't explain your reasoning." What is the more effective way to phrase this?
Q3.A prompt places the instruction "summarize the risks in 3 bullets" at the very top, followed by a 15,000-token contract. Output quality is inconsistent. What change addresses this?
Q4.While improving a prompt, an engineer rewrites the instruction, adds two few-shot examples, and reorders a section — all in the same revision — then observes the output quality improved. What is the problem with this approach?
Practice This Lesson