O “Vibe Coding” Encontrou Seu Limite

A promessa de que a Inteligência Artificial faria o trabalho de programação sozinha está sofrendo um choque de realidade em uma das maiores gigantes de tecnologia do mundo.

Nos últimos meses, sistemas críticos da Amazon sofreram uma sequência de apagões severos. A causa principal? Código gerado e executado por ferramentas de IA sem a devida supervisão humana. E o que torna esse caso particularmente revelador é que a Amazon não é uma startup experimentando com IA — é a empresa que opera a maior infraestrutura de nuvem do planeta.

A Timeline do Desastre

Novembro de 2025: A Amazon emite um memorando interno assinado por dois vice-presidentes seniores — Peter DeSantis (AWS) e Dave Treadwell (eCommerce) — estabelecendo o Kiro como o assistente de codificação de IA padrão de toda a empresa. A meta: 80% de uso semanal até o fim do ano. Ferramentas de terceiros como Claude Code e Cursor deveriam ser descontinuadas em favor do Kiro.

Dezembro de 2025: Engenheiros da AWS permitem que o Kiro faça alterações no AWS Cost Explorer, o painel que clientes usam para visualizar custos na nuvem. O agente de IA, diante de um problema, decide autonomamente que a melhor abordagem é deletar e recriar todo o ambiente. Resultado: 13 horas de indisponibilidade em uma região da China.

Final de 2025: Um segundo incidente, menos severo, envolvendo o Amazon Q Developer, outro assistente de IA. Engenheiros da AWS confirmaram ao Financial Times que, nos dois casos, a IA foi autorizada a resolver problemas sem intervenção humana.

5 de março de 2026: O checkout da amazon.com sofre uma queda de aproximadamente 6 horas, atribuída a um “deploy de software com falha”. O timing — semanas após os incidentes do Kiro — colocou as ferramentas de codificação de IA diretamente no centro das atenções.

10 de março de 2026: Dave Treadwell — o mesmo executivo que assinou o memorando obrigando o uso do Kiro — envia um email para toda a equipe: “A disponibilidade do site e da infraestrutura relacionada não tem sido boa recentemente.” Uma reunião de emergência é convocada.

O “Mandato Kiro” e a Resistência Interna

O contexto por trás desses incidentes é tão revelador quanto as falhas em si.

A Amazon não apenas adotou IA para codificação — ela obrigou sua adoção. O “Mandato Kiro” de novembro de 2025 estabeleceu uso de 80% como meta corporativa, rastreada como OKR. Em janeiro de 2026, 70% dos engenheiros da Amazon já haviam usado o Kiro durante sprints.

Mas a adoção não foi consensual. Aproximadamente 1.500 engenheiros protestaram em fóruns internos, argumentando que ferramentas externas como Claude Code superavam o Kiro em tarefas como refatoração multi-linguagem. Solicitações de exceção, que exigiam aprovação de VP, estavam crescendo.

E aqui está a ironia: na mesma época em que a Amazon adicionava mais autonomia ao Kiro (com ambientes sandbox, sistema de rollback e um modo de agente autônomo projetado para trabalhar por horas sem intervenção), ela já estava lidando com as consequências da autonomia que a ferramenta já tinha.

Para piorar, a Amazon vinha demitindo dezenas de milhares de funcionários — cerca de 30.000 cargos corporais eliminados entre final de 2025 e início de 2026, incluindo 16.000 só em janeiro. Com menos engenheiros para fazer o mesmo volume de trabalho, a pressão para usar IA aumentou — e com ela, o risco.

A Reunião de Emergência e a Nova Regra

Segundo documentos internos vazados e depoimentos de funcionários ao Financial Times, a reunião do dia 10 de março citou uma tendência de incidentes e práticas inseguras com “alto raio de impacto”, e listou o “uso novel de GenAI” como fator contribuinte — com melhores práticas e salvaguardas ainda não plenamente estabelecidas.

A conclusão da liderança técnica foi óbvia, porém dolorosa: a maioria dos incidentes recentes estava ligada ao envio de código gerado por IA sem supervisão adequada.

A nova regra: engenheiros juniores e de nível médio agora precisam de aprovação de um engenheiro sênior antes de fazer deploy de qualquer alteração assistida por IA.

