AI-DLC

Learning objectives

By the end of this module, you will be able to:

1. Explain why accelerating individual SDLC phases with AI hits a ceiling, and what AI-DLC changes structurally.
2. Name the three AI-DLC phases and describe what each one produces.
3. Run the Plan → Clarify → Approve → Execute loop that repeats inside every phase.
4. Map the traditional SDLC — and SPECTRA’s seven-phase agentic SDLC — onto the three AI-DLC phases, place idea assessment and bug fixing on that map, and say what actually changes at each boundary.
5. Use the AI-DLC vocabulary correctly — bolt, unit of work, mob elaboration, mob construction.
6. Say who is in the room at each phase, what those people own, and what AI does alongside them.
7. Translate all of it into concrete Spec Kit and SPECTRA commands, and run your first bolt.

1.Why the lifecycle itself has to change

Everything in this course so far has made one part of your work better. Modules 1 and 2 sharpened what a spec is. Modules 3 and 4 put the workflow into your hands. Modules 5 and 6 covered the work on either side of a feature — deciding whether to build it, and fixing what broke. Module 7 made the workflow your own, Module 8 covered what breaks, and Module 9 covered how the team splits the work.

But the lifecycle those improvements sit inside has not moved. The traditional SDLC — plan, design, implement, test, deploy, maintain — was designed to coordinate human execution at scale. Its phases, hand-offs, and documentation all exist to solve one problem: humans are the only engine that can turn intent into working software, and humans need to pass work to each other.

That assumption is the thing AI broke. When an agent can draft the requirements, the design, the code, and the tests, the question stops being “how do we organize human effort?” and becomes something much less comfortable:

How do we keep speed from turning into chaos?

Teams answering that question tend to land in one of two ditches.

Ditch one: AI-assisted SDLC

AI helps with isolated tasks. Generate this function. Summarize that ticket. Draft some tests. The lifecycle is untouched — same phases, same hand-offs, same documents. You get faster locally and the overall cadence barely moves, because the waiting was never in the typing. Drift and late discovery survive completely intact. This is the “faster typist” problem, and it is exactly what Module 1 opened with: the bottleneck has moved upstream.

Ditch two: AI-autonomous “build it all”

The opposite move: hand the agent a paragraph and expect a system. Output arrives fast. Alignment, traceability, and safety do not. You end up with something that runs and nobody can explain, which is worse than slow.

AI-DLC sits between these two. It uses AI broadly — across the whole lifecycle, not one phase — but channels it through a structured workflow with explicit human approval points. Not vibe coding. Not a rubber stamp. Velocity with governance.

2.What AI-DLC is

AI-DLC is a lifecycle in which AI does not merely help you write software — it helps you build software end to end: clarifying requirements, proposing a staged plan, generating and refining artifacts, and supporting operational readiness. AWS states the operating principle directly:

AI creates plans, seeks clarification, and implements plans, while humans make critical decisions.

Read that twice, because both halves are load-bearing. AI is not waiting to be told what to do next — it proposes. And AI does not decide — it defers, to the people who hold the business context.

The four principles

1. AI-powered execution with human oversight. AI systematically creates detailed work plans, actively seeks clarification, and defers critical decisions to humans.
2. Dynamic team collaboration. Because AI absorbs the routine work, the team's time goes into real-time problem solving and rapid decision-making — together, not in a queue of hand-offs.
3. Persistent context. Plans, requirements, and design artifacts are written into the project repository and carried across every phase, so nothing has to be re-explained.
4. Quality through alignment. The team builds precisely what it has in mind, rather than an abstract AI interpretation of the intent.

If you keep one sentence from this module, keep this one: AI executes, humans govern.

3.The three phases

AI-DLC collapses the six familiar SDLC phases into three, executed in order.

Inception — what are we building, and why?

Turns business intent into validated direction: requirements, user stories, constraints, success criteria, and a decomposition into units of work. The goal is not more documentation. The goal is less ambiguity, established while changing your mind is still cheap.

Construction — how are we building it?

