# AI-DLC: The AI-Driven Development Life Cycle That Replaces Sprints With Bolts

*Author: Siddhesh Prabhugaonkar — Enterprise AI & Cloud Advisor*

For twenty years we have shipped software the same way: sprints, standups, story points, retros. Then generative AI arrived and we mostly bolted it onto the side. Copilot in the IDE. A chatbot in Jira. An autonomous coding agent in a sandbox. Productivity moved. The lifecycle did not.

In July 2025, AWS published a piece — and a companion white paper — arguing that this is the wrong game. The article is titled [*"AI-Driven Development Life Cycle: Reimagining Software Engineering"*](https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle) and it introduces **AI-DLC**, a methodology that treats AI not as an assistant but as the *primary driver* of the development lifecycle, with humans in the loop as validators and decision-makers.

This post unpacks what AI-DLC is, how the three phases actually work, why *bolts* replace *sprints*, and where I think it fits — and doesn't fit — in real enterprises.

> **Rolling out AI in your engineering org and unsure whether to double-down on Copilot, adopt Kiro/AI-DLC, or wait?** I run enablement workshops for engineering leaders on exactly this question. [Book a discovery call →](https://topmate.io/siddheshp)

* * *

## The problem AI-DLC is trying to solve

Today, most organisations use AI in software development through one of two patterns:

| Pattern | What it looks like | The ceiling |
| --- | --- | --- |
| **AI-assisted development** | Copilot completions, AI-written tests, doc generation, chat-in-IDE | AI enhances individual tasks, but the SDLC itself is unchanged. Product owners still write JIRAs by hand, architects still draw diagrams in Miro, standups still take 30 minutes. |
| **AI-autonomous development** | "Build me a to-do app" style agents that generate an entire codebase from a one-line prompt | Impressive demos, hallucinated architectures. Loses fidelity to actual business intent. Non-deterministic. Impossible to govern at enterprise scale. |

AWS's argument is that both patterns leave enormous productivity on the table because our existing SDLC is *designed for human-driven, long-running processes*. Product owners, developers and architects spend most of their week on non-core activities — planning meetings, refinement, estimation, ceremonies, status updates. Retrofitting AI as an "assistant" inside that structure reinforces the very inefficiencies we should be tearing down.

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/f975b967-b7da-489b-b0e9-9fbb42865577.png align="center")

AI-DLC positions itself as the third option — AI runs the workflow, humans steer it.

* * *

## What AI-DLC actually is

AI-DLC rests on two dimensions that operate simultaneously through every phase of the lifecycle:

### 1\. AI-powered execution with human oversight

AI systematically creates detailed work plans, actively seeks clarification, and defers *critical* decisions to humans. The premise: only humans possess contextual understanding of business requirements, regulatory context, brand tone, security posture and organisational politics. AI does the mechanical lifting; humans make the calls.

### 2\. Dynamic team collaboration

Because AI handles the routine plumbing, product managers, architects and engineers stop working in silos. They converge in high-bandwidth *mob* sessions to answer AI's clarifying questions, resolve trade-offs, and unlock next steps in real time. The centre of gravity shifts from asynchronous ticket-passing to synchronous decision-making.

### The mental model

Every AI-DLC activity — writing a requirement, generating an architecture, provisioning infrastructure — follows the same four-step loop:

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/a903fdbd-6567-4810-a3a9-d73691c21a9b.png align="center")

Two things make this different from just "using Copilot well":

*   **AI initiates the workflow.** It is not waiting for you to open a ticket and type a prompt. Given a business intent, AI proposes the next unit of work.
    
*   **Context is persisted to the repo.** Plans, requirements, design decisions and architectural rationale are stored as artifacts — not in someone's head or a Slack thread. Every subsequent activity starts with richer context than the last.
    

* * *

## The three phases

AI-DLC compresses the entire lifecycle into three phases. Each phase builds context that flows into the next.

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/493dc053-c2b3-4dfc-99eb-5fdc4be97a73.png align="center")

### Phase 1 — Inception

AI transforms raw business intent into detailed requirements, user stories and **units of work** through a ritual called **Mob Elaboration**. The whole team — product, engineering, design, sometimes even legal or compliance — sits in one room (or one Zoom) and validates AI's proposals in real time. There is no back-and-forth over three sprints while a BA "writes up the story". The story is drafted, questioned, refined and accepted in the same session.

### Phase 2 — Construction

Using the validated context from Inception, AI proposes a logical architecture, domain model, code and tests through **Mob Construction**. Engineers focus their expensive attention on the choices that actually matter: is a saga the right pattern here? Do we need eventual consistency in this bounded context? Which decisions lock us in and which are reversible? AI writes the mechanical code; the humans in the mob resolve the design trade-offs.

