The book ends where the daily work begins: with two short supports you return to without rereading the chapters. The first is the "need - use" table: in the left column you find your task, in the right one the surface or mechanism for it. The second is a dated version snapshot that fixes exactly which product the book was written on. A reference has one temptation: to learn it by heart and use memory. That is precisely what must not be done, and the whole chapter is about why.
The naive move is understandable: a reference is a reference so that you memorize it once and do not check each time. For one of its parts this works, for the other it deceives. The mapping table rests on stable mechanics: Command for an inline edit, Ask for a read-only answer, Devin Local in a worktree for local implementation, Quick Review for an independent diff review. These pairings change slowly and can be kept in your head. The version snapshot is of a different nature: it is true as of its date and ages with every release.
The naive model breaks on exactly this difference of natures. The mechanics answer the question "which tool solves this class of task" and stay true as long as the tools are named the same. The snapshot answers the question "what is available right now and at what price" - and here memory fails fastest: the default name, the stable version number, the primary local agent, the composition of the model catalog and the prices live in the live interface, not in the text. To confuse these two layers is to apply yesterday's line to today's product.
So the snapshot in the book is a dated one, not eternal truth, and it is read with the date in view. For this snapshot: the date is August 11, 2026; the primary name is Devin Desktop, the former Windsurf remaining only in legacy paths and historical context; stable is 3.7.16 of August 10, 2026; the primary local agent is Devin Local; the Next preview line is not mixed with stable; pricing and the model catalog are given as dated snapshots, and in case of discrepancy priority always goes to the live interface, not the book. Each of these lines is a verifiable fact as of its date, not a promise for the future.
The "need - use" table is built as a reverse index of the whole book: not "what Devin can do" but "for my task - what to take". An inline edit - Command via Cmd/Ctrl+I. The agent panel with the selected context - Cmd/Ctrl+L. An answer with no changes - Ask, exploration with a plan - Plan. Local implementation - Devin Local in a worktree. Long background work - Devin Cloud. An external compatible agent - ACP. An independent check of the diff - Quick Review. A durable short instruction - AGENTS.md or a rule, an on-demand procedure - a skill. A hard prohibition - permission deny, sandbox or hook. Legacy memory and workflows - Cascade and the Migration Wizard.
The value of the table is that it imposes the right order of thought: the task first, the tool second. This is the same discipline that runs through the whole book: not "which window is open" but "what I am solving and how I prove it". Reading left to right, you name the task before the surface every time - and automatically avoid the two main distortions: a heavy surface on a small edit and the active branch under multi-step work. The table does not add knowledge; it cements the habit of choosing by the task rather than by habit.
| Need | Use |
|---|---|
| Inline edit | Command · Cmd/Ctrl+I |
| Agent panel / selected context | Cmd/Ctrl+L |
| Read-only answer | Ask |
| Exploration and alignment | Plan |
| Local implementation | Devin Local + worktree |
| Long background task | Devin Cloud |
| External compatible agent | ACP |
| Independent diff review | Quick Review |
| Durable short instruction | AGENTS.md / rule |
| On-demand procedure | Skill |
| Hard prohibition | Permission deny / sandbox / hook |
| Legacy memory/workflow | Cascade - Migration Wizard |
The cost of living by the reference is a mandatory check before applying the volatile, and it is cheaper than a mistake. The order of re-checking is set in the book explicitly and goes by layers: first the changelog, then the agent selector, then the model picker, then Customizations, then usage, then the security and admin policy, and at the end - the provider terms for ACP. This route is not over-caution but a way to bring your understanding into agreement with the current state of the product in a minute, before acting on it.
The book holds the stable-preview boundary firmly precisely here, at the finale. Next is a separate line, and a fact from Next is not considered available in stable without separate confirmation. Mixing them is a typical mistake: a technique from preview is applied in stable, the promised thing is not found, and time is spent searching for what is not in this line. Preview is convenient on a separate profile as a way to look at the future, but not as a hidden variable of the shared workflow.
You should check that the reference is used correctly by one sign: applying a volatile line, you checked against the live source, and applying a stable one, you named the task before the tool. If before acting you opened the changelog, the selector and the model picker and confirmed the snapshot is still true, the reference worked as intended. If you act on a line from the book because "that is how it is written", without a check, you are trusting memory where a live source is needed.
The typical failure of the final chapter is confusing its two layers. The stable mechanics start being checked every time, wasting effort on the obvious; the volatile snapshot, conversely, is taken for eternal truth and acted on from a stale line - looking for a feature in the wrong release line, naming the version from memory, trusting a price from the book instead of the pricing page. The sign is the same: a line from the reference was applied to today's product without asking which layer it belongs to and as of what date it is true. Ask that first, and the reference will stay useful longer than any single release lives.