Uses that validated context to produce logical architecture, domain models, working code, and tests. AI moves very fast here, which is exactly why the humans stay responsible for correctness of intent and for quality boundaries.

Operation — how do we run and ship it safely?

Deployment, infrastructure-as-code, monitoring, and the feedback that informs the next cycle. AI applies the context accumulated in the two earlier phases rather than meeting the system cold. This is the phase that turns “coding faster” into “delivering faster.”

4.The loop inside every phase

Here is the part that makes AI-DLC feel different in practice. The traditional SDLC is a sequence: finish a phase, hand it on. AI-DLC is a loop, and the same four beats repeat inside every phase and every stage.

Four beats, in order, every time:

1. Plan. AI proposes what to do next — the stages, the outputs, the checks.
2. Clarify. AI asks targeted questions to remove ambiguity before generating anything.
3. Approve. Humans confirm intent, constraints, and risk decisions.
4. Execute. AI generates the artifacts and work products.

Then the loop runs again with more accumulated context than it had last time. That is the whole shift, and it is smaller than it sounds: you are not asking AI for an answer, you are running a lifecycle.

You have already run this loop, by the way. It is what Modules 3 and 4 had you do. Section 8 puts the command names on each beat.

5.Mapping AI-DLC onto the SDLC you already run

This is the picture worth holding in your head. Traditional phases on the left, AI-DLC phases in the middle, and — the part most summaries leave out — who is actually in the room for each phase on the right.

The phase collapse

Notice what the middle row is really saying. The point is not that the phases got renamed. The point is that the hand-offs between them were deleted. Every hand-off in the traditional SDLC is a place where context is dropped, re-derived, and slightly changed. AI-DLC removes the hand-off by keeping one shared context and one continuous loop.

SPECTRA’s agentic SDLC on the same map

SPECTRA runs the lifecycle as an agentic SDLC in seven phases: the six familiar ones plus a Foundation phase that happens once, before the first feature. Every phase reads and writes the same durable artifacts, and every phase has a human gate. The seven fold straight into AI-DLC’s three stages:

Two placements are worth noticing. Idea assessment sits in Inception, before Plan, because it decides whether Plan should start at all — a kill verdict is Inception doing its job, not failing at it. Bug fixing is Maintain work, in Operation: the diagnosis, bounded fix, and verification from Module 6 happen against a running system, and what they teach flows back into the next Inception.

What changes, dimension by dimension

The main risk row is the one to internalize, because it tells you where to spend your attention. Under the SDLC you defended against misunderstanding. Under AI-DLC you defend against building the wrong thing beautifully and at speed. Those need different countermeasures — which is what sections 7 and 8 are about.

One line summarizes the whole table: the SDLC manages humans; AI-DLC manages change.

6.Sprints become bolts

The vocabulary changes too, and the new words are not cosmetic — each one marks something that genuinely has no equivalent in the old model.

What a bolt actually feels like

A sprint is a container for coordinating work that people do separately: you plan on Monday, disperse, and reconvene. A bolt is the opposite shape. The team is together, AI is producing artifacts inside the session, and the questions that would normally have become Slack threads get answered in the room while the work is still warm.

Activities that previously took weeks land in hours or days. Not because anyone is typing faster, but because the waiting is gone — the waiting for a review slot, for a clarification, for the next ceremony, for someone to have the context you needed.

The demand this places on you

Bolts have a real cost, and it is worth naming honestly: the team has to be available inside the bolt. Mob elaboration assumes the mob turns up. A bolt that stalls for six hours waiting on an absent approver is not a bolt — it is a slower sprint with worse ergonomics.

This is a scheduling problem before it is a tooling problem. If your product owner is in back-to-back meetings all week, AI-DLC will not work for your team yet, and no command will fix that.

7.Who is in the room — personas at every phase

This is the most misunderstood part of AI-DLC, so it is worth stating flatly before anything else:

At every phase it is humans and AI, working the phase together. Not a hand-off to AI. Not a hand-back from AI. The same room, the whole way through.

