SDLC vs AI-DLC: do AI agents really need a new development lifecycle?

There's an infographic going around LinkedIn called "From SDLC to ADLC", made by Rakesh Gohel. Two loops side by side, six boxes in each. On the left, the classic lifecycle: requirements, design, build, QA, release, monitoring, with humans handing work from stage to stage. On the right, the agentic version: written intent, specs, agents building, continuous evals, production signals feeding new work back in. It's a clean summary of where things are heading. I've also been working that way for a while now, and I'm not sure it needs a new name. Put the two loops next to each other and match the boxes, and you get this:

Three acronyms, one idea

First, some cleanup, because the naming is already a mess.

• AI-DLC is the AWS one. Raja SP introduced the AI-Driven Development Life Cycle on the AWS DevOps blog in July 2025. AI proposes plans, asks clarifying questions, and implements after a human validates. Three phases: Inception, Construction, Operations.
• ADLC in the infographic means Agentic Development Lifecycle: agents doing the building, chained together by markdown artifacts.
• ADLC at IBM and Salesforce means Agent Development Lifecycle, which is about building and operating agents as a product. Different thing entirely. Same letters.

This post is about the first two, since they describe the same move: let agents do most of the work, and use written artifacts instead of meetings to hand work between steps.

What AWS actually proposes

The original AI-DLC post renames a lot of Agile. Sprints become bolts, measured in hours or days. Epics become Units of Work. Requirements get worked out in Mob Elaboration, where the whole team sits with the AI while it turns business intent into stories. Then Mob Construction, where the AI proposes architecture, domain model, code and tests while the team reacts in real time.

The interesting part is what happened next. In November 2025 AWS open-sourced the workflow and listed the problems they'd run into with the first version. Rigid workflows that pushed every project through the same sequence. Fixed depth, so small tasks got over-engineered. And, my favorite, automation drifting toward "passive execution" that weakened developer judgment. In other words: the new lifecycle had the old lifecycle's problems, plus a new one.

Today aidlc-workflows is at version 2.10. The README lists 5 phases, 33 stages, 14 agents, 11 workflow profiles and a 113-event audit trail. You install it with a shell script and start it by typing /aidlc inside Claude Code, Kiro, Codex, Cursor, opencode or Copilot.

The methodology that was supposed to replace process ceremony ships with 33 stages. The Scrum Guide has 5 events.

To be fair, it's adaptive and a bug fix won't walk through all 33. But notice where it runs. Not in Jira, not in a process handbook. Inside the coding agent, as a slash command. That detail answers most of the question in the title.

Your agent already does most of the agentic loop

The infographic sums up the agentic way in six steps: plan, design, build, test, deploy, maintain. Map each one to tools you can install today.

• Plan: "the originator writes intent.md". Kiro generates requirements.md, design.md and tasks.md per feature. GitHub's Spec Kit produces spec.md, plan.md and tasks.md, plus a constitution.md for project-wide rules. Claude Code has plan mode. The intent file exists, it just has three competing names.
• Design: "requirements and design collapse into one session". That's every plan mode session where the agent reads the code, asks you four questions, and proposes an approach before touching anything.
• Build: "institutional knowledge becomes CLAUDE.md, guardrails run as hooks". The infographic literally names the Claude Code feature. Kiro calls them steering files, Cursor calls them rules, Copilot has instruction files.
• Test: "every session verifies its own work first". Agents run the test suite and the linter before saying they're done. Most of them, most of the time.
• Deploy: "agentic review with executable governance". AI code review on pull requests plus required CI checks and branch protection. Exists, widely used.
• Maintain: "a production alert writes a new intent.md". This is the only step that's mostly not standard yet. Hold that thought.

So five out of six are features, not a lifecycle. The tools got there first and the diagrams came afterwards to describe them. That's not a criticism of the tools, it's a criticism of selling a feature list as a paradigm shift.

What doesn't hold up

The SDLC side is a strawman. "Linear. Human handoffs. Slow by design." That's waterfall, and it's been the villain of every conference talk since 2001. Most teams I've worked with ship through CI/CD, trunk-based or close to it, several times a week. Also the "linear" SDLC is drawn as a loop. As the diagram above shows, both sides have six steps in a loop. The agentic side renamed them.

Self-verification is self-grading. "Every session verifies its own work" sounds great until you remember the tests were written by the same model, from the same misunderstanding of the requirement, in the same context window. If the agent thought "archive" meant "delete", it will write a passing test that confirms the record is gone. Green checkmarks, wrong feature. Verification has to come from something that didn't write the code: a human, a separately written acceptance test, a different model with only the spec, or production data.

"Human judgment reserved for critical code." Who decides what's critical? In practice, whoever (or whatever) is classifying the diff. And the incidents I remember best did not come from code anyone flagged as critical. They came from a config default, a retry loop, a "harmless" migration. Criticality is usually obvious in hindsight.

