The classic software development life cycle assumes a human sits down and types the code. Every model taught since the 1970s, waterfall, spiral, agile, puts its heaviest weight on design and implementation, because that is where people spend their hours. That assumption just broke.
In a 2025 randomized controlled trial, METR put 16 experienced open-source developers through 246 tasks on repositories they had maintained for years, and early-2025 AI tools made them 19 percent slower. The same developers forecast a 24 percent speedup going in, then still believed AI had sped them up by 20 percent afterward. They were wrong in both directions. AWS, meanwhile, reports teams collapsing weeks of work into hours on the same tooling. Both results are real. The gap between them is the whole story.
The difference is not the model. It is the life cycle wrapped around it.
Subscribe to the newsletter for weekly analysis on AI and engineering.
What AIDLC means, and why the acronym matters
AIDLC stands for AI Development Life Cycle. AWS Labs expands the same letters as the AI-Driven Development Life Cycle, and open-sourced a formal version in 2025 built around three phases, Inception, Construction, and Operations. The full form tells you the intent directly. This is a lifecycle designed on the premise that agents do the writing, not a human process with a chatbot bolted to the side.
That distinction decides everything downstream. When you retrofit AI as an assistant inside the old SDLC, you keep every inefficiency the old process carried and hand the agent a role it was never shaped for. It generates ten files in the time a junior writes one function, and it gets the wrong abstraction wrong ten times as fast. I wrote the deeper version of this argument in my AI Development Life Cycle pillar, where the method runs as eight phases. Here I want to hold the two life cycles side by side and show exactly where the human hours move.
The phase-by-phase contrast
Map the traditional SDLC onto its agentic equivalent and the structure survives, but the center of gravity slides toward the edges. Requirements gathering becomes an intent-framing exercise a human still owns tightly, because a vague frame now produces a thousand lines of confidently wrong code. Implementation, the phase that used to consume the calendar, compresses to a supervised generation loop. Testing stops being a stage you reach at the end and becomes a harness you build first.
Read the table and one pattern jumps out. The phases that shrink are the ones a machine can do at scale. The phases that grow are the ones that require judgment, taste, and accountability. You cannot delegate the decision about what "correct" means to the thing producing the output.
The AWS version formalizes this with two rituals worth borrowing regardless of which framework you run. Inception uses what they call Mob Elaboration, where the team validates the agent's questions and proposals before a line of code exists, forcing the ambiguity out of the requirements while it is still cheap to fix. Construction uses Mob Construction, where the agent proposes architecture, domain models, and tests, and humans supply real-time clarification on the technical calls. The pattern in both is the same. The agent drafts. The humans decide. Run that division of labor and you have the method itself, nothing more.
Operations, the third AWS phase, remains mostly a placeholder in the current spec, and that honesty is worth noting. Nobody has fully solved autonomous deployment, monitoring, and incident response with the same rigor as the front two phases. The intent is clear, an agent that carries the accumulated context from Inception and Construction into production. The execution is still maturing.
Where developer time actually goes now
Here is the part most adoption plans miss. When implementation gets cheap, the saved hours do not vanish into the profit line. They move. The 2025 DORA report, built on responses from nearly 5,000 technology professionals in Google's research, tied AI adoption to higher software delivery throughput and, at the same time, lower delivery stability. More shipped. More broke. The verification work did not disappear. It relocated and, in many teams, it grew.
McKinsey's controlled study of developer tasks found generative AI cut the time to write new code by 35 to 45 percent and the time to document it by roughly half, while gains on high-complexity work stayed under 10 percent. That is the implementation column collapsing where the task is routine and holding firm where judgment lives. The review gate tells the other half of the story. Faros AI telemetry across 2025, drawn from 10,000 developers across 1,255 teams, tied heavy AI use to pull requests 154 percent larger and review times 91 percent longer, and Intercom reported that over 19 percent of its agent-driven pull requests merged with no human reviewer in the loop. The time you win at the keyboard, you owe back at the review gate. AIDLC makes that trade explicit instead of pretending the second half is free.
This is why senior engineers get more valuable under agents, not less. The scarce skill is no longer typing the loop. It is reading a diff you did not write, spotting the abstraction that will rot in six months, and holding the line on what ships. I unpack the daily mechanics of that supervision in my guide to running Claude Code as a senior engineer.
Consider what a review actually costs now. A human writing a function builds a mental model of it as they go, so review is partly recall. Reviewing agent output gives you none of that context for free. You have to reconstruct the intent, check it against a spec the agent may have misread, and stress the edges the agent smoothed over. CodeRabbit's December 2025 analysis of 470 real pull requests found AI-authored code carried about 1.7 times as many issues as human-authored code, 10.83 per PR against 6.45, which tells you the review burden is not a rounding error. It is the new center of the job. Teams that staffed for the old ratio, mostly writing with a thin review pass, find themselves inverted, mostly reviewing with a thin writing pass.
Why the same tools produce opposite results
The METR slowdown and the AWS speedup come from identical models. The variable is process discipline. Drop an agent into an undisciplined SDLC and you get the METR result, developers babysitting output, re-prompting, and cleaning up subtle wrong turns that cost more than writing the code themselves. Wrap the same agent in a lifecycle that front-loads a precise spec and wires an eval harness before any feature code exists, and you get compression.
AWS renamed the work unit to make the point. Week-long sprints become "bolts," cycles measured in hours or days, because the constraint is no longer how fast a person types. The 2025 DORA authors framed AI as an amplifier. It magnifies whatever your team already is. Strong specs and thick tests get faster. Thin ones get worse, faster.
Adoption itself is no longer the question. Stack Overflow's 2025 survey put 84 percent of developers on AI tools or planning to adopt them, and the 2025 DORA report found 90 percent using AI in daily work. The open question is whether teams rebuild the process around that reality or keep running a human-shaped lifecycle at agentic speed and absorbing the instability.
How teams actually adopt it
The transition is not a tool purchase. It is a shift in where you spend your senior hours. Three moves separate the teams getting the AWS number from the teams getting the METR number.
- Write the spec as if the agent has no context, because it does not. The precision you would have discovered while typing now has to exist before generation starts.
- Build the eval harness before the feature. Tests stop being a trailing stage and become the boundary that lets you trust output you did not write line by line.
- Move senior review to the front of the value chain. Architecture and verification are where humans earn their seat now, not implementation.
None of this requires the AWS framework specifically. It requires accepting that the lifecycle inverted. Effort that used to sit in the middle now sits at the two ends, and the teams that reorganize around that win the compounding advantage.
Adopting an agentic development life cycle?
Most AI projects stall because nobody on the team knows how to design agents, manage token budgets, or wire production evals. I build that layer for B2B companies so the feature actually ships and keeps shipping.
Senior engineer turned AI specialist. React, Next.js, AWS, agent orchestration.
Direct collaboration across UAE, Europe, and US time zones.
Discovery, role design, MCP integration, evals, and production deployment.
The short version
SDLC assumed humans write the code. AIDLC assumes agents do. Everything else follows from that single premise. Implementation stops being the bottleneck, specification and verification become the work, and the senior engineer's judgment turns into the scarcest input in the building. The teams treating AI as a faster junior are measuring their own slowdown. The teams rebuilding the life cycle around verification are the ones shipping in bolts.