The bracket gloss

When a specialist term shows up for the first time, you will see a short definition in brackets right after it. Like this: stateless function [a function that does not retain any memory of its past executions]. The brackets signal “here is a working definition, enough to keep going.” Terms that need more than a sentence get a full paragraph of teaching. Either way, no prior technical knowledge is assumed.

Citations

Every technical claim carries a citation. They look like [@example2025paper] inline and render to a full reference at the back of the book. You do not need to follow them to read the prose. If a claim surprises you, the citation tells you where to verify it.

Callouts

Boxes that look like this mean “pause, this is the key insight”:

Code

There is Python in most chapters. It is there to show the mechanism exactly, not because you need to write it. If you do not read code, skim past the snippets. The prose around each one carries the argument. You will lose nothing by treating the code as a visual marker for “here is where the claim is proven.”

Voice

First-person plural (“we”) for the reasoning we are doing together through the book. First-person singular (“I”) for claims that rest on measurement I ran myself, for example “I ran this on a 9060 XT.” Second-person (“you”) for the reader. Opinionated where the evidence warrants, hedged only where the evidence actually hedges.

How to use the book

Linearly is how it was built. The argument compounds; each chapter deflates some remaining magic left over from the last one. By Part V you will have a working mental model of what these systems are and what it costs to run them.

That said, chapters are not locked. If you landed here because you are debugging a prompt injection right now, jump to Chapter 18. The callbacks (see @sec-some-earlier-section) will tell you where to catch up if something earlier in the book would help.

The book is a journey, not a manual. But it will not lock you out.