Hay programas que hoy nacen sin que nadie realmente escriba una línea a mano. Alguien describe lo que quiere, acepta cada sugerencia del asistente y devuelve los errores al chat hasta que la aplicación funciona. Esa práctica tiene nombre desde que Andrej Karpathy, cofundador de OpenAI y exdirector de IA de Tesla, la bautizó como «vibe coding» en un mensaje publicado en X, el 2 de febrero de 2025, donde confesaba olvidar que el código existía, según recogió MIT Technology Review. La ocurrencia caló tan hondo que el Collins Dictionary, la eligió palabra del año 2025, como informó la BBC.
Diecinueve meses después de aquel mensaje, la industria respondió con un método que invierte el orden. GitHub presentó el 2 de septiembre de 2025, su toolkit open source, Spec Kit, que coloca la especificación en el centro y deja que el agente genere la implementación y las tareas a partir de ella, como explicó en su blog oficial. El repositorio superó las 100.000 estrellas en septiembre de 2026, una acogida que revela el hambre de orden que había.
El giro tiene motivos medidos. Veracode analizó más de 100 modelos en 80 tareas y encontró fallos del OWASP Top 10 en el 45% del código generado, con Java por encima del 70%, según su informe de julio de 2025. Y un ensayo de METR con 16 desarrolladores expertos en 246 tareas reales mostró que usar IA alargaba el trabajo un 19% en código complejo, aunque los participantes creían haber ido un 24% más rápido, según METR.
El mensaje es claro: programar por «sensaciones» sirve para prototipos, pero el software que debe durar pide escribir primero qué se quiere y dejar que el código obedezca. Pero sobre todo, pide que se revise, se pruebe, y se vuelva probar, como siempre ha sido.
Spec-Driven Development: haciendo del «vibe coding» algo serio
Piensa en pedir una tarta por intuición frente a encargarla con receta. Con el vibe coding dices hazme una tienda online bonita y aceptas lo que salga. Con el Spec-Driven Development escribes ingredientes, pasos y punto de cocción. Una buena especificación detalla sus piezas.
- Qué se construye y qué problema resuelve, contado desde el usuario.
- Recorridos principales y resultados que importan.
- Criterios de aceptación que marcan el aprobado de cada función.
GitHub resume el giro con una imagen directa en su guía de Spec Kit. Durante décadas el código fue el rey y las especificaciones eran andamios que se tiraban al empezar la obra, mientras que ahora se vuelven ejecutables y generan implementaciones que las obedecen, como detalla la documentación de Spec Kit. El código deja de mandar y pasa a servir a la especificación.
Quien definía un esquema OpenAPI antes de programar la API practicaba esta disciplina sin saberlo. La novedad es que el agente convierte requisitos en planes y planes en código, mientras la persona dirige, revisa y decide, con principios fijados en un fichero de constitución.
Te puede interesar: Vitalik Buterin explica por qué Ethereum será mucho más que una blockchain
¿Cómo se trabaja con especificaciones y agentes de IA?
El flujo habitual encadena un recorrido que produce documentos en texto plano versionados con Git, donde cada fase alimenta la siguiente y nada se decide dos veces en hilos de chat perdidos.
- Define el qué y el porqué con historias de usuario.
- Acuerda el cómo con pila, arquitectura y restricciones.
- Trocea el plan en tareas pequeñas y comprobables.
- Con el plan cerrado, implementa tarea a tarea con revisión acotada.
Los comandos dirigen al agente sin teclear rituales. Cada orden genera ficheros Markdown del proyecto que alimentan la fase siguiente, con contexto estructurado en vez de promesas sueltas perdidas en el historial del chat.
Spec Kit aporta órdenes como /specify para la especificación, /plan para el diseño y /tasks para la lista de trabajo, además de /implement y /converge en su versión 1.0, según explica Microsoft para desarrolladores. Si algo cambia, se edita la especificación y se regenera desde allí, nunca se parchea el código generado a espaldas del documento.
La variante de Amazon sigue la misma lógica con su propio vocabulario. Kiro, por ejemplo, pide requisitos con criterios de aceptación en formato EARS, del tipo cuando ocurre X, el sistema deberá hacer Y, y a partir de ahí produce diseño, propiedades de corrección y tareas, como contó su ingeniero principal en AI Engineer. Kiro suma documentos de dirección, ganchos automáticos y conexión MCP para traer documentación externa. La idea de fondo coincide en ambas herramientas, porque el desarrollador dirige la orquesta y el agente toca los instrumentos, pero la partitura manda.
¿Por qué funciona cuando el vibe coding se rompe?
La clave está en la memoria que cada método ofrece al modelo. Un modelo de lenguaje optimiza la continuación más plausible del texto inmediato, no la fidelidad a una intención expresada hace veinte mensajes. Sin especificación, cada indicación negocia de nuevo lo ya decidido y el diseño se desplaza hacia un programa distinto del pedido. Con especificación, la intención queda fijada en un documento persistente que el agente consulta en cada paso, y lo generado se comprueba contra ese texto.
Ese anclaje cambia además el objeto de la revisión. Leer un volcado de tres mil líneas que nadie ha visto supera la atención de cualquier persona, mientras que leer una especificación de dos páginas con criterios claros entra en una sentada. En vez de revisar montañas de código de una vez, el desarrollador válida cambios enfocados que resuelven piezas concretas, porque la especificación ya dijo qué toca construir y la tarea ya dijo en qué orden, como describe el anuncio de Spec Kit. Revisar intenciones sale más barato que revisar diferencias, y corregir una frase cuesta menos que reescribir un módulo.
Ensayos concretos
| Dimensión | Vibe coding | Spec-Driven Development |
|---|---|---|
| Velocidad del primer prototipo | Minutos u horas desde una frase | Horas o días con especificación previa |
| Calidad del código | Impredecible y desigual entre sesiones | Acotada por contratos y verificable |
| Seguridad | Fallos del OWASP Top 10 en el 45% según Veracode | Pruebas y contratos derivados de la especificación |
| Mantenimiento | Código opaco que nadie recuerda haber diseñado | La especificación sirve de documentación viva |
| Trabajo en equipo | Individual, cada persona negocia con su chat | Tareas paralelas sobre un contexto compartido |
| Contexto para la IA | Efímero, se pierde entre mensajes | Persistente, versionado y auditable |
Hay un tercer efecto menos visible y quizá el más decisivo para equipos grandes. Cuando los requisitos usan formatos estructurados como EARS, dejan de ser prosa decorativa y se convierten en materia computable. Kiro los analiza para cazar ambigüedades y choques entre requisitos, y desde su versión general genera propiedades de corrección que alimentan pruebas capaces de ensayar cientos de valores donde una prueba clásica solo toca unos pocos, como mostró la sesión técnica de re:Invent 2025. Con contratos precisos, el margen del modelo para inventar decisiones ya tomadas desaparece.
Conviene matizar que estas cifras describen ensayos concretos, no sentencias universales. El 45% sale de tareas diseñadas para tentar al modelo y el 19% mide a expertos en repositorios enormes, pero ambas apuntan en la misma dirección.
Te puede interesar: AI Act, cómo afecta la inteligencia artificial a las startups de Europa
¿Qué gana un desarrollador que ya usa IA cada día?
Quien programa a diario con Copilot, Cursor o Claude Code notará el cambio donde más duele, en el retrabajo. Las primeras sesiones con especificación se sienten más lentas porque obligan a pensar media hora antes de generar nada, y Thoughtworks lo dijo sin rodeos en su Radar de noviembre de 2025, al colocar el método en su anillo de evaluar con advertencias sobre su complejidad, como publicó Thoughtworks. Pero esa media hora se recupera cuando el agente deja de proponer la librería equivocada y cuando un compañero entiende en una tarde lo que antes exigía una semana de lecturas.
El ahorro aparece también en la colaboración entre personas. Con una especificación compartida, dos desarrolladores pueden pedir a dos agentes distintos piezas compatibles del mismo sistema, porque ambos beben del mismo contrato de datos y de las mismas reglas de error y registro. Sin ella, cada persona negocia por su cuenta con su asistente y el repositorio acaba con varias formas de autenticar y varias definiciones de listo. David Yanacek, ingeniero principal de IA agéntica en AWS, lo expresó con claridad en declaraciones recogidas por InfoWorld. Dedicar tiempo a describir qué se construye y qué significa bien hecho permite volver atrás y comprobar que el agente hizo lo pedido.
Muchos equipos aplican además un modelo híbrido sin darle nombre, donde la exploración y la entrega siguen reglas distintas. Ayaz Ahmed Khan, director de ingeniería en Cloudways, lo resumió en la misma pieza de InfoWorld. Usa el vibe coding para explorar y prototipar, y el desarrollo guiado por especificaciones con IA para endurecer y publicar.
Revisar y probar sigue siendo obligatorio
La pregunta que más se repite en espacios como X tiene respuesta afirmativa. Sí, hay que revisar y probar todo lo que genera con IA, incluso usando SDD. La especificación no es un hechizo que vuelve correcto al modelo, sino un contrato que permite pillar sus errores. El humano válida especificación, plan y tareas antes de dejar que el agente ejecute en modo supervisado.
El matiz importante es que las pruebas nacen de la especificación y no del código. Un agente de pruebas deriva casos desde los criterios de aceptación, de modo que una prueba que pasa sin cubrir ninguna cláusula del contrato revela un hueco en la red y no un aprobado.
A eso se suman las prácticas clásicas que la IA no jubila, como el análisis estático en el flujo, la revisión de dependencias y versiones elegidas por el agente, y la atención a la inyección de logs y al scripting entre sitios, donde Veracode midió fallos superiores al 85%. Simon Willison trazó la frontera con una frase que conviene enmarcar. Si un modelo escribió cada línea, pero las revisaste, las probaste y las entendiste, eso es usar el modelo como asistente de escritura, y solo cuando aceptas sin comprender programas por sensaciones, como recogió Ars Technica.
La especificación también puede fallar si fosiliza suposiciones equivocadas. Por eso el proceso exige siempre documentos vivos que evolucionan con lo aprendido y comprobaciones frecuentes en equipo, no contratos tallados en piedra.
Una práctica en expansión
El ecosistema creció a una velocidad poco común para una práctica con nombre tan joven. Spec Kit salió como experimento open source con licencia MIT y en septiembre de 2026 acumulaba más de 100.000 estrellas, con más de 200 contribuidores, una treintena de integraciones y más de un centenar de extensiones comunitarias, según su documentación. La propia herramienta se desarrolla comiéndose su propia comida, con cambios relevantes probados a través de sus comandos de especificación, lo que en jerga se conoce como dogfooding y aquí funciona como control de calidad público.
Kiro representa la apuesta integrada. Nació en un equipo pequeño de Amazon con dirección propia de producto, y su flujo de requisitos, diseño y tareas viene de serie en el IDE en lugar de añadirse como plantilla externa. Sus bazas son los documentos de dirección, los ganchos que automatizan rutinas y la integración con el Model Context Protocol, como demostró el taller de re:Invent 2025. Sus casos internos hablan de funciones enviadas en días, cifras de la propia casa que cada equipo deberá contrastar.
Alrededor de esos dos polos orbita una constelación con matices propios. Tessl defiende la postura más radical, con la especificación como artefacto que se mantiene en lugar del código, aunque en septiembre de 2025 seguía en beta privada, según el Radar de Thoughtworks. Como regla práctica, cuantos más niveles toca un cambio, más especificación merece.
Especificar primero y dejar que el código obedezca
El debate ya no enfrenta a entusiastas contra escépticos de la IA, en este tramo final de septiembre de 2026, sino a dos formas de usarla con distinta ambición. El vibe coding conserva su territorio en la exploración, los prototipos de fin de semana y las pruebas de concepto que nadie mantendrá, donde su velocidad resulta imbatible. Todo lo que deba sobrevivir al tercer mes, pasar una auditoría o custodiar datos sensibles pide el camino disciplinado, con contratos escritos y pruebas que nacen del documento.
Quien empiece hoy tiene un itinerario sencillo de probar. Elegir una función pequeña, pero real de varias capas, escribir su especificación con criterios comprobables, planificar con restricciones explícitas y dejar que el agente ejecute por tareas revisables una a una, midiendo tiempo, defectos y esfuerzo de revisión frente al método anterior. Si la función sobrevive al trimestre sin convertirse en deuda, la receta funcionó y merece repetirse a mayor escala.