The book teaches programming alongside a command-line agent: how to give it memory of the project, how to connect external servers that hand it tools, how to delegate work to subagents, how to automate steps with hooks. It is a product manual, and it should be read as one.
What I took from it
The distinction between asking a model nicely and managing its context. The first is writing; the second is engineering: what gets written down permanently, what gets retrieved only when needed, what gets compressed, and what gets isolated in a separate process so it does not contaminate the rest. That four-way grid works with any tool, and will still work when this one is gone.
The second: the project memory file is documentation that actually gets maintained, because it has a reader who uses it daily. It is the only case I know where writing down a repository's conventions stops being a well-meaning gesture.
And the third, against the fashion: before splitting work across several agents, exhaust what one well-informed agent does properly. The authors show this without saying it, because the multi-agent examples are the ones that tangle.
What I left out
Almost everything else, for the obvious reason: prices, plans, screens and command names change every few weeks. A printed book about a self-updating tool is a strange instrument, useful for a month and archaeological within a year. I read it for the conceptual part and to see how someone else organises the craft; for the operational detail, the product's own documentation is more current and free.