Key takeaways

The through-line

Prompt engineering stopped being clever wording and became context engineering — deciding what information occupies a finite window, in what order, under what structure. The prompt is a program whose runtime is a probability distribution.

The ideas that carry

• The system prompt sets the contract; the user turn is data. Conflating them is the root of most prompt-injection exposure and most inconsistent behaviour.
• Few-shot examples teach format far more reliably than they teach reasoning. If you need behaviour, demonstrate it; if you need knowledge, retrieve it. Examples are a poor substitute for either.
• Chain-of-thought buys accuracy with latency and tokens — and only on problems that decompose. On retrieval-shaped questions it mostly adds cost and surface area for error.
• Structured outputs are an engineering boundary, not a formatting preference. Constrained decoding and schemas turn a text generator into something a program can consume without a parser that guesses.
• Position in the context window is not neutral. Instructions at the edges survive; material buried mid-context gets lost. Long context is not the same as used context.
• Prompts are versioned artefacts. Un-versioned prompts silently drift, and nobody can say which change caused a regression. This is the single highest-leverage operational habit in the course.
• Defensive prompting assumes the input is hostile, because eventually it is — delimiters, instruction hierarchy, and never treating retrieved text as trusted.

What you can now do

Write a system prompt that holds under adversarial input. Choose deliberately between few-shot, CoT and retrieval. Ship structured outputs a downstream service can rely on. Version and A/B a prompt so a regression is attributable.

If one thing sticks

You are not writing instructions for a person. You are assembling the context that makes the right continuation the most probable one.