AI-DLC stands for the AI Development Life Cycle, which AWS expands as the AI-Driven Development Life Cycle. Both names point at one idea, whether written AIDLC, AI-DLC or AI DLC. It is a software life cycle where agents write most of the code and a senior engineer answers for all of it. The eight phases below are how I run it.
AIArtificial intelligence
Agents read the spec, write files, run tools and propose a whole slice at a time, not one autocompleted line.
DDevelopment
This is a build method, not a research programme. Every phase ends in something you can read, run or ship.
LCLife cycle
Six phases run once, from framed problem to hardened build. Two run forever and re-test every production change.
AIDLC at a glance
Full form
AI Development Life Cycle
AWS expansion
AI-Driven Development Life Cycle (same acronym, same idea)
Six run once on a first build, two run as a production loop
Merge gate
Senior review plus passing evals, automated tests of agent output
Accountable
A named engineer, never the model
Runs on
Claude, GPT, Gemini, or open weights like Llama and Mistral
Sits inside
The Construction phase of SpecForge
Operating principles
What holds the lifecycle together?
Four principles run underneath all eight phases. They keep agentic speed from turning into agentic chaos.
01 / Spec first
Specs are the source of truth
Every phase produces an artifact an agent can act on without guessing. Open questions close before code, not in review.
02 / Evals as the gate
Evals guard every change
Golden datasets, test cases with known right answers, run on every change. Agent speed never costs you correctness.
03 / Human in the loop
Senior review on every diff
A named senior engineer answers for every diff the agents write. People set the limits and the harness enforces them.
04 / Production from day one
Observability is not optional
Traces, costs and the success metric sit on a dashboard from slice one. Nothing ships that you cannot watch.
The whole thing at once
What do the AI-DLC diagrams show?
The first diagram shows the eight phases, the handoffs between them, and the eval gate. The second zooms into Generate, where agent work and human accountability split.
Diagram 1 · The eight phases and the artifacts between them
Loading diagram…
Frame hands Spec a one-page scope. Spec hands Scaffold the acceptance criteria. Scaffold hands Generate a typed skeleton with CI already green on an essentially empty repo. Every diff out of Generate meets Eval, the one gate in the method. Eval passes it to Harden or returns it to Generate with the failing trace attached. Harden proves the guardrails and releases to Ship, Ship instruments the rollout by cohort, and Operate turns live traces into the next backlog. The marker at the bottom is the part that makes this a life cycle rather than a checklist. Every production change from then on re-enters at Eval, so no shipped change routes around the gate.
Diagram 2 · Inside the Generate loop
Loading diagram…
The spec issues acceptance criteria for one slice. The agent opens a diff. The eval harness runs the golden set and then the judge suite, and a failure goes back to the agent with the cases that broke. Only a green suite reaches the senior engineer. The engineer reads the reasoning rather than skimming the output, then merges or pushes the ambiguity back into the spec. The model never approves its own work, which is the single line that separates this from vibe coding.
The eight phases
What are the eight AIDLC phases?
Each phase has one job, one owner and one exit condition. No phase ships without the one before it.
Phase 01 of 8
Frame
Pin down the problem before a line of code exists. We agree on the user, the constraint, and the single metric that proves the system is earning its keep. The output is a one-page scope, not a proposal deck.
One-page problem scope
Success metric agreed in writing
Constraints and non-goals
Who leads
You and a senior engineer. No agent is in the room yet.
Exit gate
Both sides write down one metric and can state it from memory.
If skipped
You ship something that works and still gets cancelled, because nobody can say what it improved.
Phase 02 of 8
Spec
Turn the frame into an executable specification. Agent roles, tool boundaries, data contracts, and acceptance criteria written so both a human and a coding agent can act on them without guessing.
Executable spec
Agent role and tool inventory
Acceptance criteria
Who leads
A human authors it. An agent drafts sections and argues back where the spec is thin.
Exit gate
A coding agent restates the acceptance criteria without asking a clarifying question.
If skipped
A vague requirement used to buy you one wrong function. Under agents it buys a thousand lines of confidently wrong code.
Phase 03 of 8
Scaffold
Stand up the skeleton. Repo conventions, type contracts, the eval harness, and the smallest runnable surface. Agents work best inside a structure that already enforces the rules, so we build that structure first.
Typed scaffold and conventions
Eval harness wired in
First runnable slice
Who leads
A senior engineer sets the boundaries. The agent fills the skeleton inside them.
Exit gate
CI runs the eval harness against an essentially empty repo and reports green.
If skipped
Retro-fitting evals after generation means grading code you already shipped, and the first failing case is a support ticket.
Phase 04 of 8
Generate
Agents write the bulk of the code against the spec, supervised by senior review on every diff. Two-week vertical slices, demoable each Friday. Velocity comes from the agents; correctness comes from the harness and the reviewer.
Working vertical slices
Reviewed diffs
Friday demos
Who leads
The agent leads. A named engineer reviews every diff and carries the accountability.
Exit gate
A vertical slice runs end to end and survives a live demo, not a screenshot.
If skipped
Unreviewed generation compounds. A wrong abstraction gets built on within hours, and unwinding it costs more than the slice did.
Phase 05 of 8
Eval
Golden datasets and LLM-as-judge suites guard behaviour on every change. We test the agent's decisions, not just its output, so regressions surface before they reach users.
Golden datasets
Regression-gated CI
Trace-driven backlog
Who leads
QA and engineering author the sets. CI runs them on every diff, with no manual override.
Exit gate
The suite fails when behaviour regresses, proven by deliberately regressing it once.
If skipped
Velocity without a gate is just faster regressions. You find out from a user, at the worst possible moment.
Phase 06 of 8
Harden
Close the gaps that only appear under real load. Prompt-injection defenses, PII redaction, rate limits, fallbacks, and audit logs. Self-hosted models when residency rules like PDPL or DIFC demand it.
Guardrails and redaction
Audit logging
Residency-compliant deployment
Who leads
Security and platform lead. The agent implements against a written checklist.
Exit gate
Injection, redaction, rate-limit, and fallback cases each have a test that failed before the fix and passes after.
If skipped
Prompt injection is not a bug you patch after launch. It is a property of the design, and retrofitting it means rewriting the tool boundary.
Phase 07 of 8
Ship
Release behind a flag, instrument the loop, and roll out by cohort. Costs land on a dashboard from day one. Nothing reaches production unless the eval suite and monitoring can watch it.
Flagged rollout
Cost and latency dashboards
Production observability
Who leads
Platform and SRE run the rollout. Product owns which cohort goes next.
Exit gate
Cost per request, latency, and the Frame metric all sit on one dashboard before the flag opens.
If skipped
An autonomous system you cannot watch is an incident waiting for a customer to report it on your behalf.
Phase 08 of 8
Operate
The system improves in production. Evals run on every change, traces feed the backlog, and the metric stays on a dashboard. The owning team takes handover with runbooks.
Runbooks and handover
Continuous eval loop
Operating cadence
Who leads
The owning team, working from the runbooks.
Exit gate
Traces feed the backlog on a fixed cadence and every change routes back through Eval.
If skipped
A model version bump or a provider change moves behaviour silently. Only a live eval loop catches it before your users do.
Calendar, not theory
What happens each week in AI-DLC?
Eight phases sound heavy until you see them on a calendar. Here is a first build, from the opening session to a system in production.
Week 1
Phase 01 · 02
Frame and Spec
Two working sessions and a written spec. You leave the week with a one-page scope, an agreed success metric, and acceptance criteria precise enough that a coding agent can act on them. Agents have written nothing yet, by design.
Week 2
Phase 03
Scaffold
Repo conventions, type contracts, and the eval harness go in before feature code. By Friday, CI runs the harness on a near-empty repo and reports green. The structure now enforces the rules, so the agent inherits them instead of having to remember them.
Weeks 3 to 4
Phase 04 · 05
First vertical slice
Agents generate against the spec, every diff gets senior review, and the eval suite gates the merge. The slice runs end to end and demos live on the Friday of week four. This is the first point where you can judge the work rather than the plan.
Week 5 onward
Phase 04 · 05 · 06 · 07
Slices, hardening, and a flagged release
Build settles into two-week slices with a Friday demo closing each one. Hardening runs alongside from the first slice that touches user data. The first flagged release goes to an internal cohort long before it reaches customers. You decide whether to extend after every slice, with no annual lock-in.
Ongoing
Phase 08
Operate
Evals run on every change, traces feed the backlog, and the Frame metric stays on a dashboard. The owning team takes handover with runbooks and the eval suite.
What changed
How is AI-DLC different from the traditional SDLC?
The traditional SDLC (software development life cycle) weights design and implementation, because human hours go there. Agents move the bottleneck, so specification and verification become the expensive part.
Who writes the code
Traditional SDLC
Humans write nearly all of it
AI-DLC
Agents write the bulk of it against a spec
Where the effort lands
Traditional SDLC
Design and implementation
AI-DLC
Specification and verification
Cost of a vague requirement
Traditional SDLC
One wrong function, caught in review
AI-DLC
A thousand lines of confidently wrong code, caught by an eval
What gates a merge
Traditional SDLC
Code review and a unit suite
AI-DLC
Code review, a unit suite, and a behavioural eval suite
When tests get written
Traditional SDLC
Alongside or after the feature
AI-DLC
Before any feature code exists, during Scaffold
What gets tested
Traditional SDLC
Outputs against fixed inputs
AI-DLC
Decisions and reasoning, graded on golden sets and by a judge model
What done means
Traditional SDLC
The feature works
AI-DLC
The feature works and a suite proves it still will next week
Who is accountable
Traditional SDLC
The engineer who wrote it
AI-DLC
The engineer who reviewed it, by name, on the diff
What launch changes
Traditional SDLC
Development slows, maintenance starts
AI-DLC
Nothing. Production is another turn of the same loop
Answers for operators and engineers weighing how AIDLC runs.
What does AIDLC stand for?
AIDLC stands for the AI Development Life Cycle, also written AI-DLC, which AWS expands as the AI-Driven Development Life Cycle. It is an eight-phase method for building software where agents do the heavy lifting and senior engineers keep them in bounds. The phases are Frame, Spec, Scaffold, Generate, Eval, Harden, Ship, and Operate. The first six run once, from framed problem to hardened build. The last two loop in production, sending every change back through evals.
What is the AIDLC full form?
The AIDLC full form is AI Development Life Cycle, and AWS expands it as AI-Driven Development Life Cycle. Both are also written AI-DLC or AI DLC. Every spelling means a software lifecycle that assumes agents generate most of the code. Human effort goes into framing intent, writing the specification, and verifying output against evals.
Is AIDLC the same as AI-DLC?
Yes. AIDLC, AI-DLC, and AI DLC are three spellings of the same term, the AI Development Life Cycle. AWS expands it as the AI-Driven Development Life Cycle, a lifecycle of Inception, Construction, and Operations that governs a whole engagement. The eight-phase AIDLC described here is the build engine that runs inside Construction, so the two compose rather than compete. SpecForge is where they run together.
How is AIDLC different from the traditional SDLC?
AIDLC assumes agents write most of the code, while the traditional SDLC assumes humans do. So AIDLC front-loads the work that makes agents effective. That means a precise spec, a scaffold that enforces conventions, and an eval harness that catches regressions on every diff. Familiar phases like Ship and Operate carry extra weight, because an autonomous system needs monitoring that humans would otherwise provide.
Do agents really write most of the code?
Yes, agents write most of the code on a well-specified slice. But every diff goes through senior review, and nothing merges without passing the eval suite. The speed comes from the agents while the accountability stays with a person. That split is the whole point of the lifecycle.
Where do evals fit, and why so early?
Evals go in during Scaffold, before any feature code exists, so they gate every change from the first slice onward. Golden datasets and LLM-as-judge suites test the agent's decisions, not just its output. Catching a behavioural regression in CI is cheap; catching it from a user is not.
Can AIDLC run on a private or on-premise LLM?
Yes. The Harden phase covers self-hosted models when residency laws, such as UAE PDPL or DIFC rules, forbid hosted ones. The lifecycle is model-agnostic and runs on Claude, GPT, Gemini, or open weights like Llama and Mistral. The deployment target is a choice made on constraints, not a rewrite.
How long does a first pass through AIDLC take?
A first pass reaches a live demo in week four. Frame and Spec take the first week. After that, build runs in two-week vertical slices with a Friday demo. You decide whether to extend after each slice, with no annual lock-in.
What happens after the build is done?
The Operate phase keeps the system improving in production. Evals run on every change, traces feed the backlog, and the success metric stays on a dashboard. The team that owns the system takes handover with runbooks and eval suites.
What tools does AIDLC run on?
Claude Code carries most of the generation work, with skills, subagents, and hooks doing the enforcement. MCP servers connect the agents to real systems, and the eval harness runs in ordinary CI alongside the unit suite. None of that is load-bearing though. The lifecycle is tool-agnostic, so a team on Cursor, Codex, or a homegrown harness runs the same eight phases with the same gates.
Can a small team run AIDLC, or does it need a department?
Two people can run it. One person owns the spec and reviews every diff, the agents do the generation, and CI runs the eval suite. Most of the overhead sits in Frame, Spec, and Scaffold, which take two weeks, once. After that the process is lighter than a traditional sprint, because the reviewer is reading diffs instead of writing them.
How does AIDLC change each role on the team?
Every job shifts from producing artifacts to specifying and verifying them. The product manager writes specs an agent can act on rather than tickets. The architect designs boundaries agents cannot cross. QA designs evals instead of writing test cases by hand. DevOps builds observability for autonomy rather than pipelines for humans. One post per role covers the change in detail, linked in the further reading above.
What is the most common way AIDLC fails?
Skipping Scaffold. Teams get excited by generation speed, start with Generate, and promise themselves they will add evals later. By the time they do, they are grading code that already shipped. The first failing case arrives as a support ticket instead of a red build. Wire the eval harness in before any feature code exists, and every phase after it gets cheaper.
Method last reviewed . Pooya Golchian runs this lifecycle on real builds and updates this page when the method changes, not on a schedule.
Try it
Run the methodon your nextbuild
SpecForge is this method as open source. It pairs GitHub Spec Kit with AWS AI-DLC governance, and a hook blocks edits until a human approves the spec and plan.