The diagram in section 5 shows this on the right-hand side, and it is the reason that diagram has three columns instead of one. Every AI-DLC phase has named human roles with real responsibilities and a defined AI contribution running alongside them. Here it is in full.

Read down the third column and you will notice every single entry is a verb of judgment: validates, approves, reviews, guides. Read down the fourth and they are all verbs of production: generates, creates, executes, analyzes. That split is the entire operating model, and it holds in all three phases.

The anti-pattern

The most common way AI-DLC quietly degrades is this: the product owner writes a ticket and leaves. The developers and AI then do Inception without the person who holds the intent, which means the requirements document is a guess that looks authoritative. Everything downstream inherits the guess, and it surfaces in Operation.

If the PO is not in the room during Inception, you are not running AI-DLC. You are running the SDLC with a chatbot attached — ditch one from section 1, with extra steps.

Where humans decide: three gates

“Humans govern” only means something if you can say where. In practice the decisions cluster at three points, one per phase boundary:

SPECTRA’s per-phase gates from section 5 sit inside these three. Gate A is the Plan gate: the product owner approves intent and scope, on top of Foundation standards approved once, up front. Gate B is the Design gate: architects approve the plan and its decision records. Gate C is the Deploy gate: a maintainer merges, and release and rollback stay the team’s call. The gates in between — engineers reviewing every change, QE deciding what a test finding means — keep execution honest while it runs fast.

Gates are not bureaucracy, and they are not a return to stage-gate waterfall. AI-DLC does not remove engineering discipline — it relocates the discipline to a small number of high-value checkpoints and then lets execution run fast between them. Fast execution between gates; clear accountability at gates.

The reason they are non-negotiable is the uncomfortable fact from section 5: AI can move fast enough to produce the wrong thing, beautifully and with excellent test coverage. A gate is the difference between “the AI generated some stuff” and “we delivered something we can stand behind.”

8.Doing it with Spec Kit and SPECTRA

Everything above is methodology. Here is the part that makes it something you can run on Monday — because you already know these commands. The workflow Module 1 introduced and Modules 3 and 4 had you run is AI-DLC’s loop; it just did not have these stage names attached to it. Core commands run the loop end to end; add-ons are switched on when the work needs them.

Two details. /speckit-checklist runs after /speckit-plan, but it tests the spec, so the roster files it with the Inception agents and its findings go back to specify or clarify. /speckit-converge is the core agent that closes the loop — SPECTRA’s roster files it under Testing & Quality as Convergence: repeat implement and converge until it reports Converged.

Three things about the table deserve to be said out loud, because they are what turn it from a lookup into a practice.

/speckit-clarify is mob elaboration

This is the single most important mapping on the page. Clarify is the step where the AI asks its questions before anything is planned; AI-DLC’s contribution is to insist that it happens while the room is still assembled. Run it alone at your desk and you have converted mob elaboration back into an individual guessing exercise. Clarify is an add-on, which means the loop will run without it; AI-DLC is the argument for never skipping it.

Expect volume. Clarify asks at most five questions per pass, so plan on several passes, each with a focus area — functional behavior, non-functional requirements, UX. A real Inception run on a modestly sized feature surfaces well over a dozen questions, all of them before the requirements are settled. Answering them together, in one sitting, is not overhead. That is the work of Inception, and it is where the rework you never had to do gets prevented.

Durable rules beat chat history — and the constitution is where they live

AI-DLC only holds together if the agent's understanding survives between sessions. Conventions, non-negotiables, security and testing rules, and product constraints have to live somewhere versioned and reviewable — treated as an artifact, not as chat history that evaporates when the window closes.

In this course that place already exists: .specify/memory/constitution.md, written by /speckit-constitution (SPECTRA calls it the Guardrails agent) and read by every later phase. /speckit-analyze treats a conflict with it as critical, and /speckit-spectra-review-pr checks every pull request against it. It is the first thing to write and the thing to keep current. No additional tooling required — if you completed Module 3, it is already in your project.

The artifacts are your audit trail

