Spec-driven development: Spec Kit, AI-DLC and the discipline

The fastest way to waste an AI coding agent is to give it a sentence and let it go. The agent will produce something that satisfies the sentence, and the sentence will turn out to have been underspecified in a dozen ways that only become visible when the code exists. Specification-driven development, SDD, is the answer that has emerged over the past year, and it is not new. It is the old discipline of writing down what you want before you build it, restated for a world where the builder is a model and the cost of building is nearly zero. When writing the code is cheap, specifying is where the value is. Writing the code is only part of building, and integration, security, testing and maintenance still cost what they always did, but it is the part that used to be the bottleneck.

I use SDD in my own delivery work and I teach it. It was the method on an enterprise AI build for a two-wheeler manufacturer, where every piece, from the customer-facing AI experience to the analytics product on the company's historical data, had written acceptance criteria before it was built, and it is one of the AIXL Academy workshops. Two toolchains dominate the conversation: GitHub's Spec Kit and AWS's AI-Driven Development Lifecycle, AI-DLC. They overlap, they differ in scope, and the thing that makes either of them work is not in the tool.

Close

The spec-driven pipeline. A constitution or standing rules at the top; then specify, plan, tasks, implement, converge, each producing a Markdown artefact that feeds the next; human decision points marked between phases.

What spec-driven development is

The idea is that the specification, not the code, is the primary artefact. You describe what to build, in enough structure that an agent can plan from it; the agent produces a plan; the plan is broken into tasks; the agent implements against the tasks; and the result is checked against the specification rather than against a reviewer's impression. Each step produces a document that the next step reads. The human's job moves from writing code to writing and approving the documents that govern how the code is written, and to deciding at each gate whether the work may proceed.

Done well, it fixes the two failures I see most in agent-assisted delivery: the agent solving the wrong problem well, and nobody being able to say afterwards what the system was supposed to do.

Spec Kit

Spec Kit is GitHub's open-source toolkit for SDD. It passed 130,000 stars within a year of launch and supports some 38 agents, including Copilot, Claude, Gemini and Codex, so a team is not tied to one vendor. It is a process and a set of templates, not a runtime.

The process runs through phases, each with a slash command and each producing a Markdown artefact.

• Constitution. The standing rules of the project: the principles, constraints and non-negotiables that every later phase must respect. Written once, amended rarely.
• Specify. What to build and why, in terms of user outcomes and acceptance criteria, deliberately free of technology choices.
• Clarify. The agent interrogates the specification for ambiguity and the human answers. This is the step teams skip and the step that saves the most.
• Plan. The technical approach: architecture, data, dependencies, with the reasoning recorded.
• Tasks. The plan broken into small, ordered, independently checkable units.
• Analyse. A consistency check across specification, plan and tasks before anything is built.
• Implement. The agent executes the tasks against the plan.
• Converge. The newest phase: the result is checked back against the specification, and gaps go round again.

Updated 9 October 2026: when this was first published Spec Kit ended at Implement. The Converge phase arrived in its late-September release, and I have added it above because it formalises the step I was already doing by hand.

What Spec Kit gets right is the constitution. A file of principles that every phase must respect is the single most effective control I have found for keeping an agent inside an organisation's engineering standards, and it is the same idea as the harness rules I describe in the harness engineering article, applied to delivery.

AI-DLC

AWS's AI-Driven Development Lifecycle is broader. Where Spec Kit is a technique for one piece of work, AI-DLC is a methodology for a team, first described in late 2024 and now shipped as rule files that an agent follows. Its premise is stated plainly: the AI leads execution and the humans hold the decision rights. The AI drafts requirements, proposes architecture, writes code and generates tests; the people supply business context, answer the AI's questions, and approve or override before anything moves on.

It has three phases.

• Inception turns a one-line intent into requirements, user stories, acceptance criteria and a decomposition into units of work, each with its dependencies. The team does this together in what AWS calls mob elaboration: product, engineering, security and operations in one session, reacting to the AI's proposals live.
• Construction takes the validated context and proposes architecture, domain models, code and tests, again with the team clarifying and overriding in real time: mob construction.
• Operations covers deployment and monitoring.

Two vocabulary changes carry the methodology's intent. Sprints become bolts, cycles measured in hours or days rather than weeks, because the build step is no longer the bottleneck. Epics become units of work, sized so that one can be elaborated, built and checked inside a bolt.

AI-DLC is, in effect, SDD extended from the individual developer to the whole delivery organisation, with the ceremonies rewritten for a world where elaboration is the expensive step and construction is not.

