Los antecedentes más tempranos del SDD no vienen de la academia — vienen de la ingeniería militar. En 1956, Herbert D. Benington documentó el proceso usado para desarrollar el sistema SAGE en el MIT Lincoln Laboratory, presentando un flujo de nueve fases secuenciales: Operational Plan, Operational Specs, Program Specs, Coding Specs, Coding, Parameter Testing, Assembly Testing, Shakedown y Evaluation. Múltiples capas de especificación antes de una sola línea de código. La lógica era simple: el costo de un error en producción era literalmente irreversible.
En 1970, Winston Royce formalizó esa secuencia como modelo en su paper "Managing the Development of Large Software Systems" — lo que la industria terminaría llamando waterfall. Paradójicamente, lo que adoptó la industria no fue lo que Royce recomendaba: ignoró sus advertencias sobre prototipos e incrementos, y quedó solo con la estructura documental. En 1985, el Departamento de Defensa de los Estados Unidos institucionalizó ese principio con el DOD-STD-2167, exigiendo especificación formal antes de implementación como estándar obligatorio para sistemas de misión crítica.
Paralelamente, durante los años 70 y 80, emergió la corriente de Formal Methods con figuras como Tony Hoare, Edsger Dijkstra y Leslie Lamport. Su propuesta: usar notación matemática para describir el comportamiento esperado de un sistema antes de implementarlo, de modo que la corrección pudiera verificarse formalmente. Herramientas como TLA+, Z notation y Alloy son los descendientes directos de esa tradición. Su dominio natural sigue siendo sistemas donde el fallo no es aceptable — aviación, medicina, criptografía, infraestructura nuclear.
En 1988, Bertrand Meyer formalizó Design by Contract en su libro Object-Oriented Software Construction, introduciendo el lenguaje Eiffel. La idea central: cada componente de software tiene un contrato explícito — precondiciones que el llamador debe cumplir, postcondiciones que el componente garantiza, e invariantes que siempre se mantienen. No es documentación externa al código — es parte del código mismo. Esta idea influenció directamente Clojure.spec, los tipos avanzados de Rust y TypeScript, y el pensamiento detrás del TDD moderno.
En 2004, el SDD fue formalizado académicamente como síntesis entre TDD y Design by Contract, articulando por primera vez la práctica bajo ese nombre explícito.
En 2003, Dan North formalizó Behavior-Driven Development — que puede leerse como la democratización del SDD. Las especificaciones en lenguaje natural estructurado (Given/When/Then) hicieron accesible el principio de especificar primero a negocio, desarrollo y QA simultáneamente.
Aslak Hellesøy creó Cucumber como su herramienta de referencia. BDD trasladó el centro de gravedad desde la verificación matemática hacia la conversación colaborativa como mecanismo de especificación.
Paralelamente, en el mundo de las APIs y sistemas distribuidos, OpenAPI/Swagger estableció la spec como contrato de interfaz entre sistemas — un uso más pragmático y acotado, pero de enorme adopción real en la industria.
Durante los años 2010 el SDD vivió en un segundo plano relativo. El agilismo dominante, en su reacción al waterfall, tendió a ver cualquier especificación previa con sospecha. El resultado fue el péndulo conocido: del análisis parálisis al cowboy coding institucionalizado.
El quiebre ocurre entre 2023 y 2025 con la irrupción del AI coding. El problema central cambió: ya no era costoso escribir código — era costoso especificar bien. Los agentes generan código decente dado un contexto claro, y basura dado un contexto vago. De golpe, especificar antes de construir dejó de ser una virtud opcional para convertirse en la condición de posibilidad del AI coding efectivo.
En 2025, GitHub lanzó Spec Kit — un toolkit open source para SDD con agentes de AI — articulando el flujo en cuatro fases: spec, plan, tareas, implementación. Amazon desarrolló Kiro como IDE agéntico centrado en specs. Apareció Tessl, que va más lejos: propone que la spec es el artefacto primario y el código un byproduct regenerable.
Thoughtworks, en diciembre de 2025, lo sintetizó así: el SDD no es un retorno al waterfall. Las specs pueden ser pequeñas e iterativas. La diferencia estructural con el UML de los 90s es que estas specs no son documentación transversal — son artefactos focalizados, vivos, orientados a tareas concretas.
Hoy el campo está dividido en dos posiciones que todavía no se han resuelto.