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 s 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 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.

PUT /stages/:id/output endpoint, allowing the entire process to function even without AI configuration.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. This warrants a separate section: implementing the AWS methodology entailed deliberate and documented deviations from it.

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.

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:

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.

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?