Welcome, and who this is for
You built the demo in an afternoon and the room clapped. Then it met real traffic, and the bill, the latency, and the confidently wrong answers all showed up in the same week. This course is about the second part.
The demo and the product are two different systems
A demo runs once, on a happy path, 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, which is why a good engineer can pick it up quickly and why nobody hands you a tutorial for it.
What actually changed by 2026
Most production-AI material still teaches the 2025 threat model: prompt injection and output quality. Those 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, the 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, with no version bump to blame |
| Your tooling has credentials and auto-updates | An agent framework with repo access and a background updater is a supply chain, whether or not you called it one |
| Integration convenience is billed per request | Every tool definition, every retrieved chunk, every bit of MCP boilerplate rides along in the context window, on every single call |
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, and 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, you will find something narrower and faster 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 at p95, what happens when the model or a tool fails, and 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.