### Phase 3 — Operations

AI applies the accumulated context to manage infrastructure as code, deployments, monitoring and incident response. Humans oversee production changes and hold the pager. This is essentially platform engineering with an AI operator that already knows the system it is running because *it helped design and build it*.

The compounding effect is important: the more phases AI has run, the richer its persisted context, the better its next suggestion. Context is the moat.

* * *

## The new vocabulary: bolts, units, mobs

AI-DLC deliberately abandons Agile/Scrum terminology because the old words drag old behaviours with them. If you call it a sprint, people will unconsciously plan it for two weeks. If you call it an epic, someone will demand a T-shirt size estimate.

| Traditional Agile | AI-DLC | Why the change |
| --- | --- | --- |
| **Sprint** (2–4 weeks) | **Bolt** (hours to days) | Cycles are radically shorter — AI generates artifacts in minutes, so waiting two weeks to review them is malpractice |
| **Epic** | **Unit of Work** | An epic implies a fixed scope estimated up-front; a unit is scoped just-in-time by the mob |
| **Story refinement** (async, days) | **Mob Elaboration** (sync, hours) | Whole team present, AI drives, decisions in-session |
| **Sprint planning** | *(mostly eliminated)* | AI proposes the plan; the mob validates it in minutes |
| **Standup** | *(mostly eliminated)* | Persistent AI context replaces status updates |
| **Backlog grooming** | *(eliminated)* | Backlog is generated on demand from business intent |

Visually, the tempo change over the same ~4-week window looks like this:

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/be85fca9-0d12-4291-a461-d698ea49934c.png align="center")

Each bolt closes a specific unit of work — a validated requirement, a working service, a deployed change. The team is *always* shipping something.

* * *

## The team topology shifts too

In traditional scrum, roles are strongly siloed: PO writes stories, dev implements, QA tests, SRE deploys. Handoffs create latency and lose context. In AI-DLC, the mob is the unit of production and AI is the connective tissue.

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/0474146a-28ae-49f6-ab50-bd83f381f243.png align="center")

The interesting knock-on effect: **role boundaries blur but decision authority sharpens.** Everyone in the mob can propose. The AI drafts. But the human owner of a domain — security for security decisions, the architect for tech-stack decisions, the PO for scope decisions — still calls the shot. AI-DLC does not abolish accountability; it moves it forward and makes it explicit in the moment.

* * *

## Claimed benefits — and the honest read

AWS lists five benefits. Here they are, with my practitioner take next to each.

| Benefit | What AWS claims | Honest read |
| --- | --- | --- |
| **Velocity** | Hours/days for work that took weeks | Real for greenfield and well-scoped changes. Legacy modernisation still bottlenecks on humans understanding the *why* of the old code. |
| **Innovation** | Freed-up time for creative exploration | Only if leadership actively protects that time. Otherwise it gets absorbed into "more tickets, faster". |
| **Quality** | Continuous clarification + org-specific standards + AI-generated test suites | The clarification loop is genuinely the biggest quality lever here. AI-generated tests are useful but need human-designed acceptance criteria. |
| **Market Responsiveness** | Faster feedback cycles | True if your deployment pipeline can keep up. AI-DLC upstream + fortnightly release trains downstream = wasted potential. |
| **Developer Experience** | Less grunt work, more problem-solving | For senior engineers, yes. For juniors, there is a real risk of skill atrophy — see below. |

### Where I would be cautious

Two concerns I would raise in any adoption conversation:

*   **The juniors problem.** If AI drafts requirements, architecture and code, junior engineers lose the reps that used to build their judgement. AI-DLC works best on teams that already have strong senior architects and engineers in the mob. Green teams will ship faster but learn slower.
    
*   **Context lock-in.** AI-DLC's power comes from persistent context in the repo. That context becomes a critical asset — and if it lives inside a vendor's proprietary format (Amazon Q rules, Kiro workflows), you have a new flavour of lock-in that is harder to see than a traditional cloud dependency.
    

Neither is a deal-breaker. Both are worth planning for.

* * *

## Where AI-DLC fits with what you already run

You do not need to burn down Scrum to try AI-DLC. A pragmatic staged adoption:

