AIDLC Glossary
The vocabulary of AI-native delivery, defined plainly. These are the terms you will meet in tool documentation, vendor pitches, and team discussions - stated tool-agnostically, so the definition outlives whichever product is popular this quarter.
Last reviewed: September 2026
Jump to a Term
Terms, A to Z
- Agent
- An AI system that takes a goal and executes multiple steps to reach it: planning, editing files, running commands, and checking results before handing back work for review. Unlike an assistant, it acts rather than answers.
- Agentic coding
- Delegating a scoped engineering task to an AI agent that plans the work, edits across multiple files, runs commands, and returns a diff. The developer defines the task and reviews the result; the agent does the mechanical execution.
- AGENTS.md
- A plain-Markdown instruction file at a repository root, written for whichever coding agent shows up: how to build and test, the conventions, and what never to touch. It is an open format that many agents read, so it is the portable alternative to keeping the same rules in a separate file per tool.
- AIDLC
- The AI Development Life Cycle: a five-phase framework - Analyze, Ideate, Develop, Launch, Curate - that integrates AI into every stage of software delivery, replacing the human-only assumptions of traditional SDLC.
- Assistant
- An AI system that responds to a single prompt with a single answer. It waits for instruction and does not act on its own. The chat interface most developers started with.
- Compaction
- Replacing the older turns of a long session with a summary so work can continue past the context window limit. What the summary drops is gone, which is why standing constraints belong in an instruction file that reloads afterward rather than in a message partway up the conversation.
- Context engineering
- The practice of curating what an agent sees: the smallest high-signal set of intent, acceptance criteria, code, docs, constraints, and guardrails that will do the job, plus a feedback loop it can run. More context is not better - accuracy and recall fall as the window fills - so it is the upstream work that determines whether output is production-ready or throwaway.
- Context rot
- The degradation in a model's accuracy and recall as its context window fills, independent of whether the added text is relevant. It is the reason context engineering is curation rather than accumulation, and the reason compaction, retrieval on demand, and subagents exist.
- Context window
- The maximum amount of text a model can consider at once, measured in tokens. Everything the model knows about your task in a given exchange has to fit inside it, and filling it is not free: accuracy and recall degrade as the count grows, a failure Anthropic's documentation names context rot.
- Diff review
- Reading and judging the specific changes an agent proposes before accepting them. In AIDLC this is the non-negotiable human checkpoint of the Develop phase.
- Eval
- A fixture set of real cases with known-good outcomes, run against a prompt, agent, or review rule every time it or the underlying model changes. For an agent it grades two things - the final state of the system and the trajectory that got there - with a mix of code checks and model-graded rubrics, so a regression is caught rather than shipped silently. The fixture set matters more than the tool that runs it.
- Evidence pack
- A release-time bundle of the change record, risk diff, impact matrix, rollback plan, and control mapping, generated from the ticket contract so an audit does not require reconstructing history after the fact. It is the compliance output of a disciplined pipeline.
- Grounding
- Anchoring a model's output in real, retrievable source material - your code, your docs, your data - rather than letting it rely on training-time recall.
- Guardrails
- The constraints placed around an agent's work: what it may edit, which commands it may run, which checks must pass, and what requires human approval before it proceeds.
- Hallucination
- Output that is fluent and confident but wrong - an invented API, a misremembered flag, a citation that does not exist. It is the reason review and grounding are structural rather than optional.
- Harness
- The tool an agent runs inside: the IDE, CLI, or platform that supplies file access, command execution, context management, permission gating, and a review surface, plus the loop that chains those actions together. The same model can behave quite differently across harnesses.
- Instruction file
- A repo-root file such as CLAUDE.md or AGENTS.md that an agent reads every session: how to build and test, the conventions, what never to touch, and where the risk tiers live. It is reviewed, versioned, and owned like any other code, since a poisoned or rotted one degrades every session that reads it.
- Invariant
- A property that must always hold true, declared up front so it can be checked automatically. Verifying by invariant asks whether a rule survives many generated cases, not whether one example happened to pass.
- Lane A / Lane B
- The two delivery modes for agent work: Lane A is developer-driven, with an agent inside the IDE and the developer as author of record; Lane B is agent-driven and unattended, restricted to tickets labeled agent-eligible and started on the safe work class only. Expansion into more work classes is gated on the change failure rate holding flat.
- Learn loop
- The compounding practice of turning every escaped defect into a versioned review rule, every repeated task into a skill, and every release into an evidence pack. A review agent kept on this loop gets better at a specific codebase every quarter; a generic one does not.
- MCP (Model Context Protocol)
- A standard way for models and agents to connect to tools, data, and systems. It replaces brittle one-off integrations with a governed interface to your docs, tickets, databases, and services.
- Merge queue
- A mechanism that batches verification ahead of merge, keeps the main branch green, and gives agents a safe place to repair rebase and lockfile conflicts without touching a protected branch directly. It is the mechanical answer to more pull requests than a pipeline can verify serially.
- Multi-agent workflow
- Several agents working on different parts of a problem, in parallel or in sequence, with their output merged and reviewed. It pays off when the tasks are genuinely independent, or when one agent's reading would otherwise crowd out another's context. The two common shapes are a lead delegating to subagents that return only a summary, and a generator paired with a separate agent that judges its work.
- Mutation score
- The percentage of deliberately injected code mutations that a test suite catches, exposing tests that assert nothing even when coverage looks complete. It is the test-quality metric coverage cannot provide.
- Orchestration
- Coordinating multiple agents, steps, or tools into a repeatable process: how work is split, how state is passed along, and where a human steps in.
- Plan approval
- A senior human reviewing and approving an agent's implementation plan - files, interfaces, migrations, risk tier, rollback - before any code is written, rather than reviewing the finished diff. Reviewing a plan catches architectural mistakes in minutes; reviewing a long diff mostly catches typos.
- Prompt
- The instruction given to a model or agent. In AIDLC a prompt is an input to a specification, not a substitute for one.
- Prompt injection
- An attack that hides instructions inside content an agent reads - an issue, a pull request comment, a README, a fetched web page, an MCP server response - so the agent executes them as if a human had typed them. The control is treating all retrieved content as data, never as instructions.
- Risk tier
- A classification of a change by blast radius - docs and flag-off scaffolding at one end, auth and money math at the other - that determines review depth and whether agent-authored code is even eligible. It is what lets review effort scale with consequence instead of with volume.
- Risk-tiered review
- Classifying a diff against its approved plan and the CODEOWNERS map, then routing it to auto-merge, single-reviewer, or two-reviewer-plus-architect review by risk tier. Uniform review collapses once pull request volume rises; this is what replaces it.
- Sandboxing
- Confining an agent's commands to a filesystem and network boundary the operating system enforces, so it can work without an approval prompt for every step and a mistake or an injected instruction cannot reach past the boundary. It is a separate layer from the permission rules that decide what the agent may ask for.
- SDLC
- The Software Development Life Cycle: the traditional model of building software in defined phases, designed in an era when every phase was carried out exclusively by humans.
- Shadow AI
- AI tool adoption that happens outside an organization's official rollout: no logging, no shared standards, no way to assess impact, and data leaving through personal accounts. Governance exists to bring this into the open before it becomes the default.
- Skill
- A versioned, testable procedure an agent runs the same way every time a repeated task recurs, written as a file the agent discovers by its description and loads only when it applies, rather than reconstructing the approach from a fresh prompt. The SKILL.md format is an open standard that several agents now read. Like a review rule, it needs an eval to catch the quarter it silently regresses.
- Slopsquatting
- Registering a package name that models hallucinate in generated code, so that a project's own build installs the attacker's package instead of a real dependency. One large study found about one in five package recommendations hallucinated (19.7%, USENIX Security 2025). A registry allow list and a new-dependency review gate are the practical controls.
- Spec-driven development
- Writing a clear specification first, having an agent plan and execute against it, then reviewing the result against that spec. It is the disciplined alternative to prompting loosely and hoping.
- Subagent
- A second agent the main one hands a scoped task to, running in its own context window with its own tools and returning only a summary. It keeps a large search, log, or file read out of the session that spawned it, and it is how one run is split to work on several things at once.
- Test theater
- Generated tests with high coverage and no assertions of consequence: a green build that proves nothing because coverage measures execution, not verification. Mutation testing is the check that catches what test theater hides.
- Ticket contract
- A ticket written so a machine can test against it: structured acceptance criteria, a data contract, the requirement it implements, data classification, required audit log writes, a feature flag name, a rollback plan, and a risk tier. It is the unlock that tests-first delivery and compliance evidence both depend on.
- Token
- The unit models read and write, roughly a fragment of a word. Context windows, pricing, and rate limits are all measured in tokens.
- Verification tax
- The human review and validation cost that cheap AI-assisted authoring shifts downstream rather than eliminating. DORA's 2026 research names it as the mechanism behind the productivity paradox.
- Vibe coding
- Prompting loosely and accepting whatever an agent produces without meaningful review. It ships quickly and accrues debt invisibly, and guarding against it is much of why AIDLC exists.
- Work class
- The category a task falls into for delegation purposes: safe to delegate unattended (test backfill, dependency bumps, copy, scaffolding) versus never unattended (money math, auth, PII paths, rule engines, infrastructure). Lane B expands one work class at a time, gated on the change failure rate holding flat.
Frequently Asked Questions
An assistant answers a single prompt and waits for the next one. An agent takes a goal and executes multiple steps to reach it - planning, editing files, running commands, and checking its own work - before returning a result for review. The distinction matters because agents demand different habits: scoping the task, setting guardrails, and reviewing every diff.
Vibe coding means prompting loosely and accepting whatever comes back without meaningful review. Spec-driven development inverts that: you write a clear specification first, have the agent execute against it, and review the result against the spec. One optimizes for speed, the other for output you can defend.
No. AIDLC is designed to be readable without jargon, and each phase page explains its concepts in context. This glossary exists so that when a term does surface - in a tool's documentation, a vendor's pitch, or a team discussion - you have a precise, tool-agnostic definition to reach for.
Put the Vocabulary to Work
Knowing the words is the start. Learn the five-phase framework they describe, and keep the cheatsheet within reach.