TL;DR: Vibe-coding es una idea horrible. Añade una complejidad innecesaria, no siempre sigue las instrucciones y a veces hace cosas increíblemente estúpidas. Una idea igual de horrible es tirar al bebé con el agua del baño: asumir que la codificación asistida por IA es un callejón sin salida.
En manos expertas, puede suponer un aumento significativo de la productividad e incluso de la calidad del código. Algo parecido a lo que ocurre con las motosierras, que son una maravilla de la productividad moderna y, al mismo tiempo, pueden causar miles de heridos al año.
Detalles
Las motosierras son una tecnología asombrosa. En manos de un experto, una motosierra permite cortar leña 5 veces más rápido que un hacha. En manos inexpertas, sin embargo, es responsable de unas 30.000 lesiones al año sólo en Estados Unidos.
Para mí, el vibe-coding es como manejar una motosierra con los ojos vendados: se confía en que la motosierra haga cosas sanas, cuando las motosierras tienen varios modos de fallo conocidos.
El más grave es lo que se conoce como «contragolpe»: cuando de repente la motosierra da una sacudida y, si no tienes cuidado, puede golpearte en la cara o en el pecho.
Incluso unos conocimientos básicos sobre el contragolpe y cómo evitarlo suponen una gran diferencia para la seguridad de las motosierras. Por eso es importante entender cuáles son los modos de fallo de la actual generación de motosierras.
Ya he completado 5 proyectos de tamaño medio utilizando Claude Code y Cursor, y estos son los modos de fallo que he descubierto hasta ahora:
10-20% «actos aleatorios de estupidez».
He visto herramientas de codificación asistidas por IA hacer cosas increíblemente tontas que realmente te hacen preguntarte qué está pasando en esos miles de millones de parámetros. Parece que ocurren entre el 10 y el 20% de las veces. Me refiero a cosas realmente estúpidas, todas ellas reales:
Lo apunto y le pido que arregle un poco de código, y en lugar de arreglarlo, lo «burla».
En el cambio 1, arregla el problema.
En el cambio 2 - inmediatamente después del cambio 1 - deshace el arreglo.
Cambia las constantes aleatoriamente.
Especialmente si una constante es más antigua. Un punto particularmente delicado es cambiar las constantes que definen la versión de un LLM a utilizar. Normalmente utilizo la última versión, y como fue entrenado antes de la última versión, asume que la nueva versión es un error y lo «corrige».
La solución es sencilla: revisar cada línea de código que genere un asistente de codificación de IA. Sin excepciones. Cada vez que he intentado hacer las cosas al estilo «vibe-code» ha acabado en desastre y me ha llevado varias veces más tiempo que si hubiera revisado todo el código yo mismo. Esto es parecido a decir «no hagas motosierras con los ojos vendados, borracho o sin prestar atención».
Añaden complejidad
Las soluciones de los agentes de codificación de IA son más complejas que si las hubiera codificado un humano. El código que generan suele estar duplicado. Suelen tratar casos extremos que no son en absoluto probables.
Tienden a complicar demasiado las cosas, en lugar de hacerlas poco a poco. En un caso, «vibe coded» un archivo, y luego lo revisé cuidadosamente. Pude reducir el tamaño del archivo de 700 a 300 líneas sin perder ninguna funcionalidad útil.
Solución: presta atención, y no te limites a mirar los cambios uno por uno. De vez en cuando, da un paso atrás y observa si muchas pequeñas decisiones suman globalmente buenas decisiones.
No siempre siguen las instrucciones
Para mí, ésta es probablemente la mayor molestia, especialmente con Claude Code. Puede decirle a Claude Code lo que debe hacer en un archivo llamado CLAUDE.md. Que Claude Code haga realmente esas cosas es otro asunto completamente distinto.
Le he dicho repetidamente a Claude Code que no añada fallbacks y que no se preocupe por la compatibilidad con versiones anteriores. Mi CLAUDE.md tiene un número ridículo de variantes de «BAJO NINGUNA CIRCUNSTANCIA AÑADIRÁS FALLBACKS», pero sigue añadiendo fallbacks innecesarios. No estoy hablando de fallbacks útiles, sino más bien de fallbacks del tipo «si una versión futura de Python tiene un bug».
Solución: no hay otra solución para esto que ... lo has adivinado ... comprobar cuidadosamente cada paso que da.
Persiguiendo su propia cola
Muy a menudo le presento a un asistente de IA un registro de depuración y le pido que lo arregle. Puede que el 70% de las veces sea capaz de arreglarlo por sí mismo. Pero el 30% de las veces, puede quedarse atascado persiguiéndose su propia cola.
Lo que quiero decir con esto es que intentará arreglar el fallo y luego se dará cuenta de que el cambio no lo ha solucionado. Entonces intenta introducir una nueva solución que tiene el mismo problema. Y finalmente, acaba cerrando el ciclo.
Mi regla general es que si el asistente de IA no ha arreglado el fallo en 3 intentos, nunca resolverá el problema y hay que intervenir: darle una pista para que la siga, mirar el propio código o decirle la dirección en la que va es un callejón sin salida.
Entonces, ¿para qué utilizarlos?
Teniendo en cuenta estos problemas tan importantes, ¿por qué querríamos utilizar la codificación asistida por IA?
He visto una tendencia reaccionaria en la que la reacción de la gente a la codificación por vibración es descartar por completo la codificación asistida por IA. El péndulo oscila demasiado en la dirección contraria.
Como en muchas otras cosas, lo mejor es encontrar un término medio.
¿Por qué?
Aumenta realmente la eficacia
Siempre y cuando pueda evitar las trampas anteriores, no hay duda de que aumenta mi eficacia entre 3 y 5 veces, dependiendo de la fase del proyecto y del tiempo.
Hace poco terminé un proyecto de 5.000 líneas en python en 9 días laborables. Y este es un código con el que estoy contento/orgulloso/es casi de calidad de producción - no es código experimental.
Es código que no me avergonzaría mostrar a otro ingeniero al que respeto y pedirle que lo revise.
Mejora la calidad del código
Este es quizás el aspecto más sutil de todos: teniendo en cuenta los retos anteriores, ¿cómo puede exactamente esta tecnología mejorar la calidad del código?
La respuesta es que, utilizada correctamente, altera el panorama de la pereza. La triste realidad (al menos para este ingeniero) es que a veces se incurre en deuda técnica porque hacer las cosas «de la manera correcta» es aburrido y lleva mucho tiempo.
Pero, ¿y si existiera una herramienta que hiciera que hacer lo correcto no fuera más difícil que añadir una tarea pendiente? Entonces estarás mucho más inclinado a usarla.
Una de las razones por las que no necesito compatibilidad hacia atrás es porque ahora es más eficiente cambiar cada referencia (incluso las complejas) a código que utiliza la última versión.
Ahora me encuentro realizando refactorizaciones que antes no me habría planteado.
Reflexiones finales
El aumento de la eficiencia de la codificación asistida por IA es demasiado grande como para ignorarlo: en manos expertas, la cantidad de trabajo que se puede hacer con la ayuda de la IA es enorme.
Del mismo modo que la humanidad ha pasado de las hachas a las motosierras, no cabe duda de que dentro de unos años todo el desarrollo estará asistido por IA. Sí, todavía hay gente que utiliza hachas, pero suele ser por razones especializadas o de nicho.
Pero si vamos a utilizar estas técnicas, tenemos que aprender la forma correcta de utilizar estas herramientas. Del mismo modo que nunca utilizarías una motosierra con los ojos vendados porque las posibilidades de lesionarte son muy altas, nunca deberías utilizar herramientas de codificación por vibración en bases de código de producción.