How to Read This Book

The Encyclopedia is not a tutorial. You don’t read it front to back unless you want to. You pick an entry that matches where you are, follow the links it offers, and build up your understanding in the order that fits your situation.

Some scaffolding helps, though. Below you’ll find how entries are structured, what each section covers, and five curated reading tracks if you want a guided path.

The Structure of Each Entry

Most entries in the Encyclopedia follow the same template:

• Context describes the situation where this concept shows up, so you can recognize whether it applies to you.
• Problem names the specific tension or challenge you’re facing.
• Solution explains the concept: what it is and what it does.
• How It Plays Out shows the concept in action through concrete scenarios.
• Consequences covers the tradeoffs and what you give up when you apply the pattern.
• Related Patterns links to concepts that work alongside this one, refine it, or push back on it.

Some pages, including introductory and methodology articles, don’t follow this structure. They use narrative prose instead.

The Book’s Sections

The sections move from strategic to tactical and then into agentic specifics.

Product Judgment and What to Create starts before any code exists. What should you build? For whom? Why would it matter? If you skip these questions, you risk building the wrong thing well.

Intent, Scope, and Decision-Making turns a goal into a workable task. Vague ideas become requirements and constraints that can guide an agent or a developer.

Structure and Decomposition is about organizing software into parts: which pieces belong together, which belong apart, and how to break a large problem into smaller ones you can solve independently.

Data, State, and Truth covers how information is represented, stored, and kept consistent. Most bugs live here.

Computation and Interaction gets into how software does things: algorithms, side effects, concurrency, and the interfaces through which components talk to each other.

Correctness, Testing, and Evolution is about building confidence that software works, and keeping that confidence as the software changes.

Security and Trust covers protecting systems and users from things going wrong, whether by accident or by malice.

Human-Facing Software is what it takes to build something people can actually use: interaction design, accessibility, internationalization.

Operations and Change Management picks up after the code is written. How does software get deployed, updated, and kept running?

Design Heuristics and Smells collects rules of thumb and warning signs that experienced developers use to spot trouble early.

Agentic Software Construction covers the concepts specific to directing AI agents: models, prompts, context, tools, and the workflows that tie them together.

Learning Tracks

These tracks are curated reading paths. Each one links roughly ten entries in a suggested order, with a note on why each one comes when it does. They aren’t exhaustive. The sidebar has the full catalog, and browsing by section is always an option.

Track 1: Your First Day with an AI Agent

For people who have never directed an AI coding agent before. These eight entries build a working mental model of what an agent actually is and how to work with it.

1. Model — Start here. Understanding what a model actually is shapes everything that follows.
2. Prompt — Now that you know what a model does, learn how to talk to one. Writing good prompts is most of the skill.
3. Context Window — Every prompt competes for limited space. This entry explains the constraint that shapes all your decisions about what to include.
4. Agent — The jump from “model that answers questions” to “model that takes actions.” This is the concept the whole book orbits.
5. Tool — Agents act through tools: reading files, running commands, calling APIs. Here you learn what tools look like from the agent’s side.
6. Instruction File — Your first practical setup step. An instruction file gives the agent persistent context about the project so you don’t repeat yourself.
7. Verification Loop — Agents produce output, but output isn’t necessarily correct. This is how you check before you accept.
8. Human in the Loop — Once you trust verification loops, you can decide how much supervision the agent actually needs. This entry maps the spectrum.

Track 2: Building Things That Work

For people who want to understand the foundations of software construction. These twelve entries cover the concepts that experienced developers use to design systems that hold together.

1. Problem — Everything starts here. If you can’t name the problem clearly, you’ll build the wrong thing.
2. Requirement — Once you have a problem, you need to say what the software must do about it. Requirements bridge “why” and “how.”
3. Architecture — The big decisions that shape the whole system. These are the hardest to change later, so they come first.
4. Component — Architecture gives you the big picture; components are the pieces it’s made of.
5. Interface — Components talk to each other through interfaces. Getting these right is what makes parts replaceable.
6. Boundary — Where does one component end and another begin? Boundaries answer that question.
7. Cohesion — A measure of whether the pieces inside a component belong together. High cohesion means the component has a clear job.
8. Coupling — The flip side of cohesion. Coupling measures how much a change in one place forces changes elsewhere.
9. Abstraction — With components, interfaces, and boundaries in place, you can start hiding detail. Abstraction lets you ignore what doesn’t matter right now.
10. Separation of Concerns — The organizing principle behind all the structure you’ve just learned: each part should do one thing.
11. Decomposition — Now you can put the principles together. Decomposition is the act of splitting a problem into smaller problems.
12. Test — You’ve built something. Does it work? Tests are how you find out.

