Desk2Mob

Sign Up

Desk2Mob

Desk2Mob

AI-Driven Development Lifecycle (AI-DLC) — Technical Deep Dive

AI-Driven Development Lifecycle (AI-DLC) — Technical Deep Dive

Source methodology: Amazon Web Services (AWS).

~9 min read

Part 3 of a series — previously: AI-DLC Executive Briefing and AI-DLC Philosophy & Methodology.

Jump to a section

Part 1 covered what AI-DLC is; Part 2 covered why it's shaped the way it is. This article covers the mechanics: which stages actually run and when, what gets written to disk, where a human is pulled into the loop, and what an engineering lead needs settled before running a pilot.

Adaptive workflow structure

The AI-DLC workflow analyzes the user's request, the existing codebase, and the complexity of the change to decide which stages are mandatory and which are conditional. A narrowly scoped bug fix can bypass many design and elaboration stages and proceed through a lightweight plan into implementation; a new feature triggers requirements analysis, architectural design, and detailed testing. The workflow is adaptive by construction, not by exception.

A note on scope: The three-phase table below (Inception → Construction → Operations) reflects the model used in AWS's original 2025 walkthrough and the financial-services adaptation, and is the level of granularity the rest of this article uses for readability. AWS Labs' current open-source implementation (awslabs/aidlc-workflows, v2.x) has since evolved this into five phases and 33 stages — Initialization, Ideation, Inception, Construction, Operation — adding an automatic Initialization pre-phase and an Ideation phase for intent and scope capture ahead of formal requirements work. See "Current construction model" below for what else changed.

Phase Mandatory stages Conditional stages (run only if warranted)
Inception Workspace Detection, Requirements Analysis, Workflow Planning Reverse Engineering (brownfield only), User Stories, Application Design, Units Generation
Construction Code Generation, Build and Test (looped per unit) Functional Design, NFR Requirements, NFR Design, Infrastructure Design
Operations Operations (deployment and monitoring) —

Workspace Detection determines whether the target is a greenfield (new) or brownfield (existing) codebase. In the walkthrough model above it behaves as the first inception-phase gate; in the current implementation it runs as an automatic Initialization-phase stage — a rule-based scan of file extensions, config filenames, and package manifests — with no approval checkpoint of its own and no LLM delegation. In the 2025 walkthrough, brownfield projects are routed through Reverse Engineering before Requirements Analysis so the AI has an accurate model of what already exists, while greenfield projects proceed directly to Requirements Analysis. In the current implementation, workspace classification primarily determines whether Reverse Engineering runs; other intervening stages (such as Ideation or Practices Discovery) depend on the selected scope and execution plan. This single decision still cascades through the rest of the plan the workflow proposes.

Artifacts and traceability

Every AI-DLC run produces a durable, reviewable paper trail rather than a black-box transcript. The artifact layout has changed materially between the 2025 walkthrough and the current open-source implementation, so the two are described separately below.

Artifacts in the 2025 walkthrough

  • On first use, the workflow requests permission to create an aidlc-docs/ folder at the project root — no application code lives there, only generated markdown documentation.
  • Requirements clarification is captured in a requirement-verification-questions.md file, presented in multiple-choice format with a mandatory open-ended "Other" option, which the user answers inline.
  • Once answered without contradiction, the workflow produces requirements.md, then an execution-plan.md that shows which stages will run and which will be skipped and why.
  • Per unit of work, a {unit-name}-code-generation-plan.md provides a checklist the AI works through and marks complete as it goes.
  • A separate audit.md logs every prompt and decision for traceability, and progress state is tracked so a session can be resumed without losing context.

Artifacts in the current implementation

Artifacts now live under an intent record dir, aidlc/spaces/<space>/intents/<YYMMDD>-<label>/ (<space> defaults to default), organized by phase and then by stage rather than in one flat aidlc-docs/ folder:

aidlc/spaces/&lt;space&gt;/intents/&lt;YYMMDD&gt;-&lt;label&gt;/
├── aidlc-state.md               # single source of truth for workflow progress
├── audit/
│   └── &lt;host&gt;-&lt;clone&gt;.md        # per-clone, append-only shard
├── verification/                # phase-boundary check results
├── initialization/               # Phase 0 artifacts
├── ideation/                     # Phase 1 artifacts
├── inception/                    # Phase 2 artifacts
├── construction/{unit-name}/     # Phase 3 artifacts, per unit
└── operation/                    # Phase 4 artifacts
  • The single audit.md file is gone. The audit trail is now an audit/ directory of per-clone shards (<host>-<clone>.md) — each clone appends only to its own shard to avoid git merge conflicts, and readers merge-sort every shard by ISO 8601 timestamp to reconstruct one chronological history.
  • Requirements now live under inception/requirements-analysis/: the document is still requirements.md, but the clarifying-questions file is now requirements-analysis-questions.md (every stage that collects user input produces a co-located {stage-name}-questions.md), not requirement-verification-questions.md.
  • There is no single execution-plan.md anymore. Delivery Planning (stage 2.8) produces bolt-plan.md, team-allocation.md, risk-and-sequencing-rationale.md, and external-dependency-map.md instead — the role execution-plan.md used to play is now split across those.
  • The per-unit code generation plan still exists, now as code-generation-plan.md under construction/{unit-name}/code-generation/.

