The SDLC is dead. Long live the AI-DLC!?

AI-DLC vs SDLC: What I Kept, What I Changed

Progress never stands still; it is constantly evolving, bringing changes to our daily work. Today, I want to describe the changes that have taken place in my own workflows. For years, we relied on the SDLC (Software Development Life Cycle) approach; now, it is time to adopt the AI-DLC approach.

The first question is: what exactly is AI-DLC? AI-DLC does not replace the traditional SDLC; instead, it shifts task execution from humans to AI while retaining the human role of approving the results.

I incorporated the AWS-developed AI-DLC system into my own task-planning application—treating it as a core product feature rather than just a personal coding workflow. (After all, every self-respecting programmer should have their own to-do app😂)
You articulate an "Intent" in your own words; this is broken down into "Units"—large, epic-level tasks with defined acceptance criteria and dependencies. These units are then executed via "Bolts"—execution cycles lasting anywhere from a few hours to several days. At various points throughout the process, execution pauses to await human approval, and a clear history of changes (artifacts) is preserved in the target repository.

For those considering whether to adopt this approach, the most interesting aspect isn't its novelty. What matters is how much of the traditional SDLC remains virtually unchanged, despite the shift to this new model of task execution.

The 16 stages are the old SDLC phases, renamed

The catalog runs three phases — Inception → Construction (per unit) → Operations — across sixteen stages. Every one of them is a classic SDLC activity, just regrouped:

SDLC activity	AI-DLC stage(s)	Phase
Discovery / requirements gathering	Workspace Detection, Requirements Analysis, User Stories	Inception
Planning / estimation	Workflow Planning, Units Generation, Delivery Planning	Inception
System design	Application Design, Functional Design, Infrastructure Design	Inception / Construction
Non-functional requirements	NFR Requirements, NFR Design	Construction
Implementation	Code Generation Planning, Code Generation	Construction
Testing	Build and Test	Construction
Release	Deployment	Operations
Ops / observability	Monitoring	Operations

Nothing was dropped. What changed is who performs each stage and what gates the move to the next one.

What I retained from the SDLC

1. The sequence of stages itself. The "requirements → design → build → test → deploy → monitor" flow remains linear for each unit of work. AI-DLC did not invent a new lifecycle model but replicated the old one, substituting the human actors involved.
2. Human approval stages. Moving to the next stage still requires approval of the previous one (analogous to code reviews or checkpoints in traditional SDLC), but this is now enforced at the system architecture level rather than merely through procedural compliance: a stage launches only after all preceding stages in its scope are complete; a conditional write in DynamoDB prevents state conflicts during concurrent executions; and no runner process contains code to set the "approved" status—this is possible only via an HTTP request initiated by a human.
3. Process documentation. The results of each stage are mirrored in Markdown format (within the aidlc-docs/<intent-slug>/... directory of the target repository) alongside an audit.md file, which logs executions, approvals, change requests, and skipped stages. These are the same artifacts and audit logs always required in SDLC management—only now they are generated automatically rather than created manually.
4. Work decomposition structure. Units of work—complete with acceptance criteria and dependencies—serve as epics; "Bolts" function as sprints with a clear Definition of Done: a Bolt cannot be closed if even one of its constituent units of work has an unapproved mandatory stage.
5. Separation of concerns. Design and analysis stages operate in a read-only planning mode; file write permissions are granted exclusively to implementation stages (code_generation, build_and_test, deployment, monitoring). The design phase cannot silently refactor the repository while the document is being prepared—this is the same principle underlying the rule that "reviewers cannot merge their own pull requests."

What has actually changed

• Execution has shifted from humans to AI; the human role is now limited to approving results. In a classic SDLC, a human writes the requirements document. Here, however, stages such as ask-executor force an LLM tool call to generate the document, while the human's task is narrowed down to reviewing and either accepting or rejecting the output. There are two types of executors: claude (autonomous execution of Claude within a specific intent's workspace—for stages requiring repository read/write operations) and ask (forcing a tool call via a configured provider—for stages where the output must be displayed as a form, such as clarifying questions or a list of proposed work units). Stage output can also be entered manually via the PUT /stages/:id/output endpoint, allowing the entire process to function even without AI configuration.
• The lifecycle is initialized for each unit of work rather than once for the entire project. The stage catalog is data-driven: creating an "Intent" triggers its own "Inception" stages, while accepting a "Unit" launches its own "Construction" stages. Traditional SDLC phases are typically project-level rituals performed once; here, they are generated anew for each Intent and Unit. Furthermore, Units can be processed in parallel and independently, as a specific Unit's stages depend only on preceding stages within that same Unit.
• Two artifact stores instead of one. DynamoDB serves as the source of truth (authoritative store); this is necessary because the web application and an agent connected via MCP might write data simultaneously, and only a robust database supports conditional update operations. The Markdown files in the aidlc-docs/ directory constitute a read-only mirror that is updated after every transition. In a traditional SDLC, no such separation exists; the document itself serves as the record—the single source of truth.

