Spec Kit vs OpenSpec: ¿qué herramienta SDD elegir para tu equipo?
Dos herramientas CLI para Spec-Driven Development con filosofías opuestas: fragmentación por feature vs fuente de verdad unificada. Comparativa práctica y recomendación concreta para proyectos reales.
El problema que resuelven: el "vibe coding"
Cuando un equipo trabaja con agentes de IA sin una especificación clara, el resultado inevitable es lo que la comunidad llama vibe coding: el código se escribe según la interpretación del momento, las implementaciones divergen de la intención original y, con el tiempo, nadie sabe con certeza por qué se tomaron ciertas decisiones.
Tanto Spec Kit como OpenSpec son herramientas CLI que abordan exactamente este problema. Las dos parten de la misma premisa: las especificaciones deben ir primero, el código viene después. Sin embargo, divergen significativamente en cómo estructuran esas specs y en cómo mantienen la alineación entre lo que se diseñó y lo que se implementó.
En pocas palabras: Spec Kit organiza el conocimiento por feature, distribuyendo la información en múltiples ficheros. OpenSpec lo centraliza en un único documento vivo que evoluciona mediante deltas. La elección entre uno y otro no es trivial — depende del estado actual de tu proyecto y de cómo trabaja tu equipo.
Comparativa rápida
| Dimensión | Spec Kit | OpenSpec |
|---|---|---|
| Estructura de specs | Fragmentada por feature (múltiples ficheros) | Fuente de verdad única (documento unificado) |
| Enfoque de alineación | Spec-First: guía el diseño inicial | Spec-Anchored: validación continua |
| Velocidad de iteración | Más estructurado, fases completas | Ligero, ciclos de iteración rápidos |
| Tipo de proyecto | Greenfield, sistemas multi-feature complejos | Brownfield, modernización incremental |
| Fases de trabajo | /specify → /plan → /tasks → implement | Propose → Apply → Archive (delta-based) |
| Integración | Nativo en GitHub, sistema de extensiones | Agnóstico al repositorio, orientado a agentes IA |
Fragmentada vs. unificada: dos filosofías opuestas
Esta es la diferencia más profunda entre ambas herramientas y la que más influye en el día a día del equipo.
Spec Kit — fragmentación por feature
Cada feature tiene su propio conjunto de ficheros de especificación. Esto facilita el análisis cruzado entre features, pero para entender el estado completo del sistema hay que ensamblar información dispersa en múltiples fuentes.
Ejemplo: si el módulo de pagos depende del módulo de usuarios, tienes que leer ambas specs y mantener en tu cabeza la relación entre ellas.
OpenSpec — fuente de verdad única
Las especificaciones se consolidan en un único documento vivo. Los cambios se proponen como delta specs (marcando secciones como ADDED, MODIFIED o REMOVED) y se fusionan durante el archivado.
Ejemplo: el estado actual del sistema está siempre visible en un solo documento. No hay que navegar entre ficheros para obtener el contexto completo.
Ninguna de las dos estructuras es objetivamente superior. La fragmentación de Spec Kit funciona bien cuando cada feature tiene lógica suficientemente independiente. La centralización de OpenSpec paga dividendos en proyectos donde el acoplamiento entre componentes es alto o donde el equipo necesita una visión global rápida.
Niveles de alineación: Spec-First vs Spec-Anchored
Aquí reside una diferencia conceptual importante que tiene implicaciones prácticas a largo plazo.
Spec Kit — Spec-First
Las specs guían el diseño inicial y son la referencia durante la implementación. El problema surge a medida que la base de código crece: validar que el código sigue alineado con las specs se vuelve cada vez más costoso. Con el tiempo, puede aparecer una brecha silenciosa entre lo que dice la spec y lo que hace el código.
OpenSpec — Spec-Anchored
La especificación unificada puede validarse contra la implementación en cualquier momento del ciclo de vida del proyecto. Esto depende de la disciplina del equipo al mantener el documento actualizado, pero la estructura lo hace posible. Es el enfoque más cercano a la validación continua real.
Punto crítico: en la práctica, la alineación siempre depende de la disciplina del equipo. Ni Spec Kit ni OpenSpec resuelven por sí solos el problema si el equipo no tiene el hábito de actualizar las specs cuando el código cambia.
Flujo de trabajo y velocidad de iteración
El flujo de trabajo de cada herramienta refleja su filosofía de fondo.
Spec Kit — cuatro fases estructuradas
Flujo completo y exhaustivo. Ideal cuando el equipo distingue claramente las fases de diseño, planificación y ejecución. Puede sentirse lento si los cambios son pequeños e incrementales.
OpenSpec — ciclo de tres pasos orientado a agentes
Ciclo más ligero basado en deltas. El agente propone un cambio acotado, lo aplica y lo archiva en la fuente de verdad. Pensado para mantener el estado de flow con herramientas como Claude Code o Cursor.
Cuándo elegir cada una: casos reales
Elige Spec Kit si…
Proyecto greenfield desde cero
Estás construyendo un SaaS nuevo con 8 features distintas. Spec Kit te permite definir cada una con contexto independiente y navegar entre ellas sin perder el hilo.
Sistemas multi-feature con dependencias cruzadas
Cuando un cambio en el módulo de facturación puede afectar al módulo de inventario y al de usuarios, tener specs por feature facilita rastrear el impacto.
Equipos que ya usan GitHub como fuente de verdad
Si tu equipo vive en GitHub — issues, PRs, Actions — la integración nativa de Spec Kit reduce fricción. Las specs están donde el equipo ya trabaja.
Fases de desarrollo bien definidas
Si tu equipo distingue claramente entre diseño, planificación, tasking e implementación, el flujo de cuatro fases de Spec Kit encaja con esa cadencia.
Elige OpenSpec si…
Base de código legada que necesitas modernizar
Tienes un monolito de cinco años. No puedes reescribir todo, pero sí puedes ir añadiendo specs a medida que tocas cada módulo. OpenSpec está pensado exactamente para esto.
Iteración rápida con agentes IA (Claude Code, Cursor)
El ciclo Propose → Apply → Archive está diseñado para mantenerse en flow con un agente. Los delta specs permiten proponer cambios precisos sin reescribir el documento completo.
Validación continua de la implementación
Con una fuente de verdad unificada, puedes verificar en cualquier momento que el código sigue alineado con la spec — sin ensamblar información de múltiples ficheros.
Cambios incrementales frecuentes
Si tu equipo hace releases semanales con cambios pequeños y acotados, el sistema de deltas de OpenSpec es más eficiente que reabrir ciclos completos de specify/plan/tasks.
Recomendación concreta
Si tuviéramos que dar una recomendación directa para los equipos con los que trabajamos, sería esta: empieza con OpenSpec si ya tienes código existente, empieza con Spec Kit si partes de cero con un sistema complejo.
La razón es pragmática. La mayoría de los equipos no trabaja en proyectos greenfield — tiene deuda técnica, módulos legados y código sin documentar. En ese contexto, intentar aplicar el flujo completo de Spec Kit desde el inicio genera frustración: hay demasiado código que no tiene spec y es imposible cubrir todo a la vez.
OpenSpec, en cambio, funciona bien en modo incremental: cada vez que tocas un módulo, añades o actualizas el delta. Con el tiempo, la fuente de verdad se completa orgánicamente. Es menos ambicioso en el punto de partida, pero más sostenible en la práctica.
Para proyectos nuevos con múltiples features y un equipo que ya tiene disciplina de documentación, Spec Kit ofrece una estructura más sólida desde el primer día — especialmente si el equipo ya está en el ecosistema GitHub y quiere integración nativa con su flujo de trabajo actual.
Lo que no recomendamos: elegir la herramienta basándote en cuál es más popular o cuál tiene mejor marketing. Ambas resuelven el mismo problema fundamental. La diferencia está en el ajuste con tu contexto específico. Si tu equipo no tiene el hábito de escribir specs, ninguna herramienta lo creará por sí sola — ese es el trabajo de cultura de equipo que hay que hacer antes de adoptar cualquiera de las dos.
Referencias
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.