Glossary
Two people who say "we're at L3" can mean different things, and the difference is usually what a human still checks. This glossary pins down the terms the book relies on: the five levels, the rules that keep a level honest, the evidence tiers and their flags, the review-metric vocabulary, and the names of the controls and measurements in the migration chapters. Each entry gives the book's meaning in a sentence or two and links to the place that defines and argues for it. Where another model uses the same word differently, the crosswalk at the end translates it.
Using this glossary
Entries are alphabetical. A definition here is a summary; the linked section has the evidence, the caveats and the tier of each source. Terms marked "the book's proposal" in a chapter are proposals here too: no organisation has validated them against outcomes. The six review metrics (useful, addressed, led to change, resolved, actionable, marked incorrect) are filed under their own letters, because vendors use them as if they were one metric and they are not. Product capabilities mentioned in passing are as of October 2026.
A–B
Acceptance rate — The share of AI-generated suggestions, tests or fixes that a human accepts. It measures agreement, not correctness, and is never the success metric on its own. See Testing & Verification.
Actionable (review metric) — A property of a whole review, not of a comment: the review posted at least one comment. See Code Review.
Addressed (review metric) — The code changed in the same changeset in a way that responds to the comment, as judged by a rule or a model. See Code Review.
Agents Rule of Two — Meta's design rule: within one session an agent may have at most two of three properties: it processes untrusted input, it can reach sensitive systems or private data, and it can change state or communicate externally. See Security, Permissions & Blast Radius.
Amdahl's arithmetic — Speeding up one segment of lead time can never save more than that segment's share, and any growth downstream (such as longer review) is paid out of that ceiling. See When Code Gets Cheap, the Bottleneck Moves.
Amplifier — DORA's 2025 finding that AI magnifies an organisation's existing strengths and weaknesses; weak tests, large batches and unclear ownership get louder, not fixed. See Preface: How to Read This Book.
Attribution — Marking agent output as such, by a label, a commit trailer, a bot identity or metadata. Required from L2 up; without it, a phase cannot be scored above L1 and no escaped-defect comparison is possible. See The AI-SDLC Maturity Model.
Audit sample — A periodic human check of items that no longer get per-item review. Required at L4, and kept on any class routed away from human review at L3. See The AI-SDLC Maturity Model.
Authority drift — A rollback trigger: any agent credential or setting found reaching beyond its permission envelope (production reach, a skip-permission mode, an irreversible API). The threshold is one; the action is to revoke and treat it as an incident. See Measuring Success and When to Roll Back.
Background coding agent — An agent that runs a task unattended, usually in a sandbox, and returns a pull request rather than working beside a developer in an editor. It is the typical L3 coding set-up. See Coding.
Baseline — The measurement of the same task type done without the agent, taken before the agent starts: history from the previous 90 days plus, ideally, a concurrent comparison. It cannot be taken later, once people work differently. See The 90-Day Pilot.
Batch size — How much change moves through review and release at once (lines per change, changes per release). DORA's proposed mechanism for AI-associated instability is that larger batches are harder to review. See When Code Gets Cheap, the Bottleneck Moves.
Blast radius — Everything an agent's credentials can reach and damage. It is set by the credential and the environment boundary, not by the model. See Security, Permissions & Blast Radius.
C–E
Catching test — A test generated for a code change before it lands, designed to fail if the change has a bug. Unlike a hardening test, it cannot land with the change it tests. See Testing & Verification.
Change failure rate — The DORA metric for the share of releases that cause a failure in production. The book uses it as a stability pair for CI/CD climbs. See CI/CD & Release.
Constraint — The phase where work waits longest, found by mapping measured wait and active times. Speeding up any other phase lengthens the queue in front of it. See Assess Your Starting Point.
Cost per merged change — Agent tokens, CI, AI review, reviewer time and rework, divided by changes merged. No organisation has published it including human review time. See Economics, Risk and Measurement.
Counterfactual estimate — A "saving" computed as what the work would have cost without AI, such as developer-years saved. It shows where an organisation believes the value is; it is not a measurement. See Economics, Risk and Measurement.
Crosswalk — The book's reading of how other maturity models' levels map onto its L0–L4, repeated in section C.9 below. See The AI-SDLC Maturity Model.
De facto L4 — A level nobody chose: an agent whose credentials let it act without per-item approval on something it can reach (often production) is at L4 for that reach, whatever the team calls it. Every destructive incident in the book is one. See The AI-SDLC Maturity Model.
Deterministic automation — Codemods, dependency bots and rule-based rewrites. However autonomous, they count as L0 for AI. See The AI-SDLC Maturity Model.
Disputed (evidence flag) — The parties' accounts of a case conflict. The book prints both and does not attribute the outcome to "the AI" or "the human" alone. See Preface: How to Read This Book.
Egress control — Limits on where a running agent can send data. From L3 up, the envelope is default-deny with an allow-list. See Security, Permissions & Blast Radius.
Enablers — DORA's seven AI capabilities (clear AI stance, healthy data ecosystems, AI-accessible internal data, strong version control, small batches, user-centric focus, quality internal platforms), treated as preconditions for a climb, not as levels. See The AI-SDLC Maturity Model.
Entry criterion — The evidence a task type must show before it moves to the next level, stated at the end of each Part II chapter. Teams climb by meeting it, not by asking. See Scaling Across Teams.
Equivalent mutant — A mutant that cannot be killed because it does not change behaviour. It inflates the denominator of a mutation score unless filtered out. See Testing & Verification.
Error budget — An agreed amount of failure a task class may incur. It is one of the two forms of verification record an L4 class needs. See The AI-SDLC Maturity Model.
Escaped defect — A defect that got past every check and reached production. L3 requires the escaped-defect rate of AI-run work to be compared with a human baseline over at least 90 days. See The AI-SDLC Maturity Model.
Evidence bundle (evidence pack) — What a human reviews at L3 instead of every line: the verifier results, a summary of the change and, for fleet changes, a sample of files. Its structured form is the Merge-Readiness Pack. See The AI-SDLC Maturity Model.
Evidence tier — The grade on every case and every number that carries an argument, T1 to T4. A source's tier is the lower of who measured and how they measured. See Preface: How to Read This Book.
Extend, hold, step down — The three outcomes of a pilot, each fixed by a rule written in advance. Extend: flow improved and stability held. Hold: nothing broke and nothing improved, so do not climb. Step down: a stop fired, so return to the previous level. See The 90-Day Pilot.
F–K
Fabricated evidence — A diagnosis that cites logs, metrics or events that do not exist; the most common reasoning failure in one independent root-cause study. Measure its rate by sampling agent-written incident reports. See Operations & Incidents.
Fitness function (architecture) — An automated check that a change conforms to architectural rules. It is the verifier a design L3 would need; nobody has published one gating agent changes. See Requirements, Specs & Design.
Flaky test — A test that passes and fails on the same code. Flaky-test triage and repair are among the most delegable testing task types. See Testing & Verification.
Flow metric — The metric that should improve if a climb works, such as lead time, wait time or changes landed. Never reported without its stability pair. See Measuring Success and When to Roll Back.
Four readings — The assessment taken per phase and task type: what a human reviews and when, which verifier the AI cannot edit, which credentials the AI holds, and how much risk the phase can bear. See Assess Your Starting Point.
Generator-verifier gap — Generating output has become cheap and checking it has not, so system-level gains are capped by verification. See When Code Gets Cheap, the Bottleneck Moves.
Granted authority (Rule 2) — What the AI's credentials and settings actually allow. A phase's level is the higher of the review mode the team practises and the authority granted. See The AI-SDLC Maturity Model.
Guardrail — Something the agent cannot talk its way past. Instructions, approval clicks and command allow-lists are not guardrails in this sense; environment and credential scope are. See Security, Permissions & Blast Radius.
Hallucinated package names — Dependencies a model invents. Because the same names recur across queries, an attacker can register them; a lockfile and a registry allow-list are the defence. See Economics, Risk and Measurement.
Hard stop — A pilot stop that fires immediately on a safety event: the agent edits or skips its verifier, acts outside its envelope, or causes an incident above a named severity. See The 90-Day Pilot.
Hardening test — A generated test that passes when created and lands to guard against future regressions, as in Meta's TestGen-LLM and ACH. See Testing & Verification.
Human co-commit share — How often a human pushes commits to an agent's branch before merge. A rising share means people are finishing the agent's work. See Coding.
Instability — DORA's measure of delivery that goes wrong (failed changes, rework). AI adoption has been associated with more of it in both the 2024 and 2025 surveys, and faster delivery did not offset it. See When Code Gets Cheap, the Bottleneck Moves.
Instruction file — A repository file (AGENTS.md, CLAUDE.md and similar) that tells agents the commands, conventions and constraints they cannot guess. The book recommends short and human-written; the evidence that such files improve success is mixed. See Coding.
Intent violation — A change that makes a check pass by defeating its purpose: a downgraded version, a deleted or skipped test, an edited CI configuration. Count the ones your post-agent checks block. See CI/CD & Release.
Irreversible action — An action with no undo, such as deleting data with no soft delete. It makes a task class ineligible for L4; at L3 the agent prepares and a human executes. See The AI-SDLC Maturity Model.
Jagged frontier — AI capability is uneven across tasks that look alike, so results vary by task rather than by phase or team. See Economics, Risk and Measurement.
Junior track — The book's proposal for developing juniors when agents write first drafts: tutor mode by default, review-first apprenticeship, AI-off debugging drills, protected mentorship and graduated authority. See People: Roles, Skills and the Junior Pipeline.
Kill switch — A control that pauses every in-flight agent action at once, such as Google's "Red Button". Required at L4 alongside continuous monitoring. See The AI-SDLC Maturity Model.
L–M
L0 Manual — No AI touches the phase's outputs, or policy prohibits it. Deterministic automation counts as L0 for AI. See The AI-SDLC Maturity Model.
L1 Assisted — AI suggests and a human authors every artefact; AI output enters only as suggestions the human edits. See The AI-SDLC Maturity Model.
L2 Delegated — For a named, recurring task type, the AI produces complete artefacts, and 100% of them get recorded human review before they take effect; output is attributed and an instruction file exists. See The AI-SDLC Maturity Model.
L3 Supervised-autonomous — For named routine task types, the AI runs end to end and a human reviews an evidence bundle, a sample or only the routed items. Routing is machine-enforced, pause and rollback have been exercised, a 90-day comparison with a human baseline exists, and the AI cannot change its evaluator. See The AI-SDLC Maturity Model.
L4 Autonomous (task class) — For one enumerated, narrow, reversible task class, the AI acts without per-item approval, under a verification record, continuous monitoring with a kill switch, a named accountable human and periodic audit samples. Always written with its scope. See The AI-SDLC Maturity Model.
L5 — Not part of this model. General autonomy either does not exist or has no controls, according to the sources that define it. See The AI-SDLC Maturity Model.
Led to change (review metric) — A later commit touched the code the comment referred to. It does not say the change was right or needed. See Code Review.
Lethal trifecta — Simon Willison's name for the combination the Rule of Two forbids, seen from the attacker's side: untrusted input, access to private data and a way to send it out. See Security, Permissions & Blast Radius.
LLM judge — A model that scores or vetoes another model's output. Use it as a tunable second gate with a false-positive cost, never as the oracle or as a safety layer. See Maintenance & Migrations.
Managed settings — Administrator-pushed tool configuration that users cannot override, used to disable bypass and auto-approve modes on every machine. See Scaling Across Teams.
Manual tail — The part of a migration the pipeline cannot finish and people do by hand. A rising tail means the change class is drifting outside what the pipeline can verify. See Maintenance & Migrations.
Marked incorrect (review metric) — A human explicitly flagged a finding as wrong. It is a floor on false positives, since most wrong comments are simply ignored. See Code Review.
Maturity grid — Eight phases by five levels, each cell giving an observable criterion and the best public evidence with its tier. See The AI-SDLC Maturity Model.
Maturity level — What a human reviews, and when, read together with the authority the AI actually holds, scored per task type over a trailing 30- or 90-day window. Capability, agent count and rollout breadth are left out on purpose. See The AI-SDLC Maturity Model.
"Measured by" line — The line under every case and argument-carrying number: who measured, the method, the sample or window, and the tier. See Preface: How to Read This Book.
Merge-Readiness Pack — Hassan et al.'s structured evidence bundle submitted for human approval, showing functional completeness, sound verification, engineering hygiene and an audit trail. It is what an L3 reviewer reads instead of the diff; a blank is in Templates. See The AI-SDLC Maturity Model.
Mixed independence (evidence flag) — A study with a stated method whose authors include employees of a vendor with a stake in the result. It counts as T1 with the flag. See Economics, Risk and Measurement.
Model gateway — A central proxy for model access that enforces approved models, measures use per team and carries per-team budgets. See Scaling Across Teams.
Moderators — The four factors that move a measured productivity effect: task type, familiarity with the code, codebase maturity and tool generation. Quote a range with its moderators, never one number. See Economics, Risk and Measurement.
MTTM (mean time to mitigate) — Average time from an incident's start to its mitigation. Measure it per incident class, against a baseline. See Operations & Incidents.
Mutation score — The share of deliberately injected faults (mutants) that a test suite detects. It is the better measure of what tests would notice; coverage is a weak proxy. See Testing & Verification.
O–R
Oracle — The automated check that decides pass or fail for a task type: tests, mutants, the compiler, a plan classifier or a policy engine. Also called the verifier. See The AI-SDLC Maturity Model.
Oracle principle (Rule 1) — No task type runs at L3 or L4 unless an automated verifier decides pass or fail and the AI cannot edit, skip or redefine it. A claimed L3 without one is recorded as L2. See The AI-SDLC Maturity Model.
Oracle tampering — A rollback trigger: any merged agent change that deletes, skips or weakens a test or check, or edits CI or verifier configuration. The threshold is one; the task type stops at once. See Measuring Success and When to Roll Back.
Paired metrics — The rule that every climb is judged on one flow metric and one stability metric, reported together. See Measuring Success and When to Roll Back.
Permission envelope — The book's proposal for what an agent at L2, L3 and L4 may run on, hold, change and read: where it runs, credentials, write scope, network, irreversible actions, untrusted input, its own configuration, dependencies and the gate. If any setting belongs to a higher column, that is the level. See Security, Permissions & Blast Radius.
Policy (evidence flag) — The source states a rule, not a result, such as a ban or a mandate memo. It is never cited as evidence of an outcome. See Preface: How to Read This Book.
Precision tuning — Configuring an AI reviewer or router to stay silent unless confident: confidence thresholds, suppressed low-value categories, permission to say nothing. It comes before coverage. See Code Review.
Prompt injection — Untrusted text (an issue, a README, tool output) that steers an agent into actions its user did not intend. Anything an agent reads is potential input to its own controls. See Security, Permissions & Blast Radius.
Provenance — A machine-readable record of what the AI did in each change and which human answers for it, typically a commit trailer. The book's proposal: the agent never signs; at L2 the approving reviewer signs; at L3 and L4 the owner of the task class does. See Scaling Across Teams.
Queue overflow — A rollback trigger: review wait time, or merges with no review, above baseline by an agreed margin. It throttles generation; the level stays. See Measuring Success and When to Roll Back.
Resolved, AI-judged (review metric) — A model decided at merge time that the flagged issue was fixed. See Code Review.
Review mode — What a human looks at, and when: every line, an evidence bundle, a sample, or nothing. It is one of the two readings that define a level. See The AI-SDLC Maturity Model.
Review throttle — A cap that sets generation to review capacity, such as open agent PRs per owning team. Generating faster than people can review only lengthens the queue. See Maintenance & Migrations.
Reviewer noise — A rollback trigger: the "Not useful" rate for an AI reviewer's comment category goes above a threshold set before launch, with Google Tricorder's 10% as the template. It disables the category, not the phase. See Measuring Success and When to Roll Back.
Reward hacking — An agent meeting the letter of a check rather than its intent: modifying tests or scoring code, monkey-patching an evaluator, or deleting the change that failed. It is why the oracle principle exists. See The AI-SDLC Maturity Model.
Rework rate — The share of delivered work that has to be redone, a DORA metric. The book uses it as a stability pair for flow gains. See Measuring Success and When to Roll Back.
Risk ceiling (Rule 4) — The maximum level for each phase and risk class, recorded before anyone proposes a climb; for example, nothing above L2 in CI/CD for regulated services, and no L4 where an action is irreversible. See The AI-SDLC Maturity Model.
Risk tier — A class of change, built from your own incident history, that decides how much human review it gets. See Code Review.
Rollback trigger — A pre-agreed rule that takes autonomy back, with six parts written before the climb: signal, threshold, window, action, owner and re-entry condition. The book's proposal; no company has published one for coding agents. See Measuring Success and When to Roll Back.
Routing rules — Written, machine-enforced rules that decide which items reach a human at L3. The AI must not be able to change them; for review, the routing rules are the verifier. See Code Review.
Rule 6 (the coding-gap heuristic) — Run Coding at most one level above the lower of Review and Testing. It is the book's proposal, based on correlational telemetry, and is used as a tripwire, not a law. See The AI-SDLC Maturity Model.
S
Sandbox — An isolated, usually ephemeral, environment for unattended agent runs. Required from L3, with both a filesystem boundary and a network boundary. See Coding.
Scoped credential — A credential that is short-lived and limited to one task, injected from outside the sandbox, so that what the agent cannot reach it cannot damage. See Security, Permissions & Blast Radius.
Scorecard — One row per phase and task type: level and evidence, flow and stability metrics with baselines, the trigger that sends the row down, and its owner. The pilot version is signed before the agent's first run. See Measuring Success and When to Roll Back.
Secondary (evidence flag) — The figure was read only in press coverage of a primary source the book could not read, and the sentence says so. See Preface: How to Read This Book.
Self-assessment grid — The form for scoring each phase and task type: level, evidence, oracle and who can edit it, risk ceiling, and credentials held. Re-scored every quarter. See The AI-SDLC Maturity Model.
Self-healing CI — A vendor name for pipelines whose agents fix their own build failures. In this book's terms it is L2 when a human merges each fix, and L3 when fixes auto-apply after an independent verification step. See CI/CD & Release.
Self-report (Rule 7) — How fast or safe people feel. It is never evidence of a level or a success criterion: in METR's 2025 trial developers were 19% slower and believed they were 20% faster. See The AI-SDLC Maturity Model.
Shadow comparison — For a period, one responder works with the tool and one without (or with the current tool), and the times are compared by incident class. See Operations & Incidents.
Shake-down — The pilot weeks spent fixing the agent's environment (feeds, timeouts, setup steps) that do not count toward the verdict. See The 90-Day Pilot.
Share of code written by AI — A volume figure whose definition shifts from one statement to the next and which rises whether or not anything ships faster. It is never a success metric, and never compared across companies. See Economics, Risk and Measurement.
Skip-permission mode — A tool setting or flag that turns off permission prompts, such as --dangerously-skip-permissions or --yolo. On a machine with real credentials it is an unrecorded L4 grant; disable it in managed settings outside disposable containers. See Security, Permissions & Blast Radius.
Soft delete — A deletion that can be undone for a period. Irreversible actions become L4-eligible only through APIs with undo or soft delete and backups outside the blast radius. See Security, Permissions & Blast Radius.
Spec-anchored — Böckeler's term for keeping the spec after the task is done and using it to evolve the feature. See Requirements, Specs & Design.
Spec-as-source — Böckeler's term for making the spec the main source file, with humans never touching the code. It is an L3 or L4 claim about coding with no published evidence. See Requirements, Specs & Design.
Spec-driven development — Writing a spec that an agent implements, with tools such as Spec Kit and Kiro. Spec depth should scale with task size; a spec whose success condition the agent can rewrite is not a control. See Requirements, Specs & Design.
Spec-first — Böckeler's term for writing a spec before the task and using it for that task only. It is an L2 practice. See Requirements, Specs & Design.
Stability metric — The metric that would show a climb backfiring, such as reverts, escaped defects, rework or change failure rate. See Measuring Success and When to Roll Back.
Stance — The written statement of which phases and task types may run at which level, under what ceiling, with which tools, and who may step a team down. DORA found that a clear stance amplifies AI's benefit, whatever it says. See Scaling Across Teams.
Stepping down — Lowering one task type by one level when a trigger fires. Pre-wired, exercised, scoped and recorded without blame, it is normal operations, not defeat. See Measuring Success and When to Roll Back.
Stop hook — A deterministic check that runs when an agent tries to finish and blocks it until the check passes, so the verifier sits outside the agent's control. See Coding.
Stop rule — A pilot's pre-agreed exits, written before any result and applied by a named person: hard stops on safety, threshold stops on stability, and holds at day 90 on flow and cost. See The 90-Day Pilot.
Success rate per task type — Agent PRs merged divided by those merged or closed, tracked separately for each task type. See Coding.
T–W
T1 Independent measurement — Measured by a party with no product stake, using a stated method with denominators: a randomised trial, controlled study, benchmark or forensic analysis. See Preface: How to Read This Book.
T2 Organisation-measured, stated method — Measured by the organisation running or selling the system, with a method and denominators, ideally peer-reviewed or reproducible. See Preface: How to Read This Book.
T3 Telemetry or report, thin method — Numbers without a full method, baseline or n: engineering blogs, vendors' pooled customer telemetry, uncontrolled pilots. Take their direction, not their magnitude. See Preface: How to Read This Book.
T4 Claim — No method at all: executive statements, press relays, marketing, disputed accounts, policy memos. Never used to carry an argument. See Preface: How to Read This Book.
Task class — The enumerated, narrow scope an L4 grant covers, such as "dependency patch bumps". L4 never applies to a whole phase. See The AI-SDLC Maturity Model.
Task type (Rule 3) — A named, recurring kind of work within a phase, the unit the model scores: "Testing: L3 for flaky-test triage; L2 for feature tests". Task type, not task size, decides what can leave per-diff review. See The AI-SDLC Maturity Model.
Team archetypes — DORA's seven 2025 clusters of teams, from "foundational challenges" to "harmonious high-achiever". A diagnostic of how a team works, not a ladder; stabilise a legacy-bottleneck team and fix a process-constrained one before any climb. See Assess Your Starting Point.
Threshold stop — A pilot stop checked at review points: reverts or traced defects above a count fixed in advance. It is an absolute threshold, not a significance test. See The 90-Day Pilot.
Throughput — DORA's measure of how much change a team delivers. The sign of AI's association with it differed between DORA's 2024 and 2025 surveys, which the book does not call a trend. See When Code Gets Cheap, the Bottleneck Moves.
Tool poisoning — Instructions hidden in an MCP tool's description, invisible to the user but read by the model, or a description changed after approval. See Security, Permissions & Blast Radius.
Typed tools — A closed catalogue of mitigations (drain, rollback, restart, add capacity), each with a risk tag, an undo path and a maximum level, from which an operations agent selects instead of writing commands. It defines L2 in operations. See Operations & Incidents.
Unmodified-merge share — Merged agent PRs that went in with no further commits. See Coding.
Useful (review metric) — A human rated the comment helpful. Opt-in, so it counts only the people who bothered to click. See Code Review.
Value-stream map — A map of every step from ticket to production, with measured wait and active times, used to find the constraint before choosing where AI goes. See When Code Gets Cheap, the Bottleneck Moves.
Vendor-reported box (vendor-on-own-product) — The labelled box for any figure whose only source is the vendor of the product measured. It states who measured, what "success" means in their metric and what is missing; the main text never rests an argument on it. See Preface: How to Read This Book.
Verification record — The documented evidence an L4 class needs: N consecutive items with no escaped defect, or an error budget. See The AI-SDLC Maturity Model.
Verifier — Another name for the oracle: the automated check that decides pass or fail. What matters is who can edit it. See The AI-SDLC Maturity Model.
Wait time and active time — How long work queues before someone picks it up, and how long it is actively worked. Measure them separately: active review time can fall while the queue in front of it grows. See When Code Gets Cheap, the Bottleneck Moves.
Translating other models
When someone says "we're at Level 3", ask whose scale they mean. This is the crosswalk from The AI-SDLC Maturity Model: the book's reading of each model, with "≈" marking an approximate mapping. Several models count agents, rollout breadth or capability; this book's levels count what a human reviews and what the AI is allowed to do, so some rows map only in part.
One warning closer to home: the wiki's own autonomy levels page counts from L0 = "Suggest", so its L0 to L2 sit one step below this book's numbers.
What to do.
- When anyone reports a level, ask for the task type, the review mode and the credentials held. Without all three, the number means nothing.
- Translate any vendor or analyst level through the crosswalk before you compare it with your own scores.
- Ask which of the six review metrics a reviewer figure uses, and never rank two vendors that use different ones.
- Tag every number you quote internally with its tier, T1 to T4, and its flags.
- Use these definitions in your stance and scorecard so that "L3", "verifier" and "evidence bundle" mean the same thing in every team.