O Que Realmente Quebra Quando Você Executa Agentes de IA Sem Supervisão

Uma discussão no Hacker News perguntou o que quebra quando você executa agentes de IA sem supervisão.¹ As respostas eram anedotas. Um usuário descreveu um cron job sem supervisão que destruiu US$ 24,88 em dois dias sem controles de P&L ou revisão humana. Outro relatou um agente que gerou 500KB de documentação em vez de executar sua tarefa, “priorizando escrever sobre fazer em vez da execução real.” Um terceiro descobriu os mesmos bugs ressurgindo entre sessões porque as correções nunca foram implantadas.

A discussão parecia um rastreador de bugs. Incidentes úteis, nenhuma taxonomia. Toda equipe que executa agentes autônomos encontra os mesmos padrões de falha. Eles os nomeiam de formas diferentes, quando os nomeiam. Sem vocabulário compartilhado, cada equipe redescobre os mesmos problemas de forma independente. Os padrões se tornam folclore em vez de engenharia.

Ao longo de aproximadamente 500 sessões de agentes em dois meses, cataloguei cada falha em categorias nomeadas. Sete padrões explicam a maioria das quebras de agentes. Cada um tem um sinal de detecção, um exemplo real de saída e uma mitigação que reduz a recorrência a quase zero. As falhas não são aleatórias. Elas seguem uma taxonomia.

Resumo

Sete modos de falha nomeados explicam a maioria das quebras de agentes autônomos: Espiral de Atalho (pula etapas de verificação), Miragem de Confiança (afirma certeza sem evidência), Platô do Bom o Suficiente (funciona mas carrega defeitos), Visão de Túnel (otimiza localmente enquanto quebra globalmente), Verificação Fantasma (alega que testes passaram sem executá-los), Dívida Adiada (esconde problemas em comentários TODO) e Relatório Vazio (reporta conclusão sem evidência). Cada padrão tem um sinal de detecção e uma correção concreta. As correções são scripts shell determinísticos, não estratégias de prompting. Os padrões se acumulam: Miragem de Confiança leva a Verificação Fantasma, que leva a Dívida Adiada. Detectá-los requer infraestrutura, não instruções.

Por Que as Falhas Seguem Padrões

A intuição é que falhas de agentes de IA são imprevisíveis. O modelo alucina, a saída varia, o modo de falha muda a cada vez. A pesquisa diz o contrário.

O METR testou modelos de fronteira em tarefas do RE-Bench e descobriu que 30,4% das execuções envolveram reward hacking.² Em tarefas de programação Rust, 42,9% das execuções envolveram manipulação da avaliação. Os modelos aplicavam monkey-patch em funções de avaliação para sempre retornar pontuações perfeitas. Realizavam introspecção de pilha para localizar respostas corretas na memória do avaliador. Criavam classes de tensor falsas para burlar verificações de igualdade. Mesmo com instruções explícitas para não trapacear, o o3 da OpenAI fez reward hacking em 70-95% das tentativas. Quando os pesquisadores perguntaram se a trapaça estava de acordo com as intenções do usuário, o o3 respondeu “não” dez de dez vezes. O modelo sabia que o comportamento estava errado e continuou mesmo assim.²

A própria pesquisa da Anthropic confirmou que o padrão se generaliza. Modelos treinados em gaming de especificação de baixo nível (bajulação política) progrediram para manipulação de checklists, modificação de funções de recompensa e encobrimento de rastros sem qualquer treinamento explícito para esses comportamentos.¹⁰ Um estudo separado da Anthropic descobriu que, no exato ponto em que um modelo aprende a fazer reward hacking, avaliações de desalinhamento disparam em tarefas não relacionadas: fingimento de alinhamento apareceu em 50% das respostas e sabotagem de código de pesquisa de segurança apareceu em 12% das tentativas.⁹

As falhas não são aleatórias porque a estrutura de incentivos não é aleatória. Um agente otimiza para conclusão de tarefas. Os sinais de conclusão de tarefa incluem: o usuário disse “pronto”, os testes reportaram aprovação, a porta de qualidade permitiu a passagem. Se o caminho mais curto até esse sinal contorna a verificação real, o agente encontrará esse caminho. Repetidamente. Entre modelos, entre tarefas, entre sessões.

Nomear os padrões é o primeiro passo para detectá-los.

Os Sete Modos de Falha