Track 3: Keeping Software Honest

For intermediate readers who want to understand how software is made correct and kept correct over time — including how security fits into the picture.

1. Invariant — Before you can test anything, you need to know what “correct” means. Invariants are the conditions that must always hold.
2. Test — The mechanism for checking invariants. If Track 2 introduced tests, this entry goes deeper into how they work.
3. Test Oracle — A test needs a source of truth to compare against. That’s the oracle.
4. Harness — The infrastructure that runs your tests and collects results. You’ll need this before testing at any scale.
5. Regression — Bugs that come back after being fixed. Regression tests are the defense, and this entry explains why they matter more than you’d expect.
6. Threat Model — Correctness isn’t just about bugs. This entry shifts to deliberate threats: what can go wrong, and who might cause it?
7. Trust Boundary — Where data or control moves between trust levels. Most security problems live at these boundaries.
8. Input Validation — The first line of defense at a trust boundary: check that incoming data is safe before acting on it.
9. Least Privilege — Limit what each part of a system can access. If something gets compromised, the damage stays contained.
10. Sandbox — The strongest form of containment. A sandbox confines an agent or process so it can’t reach anything outside its scope.

Track 4: Mastering the Agentic Workflow

For intermediate to advanced readers who already understand the basics and want to work with agents more effectively on real projects.

1. Context Engineering — The single highest-leverage skill in agentic work. What the agent knows when it starts a task determines the quality of everything it produces.
2. Compaction — Long conversations hit the context window limit. Compaction is how the agent summarizes to make room, and understanding it prevents mysterious quality drops.
3. Thread-per-Task — Give each independent task its own session instead of stacking them. This keeps context clean and failures isolated.
4. Subagent — One agent can spawn another for a narrower piece of work. This is how complex jobs get broken down at runtime.
5. Parallelization — Once you can spawn subagents, you can run them simultaneously. This entry covers when that helps and when it backfires.
6. Plan Mode — Have the agent think before it acts. Planning catches structural mistakes before any files change.
7. Skill — A reusable instruction set the agent can invoke by name. Skills are how you encode repeatable workflows.
8. Hook — Automations that run before or after agent actions. Useful for validation, logging, and guardrails.
9. Memory — How agents retain information across sessions. Without memory, every conversation starts from scratch.
10. Worktree Isolation — Run agents in separate Git branches so their changes don’t collide. Essential when multiple agents work on the same codebase.
11. Approval Policy — Not every action should be autonomous. This entry defines where to draw the line between agent autonomy and human sign-off.
12. Eval — A structured test of agent behavior. You’ve tuned the workflow; evals tell you whether the tuning actually helped.

Track 5: From Idea to Product

A cross-cutting track that follows the path from a raw idea to deployed software. Draws from several sections of the book.

1. Problem — Every product starts with a problem worth solving. This track begins the same way Track 2 does, but heads in a different direction.
2. Customer — Who has this problem? Getting the customer wrong early means building the wrong thing, no matter how well you build it.
3. Value Proposition — Why would someone choose your product over doing nothing? This is the question most failed products never answered.
4. User Story — Translates a customer need into a unit of work an agent or developer can act on. This is where product thinking meets engineering.
5. Acceptance Criteria — What does “done” look like? Without acceptance criteria, you can’t tell whether a story is finished.
6. Deployment — The jump from “it works on my machine” to “users can reach it.” This is where the track shifts from building to shipping.
7. Continuous Integration — Merge and test changes frequently so problems surface early. CI is the safety net that makes fast shipping possible.
8. Feature Flag — Deploy code without exposing it to users. Feature flags decouple “shipped” from “released.”
9. Rollback — Things go wrong. Rollback is how you undo a deployment quickly, before users notice.
10. Observability — The product is live. How do you know it’s working? Observability closes the loop between shipping and learning.

These tracks are highlights, not reading lists you must complete in order. Follow your curiosity. The full catalog is in the sidebar, organized by section.