//Del vibe coding al spec driven development
En un año hemos pasado del frescor del vibe a la solemnidad de la spec
Ambas metodologías, Vibe Coding y Spec Driven Development, priorizan la función sobre la implementación, pero con enfoques distintos. La diferencia está en la complejidad y perdurabilidad del desarrollo.|En la prehistoria del desarrollo con IA, allá por el año 2024, descubrimos que había algo más que un auto-completado inteligente. De repente, Cursor y Windsurf (buen nombre, pero escaso recorrido) nos mostraron que podíamos chatear con nuestro código.
No dentro del fichero de código, sino como un compañero que podía ayudarnos desde la ventana de al lado. Y otras herramientas, como Bolt y Lovable, iban un paso más allá, y el chat era anterior al propio código. Era lo más importante.
El Vibe Coding
Había nacido el Vibe Coding, solo que aún no lo sabíamos. Tuvo que ser Karpathy, uno de los gurús de la IA, quien lo nombrara así, haciendo referencia a sus propias sensaciones, a sus vibras, mientras exploraba esta tecnología.
En esencia, era una manera de desarrollar sin preocuparse por la implementación, sino por el resultado final. Si no es lo deseado, se pide el cambio y, así, iteración a iteración, se llega a construir un producto funcional: el santo grial del movimiento no-code y de su democratización del desarrollo de software.
Pero también resulta muy útil en fases tempranas de un desarrollo. Permite crear MVPs rápidos y con un feedback constante. O usarlo como una prueba de concepto previa a una decisión tecnológica importante. También es válido para crear el scaffolding inicial de una aplicación y, en general, para crear soluciones sencillas en las que se asume la responsabilidad de no escalarlas, o de hacerlo más adelante de forma más profesional.
De Beach a Bach
Ya, parece un contraste absurdo, pero este símil me resulta muy apropiado desde un punto de vista sonoro. Los Beach Boys popularizaron la música festiva de rock en los años 60, mientras que Bach es considerado el maestro de la música clásica del siglo XVII. Ni por asomo los puedo comparar en cuanto a calidad artística (aunque, justamente, el tema Good Vibrations, que me recuerda a este movimiento, es genialmente ecléctico e innovador, un poco como esta tendencia).
Sin pisar demasiados callos —porque en esto de los gustos musicales todos tenemos nuestros sentimientos— convendremos en que las obras con ánimo de perdurabilidad necesitan, entre otras cosas, una composición cuidada y plasmada en partituras para múltiples instrumentos, que garanticen una interpretación coherente con la idea del autor.
No es lo mismo plantearse un tema de tres minutos sobre un amor de verano, para cuatro instrumentos, en una tonalidad y compás de 4/4, que… los Conciertos de Brandeburgo.
Ahí termina el símil musical, pero no el argumento. Los grandes (y longevos) desarrollos de software, como los que afectan a corporaciones, bancos y administraciones públicas, requieren una planificación y una documentación funcional —evolutiva, eso sí— que los hagan predecibles, escalables y fieles a las múltiples necesidades de los usuarios finales.
El Spec Driven Development
Y aquí es donde entra el Spec Driven Development, un enfoque que se centra en la creación de un documento de especificación que define el comportamiento deseado de un sistema. No es tan distinto del Vibe Coding, en cuanto a que prioriza la función sobre la implementación, pero con una diferencia fundamental: los deseos son órdenes escritas en ficheros, no conversaciones desperdigadas en un chat.
Estos documentos de especificación pueden ser tan atómicos y detallados, o tan vastos y genéricos, como el sistema y la cultura de la empresa lo requieran. Desde una tarea hasta un microservicio, en diez o en mil líneas. De verdad, hay diversidad suficiente para representar todos los tamaños.
Lo trascendente es que ese documento sea accesible (idealmente como un fichero parejo al código, en el mismo repositorio) y que pueda ser leído tanto por humanos como por máquinas. De esta forma, trataremos los specs as code.
¿Y el código, pa’ cuándo?
Una característica de ambas aproximaciones es que el código es algo que se puede generar y que, hasta cierto punto, tiene un valor menor. Dependerá del entrenamiento previo del modelo, de las capacidades del agente y también de las reglas e instrucciones que se le proporcionen. Pero la tendencia es clara: paradójicamente, ahora que la programación está en manos de máquinas, el desarrollo de software se vuelve más humano y programamos en lenguaje natural.
En el futuro seguiremos viendo cómo la IA nos ayuda a programar, cada vez más y mejor. Aparecerán nuevos paradigmas y alguien les dará nombres creativos y pegadizos. Pero lo importante es que sigamos entendiendo que nuestro valor está en comprender el problema de alguien y resolverlo usando ordenadores.