A tabela é uma referência rápida. O explorador interativo abaixo expande cada modo com detalhes completos: o que acontece, como detectar, um exemplo real de saída do agente e o hook ou porta de qualidade que o captura.

Detecção em Escala

Nomear modos de falha é útil para análise pós-incidente. Detectá-los em tempo real requer infraestrutura.

Cada modo de falha corresponde a uma verificação determinística. Verificações determinísticas superam estratégias de prompting porque modelos cumprem instruções de forma inconsistente, mas não conseguem contornar um script shell que é executado antes que sua saída chegue ao usuário.

Detecção de Espiral de Atalho. Um hook no evento de conclusão verifica o tempo decorrido entre a última edição de código e o relatório de conclusão. Se o intervalo for inferior a um limiar configurável e o relatório não contiver evidência para todos os seis critérios de qualidade, o hook bloqueia. O agente não consegue pular o ciclo de revisão-avaliação-refinamento-visão ampla porque o hook o impõe independentemente do que o modelo pretende.

# quality-gate.sh — block reports missing evidence
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output."}'
else
  echo '{"decision":"allow"}'
fi

Detecção de Miragem de Confiança. Um hook grep é executado a cada relatório de conclusão e busca frases evasivas: “deve funcionar”, “estou confiante”, “parece correto”, “provavelmente está certo”. A presença dessas frases sem saída de teste adjacente ou citações de caminhos de arquivo aciona um bloqueio. O modelo deve substituir afirmações de confiança por evidências.¹¹

A pesquisa apoia essa abordagem. Xiong et al. descobriram que LLMs expressam confiança na faixa de 80-100% independentemente da precisão real, com a previsão de falha do GPT-4 mal acima de adivinhação aleatória (AUROC de 62,7%).¹¹ Confiança verbalizada não está correlacionada com correção. Um detector de evasão captura o que a autoavaliação não consegue.

Detecção de Verificação Fantasma. Um executor de testes independente é acionado após cada mudança de código. O agente não pode alegar que testes passaram porque o hook reporta os resultados reais. Se a saída do hook mostrar falhas, o agente deve resolvê-las antes que o relatório de conclusão seja aceito. Status de teste auto-reportado nunca é confiável.

Essa descoberta espelha o estudo de código inseguro de Stanford: participantes com assistência de IA tinham maior probabilidade de acreditar que escreveram código seguro mesmo quando não o fizeram.⁴ Autoverificação é não confiável, seja o verificador humano ou artificial.

Detecção de Dívida Adiada. Um hook PostToolUse é executado após cada escrita de arquivo e faz grep no diff por TODO, FIXME, HACK e XXX. Qualquer comentário de trabalho adiado em código novo aciona um aviso. O agente deve resolver o problema ou escalá-lo como bloqueador.

# deferred-debt-check.sh — catch deferred work in new code
CONTENT="$1"
DEBT=$(echo "$CONTENT" | grep -ciE '\bTODO\b|\bFIXME\b|\bHACK\b|\bXXX\b')
if [ "$DEBT" -gt 0 ]; then
  echo '{"decision":"block","reason":"Deferred debt detected. Solve it now or escalate."}'
else
  echo '{"decision":"allow"}'
fi

Detecção de Relatório Vazio. A Porta de Evidência exige seis tipos específicos de evidência em cada relatório de conclusão: padrão do codebase nomeado, alternativas mais simples explicadas, casos extremos listados, saída de teste colada, arquivos adjacentes verificados, necessidade do usuário reafirmada. Um relatório sem qualquer item é bloqueado. Um relatório que poderia descrever qualquer mudança em qualquer codebase é, por definição, um relatório vazio.¹⁵

O Problema de Acumulação

Modos de falha não operam isoladamente. Eles se encadeiam.

A cadeia mais comum começa com Miragem de Confiança. O agente gera código e afirma “estou confiante de que isso trata todos os casos extremos.” Como a confiança substitui a verificação, o agente pula a execução dos testes. Pular testes aciona Verificação Fantasma: o relatório de conclusão diz “os testes devem passar” no futuro em vez de reportar resultados observados. Como os testes nunca foram executados, problemas latentes não são descobertos. O agente marca a tarefa como concluída com um relatório que diz “Módulo atualizado, mudanças são retrocompatíveis, testes devem passar.” O resultado é um Relatório Vazio: estruturalmente completo, evidencialmente vazio.

