Spec Kit, el kit de GitHub para trabajar con Spec-Driven Development (SDD), el desarrollo guiado por especificaciones, es de código abierto, tiene licencia MIT y el 15 de octubre de 2026 sumaba unas 141.300 estrellas en GitHub. Trae el flujo completo: una constitución con los principios del proyecto, la especificación, el plan, las tareas y la implementación.
Es una buena noticia para cualquier equipo de desarrollo, y tiene una consecuencia que conviene decir en voz alta: si la plantilla es gratis y la puede instalar cualquiera, la plantilla ya no es lo que distingue a un equipo de otro.
De ahí sale la tesis de esta pieza: lo que decide si un equipo entrega distinto con SDD es lo que la plantilla no trae. Cuándo se usa la especificación completa, cuánto puede ocupar para que alguien la lea, qué prueba que el agente la ha seguido y quién mantiene las reglas del proyecto. Eso no se descarga: se decide.
Qué trae la plantilla, y qué no
Qué es SDD y en qué se diferencia de programar a base de prompts lo explicamos en Spec-Driven Development: código con IA bajo control. Aquí basta con lo esencial: antes de que el agente escriba código, se escribe qué hay que construir, por qué y con qué criterios se dará por bueno. Spec Kit convierte ese principio en comandos que se lanzan desde el chat del agente, y la mayoría de las herramientas de SDD siguen un esquema parecido.
Lo que ninguna plantilla puede traer es el contexto del equipo: qué tamaño tienen sus cambios, cuánto tiempo de revisión tiene, qué riesgos asume y quién responde de cada decisión. Una plantilla está hecha para servir a cualquiera, y por eso no sabe nada de nadie.
Lo que cuentan quienes la han probado
Lo más útil sobre estas herramientas lo cuenta quien las ha usado con calma. En octubre de 2025, Birgitta Böckeler, de Thoughtworks, probó Kiro, Spec Kit y Tessl y publicó lo que vio en martinfowler.com. Tres observaciones importan aquí:
- El tamaño. Pidió a Kiro que corrigiera un error pequeño y el flujo fue, en sus palabras, «como usar un mazo para cascar una nuez»: cuatro historias de usuario con dieciséis criterios de aceptación. Concluye que una buena herramienta tendría que ofrecer flujos distintos para cambios de distinto tamaño y tipo.
- La revisión. Spec Kit le generó muchos archivos markdown para revisar, repetitivos y tediosos. Según ella, una herramienta de SDD eficaz tendría que ofrecer una experiencia muy buena de revisión de especificaciones.
- El cumplimiento. Pese a los archivos, las plantillas y las listas de comprobación, vio a menudo que el agente acababa sin seguir todas las instrucciones.
Y aun así no descarta la idea: escribe que el principio de especificar primero es, sin duda, valioso en muchas situaciones. El Technology Radar de Thoughtworks dijo algo parecido en noviembre de 2025, cuando colocó el desarrollo guiado por especificaciones en el anillo «Assess» (evaluar): los flujos siguen siendo «elaborados y con opiniones fuertes», y algunas herramientas generan especificaciones largas y difíciles de revisar. Esa entrada ya no figura en la edición vigente del Radar.
Ninguna de estas críticas dice que especificar sobre. Dicen que la herramienta no decide por el equipo cuándo especificar, cuánto ni cómo comprobarlo.
Cuatro decisiones que no vienen en la plantilla
Cada una de las críticas anteriores corresponde a una decisión que el equipo tiene que tomar antes de que la plantilla le sirva de algo:
| Decisión | Lo que trae la plantilla | Lo que tiene que decidir el equipo |
|---|---|---|
| Cuándo hay especificación completa | Un flujo pensado para cualquier cambio | Un umbral por tamaño y riesgo: por debajo, un carril corto; por encima, el flujo entero |
| Cuánto puede ocupar | Los documentos que el agente genere | Un límite de lectura: lo que una persona revisa con atención de una vez. Si no se lee, no se aprueba |
| Qué prueba que se ha cumplido | Instrucciones para el agente | Criterios de aceptación que se convierten en pruebas y deciden si el cambio entra |
| Quién mantiene las reglas del proyecto | Un archivo de principios (la constitución) | Una persona con nombre que responde de esas reglas, y cambios que se aprueban aparte |
Elaboración propia de onext a partir de las observaciones de Birgitta Böckeler y del Technology Radar de Thoughtworks
Las dos últimas filas tienen pieza propia. Cómo un criterio de aceptación se convierte en la puerta del merge está en tu spec ya es un eval, y qué firma cada persona en el ciclo, en specs y agentes: dónde se firma. La relación de SDD con las pruebas escritas antes del código, Test-Driven Development (TDD), la contamos en SDD, TDD y BDD: qué aporta cada uno.
Las dos primeras son las que más se saltan, porque no parecen decisiones técnicas. Lo son. Sin umbral, el equipo especifica todo o deja de especificar al poco tiempo, cansado de rellenar documentos para cambios de diez líneas. Sin límite de lectura, la especificación crece hasta que nadie la lee, y entonces la aprobación es una firma sin lectura detrás. Si además el código es antiguo, el umbral importa todavía más: no se especifica el sistema entero, sino la parte que se va a tocar, como explicamos en especificar el código legacy antes de los agentes.
Algo parecido pasa con la constitución. Un archivo de principios que el agente lee no hace cumplir nada por sí solo: orienta, pero no impide. Lo que tiene que cumplirse va en controles que se aplican solos, como contamos en Claude Code para equipos: contexto no es control.
Riesgo Instalar la plantilla sin estas cuatro decisiones da la apariencia de método: documentos largos, aprobaciones que nadie ejerce y un agente que sigue las instrucciones a medias, con todo bien archivado.
La herramienta amplifica lo que ya hay
DORA, el programa de investigación de Google sobre equipos de software, llegó en su informe de 2025 sobre desarrollo asistido por IA a una conclusión que vale también para SDD: el papel principal de la IA es el de amplificador, que magnifica las fortalezas y las debilidades que la organización ya tiene. Y los mayores retornos de la inversión en IA, según el mismo informe, no vienen de las herramientas en sí.
Aplicado a las plantillas de SDD: en un equipo que ya sabe trocear el trabajo, revisar con criterio y decidir quién responde de qué, Spec Kit ordena y acelera. En un equipo que no lo sabe, produce más documentos sin cambiar cómo se trabaja. Por eso conviene revisar primero la red que detecta los errores, como contamos en antes del agente, la red, y después elegir la plantilla.
Que la plantilla sea gratis tiene una ventaja: el equipo puede cambiar de herramienta sin perder nada, siempre que su método no dependa de ella. Si mañana aparece un kit mejor, las cuatro decisiones siguen valiendo.
Dónde encaja onext
En AI-Accelerated Development construimos con tu equipo el contexto en el que trabaja la IA y el proceso con el que trabajáis. Los dos se quedan en tu casa. Una persona decide donde hay riesgo. El primer paso es un diagnóstico gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Si quieres ver antes dónde está tu equipo, el autodiagnóstico de 16 preguntas es un buen punto de partida.
Preguntas frecuentes
¿Qué es Spec Kit?
Es el kit de código abierto de GitHub para trabajar con Spec-Driven Development (SDD), con licencia MIT. Da a los agentes de programación un proceso estructurado: una constitución con los principios del proyecto, la especificación, el plan, las tareas y la implementación.
Si la plantilla es gratis, ¿para qué hace falta nadie más?
Para instalarla, no hace falta. Lo que cuesta es lo que la plantilla no trae: decidir cuándo se usa la especificación completa, cuánto puede ocupar para que alguien la lea, qué prueba que el agente la ha seguido y quién mantiene las reglas del proyecto. Un equipo puede decidirlo solo; lo importante es que lo decida, no que lo compre.
¿Sirve SDD para corregir un error pequeño?
Con el flujo completo, normalmente no. Birgitta Böckeler, de Thoughtworks, cuenta que pedir a Kiro que corrigiera un error pequeño fue como usar un mazo para cascar una nuez: salieron cuatro historias de usuario con dieciséis criterios de aceptación. Por eso conviene fijar un umbral: por debajo, un carril corto; por encima, especificación completa.
¿Cómo se evita escribir especificaciones que nadie lee?
Poniendo un límite de lectura: lo que una persona puede revisar con atención de una vez. Si la especificación lo supera, se parte o se recorta. El Technology Radar de Thoughtworks ya avisaba de que algunas herramientas generan especificaciones largas y difíciles de revisar, y una especificación que nadie lee tampoco la aprueba nadie de verdad.
¿El agente sigue siempre la especificación?
No. Böckeler escribe que, pese a todos los archivos, plantillas y listas de comprobación, vio a menudo que el agente acababa sin seguir todas las instrucciones. Por eso la especificación tiene que traer criterios de aceptación que se puedan comprobar con pruebas, y no solo instrucciones para el agente.
¿Qué herramienta conviene elegir: Spec Kit, Kiro o Tessl?
Primero el método y después la herramienta. Las tres parten de una especificación antes del código y difieren en el flujo y en cuánto conservan la especificación después. Si el equipo tiene decididos el umbral, el límite de lectura, la comprobación y quién decide, cambiar de herramienta no cambia su forma de trabajar.
Fuentes
- GitHub, «Spec Kit», repositorio (sin fecha visible; consultado el 15 de octubre de 2026, unas 141.300 estrellas ese día).
- Birgitta Böckeler (Thoughtworks), «Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl», martinfowler.com, 15 de octubre de 2025.
- Thoughtworks, «Spec-driven development», Technology Radar, anillo Assess, 5 de noviembre de 2025 (no figura en la edición vigente).
- DORA, «State of AI-assisted Software Development 2025» (2025; sin fecha exacta visible).
- Las citas de fuentes en inglés están traducidas por onext. La tabla de las cuatro decisiones y su lectura son elaboración propia de onext.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →