Spec-Driven Development en 2026: qué es y cómo elegir entre OpenSpec, Spec Kit y BMAD

Programar con agentes de IA dejó de ser una curiosidad. Hoy un agente lee el repositorio, propone un plan, escribe el código, corre las pruebas y abre el pull request. El problema es que hace exactamente lo que entendió, y si lo que le pediste cabía en una frase de chat, lo que entendió puede estar muy lejos de lo que necesitabas. Spec-Driven Development (SDD, desarrollo guiado por especificaciones) es la respuesta que la industria fue armando durante 2025 y que en 2026 ya tiene herramientas maduras. Este artículo explica qué es, cómo se usa hoy y cómo se comparan sus tres frameworks más usados: OpenSpec, Spec Kit y BMAD Method.

Cómo llegamos aquí

En pocos años, la forma de programar con IA pasó por cuatro etapas:

Con los agentes apareció el vibe coding: describir lo que uno quiere en lenguaje natural, aceptar lo que salga y seguir pidiendo cambios hasta que "se vea bien". Sirve para un prototipo de fin de semana. En un sistema real trae problemas conocidos: el agente pierde el contexto a mitad de camino, toca archivos que no debía, rompe lo que ya funcionaba y las decisiones técnicas quedan enterradas en un historial de chat que nadie vuelve a leer.

SDD toma otro camino: acordar antes de construir. Si el agente va a escribir el código, lo más valioso que hace el programador es decir con precisión qué hay que construir, revisar el plan y verificar el resultado.

Qué es Spec-Driven Development

Es una forma de trabajar en la que cada cambio parte de una especificación escrita: un documento en Markdown que dice qué debe hacer el sistema y por qué, antes de decidir cómo. El agente la usa como contrato para planificar e implementar, y el programador la revisa en el punto donde corregir es barato: corregir un párrafo toma minutos; reescribir código mal encaminado toma horas.

Uno de los mejores puntos de partida en español es el curso gratuito Hello SDD de Brais Moure (MoureDev), ingeniero de software desde 2010 y uno de los divulgadores de programación más seguidos en nuestro idioma, con cerca de un millón de suscriptores en YouTube. En su curso, el flujo completo tiene ocho pasos:

Para que los requisitos no se presten a interpretación se usa a menudo la notación EARS (Easy Approach to Requirements Syntax), que obliga a nombrar el disparador, el sistema y la conducta esperada: "CUANDO el usuario envía el formulario sin correo, EL SISTEMA DEBE mostrar el error junto al campo y no enviar nada". Un requisito así se puede probar; "el formulario debe validar bien" no.

Los tres niveles de SDD

Birgitta Böckeler, de Thoughtworks, propuso en octubre de 2025 una clasificación que hoy usan casi todas las herramientas para describirse. La pregunta es cuánto tiempo sigue importando la especificación:

El tercer nivel es la apuesta más ambiciosa y la menos probada: recuerda a lo que prometió el desarrollo dirigido por modelos (MDD) hace veinte años, ahora con la dificultad añadida de que un modelo de lenguaje no genera dos veces lo mismo.

En la práctica, la mayoría de los equipos que hacen SDD en serio apuntan a spec-anchored: es lo que evita que la documentación quede desactualizada.

Cómo se usa en 2026

Más allá del framework que se elija, los equipos que sacan buen resultado de SDD comparten algunas prácticas:

• Un archivo de contexto para el agente. AGENTS.md (o CLAUDE.md) en la raíz del repositorio: qué es el proyecto, cómo se corre, qué convenciones sigue y qué debe verificar antes de dar algo por terminado.
• Especificar sólo lo que se va a tocar. En un sistema existente no se documenta todo antes de empezar. Cada cambio especifica su propio pedazo, y la documentación crece alrededor del trabajo real.
• Contexto limpio para implementar. Un agente con la ventana de contexto llena rinde peor. Se planifica en una sesión, se limpia el contexto y se implementa con la especificación y el plan como única entrada.
• Tareas pequeñas. Cada tarea debe caber en una sesión corta y tener un criterio de término verificable.
• Pruebas trazables a requisitos. Cada requisito numerado tiene al menos una prueba que lo cubre. La validación deja de ser "parece que funciona".
• El humano decide. El agente propone especificaciones, planes y código; el programador los revisa, los corrige y los aprueba. Sin esa revisión, SDD es vibe coding con más archivos.

Los tres frameworks principales

Los tres son de código abierto, gratuitos y funcionan con varios agentes. Todos producen archivos Markdown dentro del repositorio y se usan con comandos o skills dentro del chat del agente.

OpenSpec (Fission AI)

Nació en agosto de 2025 y ronda las 70 mil estrellas en GitHub (versión 1.13, licencia MIT). Se instala con npm o Homebrew y se inicializa con openspec init. Su filosofía está en su propio README: fluido antes que rígido, iterativo antes que en cascada y pensado para código existente (brownfield-first).

El ciclo tiene tres comandos:

Antes de proponer se puede usar /opsx:explore, que lee el código y ayuda a pensar el cambio sin crear nada.