"No human starts it." This is the Maintain step: a production alert writes an intent file and the loop runs again on its own. I get the appeal. But deciding which alert deserves a code change is prioritization, and prioritization is the actual hard part of maintaining software. Half of alerts should change a threshold, not the code. An autonomous loop where the system that caused the incident writes the fix, tests the fix and reviews the fix has exactly zero independent eyes in it. I'd want a human in that loop for a long time, and not as a rubber stamp.

Markdown is not an audit trail. "The chain of commits becomes the audit trail" will make anyone who has sat through a real audit wince a little. An audit trail needs to show who approved what, when, under which identity, and that nobody edited it afterwards. A plan.md generated by an agent and approved with a click in a terminal is a useful record. It's not evidence on its own. Signed commits, protected branches and PR approvals tied to real people get you closer. AWS's 113-event audit trail is a better attempt, but it's still logging what the workflow did, not proving a human understood it.

"No committees." Committees are slow, sure. They also exist because someone in the room knows the payment provider changes its API in March. Collapsing requirements and design into one session with an agent is fast precisely because you've removed the people who would have disagreed. Sometimes that's fine. Sometimes that's the bug.

And the boring one: process doesn't fix organisations. Google's DORA 2025 report found around 90% of developers using AI, and described it as an amplifier. It makes good teams better and makes struggling teams struggle faster. Read the team profiles closely, as Rob Bowley did, and only two of the seven get more throughput without hurting stability. A new acronym on top of a team with no tests and unclear ownership just produces unclear code quicker.

What does make sense

I don't want to be the person who only throws cold water, because some of this is genuinely the right direction.

• Write the intent down before the agent starts. This is the biggest win and costs ten minutes. An agent with a clear goal, constraints and a definition of done behaves completely differently from one that got "add export to the dashboard".
• Keep specs next to the code, versioned. When the spec lives in the repo, it's reviewable in the same PR as the change. When it lives in Confluence, it's dead by Thursday.
• Put tribal knowledge in a file the agent reads. CLAUDE.md, steering files, whatever. "We use pnpm, never touch the migrations folder by hand, the staging DB is shared" is exactly the stuff new humans also need.
• Hooks, not habits. This one line from the infographic is the best idea in it. A prompt that says "please don't commit secrets" is a suggestion. A pre-commit hook that blocks it is a guarantee. Anything you actually care about should be deterministic code that runs whether or not the model was paying attention.
• Explicit approval gates. AWS's own fix for "passive execution" was hard stops where the agent waits for a human decision. Correct. The trick is having few enough of them that people still read what they approve.
• Evals that keep running. If your product includes model behavior, treat evals like tests: in CI, versioned, failing the build when they regress.

None of this needs a new lifecycle. It needs a repo with a spec folder, a rules file, a few hooks, branch protection and a habit of reading diffs.

What I'd actually set up

For a small team or a solo developer, this covers about 90% of what the agentic loop promises:

repo/
├── CLAUDE.md              # conventions, commands, things never to touch
├── specs/
│   └── 2026-10-export/
│       ├── intent.md      # written by a human: goal, constraints, done means...
│       └── plan.md        # written by the agent, approved before code
├── .claude/settings.json  # hooks: format, lint, secret scan, block force push
└── .github/workflows/     # tests + evals, required to merge

Human writes intent. Agent plans in plan mode, human reads and approves the plan. Agent builds and runs tests. A separate pass reviews against the spec, not against the code. Human merges. Production signal goes to a human, who decides whether it becomes a new intent.

Is the full AI-DLC worth it? For a larger org that wants every team doing it the same way, with an audit story, it might be. It's free, MIT-0 licensed, and runs in the tools people already use. For a three-person team shipping a SaaS product, 33 stages is a lot of ceremony to adopt in the name of getting rid of ceremony.

Where this is going

My honest guess: in two years nobody says ADLC, the same way nobody says "DevOps lifecycle" anymore. It just becomes how software gets built.

The lifecycle is moving out of process documents and into harness configuration. Rules files, hooks, skills, CI gates. AI-DLC being installed as a slash command is the clearest sign of that. The methodology is now a plugin.

I also expect the explicit stages to shrink. Every model generation absorbs more of the scaffolding we bolt around it. A year ago you needed a prompt template to make an agent plan before coding; now plan mode is a toggle. The 33 stages are mostly there to compensate for what current models forget or skip, and that list gets shorter.

What won't shrink is the human part, it just moves. Less typing, more deciding. Owning the intent, judging whether the plan is right, and reviewing work you didn't write, which is harder and more tiring than writing it. The bottleneck is no longer producing code. It's verifying code. Any "new lifecycle" that doesn't put most of its energy there is a nicer diagram of the same old problems.

So, is it needed? The practices, yes, most of them. The new loop and the new acronym, no. Your agent already ships with the loop. Spend the time on the hooks.