![](https://cdn.hashnode.com/uploads/covers/651bff05e4455a8ac9ec7688/e025b648-d0a7-44d2-896f-433cfc9844b1.png align="center")

Most enterprises I work with are somewhere between Stage 1 and Stage 2. The single highest-leverage move is **Stage 2 — introducing Mob Elaboration for one new product line or platform capability.** It requires no toolchain change, tests the cultural readiness for high-bandwidth collaboration, and produces artifacts (well-written requirements, persisted context) that pay off even if you never adopt the rest.

* * *

## Getting started

AWS's suggested on-ramps:

1.  **Read the** [**AI-DLC white paper**](https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle) and share it with your engineering leadership team.
    
2.  **Explore tooling:** Amazon Q Developer *rules* and *Kiro* custom workflows are AWS's preferred vehicles to codify AI-DLC patterns. If you are on Microsoft's stack, the equivalent building blocks are GitHub Copilot custom instructions, agent modes, and spec-driven workflows — the methodology is portable even if the branding is not.
    
3.  **Pilot on one team, one product line.** Pick a greenfield or well-understood domain. Do not start with your monolithic core banking platform.
    
4.  **Measure the right things.** Not lines of code or PR count — measure time-from-intent-to-production, defect escape rate, and mob participant satisfaction.
    

* * *

## The bottom line

AI-DLC is the first serious attempt I have seen to redesign the software lifecycle *around* AI rather than *for* AI. The vocabulary is deliberately provocative — bolts, mobs, units of work — because the authors understand that language shapes behaviour, and Scrum's language quietly enforces Scrum's tempo.

You do not have to buy every claim. You should probably not rip out your Jira boards tomorrow morning. But if you are an engineering leader who has been quietly wondering why your Copilot rollout produced happier developers and roughly the same delivery cadence, AI-DLC is pointing at the answer: the tool changed, the operating model did not.

Fix the operating model.

* * *

*If you found this useful, I write regularly on enterprise AI, agentic architectures, and the productivity paradox of generative AI in large organisations. My other recent posts:*

*   [*The AI Productivity Paradox: Why 87% of Workers Use AI, But Only 13% of Companies See Real Gains*](https://azureauthority.in/ai-productivity-paradox-botsitting-botshitting)
    
*   [*AI Agents, Multi-Agent Systems & LLM Council: A Practitioner's Guide to Enterprise Agentic AI*](https://azureauthority.in/ai-agents-multi-agents-llm-council-enterprise-guide)
    

**Want to discuss AI-DLC adoption or a broader engineering AI strategy for your organisation?** [**Book a discovery call →**](https://topmate.io/siddheshp)

* * *

### References

*   AWS DevOps Blog — [*AI-Driven Development Life Cycle: Reimagining Software Engineering*](https://aws.amazon.com/blogs/devops/ai-driven-development-life-cycle) (Raja SP, 31 July 2025)
    
*   [Amazon Q Developer](https://aws.amazon.com/q/developer/)
    
*   [Kiro — spec-driven AI IDE from AWS](https://kiro.dev/)
    

* * *

## About the Author

**Siddhesh Prabhugaonkar** is a **Generative AI & Agentic AI Enablement and Adoption Specialist** with two decades as an Architect, Consultant, and Trainer across IT, Cloud, and Generative AI. He is a **Microsoft Certified Trainer**, a **Pluralsight Instructor**, and helps enterprises move from GenAI curiosity to production adoption at scale.

His consulting and training practice spans **GenAI, Azure, Microsoft Foundry, Anthropic Claude, GitHub Copilot, Amazon Q, Kiro, Google Gemini, OpenAI Codex, Cursor, Windsurf/Devin**, and modern full‑stack engineering (.NET, MEAN, MERN). Notable engagements include GenAI enablement for **ADP**, IoT platform consulting for **IIT Bombay's E‑Yantra** program, and early work on Microsoft's Repository platform (which later became **Entity Framework**).

> *Empowering organizations and individuals to adopt, build, and scale with Generative AI, Cloud, and Modern Software Engineering.*

**Connect & explore:**

*   💼 LinkedIn — [linkedin.com/in/siddheshprabhugaonkar](https://www.linkedin.com/in/siddheshprabhugaonkar)
    
*   📝 Blog — [azureauthority.in](https://azureauthority.in/)
    
*   📬 Newsletter — [cloud-authority.com](https://cloud-authority.com/)
    
*   🎥 YouTube — [youtube.com/c/SiddheshPrabhugaonkar](https://www.youtube.com/c/SiddheshPrabhugaonkar)
    
*   🤝 Book a 1:1 on Topmate — [topmate.io/siddheshp](https://topmate.io/siddheshp)
    
*   🎓 Research Papers (Google Scholar) — [scholar.google.com](https://scholar.google.com/citations?user=TuqOYtwAAAAJ&hl=en)