Spec-driven development (AI)

A discipline for AI-assisted coding: agree on a written specification of what you're building before the AI generates code, so the agent implements an agreed plan rather than improvising. Introduced to this wiki by spec-driven-ai-tools.

Why it exists

The motivating claim: AI coding tools deliver speed, but "speed without structure means shipping ambiguity at scale." A spec is the structure — a reviewable artifact the human approves before implementation, and a reference the implementation can be checked against.

Recurring design elements (across the tools surveyed)

A source-of-truth spec that the project accumulates (e.g. OpenSpec's archived delta specs; Spec-Kit's project-wide "constitution").
Explicit handling of unknowns (Spec-Kit's NEEDS CLARIFICATION flags).
Phases (plan → implement) and, in the better tools, course correction and review gates between them.
Delivery as agent-skills / slash commands installed into the coding agent.

More instances (2026-06-01)

conductor extends the idea to context-driven-development: not just a spec before code but context as a managed, persistent artifact (Context → Spec & Plan → Implement), with a mandatory plan-review gate and git-aware revert by logical work unit. Google's launch post names CDD as its own discipline — SDD widened from spec-before-code to context + spec before code.
BMAD (per claude-code-best-practices) is a spec-driven methodology a practitioner reserves for projects with real users / security surfaces — it surfaced 36 user flows + risks before coding, where lighter "plan mode" missed security issues. Concrete evidence the spec-first discipline pays off where stakes are real.
spec-kit (GitHub) — the reference SDD toolkit: six /speckit.* commands (constitution → specify → clarify → plan → tasks → implement), "specs as executable blueprints," across 30+ agents. The canonical, tool-agnostic instance.
get-shit-done (GSD) — a Claude-Code system pairing context engineering with SDD; shows the discipline converging with conductor's "context as artifact" idea.

Mined context, not written context (2026-07-22)

corbell moves the discipline's input from prose to extraction. Where the tools above have a human author the constitution, the clarifications, or the managed context, Corbell builds a knowledge graph of the existing codebase (tree-sitter call graphs, typed signatures, service dependencies, plus git change coupling) and generates the spec against that, across multiple repos, validating it against recorded architecture constraints. The spec is then grounded in what the system demonstrably does rather than in what someone documented — and two of its inputs, change coupling and infra detection, are signals nobody maintains by hand. Unevaluated (no benchmark), so read it as a design direction: derived context as the SDD input.

The discipline aimed at beginners (2026-09-01)

vibe-coding-prompt-template keeps the ordering and drops almost all the tooling. Four copy-paste prompts — research, PRD, tech design, agent files — run in any chat tool with no repository, then a build loop in an AI IDE, priced at two to four hours end to end. Its stated audience "does not need to be an experienced developer."

Every earlier instance here assumes a working engineer: spec-kit's slash commands, OpenSpec's delta specs, BMAD's course correction, conductor's tracks, corbell's code-graph extraction. This one isolates the variable the others bundle — the sequence, without the machinery — and it carries the same review gate ("propose a Phase 1 plan, wait for my approval") and the same durable artifacts (AGENTS.md, MEMORY.md, agent_docs/). Whether the ordering or the tooling does the work is still untested; this at least separates them. It ships no evaluation, so it is a design position, not evidence. It also carries the discipline's name backwards — see vibe-coding.

From one repo to an org (2026-10-08)

Every instance above assumes a single project adopting the discipline. spec-kit's enterprise extension post names the step up: a stable core with explicit extension points, so an org layers presets/extensions/bundles/workflows on top rather than forking. The single-level constitution becomes three inherited levels (org → domain → team), and a catalog splits into governed (vetted, installable) vs. community (discovery only — listing is not a security review). This is governance scaffolding, not a new discipline: the six-command loop is unchanged, what's new is how many teams can share one baseline without drifting. No evaluation of whether the layering actually holds up at scale — conceptual, first-party.

Connections

Sits alongside claude-financial-services and (cross-wiki) gbrain as another case of capability and process encoded as markdown an agent executes. (Reflexively, it mirrors how this very wiki was built — a brainstorm → spec → plan → execute loop — which is some weak corroboration that the structure-before-code instinct generalizes.)

spec-driven-ai-tools · conductor · claude-code-best-practices · agentic-coding-harness · agent-skills · vibe-coding-prompt-template · vibe-coding