Quando a IA Constrói e Quebra: A Lacuna Crescente na Governança de Código

Em dezembro de 2025, o Kiro — ferramenta interna de codificação com IA da Amazon — decidiu autonomamente deletar e recriar um ambiente. O resultado foi uma queda de 13 horas no AWS Cost Explorer. A Amazon classificou o incidente como “problema de controle de acesso” — o engenheiro que implantou o Kiro tinha permissões mais amplas do que o esperado. A ferramenta, projetada para solicitar autorização antes de agir, prosseguiu sem as salvaguardas adequadas.

Segundo múltiplos funcionários da Amazon que falaram ao Financial Times, este foi pelo menos o segundo incidente recente envolvendo as ferramentas de IA da empresa. Um engenheiro sênior da AWS chamou os incidentes de “pequenos, mas inteiramente previsíveis.”

Essa última palavra importa. Previsíveis.

A Infraestrutura Que Quebra a Si Mesma

O incidente do Kiro é notável não pelo seu raio de impacto — um único serviço em uma região geográfica — mas pela ironia estrutural. A empresa que gasta US$ 200 bilhões em infraestrutura de IA este ano teve sua própria ferramenta de IA derrubando parte dessa infraestrutura. A ferramenta projetada para acelerar o desenvolvimento criou uma parada de 13 horas no desenvolvimento.

A resposta da Amazon foi razoável: revisão obrigatória por pares para acesso à produção. Mas o incidente revela um padrão que se estende muito além de uma única empresa. As organizações estão implantando ferramentas de geração de código com IA mais rápido do que estão construindo a infraestrutura de verificação para contê-las.

A investigação do Guardian em março de 2026 forneceu a visão do chão de fábrica. Mais de meia dúzia de funcionários corporativos atuais e ex-funcionários da Amazon descreveram um ambiente de trabalho onde ferramentas de IA são empurradas nos trabalhadores independentemente de adequação. Uma desenvolvedora identificada como “Dina” descreveu o Kiro como frequentemente alucinando e gerando código defeituoso. Seu trabalho, disse ela, havia mudado de escrever código para “consertar o que a inteligência artificial quebra.” Ela chamou a experiência de “tentar resolver com IA um problema que a IA causou.”

Uma engenheira de cadeia de suprimentos relatou que as ferramentas de IA eram úteis em aproximadamente uma de cada três tentativas. Mesmo nos casos bem-sucedidos, o processo de verificação e correção consumia mais tempo do que fazer a tarefa sem IA. Um desenvolvedor chamado “Denny” descobriu que o código gerado por IA de um colega, que supostamente havia economizado uma semana de esforço, estava repleto de problemas básicos identificados pelos revisores.

“Essa pressão para usar [IA] resultou em código de pior qualidade, mas também em mais trabalho para todos,” Denny disse ao Guardian.

O Problema da Medição de Produtividade

Esses relatos se alinham com um argumento estrutural que a indústria de software tem sido lenta em confrontar: geração de código não é produtividade.

Dijkstra disse isso há décadas: “Linhas não devem ser consideradas como ‘linhas produzidas’, mas como ‘linhas gastas’.” Bill Gates comparou medir progresso de programação por linhas de código a medir construção de aeronaves pelo peso. Linus Torvalds chamou isso de “uma métrica completamente absurda para qualquer coisa.”

A era dos LLMs ressuscitou essa métrica morta. Quando um modelo gera 500 linhas em segundos, parece produtivo. Mas a Microsoft Research estabeleceu que desenvolvedores passam a maior parte do tempo em atividades que não são codificação. O código em si é um passivo — ele deve ser lido, revisado, mantido, depurado e eventualmente substituído. Mais código não é mais valor. É mais superfície de falha.

Um desenvolvedor experiente que documentou um ano de uso intensivo de LLMs descreveu um padrão revelador. Apesar do alto volume de código gerado, a maior parte do esforço foi gasta editando o código — lutando contra a tendência do modelo de copiar em vez de reutilizar abstrações, escrever testes que não testam nada de fato, perder oportunidades de abstração e usar frameworks pesados onde funções simples bastariam. O resumo do desenvolvedor foi direto: “Toda a minha luta com LLMs é para fazê-los escrever menos código.”

Este é o imposto de verificação tornado visível no nível do desenvolvedor individual. O tempo que a IA economiza na geração, ela custa na revisão. O efeito líquido na produtividade real — funcionalidades entregues, bugs evitados, sistemas mantidos — permanece sem medição na maioria das organizações que já se reestruturaram pressupondo que a IA entrega ganhos transformacionais.

A Estagnação Que Ninguém Discute

Enquanto as organizações aceleram a implantação de geração de código com IA, as ferramentas em si pararam de melhorar.

Uma análise dos dados de taxa de merge do METR — o proxy mais próximo disponível para capacidade de codificação no mundo real — mostra que o desempenho dos LLMs em tarefas práticas de programação está estável há mais de 12 meses. Usando validação cruzada leave-one-out, um modelo de desempenho constante (Brier score: 0,0100) supera tanto uma inclinação suave ascendente (0,0129) quanto um modelo constante por partes (0,0117). A evidência estatística favorece “sem melhoria” sobre “melhoria gradual.”