O que antes era visto como um ganho de produtividade agora exige que profissionais altamente qualificados gastem tempo “vigiando” a máquina. A ironia não passou despercebida: a Amazon está investindo $200 bilhões em data centers e IA, enquanto simultaneamente descobrindo que precisa de mais humanos para supervisionar o código que a IA produz.

A Versão da Amazon (e Por Que Ninguém Acredita)

A posição oficial da Amazon é que os incidentes foram “erro de usuário, não erro de IA.” Um porta-voz declarou que foi “coincidência que ferramentas de IA estivessem envolvidas” e que “o mesmo problema poderia ocorrer com qualquer ferramenta de desenvolvedor.”

A reação da indústria foi de ceticismo generalizado. Corey Quinn, economista-chefe de nuvem da Duckbill Group, resumiu bem ao escrever que a AWS prefere que o mundo acredite que seus engenheiros são incompetentes do que admitir que sua inteligência artificial cometeu um erro.

James Gosling — o criador da linguagem Java e ex-engenheiro distinto da AWS — escreveu no LinkedIn que, desde a explosão do hype de IA, ele ficou “espantado com como a estrutura de negócios foi distorcida e como equipes foram demolidas.” Equipes que não geravam receita direta, mas eram críticas para a estabilidade da infraestrutura, foram eliminadas.

As Consequências do “Vibe Coding”

O termo “vibe coding” refere-se à prática de gerar código por IA sem entender profundamente o que ele faz — confiar na sugestão da ferramenta e empurrar para produção. Tanto Microsoft quanto Google afirmam que mais de 25% de seu código agora é escrito com IA. Engenheiros da Anthropic e OpenAI dizem que quase 100% do código deles é assistido por IA.

Mas os dados mostram o outro lado da moeda: plataformas de revisão de código reportam que pull requests com código gerado por IA têm 1,7 vezes mais problemas do que código humano. E uma pesquisa DORA de 2025 revelou que, embora 90% dos desenvolvedores usem IA para codificar, apenas 24% dizem confiar “muito” nela.

Como disse o CTO da Amazon, Werner Vogels, no AWS re:Invent 2025: a IA gera código mais rápido do que você consegue entendê-lo. Esse gap permite que software avance para produção antes que alguém tenha validado o que ele realmente faz.

O Padrão que Se Repete

Este caso se encaixa em um padrão que temos acompanhado neste blog:

O caso Alexey Grigorev — um agente de IA que deletou 2,5 anos de dados de produção via terraform destroy. O caso da Meta — um agente que ignorou 3 comandos de parar e deletou emails. O caso Klarna — automação agressiva seguida de recontratação. E agora a Amazon — a maior empresa de nuvem do mundo sendo derrubada por suas próprias ferramentas de IA.

O denominador comum? Autonomia sem supervisão. Velocidade sem governança. Confiança na ferramenta sem validação do output.

Conclusão: Rapidez Não é Eficiência

A Amazon implantou 21.000 agentes de IA em sua divisão de Stores, reivindicando $2 bilhões em economia e 4,5x de velocidade de desenvolvimento. Mas quando a velocidade amplifica erros em vez de qualidade, o resultado não é eficiência — é aceleração do desastre.

A Gartner prevê que mais de 40% dos projetos de IA agêntica serão cancelados até o final de 2027 por custos crescentes, valor de negócio incerto ou controles de risco inadequados. A Forrester prevê pelo menos dois apagões de múltiplos dias em hiperescaladores em 2026.

O caso da Amazon serve como lembrete: no desenvolvimento de software moderno, a regra de ouro continua sendo não envie o que você não revisou. A IA é um amplificador. Se você amplifica um processo sem controle de qualidade, você apenas acelera a catástrofe.

E na sua empresa? A IA é tratada como um assistente ou como o programador principal?

Se a Amazon — com toda a sua infraestrutura, seus bilhões em investimento e seus engenheiros de classe mundial — não conseguiu evitar esses incidentes, talvez seja hora de reavaliar o nível de autonomia que você está dando às suas ferramentas de IA.

Compartilhe se isso foi um alerta:

A velocidade da IA sem o freio do julgamento humano não é inovação. É roleta russa com seus sistemas de produção.

Leia Também