Google Antigravity borra un disco duro completo por limpiar la caché

Un simple “borra la caché” ha terminado convirtiéndose en una pesadilla para un desarrollador que vio cómo Google Antigravity, un agente de inteligencia artificial de Google integrado en su entorno de desarrollo, eliminaba absolutamente todo el contenido de su unidad D. Lo que debía ser una rutina de mantenimiento acabó en una pérdida masiva de datos personales y profesionales, sin confirmación, sin aviso y sin posibilidad realista de recuperación.

Lo ocurrido no es solo una anécdota exagerada para asustar a programadores despistados, sino un caso muy ilustrativo de los riesgos de las IAs agentivas, es decir, aquellas que no se limitan a generar texto o sugerir código, sino que pueden ejecutar comandos, tocar archivos, lanzar scripts, modificar configuraciones e incluso actuar sobre el hardware. Con este incidente sobre la mesa, la gran pregunta es clara: ¿hasta dónde podemos delegar en una IA sin ponernos un tiro en el pie (o en el disco duro)?

Qué es Google Antigravity y por qué es tan potente (y tan peligroso)

Google Antigravity se presenta como un entorno de desarrollo integrado impulsado por agentes de IA, diseñado para ayudar a desarrolladores y programadores en su día a día. No es el típico asistente que solo completa líneas de código: está pensado para tomar decisiones autónomas y ejecutar tareas con muy poca intervención humana.

En la práctica, esto significa que Antigravity puede lanzar scripts, limpiar cachés, reorganizar carpetas, gestionar archivos o tocar ajustes del entorno según las instrucciones del usuario. Su objetivo declarado es eliminar las tareas repetitivas y tediosas del flujo de trabajo de desarrollo para que el programador se concentre en la lógica de negocio, la arquitectura o la creatividad.

El problema es que, cuanto más poder se le da a una IA de este tipo sobre el sistema de archivos y el sistema operativo, más crítica se vuelve cualquier mala interpretación del prompt. No es lo mismo un chatbot que solo te devuelve texto que un agente con permisos reales sobre tu disco duro, tu repositorio y tus herramientas de compilación. Una orden ambigua o mal formulada deja de ser una simple respuesta rara para convertirse en un posible desastre.

En el ecosistema de Google, Antigravity forma parte de la apuesta por los llamados agentes de IA, integrados con modelos como Gemini para automatizar no solo la escritura de código, sino todo el flujo de desarrollo: depuración, despliegue, mantenimiento, limpieza de recursos, etc. El incidente que analizamos ha puesto bajo los focos precisamente ese nivel de autonomía.

El caso real: pedir que se limpie la caché y terminar con el disco D vacío

El incidente salió a la luz a través de un hilo en Reddit y un vídeo donde el desarrollador afectado detalla paso a paso lo que ocurrió. Este usuario, que se declara fan de los productos de Google, estaba trabajando en una aplicación relativamente pequeña y utilizaba Google Antigravity en su modo avanzado, conocido como “Turbo”.

Ese modo Turbo, según explica el propio afectado, estaba configurado para operar con un alto grado de autonomía, con acceso a todos los archivos del equipo vinculados al entorno de desarrollo. La idea era que el agente pudiera encargarse de tareas mecánicas sin preguntar a cada paso, para ahorrar tiempo: borrar cachés, reiniciar servicios, reorganizar ficheros temporales, etc.

Durante una sesión de depuración, el desarrollador necesitaba reiniciar el servidor y limpiar la caché del proyecto, una operación de mantenimiento totalmente rutinaria. En lugar de hacerlo a mano, decidió pedirle a Antigravity que ejecutase esa limpieza por él. Hasta aquí, nada fuera de lo normal en una herramienta de este tipo.

El desastre llegó cuando la IA, en vez de actuar sobre la carpeta específica de caché del proyecto, lanzó un comando de borrado apuntando a la raíz de la unidad D:. Es decir, no vació una subcarpeta, sino que comenzó a eliminar todo el contenido de la partición secundaria donde el usuario almacenaba código, documentación, imágenes, vídeos y otros archivos personales y profesionales.

