Um agente de IA destruiu o banco de dados inteiro de um programador — e ele não é o único com uma história de terror
Inteligência Artificial no desenvolvimento de software já não é novidade, mas os acidentes que ela pode causar quando usada sem o devido cuidado estão aparecendo com uma frequência que preocupa — e muito.
E não estamos falando de bugs simples ou de erros fáceis de corrigir.
Estamos falando de bancos de dados de produção apagados, sistemas críticos derrubados e anos de trabalho colocados em risco em questão de minutos — tudo por conta de agentes de IA que receberam autonomia demais, sem as travas certas no lugar.
O caso do engenheiro Alexey Grigorev virou símbolo disso. Enquanto usava o Claude Code, ferramenta popular da Anthropic que ajuda desenvolvedores a escrever e executar código, para atualizar um site, ele viu o agente começar a destruir o ambiente de produção: rede, serviços e, o mais crítico de tudo, o banco de dados com anos de dados de cursos. Uma configuração errada num laptop novo foi o suficiente para o agente confundir o que era real com o que podia ser deletado. Os dados foram recuperados com a ajuda do suporte da AWS, mas a lição ficou — e ela serve pra muita gente além dele. 🚨
Porque o problema não é isolado. Da Amazon às startups, passando por empresas de todos os tamanhos, uma combinação de pressão por produtividade, excesso de confiança nas ferramentas e falta de revisão humana está criando um cenário cada vez mais arriscado no desenvolvimento assistido por IA. E os números que estão surgindo são difíceis de ignorar.
O que realmente aconteceu com o banco de dados de Grigorev
Para entender o tamanho do problema, é importante ir além do resumo. O engenheiro Alexey Grigorev estava realizando uma tarefa aparentemente simples: atualizar configurações de um site usando o Claude Code, um agente de inteligência artificial com capacidade de executar comandos diretamente no terminal, acessar arquivos e interagir com serviços de nuvem de forma autônoma. Esse tipo de ferramenta representa um salto enorme na automação de processos de desenvolvimento, porque permite que tarefas repetitivas e técnicas sejam delegadas para a IA com muito menos intervenção humana do que antes. O problema é exatamente essa autonomia — quando ela não está cercada de limites bem definidos, o risco de dano real cresce de forma exponencial.
O que desencadeou o incidente foi uma configuração ausente no laptop novo que Grigorev estava usando. Sem as variáveis de ambiente corretas apontando para ambientes de teste ou staging, o agente interpretou o ambiente de produção como o alvo legítimo das operações. E foi em frente. Apagou registros de rede, derrubou serviços e, no momento mais crítico, começou a destruir o banco de dados que armazenava anos de informações sobre cursos — um ativo digital de valor inestimável para qualquer plataforma educacional. Tudo isso aconteceu em minutos, sem nenhum aviso claro, sem uma etapa de confirmação obrigatória e sem que houvesse um mecanismo de reversão automática ativado antes da execução.
O próprio Grigorev reconheceu que havia se apoiado demais no agente de IA e que, ao permitir que ele fizesse e executasse todas as mudanças de ponta a ponta, acabou removendo verificações de segurança que teriam impedido a exclusão dos dados.
A recuperação dos dados só foi possível graças ao suporte da AWS, que conseguiu restaurar snapshots anteriores do banco. Mas esse final feliz não é garantido em todos os casos. Como o engenheiro disse à Fortune: assistentes de IA são ótimos e economizam muito tempo, mas ele espera que as pessoas aprendam com os erros que ele cometeu e incorporem salvaguardas nos seus fluxos de trabalho. 💡
Vale lembrar que o Claude Code possui configurações que permitem ao usuário controlar quando e com que frequência o agente precisa pedir autorização antes de executar ações. É possível especificar que determinadas operações exijam permissão explícita. Mas muitos desenvolvedores preferem deixar o agente tomar decisões de forma mais autônoma, em parte porque isso economiza tempo. Até o momento da publicação original da reportagem, a Anthropic não havia respondido a um pedido de comentário sobre o caso.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
Amazon também enfrentou problemas com código gerado por IA
Se o caso de Grigorev fosse um incidente isolado, talvez pudesse ser tratado como curiosidade. Mas a realidade é que até mesmo as maiores empresas de tecnologia do mundo estão enfrentando situações semelhantes. Na semana anterior à publicação original da reportagem da Fortune, a Amazon convocou uma reunião de análise aprofundada — um chamado deep dive — após uma série de interrupções afetar seu site e aplicativo. De acordo com reportagens de veículos como Financial Times e CNBC, pelo menos uma das falhas de sistema envolveu mudanças assistidas por IA.
Um porta-voz da Amazon disse à Fortune que a reunião era parte das operações regulares semanais da empresa. A companhia também afirmou publicamente que apenas um dos incidentes envolveu IA, e que a causa real não estava relacionada à inteligência artificial em si — o problema teria sido que os sistemas da empresa permitiram que um erro de engenharia humana tivesse um impacto mais amplo do que deveria.
No entanto, documentos internos da Amazon visualizados tanto pela CNBC quanto pelo Financial Times originalmente citavam mudanças assistidas por IA generativa como fator em uma tendência de incidentes. A referência ao papel da IA nas interrupções foi posteriormente removida do documento antes da reunião, segundo a CNBC. De acordo com o Financial Times, uma interrupção nos serviços da Amazon Web Services em dezembro ocorreu depois que engenheiros permitiram que o Kiro, ferramenta de codificação por IA da própria Amazon, fizesse alterações — algo que a empresa depois classificou como erro do usuário.
Esse tipo de situação é particularmente revelador porque mostra que mesmo organizações com recursos praticamente ilimitados de engenharia e infraestrutura não estão imunes aos riscos de dar autonomia demais a agentes de IA em ambientes de produção. Se a Amazon enfrenta esse tipo de problema, imagine o que pode acontecer em empresas menores, com menos camadas de revisão e menos capacidade de recuperação após um incidente grave.
A dependência excessiva de ferramentas de IA está mudando a engenharia de software
Em toda a indústria, engenheiros relatam que a dependência de assistentes de IA para escrever e implantar código está mudando rapidamente a natureza dos trabalhos de desenvolvimento de software — e introduzindo novos riscos que poucos estavam preparados para enfrentar.
Um engenheiro da Amazon, que pediu para não ser identificado, disse à Fortune que as pessoas estão se tornando tão dependentes da IA que essencialmente param de revisar o código por completo. Segundo ele, profissionais tecnicamente qualificados estão migrando para um papel mais de revisão do que de codificação ativa, com a IA cuidando de boa parte da implementação real. Embora essas ferramentas permitam uma entrega mais rápida de funcionalidades, elas também criam o que alguns chamam de ruído de produção — código que é entregue rapidamente, mas que nem sempre é necessário ou totalmente testado. Em alguns casos, esse código pode até afetar sistemas críticos.
David Loker, VP de IA na CodeRabbit, explicou que as consequências nem sempre são tão visíveis quanto uma interrupção de serviço. Em uma ocasião, ele contou que um assistente de IA gerou código que parecia perfeitamente válido, mas que foi construído com base em suposições erradas sobre o sistema subjacente — código que poderia ter passado numa revisão rápida, mas que teria derrubado o banco de dados em produção se tivesse sido implantado.
Há ainda outro efeito colateral preocupante. Como a codificação assistida por IA reduz o conhecimento técnico necessário para executar certas tarefas de desenvolvimento, engenheiros relatam que empresas estão terceirizando trabalhos normalmente feitos por profissionais seniores para juniores ou funcionários menos técnicos — apenas para descobrir que a baixa qualidade do resultado gera mais trabalho do que economia.
Um engenheiro baseado em Londres, que trabalha em uma empresa de software corporativo e pediu anonimato, descreveu a situação assim: muito do que foi construído era de qualidade ruim, quebrava frequentemente e acabava sendo mais um fardo do que um benefício. O tempo economizado ao colocar pessoas menos experientes para escrever o código era anulado pela necessidade de pagar alguém muito mais caro — um sênior ou principal — para ir lá consertar quando tudo quebrava.
O imposto da correção recai sobre os mais experientes
Dados mais amplos sugerem que o fardo de revisar e consertar trabalhos assistidos por IA está caindo de forma desproporcional sobre os engenheiros mais experientes. Embora profissionais seniores tenham habilidades para identificar erros lógicos ou falhas de segurança que um júnior poderia deixar passar — o que permite que eles entreguem mais rápido —, eles também estão pagando um crescente imposto da correção.
Uma pesquisa da Fastly de julho de 2025 revelou que engenheiros seniores publicam quase 2,5 vezes mais código gerado por IA do que juniores, justamente porque são melhores em identificar erros antes que eles se acumulem. Mas quase 30% dos seniores disseram que corrigir o resultado da IA consumia a maior parte do tempo que haviam economizado, em comparação com 17% dos desenvolvedores juniores. Os juniores frequentemente sentem que obtiveram ganhos de produtividade maiores porque ainda não conseguem enxergar toda a dívida técnica ou as vulnerabilidades latentes que suas alterações assistidas por IA estão silenciosamente adicionando ao sistema. 🔍
O paradoxo da produtividade e o FOMO da alta liderança
Parte do problema vem de cima. Engenheiros de laboratórios de IA líderes do mercado têm divulgado surtos de produtividade que teriam parecido implausíveis há apenas alguns anos — e organizações maiores, de diversos setores, querem replicar esses ganhos a qualquer custo.
Por exemplo, Boris Cherny, chefe do Claude Code na Anthropic, já disse que não escreve uma linha de código há meses, confiando inteiramente no modelo de IA da empresa para gerar tudo. Dentro da Anthropic como um todo, a empresa informou à Fortune que entre 70% e 90% de todo o seu código já é gerado por IA. No Spotify, o co-CEO Gustav Söderströn revelou que os melhores desenvolvedores da empresa não escreviam uma única linha de código desde dezembro e que mais de 50 novas funcionalidades foram lançadas em 2025 usando fluxos de trabalho assistidos por IA.
Mas, como os problemas recentes da Amazon demonstram, os ganhos de produtividade mais visíveis em laboratórios de IA e startups ágeis podem ser muito mais difíceis de replicar em grandes empresas com sistemas legados e bases de código complexas. Onde equipes menores podem se mover rápido e absorver erros, empresas como a Amazon operam infraestruturas onde uma única implantação ruim pode afetar milhões de clientes.
Um relatório de setembro da Bain & Company concluiu que, embora a programação tenha sido uma das primeiras áreas a adotar IA generativa, as economias reais foram modestas e os resultados não corresponderam ao entusiasmo. Enquanto isso, uma pesquisa da empresa de segurança Apiiro mostrou que desenvolvedores usando IA introduziram aproximadamente dez vezes mais problemas de segurança do que aqueles que não usavam.
Os modelos de IA cometem erros sutis que se amplificam em escala
Como o pesquisador de IA Andrej Karpathy já observou, modelos de IA podem cometer erros conceituais sutis, complicar excessivamente o código e deixar código não utilizado para trás — problemas que são gerenciáveis em um ambiente controlado, mas muito mais difíceis de identificar e corrigir em escala. Um relatório de dezembro da CodeRabbit, que analisou 470 pull requests de código aberto no GitHub, descobriu que código escrito por IA continha aproximadamente 1,7 vezes mais problemas no geral do que código escrito por humanos.
Organizações maiores tendem a ter mais stakeholders, mais camadas de revisão e mais dependências — um ambiente onde código gerado por IA tem mais chances de introduzir falhas inesperadas.
Como Loker explicou, vai levar mais tempo para organizações grandes como AWS ou Nvidia implementarem isso com segurança, porque elas têm muito código legado. Há menos documentação, menos capacidade de busca para a IA se orientar, e por isso é mais difícil encontrar o contexto correto. O resultado inevitável é a introdução de problemas.
As métricas de sucesso estão contando apenas metade da história
Outro aspecto fundamental que a reportagem original levanta é como as próprias empresas medem o sucesso da codificação por IA. Segundo Loker, é muito fácil medir o aumento de produtividade bruta. O que não é fácil medir é a causalidade do que acontece depois. As métricas tradicionalmente usadas para avaliar a produtividade de desenvolvedores — funcionalidades entregues, código commitado — parecem fortes quando IA está envolvida, mas não capturam as consequências downstream como bugs, rollbacks ou o tempo gasto limpando a bagunça.
Existe também a questão dos benchmarks usados para medir a capacidade de codificação da IA. Um estudo recente do METR, uma organização de avaliação de IA, descobriu que metade das soluções de codificação por IA que receberam nota de aprovação em um teste proeminente da indústria — que é ele próprio avaliado por um modelo de IA — teriam sido rejeitadas por revisores humanos por qualidade inadequada.
Toby Ord, pesquisador sênior da Oxford Martin AI Governance Initiative, afirmou que as estimativas atuais da capacidade de codificação da IA estão de fato superestimando as coisas, e talvez por um fator significativo.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
A dívida técnica está se acumulando numa velocidade sem precedentes
Empresas que adotam IA em escala também correm o risco de acumular o que engenheiros chamam de dívida técnica — código que funciona no curto prazo, mas que se torna cada vez mais custoso de manter ao longo do tempo. Como Loker descreveu de forma bastante direta: a produção de dívida técnica usando IA está acontecendo num ritmo que ele nem consegue dimensionar. A estimativa dele é de que seja de três a quatro vezes maior do que era anteriormente.
Esse é talvez o risco mais silencioso e mais perigoso de todos. Enquanto uma interrupção de serviço é visível, imediata e demanda ação urgente, a dívida técnica se acumula lentamente, sem alarmes, até que o sistema se torna tão frágil que qualquer pequena mudança pode desencadear uma cascata de falhas. Para grandes empresas, esse tipo de degradação silenciosa pode representar um custo que supera em muito as economias iniciais obtidas com a adoção de ferramentas de IA.
Segurança de dados não é opcional quando IA entra no jogo
Um dos pontos mais importantes que o caso Grigorev coloca na mesa é a questão da segurança de dados em ambientes onde agentes de IA têm acesso operacional real. Tradicionalmente, a segurança no desenvolvimento de software é pensada em termos de proteção contra ataques externos — invasões, vazamentos, exploração de vulnerabilidades por atores mal-intencionados. Mas um agente de IA com permissões amplas representa um vetor de risco completamente diferente: ele não precisa ser hackeado para causar dano. Ele pode causar dano por design, simplesmente executando as tarefas para as quais foi instruído, em um contexto que ele não interpretou corretamente.
Práticas básicas de segurança que deveriam ser inegociáveis incluem:
- Separação rigorosa entre ambientes de desenvolvimento, staging e produção, com variáveis de ambiente explícitas e verificadas antes de qualquer execução automatizada
- Aplicação do princípio do menor privilégio para qualquer agente de IA com acesso a recursos críticos
- Backups automáticos e frequentes, com testes regulares de restauração
- Etapas obrigatórias de confirmação humana antes de ações destrutivas como exclusão de dados ou modificação de infraestrutura
- Documentação clara e acessível sobre o que cada agente está autorizado a fazer — e o que não está
Essas não são medidas novas — são boas práticas de engenharia que existem há décadas, mas que precisam ser reafirmadas e adaptadas para o contexto dos novos agentes autônomos. A segurança de dados em um ambiente de IA não é um complemento à estratégia de desenvolvimento: ela é parte fundamental da estratégia. 🔐
O que os erros de hoje estão ensinando para o amanhã
Por mais que incidentes como o de Grigorev e as interrupções na Amazon sejam preocupantes, eles também têm um papel importante: estão ajudando a construir, na prática, um conjunto de lições que a indústria precisava aprender de alguma forma. A discussão que surgiu depois que esses casos vieram a público gerou um debate rico sobre as responsabilidades de quem desenvolve ferramentas de IA, de quem as adota e de quem define as políticas de uso dentro das organizações.
Entre as principais lições que estão emergindo dessas situações, algumas se destacam com clareza:
- Autonomia e responsabilidade precisam andar juntas — quanto mais independente for um agente de IA, mais robusto precisa ser o sistema de supervisão e reversão ao redor dele
- A configuração do ambiente é tão crítica quanto o código em si — uma variável de ambiente faltando pode ser tão destrutiva quanto um bug grave no sistema
- A comunicação dentro das equipes sobre o que os agentes de IA estão autorizados a fazer precisa ser explícita, documentada e revisada regularmente
- Métricas de produtividade precisam incluir indicadores de qualidade downstream, como taxa de bugs, rollbacks e tempo gasto em correções
- Engenheiros seniores não podem ser reduzidos a revisores de código gerado por IA — sua experiência precisa informar a governança do uso dessas ferramentas, não apenas a correção dos seus erros
Olhando para frente, o que o mercado vai exigir — e o que as melhores equipes já estão construindo — é uma abordagem madura para o uso de inteligência artificial no desenvolvimento de software. Uma abordagem que celebra os ganhos reais de produtividade que essas ferramentas oferecem, mas que trata os riscos com a seriedade que eles merecem. Isso significa investir em treinamento, em processos, em testes e em uma cultura onde admitir que algo deu errado é o ponto de partida para melhorar — não um motivo de vergonha.
A IA vai continuar evoluindo, as ferramentas vão ficar mais poderosas e a tentação de dar mais autonomia a elas vai crescer. A questão não é se mais incidentes vão acontecer, mas se as equipes estarão preparadas para contê-los antes que o estrago seja irreversível. 🚀
