AI-DLC: Redesigning the Lifecycle Around the Model
Two vendors, six months apart, with no evident contact between them, open on the same controlled study: developers using AI tools believed they were 20% faster and were measured 20% slower. Both reach the same diagnosis — the coding gains are real, and every one of them is absorbed by the waiting around them — and both conclude that the fix is to redesign the lifecycle rather than bolt AI onto it. The second talk is not a room convened on the first. It is an independent arrival at the same terrain, which is why the examination below has no contested band, and why that absence is the finding.
Primary source
Introducing AI Driven Development Lifecycle (AI-DLC)Anupam Mishra and Raja SP, AWS
Recorded session, 59 min — AWS re:Invent 2025, DVT214
Discussion
AI in the SDLC: Rethinking AI Coding Tools & AI AgentsCedric Clyburn, IBM
Recorded talk, 9 min — independent, six months later
The examination — what the discussion did to each claim
- Corroborated
- The discussion agreed with the report.
- Contested
- The discussion pushed back on the report.
- Extended
- The discussion worked out more than the report stated.
- Unresolved
- The report did not say enough to settle it.
A washed band is unsettled — the two sources disagree, or the report does not say enough to decide. Timestamps are positions in the second recording. Its presenter is named, so the register credits him; nothing is attributed to anyone the recordings do not identify.
Claim 1. Faster, and measurably slower
CorroboratedThe record
Two measurements open the talk. ThoughtWorks put the practical velocity gain at “10 to 15%.” In the METR experiment, sixteen open-source developers were split into two teams of eight across about 250 issues; those who used AI estimated they had been 23% more productive, revised it to 20%, and “when the actual analysis was done … the team which use AI was actually 20% less productive.” The talk presents this as an open question about instruments, not a verdict on AI.
Why it is not working — 3:39
The testimony
- 0:21
… a model evaluation and threat research organization published a controlled study on open source developers. Who thought that they were 20% faster thanks to the coding tools that they were using.
- 0:35
… turns out they were actually 20% less productive and slower because of these new tools that were introduced.
Reading
Both talks open on the same study, and neither uses it to argue that AI does not work. The useful part is the direction of the error: the instrument disagreed with the feeling, and the feeling was confident. This site's memory pillar already carries one negative result of exactly this shape — a memory harness that changed nothing except cost, on a task whose corpus already fit. Measure the distance before you build across it.
Lands onThe Agentic SDLC — all six stages- 0:21
Claim 2. The gains are absorbed, not lost
CorroboratedThe record
Lifecycle time is not spent coding. “In SDLC generally, it is not by design, but this is how we have landed in a world where everybody waits for everybody” — security gatekeeping the release, operations waiting on development, QA waiting on a build — and the cyclic dependencies resolve into escalation and alignment meetings. Speeding up coding therefore returns “a small step increment,” not “the paradigm leap.”
Where does time go in SDLC — 12:26
The testimony
- 1:23
A lot of the time that you would think spent in this entire lifecycle is not spent writing code.
- 2:15
When AI makes one box in this diagram faster … those gains get absorbed by all of the other phases and you don't see that big of an impact for the entire software delivery lifecycle.
- 2:31
… maybe you're coding three times faster, but the surrounding processes aren't changing.
Reading
Amdahl's law, stated twice by people who never name it. This pillar already puts code generation at roughly a fifth of the lifecycle and argues that automating one phase moves the queue downstream rather than draining it. Both talks reach for the same figure of speech independently — one box, one phase, everything else absorbing the difference — which makes this the most firmly established claim in the reading.
Lands onBeyond Code Generation — the other eighty percent- 1:23
Claim 3. Two anti-patterns, and the axis between them
ExtendedThe record
Developers use two broad approaches and both cap out. The AI-managed approach throws an ambiguous problem at the model and expects autonomy: it “seldom works except for very small prototyping scenarios,” and leaves developers putting their name on code they did not read. The AI-assisted approach is “the extreme opposite” — the senior developer plans and decomposes, inserting AI into narrow slots — but “the intellectual heavy lifting is done by the humans, which is same as before AI also.”
The two anti-patterns — 5:29 and 6:55
The testimony
- 2:39
… a lot of them fall in one of two situations and you can kind of think of it like a spectrum.
- 2:46
On one end, you have over delegation, where you hand a frontier model a big ambiguous problem, like, hey, I want you to code me an e-commerce platform.
- 3:51
On the other end is under delegation.
- 4:10
The intellectual heavy lifting now is still 100% human.
Reading
The primary describes two buckets; the discussion draws them as the two ends of one axis, which is the more useful object, because an axis has a middle. Neither talk locates that middle precisely, and the question it poses is the one this pillar's ownership sheet is really about: how much of a decision can be handed over before it stops being checkable? Both ends fail identically — the work that determines whether the output is right stays exactly where it was.
Lands onWho Owns What — judgment human, throughput agentic- 2:39
Claim 4. The unit is plan, validate, execute, verify
CorroboratedThe record
Control comes from seeing the plan before the work: “we ask AI to create a plan. We humans will validate the plan, and that's where we do course correction … AI executes the plan, and human again, verifies the output.” The stated purpose is alignment rather than quality control — “this brings AI's brain and human brain at the same level” — and the cycle repeats at every stage of the method.
Core principles — 11:08
The testimony
- 3:22
This process seldom works, especially for production, because review is slow.
- 8:38
… moving the human role from typing to validating and working with other teams in the organization.
Reading
This site already draws two human stops on the ADLC loop, at intent and at review. The primary supplies what sits inside every station between them: the same four beats, repeated, so a plan stays cheap to redirect and the diff is never the first place a human meets the decision. The discussion supplies the reason the order matters — review is the slow step, so a plan reviewed early costs less than a diff reviewed late.
Lands onThe ADLC Loop — intent to production, continuously- 3:22
Claim 5. Narrow the task, or the assumptions become the output
ExtendedThe record
“Build me a complete e-commerce platform” is unanswerable — “what is the meaning of completeness here? Should there be payments? Should there be shipping?” — so the model supplies the missing decisions itself. The stated remedy is decomposition: “ask AI to decompose the tasks … decomposition should be pretty non ambiguous and narrow. And if any AI executes that decomposed task, output is always better.”
Working with AI — 24:09
The testimony
- 5:42
The vibe coding of today simply doesn't scale.
- 5:47
Instead of asking AI to build entire systems, we can focus on small and well-defined tasks.
- 5:58
… taking the intent that we have for the software we need to build and turning that into a specification that a model can read and follow.
Reading
Both talks say narrow the task. Only the discussion names the artifact that carries the narrowing — a specification the model reads, rather than an instruction a human remembers to give. That is the whole difference between a practice and a harness: one depends on the person at the keyboard being disciplined today, the other survives them leaving.
Lands onThe Unified Context Layer — one source of truth- 5:42
Claim 6. What gets configured is the harness
ExtendedThe record
The methodology ships as configuration rather than as a document: “we have distilled the AI-DLC methodology into steering files … it's a way to take a agentic coding tool, customize it to follow our workflow. Without it, that agentic coding tool might do managed approach and whatever.” The rules are open source, and the workflow they encode is adaptive — “if it's a defect fix, you don't have to do all the stages.”
The demonstration — 45:50
The testimony
- 6:07
So your agent, or the harness which includes the entire system around the agent like tools, allows us to take that original specification and build it out with subagents.
- 6:19
So one to do, say for example, research on a specific topic and dependencies you're using. One to use with MCP servers in order to pull data from different sources your team needs. And then one to do code editing …
Reading
The clearest outside confirmation of the thing this site exists to argue. A methodology that used to live in a process document now lives in files the agent reads, and a nine-stage lifecycle becomes a set of rules deciding which stages to skip. The discussion goes further and names the layer out loud — harness, sub-agents, a shared instructions file — where the primary demonstrates it without naming it. Neither talk treats the model as the variable.
Lands onThe Harness — all eleven primitives- 6:07
Claim 7. A large codebase needs a map before it needs a bigger window
CorroboratedThe record
Pointing an agent at a large repository produces a familiar failure — “AI goes in infinite loop changing almost everything and you feel all you had to done was one change and you went to like 20 files.” The proposed fix is not a larger context window but a derived index: “you have to build some semantic meaning of the code” — call graphs, the classes, what each function does — so that “AI can use it to decide what should I load in context?”
Large existing code bases — 35:13
The testimony
- 8:01
A big use case for AI and software development is modernizing … legacy software systems that no one really understands and the original developers aren't around anymore to maintain.
- 8:13
And what AI is able to do is explain this code and help us to reverse engineer systems to give you a path forward.
Reading
The discussion agrees on the use case and stops; the primary says what the agent has to be handed. Read against this site's memory pillar, that derived index is semantic memory over a codebase — facts about the system, written once and retrieved on demand, so recall becomes a lookup instead of a search. The failure it prevents is a context failure dressed as a reasoning failure: an agent editing twenty files is not confused about the change, it is confused about where the change lives.
Lands onSemantic Memory — what the agent knows about the world- 8:01
Claim 8. The rituals, and the evidence offered for them
UnresolvedThe record
The method's headline change is to human scheduling. Sprints “should not be two weeks to four weeks. It should be hours or less than a day,” and requirements are settled in a mob elaboration — product, development, QA and operations in one room for half a day, using AI to turn intention into stories. The results reported are recalled comparisons: three distributed teams closing months of planned work in about twenty hours, and a fintech launching in 48 hours what had been planned for two months.
Rituals — 14:25; customer stories — 20:25
The testimony
- 1:29
It's the waiting from a, for example, developer waiting on the product team in order to clarify a story that we need to build out.
- 8:45
We're removing friction and coordinating work across the software development lifecycle.
Reading
The diagnosis is corroborated: both talks put the cost in coordination rather than in typing. The remedy is not. This talk opens by citing a controlled experiment to show that self-reported productivity was wrong by forty points, then reports its own headline results as recollections measured against what teams had planned. That is the instrument it warned against, turned on itself. The rituals may well do what is claimed — nothing offered here settles it, and the talk's own opening is the best reason to want better evidence.
Lands onThe Agent Factory Floor — where the work actually runs- 1:29
Claim 9. Measure the distance from intent to launch
CorroboratedThe record
“Traditional metrics don't work very well” — lines produced, code accepted, mean time to repair. What is proposed instead is one end-to-end baseline: “how much time it takes from me as a business leader or a tech leader deciding to build something to it getting launched,” compared with and without AI, on the grounds that an end-to-end measure “removes a lot of metrics which can be gamed.”
Measuring effectiveness — 37:15
The testimony
- 8:49
And instead of measuring metrics like the lines of code generated, it's all about outcomes.
- 8:54
So how's the health of our systems? What's our code maintainability and complexity? And are we reducing the time for changes and new features in the software?
Reading
Both reject the same metrics for the same reason: anything measured inside the coding box can improve while the lifecycle gets slower, which is precisely what the study at the top of this reading recorded. The agreed replacement is a lead time — intent to production — and the agreed hazard is that a proxy is always easier to move than the thing it stands for.
Lands onVerification & Observability — the harness asks for receipts- 8:49
Where this reading lands
Read as vendor content, this is two companies with a methodology to sell. Read as evidence, it is something rarer: two independent talks, six months apart, opening on the same controlled study and arriving at the same diagnosis without citing one another. Nine claims and not one contested band — worth saying plainly, because a reading with no disagreement in it is either genuine corroboration or a failure to look hard enough. What the two do not settle is the remedy. The primary's answer is human ritual, evidenced by recall; the discussion's answer is specification and harness configuration, evidenced by little. The diagnosis is the durable part, and it is this pillar's opening claim in someone else's words: the coding box was never the constraint, and making it faster cannot repair a lifecycle whose time is spent waiting.
07The pillar this reading feedsAgentic SDLC