El desarrollador Renan Botasse propone en HackerNoon invertir el orden habitual de trabajo con asistentes de inteligencia artificial: primero la intención, después una especificación verificable y, solo al final, el código. Lo llama desarrollo guiado por especificaciones, o SDD (Spec-Driven Development), y lo presenta en un artículo de octubre de 2026 como respuesta a un cambio de fondo: si generar código ya es barato, lo caro pasa a ser saber qué construir y revisar lo que la máquina ha escrito.
Las claves del desarrollo guiado por especificaciones en 20 segundos
- Renan Botasse defiende en HackerNoon el desarrollo guiado por especificaciones: la spec manda y el código se deriva de ella.
- Propone seis fases con dos revisiones humanas obligatorias antes de generar código.
- GitHub Spec Kit y Kiro, de AWS, aplican flujos parecidos, aunque el autor no los cita.
- El método cambia el cuello de botella: de escribir código a revisarlo.
El punto de partida es una crítica al vibe coding, la práctica de pedir algo a la IA, probar el resultado y repetir. Botasse reconoce que funciona para prototipos y scripts de un solo uso, pero enumera sus límites: el contexto se queda en el chat y se pierde, la revisión se hace comprobando si el programa se comporta como se espera en vez de leer el código, el mismo prompt puede dar resultados distintos y no queda rastro de por qué se tomó cada decisión, algo que pesa cuando hay reglas de negocio, auditorías o cumplimiento normativo. Los riesgos de llevar ese código a producción sin más ya se trataron en la guía de seguridad para vibe coders publicada en noticias.ai.
Su alternativa convierte la especificación en la fuente de verdad. El documento se versiona junto al código, y si ambos dejan de coincidir, gana la especificación. De ahí sale la idea más llamativa del texto: el código pasa a ser regenerable y lo que conserva valor a largo plazo es la intención registrada. Refactorizar, en ese esquema, significa volver a generar a partir de la misma especificación.
Seis fases, cuatro principios y dos puertas de control humanas
El método descansa en cuatro principios. La intención va antes que la implementación, sin hablar todavía de tecnologías. Cada requisito debe tener criterios de aceptación verificables: el autor contrapone un deseo genérico, que el sistema sea rápido, con un requisito medible, como que un listado responda en menos de 300 ms con 10.000 registros. Lo que no está escrito en un fichero no existe. Y una persona valida cada fase antes de pasar a la siguiente, porque aprobar sin leer anula el método.
Sobre esa base, Botasse ordena el trabajo en fases que producen un fichero cada una. La fase 0 es una constitución del proyecto (constitution.md) con las reglas comunes de stack, arquitectura y calidad. La 1 es la especificación (spec.md), con el objetivo de negocio, los requisitos, los usuarios, los casos límite y lo que queda fuera, sin términos técnicos. En la 2, la IA señala ambigüedades y el humano las cierra; es la primera puerta de control, la que según el autor casi todo el mundo se salta y la que más ahorra después. La 3 es el plan técnico (plan.md), el único lugar donde aparecen tecnologías, contratos HTTP y modelo de datos. La 4 divide el trabajo en tareas atómicas (tasks.md) con identificador, origen, dependencias y criterio de finalización. La 5 es un análisis cruzado que busca requisitos sin cubrir y tareas huérfanas, segunda puerta humana. La 6 es la implementación, una tarea por prompt.
El ejemplo que acompaña el texto es un pequeño servicio que genera contraseñas de 16 caracteres y devuelve un GUID para recuperarlas. Tras la fase de aclaración aparecen reglas que la primera versión no recogía: nada de espacios en blanco, un GUID único por contraseña y ningún guardado parcial si la generación falla. El plan concreta un endpoint POST /api/passwords/generate y la clase RandomNumberGenerator de .NET, y las tareas siguen el ciclo de escribir primero tests que fallan y luego el código que los hace pasar. La regla de oro del autor es clara: si el resultado sale mal, no se parchea el código con la IA, se corrige la especificación y se repite el flujo desde la fase afectada.
Spec Kit y Kiro ya llevan la idea a herramientas
El artículo no menciona ninguna herramienta concreta, pero su esquema se parece mucho a lo que ya ofrecen dos proyectos. GitHub Spec Kit es un kit de código abierto con licencia MIT que necesita Python 3.11 o superior, el gestor uv y un agente de programación compatible. Su flujo básico usa comandos que coinciden casi palabra por palabra con las fases de Botasse: /speckit-constitution, /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement y /speckit-converge, que se repiten hasta que el informe de convergencia da el trabajo por cerrado. La documentación pide ejecutarlos uno a uno y revisar cada resultado, y remite a su guía para la aclaración y el análisis de consistencia. Spec Kit ha añadido además extensiones para corregir errores y para evaluar si una idea merece desarrollarse, y en octubre de 2026 sus responsables presentaron la versión 1.0.
Kiro, el entorno de desarrollo con agentes que lanzó Amazon, organiza sus specs en tres ficheros: requirements.md (o bugfix.md para errores), design.md y tasks.md. Su documentación describe tres fases (requisitos, diseño y tareas), permite empezar por los requisitos o por el diseño y ofrece una función para detectar inconsistencias, ambigüedades y huecos en los requisitos antes de diseñar, muy similar al análisis que propone Botasse. También ejecuta en paralelo las tareas que no dependen unas de otras, agrupadas en oleadas. Hay una diferencia relevante: Kiro incluye un modo Quick Spec que genera los tres documentos de una vez y sin puertas de aprobación, pensado para funciones bien conocidas. Es justo el atajo que el autor desaconseja.
Lo que el artículo no demuestra
La propuesta es un texto de opinión y divulgación, no un estudio. Botasse no aporta mediciones de tiempo, errores o coste que comparen su flujo con el vibe coding, y la afirmación de que la fase de aclaración concentra el mayor ahorro no viene acompañada de cifras. La premisa del código regenerable choca además con un problema que el propio autor atribuye al vibe coding: los modelos pueden producir resultados distintos ante la misma entrada. En su esquema, lo que fija el comportamiento no es el código generado sino los criterios de aceptación y los tests, por eso insiste en que cada requisito sea verificable. Su cierre es prudente: invita a pasar una función real por las seis fases y juzgar el resultado.
Preguntas frecuentes
¿Qué es el desarrollo guiado por especificaciones?
Es una forma de trabajar con asistentes de IA en la que primero se redacta una especificación con requisitos verificables y después se genera el código a partir de ella. La especificación se versiona junto al código y prevalece si ambos no coinciden.
¿En qué se diferencia del vibe coding?
El vibe coding itera con prompts y pruebas sobre la marcha, y el contexto se queda en el chat. El SDD deja por escrito la intención, el plan y las tareas, e incluye revisiones humanas antes de escribir código.
¿Qué herramientas aplican este método?
GitHub Spec Kit, de código abierto, ofrece comandos para constitución, especificación, plan, tareas e implementación. Kiro organiza cada spec en ficheros de requisitos, diseño y tareas.
¿Qué hago si el código generado está mal?
Según el autor, no conviene parchearlo con la IA. Hay que corregir la especificación y repetir el flujo desde la fase afectada.
Fuentes:
