Spec-Driven Development for Software. Coming Soon to Hardware, Too?

In the 1990s, the accepted best practice was to fully specify software before writing the first line of code. First came the requirements specification, then the design specification, and finally the implementation. This approach did not work. The specifications were outdated before the product was finished, and it often turned out later that the requirements were wrong. From this experience grew the agile movement and, later, DevOps: small steps, executable code with unit tests as the gold standard, and documentation only where it makes sense—often stored directly in the code or in Git.

Generating code from models was a related idea, but one we only see in niche applications. The code itself was a disposable artifact that no one touched. The effort involved in creating models, however, was quite high. Now this very idea is making a comeback, driven by AI coding. Specifications are still being defined; code is generated anew at the push of a button, and a model is no longer needed for this. The AI handles the translation.

History

The idea of generating code from a higher level of abstraction is an old one. Around the turn of the millennium, the Object Management Group coined the term Model-Driven Architecture. Tools such as Rational Rose promised to generate executable code from UML diagrams. In 2002, Mellor and Balcer described "Executable UML," a variant in which the model itself was executable and code generators produced the target language.

In practice, little of this remained. The diagrams were either too crude for complete code or so detailed that they themselves became a programming language—albeit with a poorer editor. The generated code was difficult to debug. As soon as a developer modified it by hand, the coupling to the model was broken. The effort required to maintain a model from which code could be reliably generated was often greater than the effort required to write the code directly.

Model generation has only gained traction in areas where the domain is narrow and the benefits are compelling. In the automotive industry, engineers model control algorithms in MATLAB Simulink, simulate their behavior at the model level, and use that to generate certified C code for control units. No one touches this code. If the control strategy changes, the model changes, and the code is regenerated. This works because certification according to ISO 26262 requires complete traceability, and handwritten code makes meeting this requirement costly.

Vibe Coding: Code is often left untouched

AI coding is making these ideas interesting again. Anyone using a tool like GitHub Copilot or an agent-based assistant today simply describes in natural language what they want to create and receives executable code in return. The term “vibe coding” describes a more casual version of this: you enter a prompt, roughly check the result, and regenerate it if needed. Programming skills are hardly necessary anymore.

Thus, the old vision of model generation has come to fruition, albeit indirectly. The code is once again a disposable artifact, except that the higher level of abstraction is no longer a UML diagram, but rather text in natural language. The expensive model is no longer needed because the AI handles the translation.

The catch lies elsewhere. With vibe coding, no formal specification is created. The prompt is issued, the code is generated, and the prompt is then forgotten. Anyone who asks six months later why a function behaves the way it does will get the same answer as in the pre-AI era: read the code. The specification exists only fleetingly in the chat history, if at all. That’s enough for a prototype. But for a system that runs for years and is maintained by rotating teams, it’s not enough.

Drivers: Compliance and Scalability

There are two reasons why a well-maintained specification is still valuable, and both are becoming more urgent due to AI coding:

1. Compliance. Regulated domains require traceability from the requirement to the code. Regulated products, such as medical devices or vehicles, require a verifiable specification and proof that the implementation meets it. If the code is regenerated at any time, the specification is the only stable reference against which compliance can be determined.
2. Scalability. A precise specification can be broken down into non-overlapping parts that multiple AI agents work on in parallel. A vague prompt yields slightly different results with each run, and the more agents are involved, the more the results diverge. The specification is the common contract that holds the parts together.

Both factors lead to the same conclusion: The prompt must evolve from a fleeting chat entry into a permanent, versioned artifact. This is precisely where Spec-Driven Development comes into play.

The paper

A Technical Report by Deepak Babu Piskala Published in January 2026, the report summarizes the approach for practitioners. Spec-Driven Development, or SDD for short, reverses the usual relationship. The specification is the source of truth; the code is a derived artifact. The report classifies the practice into three levels of rigor and describes a four-phase workflow: specify, plan, implement, and validate. Each phase produces an artifact that constrains the next, with human review at each transition.

The author has noticed that AI models are very good at filling in patterns but poor at reading minds. A prompt like „add photo features to my app“ forces the model to make dozens of unstated assumptions about format, rights, size limits, and storage location. A precise specification anticipates these assumptions. The report cites early controlled studies that measured an error reduction of up to 50 percent through human-refined specifications. This figure should be interpreted with caution—the data is sparse—but the trend aligns with experience.

The author’s own assessment is noteworthy. He quotes Bryan Finster as saying that SDD is not a revolution, but rather BDD with better marketing. What’s new isn’t the ideas, but the tools that make executable specifications practical, and AI as a consumer for whom specification quality directly determines the quality of the results.