Su pieza clave son las delta specs: cada cambio se escribe como requisitos agregados, modificados o eliminados respecto de lo que el sistema ya hace (ADDED, MODIFIED, REMOVED). Por eso funciona bien en un proyecto de 80 mil líneas: no hay que documentar todo el sistema para empezar. Los requisitos se escriben en Markdown simple, con la palabra SHALL (DEBE) y escenarios CUANDO/ENTONCES. Funciona con más de 30 herramientas, y en 2026 sumó los Stores (en beta): un repositorio aparte para planificar cambios que abarcan varios repositorios.

Spec Kit (GitHub)

Lo publicó GitHub en agosto de 2025 y es el más popular de los tres: cerca de 140 mil estrellas y versión 1.0 desde agosto de 2026. Se instala con Python y uv, y se inicializa con specify init. Declara integración con 38 agentes.

Su centro es la constitución del proyecto y un flujo por fases para cada funcionalidad:

La constitución se escribe una sola vez por proyecto, con /speckit-constitution.

Tiene puertas de calidad opcionales: clarify resuelve ambigüedades antes de planificar, checklist genera lo que el proyecto llama "pruebas unitarias para los requisitos" y analyze revisa la coherencia entre especificación, plan y tareas antes de implementar. En 2026 incorporó dos procesos más como extensiones: uno para corregir bugs (diagnosticar, corregir, verificar) y otro para evaluar si una idea merece construirse.

Durante 2025 se le criticó que generaba mucho Markdown repetitivo y que dejaba la especificación atrás una vez implementada. La versión actual responde lo segundo con converge y con tres modelos de mantenimiento de la especificación entre los que el equipo elige: flow-back (todos los documentos se ajustan entre sí), flow-forward (cada funcionalidad queda como registro inmutable) y living spec (la especificación manda y el plan y las tareas se regeneran). Lo primero sigue siendo verdad: es el más estructurado de los tres, y se nota.

BMAD Method (BMad Code)

Es el más antiguo (abril de 2025) y el más ambicioso: ronda las 54 mil estrellas y va en la versión 6.12. Su propuesta no es sólo un formato de especificación, sino un método ágil completo con agentes especializados. Se instala como skills (npx skills add) o como plugin de Claude Code o Codex.

Trae cinco agentes con nombre y rol:

Con el party mode se puede sentar a varios de ellos en la misma conversación, cada uno desde su rol, con el programador moderando.

Las comparaciones de 2025 describían a BMAD como pesado para cualquier cambio: una docena de agentes y un PRD fragmentado en historias antes de escribir una línea. La versión 6 corrige eso y dimensiona el proceso según el trabajo:

Suma revisión de código con varios revisores independientes, generación de pruebas de extremo a extremo y un modo para construir una épica sin supervisión. También ofrece paquetes para planificar desde ChatGPT o Gemini y después llevar los documentos al agente de código.

Otros nombres que conviene conocer

• Kiro es el entorno de desarrollo de AWS construido alrededor de SDD. Genera requisitos en notación EARS, diseño y tareas, pero no es un framework que se agrega a tu editor: hay que trabajar dentro de Kiro, en su IDE o en su CLI. Böckeler lo clasificó como spec-first.
• Tessl es la apuesta más clara por spec-as-source. Además mantiene un registro de especificaciones de librerías de código abierto que ayuda a los agentes a no inventar APIs.

Comparación

¿Cuál elegir?

No hay uno mejor en términos absolutos. Depende del dolor que se quiere resolver:

• "El agente rompe cosas que ya funcionaban." OpenSpec. Las delta specs acotan cada cambio y la documentación crece sola.
• "En el equipo cada uno trabaja con la IA a su manera." Spec Kit. La constitución y las fases alinean a todos, y las extensiones permiten adaptarlo.
• "Estamos construyendo un producto desde cero y nos falta pensar el producto, no sólo el código." BMAD. Sus agentes de análisis, producto y arquitectura hacen las preguntas que un agente de código se salta.

La advertencia más importante

Por eso el consejo de MoureDev es aprender primero SDD a mano, con una plantilla de especificación y buenos prompts, y sólo después adoptar un framework. Quien no sabe escribir una buena especificación no va a saber revisar la que genera el agente, y termina aprobando documentos que no leyó. Las críticas serias a SDD apuntan justamente ahí: demasiados documentos para revisar, agentes que no siguen todas las instrucciones aunque estén escritas, y el mismo proceso pesado para un bug de una línea. La respuesta no es abandonar la especificación, sino dimensionarla al cambio y revisarla de verdad.

Cómo lo aplicamos en Trini-Tech

Desarrollamos con agentes de IA todos los días, y la regla que más nos ha servido es la misma de SDD: nada se implementa sin un acuerdo escrito. Cada módulo tiene su registro de decisiones, cada sesión de trabajo termina con un documento de traspaso que la siguiente lee antes de empezar, y cada cambio se valida con pruebas antes de llegar a producción. Así un agente puede retomar un trabajo de días sin reinventarlo, y una persona puede auditar por qué se tomó cada decisión.

Si tu equipo quiere incorporar agentes de IA a su desarrollo sin perder el control del código, o necesita construir software con este método, conversemos.