AI-DLC Explained: A Complete Introduction to the AI-Driven Development Life Cycle

AI-DLC, short for AI-Driven Development Life Cycle, is an open software development methodology in which AI coding agents carry out development work under structured human governance. AWS published it as an open-source workflow specification, and it is designed to run with several different coding agents rather than a single vendor's tooling. Because the methodology is still relatively new, detailed, practical explanations of how it actually works are not yet widely available. This article sets out the basics: what AI-DLC is, how its three-phase workflow operates, the vocabulary that comes with it, how it compares to Agile and SAFe, and what organisations typically need to have in place before adopting it.

Where AI-DLC Comes From

AI-DLC is published and maintained by AWS in the public repository awslabs/aidlc-workflows, released under the permissive MIT-0 licence. The maintainers describe it explicitly as a methodology first and a set of convenience tools second — organisations adopt the workflow rules, then choose which coding agent runs underneath them. As of this writing, the latest stable release is v1.0.1, and a version 2.0 is in preview, described by its maintainers as extending the workflow toward more verifiable, self-correcting execution. Background reading beyond the repository itself includes an AWS DevOps blog post introducing the methodology and a separate Method Definition Paper that documents the underlying model in more depth.

The methodology is built to be agent-agnostic. The public documentation lists setup instructions for Kiro, the Amazon Q Developer IDE plugin, Cursor, Cline, Claude Code, GitHub Copilot, and OpenAI Codex, and states that any coding agent supporting project-level rules or steering files can, in principle, be configured to run it. This matters for adoption planning: choosing AI-DLC is not the same decision as choosing a specific AI coding tool, and the two can be evaluated separately.

The Three-Phase Adaptive Workflow

AI-DLC organises work into three phases, each answering a different question.

• Inception: determines what to build and why. It covers requirements analysis and validation, user story creation where relevant, application design, and breaking the work into Units of Work that can be developed in parallel, along with an assessment of risk and complexity.
• Construction: determines how to build it. It covers detailed component design, code generation and implementation, build configuration, testing strategy, and quality assurance and validation.
• Operations: covers deployment automation, monitoring, observability, and production readiness validation. The maintainers note this phase is still maturing relative to Inception and Construction in the current release.

The workflow is described as adaptive because it is designed to execute only the stages that add value for a given piece of work — a small, low-risk change and a complex, high-risk one do not receive identical treatment. This is paired with a question-driven design: rather than asking clarifying questions in open chat, AI-DLC presents structured, multiple-choice questions in files, and a human reviews and approves the resulting plan before each phase proceeds. The stated intent is to keep a human decision point at each stage rather than allowing the workflow to run end-to-end unsupervised.

AI-DLC also supports an extension system, allowing organisations to layer additional rules — for example around security, testing, or resiliency — on top of the core workflow. Each extension consists of a rules file and a matching opt-in file; opt-in prompts are presented to the user during Requirements Analysis, and once an extension is enabled, its rules become blocking constraints that are checked before a stage can proceed. The repository ships with baseline extensions for security, property-based testing, and resiliency as illustrative starting points, and documents how an organisation can define its own.

Core Terminology: Bolts, Units of Work, and Mob Rituals

AI-DLC introduces vocabulary that does not map directly onto Agile or SAFe terms, which is a common source of confusion for teams encountering it for the first time.

• Unit of Work: a discrete piece of work identified during Inception, scoped so that it can be developed independently and, where possible, in parallel with other Units of Work.
• Bolt: AI-DLC's short, AI-executed development cycle. It replaces the traditional Agile sprint as the basic unit of delivery cadence.
• Mob Elaboration: a real-time, synchronous session in which the team reviews and validates an AI-generated plan or design before construction begins, rather than relying solely on asynchronous backlog review.
• Mob Construction: a real-time, synchronous session in which the team reviews and validates AI-generated code or implementation decisions as they are produced, rather than through a separate, after-the-fact code review step.

Underlying these terms is a shift in role definition. Product owners, architects, and developers move from being primary producers of requirements or code to being validators and context-curators — reviewing and steering AI-generated output rather than authoring most of it directly. This role shift is one of the more significant organisational changes teams report when adopting AI-DLC, independent of which coding agent is used underneath it.

How AI-DLC Differs From Agile and SAFe

AI-DLC is not a rebranding of Agile or SAFe with AI added on top; several structural elements change.

• Cadence unit: the sprint is replaced by the Bolt, a shorter, AI-executed cycle.
• Review timing: after-the-fact code review and backlog grooming are replaced by live validation through Mob Elaboration and Mob Construction.
• Primary skill emphasis: shifts from authorship toward verification, orchestration, and context curation.
• Governance gates: rather than inheriting review norms from existing ceremonies, verification gate points need to be explicitly defined for the workflow to function as intended.

Because of these differences, readiness criteria built for a standard Agile or SAFe rollout do not transfer directly to an AI-DLC adoption. A team can be highly mature in Agile practice and still lack the specific technical and governance foundations AI-DLC assumes — context infrastructure that persists across sessions, for instance, or explicitly defined verification gates rather than implicit review norms.

What Organisations Typically Need Before Running a Pilot

Because AI-DLC compresses the loop between decision and execution, certain foundational elements tend to matter more here than in a conventional SDLC rollout. Based on the criteria organisations most commonly need to establish before a pilot, four areas recur:

