Applied AI Engineering
Applied AI engineering is about building software with language models — not training them. You won't write ML pipelines or tune hyperparameters. You'll learn how to communicate with models, integrate them into real systems, and ship them to production. This course teaches the foundational concepts every applied AI engineer needs. You'll learn what tokens are and why they matter, how context windows shape every architectural decision, and how to communicate effectively with models through prompts, structured output, and chain of thought reasoning. You'll move from communication to integration — connecting models to real data through grounding and RAG, extending their capabilities with tool use, and making integrations portable with the Model Context Protocol (MCP). Then you'll build on these primitives to understand agents: AI systems that reason, plan, and act autonomously. You'll learn the agent loop, specification-driven development, and how to compose agents from reusable skills. Finally, you'll learn the practices that separate prototypes from production: evaluation (measuring what matters) and guardrails (keeping AI systems safe and reliable). By the end, you'll have a clear mental model for every core concept in applied AI engineering — and the vocabulary to go deeper on any of them.
Section 1: Foundations — How LLMs Process Text
Before you can build with a language model, you need to understand what it sees. A language model doesn't read words the way you do. It processes tokens — subword chunks that determine cost, speed, and capacity. Everything it works with must fit inside a fixed-size context window. The only way to tell it what to do is through a prompt. And the randomness of its output is controlled by a single parameter called temperature. These four concepts — tokens, context windows, prompts, and temperature — are the foundation of every decision you'll make as an AI engineer. This section makes them concrete.
Section 2: Communicating Effectively with Models
You know what models see. Now you need to learn how to talk to them. A model that returns free-form prose is useful for chat. A model that returns structured JSON is useful for software. The difference is how you ask. This section covers the core communication techniques: structured output for machine-readable responses, few-shot learning for teaching by example, and chain of thought for complex reasoning. It also covers the failure mode that every AI engineer must understand: hallucination. Models will confidently generate plausible-sounding text that is completely wrong. This isn't a bug to be fixed — it's a property to be designed around.
Section 3: Connecting AI to the Real World
A standalone language model can only work with what's in its training data and its context window. That's not enough for real applications. Production AI systems need to look things up, call APIs, query databases, and read documents. This section covers the four patterns that make that possible: tool use (letting the model call functions), grounding (connecting responses to verified data), RAG (retrieving relevant documents at query time), and MCP (the emerging standard that makes tool integrations portable). These patterns transform a model from a text generator into a system integrator — one that can interact with the real world through your code.
Section 4: Building Agents
Everything so far has been single-turn: you send a prompt, the model responds, done. Agents change that. An agent is an AI system that pursues a goal across multiple steps. It reads the current state, reasons about what to do, takes an action (usually a tool call), observes the result, and repeats until the task is complete. This is the pattern behind code assistants, research tools, and autonomous workflows. This section covers the agent pattern, the loop at its core, the importance of defining what you want before asking the model to do it, and how to compose agents from reusable skills.
Section 5: Quality and Safety
AI systems fail in ways that traditional software doesn't. Outputs can be wrong but plausible. Behavior can drift between runs. A prompt change that fixes one case can break ten others. And unlike a database query, there's no guaranteed "correct" answer to compare against. This section covers the two practices that separate prototypes from production: evaluation (systematically measuring whether your AI system does what you intended) and guardrails (engineering controls that keep it safe when it doesn't). It finishes by putting everything together — the full picture of what it means to build reliable AI systems.