Llevo ya muchos meses trasteando con herramientas de IA que programan y con lo que se ha venido a llamar vibe coding. Y como suele pasar con todo lo nuevo que genera hype, hay mucho ruido, muchos hilos virales de «he construido una app en 20 minutos» y bastante menos reflexión sobre cómo hacerlo de una forma que tenga sentido a medio plazo.
Siempre me ha pasado mucho al analizar y evaluar soluciones de software que algunas son bastate buenas pero «le falta esto» o » si tuviera aquello» o «que pena que no tenga X función». Así que recientemente he estado usando el vibe coding para complementar o añadir funciones a software open source existente.
La idea más extendida del vibe coding es la de partir de cero: le describes a la IA lo que quieres, le vas haciendo peticiones por prompts y ella va construyendo el software desde la nada. Tanto la parte visual (front-end) como la lógica de detrás (back-end), conectándose a bases de datos y demás. Y está bien, funciona… aunque sin método puedes estar generando el conocido desde antaño como «código espaguetti» y acumulando deuda técnica.
Porque construir desde cero con IA tiene un problema de base: no hay convenciones previas, no hay estructura heredada, no hay consistencia más allá de lo que la propia IA decida hacer en cada momento a no ser que además de los requisitos o PRDs también le des una serie de normas, convenciones y buenas prácticas que quieres que use.
Pero hay otra forma de hacerlo que a mi me parece bastante interesante y de la que se apenas se habla. Se trata de usar vibe coding sobre software open source ya existente para ampliarlo o añadirle funciones que no tiene.
¿Por qué tiene sentido partir de un open source?
El beneficio principal es que ya partes de algo que funciona. No es un lienzo en blanco. Es un software que tiene unas buenas prácticas de programación consistentes, un diseño visual uniforme y una estructura probada por una comunidad. Y eso cambia bastante las cosas.
Cuando le pides a una IA que programe desde cero, le estás pidiendo que tome todas las decisiones. Cuando le pides que amplíe un software existente, le estás pidiendo que respete las decisiones que ya están tomadas y se adapte a ellas. Y eso suele dar mejores resultados.
Lo primero que hay que hacer es que tu IA analice y estudie el código del proyecto open source para:
- Coger el mismo stack del software ya existente. Lenguaje de programación, frameworks de back y front, librerías de componentes, sistema de base de datos.
- Respetar las convenciones del código y continuar la forma en la que está programado el proyecto original.
- Respetar el sistema visual y el diseño de las vistas (las pantallas), aunque tú quieras ampliarlo y añadir cosas que requieran nuevos diseños.
Es decir, en vez de darle carta blanca, le estás diciendo «mira cómo está hecho esto y hazlo igual». Y eso, para los que no venimos de la programación, es una gran ventaja.
El elefante en la habitación: las actualizaciones
Ahora bien, aquí viene la principal preocupación (y con razón) de este enfoque. Cuando el software open source se actualice y saque una nueva versión… ¿se van a romper tus modificaciones? ¿Vas a poder seguir creciendo con las versiones nuevas?
Esto no es algo específico del vibe coding, que conste. Pasa con cualquier desarrollo de software que crees, modifiques o extiendas. Y es realmente complicado porque no sabes qué cambios van a hacer los desarrolladores originales en el futuro.
Dicho esto, hay una convención bastante extendida que ayuda a orientarse. Es el versionado semántico, ese formato de tres cifras separadas por puntos (X.X.X) que veis en las versiones de casi cualquier software:
- Si cambia la segunda cifra (por ejemplo de 2.3.0 a 2.4.0), en principio es una versión compatible con la anterior. No debería romperse nada.
- Si cambia la primera cifra (por ejemplo de 2.4.0 a 3.0.0), eso indica una versión mayor que puede romper cosas de la versión anterior. Ante esto, lo habitual es que los desarrolladores del proyecto provean algún tipo de migrador o instrucciones para hacer la transición.
¿Y qué haces cuando llega una versión mayor?
En el escenario de que salga una versión mayor nueva que rompe compatibilidad, básicamente tienes dos caminos:
1. Mantener tu versión estática. No continuar con las actualizaciones, dejando tu versión terminada y sin actualizar salvo que se trate de parches de seguridad o vulnerabilidades graves. Esta situación es bastante parecida a cuando has creado todo el software con vibe coding desde cero y no tienes previsto actualizarlo en un plazo breve de tiempo. Funciona, es tuyo, y mientras no haya un problema de seguridad gordo… tira millas.
2. Reaplicar las modificaciones con ayuda de la IA. Si necesitas actualizar a la nueva versión y volver a integrar tus cambios, puedes usar la propia inteligencia artificial para hacer compatible la nueva versión con tus modificaciones. Para ello hay dos sub-caminos:
- Tener muy claras y documentadas todas las modificaciones realizadas para volver a aplicarlas de forma ordenada sobre la nueva versión. (Esto es buena práctica siempre, con o sin IA).
- Pedirle directamente a la IA que analice las diferencias y te ayude a integrar la nueva versión con tus cambios previos.
Concluyendo
Lo que me parece interesante de este enfoque es que aplica una lógica que en otros ámbitos siempre hemos tenido clara: no reinventes la rueda si ya hay una que funciona. Mejórala, adáptala, amplíala. Pero no empieces de cero por el simple hecho de que ahora puedes.
El vibe coding sobre open source no es magia y tiene sus riesgos (como todo), pero creo que es una forma sensata y sostenible de aprovechar estas herramientas que el «dame una app de la nada en 20 minutos» que vemos por todas partes. Aunque claro, eso no genera tantos likes.