From Vibe Coding to Spec-Driven Development (SDD): 2026 Guide and Tools (Kiro, Spec Kit, Tessl)

This Turing Post article, written by Alyona Vert and Ksenia Se, tackles an increasingly relevant debate in AI-assisted software development: why so-called "vibe coding" —that flow of prompt, generated code, patch, repeat— becomes fragile as projects grow, and how Spec-Driven Development (SDD) proposes to fix it.

The text opens with a brief historical review that helps contextualize the idea: from the procedural programming of C or Fortran, through SQL in the 1970s (where the desired result was already described instead of the exact procedure), to the attempts at Model-Driven Development and Behavior-Driven Development in the 2000s. All of these approaches sought, in one way or another, to separate intent (the "what") from implementation (the "how"). The current era of generative code assistants and autonomous agents took that logic to a different extreme: vibe coding, which drastically lowered the barrier to entry for programming but introduced a structural problem: there is no persistent plan, the results are non-deterministic, the requirements live scattered across the chat history, and prior decisions can be overwritten by later changes. The result is fragile architecture and agents that get "lost" on complex tasks.

The article's central proposal is SDD as a middle ground between the rigor of MDD/BDD and the flexibility of vibe coding. The specification becomes the central artifact and the "source of truth": a structured, versioned and machine-readable description of what the system must do, what constraints it must meet, how it must behave and what user stories it satisfies. It cites Marc Brooker, a distinguished AWS engineer specializing in agentic AI, who sums up the idea by noting that SDD allows the coding agent to move forward without backtracking, giving it the context needed to build software continuously. According to the article, the specification serves a dual function: it is used to build and maintain the software, and to build the testing infrastructure around it.

The workflow is organized into an inner loop and an outer loop. The inner one —which an agent can run autonomously— consists of writing or updating the specification, generating code and tests from it, running the code against those tests, iterating until they pass, and verifying that the tests remain aligned with the original specification. The outer loop puts that software in front of real users, gathers feedback, updates the specification and triggers the inner cycle again. Verification is integrated into CI/CD pipelines, and engineers can define invariants (idempotence, monotonicity, state consistency, etc.) that the AI system automatically stresses by generating large input spaces. The article connects this to neurosymbolic AI: LLMs propose implementations and refactors in natural language, while symbolic systems —constraint solvers, rule engines, formal methods— verify logical consistency.

Among the benefits the text highlights: greater repeatability and scalability of the code, the ability to explicitly encode what counts as good or bad output and refine it over time, testing and verification integrated as part of the flow itself, agents capable of operating autonomously for longer periods without getting lost, and changes recorded in the versioned specification rather than in an ephemeral chat history.

The second half of the article reviews three concrete tools that embody this approach. Kiro, from AWS, is an AI IDE built explicitly around SDD: specifications are organized as directories of structured markdown, and user stories are automatically rewritten in EARS format (Easy Approach to Requirements Syntax), a controlled language with patterns like "WHEN <trigger>, the system SHALL <response>" that makes each requirement directly verifiable. Kiro also incorporates property-based testing —defining general properties the output must satisfy as a function of the input, instead of manual example cases— and announces, as a future capability, detection of ambiguities in the specification using neurosymbolic techniques. The article cites figures AWS reports on the use of Kiro: a re-architecture project estimated at 18 months and 30 engineers was completed in 76 days with 6 engineers, and Socure (a digital identity verification company) completed a three-week Scala-to-Go migration in two days. It should be noted that these figures come directly from AWS/Kiro as cited by the article, and not from an independently verified source.

Spec Kit, from GitHub, implements development as a fixed pipeline of artifacts executed via CLI commands: /speckit.specify, /speckit.plan, /speckit.tasks and /speckit.implement, each generating a concrete artifact that feeds the next, so that the agent cannot skip planning. It also includes a project "constitution" file that sets persistent rules (testing standards, performance budgets, code style, UX constraints) applied to all future specifications. The key difference from Kiro is where the planning logic resides: in Spec Kit it is externalized into explicit commands and artifacts, whereas in Kiro it happens inside the loop of a single autonomous agent.

Tessl, for its part, structures the agent's context as installable packages: versioned documentation, coding-standard rules always injected into the context, and "skills" or procedural flows. These elements are packaged into installable "tiles" via a proprietary package manager, and Tessl organizes SDD around three persistent artifacts —plan, spec and tests— that remain in the repository so that future agent runs reuse them as context. Its Spec Registry, according to the article, contains more than 10,000 usage specifications aligned with specific library versions, allowing agents to install structured context instead of relying only on the model's training data.

The article also clarifies where popular tools like GitHub Copilot, Claude Code and Cursor fit: although they can participate in an SDD flow, they operate fundamentally through a prompt-reasoning-code loop where the specification exists only implicitly in the chat, so they are considered execution agents rather than SDD frameworks proper.

Finally, it offers a practical guide on when to use SDD and when to avoid it. It is best suited for large, long-lived codebases, teams using multiple AI agents (where the specification acts as a model-independent source of truth), product development with many features, and enterprise environments where specs can encode regulatory compliance rules and architecture standards. On the other hand, it is less suitable for rapid prototyping, highly exploratory development with changing requirements, low-complexity scripts or utilities, and for research or algorithm development where writing the specification could take longer than the code itself.

Overall, the article frames SDD not as a total replacement for vibe coding but as a layer of discipline and verifiability for scenarios where reliability, traceability and scalability matter more than pure iteration speed, offering a useful overview —though based largely on materials and figures provided by the makers of the tools mentioned— of where AI-agent-assisted software engineering is heading.