Quatro Modos de Falha de Agentes de IA Sem Governança

Mario Zechner é desenvolvedor. Não é analista, não é consultor, não vende framework. Ele usa agentes de IA para escrever código todos os dias e publicou uma análise do que observou quebrando nos seus projetos. O texto é curto, direto e incômodo.

Incômodo porque os quatro modos de falha que ele identifica não são bugs. São propriedades estruturais de como agentes de código operam quando ninguém desenha controles ao redor deles.

Modo 1: Composição de Erros

Zechner coloca de forma simples: “Um agente não tem capacidade de aprendizado. Vai continuar cometendo os mesmos erros repetidamente.”

Um humano comete um erro, leva uma bronca no code review, internaliza a correção. Na próxima vez, evita o mesmo padrão. O agente não faz isso. Cada sessão começa do zero. O mesmo erro aparece na segunda, na quinta, na vigésima execução.

Isoladamente, cada erro é pequeno. O problema é a composição. Dez decisões marginalmente ruins, acumuladas ao longo de semanas, produzem uma codebase que ninguém planejou. Como documentamos em A Crise da Manutenção, benchmarks pontuais capturam competência instantânea. Não capturam degradação cumulativa. O SWE-CI mostrou que mais de 75% das correções de agentes introduzem regressões ao longo do tempo.

O controle que falta: memória persistente entre sessões. Regras de projeto documentadas em arquivos que o agente lê antes de cada execução. Linters configurados com os padrões específicos do time. O agente não aprende, então você precisa ensinar a cada sessão. Quem não faz isso está confiando que um processo sem memória vai produzir resultados consistentes.

Modo 2: Remoção de Gargalos

“Você se removeu do loop, então nem sabe que todos os pequenos erros formaram um monstro de codebase.”

A promessa dos agentes autônomos é justamente remover o humano do caminho. Menos revisão, menos espera, mais throughput. Zechner aponta o óbvio que ninguém quer ouvir: o gargalo humano era também o filtro de qualidade.

Quando o desenvolvedor sênior revisava cada PR, o processo era lento. Também era seguro. Remover essa etapa sem substituí-la por outro mecanismo de verificação é o equivalente a tirar o freio de um carro para que ele ande mais rápido.

A Amazon aprendeu isso da pior forma. Quatro incidentes graves em produção, incluindo treze horas de indisponibilidade causada pelo agente Kiro. O memorando interno do SVP Dave Treadwell foi explícito: ferramentas GenAI levaram a “práticas inseguras.” O resultado foi restaurar a revisão humana para engenheiros júnior e pleno. Como analisamos em As Evidências Chegaram, o problema não foram as ferramentas. Foi a ausência de guardrails.

O controle que falta: revisão obrigatória antes do merge, com critérios explícitos. Não basta “alguém olhou.” É preciso definir o que o revisor verifica: conformidade arquitetural, cobertura de testes, impacto em dependências. A revisão humana é lenta por design. Esse é o ponto.

Modo 3: Acumulação de Complexidade

Agentes tomam decisões localmente ótimas. Dado o contexto de uma tarefa específica, a solução gerada costuma funcionar. O teste passa. O PR vai adiante.

O problema aparece quando você olha o sistema inteiro. Cada decisão local adicionou uma abstração, um wrapper, um caso especial. Nenhuma dessas adições, individualmente, é errada. Juntas, criam um sistema que ninguém consegue manter.

Zechner descreve isso como ótimos locais que produzem péssimos globais. O agente otimiza para a tarefa na frente dele. Não vê o grafo de dependências. Não percebe que a terceira camada de indireção tornou o módulo incompreensível. Não sabe que outro agente, duas semanas atrás, resolveu um problema semelhante de forma diferente.

Como exploramos em Dívida Cognitiva, código limpo e funcional pode esconder uma erosão silenciosa do entendimento compartilhado. O agente não cria dívida técnica no sentido clássico. Cria algo pior: código que funciona e que ninguém entende por que funciona daquela forma.

O controle que falta: funções de aptidão arquitetural. Métricas automatizadas que medem complexidade ciclomática, profundidade de dependências, acoplamento entre módulos. O agente pode gerar código que passa nos testes unitários e falha na verificação arquitetural. Essa segunda verificação precisa existir e precisa bloquear o merge.

Modo 4: Degradação de Recall

“Quanto maior o codebase, menor o recall.”

Modelos de linguagem operam dentro de uma janela de contexto finita. Quanto mais código existe no projeto, menor a fração que cabe no contexto de uma sessão. O agente toma decisões baseado no que consegue ver. E vê cada vez menos do todo.

Em projetos pequenos, o agente funciona bem. Consegue carregar a maior parte do código, entende as relações entre componentes, gera soluções coerentes. Conforme o projeto cresce (parcialmente por causa do próprio código que o agente gerou), a qualidade degrada. O agente cria duplicações porque não sabe que uma função semelhante existe em outro módulo. Introduz inconsistências porque não vê o padrão adotado em outro canto do sistema.

A ironia é circular: o agente gera código, o codebase cresce, o recall do agente diminui, a qualidade das decisões piora, o agente gera mais código para compensar. Satya Nadella mencionou que até 30% do código da Microsoft é escrito por IA. Com janelas de contexto atuais, nenhum agente consegue manter uma visão coerente de um projeto desse porte.

O controle que falta: estratégias de segmentação de contexto. Documentação arquitetural que o agente lê como substituto do código que não cabe no contexto. Índices de busca semântica sobre o codebase. Regras que impedem o agente de criar novos módulos sem antes verificar se funcionalidade semelhante já existe. O problema é de informação, e a solução é dar ao agente acesso estruturado ao que ele não consegue ver diretamente.

O Padrão Que Conecta os Quatro Modos

Os modos de falha de Zechner não são independentes. São estágios de uma mesma espiral de degradação.

Erros se compõem (modo 1) porque ninguém os intercepta (modo 2). Cada correção adiciona complexidade (modo 3) que reduz a capacidade do agente de ver o sistema completo (modo 4). A degradação de recall produz mais erros, que se compõem novamente.

A espiral só acelera conforme o codebase cresce. E o codebase cresce mais rápido justamente porque agentes removem o gargalo de produção.

Governança não é desacelerar por medo. É instalar os controles que permitem manter velocidade sem destruir a integridade do sistema. Cada modo de falha tem um controle correspondente. Organizações que implantam agentes sem esses controles estão acelerando na direção exata dos quatro modos simultaneamente.

A pergunta para qualquer líder de engenharia que está implantando agentes de código: qual desses quatro controles você já tem funcionando?

---

Fontes

• Mario Zechner. “Thoughts on Slowing the Fuck Down.” Março 2026.

Victorino Group ajuda empresas a governar o desenvolvimento com IA em escala. contato@victorino.com.br | www.victorino.com.br