SDD isn't a revolution; it's just BDD with better marketing

Bryan Finster: 5-Minute DevOps: Spec-Driven Development Isn’t New

From Vibe Coding to Spec-as-Source

The report identifies a spectrum that can be used to classify the maturity level of SDD. At one end is code-centric development: code first, documentation later, with drift being the norm. Vibe Coding without a well-maintained specification falls squarely into this category. At the other end is “Spec-as-Source”: the specification is the only thing people work on; code is generated exclusively and never touched by hand. In between lie two intermediate stages.

1. Ad hoc. There are no specifications; there are only prompts, which are not saved. If anything is unclear, the AI is consulted on an ad hoc basis.
2. Spec-First. The specification is created before the code and guides the initial implementation. After that, it’s allowed to evolve. The benefit lies in the initial clarity, and the maintenance effort is minimal. This approach works well for prototypes and one-off features.
3. Spec-Anchored. The specification coexists with the code throughout its entire lifecycle. Any change in behavior requires a change to both. Tests derived from the specification enforce this coupling. If the code and specification drift apart, the build fails. For most production systems, this is the appropriate approach.
4. Spec-as-Source. The specification is the source code, only at a higher level of abstraction. Drift is ruled out by design, because code is regenerated rather than modified manually. This requires mature, reliable generators. Simulink in automotive engineering is a well-established example; tools like Tessl are aimed at general software development.

The further to the right, the greater the authority of the specification and the greater the discipline required. The right choice is the lowest level that eliminates ambiguity in the given context. Spec-First for AI-assisted initial development, Spec-Anchored for long-lived systems, and Spec-as-Source only once generation is reliable.

BDD takes a similar approach, but without AI

Anyone familiar with the idea that specifications and testing should be closely linked has probably heard it referred to as Behavior-Driven Development implemented. BDD defines goals, requirements, and results in such a way that they can later be executed as automated tests. Specifications and tests are extremely closely linked, allowing for automatic verification of whether a requirement has been met. This is spec-anchored, just without AI involved.

BDD solves exactly the same problem that SDD solves for AI—only for humans. Otherwise, developers and product owners argue over what „done“ means. An executable specification makes the definition verifiable rather than debatable. A feature is done when its scenarios and associated unit tests pass.

The difference between BDD and SDD is smaller than marketing would have you believe. BDD writes the specification for a person who then implements the code by hand. SDD writes it for a model that generates the code. The specification itself, its role as a contract, and its coupling to tests remain the same. Anyone who has taken BDD seriously in systems engineering is better prepared for SDD than someone starting from scratch.

What about systems engineering?

So far, we’ve been talking about software. The title poses a more interesting question: Can this approach be applied to hardware? As long as code is a disposable artifact that AI can regenerate in seconds, it works. But mechanical or electronic components cannot be produced as easily as software, despite 3D printers and other rapid manufacturing approaches. The challenge is even greater when the physical artifacts are already in use at the customer’s site.

The solution is not to treat hardware like software, but to keep it out of the generable part. The way to do this is through platform-based thinking. You define a hardware platform that can be controlled via clear interfaces and then lock it down. As long as the platform is fully accessible via its APIs, all variability shifts to the software.

That’s exactly where SDD comes into play again. The variations in the product are embedded in the software and can therefore be specified and generated. The hardware remains stable and serves as the execution environment. Tesla’s feature set changes via over-the-air updates on unchanged hardware. The power of the platform is even more evident in smartphones. Android delivers entirely new features securely via apps without changing anything on the device. In both cases, the hardware is the platform, and the value creation shifts to the software.

This brings us back to the original question. SDD doesn’t result in hardware simply because metal sheets and gears “grow” out of specifications. It happens because a clean platform with full API control abstracts away the hardware and shifts the remaining complexity to where specification and generation actually work.

Conclusion

We’ve come full circle back to the past. What failed in the 1990s—specification before code—is making a comeback because costs have shifted. Back then, creating and maintaining the higher level of abstraction was more expensive than the code itself. Today, AI handles the translation, and the code is becoming cheap enough to be treated as a disposable artifact. As a result, the specification is once again a worthwhile investment.

In practice, this means three things. Anyone who practices “vibe coding” and lets the specification languish in the chat history is throwing away their real leverage and inviting back the drift problems of the ’90s. Anyone who needs compliance or scalability should turn the prompt into a versioned artifact and select the appropriate level—usually “spec-anchored.” And anyone working in systems engineering should think in terms of platforms first. Only when the hardware is fully controllable via APIs and the variability is embedded in the software can the method be applied to physical products. The question then is no longer whether SDD is suitable for hardware, but how cleanly the platform is designed.