AIDLC Glossary

Terms, A to Z

A2A (Agent2Agent)

An open protocol for communication between AI agents built by different vendors and frameworks. Agents publish a signed Agent Card describing their skills, then exchange tasks and results over HTTP. Google launched it in 2025 and donated it to the Linux Foundation; IBM's Agent Communication Protocol merged into it, and it complements MCP, which connects agents to tools.

ADR (architecture decision record)

A short, versioned document that records one significant design decision: the context, the decision, its consequences, and the alternatives rejected. The Ideate phase produces ADRs, and agents read them as constraints - a plan that contradicts an accepted ADR is rejected at plan approval.

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, now governed as a Linux Foundation project, 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.

Analyze (phase)

The first AIDLC phase: turning raw input - stakeholder notes, tickets, research - into a requirements brief with acceptance criteria, open questions and risks. AI drafts and surfaces gaps; the product owner decides scope. See Analyze.

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.

Background agent

An agent that runs a task without a person watching - in a cloud sandbox or CI rather than in the developer's editor - and returns a draft pull request when done. Background agents are how Lane B work runs, which is why they start on the safe work class only.

Baseline

The measured state of delivery before AI adoption - cycle time, review turnaround, change failure rate, escaped bugs - captured so later results have something to be compared with. Without one, a reported improvement is a vibe. See Measuring Impact.

Change failure rate

The share of deployments that cause a failure in production needing a fix, rollback or hotfix. One of the DORA delivery metrics, and the one to watch when AI raises output faster than review capacity. See Measuring Impact.

Characterization test

A test that records what existing code actually does today rather than what it should do, so any later change that alters behavior fails a test. Described by Michael Feathers in Working Effectively with Legacy Code. See AIDLC on Legacy Code.

Circle-back

A controlled backward edge in an agent pipeline: a downstream step that finds a gap in an upstream artifact asks for that step to be redone. Done well, it is human-gated, classified by blast radius, regenerates the whole upstream artifact with a deterministic diff for the reviewer, and is capped by a loop budget so it cannot regress forever.

Compaction

Replacing the older turns of a long session with a summary so work can continue past the context window limit. Harnesses now run it automatically as the window fills. 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 graph

Interconnected data spanning code, work items, documentation, standards, decisions, and conversations, exposed to people and agents through a permissions-aware layer. Where an instruction file gives an agent the rules of one repository, a context graph answers who owns this code, why it exists, and what depends on it.

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 engineering guidance names context rot.

Control plane

The deterministic layer that decides what an agent pipeline does next: which agent runs, when, with what context, and whether a step may advance past its gate. Agents propose; the control plane, usually a server-side state machine, decides.

Curate (phase)

The fifth AIDLC phase: monitoring, incident response, performance work and keeping documentation current after release. Its outputs - runbook entries, post-incident reviews, new rules in the instruction file and new backlog items - feed back into Analyze. See Curate.

Definition of Done

In Scrum, a formal description of the state of the Increment when it meets the required quality measures. For agent-authored work AIDLC adds a named human reviewer, an assigned risk tier, a mutation-score bar, the ticket ID in commits, and updated docs and instruction files. See AIDLC With Scrum and Kanban.

Develop (phase)

The third AIDLC phase: agents implement small slices of the spec under ticket contracts, a human approves each plan before code is written, and every pull request is reviewed at its risk tier. See Develop.

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.

Expand and contract

A safe way to change a schema or interface: add the new version beside the old, migrate readers and writers, then remove the old version in a later release. Also called parallel change. An agent may draft the expand step; the destructive contract step stays human-run.

Explain-the-diff review

A review practice in which the author of an agent-written change walks a reviewer through it and explains why it works; a change the author cannot explain is not ready to merge. See Teams and Skills.

Fail-closed gate

A check that blocks when it cannot decide - an unknown check, a missing artifact, an evaluator error - instead of letting the step through. A gate only counts as enforced when the transition itself refuses and a negative test proves it.

Feature flag

A runtime switch that turns a code path on or off without a deploy. In AIDLC it is the default rollback path for agent-authored changes and the mechanism for staged rollouts - and a flag left in place after the rollout is finished is technical debt.

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.

Hooks

