How This Course Works
One engagement, start to finish
You do not study fifteen separate subjects. You work through one customer engagement: Larkfield Systems, your employer, deploying an AI claims assistant at Harbourline Freight. Every lesson is a moment in that engagement, from the first day on site to the check one month after you leave, and every module adds a piece to one repository you can show.
The engagement, its people, its dates and its systems are described in 03-the-engagement.md. It is fictional; the real cases that open each lesson are not.
Half of this course is not code
A forward deployed engineer writes software inside someone else's organisation. Half the job is code. The other half is working out what to build and getting an organisation to actually use it. The course keeps that ratio on purpose.
| Modules | About | Lessons are mostly |
|---|---|---|
| 1 and 2 | The technical floor: what you must be able to do quickly | Code |
| 3 to 7 | The customer's problem, their data, AI work in their environment, their systems, their security rules | Code and judgement |
| 8 to 15 | The business, communication, people, delivery, money, the product, the field, your own judgement | Judgement, with small pieces of code where they help |
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. In a code lesson a short block of code proves it, and a walkthrough explains every line. In a judgement lesson the figure is a map, a timeline or a before-and-after, and the "proof" is a worked Harbourline example: a status update, a problem statement, a conversation that goes badly and then well. 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 specific moment at Harbourline, with named people | You learn the skill 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 |
| Run it, or do it | Code with a walkthrough, or a template with a worked Harbourline example | You see it work, then make your own |
| Break it | Code that fails on purpose, or a weak example you diagnose | See the failure here before you meet it at a customer |
| In production | What goes wrong with real customers, and what it costs | 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 runnable check or a checklist | 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
Each topic is marked in its heading:
| Mark | Meaning | What you get |
|---|---|---|
| (Essential) | You cannot do the job without it | Figures, practice and a "break it" step |
| (Recommended) | Skip it only if you have a reason | A figure and a short section |
| (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 or field exercise that adds this module's piece to the engagement |
...-incident-file.md | A real, published failure, then the same failure replayed at Harbourline and fixed |
Labs. A lab produces one real piece of the engagement, step by step: the TMS loader in Module 4, the triage assistant in Module 5, the stakeholder map in Module 10, the handover runbook in Module 11. Code labs run top to bottom in one fresh Colab notebook and end with a runnable check. Judgement labs end with a checklist you mark your own work against.
Incident files. Each one starts with a documented failure from the outside world, cited: an outage report, a regulator's decision, a published post-mortem. It explains why it happened, then replays the same failure on Harbourline's data or in Harbourline's story, and shows the fix and how you would have caught it earlier.
Skip what you know
You may already be a strong engineer, or already work with customers. 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. Modules 1 and 2 are a brisk check of the technical floor, not a first course in programming; where you need more depth on language models, retrieval or deployment, the module points you to the matching part of the AI Engineering course.
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.
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, and how to run the whole engagement repository locally: 02-setup-colab-and-llm-providers.md.
Lessons use only the slice of Harbourline data they need, copied from 06-shared-data.md. All of it is simulated.
Some topics cannot run in a notebook: a React interface, Docker, a customer's single sign-on, a VPN, a firewall. 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 LangGraph for multi-step workflows with a person approving. Where it helps you understand, a lesson first builds the mechanism by hand in plain Python, then shows the framework's version.
Practising without a customer
Much of this role cannot be learned by reading. The exercises in Modules 3 to 15 push you to do the real thing on a small scale: find a small business or a charity with a manual process, watch it for a day, write the problem statement and let them correct it, build something crude, sit with them while they use it, hand it over, and check a month later whether it is still used.
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. That is normal, and explaining it to a sceptical customer is itself a lesson in Module 5. Every number printed in a lesson came from running that lesson's code on the date shown.