Qué es GitHub Spec Kit: usar el desarrollo guiado por especificaciones para encauzar la programación con IA

Un análisis de Spec Kit, el proyecto open source de GitHub: cómo usa especificaciones, planes, tareas e implementación para llevar la programación con IA desde el vibe coding improvisado hacia un flujo de ingeniería auditable, trazable y reutilizable.

Spec Kit de GitHub es un nuevo conjunto de herramientas para programación con IA. Su objetivo es ayudar a los desarrolladores a practicar Spec-Driven Development, es decir, desarrollo guiado por especificaciones.

El problema que aborda es muy directo: muchos flujos actuales de programación con IA se parecen demasiado a “chatear mientras se escribe código”. Una persona da una idea aproximada y el Agent empieza de inmediato a modificar el código. A corto plazo parece rápido, pero los límites de los requisitos, los criterios de aceptación, las decisiones técnicas y la división de tareas a menudo no quedan asentados. En cuanto el proyecto se vuelve un poco complejo, es fácil que termine convertido en vibe coding de una sola vez.

La idea de Spec Kit es la contraria: primero escribir claramente la especificación y luego pasar a la planificación, las tareas y la implementación. El código ya no es el primer paso. La especificación lo es.

Qué es Spec Kit

Spec Kit es el conjunto de herramientas open source de GitHub para desarrollo guiado por especificaciones. Proporciona la CLI specify, plantillas, scripts y comandos orientados a AI coding agents, para que los equipos puedan avanzar alrededor de un mismo conjunto de artefactos estructurados.

Lo que enfatiza no es “hacer que la IA pregunte menos”, sino hacer que la IA genere y refine estos elementos antes de escribir código:

  • Principios del proyecto: restricciones del equipo sobre calidad, pruebas, experiencia, rendimiento y aspectos similares;
  • Especificaciones funcionales: qué se va a construir, por qué se construye, historias de usuario y requisitos funcionales;
  • Plan técnico: qué stack tecnológico se usará, cómo se aterrizará y qué decisiones de arquitectura están involucradas;
  • Lista de tareas: dividir el plan en pasos ejecutables;
  • Proceso de implementación: modificar el código paso a paso según las tareas, en lugar de hacer una tanda caótica de cambios.

Este flujo hace que la programación con IA se parezca más a una colaboración de ingeniería y menos a una demostración basada en un único prompt.

Flujo básico de uso

El README oficial describe un flujo inicial parecido a este:

1
2
3
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init my-project --integration copilot
cd my-project

Después de la inicialización, el proyecto genera un directorio .specify, plantillas, scripts y comandos para la integración con el Agent. Luego se usan comandos /speckit.* dentro de un AI coding agent compatible para impulsar el desarrollo.

Una secuencia típica es:

1
2
3
4
5
6
/speckit.constitution
/speckit.specify
/speckit.clarify
/speckit.plan
/speckit.tasks
/speckit.implement

Aquí, /speckit.constitution establece los principios del proyecto, /speckit.specify describe los requisitos del producto, /speckit.clarify completa los puntos ambiguos, /speckit.plan genera el plan técnico, /speckit.tasks divide el trabajo en tareas y, al final, /speckit.implement ejecuta la implementación.

Esto es muy distinto de decirle directamente a un Agent: “ayúdame a construir una aplicación”. Spec Kit exige aclarar primero qué se va a construir y cómo se aceptará, y solo después dejar que el Agent empiece a trabajar.

Cambia el punto de entrada de la programación con IA

La programación tradicional con IA suele empezar desde el código:

1
Quiero crear una aplicación de gestión de tareas. Ayúdame a escribirla.

Spec Kit se parece más a esto:

1
2
3
4
Primero define los usuarios, escenarios, límites funcionales, criterios de aceptación y no objetivos de esta aplicación de gestión de tareas;
luego elige la solución técnica según esas especificaciones;
después divídelo en tareas;
finalmente impleméntalo paso a paso.

Este cambio es importante. La IA es muy buena ejecutando a partir de contexto, pero si el contexto en sí es disperso, cuanto más rápida sea la ejecución, más rápido puede desviarse la dirección. Spec Kit convierte el contexto en archivos y plantillas, de modo que los requisitos, planes y tareas puedan revisarse, modificarse y versionarse.

Dicho de otra forma, no hace que la IA sea más “libre”; le da una vía de ingeniería más clara para que pueda desplegarse con libertad.

Cómo entender los comandos principales

/speckit.constitution

Esta es la “constitución” del proyecto. Genera o actualiza .specify/memory/constitution.md, que registra los principios a largo plazo del proyecto, por ejemplo calidad del código, estándares de pruebas, consistencia de experiencia de usuario, requisitos de rendimiento y reglas para decisiones técnicas.

Este paso es adecuado para escribir consensos del equipo, no requisitos de una única función.

/speckit.specify

Esta es la fase de especificación funcional. Hay que describir qué se quiere construir, quiénes son los usuarios, qué problema se resuelve y cuáles son los flujos principales.

