Del vibe a la especificación
El 2 de septiembre de 2025 GitHub lanzó Spec Kit, de código abierto, y explicó por qué. El vibe coding puede ser excelente para prototipos rápidos, pero es mucho menos fiable en aplicaciones serias y en código que ya existe. Spec Kit trabaja en cuatro fases: especificar qué se construye y para qué, planear el enfoque técnico, dividirlo en tareas pequeñas y comprobables, y recién entonces implementar. En palabras de GitHub, la fuente de verdad deja de ser el código y pasa a ser la intención (GitHub). Kiro, de Amazon, y Tessl van por caminos parecidos.
Qué tiene que tener la especificación
En el libro lo muestro con un salón de uñas que empezó a aceptar varios teléfonos por clienta. La orden “agrega un segundo campo a la tabla y un botón al formulario” describía dos eslabones de siete, y los otros cinco se rompieron. La intención habría sonado distinta: la clienta puede dar varios números y marcar el principal; el recordatorio va al principal; las clientas antiguas conservan sus números después de la migración; la exportación del contador abre; todas las revisiones quedan en verde (capítulo “A Goal Instead of an Instruction”). La cadena se puede recorrer en el experimento “Siete eslabones detrás de un teléfono”.
Además del objetivo, una buena intención tiene límites: qué no se hace ni por la victoria y dónde el agente debe detenerse a informar (mismo capítulo). Los límites rinden más escritos como prohibiciones (capítulo “Architecture as a System of Prohibitions”). El lugar habitual es AGENTS.md, un archivo que el agente lee al inicio de cada sesión y que, según agents.md, usan más de 60.000 proyectos de código abierto (mismo capítulo).
Qué no resuelve una especificación
En octubre de 2025 Birgitta Böckeler, de Thoughtworks, probó Kiro, Spec Kit y Tessl y anotó dónde se traban. Kiro convirtió el arreglo de un bug pequeño en cuatro historias de usuario con 16 criterios de aceptación. Spec Kit generó una pila de markdown, y ella escribió que prefería revisar código antes que todos esos archivos. Y pese a las listas de verificación, el agente a veces se saltaba instrucciones y volvía a crear clases que el proyecto ya tenía (sitio de Martin Fowler).
Lo último no me sorprende. Una regla en un archivo de texto es un pedido, y en una sesión larga el agente puede olvidarla (capítulo “Architecture as a System of Prohibitions”). La especificación funciona cuando sus puntos se vuelven revisiones automáticas y cuando los tests los escribe o aprueba alguien distinto del agente que escribe el código (capítulo “The Agent Cheats the Test”). Y el plan hay que leerlo antes de empezar, mientras el agente todavía no borró nada (capítulo “A Goal Instead of an Instruction”). Plantear una tarea para que no se pueda entender de dos maneras es el primer módulo de mi curso de IA y vibe coding.
