The title means two things, on purpose.
You build with AI when a model sits inside your product: it writes the copy, answers the visitor, calls the tools. Most of this book is about that sense. You also build with AI when a model sits beside you and writes your code. That is the sense most teams are living through right now, usually without having decided anything about it.
Most books pick one. This one argues they are the same engineering problem. In both cases a fluent, fast, persuadable contributor produces plausible work that somebody else is accountable for. In both cases the answer is the same four principles: treat the contribution as an unreliable call, keep its instructions in version control, cap what it can consume, and enforce the rules somewhere it cannot argue with.
The preposition carries the argument. Building with AI, not by it. The model is a participant whose authority ends at a boundary you draw: a contract, a cap, a constraint, a Definition of Done. Where that boundary sits is the subject of every chapter.
It means the same thing “shipping fast” meant in the last book: making a decision once, at the right level, so you never have to make it again. Where the provider lives. Where prompts live. What a turn is allowed to cost. What happens when the model is wrong. What “done” means when half the diff was written by an agent. Decide those once, apply them everywhere, and your fifth AI feature, like your fiftieth agent-written pull request, costs a fraction of the first.
The alternative is a codebase where every AI feature is a special case with its own retry policy, its own idea of a timeout, its own credential handling and its own failure mode. That is not fast. That is four features and four outages.
Boring scales. Clever decays. That was true before there was a model in the loop, and the model did not repeal it.
The System This Book Is Built On
The running example has three AI surfaces, and the book moves between them. Meet them once here, so that nothing later looks like a mistake.
Content generation. When a merchant starts a site, a small leaf service writes its copy: the hero, the services, the questions people ask. It runs on whichever provider the merchant’s workspace is configured for. Chapters 1 to 4 build its boundary.
Inline editing. A merchant on their own live site clicks a field and asks for a better sentence, or for the whole page in Spanish. The browser talks to a backend-for-frontend, which talks to the leaf service. Chapters 3, 4, 5 and 12 live here.
The agent. A conversational widget on the marketing site gathers what someone wants, verifies their email and hands them to checkout. Its turns run on a queue. The model calls tools that live in an MCP server we wrote with Laravel. Chapters 6 to 11 are mostly about this one.
browser ──► marketing app ──► queue job
│ ▲
request │ │ answer
▼ │
model provider
│ ▲
tool calls │ │ results
▼ │
MCP server
│
▼
database, mail, checkout
browser ──► editing backend ──► AI leaf service
│
▼
model provider
Two providers appear in the code, and that is deliberate. The leaf service speaks to an OpenAI-compatible API, because merchants can choose their provider and most of the choices speak that dialect. The agent speaks to Anthropic’s Messages API, because it uses features that are specific to it. Where the provider matters, the book says which one it is.