As Evidências Chegaram: Agentes de IA Estão Quebrando Coisas

Por meses, o debate sobre codificação com IA foi teórico. Otimistas apontavam pesquisas com desenvolvedores e contagem de tokens. Céticos citavam intuição e vibes. Os dois lados argumentavam a partir de projeções.

Essa fase acabou. Agora temos relatórios de incidentes.

A Anthropic Não Consegue Debugar a Anthropic

Comece pelo exemplo mais desconfortável. O Claude.ai, produto principal da empresa que constrói provavelmente o agente de codificação mais capaz do mundo, tinha um bug de UX persistente durante o início de 2026. Prompts digitados desapareciam durante o carregamento da página. Afetava cada cliente pagante, a cada visita.

Ninguém na Anthropic percebeu.

Gergely Orosz, autor do The Pragmatic Engineer, denunciou publicamente no X em março de 2026. Só então foi corrigido. Estamos falando da mesma empresa onde, segundo relatos internos, mais de 80% do código é gerado pelo Claude Code.

O bug não era complexo. Não estava escondido em algum caso extremo obscuro. Era a superfície de interação primária do produto, quebrada, na frente de milhões de usuários. Os humanos revisando o output do Claude perderam o que qualquer cliente frustrado notou imediatamente.

Isso não é argumento contra geração de código por IA. É uma demonstração do que acontece quando a infraestrutura de verificação não escala junto com a capacidade de geração. Como exploramos em Código Barato, Qualidade Cara, o custo de produzir código desabou. O custo de saber se funciona, não.

A Lição de Treze Horas da Amazon

Em dezembro de 2025, o agente Kiro da Amazon recebeu a tarefa de modificar o ambiente do AWS Cost Explorer. O agente deletou o ambiente e o recriou do zero. A indisponibilidade durou treze horas.

Até março de 2026, a divisão de varejo da Amazon havia experimentado quatro incidentes graves, incluindo seis horas de indisponibilidade no shopping. O SVP Dave Treadwell escreveu um memorando interno que deveria ser leitura obrigatória para todo líder de engenharia implantando agentes de IA: “Ferramentas GenAI suplementam ou aceleram instruções de mudança em produção, levando a práticas inseguras.”

A resposta da Amazon foi reveladora. Engenheiros júnior e pleno agora precisam de aprovação sênior para mudanças em produção assistidas por IA. Mil e quinhentos engenheiros protestaram contra um mandato exigindo 80% de uso semanal do Kiro. Fontes internas disseram ao The Pragmatic Engineer que as ferramentas de IA produziram “código de pior qualidade, mas também mais trabalho para todos.”

Releia essa última frase. Não apenas código pior. Mais trabalho. A ferramenta vendida como multiplicador de força virou divisor de força.

A nuance crítica aqui: são falhas de governança, não falhas de ferramenta. O Kiro tinha permissões de operador sem guardrails. Sem humano no loop para operações destrutivas. Sem rollout gradual. O agente recebeu confiança de engenheiro sênior e supervisão de ninguém.

A Armadilha da Medição Se Materializa

Escrevemos sobre distorção de medição por semanas. As evidências agora saíram das pesquisas e entraram na política corporativa.

A Meta tornou o uso de ferramentas de IA parte formal das avaliações de desempenho em 2026. Consumo de tokens é rastreado em calibrações. Se você quer ser promovido na Meta, precisa demonstrar que está usando IA. Se esse uso produz melhores resultados é uma pergunta separada que o sistema de avaliação não faz.

O CEO da Uber, Dara Khosrowshahi, disse à Bloomberg que power users (aqueles com 20 ou mais dias por mês em ferramentas de IA) demonstram “produtividade que nunca vi antes.” A métrica por trás dessa afirmação: contagem de pull requests. Não taxa de defeitos. Não tempo de resolução. Não impacto no cliente. Pull requests.

Como analisamos em A Armadilha da Intensidade de IA, medir intensidade de uso cria incentivos perversos. Quando a métrica é volume de atividade, você obtém mais atividade. Se essa atividade cria valor é uma pergunta que a métrica não consegue responder. E como documentamos em McKinsey Mediu a Coisa Errada, essa distorção de percepção não é ruído. É estrutural.

Khosrowshahi também sugeriu substituir headcount por “agentes e GPUs.” Quando o CEO enquadra IA como substituição de pessoal e vincula uso de IA a avaliações de desempenho, engenheiros recebem um sinal claro: produza output de IA visível ou arrisque seu emprego. Qualidade vira secundária à adoção demonstrável.

A Distorção de Percepção Ganha Replicação

O estudo METR de julho de 2025 permanece como o ensaio controlado mais rigoroso sobre ferramentas de codificação com IA. Desenvolvedores experientes foram 19% mais lentos com assistência de IA. Acreditavam estar 20% mais rápidos. Uma distorção de percepção de 39 pontos.

O METR publicou uma atualização em fevereiro de 2026 com uma coorte mais recente. O resultado: menos 4%, não estatisticamente significativo. O próprio METR chamou os dados originais de “evidência muito fraca.” Mas observe o que mesmo o resultado melhorado mostra. Após meses de desenvolvimento adicional de ferramentas, a melhor medição controlada disponível ainda não consegue demonstrar uma aceleração estatisticamente significativa para desenvolvedores experientes em codebases maduros.

A sensação de velocidade é real. Dax Raad, criador do framework OpenCode, colocou de forma precisa: “A sensação de produtividade é real. A produtividade não é.” Raad acrescentou que codebases bem organizados performam “dramaticamente melhor” com LLMs, e que trabalho sequencial com modelos mais rápidos supera agentes paralelos. Estrutura importa mais que velocidade.

