Desk2Mob

Sign Up

Desk2Mob

Desk2Mob

AI-Driven Development Lifecycle (AI-DLC) — Executive Briefing

AI-Driven Development Lifecycle (AI-DLC) — Executive Briefing

Source methodology: Amazon Web Services (AWS).

~8 min read

Part 1 of a series — coming up next: AI-DLC Philosophy & Methodology and AI-DLC Technical Deep Dive.

Jump to a section

What it is, in one paragraph

AI-Driven Development Lifecycle (AI-DLC) is AWS's methodology for building software: AI agents generate and refine plans, requirements, designs, code, tests, and infrastructure across the lifecycle, while humans retain accountability and decision authority at critical decisions and configured gates. AI-DLC itself is a methodology, not a product.

AWS Labs' open-source, multi-harness implementation, awslabs/aidlc-workflows, renders that methodology as skills, agents, and rules that run natively across several AI coding tools — including Kiro, Claude Code, Codex CLI, and opencode — rather than being tied to one tool.

Amazon Q Developer IDE plugins and paid subscriptions reach end of support on April 30, 2027; AWS recommends Kiro as the successor path for IDE users. Other Q Developer experiences — the AWS Management Console and first-party AWS integrations such as the AWS Console Mobile App and Slack/Microsoft Teams — are not part of that sunset. AI-DLC itself remains tool-independent and multi-harness — Kiro is one recommended path, not a requirement.

AWS frames AI-DLC as the deliberate middle path between two approaches that have each underperformed: AI-assisted development, where AI supports selected tasks within a largely human-led lifecycle — easier to govern, but capturing only a fraction of AI's potential; and unbounded autonomy, where AI runs the process without adequate oversight — fast, but can be unreliable and difficult to explain, and creating unacceptable risk for many regulated workloads.

AI-DLC lets AI orchestrate the process end to end while humans keep decision-making authority and accountability.

How AI-DLC moves work from intent to operations

Simplified conceptual loop — see the caveat below for how this maps to AWS's actual implementation.

AI-DLC turns intent into reviewable units and short bolts, with human validation at critical decisions and configured gates:

Intent
  → AI plans and clarifies
  → Inception (Mob Elaboration)
  → Units of work
  → Construction (Mob Construction)
  → Bolts — built and verified
  → Operations and learning
  → feeds the next Intent

Work starts as an intent — a plain-language description of what someone wants built or fixed. AI drafts a plan against that intent and asks clarifying questions before doing anything.

In Inception, the team runs Mob Elaboration: a synchronous session where product, engineering, and QA validate AI's proposed requirements together and break the intent into units of work, each sized to be reviewable on its own.

In Construction, the team runs Mob Construction, working through those units as bolts — short, verified passes that build and test one reviewable slice before moving to the next. Operations deploys the result and monitors it, and what's learned in production feeds back into the next intent.

Context — plans, requirements, decisions — persists across the whole flow, so each step is more informed than the last.

The current AWS Labs implementation (awslabs/aidlc-workflows) runs this as 5 phases — Initialization, Ideation, Inception, Construction, Operation — across 32 stages, not the 7-step simplification above.

Human validation is real but not uniform, and it depends on scope: greenfield scopes (mvp, enterprise, feature, poc, workshop) begin Construction with a solo, gated "walking skeleton" Bolt that the human approves before the rest run; incremental scopes (bugfix, refactor, security-patch) skip this ceremony since there's nothing to bootstrap on an existing codebase.

Once the walking skeleton ships, a one-time "ladder prompt" lets the team choose gated review of every subsequent Bolt or bounded autonomous execution for the rest of Construction. Even in autonomous mode, any Bolt failure halts the workflow and asks for a human decision — it doesn't fail silently.

Amazon-reported signal

In his 2025 Letter to Shareholders, Amazon CEO Andy Jassy described how the Bedrock team rebuilt its inference engine — internally named Mantle — using Kiro, AWS's agentic coding service. Comparable work, he wrote, might normally take a team of 40 people about a year to build; instead, six engineers delivered it in 76 days. Mantle is now the backbone of Amazon Bedrock's inference capacity.

This is Amazon's own account of one internal engineering effort, not an independently verified or controlled comparison. Jassy's letter credits the result to Kiro by name — it does not mention AI-DLC as the methodology used.

AWS's Financial Services blog later cited this example as illustrative of what agentic development can achieve and connected it to AI-DLC's practices. It's best read as a signal of agentic-development potential — the kind of thing AI-DLC formalizes — not as proof that the formal AI-DLC methodology caused this specific outcome.

The business case: two examples, two different evidentiary weights

IllustrativeNot an AI-DLC customer result. AWS's underlying source models a generic developer-experience investment producing a 15% Cost-to-Serve-Software (CTS-SW) improvement — it is not evidence from an observed AI-DLC implementation:

"Consider a CIO or CTO at a bank with 1,000 developers, each with an annual cost of $130K including tooling, totaling $130M in developer expenses. A 15% CTS-SW improvement achieves $20M in cost avoidance from a $2M solution investment — a 10x return. For every dollar invested, $10 are generated in return."

— AWS, "AI-Driven Development Lifecycle for Financial Services"

