AI Engineering for Web Developers

Preface · Front matter

Preface

7 min read · 1 of 12

Who this book is for

You are a working web developer. You ship things. You know JavaScript or TypeScript. You’ve used Node, you’ve called fetch, you’ve shipped to Vercel or Cloudflare or AWS at least once. You probably know React or Vue or Svelte, but you don’t have to.

You’ve heard the words. Agents. RAG. GraphRAG. Tool use. Vector databases. MCP. Harness. Sandboxing. Multi-agent. Reasoning models. You can sort-of follow a conference talk about them. You might have copy-pasted a snippet from a blog post and got it to do something interesting. But you have not built an AI feature your team relies on, and you’re not sure where to start.

That’s the reader I’m writing for. There’s a name for that audience that’s been kicking around tech forever: aware but not building. The goal of this book is to take you from there to having shipped a real AI agent, and to give you a mental model that survives the next eighteen months of churn.

Who this book is not for

If you want to fine-tune a model, distill a model, or train one from scratch, you want a different book. Probably Chip Huyen’s AI Engineering. It’s the canonical reference for that material, and it’s very good. I won’t try to compete with it on that ground.

If you want to understand transformer architecture, attention mechanisms, RLHF, or any of the model-internals math, again, Huyen. Or Karpathy’s free YouTube lectures, which are excellent.

If you’ve never written code before, this isn’t your book either. The book assumes you can read TypeScript (or JavaScript), set up a Node project, install an npm package, and debug an HTTP error. If those are unfamiliar, work through any “modern Node and TypeScript” course first; you’ll get more out of this book on the other side.

What you’ll have built by the end

One running build: a research-and-writing agent that ships.

Chapter 1 is a seven-line Gemini script. Chapters 2-5 add structured output, tool calls, and the AGENTS.md plus skills context layer that carries your standing guidance into every call. By Chapter 5 the assistant is a useful single-shot tool-user; what’s still missing is iteration. Some basic LLM terminology gets explained along the way.

Chapter 6 turns that into an agent: a runtime that loops, dispatches the tools the model picks, observes results, and stops cleanly. Chapters 7-14 grow the runtime into something you’d actually deploy: a brain/hands/session harness, the agent patterns you compose on top, multi-agent handoff via A2A, memory, evals, safety and guardrails, a Docker sandbox, a Plan-and-Execute orchestrator, and observability, cost engineering, and an HTTP/SSE deploy with audit logs and per-user budgets. Chapter 13 ships the workflow shape, then reshapes the same capabilities as an autonomous agent (one root Agent whose tools are four specialist Agents). Both end-states ship and stay in the repo.

The book builds most of this by hand on purpose, so you can see what a framework actually does for you when one’s involved. This is a deliberate choice. Earlier in my career I was teaching a lot of web development and a lot of times newcomers have faced issues in React which were a byproduct of a JavaScript issue. Skipping the basics then (that is, not learning HTML, CSS and JS) was not something I supported, and I take the same stance now - learning the individual parts better enables to use a framework that offers them for you on a silver plate.

Four bonus chapters sit outside the spine. Two cover RAG (fundamentals plus the production-shape retrieval funnel) for readers who need the assistant to search their own documents instead of grounding from live search. One rebuilds the Chapter 14 assistant on Google’s ADK so you can see what an off-the-shelf framework replaces. One walks through MCP servers, clients, and the WebMCP variant currently landing in browsers (which I’m personally really excited for).

Why this subject? Three reasons.

It exercises every pattern worth learning. Across the two builds you touch tools, RAG, planning, multi-agent handoff, memory, evals, guardrails, sandboxing, and deployment. Nothing is included for show.

It’s useful. By the RAG bonus chapter you can point it at your own notes; by Chapter 9 it remembers what you asked last week. The “cool demo to my friends” wattage is real.

It generalizes. About half the agent work happening in industry has the same shape: investigate something, synthesize an answer, take an action, hand off to a human if needed. Your next project at work probably has that shape, even if it’s not framed as research.

Why now

I was (and still am) fortunate enough to have travelled the world and deliver AI workshops. Two became really popular: “AI for Web Developers” and “The name is Agent. AI Agent”. After 20+ deliveries, I decided it is time to capture all the material, all the discussion points, all the questions and answers, all the after-event chats into a book.

What you need before Chapter 1

Read Chapter 0 (Setup). It’s short. It walks you through Node, the TypeScript runner, the Gemini API key, the editor, and the verify-it-works hello world. Reader feedback on early drafts: people who skipped Chapter 0 wasted an afternoon. Don’t be one of them.

An honest note before we continue. In this book I made a choice to use Google’s Gemini model family. I am a Google Developer Expert and Google is generous enough to provide me with ample amount of credits that I can use freely against their models, which of course helps with experimentation. That being said, the underlying concepts and methodologies - with the exception of a very few things - can also be applied to any other model provider’s API or SDK. I tried my best to mention other organisations and their offerings for full transparency.

Also note that calling the models will cost you money. How much, largely depends on how many times you run each of the prompts/apps in this book, what alterations you make to them so on and so forth. You can always check the latest Gemini pricing on https://ai.google.dev/gemini-api/docs/pricing.

Gemini 3/3.1 was in preview when I wrote this. By the time you’re reading, the -preview suffix on model identifiers may be gone, prices may have changed, and there will probably be a Gemini 4. If a code sample fails with “model not found,” check the official docs at https://ai.google.dev/gemini-api/docs/models for the current id.

The patterns will outlive the model names. That’s the bet.

How to read this book

Linear is best for the first read. Each chapter assumes the previous one, and the running build keeps growing. After the first read, the book works as a reference; jump to whichever chapter solves the problem you have today.

Every chapter closes with a bridge: one paragraph naming what the next chapter does and why it follows.

Code samples are runnable. They live in the companion repo, organized as code/chapter-XX/. Each chapter folder is its own npm project. Clone the repo, cd code/chapter-XX, npm install, node <file>.mjs, see the same output the book quotes.

A note on opinions

I have them, and I share them. When the field is doing something dumb, I’ll say so. When two reasonable approaches exist, I’ll tell you which one I’d reach for and why, and what you give up by choosing it. The encyclopedic register has its place; this book takes a different posture.

You’re welcome to disagree, and you’ll be a better engineer for the practice.

What I won’t pretend

I am not a frontier-AI researcher. I’m a developer educator. I’ve spent twenty-five years teaching developers things, and the last three of those teaching AI specifically. The book reflects that: a lot of pedagogy, a lot of running examples, a lot of “here’s the thing nobody told you the first time you saw this.”

Let’s start.