AIDLC, a lifecycle for building software the agentic way.
AIDLC stands for the AI Development Life Cycle, also written AI-DLC. It is an eight-phase method for building software the agentic way, taking an idea from a framed problem to an operated, eval-guarded system, with agents doing the heavy lifting and senior engineering keeping them inside the boundary.
AI-DLC stands for the AI Development Life Cycle, which AWS expands as the AI-Driven Development Life Cycle. Written AIDLC, AI-DLC, or AI DLC, both names point at the same idea, a life cycle for building software in the case where agents write most of the code and a senior engineer stays accountable for all of it. The eight phases below are how I run it on client work.
AIArtificial intelligence
Agents do the generation. Not autocomplete and not a faster junior developer, but a system that reads the spec, writes files, runs the tools, and proposes a whole slice at a time.
DDevelopment
This is a build method, not a research programme. Every phase ends in an artifact somebody can read, run, or ship, and the phase is not done until that artifact exists.
LCLife cycle
It does not stop at launch. Six phases run once to take a framed problem into a hardened build, and two run forever, feeding every production change back through the eval suite.
AIDLC at a glance
Full form
AI Development Life Cycle
AWS expansion
AI-Driven Development Life Cycle (same acronym, same method)
Six run once on a first build, two run as a production loop
Merge gate
Senior review on the diff plus a green eval suite
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 are what keep agentic speed from turning into agentic chaos.
01 / Spec first
Specs are the source of truth
Agents are only as good as what you point them at. Every phase produces an artifact a coding agent can act on without guessing. Ambiguity is resolved before generation, not during review.
02 / Evals as the gate
Evals guard every change
Velocity without a safety net is just faster regressions. Golden datasets and LLM-as-judge suites run on every diff, so the speed agents bring never trades against correctness.
03 / Human in the loop
Senior review on every diff
Agents generate; a senior engineer is accountable. The boundary is defined by people, enforced by the harness, and never left to the model to police on its own.
04 / Production from day one
Observability is not optional
Traces, costs, and the success metric sit on a dashboard from the first slice. If you cannot watch it, it does not ship. Handover later is a config change, not a rewrite.
The shape of the work
What does the AIDLC pipeline look like?
The first six phases run once to take a framed problem into a hardened build. The last two run as a loop, so every change in production passes back through evals before it ships.
AIDLC pipeline. Frame, Spec, Scaffold, Generate, Eval, and Harden run in sequence on a first build. Ship and Operate run as a continuous loop in production, feeding changes back through evals before they ship.
Two views. The first shows all eight phases with the artifact each one hands to the next, and the eval gate that every change has to clear. The second zooms into the Generate loop, where the split between what an agent does and what a person is accountable for actually lives.
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, which either passes it down 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 that point on re-enters at Eval, so the gate is never something a change gets to route around once it has shipped.
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, who reads the reasoning rather than skimming the output, then either merges or pushes the ambiguity back into the spec where it belongs. The model never approves its own work, which is the single line that separates this from vibe coding.
The eight phases
How does AI-DLC move from idea to operated system?
Each phase has one job, one owner, and one condition that lets the work leave it. Phases run in sequence on a first build and as a loop in production. 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
One metric is written down and both sides 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
Behaviour is guarded by golden datasets and LLM-as-judge suites that run 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. Private LLM deployment when residency, PDPL, or DIFC compliance 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 goes to production that the eval suite and the observability surface cannot watch.
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. Handover to your team with runbooks, or a monthly retainer if you want us to keep operating it.
Runbooks and handover
Continuous eval loop
Operating cadence
Who leads
Your team, working from the runbooks. Or ours on a monthly retainer.
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 does a first pass through AI-DLC actually look like?
Eight phases sound heavy until you see them on a calendar. Here is the shape of a typical first engagement, from the opening session to a system running 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. Nothing has been generated yet, and that is deliberate.
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 rather than being asked 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, and there is 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. Take handover with runbooks and the eval suite, or keep the studio on a monthly retainer. Both use the same observability surface, so switching later is a config change rather than a migration.
What actually changed
How is AI-DLC different from the traditional SDLC?
The traditional SDLC puts its weight on design and implementation, because that is where human hours go. Agents move the bottleneck. Implementation gets cheap, specification and verification get expensive, and the process has to change shape to match.
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 written for operators and engineers evaluating how AIDLC actually runs.
What does AIDLC stand for?
AIDLC stands for the AI Development Life Cycle, also written AI-DLC. It is an eight-phase method for building software where agents do the heavy lifting and senior engineering keeps them inside a defined boundary. The phases are Frame, Spec, Scaffold, Generate, Eval, Harden, Ship, and Operate. The first six run once to take a framed problem into a hardened build, and the last two run as a production loop that feeds every change back through evals.
What is the AIDLC full form?
The AIDLC full form is AI Development Life Cycle. It is sometimes expanded as AI-Driven Development Life Cycle and written AI-DLC or AI DLC. All spellings refer to the same thing: a software lifecycle built on the assumption that agents generate most of the code, so human effort concentrates on 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. Worth knowing that AWS also publishes a lifecycle called AI-DLC, which runs Inception, Construction, and Operations and 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?
The traditional SDLC assumes humans write most of the code. AIDLC assumes agents do, so it 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. The phases that look familiar like ship and operate carry extra weight because an autonomous system needs observability humans would otherwise provide implicitly.
Do agents really write most of the code?
On a well-specified slice, yes, the bulk of generation is agent-driven. 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?
The eval harness is wired in during Scaffold, before any feature code exists, so it can 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 private LLM deployment for cases where data residency, PDPL, or DIFC compliance rule out hosted models. The lifecycle is model-agnostic and runs on Claude, GPT, Gemini, or open-weights like Llama and Mistral, so the deployment target is a choice made on constraints, not a rewrite.
How long does a first pass through AIDLC take?
Frame and Spec take roughly a week. The first demoable slice ships inside two weeks of Generate. After that, build runs in two-week vertical slices with a Friday demo. You decide whether to extend after each slice. There is 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. You can take handover with runbooks and eval suites, or keep us on a monthly retainer to operate it. Both use the same observability surface, so switching later is a config change.
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. The overhead that looks heavy on paper is mostly front-loaded into Frame, Spec, and Scaffold, which takes about 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. There is one post per role covering 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, and 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 client engagements and updates this page when the method changes, not on a schedule.
Work with the studio
Bring the methodto your nextbuild.
Send a one-paragraph brief on what you want built. You will get a written reply within twenty-four hours, with an honest read on how AIDLC would run on it.
Weekly field notes on private AI, automation, and high-performance Next.js builds. Each edition is concise, implementation-ready, and tested in production work.