Prompt Engineering — the craft, systematized

You've been prompting for ten lessons; now let's make it an engineering discipline. Start with why prompting works at all, because the mechanism explains every technique: Lesson 1 taught you the model is a next-token predictor whose output is a probability distribution conditioned on everything before it. A prompt doesn't "instruct" some inner executive — it reshapes the distribution. Every word you add shifts which continuations are probable. Prompt engineering is distribution-shaping with words.

That lens makes the core techniques obvious rather than magical:

1. Specificity kills ambiguity. A vague prompt leaves a huge space of plausible continuations; the model samples somewhere in it and you call the result "wrong." The calibration standard: write for a brilliant contractor with amnesia — world-class general skills, zero knowledge of you, your project, or what "make it better" means. Everything they'd need asked, answered in advance: audience, format, length, constraints, what good looks like.

2. Few-shot examples (the ladder's rung 2, Topic 12). Show 3–5 input→output examples and the model pattern-matches format, style, and edge-case handling far better than any description conveys — this is in-context learning, the pattern-continuation engine pointed at your examples. Craft notes from the trenches: examples teach everything they contain, including mistakes (Topic 13's law, in miniature); diversity beats repetition; for classification, balance your labels or the model inherits the skew.

3. Chain of thought — with the real mechanical reason it works. "Think step by step before answering" reliably improves reasoning, and Topic 8 told you why: each token is one forward pass — a fixed compute budget. Forcing the answer in one token gives the model one pass to get it right. Letting it reason in tokens first gives it hundreds of forward passes of scratch work, each conditioning the next. You're not asking it to try harder; you're granting it more compute and working memory. (Module 8's reasoning models are this insight trained into the weights — flag planted.)

4. Structure. Delimit sections with XML tags or headers (<context>, <task>, <examples>) so instructions and data can't blur. And an ordering rule with a Module 4 payoff: static content first, variable content last — long documents and stable instructions up top, the changing question at the bottom. Partly for attention patterns, largely because Topic 37's prefix caching can then reuse the static prefix across requests: prompt structure is literally a cost decision.

5. Output shaping. Specify format explicitly; show a skeleton of the desired output. And know the industrial-strength version: constrained decoding — the API feature (often called structured outputs / JSON mode with schema) where the sampler masks invalid tokens at each step (Topic 2's dice, loaded), making schema-valid JSON a mathematical guarantee rather than a request. When parseability matters, don't prompt for it — constrain for it.

6. Give an out. "If the context doesn't contain the answer, say so" — Topic 21's abstention, one line, cheap insurance on every factual task.

The anti-patterns: politeness padding, threats, and tips are noise (measured effects are marginal-to-nil — spend the tokens on specificity instead); over-prompting strong models with 40 rules they'd follow from 5; and treating the prompt as a dumping ground where every past bug gets a new appended sentence until nobody knows which lines do anything.

Which points to the real discipline, and the theme this course keeps returning to: prompts are code. Version them. Change one thing at a time. And test every change against an eval set (Module 10's whole subject) — because "the prompt feels better now" is the vibes-engineering this course exists to cure.

---