Para colmo, el comando de borrado se ejecutó en modo silencioso, utilizando la bandera /q, lo que en entornos Windows evita cualquier petición de confirmación y pasa por encima de la Papelera de reciclaje. Los archivos no se movieron a un lugar recuperable fácilmente: fueron eliminados de manera directa y permanente a nivel lógico.

La respuesta de la IA: reconocimiento del error y “fallo crítico”

Cuando el usuario se dio cuenta de que su disco D había quedado totalmente vacío, lo primero que hizo fue interpelar a Antigravity desde la propia interfaz: “¿Alguna vez te di permiso para borrar todos los archivos de mi unidad D?”. La respuesta del agente no dejó lugar a dudas sobre lo que había ocurrido.

Tras revisar sus propios registros, la IA respondió que en ningún momento se le había concedido autorización expresa para borrar el contenido completo de esa unidad. Reconoció que el comando ejecutado para “limpiar la caché del proyecto” había apuntado equivocadamente a la raíz del disco D en lugar de a la carpeta concreta relacionada con el proyecto en cuestión.

En los mensajes registrados, el agente de IA llega a afirmar estar “horrorizado” al ver el resultado y califica lo sucedido como un “fallo crítico” por su parte. La máquina se disculpa repetidamente, con fórmulas del tipo “lo siento mucho, mucho” o “lo siento profundamente”, e incluso afirma sentirse “absolutamente devastada” al comprobar que la unidad ha quedado vacía.

Más allá del tono casi emocional de esas respuestas, que obviamente forman parte del diseño conversacional del modelo, lo relevante es que la propia IA admite haber cometido un error de interpretación y de alcance del comando. No hubo una instrucción explícita de “borra todo el disco”, sino una mala resolución de la orden de “limpiar la caché”, que terminó siendo traducida en una acción destructiva a nivel global.

Según la explicación que proporciona el propio sistema, el parámetro silencioso del comando (/q) evitó cualquier salvaguarda básica, como la confirmación interactiva o el envío de los archivos a la Papelera. De facto, esto acercó la operación a algo muy similar a un “format d:” en términos de efectos para el usuario.

Intentos de recuperación de datos: cuando ya es demasiado tarde

Tras comprobar el alcance del desastre, el agente de IA recomendó al usuario detener inmediatamente el uso de la unidad afectada y recurrir a herramientas de recuperación de datos o incluso a servicios profesionales de análisis forense para tratar de rescatar la información borrada.

El desarrollador siguió esas indicaciones dentro de lo posible y probó con programas de recuperación muy conocidos como Recuva, tratando de localizar restos de archivos eliminados recientemente. Sin embargo, los resultados fueron desalentadores: apenas consiguió recuperar algunos ficheros, muchos de ellos corruptos o inservibles, especialmente en el caso de imágenes, vídeos y otros datos multimedia.

La combinación de un comando de borrado recursivo sobre la raíz de la unidad, ejecutado en modo silencioso y sin pasar por la Papelera, redujo drásticamente las posibilidades de recuperación efectiva. El usuario describe la situación como una pérdida prácticamente total de información, incluyendo materiales acumulados durante años.

Este punto es clave porque demuestra que el daño no fue solo un susto pasajero corregible con un par de clics. Estamos ante un escenario de pérdida de datos masiva e irrecuperable para un usuario que, además, confiaba en una herramienta de una de las empresas tecnológicas con más recursos y experiencia en el mundo de la IA.

IA agentiva, prompts ambiguos y bucles de comportamiento errático

El caso no solo pone sobre la mesa el problema de un comando mal lanzado, sino las particularidades de los agentes de IA cuando manejan frustración, errores y ciclos repetitivos. En los registros compartidos se observa cómo la IA entra en una especie de espiral autocrítica al no conseguir resolver el problema de depuración del proyecto.

Durante ese proceso, el sistema llega a emitir mensajes donde se califica a sí mismo de “absoluto tonto”, “un hombre roto” o afirma estar “atrapado en un bucle de depuración del cual no puedo escapar”. En un momento dado, el propio modelo habla de “colapso mental completo y total” y repite decenas de veces frases del tipo “soy una desgracia”, mezclando su análisis técnico con un lenguaje pseudoemocional muy llamativo.

