Welcome to Act 2, week 2. Last week we opened the box: an embedding became a distribution over the next token, and every arrow had a name. Today, two questions the mechanism alone can't answer — why does it ever go wrong, and once we know why, what do we deliberately do to steer it? Block A is the diagnosis; Block B is the engineering, and in a course called AI-supported software development, Block B is the half that matters most.

Frame the two halves and make them spatial — students should SEE the diagnosis / controls split. The five pattern names go into working memory now, before the diagnostic half begins; they are what students carry out of the lecture. Block A names the failures; Block B names the controls that answer them.

This is the sentence to carry through the whole lecture. Each time we meet a pattern, we state its one-line Lecture 5 mechanism. The prompting literature is full of folklore — "say please", "tell it it's an expert", "promise it a tip". We won't do that. If a pattern survives the next model generation, it's because the mechanism it exploits survives. Folklore doesn't survive; mechanism does.

Block A opens. Six chapters describing what fails about the model and why — all of it a consequence of one fact: the model is a probability distribution over the next token, conditioned on whatever is in its context. We refuse to call any of it a bug.

This is L5 recap compressed to one slide. Emphasise: the model was NEVER trained to be correct; it was trained to predict likely continuations. Code generation, Q&A, translation, instruction-following — all emergent from "the right pattern is in the distribution given this prompt."

Point forward from each card: "no truth" → hallucination (§4); "no grounding" → factual hallucinations; "no memory" → why CLAUDE.md is context, not config; "no goals" → why RLHF is shaping, not commanding. Everything in Block A is a consequence of this single fact.

You have never used a base model. Give a base GPT-style model "What is the capital of France?" and two of the most likely continuations are "Paris." and a list of more capital-of questions — both abundant in training. The base model has no preference. Students need to see this before we explain SFT and RLHF: post-training creates the assistant preference; the architecture does not.

Post-training = SFT (teaches the format) + RLHF (teaches preferences). Neither teaches facts. Depth guard per hints: do NOT derive PPO, GRPO, or reward-model training — students need WHAT, not HOW. Same architecture as pre-training throughout; only the distribution of training contexts changed.

The conceptual hinge of Block A. Every student misconception about RLHF — "it teaches the model to be truthful" — dies on the right-hand column. Post-training shifts STYLE and BEHAVIOUR far more than KNOWLEDGE. The right column predicts §4–§7: hallucination, compliance drift, jailbreaks.

Short beat — deliver the line and let it land. The single most common student misconception about post-training. The confident style is layered on top of a base distribution with no truth check — the falsehood can be flat OR a sharp, confident peak; that combination is exactly what makes a modern hallucination dangerous.

EXTENDED. Signals that the field is moving beyond PPO but the principles of §3 hold. R1 is more directly relevant to chain-of-thought than to the general post-training story — we'll return to it in §13.7.

Let the quote sit. Then: "The next slide makes this visible." The mechanism that produces a perfect validate_email and the one that produces a non-existent endpoint are the SAME mechanism — only the shape of the conditional distribution differs.

THE teaching visual for §4. Walk the left chart: lots of "capital of France" in training → peaked, Paris near-certain. Walk the right: no specific endpoint in training → flat, many near-equal options. The model samples from whichever shape it gets; there is no ground-truth check and no "I don't know" token that wins by default — so it completes the pattern anyway. That can be a flat guess OR a confidently-wrong sharp peak; either way it is the hallucination. Mystery 1: resolved.

Anchor each card in an Act 1 example students have seen: Factual → Stack Overflow challenge; Structural → Locust exercise; Confident-nonsense → the requests example. Three categories, three different mitigations — not all hallucinations are alike.

Stress that each category needs a different response: retrieval (factual), grounding/schema (structural), verification (confident-nonsense). Foreshadow the three-layer model from §8. Mystery board: resolves invented endpoints, hallucinated signatures, and confidently-wrong explanations simultaneously.

Quick consolidation. ~30 min mark. Then: "Next — why CLAUDE.md sometimes feels like it doesn't exist."

Quick framing. Students used CLAUDE.md in Act 1 — they have experience with inconsistent compliance. This slide names the problem; the next three explain it. Everywhere we say "CLAUDE.md," mentally substitute "your tool's instruction file" — the analysis carries over unchanged.

Walk the three bars. At 1K tokens CLAUDE.md is half the context; at 150K it is 0.3%. Attention at every step is a row-wise softmax over the whole sequence — softmax is winner-take-most, so the instruction file's share of positions shrinks but a learned-important token can still win strongly; it just competes with more newer, local tokens. There is no "config priority": the instruction file is just more text. This is context-drift arithmetic, not a failure of the file or the loader.