AI-DLC insists on keeping a visible record of where the lifecycle is and why each decision was made. Speed without receipts is how teams end up unable to explain their own system six months later.

Spec Kit gives you that for free: the specs/<NNN>-<name>/ directory — spec, plan, tasks, and design artifacts, versioned alongside the code — plus SPECTRA’s decision records under the artifact root. When someone asks “why did we do it this way?”, the answer is a file, not an archaeology project. This is the same point Module 9 made about specs as a review surface, now doing double duty as the lifecycle's memory.

One bolt, end to end

A single bolt on a small feature, with the gates marked:

# ── Inception ─────────────────────────────────────────────
# Whole room: PO, tech lead, an architect, QE lead.
# Unsure it is worth building? Assess it first (Module 5).
/speckit-constitution     # once per project, not per bolt
/speckit-specify          # AI drafts the spec from stated intent
/speckit-clarify          # AI interrogates it — answer together
# ▸ GATE A — the room approves scope, success criteria, constraints.
#   Do not proceed on "looks fine, ship it." Say what is out of scope.

# ── Construction ──────────────────────────────────────────
# Developers + QE. PO reachable for questions.
/speckit-plan             # architecture direction and technical approach
/speckit-checklist        # unit tests for the spec; people tick them
/speckit-tasks            # decomposition into ordered, checkable work
/speckit-analyze          # read-only cross-check; fix at the source
# ▸ GATE B — approve the approach, the definition of done, the test
#   strategy. This is the last cheap moment to change your mind.
/speckit-implement        # AI builds in stages; verify each one
/speckit-converge         # repeat with implement until Converged

# ── Operation ─────────────────────────────────────────────
# Developers + DevOps.
# ▸ GATE C — readiness: what breaks, how you would know, how you roll back.
/speckit-spectra-create-pr    # offered when implement finishes
/speckit-spectra-review-pr    # checks spec, ADRs, constitution
# A maintainer merges. Later defects: the bug workflow (Module 6).

Compare that against the diagram in section 5 one more time. Same three phases, same personas, same gates — expressed as commands you have already run in Modules 3 and 4.

9.What a real run looks like

The three phases are tidy at a distance. Up close a real run has more structure than “Inception, then Construction” — and the structure is reassuringly familiar.

It starts by working out what kind of codebase it is

AI-DLC's first move is workspace detection: is this greenfield, or is there an existing system to retrofit? Everything downstream adapts to the answer — a greenfield run generates from intent, a brownfield run has to reverse-engineer the current behavior before it can safely add to it.

You have already run both halves of that split. Module 3 was the greenfield path. Module 4 was the retrofit path, and its pattern — a reviewable baseline, guardrails drawn from what is already true, one bounded change — is exactly what AI-DLC does when detection comes back “existing code: yes.”

Inception runs in stages, not in one shot

Requirements → user stories → workflow planning → application design → decomposition into units of work. In Spec Kit terms that is /speckit-specify and /speckit-clarify doing the first two, and /speckit-plan beginning where design starts. The staging matters because it gives you somewhere to stop: you can approve requirements without having committed to a design.

Construction runs a repeatable loop per unit of work

For each unit: functional design → non-functional requirements → NFR design → infrastructure design → code generation. Note where NFRs and infrastructure sit in that list — before code generation, not after the demo. That ordering is deliberate, and it is why AI-DLC trends toward deployment readiness rather than toward an impressive prototype that nobody can operate.

In Spec Kit terms this is the /speckit-plan → /speckit-tasks → /speckit-implement → /speckit-converge cycle, run once per unit of work rather than once per feature — the same move as Module 8’s spec of specs, where each roadmap slice runs its own loop.

10.What this does not fix

Every module in this course ends with the honest limits, and AI-DLC has several worth knowing before you propose it to anyone.

