---
title: "SDLC vs AI-DLC: why technology leaders are switching"
description: "A working guide to AI-DLC for CTOs and VPs of Engineering - what changes at each stage, what it returns, what goes wrong, and how to explain it to your board."
type: Playbook
url: https://sunilkumar.ai/playbooks/sdlc-vs-ai-dlc/
author: Sunil Kumar (https://sunilkumar.ai/about/)
datePublished: 2026-09-04
lastReviewed: 2026-09-04
version: "1.0"
pillar: Organisation
tags: [ai-dlc, sdlc, engineering-leadership, delivery, pods, governance]
license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
---

# SDLC vs AI-DLC: why technology leaders are switching

A working guide to AI-DLC for CTOs and VPs of Engineering - what changes at each stage, what it returns, what goes wrong, and how to explain it to your board.

## In short

- SDLC was designed for a world where writing code was the bottleneck. It no longer is. The bottleneck has moved to deciding what to build, verifying what was built, and keeping it safe in production.
- AI-DLC puts agents to work at every stage, from intent to operations, and keeps humans at four gates - the plan, the design, the review of intent and the decision to release. It is not "developers with Copilot". That is AI-assisted SDLC, and it leaves most of the value on the table.
- The evidence cuts both ways, usefully. Adoption is near-universal and throughput is up, and controlled studies still show experienced developers getting slower with AI and generated code failing security tests. The difference is process, not tools.
- The board conversation is about capacity and risk, not AI. Ask for one programme, one quarter, a fixed budget and three metrics agreed in advance.

## Steps

1. **Audit readiness before buying anything** CI/CD speed, test environment fidelity, coverage and security scanning decide your ceiling. Fix the slowest of them first.
2. **Pick bounded work for the first programme** Internal tools, integrations and test debt compress most. Novel algorithms and unknown requirements compress least.
3. **Write the context repository** Domain glossary, architecture decisions and non-negotiables, versioned in the codebase, read by humans and agents alike.
4. **Name the four gates and their owners** Plan, design, review of intent, release. A named person for each, and the rule that only a human accepts.
5. **Run mob elaboration and ship the first three units** The whole pod in the room for the first intent. Expect the first unit to be slow. Fix the process, not the people.
6. **Move to a unit flow and measure three things** Lead time, change failure rate and cost per outcome, weekly. Ignore volume of code and story points.
7. **Take the decision to the board with your own numbers** The three-programme ROI model, the three metrics against baseline, and a go or no-go on spreading it one engineer at a time.

You run engineering. Maybe 30 people, maybe 800. Your CEO has asked, at least twice, why the company is not doing more with AI. Your developers already use AI tools every day whether or not you approved them. Your backlog is longer than it was two years ago, not shorter. And somewhere in the building a vendor has shown a demo where a feature got built in eleven minutes.

You are trying to work out what is real, what is marketing, and what it would take to change how your team builds software without a quality or security incident on your watch.

This is the guide I wish someone had handed me in early 2025. I spent the first part of my career as a solution architect inside large enterprises, and since 2017 I have run [Ailoitte](https://ailoitte.com), where we have shipped 300+ products for clients in healthcare, fintech, government and manufacturing. For the last two years we have rebuilt our own delivery model around [AI-DLC](/ideas/ai-dlc/). Some of it worked immediately. Some of it did not. Both are in here.

> **AI-DLC (AI Development Lifecycle)**: A software lifecycle in which agents do a large share of the writing, testing and operating, and humans own the definition of done, the review of intent, and the decision to release. AI proposes and produces; a human accepts at four gates: the plan, the design, the review of intent and the release.

## 1. What SDLC was built for, and why it is straining

Every SDLC variant you have used, waterfall, RUP, Scrum, SAFe, DevOps, shares one assumption: humans produce every artefact, so the process exists to coordinate human effort.

Requirements are written by analysts. Designs are drawn by architects. Code is typed by developers. Tests are written by QA. Deployment scripts are maintained by DevOps. Each handoff is a meeting, a document, a ticket, a review. The ceremony, sprints, story points, retros, definition of done, exists to keep that coordination from collapsing.

That model made sense when a senior developer produced maybe 50 to 150 lines of working, tested code a day and the biggest project risk was people misunderstanding each other.

Two things have changed.

First, the cost of producing a first draft of almost any artefact has collapsed. A requirements document, a data model, an API contract, a test suite, a Terraform module, a migration script. All of it can be generated in minutes from a clear description. The draft is not always right, but it exists, and it exists fast.

Second, and this is the part most teams miss, the cost of verifying has not collapsed. Reading generated code carefully is slower than reading code you wrote yourself. Reviewing a 40-file pull request an agent opened at 2am is real work. Deciding whether the agent understood the business rule is real work.

So a team that bolts AI onto an unchanged SDLC ends up with a strange shape: production of drafts is nearly free, verification is as expensive as ever, and the process still has every ceremony it had when production was the bottleneck. Throughput rises, quality wobbles, and leadership sees a bigger cloud bill and no obvious business outcome.

The [2025 DORA report](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report), from close to 5,000 technology professionals, put this plainly: AI does not fix a team, it amplifies what is already there. It found that AI adoption now goes with higher delivery throughput, reversing the 2024 finding, and still goes with lower stability. The gains only turn into product outcomes when the surrounding system, platform quality, clear workflows, visibility of the value stream, is in place.

That is the whole argument for AI-DLC in one sentence. If AI amplifies your process, you need a process designed to be amplified.

## 2. What AI-DLC actually is

The definition at the top is mine, and it describes what changes in a team once an agent can take a ticket, write the code, run the tests and open the pull request. AWS reached a similar place from the other direction. In 2025 it published a methodology it also calls AI-DLC, for AI-Driven Development Lifecycle, and then [open-sourced the workflow rules](https://github.com/awslabs/aidlc-workflows) that run inside coding agents such as Kiro, Amazon Q Developer, Claude Code, Cursor and GitHub Copilot. I treat those workflows as a good implementation of the idea, and the two overlap closely enough that I will use AWS's phases here.

AWS's framing has three phases:

1. **Inception.** The agent turns a business intent into requirements, user stories and units of work. The team does this together in what AWS calls mob elaboration: the agent asks questions, the humans answer and validate, and the output is a plan everyone has seen.
2. **Construction.** The agent proposes architecture and functional design, then generates code and tests unit by unit, with a human approving each unit before moving on.
3. **Operations.** Deployment artefacts, runbooks, observability and the context needed for the next change are produced as part of the work, not afterwards.

The principle I think matters most is that the workflow is adaptive. It looks at whether the work is greenfield or brownfield, how complex the codebase is and how risky the change is, and runs only the stages that add value for the change in front of it. A one-line configuration change and a new payments module do not go through the same ceremony. If you have ever watched a team apply the full Scrum ritual to a bug fix, you will understand why that principle alone is worth the switch.

I want to be clear about what AI-DLC is not, because the phrase gets used loosely.

- It is not "give every developer a coding assistant". That is AI-assisted SDLC.
- It is not vibe coding. Vibe coding has no gates. AI-DLC is mostly gates.
- It is not a tool. You can run it on any capable agent. The methodology is the process, the decision rights and the artefacts.
- It is not the removal of engineers. It is a change in what engineers spend their day doing.

## 3. AI-assisted or AI-native: the distinction that decides your return

Most organisations I speak to think they are doing AI-DLC because 90 percent of their developers use an assistant. DORA's 2025 data shows that number is now typical everywhere, so it is not a differentiator, and on its own it does not change the lifecycle.

Here is the test I use.

| Question | AI-assisted SDLC | AI-native (AI-DLC) |
| --- | --- | --- |
| Where does AI enter? | At the keyboard, when a developer asks | At intent, before a ticket exists |
| Who holds the context? | The developer's head, then a ticket | A versioned context repository that agents and humans both read |
| What is a unit of work? | A story, sized in points | A bounded unit with acceptance criteria, generated tests and a rollback plan |
| Where do humans spend time? | Typing, then reviewing their own typing | Clarifying, deciding, reviewing, verifying |
| How is quality enforced? | Code review and QA at the end | Gates at every stage; tests and security checks generated with the code |
| Cadence | Two-week sprints | Hours to days per unit; releases when the gates pass |
| What is measured? | Velocity, story points | Lead time, change failure rate, cost per delivered outcome |

The left column gives you a 10 to 30 percent speed-up on individual tasks and roughly the same lifecycle. The right column changes the lifecycle and gives you a different order of magnitude on the work that fits it.

## 4. SDLC vs AI-DLC, stage by stage

Here is the same feature travelling through both. The eight stages are the same. What changes is who produces, who decides, and how long you wait.

![Eight stages side by side. Traditional SDLC: a BA writes requirements over weeks; grooming and sprint planning; an architect designs by hand; developers type the code; QA tests at the end; code review of a large pull request; a change board and monthly release trains; ops monitors while the context decays. AI-DLC: the agent elaborates the intent with the team in hours; a plan sized to the risk, gate one; the agent proposes the architecture, gate two; the agent generates code and tests per unit; automated checks on every unit; an engineer accepts the unit, gate three; the agent produces the deploy artefacts, gate four; AI-assisted operations with the context preserved.](../../assets/images/playbooks/sdlc-vs-ai-dlc-stage-by-stage.png)

_One mid-size feature. Four to ten weeks the old way, most of it waiting between stages; hours to days under AI-DLC, most of it deciding rather than producing._

> The chart is free to share: [download it as a PNG](/images/social/sdlc-vs-ai-dlc-stage-by-stage.png) (1600px wide, CC BY 4.0). The same eight stages follow in a table, for reading rather than sharing.

| Stage | Traditional SDLC | AI-DLC |
| --- | --- | --- |
| 1. Requirements | A BA writes them over one to three weeks; the context ends up in documents and heads | The agent elaborates the intent with the team in one session; the team corrects it |
| 2. Planning | Grooming, estimation, sprint planning; work waits for the next sprint boundary | A plan sized to the risk; the team approves it. **Gate 1** |
| 3. Design | An architect draws it by hand, often after the fact | The agent proposes the design from the codebase and the context repository; the architect accepts or redirects. **Gate 2** |
| 4. Build | Developers type the code; tests come later, if at all | The agent generates code and tests per unit, each small enough to read in twenty minutes |
| 5. Test and security | QA at the end; security is a quarterly penetration test | Tests, static analysis and policy checks on every unit; the agent fixes its own findings first |
| 6. Review and accept | Code review of a large pull request; a rubber stamp or a week-long argument | A review of intent on a small unit; a human accepts or rejects. **Gate 3** |
| 7. Release | A change board and monthly release trains; runbooks written by DevOps | Deploy artefacts, runbook and audit evidence come out of the same unit; the release owner approves. **Gate 4** |
| 8. Operate | Ops monitors while the context decays with the people | AI-assisted triage with the full history; decisions live in the context repository |

Notice what did not disappear. There are still four human decision points. There is still an architect. There is still a release owner. What disappeared is the waiting, the re-typing of context from one document into another, and the QA step that happened after the fact instead of alongside.

The four gates map onto the three things I say humans keep in AI-DLC: the definition of done (gates one and two), the [review of intent](/ideas/ai-dlc/) (gate three) and the decision to release (gate four). If a gate has no named owner, it is not a gate; it is a hope.

## 5. Why technology leaders are moving now

I try to give clients both sides, so here are both.

**The case for moving**

- **Adoption is done; the question is method.** Roughly 90 percent of developers already use AI at work, and Gartner expects [90 percent of enterprise software engineers to use AI code assistants by 2028](https://www.gartner.com/en/newsroom/press-releases/2025-07-01-gartner-identifies-the-top-strategic-trends-in-software-engineering-for-2025-and-beyond), up from under 14 percent in early 2024. If the tools are in your building anyway, the only choice left is whether they run inside a governed process or outside one.
- **The ceiling on compression is high for well-bounded work.** In his [2025 letter to shareholders](https://www.aboutamazon.com/news/company-news/amazon-ceo-andy-jassy-2025-letter-to-shareholders), Andy Jassy described six engineers rebuilding Bedrock's inference engine on Kiro in 76 days, work he said would normally take a team of 40 people about a year. AWS's own guidance for [financial services](https://aws.amazon.com/blogs/industries/ai-driven-development-lifecycle-for-financial-services/) is explicit that results like that depend on fast CI/CD, high-fidelity test environments, automated security and compliance gates and clear accountability. Those are prerequisites, not nice-to-haves.
- **Throughput is measurably up.** DORA's 2025 data links AI adoption to higher software delivery throughput, a reversal of the 2024 finding.
- **The role is changing whether you plan for it or not.** Gartner's view is that the developer's role shifts from implementation to orchestration: problem solving, system design and making sure the tools deliver quality. Your hiring, levelling and review processes are built for the old role.

**The case for caution**

- **Speed without process makes things worse.** [METR ran a randomised controlled trial](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) in early 2025 with 16 experienced open-source developers on 246 real tasks. With AI allowed they took 19 percent longer, while believing afterwards that they had been about 20 percent faster. METR labels the result a snapshot of early-2025 tools, and its [February 2026 update](https://metr.org/blog/2026-02-24-uplift-update/) changed the study design because of selection effects. But the perception gap is the lesson: nobody on your team can tell you by feel whether AI is helping. You have to measure.
- **Generated code is not safe by default.** [Veracode's 2025 testing](https://www.veracode.com/blog/genai-code-security-report/) found 45 percent of AI-generated code samples failing security tests and introducing OWASP Top 10 vulnerabilities. Gartner separately expects [AI agents to halve the time it takes to exploit exposed accounts by 2027](https://www.gartner.com/en/newsroom/press-releases/2025-03-18-gartner-predicts-ai-agents-will-reduce-the-time-it-takes-to-exploit-account-exposures-by-50-percent-by-2027). This is why security gates have to be inside the lifecycle, not a quarterly penetration test.
- **Most agentic projects die.** Gartner expects [over 40 percent of agentic AI projects to be cancelled by the end of 2027](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027), because of cost, unclear value or weak risk controls. The failure mode is almost always the same: a pilot that proved the tool worked and never proved the outcome mattered.
- **Instability rises with throughput.** DORA's own summary is that AI raises throughput and also raises instability, and that teams that skip the platform and workflow work drown in AI-generated complexity.

Put those together and you get the actual reason leaders are moving to AI-DLC rather than staying with ad-hoc assistants. AI-DLC is the version of this that has gates. It is the only way I know to take the upside without inheriting the failure modes.

## 6. Where AI-DLC pays off first

Not all work compresses equally. Below is where I have seen the largest returns, roughly in order.

1. **Greenfield internal tools and back-office systems.** Approval workflows, reconciliation tools, vendor portals, reporting layers. Requirements are usually clear, the domain is known to the business, and the risk of a mistake is contained. This is where a pod can go from intent to production in a couple of weeks. It is also the best place to learn the method.
2. **Integration and middleware.** Connecting a core system to three lenders, or an ERP to a logistics provider, is mostly mapping, validation and error handling. Agents are very good at generating the boring 80 percent and the test fixtures for it. Humans own the contract negotiation and the edge cases.
3. **Legacy modernisation, module by module.** Reading a 2009 codebase, explaining what it does, proposing a target design and generating the migration with characterisation tests used to take a senior engineer a quarter. It now takes a week to get to a reviewable proposal. The human work is deciding what not to carry forward.
4. **Product features on an established platform.** Once the platform, design system and CI are in place, feature work becomes a stream of bounded units. This is where the cadence changes from sprints to a continuous flow of units passing gates.
5. **Test debt.** If your coverage is at 30 percent and QA is manual, AI-DLC pays for itself here before it touches a feature. Generating characterisation tests for existing code, then keeping coverage as a gate, is the single most reliable early win.
6. **Regulated products with a compliance layer.** Healthcare, lending, government. Counter-intuitively, these do well, because the gates map neatly onto the controls you already need to evidence: HIPAA, RBI and SEBI guidance, DPDP, ISO 27001. Every gate produces an artefact. Auditors like artefacts.

Where it pays off last: novel algorithms, deep performance engineering, and anything where the requirement itself is unknown. AI-DLC helps you find out faster that you do not know what you want, which is useful, but it does not replace product discovery.

## 7. Expected outcomes, and how to model the return

I do not trust any vendor's headline multiplier, including my own. What I do trust is a model you can populate with your numbers and re-check every quarter.

**The metrics that move**

| Metric | On suitable work, once the method is running | Caveat |
| --- | --- | --- |
| Lead time for changes | 3 to 6x shorter on bounded work; 1.5 to 2x on complex brownfield | Depends heavily on CI/CD and test environment quality |
| Engineers per outcome | 40 to 70 percent fewer people for the same scope | Only senior engineers; the ratio shifts, not the skill bar |
| Test coverage | Rises fast; 30 to 70 percent in the first quarter is common | Coverage is a gate, not a goal; watch assertion quality |
| Change failure rate | Flat or slightly better if the gates are enforced; worse if not | The metric that tells you whether you have AI-DLC or vibe coding |
| Cost per delivered feature | 40 to 60 percent lower including model and tooling spend | Model spend is real; budget it as a line item |
| Time in meetings and handoffs | Drops sharply; elaboration replaces grooming, planning and much of review | The team notices this before leadership does |

These are ranges from our own delivery on suitable work and from what peers report. Treat them as hypotheses to test in your first programme, not promises.

**A simple model**

Take one representative programme you would have staffed the old way.

```text
Baseline (SDLC)
  Team size            12 people
  Fully loaded cost    X per person-month
  Duration             9 months
  Baseline cost        12 × 9 × X = 108 X

AI-DLC pod
  Team size            5 senior people
  Duration             4 months
  People cost          5 × 4 × X = 20 X
  Model and tooling    2 to 3 X (10 to 15% of people)
  Enablement, one-off  6 to 10 X (platform, CI, gates)
  Pod cost             about 30 X

Direct saving          about 75 X on this programme
Time to value          5 months earlier
```

Now add the second-order line, which is the one boards actually care about: what is five months of earlier revenue, or five months less regulatory exposure, worth? On most programmes that number is larger than the delivery saving.

Two honest adjustments. The first programme carries the enablement cost; the second and third do not, so run the model over three programmes, not one. And if your CI takes 40 minutes and your staging environment is shared and flaky, subtract most of the speed-up until that is fixed. AWS makes the same point about Amazon's own results.

## 8. What goes wrong, and the guardrails that prevent it

Every failed adoption I have seen fits one of five patterns.

1. **No gates, only speed.** Agents opening pull requests nobody reads properly. Fix: a human accepts every unit, and a unit is small enough to actually be read. If a pull request is too big to review in twenty minutes, the unit was too big.
2. **Context lives in people's heads.** The agent re-derives the domain every time and gets it subtly wrong. Fix: a versioned context repository, in the codebase, that both humans and agents read and update. Architecture decisions, domain glossary, non-negotiables, the refusal list.
3. **Security bolted on later.** Fix: static analysis, dependency and secrets scanning, and policy checks run at the construction gate, with the agent required to fix its own findings before a human sees the code.
4. **Measuring the wrong thing.** Story points go up and everyone celebrates. Fix: measure lead time, change failure rate and cost per outcome. Ignore volume of code.
5. **Treating it as a tool rollout.** Licences purchased, a lunch-and-learn, nothing else. Fix: pick one team, one programme, one quarter, and change their process end to end. Then spread the process, not the licence.

The rule I give every team: the agent may propose anything and may produce anything, but it may not accept anything. Acceptance is a human act. Once that is true, most of the rest follows.

## The playbook

Seven steps, in the order we run them with clients. They fit in ninety days if the first one goes well.

## Step 1. Audit readiness before buying anything

Days 1 to 15. Measure four things: how long CI takes, how faithful your test environments are to production, what your test coverage is, and whether security scanning runs on every change. These decide your ceiling. A 40-minute pipeline and a shared, flaky staging environment will eat most of the speed-up, and no amount of prompting will get it back.


- [ ] CI time per change, and the target you will hold it to.
- [ ] Test environment fidelity: what differs from production, and who owns closing the gap.
- [ ] Coverage today, and whether the assertions are meaningful.
- [ ] Security scanning in the pipeline, or a plan to put it there before the first unit ships.


## Step 2. Pick bounded work for the first programme

Use the list in section 6. The first programme should have clear requirements, a known domain and a contained blast radius. Internal tools, an integration, or test debt on a system you already run. Pick five senior engineers who are curious rather than five who are available.


- [ ] One programme, bounded, with an outcome you can write in a sentence.
- [ ] Five people, senior, including one from the business side as domain reviewer.
- [ ] A baseline for the three metrics you will report against.


## Step 3. Write the context repository

Before the first intent goes to an agent, write down what the agent cannot infer: the domain glossary, the architecture decisions already made, the non-negotiables, and the [refusal list](/ideas/agentic-in-production/) of things no unit may do. Put it in the codebase, version it, and make it the first thing every agent reads and every human updates.


- [ ] Domain glossary in plain language.
- [ ] Architecture decisions with the reasons.
- [ ] Non-negotiables: data residency, dependencies, patterns you will not accept.
- [ ] Refusal list, enforced where possible in code rather than in a prompt.


## Step 4. Name the four gates and their owners

Plan, design, review of intent, release. Each gate has a named owner and a written question the owner answers. Gate one: is this the right unit of work, and is done defined? Gate two: is this the design we would defend? Gate three: does the unit do what was asked, and nothing else? Gate four: are the artefacts here to run it, watch it and roll it back?


- [ ] Four gates written down with the question each answers.
- [ ] A named owner for each, on your side, not the vendor's.
- [ ] The rule, agreed and visible: the agent proposes and produces; only a human accepts.


## Step 5. Run mob elaboration and ship the first three units

Days 16 to 45. The whole pod in the room for the first intent. Let the agent ask its questions and let the domain reviewer answer them. Then set the units, run the gates and ship the first three to production. Expect the first one to be slow and slightly painful. Fix the process, not the people.


- [ ] First elaboration session held with the domain reviewer present.
- [ ] First three units in production, each accepted by a human at gate three.
- [ ] A list of what the agent consistently got wrong, added to the context repository.


## Step 6. Move to a unit flow and measure three things

Days 46 to 75. Retire the sprint rituals the units have made redundant and replace them with a unit-flow board. Track lead time and change failure rate weekly, and cost per outcome monthly. Add the security gate if it is not there yet.


- [ ] Unit-flow board replacing sprint planning and grooming.
- [ ] Lead time and change failure rate reported weekly against the baseline.
- [ ] Security checks running at the construction gate, with the agent fixing its own findings.


## Step 7. Take the decision to the board with your own numbers

Days 76 to 90. Compare the three agreed metrics against the baseline and present them in the format from the next section. Decide whether to spread, and if so, which team next. Do not spread by memo. Spread by moving one engineer from the pilot pod into the next team.


- [ ] Three metrics against baseline, with the ROI model populated.
- [ ] A go or no-go decision, and the next team named.
- [ ] One engineer from the pilot pod moving with the process.


## How to explain this to your CEO, board or management

Do not open with AI. They have heard it. Open with capacity and risk.

**The one-paragraph version**

> We have more validated work than we have people to build it. The way we build software today assumes that writing code is the slow part. It no longer is. We want to move our delivery to a governed AI-driven lifecycle, where agents produce first drafts of requirements, designs, code and tests, and our senior engineers decide, review and accept at defined checkpoints. On suitable work this cuts delivery time by more than half and reduces the people required per outcome, while adding controls we do not have today. We would like to prove it on one programme this quarter with a fixed budget and clear success criteria.

**The three questions they will ask**

_"Is it safe?"_ Safer than what we do now, if done properly. Today developers already use AI tools, mostly unmanaged. AI-DLC brings that inside a process with security scanning and human approval at every stage, and produces audit evidence as a by-product. The risk is real if we skip the gates, which is why the pilot funds the gates first.

_"What does it cost and what do we get back?"_ Show the three-programme model from section 7 with your own numbers. Lead with time to value, then with cost. Be explicit that model spend is a new line item and that the first programme carries the setup cost.

_"What happens to the team?"_ Fewer people per outcome, not fewer people. The backlog is the constraint, not headcount. Senior engineers become more valuable, not less. Juniors need a different growth path, and we should be honest that we are still designing it.

**What to ask for.** One programme. One quarter. A fixed budget. Three metrics agreed in advance: lead time, change failure rate, cost per outcome. A decision meeting at the end with a go or no-go on spreading it. That request is small enough to say yes to and large enough to be real.

## How I run this at Ailoitte: AI-DLC inside AI Velocity Pods

Everything above is the method. This section is how we operate it commercially, because a lifecycle on its own does not change the risk your CFO is carrying.

An [AI Velocity Pod](/ideas/ai-velocity-pods/) is a small senior team, typically an architect, two or three engineers and an automation lead, that owns an outcome end to end on a fixed price. The pod runs AI-DLC internally: mob elaboration with the client, gated construction, generated tests, security checks at the gate, and deployment artefacts as part of the deliverable. The client owns all of the IP. Where the client is regulated, we run a compliance layer under the pod that maps the gates to the controls they need to evidence.

The pod model exists because AI-DLC changes the economics enough that [fixed price becomes rational again](/writing/fixed-price-for-agentic-ai-how-pods-make-it-possible/). When a team of five can do what twelve used to do, and cycle time is measured in days, the delivery risk we carry on a fixed price is far smaller than it was in 2020. We would rather carry that risk than ask a client to pay for hours.

**What changed for clients**

The four stories below are composites from our delivery since 2024. Names are withheld, details are changed so that no client is identifiable, and the numbers are rounded to the shape of what we see.

_A US healthcare platform under HIPAA._ When we started, the client had a 40-person engineering team, a manual QA function of six, unit-test coverage of about 22 percent, and a release once a month that everyone dreaded. The last two releases had each been rolled back once. Our first month was not feature work. A five-person pod used the inception phase to have agents read the core modules and generate characterisation tests, which the client's senior engineers reviewed and corrected. Coverage went from 22 to 68 percent in seven weeks. Only then did we put coverage and static analysis at the construction gate and start feature units. Lead time for a typical feature went from six to eight weeks to four to six days. Releases moved from monthly to on demand; in the third month they shipped fourteen times with one hotfix and no rollbacks. The unexpected win was compliance: the four gate artefacts per unit, the approved plan, the approved design, the passing checks and the release sign-off, became the evidence pack for their HIPAA audit, which had previously taken two people three weeks to assemble by hand. It took two days.

_An Indian manufacturer replacing a twelve-year-old ERP._ The original estimate from their previous vendor was eighteen months and a team of fifteen on time and materials. The behaviour of the old system lived in two long-serving employees and roughly 400,000 lines of undocumented code. In inception we had agents read the codebase module by module and produce a behaviour catalogue: 1,100 business rules, each with the code that implemented it and a plain-language description. The two employees corrected it in elaboration sessions over three weeks; about 15 percent of the rules were wrong or obsolete, which is exactly the knowledge nobody had written down. That catalogue became the context repository for the rebuild and the acceptance test list. A six-person pod delivered the replacement in seven months on a fixed price, with the finance and purchase modules live in month four so the client could stop paying for the old licence early. The client's own view afterwards was that the catalogue alone would have been worth the engagement, because for the first time they knew what their ERP actually did.

_A lending business integrating multiple lender partners._ A middleware layer had to connect the client's platform to lender APIs for eligibility, application, disbursement and status. The first integration, done the old way by their own team, had taken about nine weeks. Under AI-DLC the pod treated each lender as a set of bounded units: schema mapping, validation rules, error and retry handling, and reconciliation, each with generated test fixtures built from the lender's sandbox responses. The second integration took twelve working days. The fourth took six. By the seventh the pod was spending almost no time on scaffolding and nearly all of it on the parts that matter: partner-specific edge cases, failure paths and the reconciliation rules that finance cared about. Eight lenders were live in under four months, with a shared test harness that the client's team now uses to onboard new partners themselves.

_A large automotive enterprise, in progress._ Two tracks running in parallel. The first is an agentic delivery pipeline for their web, mobile and conversational applications: context repository, gate definitions, security checks, agent configuration and the playbook, built with their engineers in the room and handed over once it is stable, which we have scoped at two quarters. The second is outcome-based pods for new product programmes, priced per outcome rather than per hour, because their AI programme office had more validated use cases than the internal team could build. This is the shape I expect most large enterprises to ask for over the next eighteen months: build the lifecycle together, run it together, then hand it over and stay on for the programmes where a pod is faster than hiring.

What is consistent across all four: the first two weeks are slower than the client expects, the gates are where the trust is built, and the metric that convinces the finance side is never lines of code and always time to the outcome.

## How I can help you adopt AI-DLC

Three ways, depending on where you are.

**A two-week production readiness review.** I look at your CI/CD, test infrastructure, security controls, team structure and current AI usage, and give you a written assessment of which programmes are ready for AI-DLC, which are not, and what it would take. Fixed price, agreed after a 30-minute call.

**A quarterly standing arrangement.** For leaders who want a second opinion as they roll this out: gate design, metric review, board preparation, vendor evaluation. A fixed number of hours a month, no surprises.

**An AI Velocity Pod from Ailoitte.** If you would rather see it work than read about it, we take one programme on a fixed price, run it under AI-DLC with your team in the elaboration sessions, and either hand you a working lifecycle at the end or keep running pods alongside your team. Demo before deck, always.

The [work with me](/work-with-me/) page has the details and a booking link.

## If you are doing this in your company

- Start with the readiness audit, not the tool purchase. CI speed and test environments decide your ceiling.
- Pick bounded work first: internal tools, integrations, test debt.
- Write the four gates down and name an owner for each before the first unit ships.
- Measure lead time, change failure rate and cost per outcome. Nothing else for the first quarter.
- Ask the board for one programme, one quarter, one fixed budget.
- The agent proposes and produces. A human accepts. Do not negotiate that rule.

## Sources

- Google Cloud, [Announcing the 2025 DORA Report: State of AI-assisted Software Development](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report), September 2025, and the [full report](https://dora.dev/dora-report-2025/).
- AWS DevOps Blog, [Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle (AI-DLC)](https://aws.amazon.com/blogs/devops/open-sourcing-adaptive-workflows-for-ai-driven-development-life-cycle-ai-dlc/), November 2025, and the [aidlc-workflows repository](https://github.com/awslabs/aidlc-workflows).
- AWS for Industries, [AI-Driven Development Lifecycle for Financial Services](https://aws.amazon.com/blogs/industries/ai-driven-development-lifecycle-for-financial-services/), May 2026.
- Amazon, [Andy Jassy's 2025 letter to shareholders](https://www.aboutamazon.com/news/company-news/amazon-ceo-andy-jassy-2025-letter-to-shareholders), April 2026.
- METR, [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), July 2025, and [the February 2026 design update](https://metr.org/blog/2026-02-24-uplift-update/).
- Veracode, [2025 GenAI Code Security Report](https://www.veracode.com/blog/genai-code-security-report/), 2025.
- Gartner, [Over 40% of Agentic AI Projects Will Be Canceled by End of 2027](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027), June 2025.
- Gartner, [Top Strategic Trends in Software Engineering for 2025 and Beyond](https://www.gartner.com/en/newsroom/press-releases/2025-07-01-gartner-identifies-the-top-strategic-trends-in-software-engineering-for-2025-and-beyond), July 2025.
- Gartner, [AI Agents Will Reduce the Time It Takes to Exploit Account Exposures by 50% by 2027](https://www.gartner.com/en/newsroom/press-releases/2025-03-18-gartner-predicts-ai-agents-will-reduce-the-time-it-takes-to-exploit-account-exposures-by-50-percent-by-2027), March 2025.

Findings from these sources are paraphrased; the reports themselves are the authority on their own figures.


## Questions people ask

**Is AI-DLC the same thing as the AWS methodology of the same name?**

They overlap closely and I treat AWS's open-source workflows as a good implementation. AWS published its AI-Driven Development Lifecycle in 2025 with three phases, inception, construction and operations. I have used AI-DLC on this site for the broader change in who does which step - agents draft, test and operate; humans own the definition of done, the review of intent and the decision to release. Whichever name you use, the four gates and the context repository are what matter.

**Do we need a particular tool to do this?**

No. AI-DLC is a process, a set of decision rights and a set of artefacts. It runs on any capable coding agent. The AWS workflow rules work in Kiro, Amazon Q Developer, Claude Code, Cursor and GitHub Copilot, and we have run the same gates on all of them. Buy the tool your engineers already like; change the process.

**What happens to junior engineers?**

The first-draft work that juniors used to learn on has moved to agents, and the review work that seniors do has grown. That is a real problem and I do not think anyone has solved it yet. What works for us is pairing a junior with a senior in elaboration sessions and giving them ownership of the evaluation cases and the context repository, which is where the domain knowledge now lives.

**Is this what Ailoitte does on its own projects?**

Yes, since 2024. Every AI Velocity Pod runs AI-DLC internally, which is what lets us quote a fixed price. The four anonymised stories in this playbook are composites from that work, with names withheld, details changed and numbers rounded.


---
Sunil Kumar, Co-founder and CEO, Ailoitte Technologies. https://sunilkumar.ai/about/