AI didn't invent specs-as-code. It just made them economically viable.

Spec-Driven Development is having a moment. GitHub shipped spec-kit. OpenAI is pushing "natural language as the new programming language." Every AI tooling startup is pitching some variation of: write the spec, hand it to the model, get the code.

The pitch is sound. The framing is misleading.

Dave Farley has been telling you to do this for fifteen years. So has Dan North. So has Liz Keogh. We called it Behavior-Driven Development, and most teams didn't bother. Now there is a generative model in the loop, the same idea has a new name, and the discipline is suddenly interesting.

If you are hiring engineers right now, the difference between what is actually new and what isn't tells you who to bet on.

What SDD claims

Write the spec first. Make it precise, structured, machine-readable. Hand it to an LLM. The model generates the implementation, the tests, the plan. The spec is the source of truth; the code is downstream.

The promise is real. When specs are tight, AI-assisted output is dramatically better. When specs are vague, the output is dangerous.

What BDD already did

In 2006 Dan North coined BDD. The point was simple: write requirements in a form that is unambiguous, business-readable, and executable. Given the cart has two items, when the user applies coupon SAVE10, then the total decreases by 10%. Gherkin syntax. Cucumber. Living documentation. Specs that did not rot because they ran in CI every commit.

Dave Farley — who wrote Continuous Delivery with Jez Humble and runs the Modern Software Engineering channel — has spent his career arguing that this kind of executable specification is the engineering work. Code is a byproduct of clearly stating what you want. He has been saying this since well before "AI-native" was a phrase anyone used.

The uncomfortable truth

Mechanically, SDD and BDD differ. BDD turns specs into executable tests. SDD turns specs into prompts that generate code. Different artifacts.

Philosophically, they are the same thing: the precision of your intent is the work. Both insist that the bottleneck in software is not typing — it is the gap between what you mean and what the system does. Both close that gap with rigor.

If you are excited about SDD and you have never read Farley, you are excited about a derivative without knowing the original.

So why is it suddenly working?

Because AI changed the economics.

BDD asked engineers to do extra work — write specs and maintain code. Most teams treated Gherkin as ceremony. The specs rotted. Cucumber became a graveyard. The discipline was right; the payoff was diffuse.

LLMs punish vague specs in real time. Hand a model an ambiguous spec, it confidently produces the wrong thing in twenty seconds. You feel the pain immediately. The feedback loop that BDD always wanted finally exists, because the cost of being imprecise is now visible, fast, and personal.

That is the only thing that changed. The rigor was always the point. AI just made the rigor pay.

What this means if you are hiring engineers

This is where it gets practical for founders.

The market is currently flooded with "AI engineers" whose actual skill is prompting Cursor until something runs. They will ship something fast. It will be brittle. It will not survive your second feature.

The engineers who can actually do SDD well are the same engineers who could have done BDD well. They think in invariants. They write specs that exclude ambiguity. They can describe behavior crisply because they have always had to. Give them a Claude or a Codex and they ship like a team of four. Give the prompt-and-pray crowd the same tools and they ship technical debt at four times the rate.

The discipline is not new. The leverage on the discipline is.

What to ask in your next engineering interview

Skip "have you used Cursor."

Ask: "Walk me through how you would specify a non-trivial feature before you write any code."

The engineer who reaches for executable acceptance criteria, who names invariants, who talks about edge cases as part of the spec rather than as bugs to be found later — that engineer was going to be valuable in 2015. In 2026 they are a force multiplier.

That is who we place. Not because we figured out a new methodology. Because the methodology was already there, and we hire the people who internalized it before it was fashionable.

---

If you are an early-stage founder trying to ship fast without a full engineering org, talk to us at exit-code.com. We will not sell you SDD. We will send you an engineer who already thinks that way.