Spec-Driven Development: Spec Kit vs Kiro vs OpenSpec, cuál elegir en 2026

Si usas agentes de código a diario, ya conoces el problema, el agente es rapidísimo, pero los requisitos viven en el historial del chat. Cambias de sesión, se pierde el contexto y el agente empieza a improvisar. El Spec-Driven Development (SDD) ataca justo eso, antes de escribir código, humano y agente acuerdan por escrito qué se va a construir, y esa especificación queda versionada en el repo.

En poco más de un año el SDD ha pasado de experimento a práctica habitual, y tres opciones se han quedado con casi toda la atención: GitHub Spec Kit, Kiro (AWS) y OpenSpec (Fission AI). Las tres comparten la idea de fondo, pero parten de filosofías muy distintas. Vamos a compararlas.

La idea común: requisitos, diseño y tareas

Las tres herramientas producen, con más o menos ceremonia, el mismo trío de artefactos en Markdown:

• Requisitos: qué tiene que hacer el sistema y cómo sabremos que lo hace (criterios de aceptación, escenarios).
• Diseño: cómo se va a resolver técnicamente.
• Tareas: lista de pasos implementables que el agente va completando.

La diferencia está en cuánto proceso imponen, dónde viven las specs y con qué herramientas puedes usarlas.

GitHub Spec Kit: el kit completo y extensible

Spec Kit es el toolkit open source (MIT) de GitHub y, con unas 142.000 estrellas, el proyecto de SDD más popular. Acaba de llegar a la versión 1.x y ya no se presenta solo como un flujo de SDD, sino como una caja de herramientas de procesos para agentes.

Se instala con la CLI specify (requiere Python 3.11+ y uv) y se integra con tu agente habitual. El flujo de SDD es secuencial y con revisión entre pasos:

/speckit-constitution   # principios del proyecto (una vez)
/speckit-specify        # qué y por qué
/speckit-plan           # stack y enfoque técnico
/speckit-tasks          # desglose en tareas
/speckit-implement      # implementación
/speckit-converge       # repetir hasta "Converged"

Lo que lo distingue:

• Constitución del proyecto: un documento de principios (calidad, testing, mantenibilidad) que condiciona todas las specs posteriores.
• Extensibilidad seria: extensiones (por ejemplo, flujos de corrección de bugs o de evaluación de ideas), presets para imponer estándares de la organización, workflows automatizables, bundles por rol y catálogos privados, incluso en entornos sin conexión.
• Agnóstico de agente: Copilot, Claude Code y la mayoría de asistentes del mercado.

El precio, es la opción más pesada. Genera mucho Markdown, cada fase pide revisión y para cambios pequeños puede parecer burocracia.

Kiro: el SDD dentro del entorno de desarrollo

Kiro es el IDE agéntico de AWS (basado en Code OSS, compatible con VS Code), hoy también disponible como CLI y en web. Aquí las specs no son un añadido, son una función central del producto.

Cada spec vive en el proyecto y genera tres documentos:

• requirements.md (o bugfix.md para errores): historias de usuario y criterios de aceptación, tradicionalmente en notación EARS (WHEN [condición] THE SYSTEM SHALL [comportamiento]).
• design.md: arquitectura, componentes, diagramas de secuencia, flujo de datos, gestión de errores y estrategia de testing.
• tasks.md: tareas trazables con su estado en tiempo real.

Lo que lo distingue:

• Varios modos: specs de funcionalidad (empezando por requisitos o por diseño), specs de bugs con análisis de causa raíz y una Quick Spec que genera los tres documentos de una vez para cosas bien entendidas.
• Ejecución por oleadas: al lanzar todas las tareas, Kiro construye un grafo de dependencias y ejecuta en paralelo las que no dependen entre sí.
• Revisión integrada: comentarios sobre los documentos dentro del IDE, análisis de huecos e inconsistencias en los requisitos y comprobaciones de corrección con tests basados en propiedades (estas dos últimas, solo en el IDE).

El precio, es un producto comercial con su propio modelo de créditos, y la experiencia completa te ata a su entorno. Si tu equipo usa otro editor u otro agente, las specs siguen siendo Markdown, pero pierdes casi todo lo que hace especial a Kiro.

OpenSpec: ligero y pensado para código que ya existe

OpenSpec, de Fission AI, también es open source (MIT) y ronda las 73.000 estrellas. Su filosofía cabe en una línea: fluido en vez de rígido, iterativo en vez de cascada, y pensado para proyectos existentes (brownfield), no solo para empezar desde cero.

Se instala como un único binario (o con npm o Homebrew), se inicializa con openspec init y funciona con más de 30 asistentes mediante slash commands:

/opsx:explore            # pensar opciones antes de comprometerse
/opsx:propose add-dark-mode
/opsx:apply              # implementar las tareas
/opsx:archive            # archivar y actualizar las specs

Lo que lo distingue:

• Centrado en cambios: cada cambio tiene su carpeta en openspec/changes/ con proposal.md, deltas de specs, design.md y tasks.md. Al archivarlo, los deltas se fusionan con las specs vivas del sistema en openspec/specs/.
• Specs como deltas: los requisitos se escriben como añadidos, modificaciones o eliminaciones (ADDED / MODIFIED / REMOVED Requirements), con escenarios WHEN / THEN en Markdown plano. Es justo lo que necesitas cuando tocas un sistema que ya funciona.
• Sin fases rígidas: puedes editar cualquier artefacto en cualquier momento.
• Stores (beta): un repositorio de planificación compartido para funcionalidades que abarcan varios repos.

El precio, menos estructura de partida. No hay constitución ni puertas de revisión obligatorias, así que la disciplina depende más del equipo.

Comparativa rápida

Cuál elegir

• Arrancas un proyecto nuevo o necesitas estandarizar cómo trabaja una organización con distintos agentes, Spec Kit. La constitución, los presets y los catálogos privados son difíciles de igualar.
• Quieres la experiencia más integrada y no te importa trabajar dentro de un entorno concreto, Kiro. La ejecución en paralelo por dependencias y la revisión dentro del IDE ahorran mucho trabajo manual.
• Trabajas sobre un sistema que ya está en producción y haces cambios incrementales con el agente que ya usas, OpenSpec. El modelo de deltas y la ausencia de fases obligatorias encajan con el día a día real.

Una mención aparte para BMAD Method, que roza las 55.000 estrellas, es más una metodología ágil completa con agentes por rol (analista, PM, arquitecto…) que una capa de specs, pero conviene tenerla en el radar si buscas algo más amplio.

Conclusión

La herramienta importa menos que el hábito. Las tres consiguen lo esencial, que lo que se va a construir quede escrito, revisado y versionado antes de que el agente toque el código. Mi recomendación práctica, si dudas, empieza por OpenSpec en un repo existente con un cambio pequeño. Si echas en falta estructura, pasa a Spec Kit. Y si tu equipo ya vive en el ecosistema AWS, prueba Kiro. Lo que ya no tiene sentido en 2026 es seguir programando con agentes solo a base de prompts.

Fuentes: GitHub Spec Kit, documentación de Kiro, OpenSpec. Estrellas de GitHub a 24 de octubre de 2026.