Which to use

They are not rivals. Spec Kit is the better instrument for a single engineer or a small team doing bounded work, and its artefacts fit inside any method. AI-DLC is the better frame when the question is how a whole team should work, and in particular when the organisation's existing ceremonies, sprint planning, estimation, hand-offs between roles, are the thing slowing it down. Several teams I know run AI-DLC's phases with Spec Kit's templates inside Construction, and that combination is roughly what I do.

The honest comparison is that both are young, both come from vendors with an interest in the outcome, and the evidence for either is mostly practitioner reports. What is not in doubt is the discipline underneath them, which is older than both and which I would teach regardless of the tooling.

Where both fall short for enterprise work

Having used the methods and taught them, here is my view of what neither toolchain yet handles, and what I add around them. These are positions, not measurements.

Both assume greenfield. Spec Kit's phases and AI-DLC's bolts are at their best when the agent is building something new. Enterprise AI is almost always brownfield: the specification has to describe the systems the work must fit into, the data it may and may not touch, and the legacy behaviour it must not break. I add a section to every specification that names the systems of record, the access each needs, and the owner of each boundary, before the agent plans anything.

Neither treats data access and ownership as part of the specification. On an AI build the open questions that stall delivery are about who may read which data, where inference may run, and who owns the result. Both toolchains leave those to "clarify". I make them mandatory fields: a specification without a named data owner and a named operator is not ready to plan.

Acceptance is assumed to be executable. As with harnesses, the methods expect a test suite. For AI features the acceptance criteria include a labelled evaluation set and a human review sample, and the specification has to say how big, who labels it and what "good enough" is. That is where the evaluation harness and the specification meet, and the tools do not yet connect them.

AI-DLC's ceremonies need the client in the room. Mob elaboration works when product, engineering, security and operations can all react live. In a client engagement, those people belong to the client, and getting them into one session is the forward-deployed engineer's job before the method can run at all. The methodology is right; the organisational precondition is unstated.

The specification should be an artefact the client keeps. In my engagements the specification pack is one of the five things handed over, alongside the discovery brief, the architecture decision record, the working build and the evaluation report. The toolchains treat the spec as scaffolding for the agent. I treat it as the document the owner will use to change the system after I have left, which changes how it is written: for a person first, an agent second.

The discipline underneath

Four practices make SDD deliver, and all four are things the tools can prompt for but cannot do for you.

Acceptance criteria before technology. The specification has to say what "done" looks like in terms a user or an owner can verify, and it has to say so before any decision about models, frameworks or services. The commonest failure I see is a "specification" that is a design document with the outcome left implicit.

Here is the difference in miniature. The request as it usually arrives: "Use AI to speed up supplier onboarding." The same request as a specification an agent can build from and a person can check: "When a supplier submits the onboarding pack, the system extracts the registered name, tax identifier, bank details and the two certificates we require, compares each with the master record, and produces a checklist that names every field as matching, missing or conflicting, with a link to the page it came from. A procurement officer accepts or rejects the checklist; the system never writes to the supplier master. Done means: on the last fifty onboarding packs, every missing or conflicting field the officers found is on the checklist, and the officer's review takes under five minutes per pack." Nothing in the second version names a model, and everything in it can be tested.

Clarification as a gate, not a courtesy. The clarify step exists because a model will happily resolve ambiguity by assumption. Make it a rule that implementation cannot start while any open question in the specification is unanswered. On enterprise AI work the open questions are usually about data access, ownership and what happens on failure, which are exactly the ones a model cannot answer for you.

Small, checkable tasks. A task the agent can finish in one pass and that a person can verify in minutes. Large tasks fail quietly; small tasks fail loudly, which is what you want.

Converge against the specification, not the reviewer's taste. The final check is whether the result meets the written criteria. If the criteria were wrong, change the specification and go round again. That keeps the document true, which is what makes it useful to the next person.

In my own engagements the specification pack is one of the five artefacts every participant produces and one of the things the client keeps: the discovery brief, the architecture decision record, the working build, the evaluation report and the handover note. The specification is where the first two meet the third. A team that can write one well is most of the way to being able to own what an agent builds for it, and that, rather than the tooling, is what I am trying to leave behind.

Sources

• GitHub, Spec Kit and its documentation.
• AWS DevOps Blog, AI-Driven Development Life Cycle and Building with AI-DLC using Amazon Q Developer.
• Microsoft Learn, Implement spec-driven development using the GitHub Spec Kit.