Commands an agent harness runs automatically at defined points - before a tool call, after a file edit, at the end of a session. An instruction file asks the agent to follow a rule; a hook enforces it, which is why rules that must never be broken belong in hooks. See Engineering Practices.

Ideate (phase)

The second AIDLC phase: exploring competing designs, prototyping, and recording the decisions - design notes, ADRs, API contracts - that become the spec an agent executes. See Ideate.

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.

KTLO

Keep the lights on: the maintenance, reliability, dependency, and recurring-fix work that keeps a system running. It routinely loses to new features, which is why governed agent loops on well-defined KTLO work are one of the first places agents add real capacity.

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.

Launch (phase)

The fourth AIDLC phase: testing, pipeline changes, migrations and the staged release, each with a rollback path. AI generates tests and pipeline config; humans decide whether the tests can be trusted and when to ship. See Launch.

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.

Living documentation

Documentation kept current as part of the work rather than after it - updated by agents with each change and reviewed with the diff, so the docs, the instruction file and the code do not drift apart. A Curate-phase responsibility.

LLM-as-judge

Using a model to grade another model's or agent's output against a written rubric, so an eval can score work that has no single correct answer; for an agent it grades the trajectory as well as the result. It is how model-graded rubrics are actually run, and it carries known biases - toward the first answer, toward the longer one, and toward its own family - so it is calibrated against human graders and never used where a deterministic check exists.

MCP (Model Context Protocol)

A standard way for models and agents to connect to tools, data, and systems, developed by Anthropic and now governed as a Linux Foundation project. It replaces brittle one-off integrations with a governed interface to your docs, tickets, databases, and services.

Memory poisoning

Getting false or hostile content into the notes an agent keeps between sessions, so one bad write steers every later run rather than one. It is the risk that arrives with persistent agent memory: an instruction file is reviewed and versioned, while a memory store the agent writes itself usually is not. OWASP's 2026 list for agentic applications treats it as its own category because it unfolds across sessions rather than inside one.

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.

MLOps

The practice of applying DevOps-style automation to the machine learning lifecycle - validating data and models in CI, delivering training pipelines, and monitoring and retraining models in production. LLMOps is the equivalent for applications built on language models. See AIDLC vs the ML Lifecycle.

Model pinning

Fixing the exact model version an agent or pipeline uses, so behavior does not change underneath you, and upgrading only after the new version passes your evals. The model is treated like any other dependency. See Engineering Practices.

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, the shape known as LLM-as-judge.

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.

Open-weight model

A model whose trained weights are published so anyone can run it on their own hardware, under the model's license. It is what makes a self-hosted or air-gapped setup possible. See Choosing a Coding Agent.

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. Agent Orchestration covers the control-plane version.

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.

Productivity paradox

The finding that individual developers produce more with AI while organizational delivery often does not improve, because review, testing and coordination absorb the gain. See The AI Productivity Paradox for the sourced data.

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 variant that arrives through content rather than from the operator is called indirect prompt injection, and it is the entry point for the goal hijack that tops OWASP's 2026 list for agentic applications. 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 with a published specification that most major harnesses 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.

Strangler fig

A modernization pattern in which new components are built alongside a legacy system and functionality moves over one slice at a time until the old system can be retired. Described by Martin Fowler. See AIDLC on Legacy Code.

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.

Systems of record

The tools that hold the authoritative record of work - the tracker, the repository, documentation, the incident tool. In an AI-native SDLC they are where people make decisions and where agents read structured context, and every agent action is written back to them as an audit trail.

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.

Tool poisoning

Hiding instructions in the parts of a tool the model reads and the operator does not - its description, its parameters, its schema - so connecting a server is enough to steer the agent, whether or not the tool is ever called. It is prompt injection moved from the content an agent fetches to the tool catalog it trusts, and OWASP's 2026 list for agentic applications carries it as tool misuse and exploitation. Reviewing a server before you connect it is the control.

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.

Workload identity

An identity issued to a machine workload - a CI job or an agent - instead of a person, usually through short-lived tokens exchanged over OIDC rather than stored secrets. It lets an agent act under its own audited, least-privilege identity instead of a developer's personal token. See Agents in the Pipeline.

Worktree

A git feature that checks out several branches of one repository into separate directories at once, so several agents can work on the same codebase in parallel without overwriting each other's changes.