What is Spec-Driven Development?
Delivery & EngineeringAI-assisted development where the requirements are written down first and the agent generates code against them. The spec is the contract: it version-controls with the code, and the output is judged on whether it satisfies it.
Why It Matters
Spec-driven development is the other answer to a question every AI-assisted team now faces: how does the agent know what to build? Vibe coding answers conversationally: describe, generate, react, repeat. Spec-driven answers on paper. The requirements, constraints, and acceptance criteria exist before the first line of code, and the agent works against them.
What changed is the tooling. Early AI coding tools took a prompt and produced a snippet. Newer tools take a structured spec, what to build, for whom, under which constraints, and produce a plan, then a task list, then code that traces back to the requirements. GitHub’s Spec Kit made the pattern concrete: the spec is the agent’s primary input, not a document nobody reads.
How It Works
The workflow inverts the usual order. Intent gets written down first, the agent plans against it, then code generates against the plan. Each stage reviews the one before: is the plan faithful to the spec, is the code faithful to the plan. Changes go through the spec rather than around it, so when intent changes the spec updates first and the code follows.
That makes the spec the single artefact that stays true, which is why the approach suits work where what to build is itself the contract: regulated domains, large scopes, and teams where the person writing requirements and the person checking code are not the same.
Where It Breaks
The upfront cost is real. Writing a spec good enough to generate against takes hours that conversational iteration does not need, and for exploratory work, where the requirements only become clear by building, a spec written first is a guess written formally. It is the wrong tool when the unknown is the requirements themselves.
Specs also rot like any document. Once code drifts ahead of the spec, the spec stops being the contract and becomes one more artefact to maintain. And a wrong spec does not produce a wrong answer. It produces a confident, complete, thoroughly reviewed wrong system, which is the failure mode of precision aimed at the wrong target.
How Flytebit Handles It
We treat spec-driven and conversational development as a scope decision, not a religion. Bounded work with a defined quality bar, reviewing a pull request against agreed dimensions or generating tests against stated coverage goals, runs spec-driven because the contract is known up front and the agent works inside it. Exploratory work, prototypes, and early feasibility run conversational, because the spec would be fiction.
The feasibility study is where the choice gets made. The deciding questions: how well understood is the outcome, how large is the blast radius of a wrong build, and who reviews what the agent produces.