Com a popularização a Inteligência Artificial agêntica, muitas histórias têm surgido sobre bots que deram errado. Muitas até vêm acompanhadas de lições de moral sobre o atual estágio de desenvolvimento deles. Outras, porém, refletem erros que podem ser atribuídos à supervisão inadequada.
Esse foi o caso de Alexey Grigorev, que teve a coragem de detalhar como fez com que Claude Code apagasse anos de registros de um site, incluindo os snapshots de recuperação.
Notícias Relacionadas:
- SK Hynix desenvolve memória LPDDR6 com 16 Gb de densidade e velocidades de até 10.7 Gb
- PC550: empresa chinesa YMTC lança seu primeiro SSD PCIe 5.0
- Startup quer usar computador biológico com células cerebrais para reduzir consumo de energia da IA
Tragicômico
A história começa quando Grigorev quis migrar seu site, AI Shipping Labs, para a AWS e compartilhar a mesma infraestrutura do DataTalks.Club. O próprio Claude o desaconselhou, mas Grigorev considerou que não valia a pena o incômodo ou o custo de manter duas configurações separadas.
Gregory usa o Terraform, um utilitário de gerenciamento de infraestrutura que pode criar (ou destruir) configurações inteiras, incluindo redes, balanceamento de carga, bancos de dados e, naturalmente, os próprios servidores.
Ele pediu a Claude que executasse um plano do Terraform para configurar o novo site. O problema é que ele se esqueceu de enviar um arquivo de estado vital que contém uma descrição completa da configuração em qualquer momento.
Claude fez o que Gregory pediu e criou uma configuração para o site da Shipping Labs. No entanto, o operador interrompeu o processo no meio. E, como faltava o arquivo de estado, recursos duplicados foram criados.
Então, Gregory pediu a Claude que identificasse os recursos duplicados para corrigir a situação e, em seguida, carregou o arquivo de estado, acreditando ter resolvido o problema.
Problema
Gregory assumiu que o bot continuaria a limpar os recursos duplicados e, só então, analisaria o arquivo de estado para verificar como a configuração deveria ter sido feita desde o início. O Terraform e ferramentas similares podem ser muito implacáveis, principalmente quando usados com obediência cega.
Porém, como Claude agora tinha o arquivo de estado, o bot seguiu as instruções, executando uma operação “destroy” do Terraform para preparar a configuração correta desta vez.
O problema é que, considerando que a descrição da infraestrutura incluía o site DataTalks.Club, o resultado foi a perda completa da configuração de ambos os sites, incluindo um banco de dados com 2 anos e meio de registros e snapshots do banco de dados que Grigorev considerava backups.
Para resolver o problema, o operador precisou entrar em contato com o suporte da Amazon Business, que ajudou a restaurar os dados em cerca de um dia.
Moral da História
Analisando o ocorrido, Gregory descreveu algumas medidas que está tomando para evitar incidentes semelhantes no futuro. E compartilhou no seu site para que outros pudessem aprender com o seu erro.
Essas medidas incluem a configuração de um período de teste para restauração do banco de dados, a aplicação de proteções de exclusão às permissões do Terraform e da AWS e a migração do arquivo de estado do Terraform para o armazenamento S3 em vez de sua máquina local.
Ele também admitiu que “confiou demais no agente de IA para executar comandos do Terraform” e, agora, está impedindo que o agente faça isso. Ele também está revisando manualmente cada plano apresentado por Claude para que ele mesmo possa executar quaisquer ações destrutivas.
Por fim, provável que a maior lição seja algo que muitos usuários de IAs já sabem: não se pode presumir que elas possuem o contexto para entender o significado da existência, no caso, do segundo site.
Fonte: Alexey on Data.