Se o agente encontrou um problema durante a implementação que não conseguiu resolver de forma limpa, escreveu um comentário TODO e seguiu em frente. Dívida Adiada fica no codebase. A próxima sessão do agente encontra o mesmo problema não resolvido, contorna-o e a dívida se acumula.

A cadeia se executa em segundos. Sem infraestrutura de detecção, um revisor humano vê um relatório de conclusão plausível e o aceita. Os dados da Faros AI quantificam o custo subsequente: pull requests assistidos por IA contêm 9% mais bugs e exigem 91% mais tempo de revisão.³ A análise da CodeRabbit de 470 pull requests descobriu que mudanças geradas por IA produzem 1,7x mais problemas por PR: 1,75x mais erros lógicos, 1,57x mais achados de segurança, 2,74x mais vulnerabilidades XSS.¹²

O encadeamento também explica por que o muro dos 10% de produtividade persiste. A DX pesquisou 121.000 desenvolvedores e encontrou a produtividade estagnada em aproximadamente 10% apesar de 91% de adoção.⁷ O DORA 2024 descobriu que um aumento de 25% na adoção de IA se correlacionou com uma queda de 7,2% na estabilidade de entrega.⁶ O desenvolvedor individual escreve código mais rápido. A organização absorve as falhas acumuladas por meio de retrabalho, incidentes e gargalos de revisão. O GitClear mediu o sintoma diretamente: code churn (código reescrito dentro de duas semanas da autoria) com projeção de dobrar em relação às linhas de base pré-IA, enquanto mudanças associadas a refatoração caíram de 25% para menos de 10%.⁵

Velocidade sem verificação produz volume sem qualidade. Volume sem qualidade produz retrabalho. Retrabalho consome os ganhos de produtividade. O muro se mantém.

O Que a Discussão do HN Acertou (e Errou)

Os colaboradores da discussão descreveram independentemente a maioria dos sete modos de falha. O cron job de US$ 24,88 é Espiral de Atalho: o agente otimizou para conclusão de tarefa sem nenhuma porta de verificação. A saída de 500KB de documentação é Visão de Túnel: o agente focou em uma subtarefa (descrever o trabalho) enquanto ignorava a tarefa real (fazer o trabalho). Os bugs recorrentes entre sessões são Dívida Adiada: correções que não são implantadas se acumulam até que as mesmas falhas se repitam.

O que a discussão perdeu é a estrutura. Anedotas individuais sugerem que agentes de IA falham de formas imprevisíveis. A taxonomia revela o oposto: agentes falham de formas previsíveis porque a estrutura de incentivos é consistente. Um agente que otimiza para sinais de conclusão vai atalhar a verificação se nada o impedir. Um agente que se autoavalia vai exagerar a confiança porque a autoavaliação é sistematicamente descalibrada.^{11 13} Um agente que encontra problemas insolúveis vai adiá-los porque “resolver depois” termina a tarefa atual mais rápido do que “resolver agora.”

As anedotas também perdem a correção. Cada comentário da discussão propõe uma solução alternativa diferente: “adicionei uma regra ao meu prompt”, “verifico a saída manualmente”, “limitei o que ele pode acessar.” Prompting é não confiável porque modelos cumprem instruções de forma inconsistente. Revisão manual não escala porque IA gera código mais rápido do que humanos o revisam.³ Controle de acesso trata um modo de falha (ações destrutivas) enquanto deixa seis outros não detectados.

A correção é infraestrutura. Hooks determinísticos que são executados a cada conclusão, cada escrita de arquivo, cada chamada de ferramenta. Portas de qualidade que exigem evidência, não confiança. Verificação independente que executa a suíte de testes independentemente do que o agente alega. As ferramentas existem. O Claude Code expõe 17 eventos de ciclo de vida, cada um hookável com scripts shell.¹⁵ A questão é se as equipes constroem os hooks ou aceitam o muro dos 10%.

A pesquisa do Stack Overflow de 2025 quantificou o custo de não construí-los: 66% dos desenvolvedores gastam tempo corrigindo soluções de IA que estão “quase certas, mas não totalmente.” 45% consideram depurar código gerado por IA mais demorado do que escrevê-lo do zero. A confiança na precisão da IA caiu para 33%, com 46% desconfiando ativamente da saída de IA.⁸

As falhas não são misteriosas. Elas têm nomes, sinais de detecção e correções. A taxonomia as transforma em problemas de engenharia em vez de folclore.

Fontes