How this book was made

This book was not written the usual way. It was generated by Claude, an AI model, working in Claude Code. It started from one prompt from its reader and followed a short conversation in which they steered it. That reader is also the person the book was written for. This page records that prompt, the steering, and how the chapters were produced and checked, so you can judge the text knowing where it came from.

The prompt

Everything that follows grew out of this request:

If you scan my org files (~/org), Obsidian (~/data/obsidian), and github (kisom), you can figure out what my technical proficiency is. I need a gitbook repo with a course on agentic AI engineering, starting from first principles.

Calibrating to one reader

The first step was reading the material the prompt pointed at: an org-mode notes tree, an Obsidian vault, and several hundred public GitHub repositories. The aim was to place the reader, not to summarize them. Three summaries came back, and they agreed with each other:

• Strong enough to skip:
  • systems programming, mostly Go, then C and C++, with a long tail through Lisp, Haskell and Rust;
  • applied cryptography and security engineering;
  • distributed infrastructure: NixOS, podman, Tailscale;
  • a habit of building tools from scratch: editors, Lisps, interpreters, a CA;
  • hands-on operation of a local llama.cpp inference fleet;
  • daily use of several agent harnesses.
• Thin, and therefore where the course should spend its time:
  • transformer internals;
  • writing a raw agent loop;
  • formal evaluation design;
  • prompt and context engineering as a discipline;
  • MCP internals;
  • retrieval and vector indexes;
  • fine-tuning.
• Math: applied and self-taught. Intuition comes first, and no derivation step is skipped.

That profile is why the book never explains a for loop but derives the law of cosines one line at a time.

The steering conversation

The design was settled in a few exchanges. What the reader said, and what each answer changed:

1. How deep “first principles” goes. The options were model mechanics, the API and loop, or the math. The reader chose the math. So Part I rebuilds vectors, matrices, probability, calculus and autodiff before any model appears.
2. Language. A split: Python with only numpy for the math, the model and the model server, and Go, the reader’s strongest language, from the router onward.
3. How much to write. The whole course, written out in full, delivered one part at a time with a review between parts.
4. The end state. “The end state is writing my own hermes or openclaw analog, if that helps steer the discussion. In order to do that, I want to understand the entire stack.” This turned a survey course into a build toward a persistent agent daemon. It added chapters on the daemon runtime, channel gateways, scheduling and autonomy, skills, a model of the user, code-execution sandboxes and a policy engine. It also added a chapter on how inference engines work inside.
5. The reader’s own infrastructure. An inventory of the reader’s inference fleet was shared: which hosts serve which models, and the fetch, memory and gateway services. The course was then pointed at real endpoints instead of hypothetical ones. Its examples use the reader’s own systems: the web tools, the memory service, the Mattermost gateway and the routing roles.

6. Four more steers:

   • “For the cloud target, I think z.ai might be cheaper.”
   • “It would be useful to learn how to write my own routing model server.”
   • “It would be instructive to build a toy vector database like honcho.”
   • “I’m also fine with a local model … carrying the main loop, if that’s useful as well.”

   These added a whole part on serving models, with your own inference server, constrained decoding, batching and a router. They also split the memory chapters into a vector database built from the HNSW paper and a memory service on top of it. Finally, which model runs the capstone’s main loop became a question for the evaluation chapters to answer, rather than an assumption.

7. Housekeeping. Each completed part is rebased and fast-forwarded onto master. The title and cover were the reader’s.

The resulting syllabus has 47 chapters in ten parts. It is recorded, with every decision above, in the design document at docs/superpowers/specs/2026-09-28-aec-course-design.md in the repository.

How the chapters were produced

Each part goes through the same pipeline.

1. A written plan. Each task gets exact file paths, the reference code in full, the tests that pin it, and an outline of the chapter that goes with it.
2. Implementation by a fresh agent per task. Tests are written first and the code follows them. Every code listing in the chapters is pulled from real source files by a small tool, and the build fails if the two ever disagree. Program output shown in the text is copied verbatim from real runs.
3. An independent review of every task. A different agent checks the work against the plan and the writing standards. For chapters it also re-derives the mathematics and recomputes every number the chapter prints.
4. Fix rounds until the review comes back clean, then a final review across the whole part.

The reviews caught real errors in Part I before they reached this text:

• A rank argument named the wrong matrix.
• Gibbs’ inequality was applied to the wrong entropy. The stated conclusion held only by coincidence.
• A chain-rule derivation skipped its remainder terms.
• Book citations described chapters that cover something else.

Lessons like these were written into a standing rulebook that later chapters are held to (docs/superpowers/course-writing-rules.md). Every commit names the model that wrote it.

What that means for you

The prose, derivations and code were machine-generated under human direction, and then checked by machine: tests, gradient checks, recomputation and cross-review. That process catches a lot, but it does not replace your own scrutiny. The book asks you to derive things yourself and to run the labs against your own code, and that stance is also the right one toward the book. Where it is wrong, the tests and your own derivations are how you will find out, and fixes are welcome.