Welcome, and who this is for
You built the demo in an afternoon and the room clapped. Then it met real traffic. The bill, the slowness, and the confidently wrong answers all showed up in the same week. This course is about that second part.
The demo and the product are two different systems
A demo runs once, on a path you chose, with you watching. A product runs a million times, on inputs nobody imagined, while you sleep. Same model, same API key, completely different engineering problem.
| The demo | The product | |
|---|---|---|
| Inputs | The three you tried | Anything a user can type, including on purpose |
| Who is watching | You | Nobody, at 3am |
| Cost | A fraction of a cent | A line item somebody has to defend |
| When it is wrong | You laugh and retry | A customer acts on it |
| How you find out | You saw it | A screenshot on social media |
Nothing in that right-hand column is about the model. It is all systems engineering. That is why a good engineer can pick it up quickly, and why nobody hands you a tutorial for it.
What changed by 2026
Most production-AI material still teaches the 2025 threat model: prompt injection and output quality. Both still matter. But the problems senior engineers hit now have moved somewhere harder.
| The shift | What it means for you |
|---|---|
| The stack went opaque | You call a tool, which calls a framework, which calls a gateway. When latency triples, a trace is the only thing that can tell you where |
| Providers change behaviour inside a pinned version | A prompt that scored 0.9 last month scores 0.7 today. No version number changed, so there is nothing to blame |
| Your tooling has credentials and updates itself | An agent framework with repo access and a background updater is a supply chain, whether or not you called it one |
| Convenience is billed per request | Every tool definition and every retrieved chunk rides along in the context window, on every single call |
Three of those terms are worth pinning down now, because the rest of the course leans on them.
A context window is the fixed amount of text a model can read in one call. Everything you send competes for the same space, and you pay for all of it, every time.
A trace is the recorded story of one request: every step, how long each took, and what it cost. Without one, a slow system is a guessing game.
Prompt injection is when text the model reads, from a web page, a document, or a support ticket, contains instructions, and the model follows them as if they came from you.
The through-line of the whole course is one sentence: control and observability over systems you do not own. You did not write the model. You cannot pin its behaviour. You did not audit the framework. You can still build something you are able to reason about, budget for, and debug at 3am.
If any of these is you, you are in the right place
| You are | What you get out of this |
|---|---|
| A senior engineer whose team just got handed "add AI to it" | A way to decide what the model does and what your code does, before you write either |
| Someone whose prototype worked and is now scaring them | Budgets, guardrails, fallbacks, and evals that turn it into something you can defend |
| An engineer who can build anything concrete but freezes at "design an agent" | The same design reasoning you already have, applied one level up |
The common thread: you can build. What you need is a way to decide, measure, and defend.
Two people should close this tab
The prompt-tips collector. If you want a list of magic phrases that make the output better, this is not it. Prompts here are one component in a system, and the system is the subject.
The framework tourist. If you want a tutorial on one named agent library, something narrower and faster exists elsewhere. This course names thirty-one tools, but only so you can choose one on evidence. And only after the design decision they serve is already clear.
What "production-ready" means here
By the end, you should be able to hand someone a design and answer four questions without flinching. What does it cost per request? How slow is it for the slowest five percent of requests, the number usually written p95? What happens when the model or a tool fails? How would you know it got worse?
Four questions stand between a demo and a system you can put your name on. Every module in this course exists to answer one of them.
Answering those four is the difference between a feature that impresses in a meeting and one that survives a quarter.
Recap
- The demo and the product are different systems. The gap is engineering, not prompting.
- The 2026 problems are opacity, silent provider drift, tooling with credentials, and context billed per request. Not just injection and output quality.
- The through-line is control and observability over systems you do not own.
- Next: lesson 0.2, how to use this course, and the one habit that decides whether any of it sticks.