Cada semana que pasa tenemos un nuevo término en el mundo de desarrollo con IA que entender e intentar aprender. Pero hay uno que ya lleva un tiempo dando vueltas: Vibe Coding. Por lo que voy viendo en el día a día (sostenido por una alta cantidad de memes al respecto), cada persona con la que hablo ve el vibe coding de una forma diferente. Para algunos es una gran oportunidad, para otros es el propio demonio. Aquí no vamos a hablar de si es «bueno» o es «malo», blanco o negro. Vamos a hablar de fronteras, qué líneas separan cuándo y cómo usar Vibe Coding, y qué problemas podemos encontrarnos.
¿Qué es el Vibe Coding?
¿De dónde viene todo esto del Vibe Coding? La definición original es de Karpathy, quien escribía «entregarme por completo a las vibras». No revisas el código, aceptar el output de la IA y, en caso de error, se lo vuelves a enviar a la IA que lo solucione (confiando en que se resuelve de la mejor manera).
Simon Willison hizo una distinción de este concepto: es una forma de desarrollo asistido por IA rápida (e irresponsable) donde un usuario lanza prompts a un modelo y acepta el código sin revisarlo en profundidad.
La frontera
¿Usar Vibe Coding entonces está mal? No todo es blanco y negro, vamos a movernos en una escala de grises, y hablemos de fronteras.
¿Cuál es la frontera para un correcto uso?
En un primer enfoque podríamos pensar que, según el tipo de rol, Vibe puede ser apto para perfiles más de producto o negocio (Product Owners, Product Managers) porque, como Karpathy explicitó, este tipo de proyectos realizados de esta forma son proyectos de fin de semana desechables. Es decir, apto para validar ideas, prototipos, realizar investigaciones.
Un ingeniero podría recurrir a Vibe coding para algún tipo de spike o investigación, pero raramente lo necesita porque ya sabe programar (en este caso el problema aparece si no revisase código que potencialmente puede llegar a estar en producción).
Entonces pensemos… ¿y si ese prototipo, que de repente capta mucho interés, hay usuarios dispuestos a pagar para usarlo YA? La tentación de subir el código a producción es muy alta y pocos Product Managers (¡o sus stakeholders!) van a frenarlo. Y ahí está la línea que no deberíamos pasar. Un proyecto «vibecodeado» no debería terminar nunca en producción. Mejor dicho: un código no revisado por un humano no debería acabar en producción.
El lado oscuro (Desventajas del Vibe Coding)
La teoría suena muy bien, pero ¿qué ocurre cuando es el propio ingeniero quien no revisa el código desarrollado por la IA? Esto es hasta más grave porque no es Vibe Coding, es negligencia.
En mi día a día he observado dos tipos de perfiles cuando usamos IA para desarrollar: En un extremo, los escépticos que no aceptan ninguna propuesta de la IA, y en el otro, aquellos que maravillados por el potencial del uso de la IA para desarrollar aceptan todo sin revisar. Y este último código sí que terminará en producción. Eso es lo peligroso. Por eso debemos movernos en un punto intermedio entre ambos extremos.
¿Cuál es realmente el problema? Cuando hacemos Vibe Coding o no revisamos el código generado por una IA, estamos generando deuda técnica. Peor aún, estamos generando deuda técnica sin dueño cognitivo, lo cual nos aporta una falsa sensación de seguridad.
Un proyecto vibecodeado de primera funcionará perfectamente, pero ¿qué ocurrirá cuando esto escale y tengamos mil usuarios? La magia se romperá delante de nosotros y descubriremos que tenemos un grave problema. Pero ojo, esto también puede ocurrir si es código desarrollado, pero no revisado.
La evolución del Vibe Coding
Como respuesta a las limitaciones del Vibe coding en entornos productivos, como, por ejemplo, la falta de escalabilidad que hemos comentado nace el Vibe engineering. En Vibe Engineering, el humano adopta un rol superior de arquitecto y de revisor, auditando, probando y asegurando la calidad del código entregado por la IA.
En esta línea de disciplina conviven propuestas como el Spec Driven Development (SDD), donde se define primero el comportamiento esperado y, aunque algunas implementaciones también incluyen una fase de revisión de código automática, la revisión humana del plan de implementación y el código final sigue siendo imprescindible.
¿Qué hemos aprendido?
Hacer vibe coding no es bueno ni malo. Todo depende del destino del código que usemos. Por un lado, nos puede otorgar mucha velocidad a la hora de contrastar hipótesis con usuarios con software real. Siempre sabiendo que eso habrá que tirarlo a la basura y construirlo en condiciones. Por otro lado, el código susceptible de acabar en un entorno productivo debería ser siempre revisado por un humano. De una forma u otra, lo importante es controlar la deuda técnica, porque, como todos sabemos, genera intereses.
Al final, lo importante no es tanto ponerle nombre a lo que estás haciendo, sino saber qué estás haciendo. ¿Estás explorando o construyendo? ¿Dónde como expertos, ponemos esa línea?