Spec-Driven Development: Everything Old Is New Again | superluminar GmbH<br>Software engineering as we know it is being replaced. Not by AI. By specs.<br>“Given… When… Then… | claude” is a workflow, but it’s also a forcing function: you have to actually mean what you write.<br>The thing nobody talks about<br>Getting specs right is hard. Harder than code.<br>Code is honest - it runs or it doesn’t. A vague spec just produces confident-sounding garbage, and now the garbage compiles.<br>What’s actually hard about it:<br>knowing the why before the how<br>writing down the failure cases, not just the happy path<br>treating it as a live document, not a kickoff artifact you forget about a week later<br>And the thing people keep confusing: a spec is not documentation. Documentation describes what already exists. A spec describes what must be true. Everything else - docs, tests, the code itself - can be regenerated from it. If it can be regenerated, it’s not the asset. The spec is.<br>Codegen has been spec-driven for decades<br>Before we even get to TDD, there’s a whole lineage of tools that did exactly this: you write a spec, the code is generated from it, and you never touch the output.<br>It started with IDLs - interface definition languages. CORBA in the early 90s. You wrote a .idl file describing your interfaces, data types, and operations in a language-neutral format. Then you ran a compiler and got Java, C++, or whatever you needed on the other end. The IDL was the truth. The generated code was an artifact you threw away and regenerated whenever the spec changed.<br>WSDL did the same thing for the SOAP era. Painful to write by hand, but the idea was sound: describe your web service in XML, generate the client and server stubs, ship it. The spec lived in the .wsdl file. The code was output.<br>Google built Protocol Buffers internally around 2001 and open-sourced it in 2008. Define your messages and services in .proto files, run protoc, get code in whatever language you need. gRPC sits on top of that today and the model hasn’t changed. Facebook had the same problem and built Thrift around 2007 - same pattern, write a .thrift schema, generate code in a dozen languages, never edit the generated files.<br>OpenAPI brought it to HTTP APIs. Swagger/OpenAPI specs let you describe an entire REST API in YAML, generate server stubs, generate clients, generate documentation. Tools like openapi-generator spit out thousands of lines you’d never write by hand.<br>GraphQL took a different angle but same principle: the schema is the contract. You define types and resolvers in the schema language, and a whole ecosystem of tools generates typed clients, mocks, validators from it.<br>The pattern is identical every time. Define the contract in a language designed for specification, not implementation. Generate everything else. Treat the generated code as read-only.<br>There’s a warning buried in this history though. Autoconf and automake - the GNU build tools from the early 90s - were supposed to solve portability through specification. You wrote a configure.ac describing what your build needed, and it generated Makefiles for whatever platform you were on. In theory: spec-driven, clean. In practice: people started generating the configure.ac too. Then scripts to generate the scripts. The abstraction became so leaky and the mental model so lost that most projects treated the whole thing as a black box nobody touched. It worked, in context, but the understanding had long since left the building.<br>The same thing is starting to happen with AI specs. “The spec is wrong” becomes “let’s generate the spec from the existing code” becomes “let’s have the AI maintain the spec” becomes nobody actually knows what the system is supposed to do anymore. The spec is downstream of the implementation again, just with more steps in between. All that meta-activity is a tell that the hard part - actually thinking it through - got skipped.<br>It worked because the scope was contained. IDLs describe interfaces. Proto files describe messages. OpenAPI specs describe HTTP endpoints. The spec had a clear boundary and the codegen had a clear job.<br>What’s different now is that the scope is everything. Not just the interface layer - the whole system. That’s what makes it hard, and that’s what makes the discipline of writing good specs matter so much more.<br>We’ve been here before<br>None of this is new. That’s the point.<br>In the early 2000s, Kent Beck pushed test-driven development as a design discipline. Write the test first. Let the failing test tell you what to build. The test is a spec. The code is the answer to the spec. Simple.<br>Then Dan North took it further. Around 2003 he noticed that teams struggled with TDD not because writing tests was hard, but because they didn’t know what to test. The framing was wrong. “Test” implied verification after the fact....