The spec is the new source code: how spec‑driven development works

I.From vibes to contract

For two years the dominant way to code with AI was what the industry now derides as vibe coding: describe the goal in a chat box, accept whatever appears, iterate until it compiles. Spec-driven development is the correction. As Pachi Parra's practical introduction puts it, SDD starts from a written specification — what the system should do, how it behaves in every scenario, which constraints it must obey — and treats the AI agent as the executor of that contract rather than a slot machine. The idea is old; the tooling wave is new. GitHub open-sourced Spec Kit on September 2, 2025, AWS took Kiro — an entire IDE built around specs — to general availability on November 17, 2025, and JetBrains co-produced a DeepLearning.AI course on the method. In under a year, "write the spec first" went from blog-post advice to the default workflow shipped by two of the industry's largest platform vendors.

The reason is mechanical, not fashionable. GitHub's engineers describe coding agents as "literal-minded pair programmers": given a vague prompt, a model guesses at thousands of unstated requirements, and every guess is a place the result can silently diverge from intent. A spec converts guesses into decisions made once, in writing, where a human can check them.

II.The four files

SDD's entire mechanism is a chain of Markdown artifacts, each generated by the agent from the previous one and each gated by human review. In Spec Kit's canonical form, slash commands (/speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement) produce four files:

AWS Kiro implements the same chain as requirements.md, design.md, and tasks.md, writing acceptance criteria in EARS notation (a controlled natural language for requirements inherited from systems engineering), plus persistent "steering" files for team conventions. Optional passes — /speckit.clarify to interrogate ambiguities, /speckit.analyze to check the artifacts against each other, /speckit.converge to detect drift between spec and codebase — round out what practitioners describe as a seven-phase loop: constitution → specify → clarify → plan → tasks → implement → analyze.

III.Why now: the trust gap

The adoption math explains the timing. Google's 2025 DORA report (≈5,000 professionals, September 2025) found 90% of developers using AI, a median of two hours a day working with it, and over 80% reporting productivity gains — while only 24% expressed high trust in AI-generated code. Stack Overflow's 2025 survey found the same shape: usage at 84% and rising, trust at an all-time low. That combination — everyone uses it, nobody trusts it — is precisely the condition a verification-forward workflow resolves. SDD moves human attention from the least reviewable artifact (ten thousand lines of generated diff) to the most reviewable one (a page of declared behavior), and the agent's compliance with tasks.md is checked by tests, not by eyeballing.

IV.What actually changed about coding

In an SDD shop the developer's day inverts. The morning's work is writing and reviewing prose: sharpening the spec, answering the agent's /clarify questions, editing the plan's architecture before a line exists. Implementation — formerly the job — becomes a supervised batch process. Pull requests increasingly lead with the spec diff, because that is where a reviewer can still catch a wrong decision cheaply; by the time it's code, the error is expensive and camouflaged. The senior skill shifts from knowing how to build to specifying what and constraining how — and the constitution file quietly becomes the most leveraged document in the repository, since every future agent run inherits it. GitHub's own guidance says the method pays off in three settings: greenfield builds, feature work in existing systems, and legacy modernization — which is to say, most professional software work, and a natural companion to labs' own disclosure that AI already authors the majority of code at the frontier.

V.Standard, or ceremony?

Calling SDD "the new industry standard" outruns the published evidence, and the honest read says so. The momentum is real: a 124k-star reference toolkit, a spec-native IDE from AWS, native workflows in Claude Code and Cursor, and a crowded second ring (OpenSpec, Tessl) mapped by practitioners. But the same survey warns that quantified benefits — higher first-pass agent success, error reductions — are vendor-reported and "directional, not proven." The skeptic case has four teeth: SDD can be waterfall repackaged, front-loading decisions that exploratory work can't make yet; specs drift from code the moment pressure rises, and /converge is a mitigation, not a law of physics; over-specified specs degenerate into pseudo-code, re-creating the work they were meant to replace; and a perfectly implemented wrong spec yields confident failure. Practitioners' own guidance is to skip SDD for throwaway prototypes and genuinely exploratory work — a scoping the loudest advocacy omits.

VI.The toolbox: repositories and tools worth starring

Six tools define the SDD landscape in mid-2026. Three are open-source repositories; three are commercial products. The one hands-on comparison across all of them — Augment Code's tested roundup (greenfield API, brownfield Express.js feature, four-service refactor) — is useful but sells its own entry, so its comparative verdicts are read here as vendor claims. The structural split it identifies is real, though: static specs (written once, drift as code evolves) versus living specs (updated as agents implement).

Choosing between them reduces to two questions. Does the work live in one repo or across services? — single-repo teams are served by Spec Kit or OpenSpec for free; multi-service coordination is where static Markdown breaks and platform-scope tools argue their fee. And do requirements hold still? — stable, well-understood domains suit static specs (Kiro, Spec Kit); evolving multi-session work either needs living specs or the discipline to re-run /speckit.converge religiously.

VII.How it plays out: three scenarios

Horizon 2026–2029. Probabilities are analytical judgment, not measurement.