A sufficiently comprehensive spec is not (necessarily) code

The argument

It has been reported that Hillel Wayne argued in a recent newsletter that a "comprehensive and precise spec" does not automatically equal code. The claim in a comic — that a spec detailed enough to generate a program is itself code — is, allegedly, a misunderstanding. Specs describe a set of possible implementations; code is one concrete choice from that set. Simple as that. Or is it?

A practical sketch

Wayne walks through the classic example: "I want a tool to convert miles to kilometers." Vague. Hand it to an LLM and you get a program — maybe. But which language? Web app or command-line? 1.6, 1.61, or 1.609? Context matters. The spec narrows possibilities; it doesn't pin every single decision down unless you mean it to. So a spec can be "sufficient" for its author without being indistinguishable from code.

Tests, formalisms, and the human factor

Formal methods and program synthesis are real and advancing. It has been reported that tests, TLA+, UML and the like are all ways to encode specs, and test suites are specs in code form. But encoding a spec inside code is still an encoding — not a metaphysical identity. Wayne points out that attempts to make nonprogrammers write formal specs (Cucumber, anyone?) have largely failed, allegedly, because the craft of encoding requirements remains technical. Programmers aren’t just writing code; they’re translating fuzzy human needs into precise, implementable constraints.

Bottom line

Even in an era of impressive LLMs and growing synthesis tools, the separation between spec and implementation is useful and real. Specs reduce the design space; code picks a single point in it. Keep them distinct, and you keep flexibility — and jobs. Who knew requirements could be the quiet middle managers of software development?

Sources: buttondown.com/hillelwayne, Lobsters