
Spec-Driven Development is having a moment. GitHub shipped spec-kit. OpenAI is pushing "natural language as the new programming language." Every AI tooling pitch is a variation of: write the spec… | Dmitry Demidenko | 25 comments
Spec-Driven Development is having a moment. GitHub shipped spec-kit. OpenAI is pushing "natural language as the new programming language." Every AI tooling pitch is a variation of: write the spec, hand it to the model, get the code. The framing is misleading. Dave Farley has been telling you to do this for fifteen years. Dan North coined BDD in 2006. The point was always the same: write requirements in a form that is unambiguous and executable. Code is a byproduct of clearly stating what you want. Most teams ignored it. Gherkin became ceremony. Cucumber became a graveyard. The discipline was right; the payoff was diffuse. What changed isn't the philosophy. It's the economics. BDD asked engineers to do extra work for a payoff they couldn't feel. LLMs punish vague specs in real time — hand a model an ambiguous spec, it confidently ships the wrong thing in twenty seconds. The feedback loop BDD always wanted finally exists, because imprecision now costs you visibly and immediately. The rigor was always the point. AI just made the rigor pay. Practical implication for founders hiring engineers: the people who can actually do SDD well are the people who could have done BDD well. They think in invariants. They write specs that exclude ambiguity. Give them Claude or 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. Skip "have you used Cursor" in your next interview. Ask them to walk through how they would specify a non-trivial feature before writing any code. The answer tells you everything. | 25 comments on LinkedIn