O Veredito dos Desenvolvedores

A pesquisa Stack Overflow 2025 perguntou a profissionais o que mais os frustra sobre ferramentas de codificação com IA. A resposta principal: código que “parece correto mas está sutilmente errado.”

Quase metade dos respondentes disse que debugar código gerado por IA leva mais tempo que escrevê-lo do zero.

Um desenvolvedor capturou a mudança numa metáfora que merece sobreviver à pesquisa: o trabalho mudou “de artesão fazendo uma cadeira perfeita” para “gerente de fábrica da Ikea enviando cadeiras de baixa qualidade.”

A metáfora é precisa porque identifica o que realmente mudou. Não a habilidade do trabalhador. Não a capacidade da ferramenta. A relação entre a pessoa e o output. Quando você escreve código, você o entende porque o entendimento precedeu a escrita. Quando você revisa código gerado, o entendimento precisa ser construído depois do fato, a partir de um artefato que você não projetou.

O Paradoxo de Solow e a Variável Real

Críticos dessa narrativa têm um contraponto válido. A IBM estima US$ 4,5 bilhões em ganhos com IA. A Zapier opera mais de 800 agentes internos. Casos de sucesso existem.

O Paradoxo de Solow também é instrutivo. Robert Solow observou em 1987 que “você pode ver a era dos computadores em todo lugar, menos nas estatísticas de produtividade.” Levou uma década de reestruturação de workflows antes que computadores mostrassem ganhos mensuráveis. Ferramentas de codificação com IA podem seguir a mesma trajetória.

Mas o Paradoxo de Solow tem uma pré-condição que passa despercebida: os ganhos de produtividade chegaram apenas depois que as organizações se reestruturaram ao redor da tecnologia. Não chegaram de parafusar computadores em workflows existentes e mandar usar. A reestruturação foi o trabalho.

Pense em termos mais simples. Ninguém usa chinelos para andar de moto de 1000 cilindradas. Quanto mais potente a máquina, mais proteção você precisa. Agentes de IA são a supermoto; a maioria dos times está pilotando de sandálias. A governança não é fricção — é o equipamento de proteção que permite acelerar com segurança.

Isso aponta para a variável real. Não “IA versus sem IA.” A variável real é IA governada versus IA sem governança. Os outages da Amazon vieram de implantação sem governança. O bug da Anthropic veio de revisão sem governança. A distorção de medição da Meta vem de incentivos sem governança. Cada falha neste artigo rastreia até a mesma raiz: organizações trataram adoção de IA como decisão de compra quando é uma disciplina operacional.

Como Governança Realmente Se Parece

Uma solução é óbvia e subimplantada: portões de qualidade determinísticos.

Análise estática de código — linters, detectores de complexidade ciclomática, scanners de segurança, detectores de código morto — pode restringir código gerado por IA a padrões de qualidade antes que qualquer humano o revise. Essas ferramentas não são novas. Não dependem de IA. São os mesmos instrumentos que governaram código humano por décadas.

A ironia é afiada. Organizações relaxaram portões de qualidade precisamente quando código ficou mais barato de produzir — que é precisamente quando mais precisavam deles. Limites de complexidade ciclomática, análise de dependências, funções de aptidão arquitetural: esses dão aos agentes de IA limites rígidos. O agente escreve o código. O linter diz se o código é bom o suficiente. Nenhum julgamento necessário para as verificações determinísticas. Julgamento humano reservado para as perguntas que realmente precisam dele.

Como descrevemos em O Paradoxo das Operações com Agentes, mais agentes criam mais trabalho operacional, não menos. Portões determinísticos são a única forma de escalar verificação de qualidade sem escalar headcount proporcionalmente.

O Acerto de Contas Não É Sobre IA

Cada evidência neste artigo aponta para a mesma conclusão, e não é “ferramentas de codificação com IA são ruins.”

Ferramentas de codificação com IA são poderosas. Também estão sem governança. As organizações experimentando outages, degradação de qualidade e revolta de desenvolvedores não são as que usam IA. São as que usam IA sem controles, sem infraestrutura de verificação, sem portões de qualidade que acompanhem o volume de código sendo produzido.

As evidências não são mais teóricas. Estão nos relatórios de incidentes da Amazon, no bug tracker da Anthropic, nos templates de avaliação de desempenho da Meta, e nas respostas de pesquisa de centenas de milhares de desenvolvedores no Stack Overflow.

A pergunta nunca foi se IA mudaria como escrevemos software. Vai mudar. A pergunta é se as organizações vão construir a governança para tornar essa mudança produtiva, ou se vão continuar medindo contagem de pull requests enquanto seus ambientes de produção queimam.

---

Fontes

• Gergely Orosz. “Are AI agents actually slowing us down?” The Pragmatic Engineer. Março 2026.
• METR. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Julho 2025, atualizado fevereiro 2026.
• Stack Overflow. “AI Can 10x Developers… in Creating Tech Debt.” Janeiro 2026.
• Computerworld. “Amazon finds out AI programming isn’t all it’s cracked up to be.” Março 2026.
• Codacy Blog. “The Creator of OpenCode Thinks You’re Fooling Yourself About AI Productivity.” 2026.
• WinBuzzer. “Meta to Grade Employees on AI Driven Impact Starting 2026.” Fevereiro 2026.

Victorino Group ajuda organizações de engenharia a construir a infraestrutura de governança que torna ferramentas de codificação com IA produtivas em vez de destrutivas: contato@victorino.com.br | www.victorino.com.br