Guide

Spec-Driven Development: why specs are replacing vibe coding

Published 19 September 2026 · Updated 8 October 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, which raises the question of what belongs in that writing.

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, I'd have to really read through it for a while.

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 Agent skills carrying a feature from constitution and spec through plan, tasks, implementation and convergence Yes, in the README
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 Skills carrying briefs, specifications and architecture around a delivery loop No, see below
Antigravity Google Implementation plan artifacts before changes, walkthrough summaries after No, see below

Four specifics, since the labels blur:

  • Spec Kit describes itself in its repo description as a "Toolkit to help you get started with SDD or any other process!", and its README calls it "an open source toolkit that gives AI coding agents structured processes, reusable templates, and documented outcomes". Its README invokes the work as hyphenated skills, /speckit-constitution once per project and then /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement and /speckit-converge per feature, and says plainly that "These are agent skills, not terminal commands" and that other agents and modes may use different invocation syntax. Check the repo for the current set rather than a write-up.
  • 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 repo frames itself as "Agile Ai Driven Development", and names "Durable context" among its principles: carrying product and technical decisions forward instead of re-explaining them in every chat. 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." Its docs list visual artifacts as a feature that "Tracks and verifies agent output (such as plans, code diffs, and browser recordings) with high-fidelity visual reports", and document two of those types. Of the first: "The agent uses the implementation plan artifact to architect changes within your codebase to accomplish a task." Of the second: "The agent creates walkthrough artifacts when it completes task implementation." So it puts a reviewable plan in front of the changes and a summary after them, 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. All six do exactly that. Antigravity makes it a setting rather than a premise: in Planning mode the agent "produces structured implementation plans called artifacts", and the artifact review policy decides whether "The agent always halts and requests your explicit approval before proceeding with proposed changes" or "never halts for manual review and immediately proceeds with executing its plans", while Fast mode "executes tasks directly without a dedicated planning phase". What varies is granularity, where the artifact lives, and whether the gate can be switched off.

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