Desk2Mob

Sign Up

Desk2Mob

Desk2Mob

AI-Driven Development Lifecycle (AI-DLC) — Philosophy & Methodology

AI-Driven Development Lifecycle (AI-DLC) — Philosophy & Methodology

Source methodology: Amazon Web Services (AWS).

~13 min read

Part 2 of a series — previously: AI-DLC Executive Briefing. Coming up next: AI-DLC Technical Deep Dive.

Jump to a section

AI-DLC's starting premise is that retrofitting AI as an assistant onto an unchanged, human-driven SDLC caps what AI can deliver. AWS argues that traditional methods were "designed for human-driven, long-running processes," built around iteration cycles of weeks or months — a cadence that carries rituals (standups, retrospectives, story-point estimation) whose relevance is worth re-examining once AI compresses cycles to hours or days. AWS's answer is to redesign the lifecycle around AI as a central collaborator rather than a tool bolted onto the side of it.

A note on terminology in this article: AWS has published two things under the AI-DLC name — the original AI-DLC Method Definition Paper by Raja SP (ten principles, three phases, a small set of artifacts), and a newer, more elaborate AWS Labs implementation (five phases, 32 stages). This article calls the first the foundational method and the second the current implementation, and flags which one a given claim is about. The implementation's stages and boundaries can change independently of the foundational principles, so treat specifics like stage counts as a snapshot, not a permanent spec. Where this article groups, emphasizes, or frames the source material in ways AWS itself doesn't — which principles matter most, or reading two approaches as endpoints on a spectrum — that's marked inline as this article's own reading, not an AWS claim.

Two organizing dimensions

AI-DLC rests on two dimensions that operate together.

AI-Powered Execution with Human Oversight — AI systematically creates detailed work plans, actively seeks clarification, and defers consequential decisions to a human. People contribute organizational context, judgment and accountability that AI cannot reliably infer.

Dynamic Team Collaboration — because AI absorbs the routine drafting work, the method aims to create more room for the team to work together. In practice, that means focused, real-time Mob sessions where product, engineering, and QA join as a decision needs them, not continuous participation by the entire team — replacing the sequential, handoff-heavy pattern of traditional SDLC.

The core mental model (foundational method)

