«El waterfall contraataca»: nuestra respuesta, punto por punto

225 puntos y 191 comentarios: el hilo de Hacker News que acusa al desarrollo guiado por especificaciones de resucitar el waterfall dejó huella. Tres críticas concretas y una respuesta con cifras, sin evasivas.

Un hilo de Hacker News titulado «Spec-Driven Development: The Waterfall Strikes Back» reunió 225 puntos y 191 comentarios (news.ycombinator.com/item?id=45935763). La acusación: escribir una especificación antes del código recupera el mal que el desarrollo ágil había desterrado. De él se desprenden tres críticas concretas. Aquí está nuestra respuesta, sin descartar ninguna.

Crítica 1: «la especificación se vuelve un caos cuando avanza el proyecto»

Es cierto para una especificación única que crece indefinidamente. En Maestro, nada se escribe de una sola vez: el brief, la especificación, la arquitectura y el desglose en tareas son documentos breves y separados, cada uno validado antes del siguiente mediante un punto de aprobación humana, el «Me parece bien». Un documento que crece demasiado se revisa antes de continuar; nunca se apila sobre los anteriores. Ese principio produjo una proporción aproximada de diez entre nuestra metodología y BMAD-METHOD en volumen de contexto metodológico enviado: la concisión no es un extra, es la restricción de partida.

Crítica 2: «horas sin ver código, sin feedback iterativo»

Es la crítica más acertada contra un diseño completo anticipado clásico. Nuestra respuesta es estructural: después del desglose, el desarrollo y la verificación se realizan historia por historia, nunca sobre todo el producto de una vez. El feedback llega a escala de una historia, en minutos u horas, no al final de varias semanas de trabajo. En nuestras campañas de medición, un producto completo llega a la meta por unas decenas de dólares en unas pocas horas, no tras días sin noticias.

Crítica 3: «el LLM es un compilador no determinista»

Esta da en el blanco y no se resuelve con retórica. Nuestra respuesta: acotar el no determinismo con pruebas escritas ANTES del código (el contrato de verificación queda fijado desde el desglose) y señalar cualquier prueba que el agente modifique durante una reparación, aunque ya existiera. El modelo sigue siendo probabilístico; lo que debe cumplir deja de serlo. Es el mismo principio de medición que nos llevó a derivar cada versión de nuestra metodología de un defecto encontrado por un jurado, nunca de una intuición.

Lo que no dice la defensa genérica

Martin Fowler comparó Kiro, Spec-Kit y Tessl sin elegir entre ellos (martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html), y el repositorio github/spec-kit muestra 130 054 estrellas (api.github.com/repos/github/spec-kit, verificado el 18 de agosto de 2026): el desarrollo guiado por especificaciones es un movimiento, todavía no una arquitectura probada frente a sus propias críticas. Defender la tesis sin medir qué cambia en la práctica deja la contraofensiva del hilo de HN sin una respuesta concreta.

Lo que dicen nuestras cifras

En las campañas entre nuestra metodología y BMAD-METHOD, la referencia abierta más próxima a un waterfall documental clásico (PRD voluminoso, muchas historias, poco código entregado), la diferencia crece precisamente donde apuntan las tres críticas del hilo: menos contexto muerto, feedback historia por historia y código que supera sus propias pruebas en lugar de documentos que describen una intención.

Lo que concedemos

Una spec-as-source que nunca se dividiera ni se validara en pequeñas partes merece, en efecto, la acusación de waterfall. La nuestra solo la evita porque cada etapa es pequeña, prescindible y juzgada por lo que produce, no por lo que promete. El hilo de HN tenía razón al desconfiar de una especificación que se convierte en un proyecto en sí misma; no había previsto que la dividiríamos en porciones lo bastante finas como para que ninguna llegara a convertirse en un proyecto.