• It does not rescue a vague spec. A bolt run on a woolly /speckit-specify does not fail less than a sprint would — it fails faster, and with more code already written. Compression amplifies whatever quality of thinking you put in. Everything Module 2 taught about spec anatomy matters more here, not less.
• Team availability becomes the binding constraint. Mob elaboration assumes the mob shows up. In an organization where the PO is fully booked and the QE lead is split across four teams, AI-DLC will stall at Gate A regardless of tooling. This is a calendar problem, and it is usually the real blocker.
• Review capacity is still finite. Module 9's bottleneck argument applies harder, not less. Generating more, faster, means more to review — and if review is already your constraint, AI-DLC will find that constraint immediately. The gates help by moving judgment upstream where it is cheap, but they do not create reviewer hours.
• Depth has to be adaptive or it becomes ceremony. Not every stage deserves equal rigor. Go deep where risk is high — a payments path, a migration, anything touching auth — and stay deliberately light where it is not. AI makes it very easy to overproduce artifacts, and a lifecycle drowning in generated documents nobody reads is its own failure mode.
• It is a change to how people work together, not a tool install. The commands take an afternoon to learn. Getting four people into a room at the same time to elaborate a feature is the actual adoption problem, and it is organizational.

11.Run your first bolt this week

You do not need to rewrite your process to start. The shift is smaller than it looks: you keep the lifecycle, you change the engine. Pick one small, real change — not a demo — and run it end to end.

• Name your three gates and who holds each. Write it down before you start. Gate A: who approves intent? Gate B: who approves the approach? Gate C: who approves the release? If any answer is “whoever's around,” fix that first.
• Get the constitution written. Run /speckit-constitution before anything else. Conventions, non-negotiables, security and testing rules. This is the durable context every later step reads.
• Book the Inception session and get the room. PO, a tech lead, an architect if the change warrants one, the QE lead. Ninety minutes, calendars cleared. This booking is the hard part — do it first.
• Force plan-then-clarify before any generation. Run /speckit-specify, then /speckit-clarify, and answer every question in the room. Resist the urge to skip ahead to code — this is where the value is.
• Stop at Gate A and say it out loud. State what is in scope, what is explicitly out, and what “done” means. Approving in silence is not approving.
• Run Construction in one sitting. /speckit-plan → /speckit-tasks → /speckit-analyze → Gate B → /speckit-implement, with QE present rather than queued behind you.
• Close the loop through the artifacts. /speckit-converge until it reports Converged, then /speckit-spectra-create-pr so the spec ships as the PR's own justification.
• Debrief for fifteen minutes. Where did you wait? Which question should have been asked at Inception and was not? That answer is your next improvement.

Do it once and the comparison makes itself. The gain is rarely “the AI wrote code quickly” — it is finishing with a change whose reasoning is recorded, whose scope held, and whose process you can run again next week.

Where to go from here

• AWS — AI-Driven Development Life Cycle — the canonical description of AI-DLC, and the source of every definition in this module.
• SDLC Who? Meet AI-DLC: The New Build Loop and AI-DLC in Action — two community write-ups of the AI-DLC process, and the source of the loop, the gates, and the shape of a real run described above. They demonstrate the process with their own tooling; this course runs the same process with Spec Kit and SPECTRA.
• The full SPECTRA agent roster — every agent grouped by SDLC phase and tagged with its AI-DLC phase, so you can see what is available in Inception, Construction, and Operation. See also the SPECTRA landing page.
• Module 4 — if you want to feel a bolt rather than read about one, the brownfield lab is the practice ground. Run it again, but this time with a second person in the room for /speckit-clarify and see what changes.

Knowledge check

Six questions. Pick an answer to see whether it holds.

You have finished the course

You started with what a spec is and why code stopped being a sufficient source of truth, and learned to write one an agent can act on (Modules 1 and 2). You ran the full workflow on a greenfield project and then on an inherited one (3 and 4). You decided whether an idea deserved building and fixed a real defect with evidence (5 and 6), made the workflow your own (7), learned what breaks and what teams get wrong (8), and worked through how the practice changes quality, review, and collaboration (9).

This module put a name on where all of that is heading. Spec-driven development is not a technique bolted onto the SDLC — it is how the lifecycle works once AI is at the centre of it. You already have the commands. What is left is getting the right people in the room and running your first bolt.