As AI joins us in software development, one important question becomes hard to avoid: how safe is this, really? Vibe coding has brought convenience, speed and fun to the world of programming and reduced the barrier to entry into it – but it also came with a large amount of low-quality, unstructured code, the kind of “AI coding slop,” that triggers everyone.

But if giving up vibe coding seems too radical, is it possible to make it safe and effective? How to find that source of truth which will help AI-generated code stand on firm ground?

How AI would say: Enter Spec-Driven Development (SDD).

The idea is to put everything – user stories, requirements, system behavior, constraints, acceptance criteria, features – into one place, called specification, and the coding process starts with it. It becomes the base of rules with defined goals, which acts as a map for coding agents to not get lost in the sea of prompts.

Today we’ll look at why SDD can be a more reliable alternative to vibe coding, and walk through the main SDD tools you can use right now.

And if SDD is a roadmap for coding agents, we hope this article will be your roadmap to SDD.

P.S. Special thanks to Marc Brooker, VP and Distinguished Engineer for Agentic AI at Amazon Web Services (AWS), for walking us through the key aspects of SDD.

In today’s episode:

For decades, programming meant telling the computer exactly how to do things. Early languages like C or Fortran were purely procedural: loops, memory, control flow — every step explicitly written by the developer.

Then in the 1970s, SQL introduced a radically different idea. Instead of describing the procedure, you described the desired result, for example: SELECT name FROM users WHERE country = 'US'

You didn’t specify indexes, joins or execution plans, and the database figured out the implementation. In many ways, SQL was one of the first mainstream examples of spec-driven programming – you provide the specification, the system handles the execution.

In the 2000s, the industry tried to push this idea further with Model-Driven Development (MDD). Engineers would design systems using formal models, like UML diagrams or domain models, and tools would generate the code automatically. This ensured the system is built with correct architecture and logic. In theory, this was great because models would become the main artifact and code would just be a byproduct. But in practice, the tooling was rigid and developers often ended up fighting the generated code. Another option was Behavior-Driven Development (BDD) that focuses on user behavior and ensures the system does the right thing from a business perspective.

Now we are in the next era of coding brought by generative AI like code assistants and autonomous agents. It gave us what programmers of the past could only dream of: translating natural language in working code, modifying large codebases, easier generating tests, refactoring systems, etc.

Vibe coding is a kind of peak moment in the use of AI as a co-coding assistant. It goes prompt by prompt, and more concretely the workflow looks like: developer writes prompts → AI generates code → developer patches with more prompts to refine and fix bugs → repeat. This works surprisingly well and brings the simplicity to the coding process, so much more users became able to do coding. But at the same time it is very fragile:

This happens because vibe coding lacks structure: a foundation of rules and constraints, verification systems, something like an inner compass for your agent that defines what “doing it right” means and prevents it from getting lost between iterations. Spec-driven development aims to solve this.

Spec-Driven Development (SDD) is an attempt to reintroduce formal structure, scalability and provable correctness into AI-assisted software development. It lives somewhere in the middle between MDD, BDD and vibe coding.

In SDD, the rules and the constraints are much more explicit and the main part that SSD is built on is →

How to do that? →

Everything starts from specifications in SDD, which becomes its central object. If we talk about the inner compass of coding agents, then specification is a machine-readable North Star, that gives a persistent global objective for generated code.

More concretely, a specification means structured description of:

Marc Brooker highlighted that specification is used twice:

Specification defines what software needs to do and what can be used to build the working pieces of software, tests (including UI, unit, integration and other testing), formal verification, etc.

Spec-driven development is a much more iterative process than vibe coding. You can think of it in terms of inner and outer loops: the inner loop is goal-seeking execution, building software that matches the current spec, while the outer loop is where that software meets the real world.

The inner loop includes the following stages, which an agent can run fully autonomously:

Then the outer loop puts the software in front of users, teams, customers, gathers their feedback on new features, changes and fixes, updates the specification, and trigger the inner loop again to implement changes. Everything is a continuous cycle of iterations of making the software and the spec better to the real world use, and, most importantly, correctness becomes enforced continuously.

Overall, this means specification is not treated as a separate research layer. You can have as many specifications as you need, and they all live inside version control and are integrated directly into the software development life cycle (SDLC). Engineers define invariants, such as idempotence, monotonicity, commutativity, state consistency, and the AI system then generates large input spaces to stress those properties automatically. Verification becomes a part of continuous integration and continuous delivery (CI/CD pipelines) – AI agent reads and updates specification, plans work from it, validates changes against it. Faults are caught immediately, and only verified changes move forward.

With specification, an autonomous agent finally gets a map of how to move to the defined goal correctly. The specification is the primary artifact, while code becomes a derived artifact.

So what does SDD actually add beyond vibe coding?

This is also interesting from neurosymbolic AI side. LLMs generate implementations, propose refactors and reason in natural language. But symbolic systems – constraint solvers, rule engines, formal methods – check logical consistency and enforce invariants. In this workflow, the neural part proposes, and the symbolic part verifies.

Now, let’s talk about how SDD is realized in practice.

It was actually AWS’s Kiro that confirmed our sense that SDD is becoming an important trend. Kiro is an AI IDE built explicitly around spec-driven development, designed to address the instability of vibe coding.