The paper describes the same loop repeating at every level of planning — from the Level 1 Plan (AI's first-pass proposal for how to sequence the whole piece of work) down through progressively finer sub-tasks:

Human provides a task or intent
  → AI creates a plan and seeks clarification
  → Human provides that clarification
  → AI refines the plan
  → Human approves the plan
  → AI executes it
  → Human verifies the outcome
  → cycle repeats for the next unit of work

The paper describes human oversight at each step as functioning like a "loss function" — catching and correcting errors before they snowball downstream. In the current implementation this doesn't mean every action is separately gated; see Bounded autonomy below.

Three phases (foundational) vs. five phases / 32 stages (current implementation)

The foundational AI-DLC method defines three core delivery phases:

Phase What happens Collaborative ritual
Inception AI turns intent into user stories, NFRs (non-functional requirements — constraints like performance, security, and scalability rather than features), risk descriptions, and Units of Work. Mob Elaboration — relevant cross-functional participants validate AI's questions and proposals together; AWS's design ambition is hours rather than weeks.
Construction Using validated context from Inception, AI proposes domain design, logical design, code, and tests. Mob Construction — relevant cross-functional participants clarify technical and architectural decisions in real time as code is generated.
Operations AI analyzes telemetry, proposes remediation via runbooks, and executes approved actions. Team oversight — developers validate and approve before execution; outcomes feed back into future Inception cycles.

The current, open-sourced AWS Labs workflow (awslabs/aidlc-workflows) makes the surrounding execution explicit through a catalog of five phases and 32 stages: Initialization (3 stages — bootstraps the workspace), Ideation (7 stages — validates the initiative), Inception (8 stages), Construction (7 stages), and Operation (7 stages).

This is a catalog, not a fixed sequence every project runs in full. Several stages are conditional on scope and project type, and for scopes like mvp, poc, bugfix, and refactor, the entire Operation phase may be skipped.

Initialization automatically proceeds into Ideation with no gate. Automated verification gates apply at the Ideation-to-Inception, Inception-to-Construction, and Construction-to-Operation transitions, checking that required artifacts exist and traceability links are intact before the next phase starts. A failed check doesn't hard-block: the conductor reports the issues and lets the operator choose to go back and fix them or proceed anyway. These gates catch obvious gaps and support workflow integrity. They aren't a compliance certification by themselves.

All context — plans, requirements, design artifacts — is designed to persist and stay linked for backward/forward traceability, per the paper. How well that actually holds up depends on the harness (the tooling that orchestrates AI's plan-execute-verify loop and enforces its gates — e.g., the AWS Labs workflow), repository conventions, and organizational controls a team puts in place. It isn't automatic just from adopting AI-DLC.

A worked example: intent to production

The paper walks a single scenario through all three phases. It's worth following end to end rather than staying at the level of definitions.

A Product Owner states the intent: "Develop a recommendation engine for cross-selling products." AI recognizes this as new-application work and proposes a Level 1 Plan.

Inception. AI asks clarifying questions (who are the primary users, what business outcome should this achieve), then elaborates the intent into user stories, NFRs, and risk descriptions for the team to validate. It composes the stories into Units: User Data Collection, Recommendation Algorithm Selection, and API Integration. Reviewing the output, the Product Owner catches a gap AI didn't flag: User Data Collection is missing privacy-compliance detail. They add GDPR-specific requirements before the team moves on.

Construction. A developer picks up the Recommendation Algorithm Unit. AI models the domain: Product, Customer, and Purchase History as entities. The developer flags an edge case AI's first pass missed — how to handle a new customer with no purchase history. AI then proposes a logical design (event-driven, AWS Lambda) to meet the scalability NFR; the developer accepts Lambda but overrides the storage choice to DynamoDB for faster queries. AI generates the code and tests against that decision, and the developer reviews both before sign-off.

Operations. AI packages the Unit into a Deployment Unit; the developer approves the configuration and initiates rollout. Once live, AI watches telemetry, catches a latency spike during peak traffic, and proposes a specific fix: increase DynamoDB throughput, or rebalance API Gateway traffic, rather than just raising an alert. The developer validates the recommendation, approves the mitigation, and monitors the outcome.

Nothing here required AI to act without a human decision at the point where judgment mattered. Nothing required the human to draft the user stories, model the domain, or write the code either. That division of labor is the practical shape of the two organizing dimensions described above.

Bounded autonomy, not uniform gating

The current implementation doesn't gate every step individually, even though the foundational method emphasizes oversight at each one.

In the Construction phase, the first Bolt on a greenfield scope is a walking skeleton: a minimal, end-to-end slice built solo and gated so the user approves it before the remaining Bolts run. Incremental scopes (bugfix, refactor, security-patch) skip that ceremony, since there's nothing to bootstrap on an existing codebase; their first Bolt runs like any other.

After Bolt 1 ships (whether it was a gated walking skeleton or a regular first Bolt), a one-time ladder prompt asks how any remaining Bolts should run: continue autonomously, or gate every Bolt individually. Whichever mode is chosen, a failure always halts execution and returns control to the human.

In practice, this loop pairs AI-led planning and execution with human validation at consequential decisions and configured gates. Routine, verifiable actions may execute autonomously within boundaries a human has explicitly approved. Human attention stays concentrated on ambiguous, consequential, or insufficiently verifiable decisions.

Units and Bolts: not the same kind of naming choice

It's tempting to describe Units of Work and Bolts as Epics and Sprints with new names, but the paper is more specific than that:

  • Unit — "a cohesive, self-contained work element derived from an Intent, specifically designed to deliver measurable value." The paper describes it as analogous to either a Subdomain in Domain-Driven Design or an Epic in Scrum, not as a direct substitute for either one. Units are meant to be loosely coupled, enabling independent, parallel development.
  • Bolt — "the smallest iteration in AI-DLC, designed for the rapid implementation of a Unit or a set of tasks within a Unit," described as analogous to a Sprint, but with build-validation cycles measured in hours or days rather than weeks. A Unit can span one or more Bolts, run in parallel or sequentially.

Bolt/Sprint is the closer case to an intentional rename: Principle 7 ("Facilitate Transition Through Familiarity") states outright that "AI-DLC rebrands Sprints as Bolts" to preserve associative learning for practitioners while signaling the change in cadence. Units, by contrast, are framed as a distinct compositional concept that happens to resemble both Epics and DDD Subdomains — not a straight swap for either.

Guiding principles

The paper sets out ten principles that shape AI-DLC's phases, roles, artifacts, and rituals. Four of them (this article's own emphasis) do the most work in explaining how AI-DLC actually behaves day to day; the full list is in the reference table below.

Reverse the Conversation Direction (Principle 2) is why AI drafts first and humans approve, rather than the other way around — the mechanism behind "Two organizing dimensions" above.

Align with AI Capability (Principle 4) is the honesty check built into the method: current AI isn't assumed reliable enough to run unsupervised, the same reasoning used against ungoverned autonomy later in this article.

Minimise Stages, Maximise Flow (Principle 9) is what keeps human checkpoints from multiplying — enough oversight to catch mistakes early, not so much that every step needs a meeting.

No Hard-Wired, Opinionated SDLC Workflows (Principle 10) is worth walking through in full, since the other three lean on it:

"AI-DLC avoids prescribing opinionated workflows for different development pathways (such as new system development, refactoring, defect fixes, or microservice scaling). Instead, it adopts a truly AI-First approach where AI recommends the Level 1 Plan based on the given pathway intention."

— AI-DLC Method Definition Paper

It addresses three recurring challenges identified by AWS across teams adopting agentic tools:

  • One-size-fits-all workflows. Forcing a one-line defect fix through the same requirements-and-design ceremony as a new microservice wastes time and produces artifacts nobody needed.
  • Inflexible depth within a stage. Even adaptive workflows can still over-engineer a stage — a utility function doesn't need full domain-driven design just because the workflow includes a design stage.
  • Tooling that quietly erodes human oversight. As automation absorbs more of the SDLC, teams can drift into passively accepting whatever AI proposes — AWS calls this process atrophy.

AI-DLC handles all three the same way: AI evaluates the request, the codebase, and its complexity, and adapts both which stages run and how deep each stage goes — while a human-in-the-loop checkpoint at consequential decisions keeps final judgment with the team, not the model.

The remaining six principles round out the method. For reference, here are all ten:

# Principle Core idea
1 Reimagine Rather Than Retrofit Redesign from first principles instead of bolting AI onto Agile/SDLC rituals built for week/month-long cycles.
2 Reverse the Conversation Direction Covered in the discussion above.
3 Integration of Design Techniques into the Core Design techniques (e.g., DDD) are built into the method itself, not left for each team to choose independently.
4 Align with AI Capability Covered in the discussion above.
5 Cater to Building Complex Systems Scoped for systems with real architectural complexity and trade-offs, not simple apps better served by low-code tools.
6 Retain What Enhances Human Symbiosis Keeps artifacts like user stories and risk registers that anchor human validation and risk mitigation.
7 Facilitate Transition Through Familiarity New terms (Bolt, Unit) preserve relationships to familiar Agile concepts. AWS's design goal is that an existing practitioner should be able to orient and start practicing it in a single day — a stated aspiration in the paper, not a demonstrated result.
8 Streamline Responsibilities for Efficiency AI absorbs routine task decomposition, letting developers cross traditional specialization silos; Product Owner/developer accountability stays intact.
9 Minimise Stages, Maximise Flow Covered in the discussion above.
10 No Hard-Wired, Opinionated SDLC Workflows Covered in the discussion above.

Two operating-model endpoints, and where AI-DLC sits between them

This article treats AI-assisted development and ungoverned autonomy as endpoints on a spectrum, with AI-DLC positioned between them (this article's own framing). What AWS does say directly is that "both these approaches have produced suboptimal results in terms of velocity and software quality that AI-DLC aims to address."

Fully autonomous AI-managed development lets AI run the process without human gates. The paper's own Principle 4 grounds the concern here: current AI is "advancing but not yet reliable in autonomously translating high-level intentions into executable code or independently operating without human oversight, while also ensuring interpretability and safety." Ungoverned autonomy may be a poor fit wherever reliability, traceability, or regulatory accountability need to be demonstrable. That's a real constraint in regulated industries, but it's a claim about current AI capability and audit requirements — not a verdict that autonomy is inherently unworkable.

AI-assisted development applies AI to selected tasks such as documentation, code completion, and testing. It's more easily governed and improves those specific tasks, but leaves lifecycle-level coordination — planning, sequencing, cross-team handoffs — largely human-led, which is where AWS argues most of AI's potential in the SDLC actually sits.

In practice, this puts AI-DLC between the two: AI orchestrates the development process end to end, proposing plans and, within approved boundaries, executing routine work; humans retain oversight, decision-making authority, and accountability for consequential and production decisions. In Operations specifically, this means AI can prepare deployment artifacts and propose remediation actions, but the paper is explicit that developers approve the deployment configuration and initiate rollout — AI does not unilaterally push to production.

Summary

AI-DLC's core claim is narrower than "AI runs the SDLC": it's that planning and execution can be handed to AI at every level of granularity as long as humans stay the approval authority at consequential decisions. This pairing is intended to make shorter iteration cycles possible without giving up human judgment and accountability.

What's most different about AI-DLC, compared to just pointing an AI assistant at an existing Agile process, is what changes for the human. It's not less involvement — it's a different kind: less time producing every artifact themselves, more time setting intent, supplying context, challenging AI-generated work, making consequential decisions, and remaining accountable for the outcome. That's a different way to spend a workday, not just a faster one.

For a team weighing this, the practical next step isn't a full rollout. It's a bounded pilot: one real use case, a named decision-maker, explicit human checkpoints (as in the walking-skeleton Bolt and ladder prompt above), and measurable baselines for lead time, quality, and rework before deciding whether to expand AI's authority.

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

Sources

Posted on August 06, 2026 by Amit Pandya in AI-DLC, AWS, AI


All Posts
Desk2Mob