The Newest Idea in AI Coding Is Forty Years Old

The views expressed here are my own and do not represent those of any current or former employer.

There is a particular feeling you get when the industry discovers something you’ve been doing for years and announces it as new. It’s not smugness, exactly. It’s more like watching someone present your commute to work as an expedition.

That’s how 2025’s “spec-driven development” landed for me.

The pitch goes like this: stop vibe-coding. Write a specification first. Make the specification the source of truth. Let the code be a derived artifact, something you regenerate from intent rather than hand-carve and then guard. GitHub shipped Spec Kit on this premise and it collected a hundred thousand stars in a few months. AWS shipped Kiro. A startup called Tessl raised money on it. The framing everywhere was: this is the new way to build software with AI.

Here’s the thing. Every load-bearing idea in that pitch is older than most of the people pitching it. And if you came up through infrastructure, like I did, you’ve been living inside the most battle-tested version of it the entire time.

This is the first post in a short series. Before I get to where the current wave stops (the layer almost nobody is building, which is the part I actually care about), I want to do something less common in this discourse: give the idea its ancestors. Because you can’t see what’s missing from a paradigm until you understand what it’s made of.

The through-line

Strip every spec-driven tool down to its load-bearing claim and you get one sentence:

A human-authored description of intent is the primary artifact, and the executable is generated from it.

That sentence has a long family tree. Let me walk it, because each ancestor donated a specific organ to the thing we’re calling new.

Literate programming (Knuth, 1984). Donald Knuth’s idea was that you write a program as prose explaining your intent, with the code woven into the explanation, and the explanation outranks the code. The program is a document a human reads, and the compiler extracts the machine’s version from it. Intent-first authoring, four decades ago.

Model-Driven Architecture (OMG, 2001). This one is almost on the nose. The Object Management Group launched MDA in 2001 with a thesis I could paste directly into a 2026 launch tweet: models are the primary development artifact, and implementation code is derived through automated transformation. They even had a word for it: forward engineering, producing code from abstract, human-authored models. Swap “UML class diagram” for “markdown spec” and “code generator” for “LLM” and you have spec-kit’s architecture diagram. The dream of code-as-derived-artifact is twenty-five years old and it had enterprise tooling.

TLA+ (Lamport, 1999). Leslie Lamport built a formal specification language for designing and verifying systems (especially concurrent and distributed ones) before you implement them. The whole point, in his words, is that the precision of the spec is “intended to uncover design flaws before system implementation is underway.” Spec before code, to catch the expensive mistakes while they’re still cheap. That’s not a 2025 insight. That’s how you design a distributed system that can’t afford to be wrong.

Behavior-Driven Development (Dan North, 2006). BDD took the spec and made it executable. The Given/When/Then template (built on Eric Evans’ Domain-Driven Design and Rachel Davies’ user-story format) captured acceptance criteria in a form a machine could run. The modern wave’s “the spec is executable” is BDD’s entire thesis, generalized from a test runner to a language model.

Readme-Driven Development (Tom Preston-Werner, 2010). The GitHub co-founder wrote it plainly: “Write your Readme first. First. As in, before you write any code or tests or behaviors or stories or ANYTHING.” And the line that should be carved over the door of every spec-driven startup: “A perfect implementation of the wrong specification is worthless.” RDD took MDA’s formality and made it human: the spec is just English, but it’s still the authority.

Software 2.0 (Karpathy, 2017). Andrej Karpathy gave the idea its most radical form. In Software 2.0, you don’t write the program: you specify a goal on the behavior of a desirable program and “use the computational resources at our disposal to search this space for a program that works.” The dataset is the real source code; the trained network is the compiled, derived binary. Intent as source of truth, the artifact as something compiled. That’s the philosophical root system of every “regenerate the code from the spec” pitch on the market.

The pattern across all of these: raise the abstraction from how to what, treat the what as authoritative, and generate the how. The 2025 wave’s only genuinely new move is the generator: an LLM that reads English instead of a transformer that reads UML.

The ancestor that mattered to me

I listed those because they’re the lineage everyone in the spec-driven conversation half-remembers. But there’s one more, and it’s the one that actually shaped how I think, because I didn’t read it in a paper. I ran it in production for years.

Declarative infrastructure-as-code. Terraform’s “desired state.”

If you’ve never lived in it, here’s the model. You don’t write a script that says “create this server, then attach this disk, then open this port.” You write a declaration of the desired end state (“I want three servers, this network, these rules”) and the engine figures out the diff between what exists and what you declared, and converges reality toward your declaration. There’s a canonical state file that records what’s actually true. You run plan to see what would change. You run apply to make it so. And when reality drifts from the declaration, the tool detects the drift and tells you, instead of silently pretending.

Read that paragraph again with agents in mind.

A PRD is the desired-state declaration. The tasks are the resources. There’s a state store that records what’s actually true. You plan before you apply. Drift gets detected, not papered over.

When I sat down to design fakoli-state, I kept reaching for the Terraform analogy and it kept fitting, joint for joint. I wrote about that at the time: once I let the analogy do the work, the design wrote itself. That wasn’t me being clever. That was me arriving at the spec-driven destination from a different road than everyone else. They came from “how do we make LLMs more deterministic.” I came from “this is just desired-state reconciliation with a language model in the loop, and I already know how desired-state reconciliation is supposed to work, because I’ve been on call for it.”

This is the quiet reason the infrastructure-to-AI transition is so natural, and I’ve written about which parts transfer and which don’t. The whole discipline of declarative, drift-aware, plan-before-apply state management is exactly what the agentic world is groping toward. Most of the groping is happening from first principles by people who never had to reconcile a Terraform state file at 3am. I had. It leaves a mark, and the mark turned out to be useful.

Why the ancestry matters

This isn’t a “nothing is new under the sun” post. Plenty is new. The capability jump in the models is real, and the fact that you can now write the spec in plain English and have a competent generator act on it is a genuine phase change.

The ancestry matters because a paradigm inherits its ancestors’ unsolved problems.

MDA had a famous one: the round-trip problem. You generate code from the model, then someone edits the code, and now the model and the code disagree and nobody knows which is true. Sound familiar? It should: it’s the exact problem every spec-driven tool faces the moment the spec and the implementation drift apart, which is to say, immediately.

TLA+ had one too: a spec is only as good as your discipline in keeping it true, and most teams don’t have it.

Terraform solved its version of these problems with a specific piece of machinery: a durable, canonical state file that is the single source of truth, plus drift detection that refuses to let reality and intent silently diverge. That machinery is not optional. It’s the thing that makes desired-state management work instead of being a nice idea you abandon after the second outage.

So here’s the question I’ll spend the rest of this series on. The 2025 spec-driven wave inherited the dream: intent as source of truth, code as derived artifact. Did it inherit the machinery that makes the dream survive contact with reality?

In the next post I’ll lay out the field (Spec Kit, Kiro, Tessl, task-master, BMAD, Agent OS, OpenSpec) and where each of them sits. Then, in the third, I’ll show you the specific organ almost all of them are missing, the one Terraform figured out twenty years ago, and why I think it’s the only part of this whole space that’s actually hard to build.

It’s the anvil. But I’m getting ahead of myself.

This is Part 1 of a series on the spec-driven development wave. Part 2: a field guide to who’s building what. Part 3: the layer nobody wants to build.