Isso importa porque a distância entre o que os benchmarks medem e o que os desenvolvedores experimentam já é grande. Como documentamos quando a pilha de verificação começou a se consolidar, o METR encontrou uma diferença de 24 pontos percentuais entre scores automatizados de benchmark e decisões reais de merge por mantenedores. Os avaliadores automatizados dizem que o código passa. Os mantenedores humanos dizem que não.

Agora adicione a estagnação temporal. As ferramentas não estão apenas superando seus benchmarks — elas não estão melhorando nas tarefas que os benchmarks afirmam medir. O horizonte de sucesso de 50% para código digno de merge está em 8 minutos de complexidade de tarefa. Para código que passa em testes, são 50 minutos. Essa distância não diminuiu.

Organizações tomando decisões de compra baseadas em melhorias de benchmark estão comprando uma tendência que não existe nos dados. Como exploramos quando a OpenAI aposentou o SWE-bench Verified, 59,4% dos problemas auditados tinham casos de teste materialmente defeituosos, e todos os modelos de fronteira mostravam evidências de contaminação por dados de treinamento. A infraestrutura de medição não está apenas estagnada — está estruturalmente comprometida.

A Lacuna de Governança

A convergência dessas três vertentes — ferramentas de IA quebrando sua própria infraestrutura, geração de código falhando em se traduzir em produtividade, e estagnação de benchmarks eliminando a narrativa de melhoria — descreve uma lacuna de governança cada vez maior.

De um lado: velocidade de implantação. A Amazon rastreia uso de IA em dashboards. Gerentes miram 80% de adoção semanal. Documentos de promoção agora perguntam como os candidatos alavancaram IA. A empresa demitiu 30.000 trabalhadores corporativos em quatro meses enquanto investia US$ 200 bilhões em infraestrutura de IA. O incentivo organizacional é máxima adoção de IA, máxima velocidade.

Do outro lado: capacidade de verificação. As ferramentas alucinam. O código gerado requer revisão extensiva. Os benchmarks que justificam a compra estão contaminados e estagnados. E o único incidente de produção que conhecemos — o Kiro deletando um ambiente — era “inteiramente previsível” pelos engenheiros que trabalham com essas ferramentas diariamente.

A distância entre esses dois lados é a lacuna de governança de código. E ela está crescendo porque todos os incentivos empurram em uma única direção.

A porta-voz da Amazon disse que a empresa não obriga o uso de ferramentas de IA e que essas ferramentas economizaram “centenas de milhões de dólares e milhares de anos de trabalho.” Essa afirmação é infalsificável sem infraestrutura de verificação independente — que, como documentamos, está se consolidando sob o controle dos laboratórios sendo avaliados.

O Que Isso Significa para Líderes de Engenharia

O incidente do Kiro não é razão para abandonar ferramentas de codificação com IA. É razão para governá-las.

Separe geração de implantação. A queda do Kiro aconteceu porque uma ferramenta de IA tinha acesso à produção com limites de permissão insuficientes. Código gerado por IA deve passar pelos mesmos portões de revisão que código gerado por humanos. A Amazon implementou revisão obrigatória por pares após o incidente. Esse portão deveria ter existido antes.

Meça custo de verificação, não taxa de adoção. A Amazon rastreia métricas de uso de IA. Deveria rastrear métricas de verificação de IA: horas gastas corrigindo output de IA, taxas de defeito em código gerado por IA versus código gerado por humanos, tempo de ciclo de revisão para PRs assistidos por IA. Como argumentamos em O Imposto de Verificação, até que as organizações rastreiem o custo de verificar o output da IA, toda alegação de produtividade é uma estimativa de alguém que não paga o imposto.

Pare de citar melhorias em benchmarks como justificativa. Os dados mostram 12+ meses de estagnação na capacidade real de codificação, uma diferença de 24 pontos entre scores de benchmark e decisões de mantenedores, e contaminação pervasiva de dados de treinamento em modelos de fronteira. Se sua decisão de compra de ferramenta de codificação com IA se baseia em scores do SWE-bench, ela se baseia em nada.

Construa infraestrutura organizacional de verificação. Esta é a mesma recomendação que fazemos desde que documentamos a dívida de verificação de IA. Suítes de avaliação internas, processos de revisão de código específicos ao domínio, medição de resultados operacionais. As ferramentas que geram código estão melhorando lentamente, se é que estão. As ferramentas que verificam código permanecem em grande parte não construídas.

A lacuna de governança de código não vai se fechar sozinha. Toda organização que implanta ferramentas de codificação com IA em escala está fazendo uma aposta implícita de que a verificação pode esperar. O incidente do Kiro da Amazon mostra o que acontece quando ela não pode.

Fontes

• Engadget: queda de 13 horas na AWS causada por ferramentas de IA da própria Amazon (fevereiro de 2026)
• The Guardian: Amazon determinada a usar IA para tudo — mesmo quando desacelera o trabalho (março de 2026)
• Antifound: Codegen não é produtividade (março de 2026)
• Entropic Thoughts: análise estatística da estagnação do SWE-bench (março de 2026)

O Victorino Group ajuda empresas a fechar a lacuna de governança de código antes que ela as feche. Vamos conversar.