From Spec-Driven Development to Compilable Specs

By Louis Choquel, CTO, Pipelex

Agentic Engineering is moving fast. Vercel's Zero launched in preview: a language for AI agents? Well yes: devtools for agents, languages for agents, this is the way. Specifically on languages: I am deeply convinced that the period warrants coming up with new languages, for a few reasons:

1- The old languages were designed for being written by humans, with all the limitations and high costs that come with that, and to be converted into machine-executable code down the line. Now we have very different needs: the ones writing are not always humans, and software is not only machine-executable code but also prompts for AI.

2- Whereas the old languages were for building software, which was an engineer's job, now we have new stakeholders: non-engineers who should be able to directly express their needs. That raises the question of how those needs are recorded, and how they translate to execution, raising new topics such as:

Spec-Driven Development
New takes on "Declarative languages": where one can truly just express what they want and have it executed without bothering with how it's done.

It's a new world of things to do now, because the machine understands intent in a much wider sense than it did when declarative languages like SQL were invented. Actually, while writing this, I discovered that when SQL was initially introduced by IBM in 1974, it was named SEQUEL, as in Structured English Query Language. That says a lot! The dream of expressing intent in English and letting the machine handle the rest is already 50 years old.

I recently stumbled on an article scratching that topic, written by guest writer Unmesh Joshi on Martin Fowler's blog. The article is entitled "What is code?". Unmesh's framing has two sides: Code is a set of instructions to a machine, and code is also a conceptual model of the problem domain. “Coding” is where the two meet. His point is that LLMs are commoditizing the first side, so the second side is the part that matters most: the vocabulary, the language between developers and domain experts. I agree with Unmesh that the vocabulary/domain, the conceptual model, is the part that matters. That framing is what got me and my team to build the MTHDS language for AI methods. A method written in our language sits largely on the conceptual-model side: named concepts, typed inputs and outputs, orchestration logic, all expressed in vocabulary that non-engineers can read and argue about. That's where human thinking should live.

A few weeks ago, Hugo Venturini wrote that we should "Treat Agent Output Like Compiler Output". When I read that I thought “spot on!”, the kind of tooling he's talking about to verify inputs, outputs, typing, and stuff, these are the kinds of things we've been working on. Once we have the proper tooling, we’ll trust the outputs of agents like compiler outputs.

But the agents are not compilers. To my mind, a compiler must be deterministic. So no, I wouldn't use the word compiler to describe what agents do. But it got me thinking, what if we could actually build a compiler that takes a spec and spits out working code, deterministically? There is a lineage of prior art worth pointing to:

OpenAPI made API contracts compilable.
Protobuf made data contracts compilable.

Can the same thing happen for intelligent business-process pipelines?

We built MTHDS to be interpreted, like a script, executed by a runtime software. The point for us was to have deterministic orchestration so that it can be versioned, tested, optimized, and in the end trusted and deployed like software with engineering best practices. That got us the MTHDS language and the Pipelex runtime. The methods are already executable specs: concepts, inputs, outputs, transformations, model calls, orchestration. Today, a runtime interprets them. But could our language be compiled, and not just interpreted?

I can’t see why not. The scripts we define are at a high level of abstraction. They are declarative so I'm thinking we can convert that to Python or TypeScript or Rust or Zero code or whatever language you use that can parse JSON and make API calls, basically. If we did that, what would we have? Well, to put it bluntly, what we would have is a compiler for specs.

Because that's really what our declarative language structures: it’s specs, specs written in a lightly structured syntax based on TOML, that is human readable and of course LLM readable and also software readable. And so these specs can be used to generate code deterministically. Most important of all, they can be used to generate the tests. And in addition to that, they can be used to guide agents in charge of debugging, optimizing or auditing.

And humans don’t have to write using our structured language: SWE agents like Claude Code or Codex are completely capable of writing it for humans, from natural language. And what would make this all work is that the structured specs are reviewable by non-tech humans: the specs use the domain language, the specs present the humans’ own ideas and needs back to them, in a clean structured form.

Before, we had to do this:

human → programming code → [compiler] → machine code

Now we could also do this:

human → specs → [SWE agent] → structured specs → programming code

Compilable specs could be an engineering layer for Spec-Driven Development.

Related reading: Why Multi-Step AI Workflows Need a New Language for the MTHDS language design rationale, and The Know-How Graph for why agents need the open standard.