La guía oficial enfatiza especialmente que en esta fase no se debe prestar atención demasiado pronto al stack tecnológico. Primero hay que aclarar el what y el why, y luego discutir el how.

/speckit.clarify

Esta es la fase para completar preguntas. Muchos requisitos tienen huecos cuando se escriben por primera vez: cómo se gestionan los permisos, cuáles son los estados de error, si los datos deben persistirse, cómo se aceptan las condiciones límite.

El valor de /speckit.clarify está en permitir que el Agent detecte activamente los puntos inciertos de la especificación y registre las respuestas de vuelta en el documento, reduciendo retrabajo más adelante.

/speckit.plan

Esta es la fase de planificación técnica. Solo aquí se empieza a definir el framework, la base de datos, la arquitectura, las APIs, la estrategia de pruebas y las restricciones.

Si /speckit.specify es lenguaje de producto, /speckit.plan es lenguaje de ingeniería.

/speckit.tasks

Este paso divide el plan en tareas ejecutables. Una buena lista de tareas debería permitir que el Agent avance paso a paso, y también permitir que las personas entiendan el propósito de cada paso.

/speckit.implement

Solo al final se entra en la implementación. El Agent modifica el código según las especificaciones, planes y tareas asentados previamente. En ese momento ya no está adivinando requisitos a partir de un gran prompt, sino ejecutando dentro de un conjunto de documentos estructurados.

Por qué encaja con la programación con IA

El valor de Spec Kit no está en un comando mágico concreto, sino en recuperar lo que más fácilmente se pierde en la programación con IA:

  • Los requisitos se pueden revisar;
  • Los planes se pueden discutir;
  • Las tareas se pueden rastrear;
  • Las decisiones tienen contexto;
  • Los artefactos pueden entrar en el historial de Git;
  • Los equipos pueden reutilizar plantillas y principios;
  • La implementación del Agent ya no depende solo de un registro de chat de una sola vez.

Esto es especialmente útil para proyectos complejos. Cuanto más involucre un proyecto colaboración entre varias personas, mantenimiento a largo plazo y requisitos de calidad altos, menos puede depender solo de prompts temporales para impulsar el desarrollo.

Extensions y Presets

Spec Kit también ofrece dos tipos de personalización:

  • Extensions: añadir nuevos comandos, nuevas plantillas o integraciones con herramientas externas;
  • Presets: cambiar el formato y la terminología de las plantillas existentes de especificación, plan y tareas.

En términos simples: si quieres añadir una capacidad nueva, usa Extension; si quieres transformar el estilo del flujo de trabajo, usa Preset.

Por ejemplo, un equipo puede usar un Preset para exigir revisión de seguridad, trazabilidad regulatoria, terminología de dominio o reglas de pruebas primero. También puede usar una Extension para añadir integración con Jira, revisión de código, comprobaciones de salud del proyecto y otras fases nuevas.

Esto muestra que Spec Kit no intenta encerrar a todos los equipos en el mismo flujo. Proporciona un esqueleto extensible para desarrollo guiado por especificaciones.

Para quién es adecuado

Spec Kit encaja en escenarios como estos:

  • Usar un AI coding agent para crear el prototipo de un proyecto nuevo;
  • Convertir vibe coding en un flujo que se pueda revisar posteriormente;
  • Unificar el formato de requisitos y planificación antes de que el equipo deje que la IA genere código;
  • Proyectos que necesitan criterios de aceptación y requisitos de pruebas claros;
  • Incorporar requisitos, planes, tareas y proceso de implementación al control de versiones;
  • Equipos que están explorando usos colectivos de GitHub Copilot, Claude Code, Codex CLI y herramientas similares.

No necesariamente encaja con scripts muy pequeños de una sola vez. Para problemas que se resuelven con unas pocas líneas de código, el flujo completo de especificación puede sentirse pesado. Pero en cuanto una tarea empieza a involucrar varias páginas, varios módulos, gestión de estado, permisos, modelos de datos o mantenimiento a largo plazo, el beneficio estructural de Spec Kit se vuelve evidente.

Mi lectura

Spec Kit representa un giro importante en las herramientas de programación con IA: pasar de “hacer que el Agent escriba código más rápido” a “hacer que el Agent participe de forma más fiable en la ingeniería de software”.

La programación con IA del pasado se centraba en prompts y capacidad del modelo. Spec Kit presta más atención al proceso, los artefactos y las restricciones. Nos recuerda que cuanto más rápido escribe código la IA, menos podemos permitirnos omitir especificaciones, planes y aceptación.

Si ya estás acostumbrado a dejar que la IA implemente funciones directamente, puedes probar a cambiar el movimiento inicial con Spec Kit:

Primero deja que la IA te ayude a escribir los requisitos como una especificación; después deja que escriba el código.

Ese paso puede parecer más lento, pero en la práctica reduce el retrabajo posterior de “el código está terminado, pero no es lo que quería”.

Referencias

记录并分享
Creado con Hugo
Tema Stack diseñado por Jimmy