Preface

Every large company runs on a quiet, reasonable-sounding phrase: yes, but. Yes, we should do this — but let’s wait for the platform decision. Yes, this would help — but not until the migration is done. Yes, but let’s pilot it first, let’s bring in a consultant to be sure. Each but is individually sensible, and together they add up to a culture of deferral dressed as prudence. For most of the last two decades that was survivable, because the cost of waiting was low.

Then AI revoked the patience. The barriers a corporation puts in front of delivering something new — the migrations, the committees, the rented answers — are now the difference between the organizations pulling ahead and the ones quietly falling behind, and the gap compounds by the quarter. Waiting stopped being safe. This book is about the way out, and its argument is simple: you don’t have to clear the barriers one at a time. You can leapfrog them, using skills you almost certainly already have.

Because most of the hype gets one thing wrong. Delivering AI at scale is not, mainly, a machine-learning problem. It is a cloud-engineering problem — integration, data, deployment, evaluation, cost, security, control — and those are exactly the disciplines a career engineer has been practicing for years. This book is not for AI researchers or data scientists; they are well served already. It is for the engineer who is deep into a career, fluent in how real systems actually work, AI-adjacent but not AI-native, and stuck inside the yes, but. If that is you, the central claim of these pages is that you were always qualified for this, and the barriers are lower than your organization has led you to believe.

The guide draws on two decades spent in the companies that built the modern internet — the edge, the early cloud, and now AI-enabled engineering inside a large automotive company. But it leans far less on any one career than on the researchers and builders it cites throughout, and is best read as a map that credits the people who charted the territory. (How the book itself was made — a human working with an AI — is described in the note just before this one.)

A few words on how it is built. It moves in four parts. First, why and where — why AI is now a must rather than a should, and where it actually belongs in an organization (the answer is not “a chatbot”). Then how to build — the landscape, the cloud foundations, how models are served, the patterns that hold up, and how to ground a model in your own data. Then how to survive Monday — deploying, operating, and staying in control of something non-deterministic, and how to know it is working. And finally at scale and forward — cost and performance, and security, governance, and the road ahead. Between the build and the operating parts sits a short interlude that asks you to stop reading and ship something tiny, this week, because the gap between the five percent who deliver AI and the ninety-five percent who don’t was never knowledge — it was having shipped.

Two habits run through every chapter. Each ends with experiments to run — small, real, shippable tasks — and with curated references that point to the primary sources. And the whole book is deliberately vendor-neutral: it teaches the layer beneath the tools, the durable structure that survives the next model release, rather than this quarter’s product names. Where you need hands-on code and current specifics — which age in weeks — it points you to the companion labs at leapfrog.lerias.org. The book is the why and the shape; the site is where you build.

The map is drawn. The territory is yours to cross. Let’s begin.