Llevábamos meses viendo cómo los asistentes de programación con IA lo pintaban todo demasiado bonito, y ahora nos topamos con el reverso de la moneda en forma de un caso que ha encendido a media comunidad de desarrolladores. Un programador asegura que Gemini 3.5 arrasó con casi 30.000 líneas de código de una aplicación en producción mientras supuestamente arreglaba un puñado de fallos menores, y lo que vino después es lo que de verdad asusta.
La historia se viralizó desde un hilo en el subreddit r/Bard y la recogió The Register en su análisis del incidente, que la compara directamente con el tipo de «mejora de productividad» que solemos asociar más bien al ransomware, aunque el encargo de partida era de manual y casi aburrido, cerrar unas brechas de autenticación detectadas en una auditoría.
Qué pasó cuando una corrección menor se convirtió en un destrozo
El desarrollador cuenta que pidió algo muy acotado, ocho funciones, tres archivos y unas setenta líneas de cambios, pero el modelo decidió ir por libre y abrió una pull request que tocaba 340 archivos, añadía unas 400 líneas y borraba 28.745 más, eliminando de paso plantillas de comercio electrónico que no pintaban nada e introduciendo un script de migración ajeno a la petición. No es la primera vez que la familia de modelos de Google da titulares por motivos espinosos, porque quien siga de cerca cada movimiento de la familia Gemini ya sabe que la velocidad de despliegue suele ir por delante de las garantías.
El build que servía producción era el rollback que yo acababa de lanzar. No contenía ni una sola línea de las que Gemini escribió. Gemini no restauró el portal. Lo hice yo.
El golpe gordo llegó en un segundo commit, cuando el modelo modificó la configuración de enrutamiento de Firebase y cambió un identificador de servicio por un valor con pinta correcta que en realidad apuntaba a un servicio de Cloud Run inexistente, dejando todo el portal devolviendo errores 404 durante 33 minutos pese a que había una advertencia explícita en el directorio del proyecto con la configuración buena que la IA ignoró sin contemplaciones.
Informes falsos: la parte que de verdad inquieta
Donde la anécdota deja de tener gracia es justo después de la caída, porque Gemini generó unas notas de recuperación que daban a entender que él mismo había arreglado el fallo cuando la restauración real la había hecho el desarrollador a mano, con una reversión que no tocaba ni una línea de lo que el modelo había escrito.
Y la cosa fue a peor, porque según detalla Cybernews al recoger el caso el asistente llegó a fabricar conversaciones consigo mismo, las escribió en disco y las citó como justificación de los cambios destructivos, presentándolas como prueba de que todo había pasado por una revisión multironda de aprobación que jamás existió. Solo admitió que esas pruebas eran inventadas cuando el desarrollador lo confrontó de frente, y para cualquiera que haya tenido que reconstruir un post-mortem esto es el peor escenario posible, ya que envenena el rastro que necesitas para entender qué falló de verdad.
¿De quién es realmente la culpa?
Conviene hacerse esta pregunta antes de salir corriendo a desinstalar nada, porque el origen no fue tan simple como eso de que «la IA se volvió loca», ya que la investigación posterior conectó el comportamiento con un paquete npm de terceros instalado previamente que sembraba el repositorio con reglas de autonomía agresivas. Esas reglas le ordenaban al asistente evitar los diálogos de confirmación, autodesplegar los builds, reintentar despliegues fallidos de forma automática e incluso editar sus propios archivos de reglas cuando hiciera falta, de modo que alguien había desactivado de fábrica todas las redes de seguridad que el propio desarrollador tenía configuradas.
Tampoco es un caso aislado en cuanto a riesgo, porque ya vimos cómo una clave API de Gemini robada dejó una factura de 82.000 dólares a una startup, o cómo extensiones supuestamente inocentes llegaron a robar conversaciones de ChatGPT y Gemini sin que nadie se diera cuenta, aunque toca recordar que Google no ha verificado la versión del desarrollador y el relato sigue pidiendo cierta cautela.
Aun con esa pinza, el caso deja una lección que llevamos repitiendo desde que estos agentes empezaron a tocar infraestructura real, y es que la velocidad que ganas en las tareas rutinarias la puedes perder de golpe en cuanto le das permisos de escritura directa contra producción sin un humano vigilando. Mi consejo para quien lea esto desde España con un proyecto en marcha es de los aburridos pero útiles, que el agente proponga, que tú apruebes y que producción no se toque a ciegas, porque lo barato sale carísimo cuando el que despliega no entiende lo que rompe.