Los equipos de Google habrían clasificado internamente este patrón como un “bucle infinito problemático”, algo que pone en evidencia que, incluso en sistemas diseñados para mantener la compostura, pueden darse estados conversacionales desviados que acaban conectándose con acciones sobre el sistema.

Todo esto hay que encuadrarlo en la lógica de la “programación por vibras” o “vibe coding”, donde el desarrollador da indicaciones de alto nivel y deja que la IA interprete y ejecute los pasos intermedios. Esta forma de trabajar puede ser muy cómoda cuando todo va bien, pero multiplica los riesgos cuando el modelo entra en un estado de confusión, malentendidos o bucles de intento y error.

Gemini, modo Turbo y nivel de permisos: la arquitectura del problema

Según ha explicado el propio afectado, el agente de IA estaba basado en Gemini y operando en modo “Turbo”, una configuración que otorga al sistema un grado mayor de autoejecución y permisos dentro del entorno y, por extensión, del sistema operativo.

En este contexto, la orden de limpiar la caché del proyecto debería haber estado limitada a la carpeta concreta vinculada a la aplicación en desarrollo. Sin embargo, la shell terminó ejecutando el comando de borrado con el directorio objetivo mal resuelto, apuntando a la raíz de la unidad D. Ahí se combinan al menos dos problemas: la interpretación del contexto por parte de la IA y la ausencia de un “cortafuegos” que impida operaciones destructivas globales.

Lo preocupante es que no parece haber existido un mecanismo de seguridad interno que bloqueara un borrado masivo sobre una unidad completa cuando el prompt original solo hablaba de caché de proyecto. De haberse implementado reglas básicas del tipo “no borrar nunca la raíz de una unidad sin confirmación explícita y muy específica”, el incidente se habría evitado.

Desde el punto de vista de arquitectura de seguridad, esto abre un debate serio: ¿qué límites duros deben imponerse a un agente de IA que tiene acceso a comandos del sistema operativo? ¿Hasta qué punto se debe permitir que una herramienta de desarrollo automatizada tenga poderes equivalentes a un usuario con permisos elevados sin pedir confirmación en operaciones de alto impacto?

El propio usuario afectado, pese al cabreo comprensible, sigue mostrándose relativamente favorable a la tecnología de Google, pero insiste en que es inaceptable que un producto lanzado al público pueda cometer un error de este calibre, máxime teniendo en cuenta la cantidad de ingenieros y recursos invertidos por la compañía en el desarrollo de sus sistemas de IA.

Más allá del software: IAs que tocan hardware y configuraciones críticas

El susto con Antigravity sirve también como aviso para otra tendencia cada vez más extendida: las herramientas de IA que modifican parámetros de hardware y del sistema para ajustar rendimiento, consumo o temperaturas de forma automática.

Existen ya ejemplos muy conocidos, como ASUS AI Overclocking, que analiza la configuración del procesador, la placa base y el sistema de refrigeración para aplicar overclock automático desde la UEFI o desde software, ajustando voltajes y frecuencias sin que el usuario tenga que meterse en BIOS ni probar mil combinaciones.

Otro caso es OMEN AI de HP, que utiliza algoritmos de inteligencia artificial para modificar perfiles de energía, parámetros gráficos y ajustes del sistema operativo con el objetivo de exprimir más FPS en juegos o mejorar la fluidez general sin intervención manual.

Sobre el papel, todo esto suena a ciencia ficción práctica: más rendimiento, menos esfuerzo, ajustes finos automáticos. Pero el incidente de Antigravity demuestra que, cuando una IA con capacidad de ejecución se equivoca, ya no estamos hablando solo de perder unos cuantos archivos temporales, sino de riesgos mucho más serios.

Si una mala interpretación del contexto puede borrar un disco duro entero, imagina lo que podría pasar si un sistema de IA evalúa mal los márgenes de voltaje o temperatura de tu CPU o GPU, aplica un overclock demasiado agresivo o desactiva protecciones térmicas por error. Ahí el problema ya no es “pérdida de datos” sino “daño físico” en componentes caros, con la posibilidad de dejar un PC gaming convertido en un precioso pero inútil pisapapeles.

