Spec-driven development, Scrum, SAFe, and waterfall: what works when
Spec-driven development (SDD) is a methodology that treats specifications as executable contracts from which AI agents derive code, preventing architectural drift through automated enforcement rather than passive documentation. The question is where it sits among the established methods, what stays and what changes.
Four methods, four promises, four realities. When does what fit, and why have the old specifications suddenly come back into fashion.
Software and embedded projects have been cooked from the same ingredients for decades: requirements, architecture, code, test, release. What changes is the order, the pace and the responsibility. A status check from the engine room.
Waterfall: the V-model and the regulated industries
Waterfall has a bad reputation, but it is the method a pacemaker, a brake system or a nuclear plant controller actually needs. In the regulated worlds of medical (IEC 62304), aerospace (DO-178C), automotive (ISO 26262) and nuclear, there is no way around a complete specification, an architecture, a verification against exactly that specification, and traceability of every line of code back to a requirement.
Strengths: traceability, formal reviews, audit fitness, risk management with documented state of the art.
Weaknesses: late feedback. Requirements bugs only become visible in the system test, sometimes only at the customer. Anyone who finds out two years after the requirements document that the underlying idea was wrong has an expensive day.
Waterfall works where requirements are stable and expensive to get wrong. It does not work where requirements emerge while the product emerges.
Scrum®: short loops, no architect
Scrum has made big in the web world what was always common practice in embedded: deliver in short cycles, test early, correct early. Two to four week sprints, a Product Owner with a backlog, a daily, a review, a retro.
Strengths: fast feedback, built-in opportunity to change course, clear responsibilities inside the team.
Weaknesses: the framework says nothing about architecture. It silently assumes that someone is around who keeps the architecture in their head and maintains it on the side. For pure application work that is often fine. For an embedded product with hardware, drivers, safety requirements and certification, the architecture is not built by a daily stand-up.
Second weakness: scaling. Three Scrum teams on one product are three backlogs, three refinements, three reviews, and the question “what gets integrated when” sits in no part of the framework. That is exactly where SAFe® gets sold.
SAFe: Scrum with floors
The Scaled Agile Framework adds a planning layer on top of multiple Scrum teams. An Agile Release Train (ART) bundles five to twelve teams, a Program Increment (PI) plans eight to twelve weeks ahead. Above the ART sits the Solution Train, and above that the Portfolio.
Strengths: when fifty developers work on one product, you need a planning rhythm. SAFe delivers that rhythm with PI Planning, a two-day event where all teams exchange dependencies and converge on a shared plan.
Weaknesses: SAFe is surrounded by a consulting industry that sells every role (Release Train Engineer, System Architect, Solution Train Engineer, …) as a separate full-time job. In practice the teams spend a significant share of their time in PI Planning, ART Sync, System Demo, Inspect and Adapt and similar events. The agile promise (“fast adaptation”) softens when course can only be changed every ten weeks.
SAFe pays off when the alternative “five independent Scrum teams that constantly miss each other” is actually more expensive than the methodological overhead. With one or two teams, SAFe is the wrong hat.
Spec-driven development: the small waterfall
Spec-driven development (SDD) is at heart a small waterfall. You write the specification first, then the code, then the tests, in that order, exactly like the V-model. The difference is that the whole thing does not take two years but a few hours or days, and at the end of an iteration there is not a release but a running increment that flows into the next small waterfall.
That brought an old word back into fashion in the last two years: specification. This time differently. Instead of a document that is written once and then overtaken by reality, the specification is now the continuously maintained source from which code, tests, documentation and verification are generated or against which they are checked.
The drivers are the AI coding agents. When a Large Language Model (LLM) produces a working piece of code with tests from a precise specification in minutes, the specification itself becomes the most valuable artifact in the repository. Code becomes cheap, the specification becomes expensive. Tools like GitHub Spec Kit, Anthropic® Claude Skills or commercial platforms automate exactly that step.
The idea itself is not new. Formal methods (TLA+, Z, B, Alloy) and Model Driven Engineering (MDE) with UML, SysML or MathWorks Simulink® have been pursuing it for decades. MDE was the great hype around the Object Management Group (OMG) between 2000 and 2010: model the system in UML, let a code generator turn it into C++ or Java, and serve every platform from the same model. Tools like Rational Rose, Rational Rhapsody, Telelogic Tau or MathWorks Simulink/Stateflow implemented it. What did not work: proprietary model formats, unreadable generated code, unreliable round-trip engineering, and licence prices in the five-digit range per seat. And the real problem in practice: at the end you had code in the repository and nobody knew anymore where it had come from. Partly from the generator, partly hand-patched, partly overwritten by the model, partly written in by a developer who could not edit the model. The truth sat somewhere between model, generator and code, and none of the three won. In regulated niches (avionics with SCADE, automotive with Simulink) MDE lives on; in general software engineering it has largely disappeared.
What changed for the new wave is the toolchain: translating a specification into a running system is no longer a specialist’s job, the spec is human-readable (Markdown, YAML, formal languages instead of UML XMI), and the tools are open.
Strengths: the specification survives every refactor, every language migration, every staff turnover. Code is regenerated from it. Reviews focus on what matters: is the specification correct and complete.
Stands and falls with automated tests. Without an end-to-end automated test pyramid, SDD is a blind flight. The AI agent produces code that looks plausible and compiles, but nobody systematically checks whether it actually meets the specification. The spec only becomes the source of truth once every requirement has a test that turns green or red, and that test runs every time the code is regenerated. Adopting SDD without Continuous Integration (CI) with a green test field just gives you a new way to push bugs into production faster.
Weaknesses: writing a bad specification gives you fast and consistent bad code. The old discipline “think before you type” matters more than ever. Or as the saying goes: a fool with a tool is still a fool. Second weakness: the toolchain is in motion. What is standard today may be replaced in a year. Anyone who locks themselves deeply into a single vendor repeats the mistake of the early MDE wave.
In regulated industries spec-driven development is paradoxically not a break, but the natural continuation of the V-model: the same workflow, only in small waterfalls instead of one big one. If you have to document requirements, architecture and tests anyway, you can now use those documents to generate code as well.
What fits when
| Context | Recommendation |
|---|---|
| Pacemaker, brake controller, avionics, nuclear | Waterfall / V-model, complemented by spec-driven parts where the tooling allows it |
| Web app, internal tool, startup Minimum Viable Product (MVP) | Scrum, kept small |
| Product with 50+ developers, multiple sites | SAFe or an adapted variant, with a clear eye on the methodological overhead |
| New development with AI tools on board | Spec-driven development, combined with short iterations |
| Mid-market embedded product, no audit | Hybrid: waterfall for architecture and the critical interfaces, Scrum for the iteration inside, spec-driven parts for whatever can be automated |
The honest answer: none of the four methods is ideal in pure form. What works is a deliberate combination that fits the product, the team and the regulatory context.
Three observations from the field
First, the daily is not the problem. The actual drama in agile projects is not the fifteen-minute stand-up, it is the missing architecture responsibility. With a properly documented architecture you can layer Scrum, SAFe or Kanban on top and the product does not fall apart.
Second, waterfall has not stopped existing. It just has a different name now. Every embedded project with hardware lead time, supplier contracts and a certification path has a waterfall portion. Wishing it away does not change the lead time for the connectors.
Third, spec-driven development is the most interesting movement of recent years. Not because AI coding replaces the engineer, but because it brings the specification out of the shadows where it stood for twenty years. Anyone who drew UML diagrams in the 2000s knows the feeling: finally someone is taking the models seriously.
What stays
Methods are tools, not goals. The question is never “do we do Scrum or SAFe”, but “do we have the right mix of early clarification, fast feedback and end-to-end traceability for this particular product”. Spec-driven development makes end-to-end traceability affordable for the first time without sacrificing fast feedback. That is new and big enough to deliberately try.
Sources
- IEC 62304, Medical device software, software life cycle processes
- DO-178C, Software Considerations in Airborne Systems and Equipment Certification
- ISO 26262, Road vehicles, functional safety
- Scrum Guide
- Scaled Agile Framework (SAFe)
- GitHub Spec Kit
- Anthropic Claude Skills
- Leslie Lamport, Specifying Systems, Addison-Wesley (TLA+)
Keywords: Spec Driven Development, Scrum embedded, SAFe embedded, Waterfall V-model, embedded project methodology, IEC 62304, ISO 26262, DO-178C, Model Driven Engineering, AI coding agents, project method consulting, Embedded Consulting Switzerland
Stuck on the method question in your embedded project? We bring experience from regulated mechanical engineering, classical Scrum teams, SAFe programmes and the current spec-driven wave, and find the mix that fits the product.