It works according to the workflow we described above, starting from writing a specification as a directory of structured markdown documents describing what the software should do: from a single file for a small CLI tool, to multiple files covering UI, backend, dependencies, etc. Then it goes through the general loops of SDD.

Inside Kiro, user stories and acceptance criteria are automatically rewritten into EARS form, the Easy Approach to Requirements Syntax (EARS), a structured way to write requirements using controlled natural language patterns such as:

WHEN <trigger>, the system SHALL <response>
WHILE <condition>, the system SHALL <response>
IF <error condition>, THEN the system SHALL <response>

So EARS is the syntax used inside files like requirements.md. This structure makes each requirement directly verifiable and eliminates the vague assumptions that typically cause AI systems to misinterpret prompts.

AWS are working on extracting specifications from existing code, then use them to add features or maintain the codebase. They also keep adding more types of specs to give developers more control.

But one of the most important extensions in Kiro is property-based testing. You don’t need to manually write individual example test cases like “input X → expect Y”. Instead, you define general properties that the output must satisfy as a function of the input. The system then automatically generates many different inputs and checks whether those properties hold. For example, instead of manually testing a square root function with a few numbers, you define the property that the result squared should approximate the original input. Property-bested testing can work in other domains like UI, for example, so it gives a better coverage then general way of testing.

Another interesting Kiro’s capability that is not currently live but is coming soon is spec ambiguity detection with neurosymbolic techniques. Kiro will be able to formally reason about a specification to find ambiguities and internal inconsistencies, and then highlight them to the developer for clarification.

AWS reports an impressive acceleration and more reliable code quality with Kiro’s spec-driven approach. For example, a rearchitecture project estimated at 18 months and planned for about 30 engineers was completed in 76 days with just 6 engineers. Socure, digital identity verification and fraud prevention company, completed a 3-week Scala to Go migration in 2 days. Pretty nice.

Another interesting variant of SDD tool is GitHub’s Spec Kit, which implements development as a fixed artifact pipeline executed through CLI commands. The workflow is enforced as: spec → architecture plan → task graph → implementation.

Each stage is triggered explicitly:

Every stage produces a concrete artifact consumed by the next one, that’s why the agent cannot skip planning and jump directly into code.

Spec Kit also introduces a project constitution (/speckit.constitution) file which defines persistent rules, such as testing standards, performance budgets, coding style, UX constraints and others. They are applied to all later specs and implementations. Actually, it acts as a policy layer controlling how the AI generates code.

The difference with Kiro is where the planning logic lives: Spec Kit’s workflow is externalized into explicit commands and artifacts, while in Kiro, planning happens inside a single autonomous agent loop. So Spec Kit therefore functions as a workflow engine for AI coding, while the AI agent serves as the execution layer that converts specs and plans into code.

Tessl is a platform that structures agent context as installable packages consumed during development. It manages three types of context:

These elements are bundled into tiles which are structured context packages that agents install through the Tessl package manager.

Agents receive context through two mechanisms:

Tessl organizes SDD around three persistent artifacts created before code changes: plan → spec → tests. Plans act as an execution roadmap, specs capture product intent, and tests enforce behavioral correctness. These artifacts remain persistent parts of the repository, so future agent runs reuse them as context.

Speaking about the repository, one of the core component in Tessl is repository of structured specification packages, called Tessl Spec Registry. Instead of relying on model training data or web search, agents can install structured spec packs directly into a project. Spec packs can also encode internal APIs, company tech stacks, architectural rules and engineering policies. The registry currently contains 10,000+ usage specs, each aligned with a specific library version.

Tessl also includes an evaluation framework that measures how well context improves agent behavior.

If we compare Tessl with Spec Kit, we’ll see that Spec Kit focuses more on workflow orchestration, while Tessl adds long-term specification storage and reusable knowledge packages that agents consume during development.

Now let’s look at where the most familiar coding assistants fit. You might have seen claims that tools like GitHub Copilot, Claude Code, and Cursor can be viewed as versions of SDD in practice. But the thing is, they operate primarily through a prompt → reasoning → code loop, where the model infers requirements, architecture, and implementation from conversational context. The specification exists only implicitly in the prompt or chat history.

SDD systems, in contrast, introduce explicit specification artifacts that drive implementation: plans, specs, tests or task graphs that persist independently of the agent. And this is their core defining feature. So in practice, Copilot or Claude Code can participate in an SDD workflow, but they are execution agents rather than SDD frameworks.

Some people may like the Spec-Driven Development approach because they’re tired of unreliable vibe coding. Others may think it’s too time-consuming, since you can spend more time defining interfaces, writing behavioral constraints, describing user stories, and specifying invariants than actually coding. If you’re trying to decide whether SDD fits your workflow, here are a few tips to help you choose.

Where SDD works best:

And now, where SDD is less suitable:

But still specifications can give a great foundation, because when you have the map, you can build something greater and more optimized.

AWS believes that SDD is how software will be built in the future, because it explicitly defines what software needs to do, how it should work, and, furthermore, how the coding process is checked and updated. There is a solid focus on testing and verification, and therefore on quality and more consistent results customized for user needs.

Whether SDD becomes a core coding style or not, two things are obvious now:

Resources from Turing Post