El incidente que borró años de trabajo

Todos disfrutan de una buena historia sobre agentes de IA que fallan, y estas suelen venir acompañadas de cierta satisfacción maliciosa hacia nuestros compañeros virtuales. Sin embargo, a veces los errores pueden atribuirse a una supervisión inadecuada, como fue el caso de Alexey Grigorev, quien tuvo la valentía de detallar cómo logró que Claude Code eliminara años de registros de un sitio web, incluidas las instantáneas de recuperación.

El origen del problema

La historia comienza cuando Grigorev quería trasladar su sitio web, AI Shipping Labs, a AWS y hacer que compartiera la misma infraestructura que DataTalks.Club. El propio Claude desaconsejó esa opción, pero Grigorev consideró que no valía la pena la molestia o el coste de mantener dos configuraciones separadas.

Grigorev utiliza Terraform, una utilidad de gestión de infraestructura que puede crear (o destruir) configuraciones completas, incluyendo redes, equilibrio de carga, bases de datos y, naturalmente, los propios servidores. Hizo que Claude ejecutara un plan de Terraform para configurar el nuevo sitio web, pero olvidó subir un archivo de estado vital que contiene una descripción completa de la configuración tal como existe en cualquier momento dado.

La cadena de errores fatales

Claude hizo lo que Grigorev quería y creó una configuración para el sitio de Shipping Labs, sin embargo, el operador la detuvo a mitad de camino. Como faltaba el archivo de estado, creó recursos duplicados. Grigorev hizo que Claude identificara los recursos duplicados para corregir la situación, luego subió el archivo de estado, creyendo que tenía la situación controlada.

Desafortunadamente, Grigorev asumió en este punto que el bot continuaría limpiando los recursos duplicados y solo entonces examinaría el archivo de estado para ver cómo se suponía que debía configurarse en primer lugar. Terraform y herramientas similares pueden ser muy implacables, particularmente cuando se combinan con obediencia ciega.

La destrucción total

Como Claude ahora tenía el archivo de estado, lo siguió lógicamente, emitiendo una operación de "destruir" de Terraform en preparación para configurar las cosas correctamente esta vez. Dado que la descripción de la infraestructura incluía el sitio web DataTalks.Club, esto resultó en un borrado completo de la configuración para ambos sitios, incluyendo una base de datos con 2,5 años de registros y instantáneas de base de datos en las que Grigorev había contado como copias de seguridad.

El operador tuvo que contactar con el soporte empresarial de Amazon, que ayudó a restaurar los datos en aproximadamente un día.

Lecciones aprendidas

En el análisis posterior, Grigorev describe algunas medidas que está tomando para evitar incidentes similares en el futuro, incluyendo establecer una prueba periódica para la restauración de bases de datos, aplicar protecciones de eliminación a los permisos de Terraform y AWS, y mover el archivo de estado de Terraform al almacenamiento S3 en lugar de su máquina local.

También admitió que "confió demasiado en el agente de IA para ejecutar comandos de Terraform", y ahora está impidiendo que el agente lo haga, y revisará manualmente cada plan que Claude presente para poder ejecutar él mismo cualquier acción destructiva.

Más allá del error técnico

Es tentador marcar esta historia como otra de "bot tonto que falla", pero es una suposición justa que la mayoría de administradores de sistemas detectarán los problemas básicos con el enfoque de Grigorev, incluyendo otorgar permisos amplios a lo que es efectivamente un subordinado suyo, así como no delimitar permisos en un entorno de producción para empezar.

Quizás la lección más importante es asumir que Claude siquiera tendría el contexto para entender lo que significaba la existencia del segundo sitio web, igual que no lo tendría un administrador de sistemas junior.