En marzo escribí sobre el vibe coding en pleno auge, cuando el término estaba en todos lados y costaba pensar con la cabeza fría en medio de tanto entusiasmo. Decía entonces que me había deslumbrado y asustado el mismo día, y dejaba varias preguntas abiertas, porque me parecía apresurado sacar conclusiones a tres semanas de que el concepto existiera. Pasaron cuatro meses. No es mucho tiempo, lo sé, pero en un campo que se mueve a esta velocidad, cuatro meses alcanzan para que baje un poco la espuma y empiece a verse qué hay debajo. Y eso es lo que quiero hacer acá: un balance honesto, a mitad de año, de un fenómeno que parecía que iba a cambiarlo todo. No para declararlo muerto ni para coronarlo como la revolución definitiva —las dos cosas me parecen igual de perezosas— sino para preguntarme algo más útil: cuando se apaga el ruido, ¿qué queda? Porque creo que ahí, en el residuo que sobrevive al hype, está siempre la parte que de verdad importa.
El ciclo de siempre, otra vez#
Si uno lleva suficientes años en tecnología, aprende a reconocer un patrón que se repite con cada novedad que llega prometiendo cambiarlo todo. Primero está la euforia: la herramienta nueva lo va a resolver todo, va a hacer obsoleto lo anterior, quien no la adopte ya se quedó atrás. Después llega el momento en que la realidad empieza a poner las cosas en su lugar, aparecen los problemas que el entusiasmo no dejaba ver, y el péndulo se va hacia el otro extremo: era todo humo, no servía para nada, otra moda más. Y recién mucho después, cuando ya nadie escribe titulares sobre el tema, se asienta lo razonable: la herramienta sirve para algunas cosas, no para otras, y encontró su lugar.
El vibe coding está transitando ese ciclo, y a una velocidad que asusta. En febrero era un término nuevo; en marzo, cuando escribí, estaba en su pico de euforia; y ahora, a mitad de año, empiezo a percibir el principio de la corrección. No el rechazo total todavía, pero sí las primeras señales de que la realidad está cobrando sus cuentas. Lo interesante de haber escrito en pleno auge y volver ahora es que puedo comparar lo que intuía entonces con lo que se está viendo, y revisar honestamente en qué acerté, en qué me quedé corto y en qué el tiempo todavía no dio su veredicto.
Lo que se está cayendo#
Empecemos por lo que el entusiasmo prometía y la realidad está desinflando. La promesa más fuerte del vibe coding, la que más circuló, era una versión de “cualquiera puede construir software ahora, sin saber programar, solo describiéndole a la IA lo que quiere”. Y esa promesa, llevada a su extremo, se está cayendo. No porque la herramienta no funcione —funciona, y sorprende— sino porque construir algo que parece andar y construir algo que se sostiene en producción resultaron ser, como muchos sospechábamos, dos cosas muy distintas.
Lo que empieza a verse, a medida que esos proyectos vibe-codeados maduran o intentan crecer, es exactamente lo que temía en marzo. Aparecen los problemas de seguridad en código que nadie revisó a fondo. Aparece la dificultad de mantener o extender sistemas que nadie entiende del todo, porque nacieron de conversaciones que ya no existen. Aparece el momento incómodo en que algo falla de una manera que la IA sola no puede resolver, y el que tiene que arreglarlo descubre que no entiende lo que está tocando. Hay datos que empiezan a confirmar esto: ya a principios de año, análisis sobre código asistido por IA mostraban que la velocidad de generación venía acompañada de un aumento de los riesgos de seguridad, sobre todo en lo que más cuesta detectar, que son los problemas estructurales y no los errores de sintaxis. La IA arregla las erratas y, si una no presta atención, planta los problemas profundos. Y este mismo mes empezaron a aparecer casos concretos de aplicaciones construidas con estas herramientas que terminaron expuestas por configuraciones de seguridad que nadie miró. No son catástrofes globales, pero son recordatorios.
Lo que se cae, entonces, no es la herramienta. Es la fantasía de que la herramienta eliminaba la necesidad de entender. Esa idea de que el conocimiento técnico se había vuelto opcional, de que el criterio era un lujo del pasado, de que bastaba con describir y aceptar. Eso es lo que la realidad está corrigiendo, y la corrección era previsible, porque esa fantasía no era nueva: es la misma que acompañó a cada herramienta que prometió hacer innecesario el oficio, y que cada vez terminó demostrando que lo desplazaba, no lo eliminaba.
Lo que quedó#
Pero sería injusto y, peor, poco útil quedarme solo en lo que se cayó. Porque debajo del hype había algo real, y eso es lo que me interesa rescatar. El vibe coding, despojado de la promesa exagerada, dejó un puñado de cosas que llegaron para quedarse, y que ya cambiaron cómo trabajamos muchos de nosotros.
Lo primero que quedó es la velocidad de exploración. La capacidad de ir de una idea a un prototipo que funciona en minutos, sin la fricción de antes, es real y es valiosísima. No reemplaza la construcción seria de software, pero transformó la fase de explorar y validar ideas. Hoy puedo probar un enfoque, descartarlo, probar otro, todo en el tiempo que antes me llevaba configurar el entorno. Eso no se va a ir; al contrario, se va a profundizar. Lo que aprendimos no es que el vibe coding sirva para todo, sino que para prototipar y explorar es extraordinario, y que conviene tenerlo en la caja de herramientas para exactamente eso.
Lo segundo que quedó, y es quizás lo más interesante, es una revalorización inesperada de cosas que la industria había empezado a despreciar. El vibe coding, al fallar donde falla, nos recordó por qué importan la revisión, la documentación, la arquitectura clara, el versionado de las decisiones, la comprensión real de lo que construimos. Paradójicamente, la herramienta que prometía hacer innecesaria la disciplina terminó siendo el mejor argumento a favor de la disciplina. Cuando ves de cerca lo que pasa sin ella, entendés por qué estaba ahí. Es como esas reglas que parecen burocráticas hasta que alguien las saca y todo se rompe.
Y lo tercero, más sutil: quedó una conversación honesta sobre los límites. En marzo, hablar de los riesgos del vibe coding sonaba a aguafiestas en medio de la fiesta. Cuatro meses después, esa conversación se volvió normal, casi obvia. Mucha gente que se lanzó con entusiasmo ciego aprendió, a veces a los golpes, dónde están las fronteras. Y ese aprendizaje colectivo —saber para qué sí y para qué no— es un residuo valioso que no teníamos antes de toda esta experiencia. Las modas, cuando pasan, nos dejan más sabios sobre sus propios límites, siempre que hayamos prestado atención.
El residuo útil de las modas#
Esto me lleva a una idea que excede al vibe coding y que es, en el fondo, de lo que más me interesa hablar. Las modas técnicas tienen mala fama, y en parte se la ganan, porque vienen envueltas en exageración, en promesas que no se cumplen, en ese ruido que empuja a adoptar cosas por miedo a quedarse afuera más que por necesidad real. Pero descartarlas en bloque, como hace el cínico que ya vio todo y de todo desconfía, es tan ingenuo como creerles todo. Porque casi siempre, debajo de la espuma, hay algo. Un grano de señal dentro del ruido.
El trabajo —y acá entra el criterio, que es lo que más valoro en alguien técnico con experiencia— es justamente separar ese grano del resto. No tragarse el hype entero ni rechazarlo entero, sino tener la paciencia de esperar a que baje la espuma y quedarse con lo que sobrevive. Lo vi pasar muchas veces a lo largo de los años, con tecnologías que prometieron revoluciones y dejaron, eso sí, una o dos prácticas que incorporamos para siempre. Casi ninguna moda cumple lo que promete; casi ninguna es completamente inútil. La verdad, como casi siempre, vive en ese territorio incómodo del medio, que es justo el que no genera titulares.
Y por eso me resisto, cada vez más, a opinar sobre las novedades en caliente. No porque no tenga opiniones, sino porque las opiniones en caliente casi siempre erran, para un lado o para el otro. El que en marzo declaraba que el vibe coding era la muerte de la programación tradicional se equivocó. El que lo declaraba un fraude sin valor también. Los dos opinaron rápido, sobre el ruido, antes de que hubiera con qué juzgar. El valor de esperar, de digerir, de volver cuatro meses después con la cabeza más fría, es que uno puede empezar a distinguir lo durable de lo efímero. No siempre, no con certeza, pero mejor que en el fragor del momento.
En qué acerté y en qué me quedé corto#
Una de las ventajas de haber escrito en pleno auge y volver ahora es que puedo revisar mi propio texto sin piedad, que es un ejercicio que recomiendo y que poca gente hace. Releyendo lo que escribí en marzo, creo que acerté en lo central: que el problema no era la herramienta sino el criterio que abandonábamos, que el punto de quiebre estaba en el trabajo en equipo y en producción, que faltaba versionar la intención y no solo el código. Esas intuiciones se sostienen, y algunas se confirmaron antes de lo que esperaba.
Pero también me quedé corto en un par de cosas, y vale la pena decirlo. Subestimé la velocidad a la que el fenómeno se iba a profesionalizar, para bien y para mal: pensé que el vibe coding quedaría más confinado a prototipos y experimentos, y en estos meses vi que mucha gente lo empujó directo a producción con una audacia que no anticipé del todo. También fui, quizás, demasiado prudente con lo positivo: en marzo, rodeado de tanto entusiasmo, puse el acento en las advertencias, y hoy diría con más fuerza que la capacidad de prototipar a esta velocidad es una de las mejores cosas que le pasaron al desarrollo en años. El miedo a sonar ingenuo me hizo medir de más el elogio.
Reconocer esto no me incomoda; al contrario, lo siento parte del oficio. Quien escribe sobre tecnología en movimiento se va a equivocar seguido, porque está opinando sobre algo que todavía está pasando. Lo que distingue a una mirada seria no es no equivocarse nunca —imposible— sino tener la honestidad de volver, revisar lo dicho y ajustar. El que nunca revisa lo que afirmó tiempo atrás no es que acierte siempre; es que no se anima a mirar. Y en un campo donde todos opinamos constantemente sobre lo que recién está naciendo, esa disposición a corregirse vale más que cualquier predicción acertada por casualidad.
Probarlo una vez no es haberlo adoptado#
Hay una distinción que en marzo no estaba tan clara y que estos meses ayudaron a afilar: una cosa es probar una herramienta y otra muy distinta es haberla incorporado al flujo de trabajo. En el pico del entusiasmo, mucha gente probó el vibe coding una tarde, quedó deslumbrada, escribió sobre la experiencia y sumó al coro del “esto lo cambia todo”. Pero probar algo en una sesión aislada, sin las restricciones de un proyecto real, sin equipo, sin mantenimiento, sin la presión de que eso tiene que seguir funcionando dentro de seis meses, dice muy poco sobre su valor verdadero. La demo siempre brilla. El uso sostenido es el que revela.
Lo que se ve ahora, con un poco más de recorrido, es esa diferencia entre el deslumbramiento inicial y la adopción real. Algunos equipos integraron el vibe coding a su trabajo de manera sensata: lo usan para lo que sirve, lo evitan para lo que no, le pusieron reglas, lo combinaron con revisión. Otros lo probaron, se entusiasmaron, lo empujaron a donde no debían y ahora están lidiando con las consecuencias. Y muchos, simplemente, lo probaron un rato y volvieron a sus herramientas de siempre cuando la novedad se desgastó. Esa decantación —quién lo adoptó de verdad y para qué— es información que en marzo no existía y que hoy empieza a estar disponible. Y es muchísimo más reveladora que cualquier opinión escrita en la euforia, porque está hecha de uso real y no de primeras impresiones.
Me parece que esta distinción, entre probar y adoptar, es una de las que más conviene tener presente con cualquier novedad. El ruido lo generan los que prueban y opinan rápido; la señal la dan, mucho más callados, los que incorporaron algo a su trabajo durante meses y pueden contar qué pasó de verdad. Cuando quiero entender si una herramienta nueva vale la pena, cada vez escucho menos a los que la probaron una vez y más a los que conviven con ella hace rato. Los primeros tienen entusiasmo; los segundos, experiencia. Y para juzgar, ya lo dije otras veces, la experiencia pesa más.
Lo que yo me llevo, a mitad de camino#
Si tuviera que hacer mi balance personal, diría que el vibe coding me confirmó algo que ya sospechaba y que cada nueva herramienta vuelve a poner sobre la mesa: la tecnología cambia las herramientas, pero no elimina la necesidad de criterio. Al contrario, la desplaza. Antes el criterio estaba en escribir bien el código; ahora está en saber cuándo confiar en lo que la IA genera y cuándo no, en saber qué tarea conviene vibe-codear y cuál no, en saber leer lo que se produjo aunque no lo hayamos tipeado nosotros. El lugar del criterio se movió; su importancia, no.
También me llevo una confirmación sobre cómo conviene incorporar lo nuevo en un equipo. No con prohibiciones, que no funcionan y además espantan el talento curioso. Tampoco con adopción ciega, que termina en sistemas que nadie entiende. Sino con esa actitud de exploración disciplinada: probar lo nuevo en territorio seguro, aprender sus límites de primera mano, separar dónde suma de dónde es peligroso, y recién entonces dejarlo entrar a lo que importa. El equipo que en marzo se lanzó sin red probablemente ya pagó algunas cuentas; el que esperó y observó, hoy puede adoptar lo bueno del vibe coding sabiendo dónde están las fronteras. Esa diferencia, la de la paciencia con criterio, no se nota en la euforia. Se nota unos meses después, que es justamente donde estamos.
Y me llevo, sobre todo, una manera de pararme frente a lo que viene. Porque va a venir otra cosa, seguro, otra herramienta deslumbrante que va a prometer cambiarlo todo y va a generar la misma euforia, el mismo péndulo, el mismo ruido. Y cuando llegue, voy a intentar hacer lo mismo que con el vibe coding: entusiasmarme sin perder la cabeza, probarla con honestidad, no opinar en caliente, y esperar a que baje la espuma para quedarme con el grano. No es la actitud más vistosa, ni la que consigue más aplausos en el momento del hype. Pero es, creo, la que mejor envejece.
Les dejo una pregunta para que la lleven a su propio terreno, porque seguro tienen su propia moda reciente para examinar. La próxima vez que una herramienta nueva llene de ruido las conversaciones técnicas y sientan la presión de tener una opinión ya, ¿van a opinar sobre la espuma, o van a tener la paciencia, cada vez más difícil de sostener, de esperar a ver qué queda cuando el ruido se apague? Porque casi siempre queda algo. Y casi siempre, ese algo es bastante más chico, y bastante más valioso, que lo que prometía el titular.
Fuentes consultadas#
- Andrej Karpathy, publicación original sobre “vibe coding” en X, 2 de febrero de 2025.
- Apiiro, “Faster code, greater risks: The security trade-off of AI-driven development”, 26 de febrero de 2025.