AIDLC vs SDLC: What Changes and What Stays
AIDLC is not a rejection of the software development life cycle. It keeps the SDLC's purpose - turning a need into running, maintained software - and changes the assumptions underneath it, because agents now do much of the writing. This page maps the classic stages onto the five phases, says plainly what stays the same, and clears up the misconceptions that come up most often.
The Short Answer
The SDLC was designed around a scarce resource: the time it takes people to write code. AIDLC is designed around a different one: the time it takes people to verify code that agents wrote. Authoring got cheap; judgment did not. Almost every difference below follows from that one shift.
So the stages survive, but their weight moves. Requirements and design matter more, because an agent builds exactly what it is told. Testing moves from a stage after coding to the first step of coding. Review becomes the bottleneck and has to scale by risk. And maintenance gains a feedback loop that writes rules the agents read on their next task.
Stage by Stage
The classic six stages map onto five phases. Testing is the one that does not map one to one: it splits between Develop, where the tests are written, and Launch, where the integrated release is verified.
| Traditional SDLC | AIDLC phase | What changes |
|---|---|---|
| Requirements | Analyze | An agent drafts from interviews and documents; the product owner signs a brief whose acceptance criteria are Given/When/Then, precise enough to become tests. |
| Design | Ideate | Agents generate competing designs cheaply; people choose and record why in an ADR. The output is a spec an agent can execute and contracts for every boundary. |
| Implementation | Develop | Agents author in thin slices under ticket contracts; a person approves each plan before code and reviews each diff at its risk tier. |
| Testing (writing the tests) | Moves before the code. Unit, integration and contract tests come from the criteria first, and the code is built until they pass. | |
| Testing (verifying the release) | Launch | Release assurance: the full suite on the integrated build, a mutation re-check and an independent search for gaps. |
| Deployment | Progressive delivery behind flags with a rehearsed rollback; agents work in the pipeline under hard rules and never hold production credentials. | |
| Maintenance | Curate | Read-only monitoring agents triage; every incident must produce a rule, test or eval, so the same mistake cannot pass twice. |
What Stays the Same
People are accountable
Agents draft; named people sign the brief, approve the design, review the code and make the release decision. See the RACI.
Requirements discipline
Clear problem statements and acceptance criteria matter more, not less. An agent fills every gap in a requirement with a guess.
Review and release management
Code review, change control, release plans and rollback paths all remain; they get tiered by risk so they scale with agent volume.
Security and compliance
The same frameworks apply. Agents add new surfaces to control, covered in Security and Compliance.
Your process framework
Scrum, Kanban and DevOps keep running. AIDLC sits inside them; see AIDLC With Scrum and Kanban.
Engineering fundamentals
Small batches, version control, CI and readable code still decide quality. Agents amplify good practice and bad practice alike.
What Actually Changes
The bottleneck moves from writing to verifying
Faster authoring without faster verification produces a queue at review, not more delivered work. The Productivity Paradox covers the evidence.
Documents become contracts
The brief, spec and ticket are read by agents, so they must be precise and machine-checkable. A document that was once a courtesy is now an input.
Testing moves to the front
Tests come from the criteria before the code, and the gate checks that they are real. See Testing Strategy.
Review scales by risk, not by volume
Uniform line-by-line review collapses under agent volume. Risk tiers decide review depth. See AI Code Review at Scale.
The loop writes rules agents read
A lesson from an incident becomes a line in the instruction file, a test or an eval, so every future agent run inherits it. See the learn loop.
AIDLC, Agile and DevOps
With Agile and Scrum
AIDLC does not replace sprints or boards. The phases run per ticket inside them: refinement produces the ticket contract, the sprint plans around review capacity rather than authoring capacity, and the retrospective feeds the learn loop. Details on Scrum and Kanban.
With DevOps
Launch and Curate extend DevOps practice rather than replace it. CI/CD, progressive delivery and observability stay; AIDLC adds agent identities, hard rules in the pipeline and a learn loop. Details on Agents in the Pipeline.
Common Misconceptions
| Misconception | What AIDLC actually says |
|---|---|
| "AI writes everything, people just watch." | Agents draft; people decide. Every approval in the cycle belongs to a named person. |
| "It is waterfall with new names." | Phases are the state of a piece of work, not calendar stages; a team has work in all five at once. See How the Phases Connect. |
| "Testing happens in Launch." | Tests are written in Develop, before the code. Launch verifies the integrated release and writes a test only when it finds a gap. |
| "You need a particular AI vendor." | It is model-agnostic: Claude, ChatGPT, Gemini, Claude Code, Codex, Copilot, Cursor or an in-house engine. |
| "It replaces our process framework." | It runs inside Scrum, Kanban and DevOps and changes where the bottleneck sits. |
| "It is the same as AWS AI-DLC." | Same acronym, different framework. See AIDLC vs AWS AI-DLC. |
Frequently Asked Questions
The SDLC was built around the cost of people writing code; AIDLC is built around the cost of people verifying code that agents write. The stages map closely - requirements to Analyze, design to Ideate, implementation to Develop, deployment to Launch, maintenance to Curate - but tests move before the code, documents become contracts agents read, review scales by risk, and incidents produce rules the agents follow.
No. AIDLC runs inside Scrum, Kanban and DevOps. Refinement produces the ticket contract, sprints plan around review capacity rather than authoring capacity, and retrospectives feed the learn loop. What changes is where the bottleneck sits, not the framework you use to manage the work.
The discipline is not; its human-only assumptions are. Requirements, design, review, release management and maintenance all survive in AIDLC. What no longer holds is the idea that writing code is the slow, expensive step that the whole process should be organized around.
See the Phases in Action
Follow one feature from request to production, then see how the phases hand off to each other.