The vocabulary,as man pages.

The part of the spec an agent can check itself against. The book is blunt about it: the quality of the acceptance criteria decides the quality of every downstream phase.

An LLM combined with tools, context, and a loop that lets it pursue a goal across many steps. Underneath every framework abstraction, it is a while loop around a model call.

The book builds one in 50 lines so the abstraction stops being magic.

The ReAct cycle. Reasoning traces make behaviour interpretable, tool calls ground the model in observed reality, and the loop makes tasks of dozens of steps possible.

Its most powerful use in coding work is the self-correction loop: the agent runs the tests and fixes its own code from the failures.

A file checked into the repo that teaches every agent your conventions, your architecture, your commands, and the things it must never do.

It is the smallest unit of shared context a team can own, and the first thing the book tells a team to write.

The practice of building production software with AI agents in the loop at every step, while a human stays accountable for what to build, what the limits are, and whether the result is good.

It is not a tool, a vendor, or a philosophy. It is a delivery discipline. The three things it puts at the centre are intent, constraints, and verification.

A one-page workshop template that turns "how do we adopt AI?" into a set of decisions a team can answer together. Eight areas, roughly fifty prompts, 60 to 90 minutes.

Its output is a list of decisions and open disagreements, not a poster. A blank box is signal.

What happens when every change is locally reasonable and globally inconsistent. Each session picks its own patterns, and after fifty of them the codebase has five ways to do the same thing.

The fix is shared context: rules the agent reads every session, not conventions that live in senior engineers' heads.

The automatic fix for a full context window: the system summarises the session and continues from the summary. It works, and it does its work in the dark, so you cannot see what was dropped.

A scratchpad is the version of the same idea that you can read, edit, and carry into a fresh window.

The top of the rules tree: a small set of non-negotiables that every project inherits, with language, framework, and team rules composing underneath and cross-cutting concerns branching off to the side.

Versioned in Git, like everything else that matters.

The discipline that replaced prompt engineering. Context is everything the model receives: system prompt, rules, skills, tool definitions, retrieved code, conversation history, environment metadata. Your prompt is one component.

It has exactly two failure modes: too little context, so the model guesses, and too much, so the signal drowns.

What happens when a dozen MCP servers each inject tool descriptions into every session. The window fills with capability the agent does not need, and its tool choices get worse, not better.

Matching a task-specific configuration can hand more than 15% of the context budget back to the actual task.

The slow degradation of a long session as stale instructions, abandoned approaches, and dead tool output accumulate in the window.

Countermeasures: tighter scoping, file-based state you control, deliberate reinjection, and starting a new session more often than feels necessary.

The model's working memory: everything it can see when it produces the next token. It is finite, and attention across it is not uniform. Content at the start and end is attended more reliably than content in the middle.

Treat it as a budget you spend deliberately, not a bucket you fill.

Every pattern in the orchestration chapter assembled into one self-running line: a spec goes in, agents plan, write, and test in a loop, and a change you can review comes out.

It is where this is going. It is not an excuse to stop reading diffs.

One agent produces, a separate agent attacks, you filter the findings, and the work loops until it clears a stated bar.

Separation matters. An agent reviewing its own output is a much weaker check than an agent that was asked to break someone else's.

Give the agent a stated goal and an objective test for it, then let it iterate until the test passes or the cap trips.

Anchoring a model's answer in information you explicitly supply, rather than in what it happens to remember. The single most reliable countermeasure to hallucination in engineering work.

Output that is fluent, confident, and not true: an API that does not exist, a flag that was never added, a file that is not in the repo.

It is a property of next-token prediction, not a bug to be patched. You manage it with grounding, tools that fetch reality, and checks that fail loudly.

Everything around the model: rules, skills, tools, tests, feedback loops, guardrails, and the scripts that make them run. The model is bought. The harness is built, and it is yours.

It is the real deliverable of an AI-native team, and unlike a model it compounds week over week.

A design principle, not a bottleneck. Oversight sits at the seams between phases, where misalignment is cheapest to catch, rather than sprinkled through the middle of a run.

Calibrate it to risk. Reversible work can run hot. Payments, auth, migrations and infrastructure cannot.

In-weights knowledge was learned during training. It is frozen at the cutoff and can be confidently wrong about your API, your framework version, or last month's release.

In-context knowledge is what you put in the window. It is authoritative because you control it. The fix for a model that is wrong is almost always to inject the right information, not to argue with it.

A second model reading the change against the spec and the codebase's own conventions, catching the judgment calls a linter cannot: wrong abstraction, missed edge case, silent behaviour change.

It works best adversarially and before the pull request exists.

The measured tendency of models to use information at the extremes of a long context more reliably than information buried in the middle.

Practical consequence: put the constraint that matters where the model will actually read it.

The canvas, scored. Forty questions across the same eight areas, on a ladder from absent to enforced, producing a number, a radar, blind spots, and the three things to fix first.

The jump from "present" to "enforced" is deliberately large, because an unenforced practice is not a practice.

Model Context Protocol: one integration interface between any compliant AI tool and any compliant external service, over stdio or streamable HTTP.

It solves an N-by-M integration problem. It also costs tokens and quality on every connected server, so the working rule is to match active servers to the task at hand.

Four arrangements of the same subagent building block. Which one you want is decided by whether the work splits cleanly, whether the pieces need to see each other, and how the results get merged.

The shape the engineering role takes when implementation stops being the constraint. More time goes into the work before the work, review replaces writing as the primary activity, and verification is designed up front instead of bolted on.

It rewards judgment and systems thinking over syntax fluency, which is why the book argues software engineering is becoming a leadership role.

A file of path patterns that forces human review on the code where a bad change does the most damage. Deterministic, instant, and impossible to argue with.

Thirty minutes of work, and the highest-leverage single change most teams can make.

A review checkpoint inserted between the agent's reasoning and its actions. You read the plan before anything is written.

The bridge between vibe coding and full SDD, and the cheapest habit to adopt first.

The distance between code that reads as correct and code that is correct. Models are optimised to produce plausible output, and plausible output passes a casual review.

This is why verification, not generation, becomes the bottleneck.

A deterministic check that has authority. Linting, types, tests, mutation score, SAST, secrets scanning, dependency and container scans, IaC scans, architecture fitness functions, bundle budgets, contract checks, accessibility.

A gate that only warns is not a gate. The book's line on this is that an unenforced practice is not a practice.

Running the same agent against the same instruction file over and over, letting it pick up where the last pass left off. Crude, effective on well-bounded work, and only safe with hard limits and a clean exit test.

An AI judgment about how dangerous a change is, used for everything the deterministic path gate did not already catch. Two mechanisms, in that order, decide every pull request.

A plain file the agent writes its state, decisions, and open questions into. It survives a context reset, it can be reviewed, and it can be handed to a different agent or a different model.

The cheapest reliability upgrade in the whole book.

Tests used as observations rather than as a final gate. The agent gets an objective signal it can act on, which is why clear acceptance criteria and a working test suite are the best context you can give it.

It also explains why teams with no tests get so little out of agents: there is nothing for the loop to close on.

Packaged procedures: a named set of instructions, and sometimes scripts, that an agent pulls in when the task calls for it. Model-activated, user-activated, or disabled.

Most integrations people reach for MCP to build are better as a skill plus a CLI script.

The durable artifact. It survives tool changes, model upgrades, and staff turnover, which is more than can be said for a chat transcript.

Writing one is a discovery process. Most of its value is paid out before any code exists, in the questions it forces you to answer.

The brownfield strategy. You do not retroactively specify a decade-old codebase. You pick the modules with high churn and high blast radius and spec those, then let the islands grow.

Writing intent, constraints, and acceptance criteria down before an agent starts, and keeping that document as the artifact the work is judged against.

Agents never ask for clarification. They resolve ambiguity from training data instead of from your system. A spec is how you win that argument in advance.

The explicit rule that ends a loop. Every production agent needs one, and the good ones also know when to stop and ask a human instead of guessing.

A child agent with its own context window, given a scoped task and returning only its result. The main reason to use one is context isolation, not parallelism.

How an agent acts on the world: a named function with a schema and a description the model reads to decide when to call it.

Tool quality and stopping conditions are the two most underrated design concerns in agent work. A vague description wastes iterations; a missing stop condition burns money.

How an agent gets more autonomy: never assumed, always earned, and always on work you can undo. Each rung is a bet you can afford to lose.

Four automated layers, each leaning on the ones below it, with a human directing the whole thing from outside.

Cheap checks run first and catch the most. Expensive human attention is spent last, and only where it is needed.

Giving a model a rough idea, accepting its suggestions without reading every diff, pasting errors back in, and letting it keep going.

It works for prototypes and fails in production through three named failure modes: the plausibility gap, architectural drift, and missing context.

The book's position is not that vibe coding is wrong. It is that using it on production code is.

A second checkout of the same repository on the same machine, so two agents can edit files at once without fighting over the working tree.

The middle rung of isolation, between separate context windows and separate cloud machines.