Glossary

Agentic software engineering is a fast-evolving topic, and it seems that many concepts have been given overlapping or contradictory names. Part of the purpose of this book is to articulate coherent vocabulary for the field. The glossary is divided into four parts: the core ideas of the book, the vocabulary for coding agents and their accompanying phenomena, the terms for the governed engineering environment that stabilizes them, and a few terms from the case study that grounds the book.

The core ideas

The ideas the whole argument turns on — the two theses, the conversion that grows the environment, the governing metaphor, and the vocabulary of models underneath them.

Model. A cheaper, structured approximation of a system that an agent can reason through and an engineer can specify, analyze, and predict on. The base term the Modeling Thesis turns on.

Map and territory. A model is a map, not the territory: it earns its use by dropping detail and never stands in for the running system itself.

Modeling Thesis. Bind intent and system structure into an explicit, structured model, and the fleet gains a compact representation to reason through while the engineer gains a surface to specify, analyze, and predict on.

Alignment Thesis. A governance mechanism the environment enforces holds implementation to intent. A policy decided once then stands against every later change, so confidently-wrong work is made visible instead of shipped.

Governance Conversion. Converting a recurring failure into a durable engineering mechanism that permanently retires that failure class.

The Printer. The book's governing metaphor: treat a coding agent as a 3D printer, not a coder — it builds almost anything you describe, and only what you describe. A bad build is evidence about the instructions, not a limit in the machine.

Judgment is the scarce resource. The book in one sentence: agents make implementation cheap, so the expensive part becomes judgment — what to build, what "correct" means here, which failures deserve a wall and which a note. Those calls stay human. The discipline that pays converts each one into infrastructure, encoding a decision once so no agent has to make it again.

Middle-range theory. After Merton: not a universal law, not raw description, but a mechanism bounded by stated scope conditions. It names the register of this book's claims — a theory drawn from one deep case, transferable wherever its conditions hold, never a coefficient asserted over all software.

How coding agents work (and fail)

What a fleet of coding agents is, and the ways it comes apart.

Churn. The agent-fleet form of velocity decay: an increasing share of effort spent rediscovering context, undoing recent changes, repairing regressions, or reconciling inconsistencies rather than advancing the system.

Context Window. The bounded amount of prior conversation and code an agent can hold at once. Fixed the moment you choose the model, it is the sharpest driver of churn when the work outgrows it.

Foundation model. The trained model at the bottom of the agent stack. Choosing it fixes the context window and the reasoning ceiling every layer above works within.

Agentic harness. The runtime wrapped around the foundation model — Claude Code, OpenCode, and their kin — that feeds it prompts, manages the context window, and hosts the hook, skill, and tool mechanism points.

Skill. A soft mechanism the agent can choose to enter: trigger criteria plus a body of guidance — prose, or prose mixed with code — for a recurring kind of work.

Tool. The code half of a skill: a library or command-line entry point that lets the agent take a deterministic action — rewrite a run of text, add a page — instead of guessing at it.

Fleet. The set of coding agents working the codebase — the agentic-era workforce this book governs, in place of a team of human engineers.

One-shot Scripting. The task mode for a small, unsubtle job: describe the process once, get it back in a single pass, no supervision loop.

Supervised Autonomy. The task mode for hard, reasoning-heavy work: you supply correctness conditions, tools that determinize the recurring steps, and monitoring to shape the process, rather than taking a single unsupervised pass.

Loop engineering. Shaping the agent's generate-check-correct loop — the correctness conditions, the tools that determinize recurring steps, the monitoring — instead of steering a single pass. Nearly everything in this book is an instance of it.

The Governed Engineering Environment

The environment that holds the fleet to a standard, and the mechanisms it is built from.

Governed Engineering Environment. What you get when engineering policy is encoded into the environment itself — models, constraints, sensors — rather than held in a person's memory.

Support ratio. Support-apparatus lines of code divided by production lines of code — a measure of how much governed environment a fleet has built around the product it governs.

Governance Mechanism. A repeatable environmental structure that encodes an engineering policy and does one of four things: constrains an action, detects a violation, requires evidence, or controls admission.

Constraint. A governance mechanism that prevents drift by scoping the action space, so the mistake is impossible to make in the first place.

Sensor. A governance mechanism that catches a violation after the fact instead of preventing it, failing the iteration so the mistake cannot ship unnoticed.

Validator. A governance mechanism of the evidence or admission class: it checks a candidate result against a standard before the result may advance, and refuses or flags what fails.

Gate. A check placed across a pipeline step, such as a commit or a deploy, that refuses to let the step through until its condition is met.

Lint. An automated check that scans code for a banned pattern and fails the commit when it finds one, so a rule holds without a human remembering it.

Hook. A hard mechanism the harness fires deterministically at an injection point — before or after the agent acts. The enforcement primitive that lints and gates are built on.

Invariant. A predicate over a model that must always hold — the testable claim a gate or a model-checker enforces.

Model drift. A model and the code it describes stop agreeing — the divergence a drift gate exists to catch.

Drift Gate. A build-time check that fails when a model and the code it describes disagree, keeping the model from decaying into stale documentation.

Structured (model). Said of a model written in an explicit, declared shape a machine can read and validate — a schema, not prose — so a build can check the system against it for drift.

Executable source-of-truth. An architecture that binds a model and the code that must agree with it tightly enough that a drift gate can block the build the moment they diverge.

Traceability. The round-trip join between a model and the code it governs: every model node maps to the code it constrains, and back.

Pattern. Following the Gang of Four's Design Patterns form — name, recurring problem, solution shape, consequences, known uses — the book writes each governance mechanism as a pattern, so an engineer can reach for a vetted answer instead of re-deriving one.

The Model Zoo. Part 3's tour of the 4+1 architectural views — logical, process, development, physical, scenarios — as executable, drift-gated models, each walked on the real DocAble codebase.

DocAble specifics

Two mechanisms from the book's running example, DocAble.

Fidelity Validator. The mechanism that asserts a remediated document's meaning survived the remediation, catching the case where a file became more accessible and less true to the original.

Provenance Layer. The mechanism that stamps every artifact the system inserts, so a document's remediation history can be reconstructed and any single change explained or reversed. (Distinct from model provenance, which tracks what a derived model was generated from.)