Guide

Spec-Driven Development: why specs are replacing vibe coding

Published 19 September 2026

Andrej Karpathy named vibe coding in February 2025, describing his own practice rather than attacking anyone else's. What happened next matters more: several independent teams shipped tooling whose common move is to make you write the intended behaviour down before the model writes code.

What Karpathy actually said

On 2 February 2025, Karpathy opened a post on X:

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

That is the opening sentence of a longer post, and two details vanish whenever it is requoted: the contraction, There's, and the quotation marks around vibe coding. The expanded, unquoted version in circulation is a paraphrase, not the quote Wikipedia and MIT Technology Review reproduce.

The rest of the post describes a workflow, blunt about what gets skipped:

I "Accept All" always, I don't read the diffs anymore

The code grows beyond my usual comprehension

That is a report, not a warning. The term stuck: Collins Dictionary made vibe coding its Word of the Year for 2025 and credits the coinage to Karpathy.

The part that actually breaks

Speed is not the problem with vibe coding. Review is.

What is absent is a short list:

  • no written statement of intended behaviour
  • no artifact that outlives the chat session
  • nothing reviewable except the diff

A diff tells you what changed, not what was supposed to happen, so it cannot tell you the model got it wrong. That is the gap the tooling wave aimed at.

What actually shipped

Six of the better known efforts are Spec Kit from GitHub, Kiro from AWS, OpenSpec from Fission-AI, Plan Mode from Cursor, BMAD-METHOD from BMad Code, LLC, and Antigravity from Google. Three of the six use the phrase "spec-driven development" for themselves, and three do not.

As their own docs describe them:

Tool Who ships it What it does Uses the phrase "spec-driven development"?
Spec Kit GitHub Slash commands in your agent: spec, plan, tasks, implementation Yes, in the repo's own description
Kiro AWS Turns a prompt into requirements, designs and sequenced tasks before code Yes, a heading on its homepage
OpenSpec Fission-AI Markdown specs in an openspec/ folder, agreed before code Yes, in the repo's own description
Plan Mode Cursor Researches the codebase, asks questions, drafts a plan you edit No, the docs say plan, not spec
BMAD-METHOD BMad Code, LLC Role agents produce PRDs and architecture docs, then story files No, see below
Antigravity Google Visual Artifacts including Plan and Walkthrough reports on agent output No, see below

Four specifics, since the labels blur:

  • Spec Kit calls itself a "Toolkit to help you get started with Spec-Driven Development", ships as a CLI at version 1.0.0, and claims support for 30 or more coding agents. Its commands are namespaced /speckit.specify, /speckit.plan, /speckit.tasks and /speckit.implement, so write-ups citing a bare /specify describe a pre-1.0 set.
  • Kiro is AWS's own product, with a homepage section headed "Bring structure to AI coding with spec-driven development". Its docs say a spec produces three files: requirements.md for user stories and acceptance criteria, design.md for architecture and sequence diagrams, tasks.md for a trackable implementation plan.
  • OpenSpec describes itself verbatim as "Spec-driven development (SDD) for AI coding assistants." The name is heavily forked on GitHub, several clones carrying that same description, so cite Fission-AI/OpenSpec as the upstream.
  • Cursor is two features people merge into one. Plan Mode "creates detailed implementation plans before writing any code." Rules are separate: they "provide system-level instructions to Agent." Project rules live in .cursor/rules and must carry the .mdc extension, since plain .md files are ignored there. The Rules page never mentions Plan Mode.

Two labels applied from the outside

The two are BMAD-METHOD and Antigravity. Neither uses the phrase spec-driven development for itself; the label comes from the people writing about the category, not from the projects.

BMAD-METHOD does not call itself spec-driven development. The acronym stands for "Breakthrough Method for Agile Ai Driven Development", and the repo frames itself as Agile AI Driven Development, built on durable context rather than a spec as single source of truth. Credit it as SDD and you are using someone else's label.

Antigravity does not use the phrase either. Its homepage tagline calls it "our agentic development platform, allowing anyone to build in the agent-first era." The docs describe Visual Artifacts as a way to "Track and verify agent output (plans, code diffs, browser recordings) with high-fidelity visual reports". It produces a reviewable plan artifact alongside code, just not under that label.

The category is being assembled by the people writing about it, not the projects in it. Check what a project says about itself before you cite it.

The move underneath the different names

Strip the branding and the mechanic is close to identical: produce a written statement of intended behaviour a person can read, and put it before generation. Five of the six do exactly that. Antigravity is the looser fit: its docs present Plan as an artifact for tracking and verifying agent output, which puts review alongside the work rather than in front of it. What varies is granularity and where the artifact lives.

Different shapes, one bet: the expensive thing is not writing code, it is agreeing on what the code should do.

What a spec is actually for

Not documentation. Not process. Not speed. A spec is the reviewable artifact, for four reasons:

  1. Intent is smaller than implementation. A page describing what a system does and refuses to do is shorter than the code that does it, so a human can read it through.
  2. Intent is stable across regenerations. Regenerate the code and the diff is entirely new. The spec did not move, so what you approved last week still stands.
  3. Intent is checkable by someone who did not write it. A reviewer can say the error handling is missing without reading a function.
  4. Intent makes wrongness visible. You cannot look at generated code and see the requirement it never implemented. You can see a spec section that is empty.

The tradeoff is real: the spec is front-loaded work, and wasted when the thing is disposable. Vibe coding is a fine trade for a throwaway, and a bad one the moment someone else has to maintain the result, or the system takes an action you cannot undo.

Chip Huyen, on why her book AI Engineering (O'Reilly Media, 2025) covers fundamentals instead of specific tools: "Tools become outdated quickly, but fundamentals should last longer." Some of the tools above will be renamed, absorbed or abandoned. The move under them is what lasts.

Where this fits if you use Bespoke Prompting

Bespoke Prompting is a spec generator aimed at the AI system rather than application code. From a plain-language description it emits a fixed section set: the Agent build type produces ten named sections, including a TOOL_REGISTRY where every tool carries five parts. One is what to do if it fails, which must name a specific fallback, such as retry once then fall back to Y, never "handle the error". A missing decision is visible on the page, so the argument happens over the spec rather than over behaviour you discover in production.

Sources

Suggested internal links