GitHub quiere resolver uno de los problemas más evidentes de la programación con agentes de inteligencia artificial: pedir una aplicación mediante un prompt, dejar que el modelo escriba cientos o miles de líneas y descubrir demasiado tarde que había entendido mal los requisitos. Spec Kit propone invertir ese proceso y convertir la especificación en el punto de partida del desarrollo, antes de que el agente toque el código. La idea está encontrando una enorme respuesta entre los desarrolladores: la documentación oficial mostraba recientemente más de 121.000 estrellas en GitHub y el proyecto continúa creciendo.
Las claves de GitHub Spec Kit en 30 segundos
- Spec Kit es un proyecto open source de GitHub para aplicar Spec-Driven Development (SDD) al desarrollo con agentes de IA.
- En lugar de saltar del prompt al código, genera especificaciones, planes técnicos y listas de tareas antes de implementar.
- Su flujo incluye
constitution,specify,clarify,plan,tasks,analyzeeimplement. - Actualmente documenta 35 integraciones con agentes y herramientas de programación.
- GitHub presentó el proyecto en septiembre de 2025 y su popularidad muestra una tendencia más amplia: cuanto más capaces son los agentes, más importante resulta darles contexto estructurado.
Conviene corregir una parte de la afirmación que circula estos días por redes sociales. Spec Kit no acaba de aparecer. GitHub presentó públicamente el proyecto el 2 de septiembre de 2025 como un toolkit open source para desarrollar software mediante especificaciones. Lo que sí resulta llamativo es el crecimiento posterior: la documentación del proyecto contabilizaba en julio de 2026 más de 121.000 estrellas, 240 colaboradores y 35 integraciones.
Repositorio oficial de GitHub Spec Kit
El proyecto suministrado también muestra hasta qué punto ha crecido desde aquella primera versión. Además del proceso básico incorpora actualmente extensiones, presets, bundles para distintos perfiles y mecanismos para adaptar el sistema a los estándares internos de una organización.
Lo interesante, sin embargo, no son las estrellas. Es el problema que intenta solucionar.
El vibe coding funciona muy bien hasta que el proyecto empieza a crecer
El término vibe coding se ha utilizado para describir una forma de programar en la que el desarrollador explica mediante lenguaje natural lo que quiere y deja que la IA genere buena parte del código.
Para crear una pequeña aplicación, una prueba de concepto o una herramienta de uso personal puede resultar extraordinariamente rápido.
El problema aparece al aumentar la complejidad.
Un usuario puede escribir algo aparentemente tan sencillo como:
«Crea una aplicación para gestionar las reservas de un restaurante.»
Un agente moderno puede empezar inmediatamente a generar la interfaz, seleccionar una base de datos, crear usuarios, desarrollar una API y añadir las tablas necesarias.
Pero faltan bastantes preguntas.
¿Qué ocurre si dos personas intentan reservar la última mesa simultáneamente? ¿Puede modificarse una reserva? ¿Existen varios restaurantes? ¿Hay distintos horarios según el día? ¿Qué información personal se almacena? ¿Durante cuánto tiempo? ¿Qué permisos tiene cada empleado? ¿Cómo se autentican? ¿Qué ocurre cuando falla un pago?
Si esas decisiones no aparecen en el prompt inicial, el modelo tendrá que hacer algo inevitable: asumirlas.
Y una IA que escribe código muy rápido también puede construir muy rápido la aplicación equivocada.
GitHub describía precisamente este problema cuando presentó Spec Kit: los agentes pueden producir código que parece correcto pero no compila, resolver únicamente parte del problema o elegir una arquitectura diferente de la esperada. Para la compañía, parte del problema está en tratar al agente como un buscador al que se lanza una petición en lugar de proporcionarle instrucciones suficientemente precisas.
Spec Kit intenta colocar una capa de ingeniería entre esas dos cosas.
De un prompt a una especificación que acompaña al proyecto
La filosofía se resume bastante bien en el lema oficial del proyecto: definir qué construir antes de construirlo.
GitHub denomina al enfoque Spec-Driven Development o desarrollo dirigido por especificaciones.
Las especificaciones tradicionales suelen preceder al desarrollo y después quedan relegadas a documentación. Spec Kit pretende que sean artefactos activos utilizados directamente por los agentes para generar, comprobar y evolucionar el software.
El proceso básico empieza con /speckit.constitution.
Aquí se establecen las reglas generales del proyecto: estándares de calidad, requisitos de seguridad, política de pruebas, rendimiento, experiencia de usuario o principios arquitectónicos.
Después llega /speckit.specify.
Es probablemente el cambio más importante respecto al vibe coding directo. El desarrollador explica qué quiere construir y por qué, evitando entrar todavía en los detalles tecnológicos.
A continuación puede utilizar /speckit.clarify para detectar requisitos ambiguos o insuficientemente definidos. Es una fase opcional, pero especialmente interesante porque fuerza a resolver dudas antes de convertirlas en decisiones de arquitectura.
Con /speckit.plan se pasa al cómo: tecnologías, arquitectura y decisiones técnicas.
Después /speckit.tasks transforma el plan en una lista ordenada de trabajo y /speckit.implement entrega finalmente esas tareas al agente para que escriba el código. Entre ambos puede utilizarse /speckit.analyze para comprobar la consistencia entre especificaciones, plan y tareas.
El flujo simplificado queda así:
constitution → specify → clarify → plan → tasks → analyze → implement
La diferencia parece pequeña, pero conceptualmente es importante.
La IA sigue programando. Lo que cambia es que se intenta reducir la cantidad de decisiones que tiene que inventarse mientras programa.
No elimina las alucinaciones ni garantiza buen software
Aquí también conviene evitar convertir Spec Kit en una solución mágica.
Utilizar especificaciones no garantiza que un agente escriba código correcto.
Una especificación puede estar equivocada. El modelo puede interpretarla mal. La arquitectura propuesta puede ser deficiente. Pueden aparecer vulnerabilidades, errores de concurrencia, dependencias problemáticas o problemas que únicamente aparecen en producción.
Las pruebas, revisiones de código, análisis de seguridad, integración continua y supervisión humana siguen teniendo sentido.
Lo que Spec Kit intenta solucionar es un problema anterior: que requisitos, arquitectura y código no empiecen a divergir desde el primer prompt.
También introduce una ventaja especialmente importante para sesiones largas con agentes.
Los modelos trabajan dentro de ventanas de contexto finitas. A medida que una conversación crece, resulta más difícil mantener presentes todas las decisiones adoptadas anteriormente. Una especificación persistente proporciona al agente una referencia externa que puede volver a consultar.
GitHub incluso documenta un enfoque denominado spec of specs para funcionalidades demasiado grandes como para completar cómodamente un único ciclo. El sistema divide entonces una gran funcionalidad en especificaciones menores que recorren individualmente las fases de especificación, planificación, tareas e implementación.
Esto se parece bastante más a ingeniería de software que a encadenar prompts esperando que el modelo recuerde todo lo hablado.
Spec Kit tampoco quiere depender de Copilot
Otro detalle importante es que GitHub no ha limitado el proyecto a su propio asistente.
La documentación actual habla de 35 integraciones y permite trabajar con herramientas y agentes como GitHub Copilot, Claude, Codex, Gemini, Kiro, Zed y otros. El número ha aumentado considerablemente desde las primeras versiones.
Esto convierte Spec Kit más en una metodología acompañada de herramientas que en una función exclusiva de Copilot.
La instalación crea dentro del proyecto los recursos necesarios para que el agente conozca los comandos y plantillas. Cada fase genera artefactos Markdown que sirven como entrada para la siguiente, proporcionando contexto estructurado en lugar de depender únicamente del historial de conversación.
El proyecto ha crecido además hacia organizaciones que necesitan algo más que el flujo básico.
Los presets permiten adaptar las especificaciones a estándares corporativos, requisitos regulatorios o metodologías determinadas. Las extensions añaden nuevas capacidades y fases. Y los bundles agrupan configuraciones para perfiles como desarrolladores, responsables de producto, analistas de negocio o investigadores de seguridad.
También puede funcionar offline y detrás de firewalls, algo especialmente relevante para empresas que no quieren depender de servicios externos para almacenar las reglas internas de sus proyectos.
Del prompt engineering al context engineering
Spec Kit representa además un cambio más amplio que está ocurriendo alrededor de la programación con IA.
Durante la primera etapa de la IA generativa se habló muchísimo de prompt engineering.
Había que encontrar el prompt perfecto.
Después llegaron los agentes y quedó claro que un único prompt perfecto rara vez existe para proyectos complejos. Un agente necesita documentación, herramientas, estado del repositorio, convenciones, ejemplos, tests, restricciones y conocimiento sobre aquello que está intentando construir.
La conversación se ha desplazado hacia el context engineering: proporcionar al modelo el contexto correcto en el momento adecuado.
Spec Kit encaja exactamente ahí.
En lugar de:
idea → prompt enorme → código
propone algo parecido a:
idea → requisitos → dudas → especificación → arquitectura → tareas → código → validación
Paradójicamente, cuanto mejores se vuelven los agentes programando, más importante puede resultar esta capa.
Un agente mediocre comete errores despacio.
Uno muy capaz puede generar diez archivos, modificar otros veinte y adoptar varias decisiones arquitectónicas en minutos. Si entendió correctamente el objetivo, esa velocidad es extraordinariamente útil.
Si entendió mal una premisa fundamental, también puede alejarse del objetivo mucho más rápido.
El vibe coding no desaparece, empieza a madurar
Por eso decir que GitHub ha «solucionado el mayor problema del vibe coding» probablemente sea demasiado rotundo.
Spec Kit no resuelve automáticamente los problemas de calidad del software generado mediante IA.
Hace algo quizá más interesante: formaliza una de las lecciones que están aprendiendo quienes trabajan habitualmente con agentes de programación.
Dar más autonomía a la IA no significa necesariamente darle menos instrucciones.
Puede significar exactamente lo contrario.
El desarrollador deja de explicar cada línea que debe escribir, pero necesita ser mucho más preciso sobre requisitos, restricciones, arquitectura, criterios de aceptación y resultado esperado.
El código pierde parte de su protagonismo como primera descripción del sistema. La intención pasa a ocupar ese lugar.
GitHub lo expresa de una forma todavía más ambiciosa: en el desarrollo dirigido por especificaciones, estas dejan de ser el andamio que se tira después de construir y pasan a convertirse en artefactos capaces de generar directamente implementaciones.
Quizá esa sea la evolución más interesante del vibe coding.
La primera fase consistió en descubrir que una persona podía describir una aplicación y una IA podía escribir buena parte del código.
La segunda está consistiendo en descubrir que describir bien una aplicación sigue siendo ingeniería de software.
Y ningún modelo, por muchas líneas de código que genere por segundo, puede eliminar la necesidad de decidir primero qué se quiere construir.
Preguntas frecuentes
¿Qué es GitHub Spec Kit?
Spec Kit es un proyecto open source de GitHub para aplicar desarrollo dirigido por especificaciones a agentes de programación con IA. Convierte requisitos, planes y tareas en artefactos estructurados que posteriormente utiliza el agente para implementar el software.
¿Spec Kit sirve únicamente con GitHub Copilot?
No. La documentación actual indica que dispone de 35 integraciones con agentes y herramientas de programación, entre ellas Copilot, Claude, Codex y Gemini.
¿Qué diferencia hay entre Spec Kit y el vibe coding?
En el vibe coding más directo se pasa rápidamente de una descripción en lenguaje natural a generar código. Spec Kit introduce antes varias etapas para definir requisitos, resolver ambigüedades, establecer la arquitectura y dividir el trabajo en tareas.
¿Spec Kit evita que la IA genere código incorrecto?
No. Las especificaciones pueden contener errores y los agentes pueden equivocarse al implementarlas. Su objetivo es proporcionar contexto más estructurado y reducir ambigüedades, no sustituir las pruebas, la revisión de código, la seguridad o la supervisión humana.