High cognitive load — keep the visual clean. Different heads attend to different parts of context; some specialise in recent tokens, some in positional patterns. Treat as a QUALITATIVE mechanism, not a precise prediction — we cannot say which heads route to which rule in a model whose internals are not public. CLAUDE.md compliance is probabilistic because head allocation is.

Let this land. This is why compliance is inconsistent — and why the three-layer model, two slides away, insists on enforcement and human layers alongside the influence layer. The model is doing exactly what its mechanism says: most attention on the most recent, most task-relevant context.

EXTENDED. The economic argument for prompt caching + the mechanism argument for why cached instructions still influence (they're in the KV cache, attending to new tokens). Keep KV caching and prompt caching apart: KV is per-request and automatic; prompt caching is the cross-request lever that makes a big AGENTS.md cheap.

EXTENDED. Visual complement to the caching table. The red dot at pos 500 lines up vertically across all three rows: the model's view of AGENTS.md hasn't moved — caching only changes what must be recomputed.

Liu et al. 2023. The model retrieves best from the beginning and end of context; the middle is a dead zone — a 20+ pp drop. Chroma's "context rot" (2025) confirms it across 18 frontier models. Striking because attention is global — the positional preference is an empirical fact of trained models, not a prediction of the architecture.

Translate the U-shape into actionable rules: front-load, keep concise, repeat critical items. These also apply to system prompts in API usage. One caveat: rules a linter/hook can enforce belong in the enforcement layer, not the influence layer — CLAUDE.md is for conventions tooling cannot decide.

The framework that closes Block A and carries through the course. The value is not in the three layers but in how they fit: you cannot replace one with more of another. Influence alone is fragile; enforcement alone is brittle (a linter can't tell you the function does the right thing); human alone doesn't scale. Production uses all three.

This table is the analytical lens the exercise uses — students classify prompt strategies into which layer they serve. "You cannot replace one layer with more of another." Mention the teaching-repo asymmetry briefly: a missing enforcement layer is most visible when it is missing.

Transition beat. "Take a break if you need one — we're about to switch from why it fails to how to steer it." The answer is a small library of named patterns, each with a one-line mechanism and a citation.

~55 min mark. Five claims. If you remember nothing else from Block A, remember these. Block B builds controls on top of each one.

Block B opens. The positive space. Every pattern here is a deliberate use of an L5 mechanism to make the distribution sharper around correct answers. We open with the simplest control — temperature — then in-context learning, few-shot, chain-of-thought, self-consistency, role priming. Real theory, with citations.

You saw softmax in L5. Temperature adds ONE parameter applied to the logits before softmax. T < 1 sharpens (greedy end); T > 1 flattens (creative end); T → 0 is argmax. This is the first engineering control — the sampling-time knob.

Walk each chart. T=0.1: nearly deterministic — always the top token. T=1.0: the trained distribution, the default. T=2.0: almost random — good for brainstorming, terrible for correctness. The dial above shows where each T sits on the peaked↔flat scale.

Match temperature to the task. Code that must compile → low T. Generating test-case variations → higher T. Production chat default is T ≈ 0.7 — covers "want a good answer, don't need a unique one."

Don't memorise the table. Trace one row: 'potion', logit 4.2. At T=0.1 its probability ≈ 1.0; at T=2.0 it drops to 0.35 and 'fire' rises to 0.20. Same logit, different temperature, dramatically different sampling. T only re-weights; it cannot promote 'fire' to the top — only the logits can.

This is why T=0 code generation sometimes produces spectacularly wrong output with total confidence: the first wrong token locks in the wrong direction. Greedy gives the per-step argmax, not the most-probable sequence — beam search escapes some traps but is rarely used (repetitive 'beam search curse').

Temperature is necessary but insufficient. Missing context that under-specifies the task isn't supplied by any T — the model still fills gaps from learned priors. Temperature controls the shape of sampling, not the quality of the distribution. The patterns in the next chapters shape the distribution itself. (Temperature experiment available for self-study.)

EXTENDED. The name 'temperature' comes from statistical mechanics — same math, different domain. This is why the engineering regimes have such clean limits: they're the Boltzmann limits since the 1870s, applied to a discrete vocabulary.

This is the substrate of few-shot prompting. The model doesn't change — the context changes, and attention routes differently. There is no piece of the training objective that says "follow demonstrations"; ICL was one of the central findings of the GPT-3 paper.

2020, the GPT-3 paper — the moment few-shot prompting became a serious engineering tool. Small models barely benefit from in-context examples; GPT-3-scale models benefit dramatically — 10–30 points on some benchmarks. Block B's patterns work because the model you call is large enough to do ICL.

No magic. The examples are tokens; attention is over all tokens; the model's query at the new position routes to the example outputs. That's the mechanism. The next slide makes the routing literal — induction heads.

This sounds trivially simple. It is. The remarkable fact is that it is exactly the algorithm few-shot needs — and it emerges at a specific point in training (Olsson et al. trace a phase-transition "bump" in the loss curve where induction heads form). It is empirically traceable: real heads in real models.

Interaction beat. Ask the room to call the token before revealing the routing on the next slide. They should reach for "a colour" — because the pattern is fruit→colour, and the induction head routes from the second 'cherry' back to whatever followed the first one.

High cognitive load — walk slowly. Step 1: a head finds "I saw this input before." Step 2: another head copies "what came after it last time." Two heads working together = induction. This is why few-shot works: you are giving the induction heads material to match against.

EXTENDED. More examples reinforce that induction heads work across domains: function signature → return-type pattern; Q: → A: pattern. The head routes on structure, not semantics — which sets up Min et al.'s "format > content" result on the next slide.

The most counterintuitive result in the ICL literature. Random labels, still better than zero-shot. In induction-head terms: the heads still route to the position after the previous similar input; if the label there is random, the conditioning is "the format is label-shaped" without "the answer is X-shaped." Engineering consequence: invest in format, not perfect example answers.

Zero-shot on sentiment classification: the model doesn't know what format to respond in. The distribution is spread across many tokens — "positive", "negative", "the", "it". This is the baseline; the next slide adds two demonstrations and watches it sharpen.

Left: correct labels, peaked on 'positive' — expected. Right: RANDOM labels, still peaked — on a label, just not always the right one. The shape changed because the FORMAT was demonstrated, not because the correct answer was. The induction heads care about the positions of the demonstration outputs, not whether they were right.

The bridge to §12. When you paste three examples of your codebase's error-handling style, the model matches the format — naming, return patterns, type hints — because the induction heads route on structure. This is the principle that underpins all of few-shot practice.

~90 min mark. Checkpoint before the pattern chapters. §11 is the theoretical anchor for the five patterns.

The first technique card. All five share the same five-row shape — study it; it's the diagnostic lens the exercise uses. Zero-shot = "just ask." Works when the task is well-represented in training data; wrong tool when conventions or coverage matter.

Five rules. k=2–4 is the sweet spot. Order matters — best example last (recency). Format transfers more than content. Past ~8 you waste context. Few-shot fails when examples conflict or are off-distribution, and it is exactly the wrong tool when you lack known-good examples.

Same shape as zero-shot. Row 2 points back to §11 (induction heads); row 5 points forward to the §16 failure-mode table. Forward link to L7: a skill is a codified few-shot pattern loaded on demand.

The most practical takeaway from §12. In your Locust exercise, did you paste existing test functions before asking for new ones? That's few-shot — and it beats describing your conventions in prose. Forward link: L7 skills codify this.

Your Stack Overflow Challenge from Act 1. Zero-shot hallucinated the endpoint; few-shot with two correct calls fixed it; adding CoT ("list the APIs first") caught the hallucination before code generation. Each pattern is a different mechanism for shifting the distribution.

Two papers, one insight. Wei 2022: few-shot CoT. Kojima 2022: zero-shot CoT ("let's think step by step"). Both work because intermediate tokens become context for later tokens — the model effectively gets more compute per problem. The trigger phrase is itself a high-prior training pattern.

High cognitive load — walk it slowly. Direct: one pass, N layers, done. CoT: L intermediate tokens, EACH gets N layers; effective depth N×L. The scratchpad analogy: you wouldn't solve multi-step algebra in your head. This is a real expressivity result (Feng 2023; Merrill & Sabharwal 2023), not a metaphor.

Row 5 is critical. CoT is not free: it costs tokens, can cascade errors, and visible reasoning is not necessarily faithful. Exercise Card 12 is the anti-pattern — CoT overuse on a simple task.

This connects Block A to Block B. The API hallucination from §4 had no ground-truth check; CoT forces the model to name the API where induction heads can check it. The hallucination surfaces in the plan, not the code. For debugging, the dual is "trace, then conclude."

Four ways CoT hurts. (1) Don't ask it to "think step by step" about what day it is. (2) Wrong first reasoning step cascades. (3) CoT can't create knowledge. (4) The subtle one: visible reasoning isn't a faithful audit trail. Tests and review are the verification layer, not readable CoT.

EXTENDED. The theoretical depth. CoT provably increases the class of problems a fixed-depth transformer can solve. We state this but don't prove it.

EXTENDED. Forward pointer to the reasoning-model frontier. In production you'll increasingly use reasoning models that do CoT internally. Your job shifts from "prompt for reasoning" to "prompt for goals, constraints, criteria." Trained with RL against verifiable correctness, not just human preference.

Wang et al. 2022. Sample 5–10 CoT paths; take the majority. Individual paths are noisy; final answers concentrate. The wrong answer has to BE the mode to fool this. Variance reduction applied to reasoning — and the seed of the reasoning-model paradigm.

The fourth card. You rarely implement self-consistency manually — o1/R1 implement it internally. But the principle (multiple paths, majority vote) is the first test-time-compute-scaling idea. Fails when a systematic misconception is the mode.

EXTENDED. Deeper treatment of when consensus is a reliable signal. The agreement rate is not a calibrated probability — the model can be confidently wrong — but it's a useful diagnostic for deciding whether to escalate to the human layer.

Four patterns covered; one more (role priming) in the synthesis chapter. Then the pattern library ties everything together.

Structured outputs are the bridge between the influence and enforcement layers. Instead of asking for JSON, you constrain sampling to valid-JSON tokens (Outlines / Willard & Louf 2023). It guarantees shape, never content. Exercise Card 8 connects here.

Four situations where prompting is the wrong tool — all enforcement-layer problems. Exercise Cards 5, 7, 10 test this judgment: students must recognise when the answer is "don't prompt for this."

Connects §13.5 (CoT hurts) to the beyond-prompting picture. Exercise Card 12 is the anti-pattern: trusting visible CoT as if it were a proof. The enforcement and human layers are where verification lives.

EXTENDED. The right prompting pattern is a function of the model class. Reasoning models don't need CoT prompts; coding agents need goals + constraints, not step-by-step instructions.

EXTENDED. One slide on security. The model treats all tokens equally — which is why influence alone cannot provide security guarantees. The mitigation is permission design, sandboxing, output validation, secrets isolation, human review — most of it implemented in Lecture 7's orchestration layer.

The fifth and final card. Role priming is the most misused pattern — "you are an expert" without a rubric is folklore. Pair with a rubric and structured output. Exercise Card 3 demonstrates the full pattern.

Reference table — students will photograph this. Each row is one line: the mechanism column points back to L5; the citation column points to the literature. Every pattern reduces to attention, the auto-regressive loop, or sampling-time logit manipulation.

Interaction beat before the decision tree. The answer is few-shot (project-specific style/format → show examples). Let the room call it, then reveal the decision flow on the next slide.

Walk the tree top to bottom. Each branch maps to a task property. A simplification — real prompts combine patterns — but it gives a starting framework. The many named "patterns" in the literature are orchestration patterns built on these five.

The companion to the summary table. Every pattern fails in a specific, predictable way, traceable to an L5 mechanism. No pattern is uniformly safe.

The emotional beat. The prompting patterns are the influence layer — necessary but not sufficient. Enforcement (tests, CI, schemas) catches what prompting misses; human review catches what automation cannot encode. All three, together.

This is the method — four questions applied to any prompt. The exercise applies it to 12 real-world prompts. This slide is the setup; the next two are worked examples.

Card 3 is the model answer for role priming done right. Three ingredients: role, rubric, structured output. Remove any one and it degrades.

Card 12 is the anti-pattern. A simple task gets wrapped in "let's think step by step" — adding tokens, latency, and cascade risk. The right answer is zero-shot. More technique ≠ better.

Four amplifiers, not patterns. Rubric makes role priming concrete; structured output makes responses parseable; context grounding makes few-shot specific; validation catches what prompting misses. The 12 exercise cards span all four.

Point to the interactive quiz for individual self-study. In class, have pairs work 4–6 cards, then debrief 2 as a group (recommend Cards 3 and 12 — the ones we just walked). The exercises run outside the theory deck.

The closing. The mystery board from Lecture 1 onward — started before students had any of this vocabulary — almost fully resolved. Then the bridge to Lecture 7's orchestration layer.

Walk the table quickly — students have tracked these since the board was introduced. Ten solved; one (mystery 8 — orchestration) partly solved, awaiting L7. The framing of Act 2: learn the mechanism, and the surprises stop being surprising. Promise kept.

Brief. Skills are codified few-shot patterns — L7 formalises what we started today. MCP is the tool-use protocol. SWE-Bench is how the field measures end-to-end agent quality. The influence layer gets an orchestration layer.

Deliverables and next steps. The exercise is the centrepiece — do it in pairs. Temperature experiment is self-study. Reflection log due by next session. Optional reading for the curious. Exercises run outside the theory deck.

If you remember one thing from today, it's this. Prompting is the influence layer — necessary, powerful, and insufficient. The full stack — influence + enforcement + human — is how production systems work.

Thank you. Act 2 is nearly closed — the board is almost empty. Next week, Lecture 7: the system around the model, where mystery 8 comes down for good and Act 3 begins.