The AI-Driven Development Lifecycle: Terms

Adversarial review

Review by a separate agent with a fresh context, which sees only the diff and the criteria — not the reasoning that produced the change.

Why it matters for testing: The highest-value quality use of subagents. Budget for false positives: a reviewer prompted to find gaps will usually report some even when the work is sound, and chasing every finding leads to over-engineering.

Agentic coding

A shift from autocomplete to autonomous task execution: the agent takes a high-level goal, breaks it into steps, executes them independently and adjusts based on feedback from your environment.

Why it matters for testing: An agent that runs your build and tests treats a green suite as its stopping condition. Weak tests now actively license bad code rather than merely failing to catch it.

Agentic engineering

Karpathy's successor term to vibe coding: "Vibe coding raises the floor. Agentic engineering is about extrapolating the ceiling", with the explicit rider that you remain responsible for your software.

Why it matters for testing: The clearest statement from the originator of "vibe coding" that accountability for defects does not transfer to the tool.

AGENTS.md

A conventional file — "a README for agents" — giving build steps, testing procedures and code conventions in a predictable place. Now stewarded under the Linux Foundation.

Why it matters for testing: This is where you tell agents how to run your tests, so a stale AGENTS.md silently means agents stop verifying their own work.

Usage is contested. Explicitly a convention rather than a formal specification, with no required fields, so conformance cannot be validated.

AI code review

Automated review of a pull request by a model, sometimes gathering whole-project context rather than reading only the diff.

Why it matters for testing: Useful as an extra pass, not as the gate. It shares the author's blind spots when it shares the author's context.

Usage is contested. No primary definition of "agentic code review"; the "does it investigate the repo or only read the diff" threshold is a vendor differentiator with no agreed line.

AI development lifecycle

also: ADLC, AIDLC

A colliding acronym. Some writers use it for the lifecycle of building AI and ML systems — data, model, deployment, monitoring — which is the MLOps-adjacent meaning, not AWS's AI-DLC.

Why it matters for testing: A test strategy written against the wrong sense will be aimed at model drift instead of generated-code defects. Always disambiguate which one is meant.

Usage is contested. No authoritative owner. The acronym genuinely denotes two different things and nobody has arbitrated it.

AI pair programming

The original framing for inline code completion, described with a human collaboration metaphor.

Why it matters for testing: The analogy borrows pair programming's implied peer review, which completion tools do not provide. Teams that counted it as a review step quietly lost one.

Usage is contested. Marketing framing rather than a technical term, and largely retired as products moved to agents.

AI-DLC

also: AI-Driven Development Life Cycle

A software development methodology that puts an AI agent in the driver's seat across the lifecycle — proposing plans, asking clarifying questions, generating artifacts — with people acting as validators and decision-makers rather than primary authors.

Why it matters for testing: It relocates quality from a downstream stage to continuous validation inside every phase, so gates, evidence and test strategy have to be defined per phase rather than per release.

Usage is contested. It is an AWS coinage (July 2025), not a standard. No standards body has adopted it, AWS spells the expansion three different ways, and Gartner's vendor-neutral term for the same shift is "AI-native software engineering".

AI-DLC phases

The methodology describes three: Inception (business intent to requirements and units of work), Construction (architecture, domain models, code and tests) and Operations (infrastructure, deployment, incidents). Each phase enriches the context the next one consumes.

Why it matters for testing: Test design is specified in Inception and executed in Construction — so a defect in Inception's requirements propagates into the generated tests as well as the generated code, and the tests will not catch it.

Usage is contested. The open-source implementation ships five phases and 33 stages, adding Initialization and Ideation. "The AI-DLC phases" is ambiguous unless you say which.

AI-native software engineering

Gartner's term for practices and principles optimized for using AI-based tools to develop and deliver software. It appears on Gartner's 2026 Hype Cycles.

Why it matters for testing: This is the vendor-neutral label likely to appear in analyst-driven procurement and board decks, where "AI-DLC" will not.

Audit trail (agent-generated work)

An append-only event log recording what the agent did, which artifacts it produced, and which human approved what — intended to give end-to-end traceability from business intent to production code.

Why it matters for testing: In regulated environments this substitutes for a human-authored change record, and it is the only way to answer "which person approved this generated code, against which plan?"

Bolt

AI-DLC's replacement for the sprint: a delivery cycle measured in hours or days rather than weeks, covering one or more dependency-linked units of work.

Why it matters for testing: Hour-scale cycles break any QA process that assumes a multi-day regression window. Verification has to be automated and run per unit, not per sprint.

Code duplication drift

The observed rise in copy-pasted code and fall in refactoring associated with AI-assisted development.

Why it matters for testing: Analysis of 211 million changed lines found copy-pasted code rose from 8.3% to 12.3% of changed lines while lines associated with refactoring fell from 25% to under 10%. Maintainability is the quality dimension most at risk, and it is invisible to a pass rate.

Coding agent

also: cloud agent, background agent

An agent that takes a task — often an assigned issue — works independently in an ephemeral environment, pushes commits to a draft pull request and requests human review.

Why it matters for testing: Review load moves from authoring time to pull-request time in bulk. The draft-PR plus required-review boundary is the actual quality gate, not the agent's own confidence.

Usage is contested. The category name is churning — vendors have renamed "coding agent" to "cloud agent" and "background agents" to "cloud agents". "Prompt-to-PR" and "issue-to-PR" are not terms of art.

Constitution

A project-level file establishing non-negotiable principles for code quality, testing and maintainability, which subsequent specs and plans must respect.

Why it matters for testing: The closest thing in current tooling to encoding a definition of done or a coding standard somewhere the agent will actually read it.

Construction verification command

