Hay un patrón que casi todo el que construye con IA repite: al principio le hablas, aparece código, funciona, es magia. Pero cerca de la quinta o sexta función la magia se rompe — le pides un cambio pequeño y se cae otra cosa, le explicas por tercera vez cómo va el login "porque se le olvidó", y abres el proyecto al día siguiente sin recordar por qué existe la mitad de los archivos. El problema de fondo no es que la IA sea tonta: es que no tiene memoria de intención y adivina distinto cada vez que rellena un hueco. El Spec-Driven Development invierte el orden del vibe coding: antes de que la IA escriba una línea, escribes la spec —qué debe hacer la app, en tus palabras— y ese documento se vuelve la única fuente de verdad desde la que el agente genera plan → tareas → código, con checkpoints tuyos en medio. En esta guía verás la herramienta que lo instala como comandos dentro de tu propio agente (GitHub Spec Kit, gratis y open source), el flujo real de 4 fases, los comandos exactos, y un solo prompt maestro para arrancar cualquier proyecto spec-first sin volverte programador.
Al principio el vibe coding es mágico. Le hablas a la IA, aparece una pantalla, funciona, aplaudes. Pero llega un punto —casi siempre alrededor de la quinta o sexta función— en que la magia se rompe. Le pides un cambio pequeño y se cae otra cosa que no tocaste. Le explicas por tercera vez cómo debe funcionar el login "porque se le olvidó". Abres el proyecto al día siguiente y ni tú sabes por qué existe la mitad de los archivos. Ese es el momento: cuando la conversación deja de ser suficiente como fuente de verdad, y necesitas algo más sólido que un chat con memoria de pez.
El Spec-Driven Development (desarrollo dirigido por especificación, o SDD) nace exactamente ahí. La idea es tan simple que casi ofende: antes de que la IA escriba una línea de código, escribes lo que la app debe hacer — clara, ordenada y guardada en un archivo. Ese documento, la spec, se convierte en la única fuente de verdad. Y el agente genera, a partir de ella, un plan → una lista de tareas → el código. En ese orden. Con puntos de control tuyos en medio.
El problema no es que la IA sea tonta. Es que la IA no tiene memoria de intención. En cada mensaje toma la mejor decisión para ese mensaje, sin una imagen completa de qué estás construyendo ni por qué. Tú tienes esa imagen en la cabeza — pero la cabeza no es un documento que el agente pueda leer. Así que la IA rellena los huecos adivinando, y adivina distinto cada vez. Una vez el carrito guarda impuestos, otra vez no. Una vez el usuario puede editar su perfil, otra la función desaparece en un refactor. Nadie mintió: simplemente nunca existió un contrato que dijera qué es correcto.
¿Qué pasa si no arreglas esto? No es el apocalipsis — es un accidente lento. Terminas con una app que casi funciona, imposible de explicarle a otra persona (o a la IA de la semana que viene), donde cada arreglo tiene su propia probabilidad de romper algo más. Y esas probabilidades no perdonan: en un blog de esta misma serie contamos la matemática del 27% — un agente que acierta el 85% en cada paso solo completa un flujo de ocho pasos el 27% de las veces (0,85⁸), porque los aciertos se multiplican, no se suman. Construir a ciegas encadena pasos frágiles exactamente igual. La spec es lo que rompe esa cadena de fragilidad: le da a la IA un punto fijo contra el cual verificar cada paso, en vez de dejar que cada uno dependa de la buena suerte del anterior.
En el vibe coding el flujo es: hablas → código → (a veces) documentas. En el SDD se invierte por completo: especificas → planeas → generas tareas → código. La documentación deja de ser el resto olvidado del final y se convierte en el punto de partida. Y no es burocracia: cada fase es un artefacto que el agente genera casi solo a partir del anterior, con un checkpoint tuyo para aprobar antes de seguir. Tú diriges; la IA ejecuta.
No tienes que inventar este flujo a mano. GitHub Spec Kit es un kit de herramientas open source —de GitHub, gratis, licencia MIT— que instala el SDD como una serie de comandos dentro de tu agente de IA. Tú escribes la spec en lenguaje natural; él te da la estructura, los checkpoints y los comandos para que la IA la convierta en app. Es de las herramientas de IA que más rápido creció: 122.000 estrellas en GitHub, y su última versión estable, la v0.13.0, salió el 2026 年 7 月 17 日. Integra 30+ agentes — Claude Code, GitHub Copilot, Cursor, Gemini CLI y el que uses.
El kit oficial de GitHub para Spec-Driven Development. Instala un flujo de comandos (constitution → specify → plan → tasks → implement) dentro de tu agente de IA, para que construyas desde una especificación ejecutable en vez de improvisar. Model-agnostic: funciona con 30+ agentes.
Spec Kit se instala con uv, el gestor de paquetes de Python moderno (rápido, sin dramas). Si no tienes uv, lo instalas primero — una línea. Luego instalas el CLI de Spec Kit de forma persistente, e inicializas tu proyecto eligiendo tu agente. No te asustes por la terminal: son literalmente estos comandos, en orden, y no vuelves a tocarla para el trabajo real (ese pasa dentro del chat de tu IA).
# 1) Si no tienes uv (el gestor de paquetes de Python), instálalo: curl -LsSf https://astral.sh/uv/install.sh | sh # 2) Instala el CLI de Spec Kit de forma persistente (fijando la versión estable): uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.13.0 # 3) Mira qué agentes puedes elegir (el valor exacto para el flag --integration): specify integration list # 4) Inicializa tu proyecto eligiendo tu agente (aquí, Copilot como ejemplo): specify init mi-proyecto --integration copilot # 5) Comprueba si hay una versión más nueva (no modifica nada, solo lee): specify self check
specify init mi-proyecto --integration copilot, el valor después de --integration es tu herramienta. Spec Kit trae 30+ integraciones y las va cambiando entre versiones, así que en vez de memorizar el nombre exacto, córrele antes specify integration list y elige de esa lista el que uses (Copilot, Cursor, Gemini, Claude Code, etc.) — es como pedir el menú antes de ordenar, así nunca pides un plato que no está. Ese comando init crea la carpeta con los comandos /speckit.* ya cableados dentro de tu agente; a partir de ahí, todo el trabajo ocurre hablándole a la IA, no en la terminal.Una vez inicializado, Spec Kit te da una serie de slash commands que escribes dentro de tu agente. No son mágicos: cada uno le pide a la IA que genere el siguiente artefacto del flujo. El orden importa — es una cascada donde cada paso se apoya en el anterior. Estos son los reales, tal cual vienen en la v0.13.0:
/speckit.implement es volver al vibe coding con pasos extra. La cascada funciona porque cada artefacto restringe al siguiente: la constitución acota el plan, el plan acota las tareas, las tareas acotan el código. Si rompes la cadena, la IA vuelve a adivinar. La disciplina está en respetar los checkpoints, no en tener los comandos.Puesto todo junto, así se ve un proyecto de principio a fin. Fíjate que en cada frontera tú revisas y apruebas antes de que la IA avance. Ese es el truco: no es que la IA trabaje sola sin freno, es que trabaja sola entre checkpoints que tú controlas.
/speckit.constitution y defines las reglas de oro del proyecto. Checkpoint: lees y confirmas que esos principios son los correctos. Se escribe una vez, gobierna siempre./speckit.specify y describes qué construir. Luego /speckit.clarify para que la IA cierre ambigüedades preguntándote. Checkpoint: la spec dice EXACTAMENTE lo que quieres, sin huecos./speckit.plan da el plan técnico; /speckit.tasks lo vuelve tareas; /speckit.analyze verifica que todo sea coherente. Checkpoint: apruebas el stack y las tareas antes de que se escriba código./speckit.implement construye. La IA ejecuta las tareas una a una contra la spec. Checkpoint: usas /speckit.checklist para validar que lo construido cumple los requisitos.El SDD no es para todo. Un cambio de una línea, un botón de color, un texto — a eso le hablas normal a la IA y ya. Escribir una spec para eso sería como pedir plano de arquitecto para colgar un cuadro. El hábito bueno es reconocer el umbral: en el momento en que una tarea toca más de un archivo, tiene reglas de negocio, o vas a volver a ella la semana que viene — ahí sí, spec primero. Y de ahí en adelante, cada función nueva grande nace de una spec, no de un impulso.
Aquí está el único prompt que necesitas memorizar. Es el que le das a tu IA (con Spec Kit ya inicializado) para arrancar bien desde el primer minuto: le pide que primero fije la constitución, luego construya la spec contigo preguntando lo que falte, y que no escriba código hasta que apruebes. Cópialo, rellena los [corchetes], y pégaselo a tu agente al empezar cualquier proyecto serio.
Vamos a construir este proyecto con Spec-Driven Development usando GitHub Spec Kit, que ya está inicializado. NO escribas código todavía. Sigue este flujo conmigo, deteniéndote en cada checkpoint para que yo apruebe antes de avanzar. Mi proyecto es: [describe qué quieres construir y para quién, en 3-5 frases]. Lo que NO debe hacer / mis límites: [ej. sin guardar tarjetas de crédito, funcionar en móvil, nada de datos sensibles en logs]. PASO 1 — CONSTITUCIÓN. Antes que nada, corre /speckit.constitution y propón los principios inviolables de este proyecto (seguridad, validación de entradas, consistencia, lo que aplique). Muéstramelos y espera mi visto bueno. PASO 2 — SPEC. Luego corre /speckit.specify y redacta la especificación a partir de mi descripción: requisitos claros e historias de usuario. Después corre /speckit.clarify y hazme TODAS las preguntas necesarias para eliminar ambigüedades — no adivines, pregúntame. No sigas hasta que yo diga que la spec está correcta. PASO 3 — PLAN Y TAREAS. Con la spec aprobada, corre /speckit.plan y propón el stack y la arquitectura (explícame en cristiano por qué elegiste cada cosa). Luego /speckit.tasks para el desglose, y /speckit.analyze para verificar que spec, plan y tareas no se contradigan. Muéstrame todo y espera mi aprobación. PASO 4 — IMPLEMENTAR. Solo cuando yo lo autorice, corre /speckit.implement y construye. Al terminar, genera un /speckit.checklist para validar que lo construido cumple la spec. Regla de oro durante todo el proceso: la spec es la única fuente de verdad. Si algo del código se aparta de la spec, la spec gana — o me avisas para actualizarla juntos. Nunca cambies el comportamiento en silencio.
/speckit.clarify existe justo para eso: sacar esas suposiciones a la luz antes de que se conviertan en código.Para que no te pierdas: casi todo ocurre hablándole a tu IA. La terminal la tocas una sola vez (instalar e inicializar). Los /speckit.* los escribes dentro del chat de tu agente, como cualquier otro mensaje. Y la spec la escribes en tus palabras — no en código. Este es el reparto:
uv, instalar specify-cli, ver los agentes con specify integration list, correr specify init mi-proyecto --integration <tu-agente>, y specify self check para comprobar que estás al día. Se acabó — no vuelves a la terminal./speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement. Los escribes como mensajes normales./speckit.clarify, y las aprobaciones en cada checkpoint. Cero código de tu parte.Si has seguido la biblioteca, esto no te suena nuevo — es el siguiente escalón. El protocolo C-A-R te enseñó a separar construir de auditar para no enviar bugs. El recurso de sistema de diseño te enseñó a fijar las reglas visuales antes de la primera pantalla. Ambos comparten una misma idea: decide el contrato antes de ejecutar. El SDD lleva esa idea a su forma más pura: la spec es el contrato, y es la única fuente de verdad para toda la app — diseño, lógica, comportamiento. Pasas de "organiza tu contexto" a "escribe el contrato y deja que la IA lo cumpla".
Únete a 4.200+ creadores. Sin tarjeta. Construye tu primera app con IA en minutos.