API to Architecture
From client.complete()
to architecture.
Fourteen design patterns for the engineering layer above the AI model. Worked TypeScript examples for RAG, tool use, agent loops, structured outputs, evals, fallback — each pattern names a problem, names the failure mode it prevents, and tells you when not to reach for it.
If any of this sounds familiar
Your demo works.
Production is another problem.
- You wrote a prompt that returns valid JSON 90% of the time and shipped anyway, because you didn’t know what else to do.
- Your “agent” gets stuck in loops, picks the wrong tool, or takes thirty seconds when it should take two.
- Your AI bill is 50× what you budgeted, and you don’t have a clear picture of where the cost is going.
- You change a comma in a prompt and three things break in production. There’s no eval set; there’s no signal.
- You can name “RAG” and “agents” but couldn’t explain to a colleague when to use which, or what failure mode each one prevents.
None of this is the model being dumb. It’s a missing architectural layer above the model — the patterns that turn a working demo into a system that survives production. This course is that layer, named.
What you walk away with
A working architecture for AI in production.
Chapter 1
A clear contract for getting data, not text, from the model
Chapter 2
A working understanding of when retrieval beats fine-tuning
Chapter 3
The agent loop you can ship vs. the agent loop that burns money
Chapter 4
The pattern that drops your AI bill by 80% without losing quality
Chapter 5
Eval sets — the load-bearing pattern under everything else
Chapter 6
Memory architecture that survives sessions and respects privacy
Throughout
A vocabulary for the architectural debates that AI teams keep having
Chapter 7
The judgment to skip the patterns you don't actually need
Each pattern is named, with a worked TypeScript example, an explicit “when to use” and “when not to,” and the failure mode it prevents. You’ll come out with vocabulary for problems you’ve been hitting without names, and a checklist for the next AI feature you build.
Syllabus
8 chapters · 21 units
Each unit is one pattern. The first two units (Ch 0) are free. They include the framing for the whole course and the map of how the patterns compose.
Ch 0Start herePsychological2 units
What this is. Why classical design patterns still apply. Why these new ones exist on top.
Ch 1Text to dataMedium3 units
The model returns text. You need data. Three patterns make the gap manageable.
Ch 2Context the model needsPEAK3 units
The model doesn't know what you know. Retrieve it, decompose it, rerank it.
Ch 3Actions the model takesPEAK3 units
Letting the model trigger code in your system — tools, agents, and when not to.
Ch 4Cost and latencyMedium2 units
Cheap models first. Big models when warranted. Cache everything you can.
Ch 5When the model is wrongPEAK3 units
Evals measure quality. Guardrails enforce it. Fallback handles the rest.
Ch 6Memory and conversationMedium2 units
What to remember across turns, and what to remember across sessions.
Ch 7Composition and anti-patternsHigh point3 units
Patterns are tools. Knowing when not to reach for one is the senior move.
The format
One pattern per unit. Pairs you can copy.
Every unit is structured the same way: name the pattern, name the problem it solves, show the naive code, show the pattern applied, name when to use it and when not. The pairs are TypeScript using the Vercel AI SDK syntax — runnable, copyable, model-agnostic.
| Typical AI engineering content | This course | |
|---|---|---|
| Format | Blog posts and Twitter threads | 21 short written units with TS code pairs |
| Scope | One library, one model, one moment in time | The patterns, model-agnostic and SDK-agnostic |
| When it ages out | Next model release | Never — the patterns outlast the models |
| What you do with it | Bookmark, forget | Apply one pattern to your next feature |
| Voice | Hype, demos, threads | Diagnostic, examples-first, plain language |
| Anti-patterns covered | Rare | Two full units (agent-for-everything, single-best-model) |
Every pattern unit, the same shape
- 1. The problem. The specific failure mode this pattern addresses.
- 2. The pattern. Named, described, with the architecture explained.
- 3. The pair. Naive TypeScript code, then the pattern applied. Side by side.
- 4. When to use / when not. Specific. Not best practices — the conditions under which it’s right, and the conditions under which it’s wrong.
- 5. Try it. A reflection that maps the pattern to your real codebase.
8 chapters · 21units · ~5–9 minutes per unit.
Full access
Unlock the full course.
- ✓All 8 chapters, 21 units, every worked code example
- ✓Chapter 0 (2 units) open to read — taste the format before you unlock
- ✓Progress tracking and a continue-learning button, locally on your device
Frequent objections
Honest answers.
Who is this for?
Engineers who've already shipped at least one feature using an LLM and are now trying to make it survive real users. You should know what an API call looks like, what JSON is, and have written some TypeScript or Python. You don't need a machine-learning background — this course is about engineering patterns on top of models, not about training them.
Do I need to know AI/ML to take this course?
No. The course treats the model as a component. No transformers theory, no fine-tuning, no embedding math. Just the patterns for using these components in a system that has to work for real users at real volume.
Why TypeScript?
Consistency with the rest of the platform. The code examples use the Vercel AI SDK syntax, which is the cleanest current standard for AI work in TypeScript. Every pattern in this course works identically in Python — most of the patterns aren't even SDK-specific. If you're a Python engineer, the translation is one library swap per example.
What if I use a different SDK or provider?
The patterns work the same. The SDK choice is incidental — what changes between SDKs is the syntax of the function calls, not the architecture of the pattern. RAG is RAG whether you use Vercel AI SDK, the OpenAI client, the Anthropic client, LangChain, or raw fetch. You'll read the code examples for the shape; the syntax is portable.
Why no specific model names in the course?
Because they age out within months. Every six months a new model becomes the default and the old recommendations look dated. The patterns in this course were as true two years ago as they will be two years from now. The code examples use a bare 'model' variable that you configure to whatever you're using.
How long does this take?
About 3–4 hours of reading. Less if you skim the patterns you already know; more if you implement each one as you go. The course is structured so you can read it in order or jump to a specific pattern you have a problem with. Each unit is self-contained.
I already use some of these patterns. Is this for me?
Probably yes. The course's job isn't to introduce patterns you've never seen — many of them you've already used, even if you didn't have the name. The value is in the naming, the comparison, and the explicit 'when not to use it' for each. Most engineers find the anti-patterns chapter alone changes how they make architecture decisions.
Will this stay relevant?
Yes. The course is intentionally model-agnostic and SDK-version-agnostic. The underlying patterns — give the model facts via retrieval, validate outputs with schemas, route to the right model for the task, build evals before you ship — outlast every specific implementation. The Vercel AI SDK examples may need updating in a year; the patterns won't.
What about classical design patterns?
Still essential, untouched here. GoF and Refactoring.Guru cover them well — links in unit 0.0. This course is only about the patterns layered on top, the ones that didn't exist before there was a model in the system. Strategy, Factory, Adapter, Observer all still apply to your surrounding code.
The first two units are free.
Read them. If they don’t change how you think about your next AI feature, close the tab. If they do — the rest of the course is the catalog.