← Courses
Start here8 modules·41 lessons·~17 hours
Applied AI Engineering
A structured path from writing normal software to building and shipping systems on top of language models. Assumes you can program and nothing about AI. Eight modules, from what the job actually is through to the interview that gets you it.
Most material about building with language models is either a research paper or a fifteen-minute tutorial that stops working next month. This course sits in between: the working knowledge an engineer needs to ship something real, in the order you actually need it.
It assumes you can already program. It assumes nothing about AI. If you have been meaning to properly understand what an embedding is, why everyone keeps saying "evals", or what people mean when they call something an agent, start at module one and go in order.
The course is deliberately opinionated. Where there is a decision, it makes one and tells you the conditions under which it would flip. Where a topic is fashionable but rarely worth it in production, it says so.
Modules one to four are free to read. Later modules ask you to sign in or subscribe, and every lesson links into the question bank so you can practise what you just learned against real interview questions.
WHAT YOU WILL BE ABLE TO DO
- →Explain how a language model turns your text into an answer, and reason about what each step costs
- →Write prompts that produce structured output a program can rely on
- →Design and debug a retrieval system, and know when retrieval is the wrong answer
- →Build a tool-using agent, and recognise the far more common case where you should not
- →Evaluate an AI feature with something better than reading outputs and nodding
- →Take an applied AI interview loop without being surprised by what it tests
BEFORE YOU START · You can program in any language, are comfortable calling an HTTP API, and can read code. No machine learning background needed, and none is assumed.
Course content
- ○The four things you will actually buildApplied AI work looks endlessly varied from outside and turns out to be four recurring shapes. Knowing them early tells you what to learn, what to skip, and what any given feature request really is underneath.Free11m
- ○Five habits from normal software that will hurt you hereThe hardest part of moving into applied AI is not the new material, it is the instincts you already have. Five of them are actively wrong here. This lesson names each one, what replaces it, and why the substitution is not optional.Free15m
- ○A map of the stack, and where the hard parts actually areEvery system in this course is the same seven pieces in different arrangements. This lesson lays them out, shows which ones consume your time in practice, and gives you a mental frame to hang the next six modules on.Free12m
- ○How to use this course without wasting your timeHow this course is built, how it connects to the question bank and the concept curriculum, and the three ways people waste weeks on material like this. Read it once and the remaining six modules take less effort.Free10m
- ○Tokens: the unit everything else is priced inBefore you can reason about cost, latency, context limits, or chunk sizes, you need one mental model: the system charges you in tokens, not words. This lesson installs that habit and shows where it comes back in every later module.Free12m
- ○Embeddings: why a computer can suddenly tell that two sentences mean the same thingEmbeddings are the reason search stopped depending on matching words. This lesson builds the intuition from a problem you already have, shows what the geometry does and does not know, and sets up why retrieval works at all.Free13m
- ○Attention: how a model decides which words matter to whichYou do not need the maths of attention to build with models, but you do need what it buys and what it costs. This lesson gives you the intuition and the one consequence that shapes every design decision later: cost grows with the square of the input.Free14m
- ○Why a model states something false with total confidenceHallucination is not a bug that will be patched out. It follows from what the model is built to do. Understanding why changes how you design around it, and separates engineers who mitigate it from those who keep hoping the next model fixes it.Free13m
- ○Why the same prompt gives a different answer twiceRandomness in a model is a setting, not a mystery, and knowing which knob does what is the difference between a feature that behaves and one that surprises you in production. This lesson also covers why turning it all the way down still does not give you exact repeatability.Free12m
- ○A big context window does not mean you should fill itContext windows keep growing, and the instinct is to stop thinking about what goes in them. This lesson closes the module by showing why capacity is not recall, what actually degrades as the window fills, and how to decide between more context and better context.Free13m
- ○What a prompt is actually made ofA prompt is not a sentence you write once. It is an assembled document with parts that do different jobs, and knowing which part carries which job is the difference between fixing a problem and rewording it.Free13m
- ○Getting output your program can actually rely onThe step that turns a chat toy into a component you can build on. Three levels of guarantee, why asking politely is the weakest of them, and the validation layer you need even when the format is guaranteed.Free14m
- ○Examples and reasoning steps, and when each stops payingTwo techniques get reached for reflexively and both have a point where they stop helping and start costing. This lesson covers what each actually does, how to choose examples that carry information, and the reasoning trap that costs teams real money.Free14m
- ○The prompt failures you will meet, and what each one meansSix failures account for most of what goes wrong with a prompt in production. Each has a distinct cause and a distinct fix, and recognising which one you are looking at is faster than any amount of rewording.Free13m
- ○Telling a real improvement from a lucky runMost prompt iteration is superstition: change something, try it once, feel better, ship. This lesson replaces that with the smallest honest process, which takes about an hour to set up and is the highest-return hour in the course.Free13m
- ○Why retrieval exists, and what it actually buys youRetrieval is the standard answer to making a model useful on knowledge it never saw. This lesson covers the three problems it solves at once, the one thing it does not fix, and the shape every system in this module is built from.Free13m
- ○Chunking: the decision that quietly caps your qualityHow you split documents into passages sets a ceiling on how good your retrieval can ever be, and it is usually decided in five minutes by a default. This lesson covers the tension every strategy is trading against, and how to choose deliberately.Free14m
- ○Why your search misses the obvious answerPure vector search fails in two specific, predictable ways, and both have standard fixes that most first systems are missing. This lesson covers the two-stage design that turns a demo into something that finds the right passage.Free14m
- ○How a working retrieval system goes wrongThe failures that arrive after launch, once real documents and real questions replace your test set. Six of them, each with the signal that identifies it, because the wrong diagnosis here wastes weeks.Free14m
- ○When retrieval is the wrong answerRetrieval has become the reflex, and it is wrong often enough to be worth a lesson. Four situations where something simpler or entirely different is the better system, and the decision procedure that gets you there in ten minutes.Free12m
- ○Project: build a retrieval system over your own documentsPROJECTThe first project of the course. Build a working question-answering system over documents you actually have, in five stages, each one checkable on its own, and finish with something honest enough to put in a portfolio.Free240m
- 🔒What a tool call actually is, mechanicallyThe single most useful correction for anyone new to tool use: the model never runs anything. It emits a request, your code decides whether to honour it, and that boundary is where all the safety and most of the reliability live.Sign in13m
- 🔒Tool design is prompt engineering by another nameThe model chooses tools using only their names, descriptions and parameter schemas. That surface is the whole prompt for the decision, which makes tool design an authoring problem rather than an API problem, and explains most wrong-tool bugs.Sign in14m
- 🔒The loop, and how to stop itPutting a tool call in a loop is a four-line change that turns a predictable component into an open-ended process. This lesson covers what the loop buys, the three ways it fails to terminate, and the budgets that keep it survivable.Sign in14m
- 🔒Try these five things before you build an agentNow that you can build an agent, here is the ladder of cheaper designs to exhaust first. Each rung handles a large share of what people reach loops for, and moving up one rung at a time is how you end with a system you can operate.Sign in12m
- 🔒Project: give your retrieval system a toolPROJECTTake the system you built in module 4 and let it act, not just answer. One tool, one bounded loop, a confirmation gate on anything irreversible, and an honest comparison against the version without a loop.Sign in120m
- 🔒Why measuring this is genuinely hardEvaluation is not testing with extra steps. Three properties of generative output break the assumptions ordinary testing rests on, and understanding which one you are up against tells you which technique to reach for.Sign in13m
- 🔒Building a set of examples worth trustingYour evaluation is only as good as the examples in it, and most sets are quietly useless because of how they were assembled. This lesson covers where to get examples, what proportion should be awkward, and the maintenance nobody plans for.Sign in14m
- 🔒Letting a model grade the work, and how it lies to youUsing a model to score output is the only way to evaluate open-ended work at any scale, and it has five documented biases that will flatter you if you do not design around them. This lesson covers each one and the cheap defence.Sign in14m
- 🔒Why your offline score and reality disagreeA system that scores well and disappoints users is the most common outcome in this field. Five specific reasons the two diverge, and the small number of production signals worth wiring up to catch it.Sign in13m
- 🔒What to do with a number once you have oneMost teams that build evaluation stop at producing scores. This lesson is the part that makes them useful: reading a change honestly, deciding what would make you revert, and turning a set into something that runs without anyone remembering to.Sign in12m
- 🔒Latency, cost and quality: pick your constraintThree quantities you cannot maximise at once, and the levers that move each. Most systems are tuned by accident; this lesson is how to decide deliberately, starting from the requirement rather than from the model.Sign in13m
- 🔒Caching, and the one that pays for itself immediatelyThree kinds of caching apply here and they are not interchangeable. One is nearly free and often sits unused, one needs care, and one will serve wrong answers if you are careless about what belongs in the key.Sign in13m
- 🔒Everything the model reads is untrustedA system that retrieves documents and calls tools has a security property most engineers meet for the first time here: instructions can arrive inside data. This lesson covers why prompt fixes are insufficient and where the defence actually goes.Sign in14m
- 🔒Seeing inside a system whose failures are silentOrdinary monitoring tells you the request succeeded, which here means almost nothing. This lesson covers what to record so a bad answer is explainable a week later, and the three alerts worth having on a system that never throws.Sign in13m
- 🔒What your system does on a bad dayYou depend on a service you do not control, which will be slow, rate-limited or down at some point. This lesson is the set of decisions to make in advance, and the one that matters most: what a degraded answer looks like.Sign in13m
- 🔒Project: harden your system for a bad dayPROJECTThe capstone. Take the system you have built across three modules and make it operable: one stated constraint, a cache with a correct key, a real trust boundary, logs that explain a bad answer a week later, and a rehearsed answer for when the model API is down.Sign in180m
- 🔒What each round is actually listening forEvery round has a stated subject and a real one. This lesson maps what interviewers are screening for onto the seven modules you have just read, so you know which part of your knowledge each round is trying to reach.Premium13m
- 🔒Turning this course into a study planA concrete four-week plan mapping the seven modules onto the question bank, plus what to do differently if your interview is next week rather than next month.Premium12m
- 🔒Driving the design conversationA design round is a conversation you are expected to lead, not a question you answer. This lesson is the shape that works, the four moments that decide the outcome, and the two classic ways strong candidates lose one.Premium14m
- 🔒Talking about AI work without sounding like a demoThe behavioural round for this role has its own questions, and the ones about AI work are easy to answer badly. The last lesson of the course covers the four stories to have ready and the honesty that makes them land.Premium13m
Every lesson links into the question bank so you can practise what you just read against real interview questions. Locked lessons still show their full summary, so you always know what is behind them.