How This Course Works
One support desk, measured piece by piece
You do not study fifteen separate subjects. You build one thing, an assistant for the support desk at Quillpath, a made-up project-management software company, and every module adds a part to it. Each idea in the course is measured on the same 36 support tickets, so you see exactly what a technique changes. By the end you have one repository you can show and explain line by line.
The project, its people, its data and its dates are described in 03-the-quillpath-support-desk.md. It is fictional; the real cases that open each lesson are not.
Pictures first
Every lesson is a walk through one example, one picture at a time. A figure shows an idea; a short paragraph says what the figure shows in plain words; a short block of code proves it; a walkthrough explains every line of that code. Then the next figure. A lesson has fifteen to thirty figures and takes thirty to forty-five minutes to read properly.
The same colours mean the same things in every figure:
| Colour | Means |
|---|---|
| Blue | Your system, the normal path |
| Amber | The model, anything uncertain |
| Green | Correct, safe, passed |
| Red | Failure, attack, danger |
| Grey | Optional, background, ignored |
The shape of every lesson
| Part | What happens | Why it is there |
|---|---|---|
| The situation | A problem at the Quillpath support desk, with named people | You learn the idea because you need it |
| A real case, first | Something that really happened, from a published source, cited | So you know the idea matters outside a course |
| The idea | Figures and short paragraphs, one running example throughout | The picture comes before the vocabulary and the formula |
| Run it | A short piece of code, pasted into Colab, with a code walkthrough | You see it work, and you understand every line |
| Break it | You make it fail on purpose | Real systems fail; see the failure here first |
| In production | What teams do with this at scale | The part most courses leave out |
| Check yourself | Three to five questions, answers hidden until you click | You find out whether it stuck |
| Exercise | One task with a way to check it | You do it, not just read it |
| Key terms and sources | A short glossary and the sources the lesson used | So you can go further |
Three depths of topic
Not every topic deserves the same attention. Each one is marked in its heading:
| Mark | Meaning | What you get |
|---|---|---|
| (Essential) | You cannot do the job without it | Figures, code and a "break it" step |
| (Recommended) | Skip it only if you have a reason | A figure and a short section, often with code |
| (Optional) | Knowing it exists is enough | An "awareness card": what it is, when you would need it |
If you are short of time, do the Essential sections of every module first and come back for the rest.
What every module contains
| File | What it is |
|---|---|
README.md | What the module is for, what you need to know first, the lesson list |
| Numbered lessons | One file per group of topics |
...-module-lab.md | A guided build that adds this module's piece to the support desk |
...-incident-file.md | A real, published failure, then the same failure replayed at Quillpath and fixed |
Module 15 is the capstone: one lab, with four tracks to choose from and the same evidence required of each.
Skip what you know
You may already call models from code every day, or already have trained one. Each module README starts with What you need first, so you can check whether it is safe to jump ahead. Some suggested routes are in the course README. Where another course in this series teaches a subject in more depth (retrieval pipelines, transformer internals, agents that act unattended), the module points you to it.
How to run the code
All code runs in Google Colab. Open a new notebook, paste each code block into a cell in order, and run it. No installation is needed beyond the install cells the lessons give you.
Every lesson that calls a model starts with the same short setup cell. It lets you choose between three model providers by changing one word. Groq and Gemini work in Colab with a free key. Ollama runs a model on your own computer, so if you choose it you work in a code editor on your machine. Setup for both routes, the one table of model prices, the extra libraries each module needs, and how to run the whole repository locally: 02-setup-colab-and-llm-providers.md.
Lessons use only the slice of Quillpath data they need, copied from 06-shared-data.md. All of it is simulated.
Some topics cannot run in a notebook: a GPU serving engine, a container, a CI pipeline. Those lessons give exact instructions for your own computer, say plainly that they were not run in the course, and say what was checked against the official documentation instead.
The tools
Everything in the course is open source, apart from the hosted model services, which are shown as options. The course uses LangChain for calling models and tools and LangGraph for loops and approvals. Where it helps you understand, a lesson first builds the mechanism by hand in plain Python, then shows the framework's version, so you know what the framework is doing for you. PyTorch and Hugging Face libraries appear where you open a model up or adapt one.
Every output is real
Every output printed in a lesson came from running that lesson's code, with real provider keys, on the date shown. There are no hand-written "example outputs". Where a lesson tests plumbing (a parser, a retry loop) with a scripted stand-in instead of a model, it says so, and the stand-in's replies are never presented as what a model said. Numbers in the text come from those runs or from a cited source.
Your answers will not match ours exactly
Language models do not return the same words every time. When a lesson shows output, yours may be worded differently, and your scores may differ by a ticket or two. That is normal. Module 3 explains why, and Module 10 shows how to tell a real improvement from that noise. Building reliable software on top of an unpredictable component is the main skill this course teaches.