Prompt Engineering

Instructions that hold up in production.

Fig. 2 — Prompt, detail at larger scale

What you send in, and the shape you demand back.

Key plan — part 1 on Fig. 1

19lessons4parts7min a lesson133min in total

Figure 2 — the parts of this course, as links to their lessons

What the detail shows

Two inlets meet at one manifold: the system turn sets the frame, the user turn carries the job.
Two worked example pairs join them — what went in, beside the answer it should have got.
One hard request is split into three smaller ones, which rejoin.
A loop under the line is the model thinking out loud; the ticks beneath it are the tokens that costs.
Untrusted text crosses the boundary into your app — the point where an injection gets in.
The same request is sent three times, and the three answers are voted down to one.
A valve checks the winner against the contract, which watches from above and carries nothing.
What fails the check goes back round the bottom line and is asked again.
What passes leaves through the outlet manifold, in the shape the contract demanded.
A dotted tap watches the prompt itself: every version is kept and tested, and a model writes the next one.

Schedule of lessons

19 lessons

How instructions land
4 lessons · 28 min
1. Why prompts fail
  Three causes, one debugging order, and why telling it to try harder does nothing.
2. The system prompt and the user turn
  Which half of the request is the frame, and which half is the job.
3. Prompt layout and the cache
  Stable text first, changing text last. The model reads it better, and the provider can reuse the work.
4. Examples beat explanations
  Two worked pairs settle more than a paragraph, and settle it without argument. Usually. Here is when they do not.
Techniques that hold up
5 lessons · 35 min
1. Decomposition
  Split one hard prompt into a few checkable ones — and know when not to.
2. Thinking out loud
  When reasoning before the answer earns its tokens, and when it just burns them.
3. Steering how much it thinks
  Effort is the dial, the prompt is the weak second lever, and every token of thinking is billed.
4. Output contracts
  Stop asking for a format. Specify one, then make it impossible to miss.
5. Structured outputs in practice
  The decoder holds the shape. Know what it cannot say, and how a reply can still arrive broken.
Making it reliable
6 lessons · 42 min
1. Validating what comes back
  Treat every response as an untrusted body, and catch the wrong answer before it reaches your database.
2. Stop reasons and refusals
  An HTTP 200 means a reply arrived, not that you got an answer. Sort every reply before you use it.
3. Retries and fallbacks
  Turn a validation failure into a second attempt the model can actually get right.
4. Prompt injection
  Why untrusted text can steer your app, and the defences that actually reduce the damage.
5. Containing prompt injection
  You cannot make the model un-foolable. You can make a fooled model unable to reach anything.
6. Sampling and voting
  When there is no error to catch, run it more than once and let the answers disagree with each other.
Keeping it working
4 lessons · 28 min
1. Versioning and testing prompts
  Put the prompt in git, and get a number that tells you whether your last edit helped.
2. Trimming a prompt that grew
  Prompts only gain lines. Use the harness to find the ones that no longer earn their place.
3. Let a model write the prompt
  Turn the harness from Versioning and testing prompts into a search, and stop hand-editing by feel.
4. Searching over prompts
  Run the drafting round many times, and keep three sets apart so the score you report is still true.

Notes

Past the tricks. How instructions actually land, which techniques survive contact with real traffic, how to validate what comes back, and how to stop a prompt edit from quietly breaking last week's behaviour.

Every figure on this sheet is counted from the lessons themselves. Your progress is kept in this browser only — no account, nothing sent anywhere.