A single project-level check, recorded once with an explicit human authorization receipt bound by hash to the exact command text, and reused at every checkpoint. Changing the command requires a fresh human receipt.

Why it matters for testing: The most rigorous quality-gate mechanism in any framework surveyed. It makes "the agent ran the tests" attributable to a human-approved command, closing the obvious cheat of an agent choosing a weaker check at verification time.

Delivery stability

In DORA's model, the reliability half of software delivery performance — change failure rate and failed deployment recovery time — as against throughput.

Why it matters for testing: DORA's 2025 research found AI adoption has a positive relationship with throughput and a negative relationship with delivery stability. If you measure only speed, you will not see the cost.

Guardrail

A control on what an agent may do or say.

Why it matters for testing: The most overloaded word in the field. It denotes at least three unrelated things: content filtering of model input and output, capability and filesystem permission restriction, and CI quality gates. Vendors use it for whichever they sell — ask which one is meant before accepting a claim.

Usage is contested. Three unrelated senses in common vendor use.

LLMOps

A specialization of MLOps for applications built on pretrained language models, adding prompt and configuration versioning, output-quality evaluation, retrieval pipeline management and cost control.

Why it matters for testing: If your product contains a model you need LLMOps evals. If your product is merely built with one, you need AI-DLC-style code verification. Many teams buy the wrong one.

MLOps

Managing the machine-learning lifecycle — data, features, training, evaluation, deployment, monitoring — by applying DevOps discipline to models.

Why it matters for testing: Do not conflate it with AI-DLC. MLOps gates are about data and model metrics; AI-DLC gates are about generated application code.

Mob Elaboration

An AI-DLC ritual where the whole cross-functional team answers the AI's generated clarifying questions live, validating requirements and units of work before the workflow advances.

Why it matters for testing: The only point in the methodology where a tester can challenge acceptance criteria before they are frozen into generated code and generated tests. Skip it and the ambiguity is baked in.

Perceived versus actual productivity

The gap between how much faster people believe AI made them and how much faster they measurably were.

Why it matters for testing: A randomized trial of experienced open-source developers found they took 19% longer with AI tools while believing they had been 24% faster. Self-reported productivity is not evidence — which is the whole argument for measuring outcomes.

Plan mode

Two different things share this name. In agent architecture, plan-and-execute is a topology. In some coding tools, plan mode is a permission mode: the agent may read and explore but edits stay blocked until you approve the plan.

Why it matters for testing: Only the second is an enforceable gate. A "planning agent" that merely writes a plan first gives you no guarantee that it stopped.

Usage is contested. Control-flow topology and permission enforcement are routinely described with the same words.

SDLC

also: software life cycle processes

The classical framework of software life cycle processes — acquisition, supply, development, operation, maintenance, disposal — standardized as ISO/IEC/IEEE 12207.

Why it matters for testing: The only genuinely standardized baseline in this area. When a vendor says "AI-DLC replaces the SDLC", this is what you should hold the claim against.

Sensor

In AI-DLC, a deterministic check — a linter, a type-check — that fires automatically on matching edits or at an approval gate, recording an audit row. Blocking findings require correction or an explicit audited override.

Why it matters for testing: The deterministic/probabilistic split is the useful mental model: sensors are the part of agent quality control you can actually rely on, and the audited override trail is what makes exceptions reviewable.

Spec artifacts

Named files that carry requirements into agent execution — typically a requirements file, a design file and a task list, sometimes with a traceability record alongside.

Why it matters for testing: These are your new requirements-traceability artifacts, and they live in the repo — so coverage can be traced to a version-controlled file rather than a ticket.

Spec-driven development

also: SDD, spec-first development

Workflows that begin with a structured functional specification, decomposed into a plan and tasks that agents implement against. One framing calls the spec "a contract for how your code should behave".

Why it matters for testing: The spec becomes the de facto requirements baseline your tests trace to — so spec review quality now determines test quality.

Usage is contested. Genuinely contested, and documented as such by Thoughtworks. The real split: is the spec a throwaway scaffold for one feature, or a permanent replacement for source code? Different vendors mean different things.

Test strategy level

AI-DLC makes test volume an explicit setting: Minimal (roughly one test per requirement), Standard (per component, weighted toward unit tests), Comprehensive (adding end-to-end, performance and security).

Why it matters for testing: A rare case of a framework making test volume a configurable, auditable decision rather than an emergent property — and it means "AI-DLC generated tests" tells you nothing until you know which level was set.

Unit of Work

AI-DLC's primary decomposition unit, replacing the epic or story: an independently implementable slice, listed with its dependencies so units form a graph that determines what can run in parallel.

Why it matters for testing: The unit, not the pull request, is the atom that gets verified and approved — so coverage and traceability are tracked against the unit graph.

Verification gate

In AI-DLC, checks at phase boundaries that run automated traceability validation to catch missing links, orphaned artifacts or inconsistencies before later stages build on them.

Why it matters for testing: These are traceability gates, not test gates. They verify that requirements, units and artifacts still link up — which is the failure mode agent-generated documentation actually has.

Vibe coding

Coined by Andrej Karpathy in February 2025 — "fully give in to the vibes… and forget that the code even exists". The defining behavior in the original is accepting diffs without reading them.

Why it matters for testing: The dictionary definition that followed is much broader — any AI-assisted coding — and the two have opposite risk implications. Insist on the behavioral definition when assessing risk.

Usage is contested. Contested by drift. Collins made it Word of the Year 2025 with the broad meaning, which is not the coiner's.

Walking skeleton

An older agile term reused by AI-DLC: the smallest working integrated slice, planned as the first unit, which must pass an end-to-end verification command and receive human approval before any later unit begins.

Why it matters for testing: The answer to agents generating large volumes of unintegrated code — nothing proceeds until one slice demonstrably runs end to end.