AI Development Lifecycle (AIDLC)
An AI SDLC needs clear requirements, control over agent work, and evidence that the result meets the brief. AIDLC is driftless's term for the practical operating cycle of Cascades.
AIDLC stands for AI Development Lifecycle: the cycle a piece of work travels when agents do the building. A human directs. Agents shape the work into specifications. Gates validate the spec before anything builds. Agents ship. Verification proves the result against acceptance criteria that were written before the code existed. Every stage produces an artifact the next stage consumes, and a failure caught at one stage never flows downstream.
AI SDLC and agentic software delivery
This page covers using AI to deliver software: shaping requirements, executing scoped work, and verifying the result. An AI-assisted development lifecycle can include help with individual tasks; in driftless's agentic cycle, agents carry work through specifications and implementation while humans direct and accept the outcome.
If you are looking for an SDLC for AI models, that is a different scope: data preparation, model training, evaluation, deployment, and monitoring. Here the artifact being verified is the software change against its acceptance criteria.
Names differ between methods. AWS AI-DLC means AI-Driven Development Lifecycle and uses Inception, Construction, and Operations. Driftless uses AIDLC for the Cascades operating cycle below. These are distinct methods; the five stages here describe how driftless runs the work.
Direct
The human sets direction: what matters, what ships first, and the judgment calls that stay human (priorities, tradeoffs, risk acceptance). Direction is the one stage that never delegates.
An engineer or delivery lead. Agents take direction throughout the rest of the cycle; directing stays with the human.
Direction: what matters, ship order, and the judgment calls resolved (priorities, tradeoffs, risk acceptance).
Shape
A business analyst agent converts conviction into paired product and technical specs, decomposed into tasks with testable acceptance criteria and a mapped dependency graph.
The BA agent, working from the human's direction.
Paired product and technical specs, decomposed into tasks with testable acceptance criteria, plus a mapped dependency graph.
Gate
The spec is evaluated before any build starts: buildability, contradictions, coverage. A failed gate blocks execution until the spec is clean; blocking is the behavior, warning is not.
Spec gates: automated deterministic checks plus agent reasoning. No human review is required for the gate to run.
A gated-clean spec ready to build, or a blocked spec with specific findings pointing at the exact problem.
Ship
Persistent coding agents execute the gated tasks in parallel and post evidence to the task record as they work.
Coding agents, orchestrated against task directives. Humans monitor, the task record carries the status.
Shipped code with evidence attached to the task record.
Verify
The acceptance criteria written at shape time are tested against the shipped code. A human confirms done. Failures route back to the stage that caused them.
Automated verification first (acceptance criteria, CI gates, tests); a human confirms done last.
Verification results against the acceptance criteria written before the code existed. Failures route back to the stage that caused them.
What changes in practice
- The board is the plan: sequencing follows the dependency graph, not a calendar; work flows continuously with no sprint boundary to plan around.
- Status is written, not spoken: the task record is the decision log; anyone can read what happened and why without a meeting.
- Failure routes upstream and is contained where it is caught: a spec contradiction dies in the gate; a failing test never reaches done.
- Human time concentrates where it is irreplaceable, direction and verification; process maintenance moves into the software.
What a cycle produces
Each stage hands its artifact to the next, and the finished cycle leaves a chain you can read back:
- A gated-clean spec
- Tasks with locked acceptance criteria
- Shipped code with evidence attached
- Verification results
The audit trail exists because the platform writes it, not because someone kept notes.
How to adopt an AI-assisted development lifecycle
Start with one initiative. Direct the first cycle yourself. Read the artifacts the agents produce. Scale what the artifacts prove.
Choose a bounded change with an observable outcome. Agree on acceptance criteria, permitted tools and data, and the person who will verify it. Keep your existing review, CI, and release requirements in place. Compare the accepted result, review and rework effort, and tool and model costs with a baseline from comparable work before expanding.
For a concrete view of the specification handoff, see how driftless plans work and checks specs.
AI development lifecycle FAQ
How does an AI SDLC differ from a traditional SDLC?
Requirements, design, implementation, testing, and maintenance still need owners. AI assistance changes how work gets done; agentic delivery delegates multi-step execution as well. In driftless, Direct sets priorities, Shape produces specs and acceptance criteria, Gate checks the spec before execution, Ship implements the work, and Verify tests the result. Your team's code review, CI, security checks, and release policies still apply.
How do you verify AI-generated code?
Write testable acceptance criteria before implementation. Review the diff and test the intended behavior, including failure cases, rather than relying on the agent's summary or generated tests alone. In Cascades, Gate checks specification readiness before code is built; Verify checks the shipped result against those criteria. Agents attach evidence to the task, failures return to the stage that caused them, and a human confirms done. A passing build alone does not complete the task.
Where does human oversight belong in agentic software delivery?
Humans own direction, priorities, tradeoffs, risk acceptance, and the final decision that the work meets the brief. Agents shape specifications and execute gated tasks. A failed spec gate blocks execution until its findings are resolved. Decide which tools, data, and actions an agent may use before delegating work; enforce those permissions in the systems it reaches. Read how driftless handles human approval.
What security controls should a team evaluate for AI coding agents?
Check repository and tool permissions, credential handling, what context reaches model providers, and which actions require approval. Treat repository text and tool output as untrusted input, review changes to dependencies and CI configuration, and run security checks on generated changes. Spec gates check the work's specification; they do not replace code security review. Review driftless's access controls and execution boundaries against your own policies.
What evidence supports audit and compliance review?
The Cascades cycle connects product and technical specs, tasks with locked acceptance criteria, shipped code, and verification evidence. The task record preserves decisions and progress so a reviewer can follow why the work happened and how it was checked. Review the documented audit trails for activity attribution and retention scope. Your organization must assess those records and controls against its obligations; a delivery workflow alone does not establish compliance.
How should we measure AI development productivity and cost?
Start with one bounded initiative and a baseline from comparable work. Track accepted outcomes, elapsed delivery time, human review and rework, defects found during verification, and tool and model spend. Include the effort needed to correct and operate the result. Use those observations to decide whether to expand adoption. This is a pilot evaluation plan, not a promised productivity gain or an automatic measurement feature.
Where the two pages fit
Cascades is the methodology. AIDLC is how you run it. The Cascades page covers the methodology at full depth: why each gate exists and what each phase produces.