• Context infrastructure — a mechanism, typically repo-based, so that requirements, decisions, and code state carry forward across sessions rather than being lost between them.
• Explicitly defined verification gates — points in the workflow where human review is required, agreed in advance rather than left to individual discretion.
• Codebase suitability — a target codebase that is reasonably well-documented and bounded, without significant undocumented, tribal-knowledge dependencies.
• A named risk register — documented ownership of AI-DLC-specific risks such as hallucinated architecture decisions, context drift across sessions, or over-reliance on AI-generated test coverage.

None of these are visible in a short demonstration of the workflow. They tend to surface once a pilot has been running for several weeks, which is why organisations evaluating AI-DLC increasingly structure this evaluation as a formal step before committing a team or budget, rather than discovering the gaps mid-pilot.

Structuring the Readiness Question

A readiness assessment, in this context, is simply a structured way of evaluating the areas above before deciding whether, and how, to proceed with adoption. Rather than a single yes-or-no judgement, a well-structured assessment scores an organisation across several independent dimensions, since strength in one area does not offset a gap in another — an organisation can have strong executive sponsorship and budget while still lacking the technical guardrails a pilot depends on.

One example of this structure, used in Viksya's own AI-DLC Adoption Readiness Assessment, scores an organisation across five dimensions:

1. Strategic & Executive Readiness: whether a named executive sponsor, a defined portfolio segmentation, agreed success metrics, committed budget, and a decided tool or harness strategy are in place.
2. Organisational & Cultural Readiness: whether roles, ceremonies, change management, and training are prepared for the shift from producer to validator and context-curator.
3. Technical & Platform Readiness: whether context infrastructure, tooling, codebase suitability, CI/CD, and security guardrails are in place to receive AI-generated work safely.
4. Governance & Risk Readiness: whether decision audit trails, verification gates, process-atrophy monitoring, and a named risk register exist.
5. Delivery & Pilot Readiness: whether a bounded pilot is actually scoped, including the use case, team, baseline metrics, rollback plan, and review cadence.

Each criterion is typically scored on a five-point scale, moving from Not Started, through Awareness Only and In Progress, to Established and Leading Practice. The overall score is then banded — commonly red below a 2.5 average, amber in the emerging range, and green from 4.0 upward — and combined with the Technical and Governance scores specifically to produce a recommended starting point: whether foundational work is needed first, whether a pilot is appropriate but should stay within a bounded, greenfield scope, or whether the organisation is positioned to scale adoption more broadly. Some assessments also adjust dimension weighting automatically depending on whether the target codebase is greenfield, brownfield, or part of a regulated core system, since brownfield and regulated environments generally demand more of the technical and governance foundation before adoption proceeds.

Where Viksya's AI-DLC Tools Fit

This introduction covers the definitional layer: what AI-DLC is, how the workflow is structured, and what a readiness assessment measures before adoption begins. Once an organisation has cleared that initial evaluation, a further set of practical questions follows — how to engineer persistent context so agents don't lose state across sessions, how to benchmark maturity once a pilot is already underway, and how a team becomes fluent in the Bolt and Mob rhythm without rebuilding the process from scratch on every engagement. Viksya's AI-DLC product line is organised around that progression, from a free Dictionary of Terms for teams still getting oriented in the vocabulary, through the Adoption Readiness Assessment covered here, into context engineering, maturity benchmarking, and structured starter kits for teams already past the pilot stage. A related post, Map the Transition Before You Announce It, covers how to map existing Scrum, SAFe and Waterfall responsibilities to their AI-DLC equivalents.

Frequently Asked Questions

What is AI-DLC?

AI-DLC (AI-Driven Development Life Cycle) is an open methodology, published by AWS, in which AI coding agents execute development work — across Inception, Construction, and Operations phases — under structured human governance, using short, AI-executed cycles called Bolts in place of traditional sprints.

Is AI-DLC a specific product or tool?

No. AI-DLC is distributed as workflow rules and steering files rather than installable software, and it is designed to run on multiple coding agents, including Kiro, Amazon Q Developer, Cursor, Cline, Claude Code, GitHub Copilot, and OpenAI Codex.

What is a Bolt in AI-DLC?

A Bolt is AI-DLC's short, AI-executed development cycle, replacing the sprint as the basic cadence unit. Bolts are paired with real-time validation rituals — Mob Elaboration and Mob Construction — rather than asynchronous backlog grooming and code review.

How is AI-DLC different from Agile or SAFe?

AI-DLC changes the cadence unit from sprint to Bolt, moves code review from after-the-fact to live validation during Mob sessions, shifts the primary skill emphasis from authorship to verification and context curation, and requires verification gates to be explicitly defined rather than inherited from existing ceremonies.

What should an organisation evaluate before starting an AI-DLC pilot?

Commonly cited prerequisites include persistent context infrastructure, explicitly defined verification gates, a suitably documented and bounded target codebase, and a named risk register covering AI-DLC-specific risks. A structured readiness assessment is one way to evaluate these systematically before committing budget or a team.

Where can I find a structured AI-DLC readiness assessment?

The AI-DLC Adoption Readiness Assessment scores 25 criteria across five dimensions and produces a Readiness Score plus a recommended Adoption Path — available at viksya.com/ai-dlc-readiness-assessment.