AI-DLC Phases: Inception, Construction, and Where Humans Gate

The AI-DLC phases break software delivery into three stages, Inception, Construction, and Operations, each one run by AI agents that draft the work and closed by a human who signs off before the next stage begins. The methodology comes from Amazon Web Services, which defines AI-DLC as an AI-first lifecycle that keeps engineers in control through explicit approval points rather than letting an agent run end to end.

That framing matters because the failure mode it prevents is specific. Point an agent at a vague ticket and it will produce requirements, architecture, code, and a deployment plan in minutes, folding in assumptions nobody agreed to along the way. These phases exist to put a named checkpoint between each of those bursts of output, so a person with authority reviews the plan while changing it still costs minutes instead of days.

Key Takeaways

• Three phases, not five stages: AI-DLC compresses the traditional lifecycle into Inception (intent to requirements), Construction (architecture, code, and tests), and Operations (deployment and runtime), as defined in the AWS AI-DLC methodology.
• Humans gate the transitions: Each phase ends at a validation point where the team approves the AI's output before the next phase starts. The gates, not the agents, are what separate AI-DLC from ad-hoc prompting.
• New units of work: AWS replaces the sprint with a "bolt" measured in hours or days, and runs collaborative "mob elaboration" and "mob construction" sessions to resolve ambiguity before agents execute.
• Gates need three things to hold: formal authority to reject, real system context, and a recorded sign-off. Miss any one and the gate becomes a rubber stamp.
• Multi-repo breaks the context condition: In distributed systems no single reviewer sees the whole blast radius, which is where platforms like Enact ground the gates in a cross-repo knowledge graph.

What are the AI-DLC phases?

AI-DLC (the AI-driven development lifecycle, often written AIDLC) organizes work into three phases where AI agents author the artifacts and human engineers approve them at the boundary between phases. Inception turns intent into verified requirements, Construction turns requirements into architecture, code, and tests, and Operations turns an approved build into a deployed, monitored system. Amazon Web Services introduced the model, and the open-source awslabs/aidlc-workflows repository documents the reference prompts and gates.

Two vocabulary changes come with it. AWS replaces the sprint with a bolt, a short iteration measured in hours or days rather than weeks, and replaces the epic with a unit of work, a self-contained slice that carries its own dependencies. The shift is deliberate: when an agent can draft a feature in minutes, a two-week sprint is the wrong unit for planning around it.

AI-DLC sits between two extremes. Fully manual AI-assisted coding keeps a human typing prompts and merging diffs one at a time. Fully autonomous generation hands the whole job to the agent. AI-DLC takes the middle path, the agent drafts a complete plan and asks clarifying questions, and it only implements after a person validates the approach. This is the same principle behind the broader agentic SDLC, applied as a concrete three-phase sequence.

Workflow summary: AI agents drive Inception, Construction, and Operations in sequence, while human approval gates between each phase hold requirements, architecture, and release decisions for sign-off before the next phase begins.

The three AIDLC phases: inception, construction, operations

Mapping the AIDLC inception, construction, operations sequence onto a real team is less about the agent and more about what each gate is responsible for catching. Here is what each phase produces and the decision the human at its gate actually owns.

AI-DLC inception phase: intent to requirements

In the inception phase, the agent consumes raw intent, a product goal, a support theme, or an issue ticket, and drafts structured requirements, user stories, and acceptance criteria. Rather than guessing at missing constraints, a well-run Inception surfaces open questions explicitly, often with a [NEEDS CLARIFICATION] marker, and resolves them in a mob elaboration session where the whole team validates the agent's proposals in real time.

The output is a unit of work with acceptance criteria the team agrees on, not a wall of prose. The gate here asks one question: do these requirements describe the thing we actually want built? Correcting a misunderstood requirement during Inception takes five minutes. Discovering it after Construction means unwinding architecture and code that were faithfully built to the wrong spec. This is why review in an AI-DLC moves upstream, a shift explored in depth in why AI coding agents need collaborative planning.

AI-DLC construction phase: architecture, code, and tests

The construction phase takes the approved requirements as a fixed boundary. The agent proposes a technical design, data models, and API contracts, and after that design is approved it generates the source code and test suites. AWS runs a mob construction session here, the same collaborative pattern as Inception, but focused on architecture and implementation decisions rather than product scope.

Construction is where diff-based review quietly fails. An agent can produce an 800-line change set in minutes, and reading it line by line obscures the decisions that matter, a bypassed authorization check, a duplicated service, a schema change that breaks a downstream consumer. The construction gate is not "does this code compile." It is "is this the right design, and does it stay inside the approved scope." Teams that still want a final diff review should pair it with upstream design approval rather than relying on it alone, as covered in the spec approval workflow for AI coding agents.

A subtle risk lives inside test generation. Tests written by the same model that wrote the business logic tend to encode the model's assumptions rather than the business contract. The human at the Construction gate has to confirm the tests assert real user outcomes, not just that the code does what the code does.

AI-DLC operations phase: deployment and runtime

The operations phase uses the accumulated context from the first two phases to generate infrastructure-as-code (machine-readable definitions of servers, networks, and services), configure deployment pipelines, and set up telemetry and alarms. Because the rationale from Inception and Construction is preserved as structured data, an operational agent can reference the original intent during an incident instead of reverse-engineering what the system was meant to do from logs.

AWS still describes Operations as the least mature of the three phases, so treat vendor claims about fully autonomous operations with care. The release gate remains a human decision: is this safe to ship, and can we trace what we are shipping back to an approved plan.

Where AI-DLC human approval gates sit, and what makes them hold

The agents are interchangeable. Cursor, Claude Code, GitHub Copilot, and Amazon Q all draft plans and write code. What makes a lifecycle an AI-DLC rather than fast vibe coding is the AI-DLC human approval gate between each phase. A gate is only real when three conditions hold at once:

1. Authority: the designated reviewer can reject a flawed proposal, not just comment on it. A gate the agent can route around is not a gate.
2. Context: the reviewer can see the real system, including cross-service dependencies, not just the local diff. Without this, approval is a guess.
3. Evidence: the decision is captured as a durable record of who approved what, against which version, and when.

That third column is the whole argument for the AI-DLC phases. Each skipped gate does not fail loudly. It fails as a plausible-looking artifact that nobody with authority actually agreed to, which is exactly what a product manager is trained to catch when reviewing an AI coding agent's plan. Teams can estimate what catching these errors upstream is worth using the rework ROI calculator.

Why the AI-DLC phases strain in team environments

On a solo project, the three phases run smoothly because one engineer holds the whole system in their head, and their own understanding is the gate. In a team managing distributed microservices, the context condition breaks first.

A product manager can approve an Inception document without knowing an existing internal service already does the job. An engineer can approve a Construction plan that looks correct in their repository while a schema change quietly breaks consumers in three others. Procedurally, the gate was cleared. Architecturally, a production incident was approved. This is the same failure analyzed in why spec-driven development breaks in teams, and it gets worse as repositories multiply, as covered in AI coding agents across multiple repos.

Fixing it means giving the gate the context a single human cannot hold. Platforms like Enact build a unified knowledge graph across connected repositories using tree-sitter parsers (incremental syntax analyzers that map code structure), so a reviewer sees the full blast radius of a change before signing off. The approved plan is then served to Cursor, Claude Code, and Copilot through the Model Context Protocol (MCP), the open standard for feeding context to coding agents, so the agent executes the approved scope rather than re-deriving it.