AI Engineering Playbook
Applied AI, from zero to production depth.
The consumer side of AI engineering — you take models you did not train and build systems that are correct, fast, cheap, and safe enough to put in front of real users. RAG, embeddings, vector search, agents, MCP, and the production engineering that holds it together.
Most material on this subject is a pile of definitions. Definitions tell you what something is called. They don't tell you what breaks without it, what it costs, or what you'd reach for instead — and those are the things you actually need when you're the one building it.
So every page here is built to answer three questions in order: why does this exist, how does it actually work, and what goes wrong in production.
What makes this different
Intuition before jargon
Every page opens with a plain-language analogy that makes the mechanism obvious later. The technical depth is unchanged — you just arrive at it already oriented.
Traced, not asserted
Each topic follows one concrete input end to end with real numbers — token counts, dimensions, milliseconds, ranks — then breaks it on purpose to show what each stage was protecting you from.
Applied, not academic
No PyTorch, no training loops, no backprop. Model internals appear only at survival depth — enough to reason about a boundary question without bluffing.
How every page is built
The intuition
The idea in plain language, with one load-bearing analogy, before any terminology.
Why it exists
The specific pain that makes the concept necessary, and why the obvious alternatives lose.
The core idea
The concept stated properly and densely — the version you'd want to be able to explain out loud.
How it actually works
One level down, with a diagram: the mechanism, the parameters, and the maths that matter.
The flows
The distinct end-to-end paths through the system, each with the condition that selects it and the thing that breaks it.
A worked example
One concrete input traced through the whole mechanism with real-ish values — then deliberately broken.
Production concerns
Scale, cost, latency, failure modes, and the operational details that only show up with real traffic.
Test yourself
Scenario questions you answer out loud, then grade yourself on. If you can't reason through them, reread — don't move on.
Every page also opens with its prerequisites and closes with where this connects, so the site is a web you can walk rather than a list you have to read front to back.
The dependency map
Arrows mean "this builds on that". Follow them and nothing will use an idea you haven't met yet.
Read the four highlighted nodes as the spine: fundamentals → embeddings → RAG → agents. Everything else hangs off that spine. If you only have one evening, walk the spine.
The learning path
Read in nav order, top to bottom. Each section assumes the ones above it, and pages inside a section are ordered so nothing is used before it's introduced.
- LLM Fundamentals — what the model is, and what it isn't
- Embeddings & Search — how meaning becomes geometry
- Vector Databases — where that geometry lives
- RAG — grounding answers in documents the model never saw
- Agents — when the model chooses the control flow
- MCP — the standard socket between models and tools
- Production — latency, cost, reliability, observability, security
- Model Landscape — buy, host, or adapt
- Multimodal — when the input isn't text
- System Design — assembling all of it under constraints
- Rapid Fire — compress it back down
The running example
Abstract concepts need something concrete to land on. Across this site, one system recurs:
The governed enterprise LLM platform
Consider a large firm in a regulated industry. Employees want to use LLMs on internal material, but internal data cannot be sent to public model APIs. So the firm builds a platform: a model gateway fronting a managed cloud model service — data stays inside the tenancy, access goes through IAM — and on top of it, retrieval over internal documents, personal and org-wide vector stores with entitlement-filtered retrieval, temporary per-session document upload with TTL cleanup, grounded web search, an agent mode calling internal tools over MCP with human approval on writes, and a guardrails, observability and cost layer wrapping all of it.
It's deliberately generic — an architecture pattern many organizations converge on, not any one company's system. Numbers used with it are illustrative typical scale, not measured figures. It reappears throughout — in RAG, vector databases, agents, MCP, and production — so that by the end you've seen one system from ten angles instead of ten systems from one angle each.
What this is not
- Not a machine-learning course. No PyTorch, no training loops, no backprop. Model internals appear only at survival depth.
- Not a substitute for building something. These pages make knowledge legible and structured. Shipping a system is what makes it real.
- Not evergreen in its specifics. Model names, prices, and API details rot within months. Mechanisms and tradeoffs don't. Cross-check any specific figure against provider docs before relying on it.
How to actually use this
Read a page, then close it and explain the concept out loud to an empty room in two minutes. The gap between what you recognized and what you can say is your real study list. The Test yourself block at the end of each page exists to find that gap for you — reveal, then grade yourself, and the pages you flagged become the list you come back to.