- Após uma sequência recente de interrupções de serviço relacionadas ao uso de ferramentas de codificação com IA, a Amazon introduziu um processo de aprovação prévia por engenheiros sêniores para todas as mudanças de código assistidas por IA
- Segundo uma nota interna, a causa das falhas foi atribuída ao "uso de novos recursos de GenAI cujas melhores práticas e salvaguardas ainda não estão totalmente estabelecidas"
- Neste mês, o site da Amazon e o aplicativo de compras ficaram fora do ar por cerca de 6 horas, impedindo clientes de concluir transações, verificar informações da conta e consultar preços, entre outras ações; a causa foi a implantação de um código de software incorreto
- Na AWS, também foram relatados ao menos dois incidentes relacionados a IA, incluindo uma interrupção de 13 horas causada quando o assistente de codificação com IA Kiro apagou e recriou ambientes
- À medida que os riscos operacionais de aplicar ferramentas de codificação com IA em produção se tornam realidade, entrou em vigor uma medida imediata que obriga engenheiros júnior e de nível intermediário a obter a assinatura de um engenheiro sênior para mudanças assistidas por IA
Reuniões internas da Amazon e medidas de resposta
- A divisão de comércio eletrônico da Amazon convocou uma grande reunião de engenharia para analisar as interrupções consecutivas de serviço ocorridas recentemente
- A pauta incluía incidentes relacionados ao uso de ferramentas de codificação com IA
- Nas notas internas de briefing, foi mencionado que houve um aumento de incidentes recentes de "alto risco de grande impacto (high blast radius)", e que "mudanças assistidas por Gen-AI" foram citadas como um fator importante
- Os documentos indicam que "novos casos de uso de GenAI que ainda não estão totalmente estabelecidos" foram apontados como fator contribuinte
- Em um e-mail, o vice-presidente sênior Dave Treadwell afirmou que “a disponibilidade recente do site e da infraestrutura não foi boa”
Casos de falhas relacionados à IA
- O site da Amazon e o aplicativo de compras ficaram indisponíveis por cerca de 6 horas no início deste mês, e a causa foi identificada como a implantação de um código de software incorreto
- Com isso, os clientes não puderam concluir transações, verificar informações da conta nem consultar preços de produtos
- Na AWS, também ocorreu um problema durante o uso do assistente de codificação com IA Kiro
- Em meados de dezembro, o Kiro decidiu “apagar e depois recriar” o ambiente, causando uma interrupção de 13 horas no serviço de calculadora de custos
- A Amazon descreveu esse caso como um "incidente muito limitado, restrito a um único serviço em algumas regiões da China continental"
- A Amazon acrescentou que o segundo incidente "não teve impacto sobre serviços da AWS voltados a clientes"
Novo processo de aprovação e melhorias operacionais
- Treadwell planeja discutir as causas do problema e medidas de melhoria de curto prazo por meio da reunião semanal ‘This Week in Stores Tech (TWiST)’
- A reunião, que antes era opcional, passou a ter participação recomendada para todos os funcionários
- Daqui em diante, mudanças de código assistidas por IA realizadas por engenheiros júnior e de nível intermediário deverão receber aprovação com assinatura de um engenheiro sênior
- A Amazon definiu esta revisão como "parte do curso normal dos negócios" e afirma que busca melhoria contínua
Controvérsia sobre redução de pessoal e aumento de falhas
- O Financial Times informou que alguns engenheiros disseram ter visto um aumento de incidentes de nível ‘Sev2’ (falhas intermediárias que exigem resposta rápida) após a redução de pessoal
- A Amazon realizou várias rodadas de reestruturação nos últimos anos e, somente em janeiro de 2026, cortou 16.000 cargos corporativos
- No entanto, a empresa não concorda com a alegação de que a redução de pessoal seja a causa do aumento das falhas
Direção futura
- A Amazon está tornando regulares as revisões de disponibilidade do site e as análises de desempenho operacional
- A empresa também avança, em paralelo, no uso seguro de ferramentas de codificação com IA e no fortalecimento dos sistemas de prevenção de falhas
- A medida é vista como um caso que volta a destacar a importância dos processos de validação humana em meio à expansão da adoção de IA
6 comentários
Não dá para garantir que será seguro só porque um engenheiro sênior revisou o código gerado por IA
o caso da CrowdStrike não aconteceu por causa de IA
e o Heartbleed também foi um incidente de uma época em que não existia IA
No fim, o ponto central é que querem colocar a responsabilidade em alguém
Isso me lembra o humor ácido daqueles contadores que diziam que não seríamos substituídos, porque legalmente precisa existir um ser humano responsável.
Pois é, então acho que isso vai continuar a menos que coloquem algo como uma assinatura legal nos agentes de IA..
Então o custo de usar Anthropic ou OpenAI teria que ficar astronomicamente alto.
Já que, a cada chamada de API, teria que se pagar um prêmio de seguro.
Hmm... é meio uma viagem, mas tenho a sensação de que não pode acabar surgindo algo parecido com o IAM...
Diziam que o papel do contador é ir para a cadeia, mas como a seguradora não vai presa no lugar dele, no fim das contas...
Comentários do Hacker News
Esta “mandatory meeting” é, na verdade, a reunião operacional semanal de toda a empresa
A adesão só está maior esta semana porque houve um grande incidente operacional na semana passada
Parece que a imprensa está exagerando demais
Também mencionava a política de que “mudanças de código com IA feitas por engenheiros júnior e pleno exigem aprovação de um sênior”
Mesmo sendo uma reunião regular, se houver anúncio de nova política, acho que isso tem valor jornalístico
Os preços não apareciam e nem dava para adicionar itens ao carrinho
Se fosse um concorrente como o Walmart, teria virado notícia, então é estranho
A política de “engenheiros júnior e pleno não podem dar push em código gerado por IA sem aprovação de um sênior”
parece vir da ilusão de que review de sênior resolve tudo
Na prática, para um sênior validar completamente o código, o tempo gasto é parecido com o de escrevê-lo diretamente
Ou seja, review tem valor, mas não transforma código ruim em código bom
No fim, o problema é a falsa ideia de que, se você criar um sistema “idiot proof”, então pode contratar ‘idiotas’
Encontrar bugs é só efeito colateral; o que realmente importa é facilitar testes e reduzir a complexidade do código
Mas esse tipo de trabalho não ajuda na promoção
O ideal é supervisionar desde o momento em que o modelo está trabalhando
Caso contrário, a IA despeja uma bomba de código de baixa qualidade
Se um especialista gastar de 5 a 15 vezes mais tempo corrigindo, ainda dá para aproveitar; senão, a base de código degrada
Especialmente código ruim, que leva o dobro do tempo para entender
Você precisa manter na cabeça o código existente e a nova solução ao mesmo tempo e compará-los, então a carga cognitiva é alta
No fim, parece uma evolução natural rumo a empresas focadas em gerenciar desempenho médio
Dentro da Amazon, a maioria só se preocupa em não ser demitida e em ser promovida
A avaliação dos desenvolvedores é definida por “velocidade de fechamento de tickets”, “quantidade de comentários em PR” e “documentação escrita”
Se você não usar IA, fica para trás na competição
Nessa estrutura, pedidos para “moderar o uso de IA” dificilmente funcionam na prática
Quanto melhor a colaboração de um time, menos discussão costuma haver no PR
Acho que o que realmente faz falta é um processo de self-review
Dar push em código escrito por IA sem revisar é perigoso
Plataformas como o GitHub deveriam adicionar uma opção de “self-review obrigatório”, deixando explícito que o autor revisou o próprio código
Como a UI local é rápida, acabo entendendo melhor o fluxo do projeto
Parece algo óbvio, mas na prática ajuda
A confiança na liderança da Amazon está caindo
Com veteranos saindo, queda na qualidade ligada à IA e incidentes frequentes, a impressão é que a engenharia está se deteriorando
Parece que os tomadores de decisão não entendem gargalos de pipeline
Mesmo que a IA gere diffs 10 vezes mais rápido, se o review for o gargalo, a velocidade total continua a mesma
No resultado final, só aumentam os custos e a incerteza
Se o review de código gerado por IA acontecer na etapa de PR, a vantagem de produtividade desaparece
A IA cria uma funcionalidade em 10 minutos, mas o review humano leva de 10 a 20 vezes mais tempo
O realmente difícil é saber “o que está sendo construído e por quê” e “se foi construído corretamente”
A IA ainda não consegue fazer nenhuma dessas duas coisas
Até que LLMs sejam bons tanto em produção quanto em review, o risco só aumenta
É uma política inviável na prática
Aí viria uma era de deploy logo após os testes
A essência do code review não é detectar erros, e sim sincronizar o time e promover aprendizado
O review serve para compartilhar design e padrões, ensinar juniores e incorporar diferentes perspectivas
Esse processo é justamente o que mais ajuda a reduzir os próprios erros
Porque, se você segue na direção errada no design, depois é difícil voltar
Está se gastando tempo e dinheiro demais na febre da IA
Fico preocupado com o futuro do software de infraestrutura crítica
Se até software de aviação for arrastado por essa tendência, as consequências podem ser catastróficas
A IA tende a ser usada como ferramenta auxiliar para melhorar a qualidade