Vibe coding vs SDD: la velocidad sin rumbo sale cara

Vibe coding vs SDD: no es una guerra, son dos momentos

Yo hago vibe coding. Para probar una idea un domingo por la tarde no hay nada más divertido: le cuentas al agente lo que quieres, iteras sobre la marcha y en una hora tienes algo funcionando. El problema llega cuando ese “algo” quiere ir a producción. Por eso, cuando me preguntan por vibe coding vs SDD, mi respuesta es que no compiten: el vibe coding sirve para explorar y Spec-Driven Development, para construir lo que se va a quedar.

Esta semana he leído dos cosas que lo explican mejor que yo.

Lo que aprendió Microsoft por las malas

El equipo de IT interno de Microsoft ha contado cómo pasó del uso improvisado de agentes a SDD. Empezaron como casi todos: cada ingeniero aprendiendo las herramientas por su cuenta. Funcionó a medias. Uno de sus responsables lo resume así: mejorar la productividad de cada desarrollador no se traducía en un equipo más productivo.

La frase que más me gusta es de uno de sus ingenieros: “la velocidad sin dirección es solo caos caro, y lo aprendimos por las malas con el vibe coding”. Él habla de velocidad y de vector: no basta con ir rápido, hay que ir hacia el sitio correcto.

Cómo lo trabajan ahora

• Antes de las specs, el equipo acuerda una “constitución”: principios de arquitectura, seguridad y límites que respetan tanto las personas como los agentes.
• La spec es la fuente de verdad, vive en el mismo repositorio que el código y se actualiza con el proyecto.
• Usan GitHub Spec Kit con seis fases: definir el problema, aclarar ambigüedades, plan técnico, tareas trazables, validar que el plan cuadra con los requisitos e implementar.
• Specs pequeñas y acotadas, porque generan resultados más fáciles de revisar.

Nada de esto es magia. Es mover el pensamiento al principio, donde todavía es barato cambiar de idea.

Lo que el agente no sabe porque nadie se lo dijo

La segunda lectura es un paper reciente, FDE-Gym. Han convertido 20 proyectos reales de entrega a cliente, de 18 sectores, en 95 tareas. El agente trabaja como un ingeniero desplazado en casa del cliente: tiene un sistema en producción, documentos y personas simuladas a las que puede preguntar. Y lo puntúan por cuánto mejora la métrica de negocio del cliente, no por si el código compila.

Los resultados dan que pensar. Probaron 13 configuraciones de 7 proveedores. La mejor saca una nota media de 0,56 y solo resuelve 14 de las 95 tareas. Cuando le das al agente las reglas y restricciones del problema, los mejores modelos sacan entre 0,73 y 0,82. Cuando tiene que descubrirlas él, caen a entre 0,39 y 0,62. Los autores lo dicen claro: el principal cuello de botella es descubrir las restricciones que nadie ha dicho.

Hay otro detalle que me encanta. Por diseño, hacer al pie de la letra lo que pide el cliente, sin investigar más, puntúa como mucho 0,2. Igual que en la vida real.

Por qué esto es un argumento a favor de la spec

Si lo juntas todo, la conclusión es bastante clara. El agente escribe código muy bien cuando sabe qué tiene que construir y con qué límites. Donde falla es en lo que no está escrito. Ojo, que no es lo único: incluso cuando el agente consigue todos los datos, muchas veces no acierta con la solución. La spec es necesaria, pero no suficiente. Y sacar a la luz las restricciones, los casos límite y lo que de verdad necesita el negocio antes de que el agente empiece es justo lo que hace una buena spec.

Con vibe coding, todo eso vive en tu cabeza y en un chat que se pierde. Con SDD, queda escrito, revisado y versionado, y el agente trabaja sobre algo que alguien ha pensado. También cambia cómo revisas: con una spec puedes comprobar si el cambio hace lo que se pidió, no solo leer líneas. Lo contaba en mi post sobre revisión de código con agentes en Claude Code y en el de por qué las empresas necesitan SDD para adoptar agentes.

Mi regla práctica

• Vibe coding para explorar, prototipar y tirar a la basura sin pena.
• SDD en cuanto algo va a tocar usuarios reales, datos de clientes o código que otra persona tendrá que mantener.
• Y el paso de uno a otro, consciente: el prototipo te enseña qué preguntar, y la spec lo convierte en algo serio.

Lo que me llevo

El modelo importa, pero cada vez me convenzo más de que lo que separa un proyecto que sale bien de uno que no es la calidad de lo que le cuentas al agente. Esta semana estamos en la TRG26, en Madrid, y el jueves damos un taller de SDD justo sobre esto. Y si tu equipo quiere dar el salto del vibe coding a algo que aguante en producción, en onext ayudamos a montarlo.