Where to Go Next

This book taught how to work with a coding agent you did not build, on a service whose architecture it left alone, with the security and git knowledge the work needed and no more. Each of those limits was deliberate, and each is where another course on this shelf begins.

This page puts the whole book on one figure, then names four courses and the question each one answers. Pick the next one by the question you are stuck on, not by the order of the shelf.

The Book on One Page

The loop of Chapter 2 is the spine: specify, give context, generate, read, test, then commit or discard. Every chapter from 3 to 9 is one stage of it done well, and Chapters 10 to 14 are the same loop under real conditions: a bug, unfamiliar code, an attacker, a team, a budget. The figure is the reference to keep beside your editor until the habits are automatic.

Prepare: instructions file, commands, permissions, a clean start→Chapter 3

Context: point at files and evidence, keep sessions short→Chapter 4

Specify: a task it can finish, a plan read first, small steps→Chapter 5

Read: the diff is the product, tests first→Chapters 6 and 7

Test: the test is the contract you review→Chapter 8

Commit or discard: a known-good point before every request→Chapter 9

Agentic AI from Scratch

This is the course for the reader who wants to know how the thing works. It builds an agent from a single model call: the loop, tools and their schemas, the Model Context Protocol through which agents load tool servers, context engineering, evaluation, and trust boundaries from the builder's side. Three times this book stopped at the edge of that material, when it gave the agent loop one paragraph in Chapter 1, when it named tool servers in Chapter 4, and when it treated prompt injection from the user's side in Chapter 12. Each of those handoffs points here.

Its entry bar is met by anyone who finished this book. Knowing how an agent is assembled also changes how you supervise one: the failure modes of Chapter 7 stop being a list to memorise and become consequences you can predict.

It uses its own running example, an online marketplace called Sundry, and its own vocabulary for the parts this book treated as a black box. Expect to recognise every behaviour you have supervised here, from the context window filling up to an agent acting on text it read in a tool result, and to see for the first time the code that produces it.

Backend Deep Dive

This is the course for the reader who wants to build services like the booking service rather than change one. It covers what this book declined to teach in one sentence each: designing an API, data access and transactions, queues and background work, failure by design, and running a service in production.

The argument for it is sharper with an agent in the loop. An agent writes this kind of code fastest, and gets its design wrong most quietly, because a poor design compiles, passes its tests and fails only under load or six months later. The skills of the previous chapter's third topic apply here most of all: you can only judge the design you could have made yourself.

The course also explains several things this book only used. The race that let a 17th climber into a class of 16 in Chapter 13 is a concurrency problem at the row level, which it treats in depth. The retries and idempotency that a waitlist offer needs belong to its chapter on failure by design. Reading it after this book turns a list of review comments into a model of why they were right.

CyberSecurity Deep Dive

This is the course for the canon that Chapter 12 assumed. Chapter 12 covered only what is new because an agent sits in the loop: secrets in context, instructions hidden in content, invented packages, the agent's own permissions. The classic material it relied on is in this course: identity and access management in its Chapter 3, web application security, including injection and broken access control, in its Chapter 6, and securing the build, from dependencies and the supply chain to secrets in CI, in its Chapter 12.

An agent reproduces the insecure patterns of public code faster than any reviewer who does not know them can catch them. The defence is knowing the patterns, and this is where they are taught.

It is a deep course, and it is not a prerequisite for anything in this one. Read the three chapters named above first; they are the ones a reviewer of AI-assisted changes uses every week.

Git, GitHub & GitHub Actions

This is the course for the depth that Chapter 9 used and did not teach. Its fourth chapter covers history and rewriting, including interactive rebase and bisect, the tool Chapter 10 used to find the commit that introduced a bug. Its eighth covers branch protection, rulesets and required reviews, the repository rules that the last topic of Chapter 13 and the cloud agents of this chapter lean on. Its eleventh and twelfth cover secrets in CI and the security of automated workflows, which decide what an agent's pull request can reach.

The undo button gets better the better you know the machinery under it. When parallel agents leave a history that needs untangling, this course is where the commands for it are taught.

Its title names a product, which is why earlier chapters only point to it and this chapter describes it. The repository rules it teaches exist in some form on every major host, and the habits carry over even where the menus differ.

What to Re-read When the Tools Change

The first three pages of this chapter are rewritten every month, and the rest of the book changes slowly. When a new tool arrives, the fourth page of this chapter, on what carries over and how to evaluate a tool in an afternoon, is the one to re-read. The places in the book marked "as of 2026" are the ones to check first; they are the claims expected to move.

And after your first month on a real codebase, go back to Chapter 7. The failure modes read differently once you have caught a few yourself, and the second reading is the one that sticks.