Even the "implementation of AI-DLC" did not mean blindly following the specification.

This warrants a separate section: implementing the AWS methodology entailed deliberate and documented deviations from it.

Upstream AI-DLC	This implementation	Why
aidlc-state.md is the state	DynamoDB is authoritative; markdown is a mirror	Two writers (web app + MCP) plus conditional-update locking need a real store — a markdown file can't express a ConditionExpression
Every stage runs through the coding agent	Form-shaped stages run on the LLM provider directly (ask executor)	Keeps file-write authority away from stages that have no use for it
Mob Elaboration (synchronous group review)	Single-player: an editable unit list plus request-changes	This app has profiles, not accounts — the intent of the practice survives, the "whole team" part isn't modelled
33 stages across five phases	16 stages across three	The catalog is data, so growing it back is a data change, not new code
Implicit approval authority	approvedBy records who acted, not that they were allowed to	There's no authentication in this app, so approval is a record, not a claim

The point is not that these deviations suit everyone, but rather that "implementing AI-DLC" is not a binary process. Any team adopting a known methodology will adapt it to their system's actual capabilities; documenting these changes—rather than letting them devolve into imperceptible process "drift"—is, in itself, a valuable SDLC discipline.

A second layer of governance atop the first.

The AWS AI-DLC methodology provided me with stages, modules, and an approval checkpoint. It differs from Anthropic’s approach (the AI-native SDLC playbook), which outlines its own six-step model (Planning → Design → Development → Testing → Deployment → Support) based on three governance layers: Skills (advisory rules and policies), Hooks (deterministic runtime safeguards), and human approval stages. Comparing my implementation against this second model revealed gaps that the AWS specification alone did not address, and I resolved all four:

• Skills (Rules/Guidelines). Markdown-based policy files (e.g., security checklists or compliance rules) placed by the user in the target workspace; these are automatically attached as context to stages marked as relevant (nfr_design, infrastructure_design, deployment). They are purely advisory in nature, with a level of trust equal to that of any other context passed to the stage.
• Hooks. The AIDLC_POST_RUN_HOOK variable executes a custom shell command after the successful completion of the code_generation or build_and_test stages, but before the stage transitions to the awaiting_approval state. A non-zero exit code causes the stage to fail immediately—this serves as a deterministic counterpart to the advisory approach used by Skills and is the mechanism most similar to Claude Code hooks.
• AI-based verification extended to code-related stages. The previously existing optional verification step—formerly limited to the requirements or design phases—now also analyzes diffs during the code_generation stage and the results (success/failure) of the build_and_test stage. These checks are purely advisory and never block the process, thereby upholding the inviolable principle that "no executor can approve their own work."
• An evaluation suite. Tests located in apps/api/tests/*.eval.ts verify that stage prompts align with the intents defined in the test data (fixtures); this ensures that any changes to prompts or the directory structure—which might otherwise silently break Workspace Detection or Units Generation mechanisms—are caught during the CI phase rather than in production.

All these features are optional and disabled by default—including two that I developed but did not bring into full compliance with the specification: AIDLC_PARALLEL_WORKTREES assigns a separate Git worktree and branch to each unit to ensure complete build isolation, yet it intentionally omits the automatic merge step following approval that was envisioned in the original playbook design. Automatically merging a branch into the actual Git history is too critical an action to entrust to the stage runner without human oversight; Consequently, the branch remains available for the user to review and merge manually—reflecting the general principle that final approval always rests with a human. The POST /aidlc/alerts endpoint closes the operational loop by creating a draft standard Intent based on a monitoring system alert; however, there is no automatic approval or execution involved here either: the generated Intent enters the pipeline at the workspace detection stage alongside other Intents and undergoes the same validation checks.

Conclusion

When creating something similar, it is more useful to view the situation not as a clash between two lifecycle models—SDLC and AI-DLC—but from a different perspective. AI-DLC is essentially the same as SDLC, except that the execution vector is redirected toward AI, while the validation vector is intentionally retained by humans. Control is maintained through structural mechanisms (such as blocks, checkpoints, and access control systems) rather than team discipline; after all, discipline cannot be relied upon when the work between checkpoints is performed by an agent.

Everything else—stages, approval procedures, documentation, audit logs, and backlog structure—is carried over from the old model rather than reinvented. The methodology’s name changes, but the fundamental nature of the work remains largely the same.

Are there any among you who have fully switched to AI-DLC? What methodology do you use? Have you made any changes to the used AI-DLC specifications?