The financial-services adaptation of AI-DLC extends this into formal requirement traceability: when a test fails, it traces back to the requirement that generated it, and that requirement traces back to the user story it came from — a chain auditors and risk teams can walk end to end.

Human-in-the-loop checkpoints

At the end of every stage in the walkthrough model above, the workflow stops and presents three options: request changes, add or amend items, or approve and continue. This is enforced structurally, not left to convention — the workflow rules instruct the underlying model to ask clarifying questions rather than assume, and to flag any contradiction or ambiguity in the user's answers before it will allow the team to move forward.

The current implementation refines "nothing proceeds without approval" into something more precise: Initialization stages run automatically with no gate, phase-boundary verification is automated, and Construction runs on an approval ladder rather than a gate-per-stage rule — described next. Human approval is required at defined checkpoints and consequential decisions, while routine or already-approved-pattern stages may run automatically or within an explicitly chosen autonomy mode. What doesn't change is the failure path: during Construction, a Bolt execution failure halts the workflow and returns control to the human, regardless of autonomy mode, with options to retry, skip, or abort. The result is a process that looks, from a distance, like it's running itself, but that keeps a recorded human decision at every consequential fork.

Current construction model

The Construction phase is organized around Units — discrete work items produced during Units Generation and sequenced during Delivery Planning — and Bolts, which are passes through the design-through-code-generation stages for one Unit or a small group of tightly dependent Units.

For greenfield-oriented scopes (feature, MVP, enterprise, POC, workshop, infrastructure), the first Bolt is normally a walking skeleton: the smallest gated end-to-end slice that proves the architecture. Incremental scopes — bug fixes, refactors, security patches — skip this ceremony, since an existing application foundation is already in place and the first Bolt runs like any other.

After the first Bolt completes — and, where applicable, its walking-skeleton gate is approved — a one-time prompt asks whether to run the remaining Bolts autonomously or gate each one individually; the choice is recorded in workflow state and governs the rest of Construction. Bolts that share the same prerequisite can run in parallel batches under a single covering approval gate instead of one gate per Bolt.

In every mode, an execution failure halts Construction immediately and hands control back to the human with retry, skip, or abort options — autonomy mode changes how often you're asked to approve, not whether failures get reported.

Worked example: end-to-end run (2025 walkthrough)

AWS's own walkthrough (building a River Crossing Puzzle web app with Amazon Q Developer, published November 2025) illustrates the flow concretely under the three-phase model described above. It predates the current five-phase, Bolt-based Construction model, but the shape it demonstrates — adaptive stage selection, checkpointed approval, generated planning artifacts — still holds.

1. Problem statement. The developer types "Using AI-DLC let's build a web application to solve the river crossing puzzle," which triggers the workflow.

2. Workspace Detection. The workflow detects a greenfield project, creates aidlc-docs/, and generates aidlc-state.md and audit.md.

3. Requirements Analysis. Q Developer asks multiple-choice clarifying questions (puzzle variant, interaction method, persistence, leaderboard) in requirement-verification-questions.md; the developer answers inline and types "Done."

4. Requirements Review. A requirements.md document is generated and presented for approval; because the app is simple, AI recommends skipping the User Stories stage, and the developer agrees.

5. Workflow Planning. An execution-plan.md is generated, skipping Application Design and Units of Work Planning since the scope is a single-file app; the developer approves.

6. Code Generation Planning. An eight-step, checkbox-based plan is generated before any code is written.

7. Code Generation. The plan executes step by step, producing a single index.html with embedded CSS/JS.

8. Build and Test. Build and test documentation is generated (unit, integration, performance, and other layers as relevant), with a summary of readiness for deployment.

Complex applications follow the same pattern but engage more of the conditional stages — the workflow scales its rigor to the problem, not the other way around.

Questions to answer before a pilot

Before running AI-DLC against a real repository, an engineering lead should have answers to:

  • Repository permissions — what write access does the agent have (branch-only, PR-only, direct push)?
  • Artifact retention — for the AI-DLC artifact directory (aidlc-docs/ in the 2025 walkthrough; aidlc/spaces/<space>/intents/.../ in the current implementation), what's committed vs. gitignored? State, audit shards, and stage artifacts are meant to be committed; per-user session cursors and recovery breadcrumbs are not.
  • Approval ownership — who is the human at each gate: the requesting engineer, a tech lead, or a rotating reviewer?
  • Autonomy policy — is the team opting into autonomous Bolts by default during the pilot, or gating every one?
  • Test environment — where may the agent execute build and test commands, and which checks must be repeated independently in CI?
  • Rollback — if a Bolt's output is wrong, is the recovery path a git revert, a skip-and-continue, or a full abort?
  • Success metrics — cycle time, defect rate, review burden — what is actually being measured to judge the pilot?
  • Sensitive source handling — for brownfield runs, what content from Reverse Engineering (business logic, architecture, dependency details) is acceptable to have summarized into checked-in markdown, and who can read it?

This article reflects AWS's AI-DLC documentation as of August 2026, cross-checked against current AWS Labs documentation. AI-DLC is evolving quickly, and specifics like stage counts, file names, and gate locations may change — the AWS Labs docs linked in Sources are the source of record going forward.

Sources

Posted on August 14, 2026 by Desk2Mob in AI-DLC, AI, AWS


All Posts
Desk2Mob