Two clarifications worth carrying into any internal use of this figure: 15% of $130M is $19.5M, which AWS rounds to "$20M," and the "10x return" is better understood as an approximate gross benefit-to-investment ratio than a formal, audited net-ROI calculation.

"A 10x return" is an approximate benefit-to-investment ratio — not a formal, audited net-ROI calculation.

Anonymous adopterAWS's Financial Services blog also cites an unnamed European financial institution: one product owner's team went from 15 to 35 features delivered per sprint — more than doubling throughput — while shrinking from 12 developers to 3, a reduction of 9 external contractor FTEs.

AWS does not disclose the customer's name, measurement period, feature-size equivalence, quality outcomes, or evaluation method, so treat the figures as directionally suggestive rather than benchmarked.

The delivery improvement (35 vs. 15 features per sprint) is the more defensible headline than the headcount reduction, which risks reading as a workforce-cutting pitch rather than a productivity one.

Controls that can support regulated adoption

Speed is the headline; governance is what determines whether that speed is usable in a regulated environment. A well-configured implementation can retain linked requirements, designs, tests, approvals, and decisions as work moves through the workflow — for example, a failed test can be traced back to the requirement and user story that generated it.

Turning that into auditor-ready evidence still depends on implementation: access controls, retention policies, verification practices, and the surrounding engineering toolchain all have to be in place around it.

Policy and configuration artifacts — "steering files" in Kiro, project rules or equivalent constructs in other harnesses — guide the AI agent's behavior: encoding security policy, architecture standards, approved dependencies, and regulatory guidance such as the EU AI Act into its operating parameters. Organization-approved security and compliance rules can guide agent behavior; they do not by themselves certify compliance.

Decisions and approvals can be logged to support an audit trail, but how complete and reliable that trail is depends on how an organization configures and operates the workflow.

Measuring it

AI-DLC deliberately tracks a KPI suite designed to work in tension with one another so no single metric can be gamed in isolation: mean time to deployment, mean time to recovery, percentage of failed deployments, number of incidents by severity, technical debt levels, and customer Net Promoter Score. Read together, these give risk and audit functions ongoing, quantifiable assurance rather than a single velocity number that could mask quality erosion.

What operationally changes

The comparison below reflects the pattern in AWS's financial-services case study above — treat it as illustrative of the kind of shift AI-DLC drives, not a universal target for every team.

Dimension Traditional SDLC AI-DLC
Team size Scrum teams of ~7 developers AI Pods of 2–3 developers working in Mob format
Cadence Sprint planning, 2-week cycles Bolts — work done in days, smaller batches, faster deployments
Code review After completion Continuous, high-volume (LLM + human)
Testing Low-fidelity mocks High-fidelity, with realistic simulators plus security and penetration testing
CI/CD Slow, committee-gated build infrastructure Fast pipelines with automated, risk-based quality gates

A three-step path to adoption

The cadence below reflects AWS's financial-services guidance — a pattern to adapt, not a fixed AI-DLC rule.

Step Focus Exit criterion
1. Executive Alignment Align the C-suite on AI-DLC vs. Agile; tie adoption to measurable outcomes. Executive sponsorship secured — without it, adoption stalls at the pilot stage.
2. Technical Enablement Build agentic-coding expertise (Kiro, Claude Code) in architects and leads; identify champion teams. Trained technical champions ready to run a pilot.
3. Hands-On Pilots Run focused 2–3-day pilot sprints on real codebases to build evidence (AWS's FSI guidance). Concrete proof points and momentum for broader rollout.

Organizations then scale through one of two models: decentralized, with wide self-service access, training, and community support, or centralized, with controlled access rolled out in deliberate waves. AWS is explicit that both are viable.

AWS's financial-services guidance treats mature DevSecOps practices as a prerequisite for adoption — a pattern worth validating against your own environment, not a guaranteed universal rule. AI-DLC amplifies existing engineering capability; it does not compensate for foundational gaps in testing, CI/CD, or security discipline.

The ask: approve one bounded AI-DLC pilot

Rather than a general endorsement, the concrete decision this briefing is building toward is scoped and bounded:

  • Select one meaningful but contained use case.
  • Name an accountable business and engineering owner.
  • Define AI authority, human gates, and security constraints.
  • Baseline lead time, quality, rework, and traceability — and agree success, stop, and scale criteria.
  • Expand AI authority only when the evidence supports it.

Three things stay true throughout:

  • Teams likely get smaller and faster — AWS's FSI guidance describes Scrum teams of ~7 becoming "AI Pods" of 2–3, though this is a reported pattern, not a guaranteed outcome.
  • Oversight gets stricter rather than looser, since AI-generated plans require human approval at gated checkpoints, with the option to grant bounded autonomy only after a proven walking-skeleton Bolt.
  • The prerequisite is a mature engineering organization — AI-DLC amplifies existing DevSecOps discipline, it does not substitute for the absence of it.

Sources

Note: AI-DLC is a fast-moving, recently launched methodology. Adoption figures, service names, and tool support should be re-verified against AWS's current documentation before use in external-facing materials.

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


All Posts
Desk2Mob