How to use this course
Work each module as lessons then exercises, mark your answers against the rubric or the runner, and decide which modules to skip if you already ship an agent.
On this page
This course has 42 lessons and 35 exercises across ten modules, and the exercises are the course. A lesson teaches one mechanism with a number attached; an exercise hands you a situation with real numbers and asks for one decision or one estimate, then shows a strong answer and a rubric to mark yourself against. The reader who writes their answer before opening the strong one leaves able to size, build, eval and defend a model feature. The reader who only reads the lessons leaves with vocabulary.
Lessons, then exercises, in order
Every module after this one opens with its lessons and closes with three to five exercises that practise them. Work the lessons first, in order, because each one assumes the number the previous one taught: where the money goes assumes you can count tokens, and prompt caching assumes you know where the money goes.
Every lesson ends the same way. ## In an interview says what an interviewer is testing with the topic and names the mistake that loses points. ## Check yourself asks two or three questions that force a decision or an estimate, each answered in a blockquote so you can mark yourself without scrolling up. Answer them before reading the blockquote. The same shape runs through the DSA course, where problems sit beside lessons as exercises do here.
The five kinds of exercise
| kind | What you produce |
|---|---|
case | a decision for a situation, and the evidence that would reverse it |
estimate | a number, with the arithmetic shown from stated assumptions |
design | a mechanism — a schema, a tool surface, a cache layout, a golden set — and its defence |
critique | what is wrong with a given decision or result, and what to do instead |
code | one solve() against a stated contract, proved by the runner |
The chips on a module page give the kind and the difficulty. Difficulty describes the idea, not the length: an easy exercise applies one lesson directly, a medium one needs a transformation the lesson did not spell out, and a hard one composes two modules.
How to work an exercise page
Every exercise has the same five sections, and the order is the method. ## The situation states who, what volume, what it costs today and what is promised — and, for an estimate, every constant it uses, because the lessons use only the names from the four numbers and an estimate has to end in a sum. ## The question asks for one decision or one estimate. Stop there.
Write your answer. For an estimate that is a number with the arithmetic that produced it; for a case or a design it is the decision, the reason, and the evidence that would change your mind. Two hundred words is enough. Only then open ## A strong answer, and mark yourself against ## Rubric. If you scored four of six, ## Where answers go wrong will usually show which weak answer you wrote and the one sentence a reviewer would say about it.
What the rubric is for
A rubric makes the strong answer gradeable. Each bullet is one observable thing an answer does — "converts pages to tokens with the arithmetic shown", "names the condition under which the answer flips" — never "understands tokens". If a bullet could be satisfied by using the right word, the bullet is wrong, and we tried to write none of those. The bullets cover the reasoning, not only the final number, so an estimate that lands on the right figure with the wrong arithmetic scores two of five, and that score is the honest one.
The rubric also settles disagreements. If you reach a different decision from the strong answer, the bullets tell you whether the disagreement is about the arithmetic, which you can check, or about an assumption, which you should state. The course's constants are labelled assumptions, and an answer that substitutes your own and shows the working is a strong answer.
The runner for code exercises
Seven exercises are kind: code. The contract is a solve() signature with a docstring, shown in ## The question, and the page's TESTS list of (args, expected) pairs, which includes every example printed on the page plus the edge cases. The solution under ## Solution passed those tests before it reached the page: the build imports every solution file, calls solve(*args) on each case, and fails if any case does. Python 3, standard library only, no shared helper module.
To work one, copy the signature and TESTS into a file, write solve(), and run the cases:
for args, expected in TESTS:
got = solve(*args)
assert got == expected, (args, got, expected)
print("ok")
An answer that passes the page's example and fails one edge case is the usual outcome of a first attempt, and the exercise's ## Where answers go wrong names that edge. Five of the seven are in module 8, where a harness in 200 lines shows how they compose into one loop; the scheduler among them assumes the topological order taught in cycles and ordering.
What to skip
If you have called a model API once and are about to ship on it, read everything in order; module 1 before anything else.
If you already ship a feature with a loop in it — tools, retries, a history that grows — test out of modules 1 to 3 rather than skipping them: do each module's exercises cold, and move on from any module where you score four of six on every rubric. Expect to be surprised by sampling and determinism and by the caching arithmetic; those two catch most people who skip.
Nothing in modules 5 to 7 is skippable, whatever you ship. Evals as the unit test of LLM work, skills and hooks, MCP, and why reliability lives in the harness are where teams that already run an agent, and still get surprised in production, have the gap.
Module 4 is retrieval; skip it if your feature has no corpus, and come back the week the first "the model does not know our data" ticket arrives — the model does not know your data is where to start. Module 8 is for whoever will write the harness. Module 9 is for the week before an interview, and its first lesson, what an interviewer asks an AI engineer, is worth one read by everyone, because the six question families are also the six questions a reviewer asks about a design.
Three things are linked rather than re-taught. Little's law and pool sizing come from the system design course; the interface a harness's tools present comes from designing to an interface; and wherever a lesson reaches the application of a mechanism — an MCP server for your own company, an automation run as a virtual employee — it links the agents course in one line, as module 6 links designing the tool surface, and stops.
In an interview
An interview tests whether you can produce the number and the decision under time, out loud, with the arithmetic visible. The exercises are that test, taken alone and slowly first. A candidate who has written forty answers before opening forty strong ones has rehearsed the motion the interviewer is scoring; one who has read forty strong answers has rehearsed recognising them, which is a different skill and the wrong one.
The mistake that loses points is reading the strong answer first. It feels like learning, and next month you will recognise the approach and still not produce it. The rubric scores what you did, not what you recognised.
Check yourself
1. You scored three of six on a case exercise, but your decision matched the strong answer's. Move on?
No. The rubric scores the reasoning, and a decision without the evidence that would reverse it is a guess that landed. Redo the exercise in a week without looking, and aim for the three bullets you missed — they are usually the ones about what would change your mind.
2. You run an agent in production. Which modules do you do in full, and which do you test out of?
Test out of 1 to 3 by their exercises, four of six on each rubric to pass. Do 5, 6 and 7 in full. Do 4 only if there is a corpus. Do 8 if you will write or own the harness, and read the four numbers whatever else you skip, because every exercise is written in its units.
3. Your solve() passes the page's worked example and fails one case in TESTS. What is the next move?
Print the failing
args. It is an edge case the page named in## Where answers go wrong— an empty input, a budget of zero, a turn cap hit on the last turn. Fix it, then add the case you would have missed next time to your own list; the runner is only as strong as the cases in it.