SDD: la trampa que te quieren vender los gurús
Spec-Driven Development. Escribe una especificación exhaustiva, dásela al agente, recibe el sistema. Lo venden como el método que profesionaliza el trabajo con IA. Lo que profesionaliza, en varios casos que he visto, es la producción de documentos que nadie lee.
Aclaro antes de que me citen fuera de contexto: especificar es parte del trabajo y siempre lo fue. Mi problema no es la especificación. Es el “driven”.
Ya vimos esta película
Cascada, 1970. Escribe todo primero, construye después. Fracasó por una razón que no ha cambiado: la especificación completa de un sistema no existe antes de construirlo, porque construirlo es precisamente lo que revela los requisitos que nadie sabía que tenía.
SDD es cascada con markdown y un LLM al final. El mismo supuesto —que puedes saberlo todo por adelantado— con mejor tipografía.
Los tres síntomas
La spec de 40 páginas. Escrita para el agente, ilegible para el equipo. Nadie la actualiza después del tercer cambio de requisito, así que a la semana el código y la spec discrepan, y como la spec no compila, el que miente es el documento.
La ceremonia sin verificación. Se aprueba la spec en una reunión, se genera, y nadie definió cómo se comprueba que lo generado cumple lo especificado. Si tu criterio de aceptación no es ejecutable, escribiste un deseo con viñetas.
El vendedor de plantillas. Cinco carpetas, doce archivos y una convención de nombres, todo antes de escribir una línea. El proceso se vende solo porque produce artefactos visibles rápido, y los artefactos visibles se confunden con progreso desde que existe el PowerPoint.
Lo que sí funciona, sin nombre pegajoso
Especificación mínima y ejecutable. Los criterios de aceptación como tests, no como prosa. “Devuelve 429 después de 100 requests por minuto” es un test; “el sistema debe ser resiliente” es un horóscopo.
Contratos donde hay costo de coordinación. El esquema de la API, el formato del evento, el contrato de la migración. Ahí especificar por adelantado se paga solo, porque el error se detecta entre equipos y no dentro de uno.
Escribir la spec del pedazo que viene, no del sistema entero. Un ciclo corto: especifico esto, lo construyo, aprendo algo, ajusto lo siguiente. Sí, es iterativo. Sí, es lo que llevamos veinte años diciendo. No, no necesita nombre nuevo.
Documentar decisiones, no intenciones. Un ADR de tres párrafos explicando por qué se eligió una cosa vale más que cuarenta páginas describiendo lo que se va a hacer. El código muestra el qué; solo el documento puede guardar el porqué.
Cómo detectar al gurú
Preguntas rápidas: ¿cómo se verifica automáticamente que la implementación cumple la spec? ¿Qué pasa cuando el requisito cambia en la mitad? ¿Puedo ver esto funcionando en un repo con cinco años de historia y deuda real, no en un proyecto nuevo?
Si las tres respuestas incluyen la palabra “disciplina”, te están vendiendo un problema de proceso disfrazado de metodología. La disciplina es lo que se invoca cuando el método no soporta la realidad.
El resumen
Especifica lo justo, hazlo verificable, itera. Eso no es una metodología: es el trabajo.
Y si alguien te vende un framework de cinco letras que promete convertir requisitos en software sin la parte incómoda de pensar en el medio, ya sabes en qué categoría de producto está. Los frascos de la foto los vendían igual de bien.