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 respuesta enorme entre los desarrolladores: la documentación oficial mostraba recientemente más de 121.000 estrellas en GitHub y el proyecto sigue 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 refleja una tendencia más amplia: cuanto más capaces son los agentes, más importa darles contexto estructurado.
Conviene corregir una parte de lo que circula estos dÃas por redes sociales: Spec Kit no acaba de aparecer. GitHub lo presentó públicamente el 2 de septiembre de 2025 como un toolkit open source para desarrollar software mediante especificaciones. Lo 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 también muestra hasta qué punto ha crecido desde aquella primera versión: además del proceso básico incorpora 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 resolver.
El vibe coding funciona muy bien hasta que el proyecto empieza a crecer
El término vibe coding describe una forma de programar en la que el desarrollador explica en lenguaje natural lo que quiere y deja que la IA genere buena parte del código. Para una pequeña aplicación, una prueba de concepto o una herramienta de uso personal puede resultar extraordinariamente rápido, pero el problema aparece en cuanto crece 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 de inmediato a generar la interfaz, elegir una base de datos, crear usuarios, montar una API y añadir las tablas necesarias. Pero faltan bastantes preguntas.
¿Qué ocurre si dos personas intentan reservar la última mesa a la vez? ¿Puede modificarse una reserva? ¿Existen varios restaurantes? ¿Hay horarios distintos según el dÃa? ¿Qué información personal se guarda y durante cuánto tiempo? ¿Qué permisos tiene cada empleado, cómo se autentican? ¿Qué pasa cuando falla un pago?
Si esas decisiones no aparecen en el prompt inicial, el modelo tiene 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 al presentar Spec Kit: los agentes pueden producir código que parece correcto pero no compila, resolver solo parte del problema o elegir una arquitectura distinta de la esperada. Para la compañÃa, parte del fallo está en tratar al agente como un buscador al que se lanza una petición, en lugar de darle 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 bien en el lema oficial del proyecto: definir qué construir antes de construirlo. GitHub llama a este enfoque Spec-Driven Development, o desarrollo dirigido por especificaciones.
Las especificaciones tradicionales suelen preceder al desarrollo y luego quedan relegadas a documentación olvidada. Spec Kit pretende que sean artefactos activos, usados directamente por los agentes para generar, comprobar y hacer evolucionar el software.
El proceso arranca con /speckit.constitution, donde se fijan las reglas generales del proyecto: estándares de calidad, requisitos de seguridad, polÃtica de pruebas, rendimiento, experiencia de usuario o principios de arquitectura. Después llega /speckit.specify, probablemente el cambio más importante frente al vibe coding directo, porque el desarrollador explica qué quiere construir y por qué, sin entrar todavÃa en detalles tecnológicos.
A partir de ahà puede usarse /speckit.clarify para detectar requisitos ambiguos o mal definidos. Es una fase opcional, pero interesante porque obliga a resolver dudas antes de que se conviertan en decisiones de arquitectura. Con /speckit.plan se pasa al cómo: tecnologÃas, arquitectura y decisiones técnicas. Luego /speckit.tasks convierte 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 usarse /speckit.analyze para comprobar que especificación, plan y tareas encajan entre sÃ.
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 reduce la cantidad de decisiones que tiene que inventarse mientras programa.
No elimina las alucinaciones ni garantiza buen software
Conviene no convertir Spec Kit en una solución mágica: usar especificaciones no garantiza que un agente escriba código correcto. Una especificación puede estar equivocada, el modelo puede interpretarla mal o la arquitectura propuesta puede ser deficiente. Pueden aparecer vulnerabilidades, errores de concurrencia, dependencias problemáticas o problemas que solo se ven en producción.
Las pruebas, las revisiones de código, el análisis de seguridad, la integración continua y la supervisión humana siguen teniendo sentido. Lo que Spec Kit intenta resolver es un problema anterior: que requisitos, arquitectura y código no empiecen a divergir desde el primer prompt.
También aporta una ventaja importante en sesiones largas con agentes. Los modelos trabajan dentro de ventanas de contexto finitas, y a medida que crece una conversación resulta más difÃcil mantener presentes todas las decisiones adoptadas antes. Una especificación persistente le da al agente una referencia externa a la que volver.
GitHub incluso documenta un enfoque llamado spec of specs para funcionalidades demasiado grandes como para completar cómodamente en un solo ciclo: el sistema divide entonces una gran funcionalidad en especificaciones menores que recorren, cada una por su cuenta, 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: 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 crecido bastante desde las primeras versiones.
Esto convierte a 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 en Markdown que sirven de entrada para la siguiente, aportando contexto estructurado en vez de depender solo 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 concretas. 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 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 de programación 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 lo que está intentando construir. La conversación se ha desplazado hacia el context engineering: darle 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, pero 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 con IA.
Hace algo quizá más interesante: formaliza una de las lecciones que están aprendiendo quienes trabajan a diario con agentes de programación. Dar más autonomÃa a la IA no significa necesariamente darle menos instrucciones, sino justo 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, y la intención pasa a ocupar ese lugar. GitHub lo expresa de 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 ser 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 el agente usa después 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 aportar 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.
Fuentes: