Spec-Driven Development for AI: Write the Spec, Not the Prompt

What changes when the specification — not the code — becomes the thing you build and maintain, the tools that make it work in 2026, and how we approach it as a studio.

For two years the default way to build with AI was to describe what you wanted and let the model write the code. It works — until the project gets big enough to matter. Andrej Karpathy named this "vibe coding" in early 2025; it became Collins' word of the year, and by 2026 even Karpathy called it passé.

The reason is simple. When an agent writes most of the code, typing stops being the bottleneck. Deciding precisely what to build — and keeping the code honest to that decision — becomes the whole game. That is the gap spec-driven development closes.

What spec-driven development actually is

SDD inverts the AI coding loop. Instead of prompting for code and hoping it matches intent, you write a structured, version-controlled specification first, turn it into a plan, break the plan into tasks, and only then generate code. The spec — not the code — is the source of truth. When requirements change, you change the spec and regenerate the parts that moved.

Think of it the way a compiler thinks about source: the spec is what you edit and review; the code is the build output. The twist is that the "compiler" is now a non-deterministic agent — which is exactly why the spec has to be precise.

The canonical loop, popularized by GitHub's Spec Kit, runs in five steps, each producing a markdown file the next step reads:

• Constitution — the non-negotiable rules for the project: testing approach, architecture conventions, stack.
• Specify — what you are building and why, written as behavior, not implementation.
• Plan — the technical approach that satisfies the spec.
• Tasks — the plan broken into ordered, atomic units an agent can execute.
• Implement — the agent writes code against the tasks.

You review intent at the spec and plan stage — where a mistake costs a sentence — instead of reviewing a two-thousand-line diff after the fact.

Why it beats prompting for anything you have to maintain

Three things change when the spec leads.

You review decisions, not diffs. Catching "this isn't what we meant" in a one-page spec is cheap. Catching it in shipped code is not.

The intent survives. A prompt is gone the moment the chat closes. A spec lives in the repo, so the next engineer — or the next agent — inherits the context. That matters even more on a team, where product, engineering, and the client all have to agree on the same thing.

Requirements become testable. The most useful convention here is EARS (Easy Approach to Requirements Syntax): a handful of plain-English patterns — "When [trigger], the system shall [response]" — that turn fuzzy asks into acceptance criteria an agent can build to and a test can check.

One honest caveat about the ceiling. Practitioners — Martin Fowler's team among them — sort SDD into three levels: spec-first (write the spec, generate once), spec-anchored (keep the spec alive to evolve the feature), and spec-as-source (the human only ever edits the spec, never the code). Most real value today sits at the modest end. Spec-as-source is the frontier and still largely unproven — run the same spec through a non-deterministic model twice and you can get two different implementations. Adopt the discipline; don't buy the maximalist pitch yet.

The tools worth knowing in 2026

By 2026 every serious coding tool ships some flavor of SDD. Here is the honest landscape, from most portable to most ambitious.

• GitHub Spec Kit — the open-source, agent-agnostic default. A CLI (specify) that installs the constitution → specify → plan → tasks → implement workflow as slash commands, and works with 30-plus agents including Claude Code, Copilot, Codex, Cursor, and Gemini CLI. Past 100,000 GitHub stars in 2026. Start here if you want the method without lock-in.
• AWS Kiro — the most complete spec-native environment. An agentic IDE (built on Code OSS, so VS Code users are instantly at home, with a CLI too) where specs are not an add-on, they are the interface: requirements → design → tasks. It adds EARS by default, agent hooks (automations that fire on save — update tests, refresh the README, run a security scan), and MCP support. Best when a team is committing to SDD.
• Claude Code — the lowest-friction terminal path. Plan mode plus a short markdown spec is the most common lightweight spec-first workflow, no framework required. Skills let you encode your spec templates and guardrails once and invoke them on demand.
• Cursor — Plan Mode plus an AGENTS.md file, for teams that want spec-driven principles inside an IDE-first flow.
• Google Antigravity — Google's agent-first platform (IDE, CLI, SDK), designed end to end around plan → execute → verify. Newer, but built on the same premise.
• Tessl — the boldest bet. It raised around $125M on spec-as-source: specs as the sole source, code as a regenerable byproduct. The public registry of workflow tiles ships today; the full framework is still in beta. Watch it; don't stake production on it yet.
• OpenSpec / BMAD-METHOD — lighter, proposal-first options that suit brownfield and exploratory work.

The right choice is less about the logo than about two questions: do you want the spec as a static planning doc or as living infrastructure, and are you working solo or coordinating agents across a team? Answer those and the shortlist writes itself.

There is a gap to close, too. The JetBrains AI Pulse survey of 11,000 developers in early 2026 found that 90% use AI at work, but only 13% use it across the whole software lifecycle. SDD is one of the clearest ways to move from the first number toward the second.

How we think about it as a studio

None of this is new to anyone who has shipped software for a living. Long before agents, the artifact that made a build faster and cheaper was a sharp spec — the cahier des charges that gets product, tech, and the client agreeing on the same thing before a line is written. Our two-day Co-think workshop exists to produce exactly that. SDD is the AI-native version of a discipline good operators already keep: decide precisely, write it down, then build.

A few things we hold to.

Don't over-tool. You don't need Kiro and Spec Kit and a registry to start. Take one feature you would ship this week, write it as a one-page spec with a handful of EARS acceptance criteria, and run it through the agent you already use. Thirty minutes, and you will feel the difference in the first-pass output.

Keep vibe coding — in its lane. It is still the right call for spikes, throwaway scripts, and exploration. The pattern that works: vibe-code the spike to learn, distill what you learned into a spec, then spec-drive the production version. Speed of learning is the point; the spec is how you keep the learning.

Treat the spec as a team artifact, not a solo one. On a TypeScript stack shared across a studio, the spec is where a founder's intent, an engineer's plan, and a client's acceptance criteria meet. That alignment is worth more than any single agent's cleverness.

The bottleneck has moved. It is no longer how fast you can type code — it is how clearly you can say what you want. That is a skill, and it is the one worth building.

Talk to a builder

We build AI-native products for founders and corporates — and we start where SDD does: with a spec you can build from. If you have a problem worth shipping and want operators who write the spec and then write the code, start with a conversation.

Talk to a builder →

‍