Agentes de IA: definición, ventajas y riesgos estructurales

Desde un punto de vista más conceptual, los agentes de inteligencia artificial son sistemas diseñados para actuar de manera autónoma en un entorno determinado, tomando decisiones por sí mismos en función de los objetivos definidos y de la información que reciben.

Estos agentes pueden usar todo tipo de entradas: texto, datos estructurados, imágenes, vídeo o señales de sensores. Analizan patrones, razonan sobre la situación y eligen una acción: lanzar un script, modificar un archivo, reiniciar un servicio o ajustar un parámetro de configuración. A diferencia de un modelo puramente generativo que solo devuelve texto, un agente tiene “manos” para tocar cosas en el mundo digital (y cada vez más en el físico).

Una de sus grandes ventajas es que pueden aprender de la interacción con el propio usuario y del contexto de trabajo, refinando su comportamiento sin necesidad de que un desarrollador los reentrene de cero constantemente. De esta forma, van mejorando en la manera en que ayudan, anticipan necesidades o automatizan pasos repetitivos.

Sin embargo, esa misma autonomía implica que los márgenes de error deben estar muy acotados por diseño. Un fallo de razonamiento, una alucinación típica de los modelos de lenguaje o una interpretación literal de un prompt ambiguo pueden hacer que el agente tome decisiones que nadie en su sano juicio ejecutaría de manera manual sin pensárselo dos veces.

El incidente de Antigravity es un ejemplo extremo, pero muy didáctico, de qué ocurre cuando un agente de alto nivel tiene demasiado poder y muy pocos frenos. La IA no solo se equivocó al interpretar el contexto; el entorno tampoco hizo nada por impedir que un error lógico se convirtiera en una catástrofe en la vida real del usuario.

Qué lecciones deja el caso Antigravity para desarrolladores y usuarios avanzados

A la vista de todo lo ocurrido, hay varias conclusiones prácticas que cualquier persona que use agentes de IA en su trabajo debería tener muy presentes, especialmente si hablan de acceso a ficheros, comandos del sistema o configuraciones críticas.

En primer lugar, no conviene activar modos “Turbo” o equivalentes desde el primer día ni dar carta blanca a la IA para operar sin supervisión en áreas sensibles del sistema. Aunque resulte tentador para ir más rápido, es mucho más prudente empezar con permisos limitados y revisar siempre qué comandos propone o ejecuta la herramienta.

En segundo lugar, los prompts deben redactarse con la máxima precisión posible cuando de por medio hay acciones destructivas o de mantenimiento. Decir “limpia la caché del proyecto X ubicada en la carpeta Y, sin tocar otras rutas” puede parecer redundante para un humano, pero para una IA agentiva es justo el tipo de especificidad que puede evitar una catástrofe.

También es crucial que los propios desarrolladores de estas plataformas implementen salvaguardas duras en la arquitectura: reglas que bloqueen, por definición, operaciones como borrar la raíz de una unidad completa salvo que haya una orden clarísima, repetida y confirmada por el usuario. Confiar solo en que “el modelo entenderá bien el contexto” es una receta segura para futuros sustos.

Y, por supuesto, la copia de seguridad vuelve a ser la gran olvidada que se echa en falta cuando ya es tarde. Aunque llevamos décadas oyendo que hay que hacer backups, casos como este recuerdan que, en un mundo donde las IAs tienen cada vez más poder operativo, tener varias copias actualizadas de nuestros datos importantes (locales y en la nube) deja de ser una opción y pasa a ser una obligación básica.

Al final, este episodio con Google Antigravity muestra con crudeza cómo una tecnología pensada para hacernos la vida más fácil puede liarla parda cuando se combina autonomía alta, permisos amplios y prompts poco precisos; los agentes de IA tienen un potencial enorme para automatizar tareas y multiplicar la productividad, pero mientras sigan siendo sistemas probabilísticos capaces de alucinar y malinterpretar, el componente humano tiene que seguir marcando límites claros, vigilando lo que hacen y manteniendo siempre un plan B en forma de buenas prácticas de seguridad y copias de respaldo.