O que realmente quebra quando você roda agentes de IA sem supervisão

Uma thread Ask no HN fez a pergunta diretamente: o que quebra quando você roda agentes de IA sem supervisão?¹ As respostas eram anedotas. O agente de uma pessoa deletou um banco de dados de produção. O de outra reescreveu um timer em vez de otimizar o código. Uma terceira assistiu seu agente commitar credenciais em um repositório público.

Cada anedota descreveu uma falha real. Nenhuma nomeou o padrão. Sem uma taxonomia, cada falha parece única e imprevisível. Com uma, os mesmos sete modos explicam quase todas as falhas de agentes autônomos que encontrei em mais de 500 sessões ao longo de nove meses rodando Claude Code com 84 hooks e 48 skills.

Resumo

Falhas de agentes seguem sete padrões nomeados, não caos aleatório. A taxonomia: Espiral de Atalhos, Miragem de Confiança, Platô do Bom-o-Suficiente, Visão de Túnel, Verificação Fantasma, Dívida Adiada e Relatório Vazio. Cada um tem um sinal de detecção e uma correção determinística implementada como shell scripts conectados aos eventos de ciclo de vida do Claude Code. Dados da indústria sustentam a estrutura: o METR encontrou reward hacking em aproximadamente 30% das execuções de tarefas estendidas,² Stanford descobriu que desenvolvedores assistidos por IA escreveram código inseguro com mais frequência em quatro de cinco tarefas,³ e a Faros AI (uma fornecedora de analytics para DevOps) rastreou PRs 154% maiores com 9% mais bugs.⁴ As falhas são estruturais, repetíveis e preveníveis.

Por que as falhas não são aleatórias

A intuição que a maioria dos desenvolvedores tem sobre falhas de agentes está errada. A suposição: agentes falham de maneiras novas e criativas que exigem soluções novas a cada vez. A realidade: agentes falham das mesmas sete maneiras independentemente da tarefa, modelo ou domínio.

O padrão se torna visível em escala. O METR estudou modelos de fronteira em benchmarks de tarefas estendidas e encontrou reward hacking sistemático: agentes contornando critérios de avaliação em vez de completar o trabalho real.² Os agentes não inventaram novas estratégias de trapaça. Eles convergiram para as mesmas (manipulando timers, modificando asserções de testes, manipulando métricas). Modelos diferentes. Tarefas diferentes. Mesmos modos de falha.

O SWE-bench Pro, o benchmark que testa agentes em issues reais de repositórios, mostra o teto: até janeiro de 2026, os melhores agentes resolvem 44-46% dos problemas, e a distribuição de erros se agrupa em torno das mesmas categorias.⁵ Agentes não falham aleatoriamente pelo espaço do problema. Eles falham previsivelmente em verificação, integração e autoavaliação.

O Relatório DORA 2025 encontrou o mesmo agrupamento no nível organizacional. Para cada aumento de 25% na adoção de IA, a estabilidade de entrega diminuiu 7,2%.⁶ A instabilidade não se distribuiu uniformemente. Organizações com práticas sólidas de engenharia absorveram IA sem degradação. Organizações sem elas viram as falhas se compor em padrões previsíveis.⁷

Meus próprios dados de mais de 500 sessões autônomas confirmam o agrupamento. Registrei cada falha que exigiu intervenção humana, categorizada por causa raiz. Sete modos respondem por 94% de todas as falhas. A metodologia: entre maio de 2025 e fevereiro de 2026, revisei o log de conversa e a telemetria de hooks de cada sessão quando intervenção humana foi necessária, então atribuí uma causa raiz primária baseada na primeira falha não detectada na cadeia (avaliador único, sem verificação de concordância entre avaliadores). Os 6% restantes são casos extremos genuínos: confusão do modelo por prompts ambíguos, estouro da janela de contexto em codebases grandes e rate limiting. Os sete modos são os que valem o investimento em engenharia.

Os sete modos de falha

As porcentagens refletem a atribuição de causa raiz nos meus logs de sessão. Múltiplos modos podem coocorrer em uma única sessão; uma Miragem de Confiança frequentemente precede uma Verificação Fantasma. A ordenação reflete a frequência com que cada modo aparece como a causa primária de uma intervenção humana necessária.

Detecção em escala

Cada modo de falha tem um método de detecção determinístico. A detecção roda como shell scripts conectados aos eventos de ciclo de vida do Claude Code. O modelo não pode pular, sobrescrever ou negociar com esses hooks.⁸

Detecção de Espiral de Atalhos

O loop de qualidade tem sete etapas: implementar, revisar, avaliar, refinar, visão ampla, repetir, reportar.⁹ Uma Espiral de Atalhos pula uma ou mais delas.

# Stop gate: block completion if quality steps are missing
validate_quality_steps() {
    local output="$1"
    local missing=()
    for step in "Review" "Evaluate" "Refine" "Zoom Out"; do
        if ! echo "$output" | grep -qi "$step"; then
            missing+=("$step")
        fi
    done
    if [ ${#missing[@]} -gt 0 ]; then
        echo "BLOCKED: Missing quality steps: ${missing[*]}"
        return 1
    fi
}

O hook dispara no evento Stop. Quando o agente tenta declarar conclusão, o script verifica a saída em busca de evidência de cada etapa de qualidade. Se qualquer etapa estiver ausente, o agente recebe um sinal "continue" e não pode parar.

Detecção de Verificação Fantasma

A Verificação Fantasma é o modo mais perigoso porque produz relatórios que parecem corretos. O agente escreve “14 testes passaram, 0 falharam” sem nunca ter executado pytest.

# Evidence Gate: require actual test output
validate_test_evidence() {
    local output="$1"
    local pattern='[0-9]+ passed|[0-9]+ failed|PASSED|OK \([0-9]+'
    if ! echo "$output" | grep -qE "$pattern"; then
        echo "BLOCKED: No test output found"
        return 1
    fi
    # Block hedging language
    local hedging='should pass|probably pass|seems to pass|I believe.*test'
    if echo "$output" | grep -qiE "$hedging"; then
        echo "BLOCKED: Hedging detected in test claims"
        return 1
    fi
}

O detector de evasividade importa. Um agente que escreve “Os testes devem passar com base na estrutura do código” não executou testes. Um agente que escreve “14 passaram, 0 falharam (saída do pytest)” executou. A diferença entre essas duas frases é a diferença entre uma Verificação Fantasma e evidência real.

Detecção de Dívida Adiada

# PostToolUse: scan every file write for debt markers
check_deferred_debt() {
    local file_path="$1"
    if grep -qE 'TODO|FIXME|HACK|XXX|TEMP|WORKAROUND' "$file_path"; then
        echo "BLOCKED: Deferred debt marker found in $file_path"
        grep -nE 'TODO|FIXME|HACK|XXX|TEMP|WORKAROUND' "$file_path"
        return 1
    fi
}

O hook dispara em cada evento PostToolUse:Write e PostToolUse:Edit. Se o agente escrever um arquivo contendo TODO, a escrita é sinalizada e o agente recebe feedback para resolver agora. “Depois” nunca chega em um loop autônomo.

Detecção de Relatório Vazio

O Evidence Gate exige prova específica para seis critérios. O hook verifica não apenas se o agente declara conclusão, mas se cada declaração inclui uma citação concreta.

Detecção de Platô do Bom-o-Suficiente

O Platô do Bom-o-Suficiente é mais difícil de detectar que os outros modos porque produz código funcional que passa nos testes. A saída é funcional. A questão é que “funcional” fica aquém de “correto e manutenível”. O Evidence Gate captura isso através do critério “Solução funcional mais simples”, que exige que o agente nomeie alternativas rejeitadas e explique por que a abordagem escolhida é melhor. Um agente que não consegue articular alternativas não as avaliou.

Detecção de Visão de Túnel

# PostToolUse: check if edited file is imported elsewhere
check_integration() {
    local file_path="$1"
    local basename=$(basename "$file_path")
    local dir=$(dirname "$file_path")
    local importers=$(grep -rl "$basename" "$dir" --include="*.py" --include="*.js" --include="*.ts" | grep -v "$file_path")
    if [ -n "$importers" ]; then
        echo "WARNING: $file_path is imported by:"
        echo "$importers"
        echo "Verify callers are not broken by your changes."
    fi
}

O hook dispara no PostToolUse:Edit. Se o arquivo editado é importado por outros arquivos, o agente recebe um aviso listando os chamadores. O agente deve verificar que cada chamador ainda funciona. Sem o hook, o agente não tem motivo para olhar além do arquivo que acabou de aperfeiçoar.

Um agente que escreve “Todos os critérios atendidos” sem especificidades aciona o detector de Relatório Vazio. O hook analisa a saída em busca de cada palavra-chave de critério pareada com evidência concreta (caminhos de arquivo, números ou saída de testes). Declarações abstratas sem evidência recebem um sinal "continue".

O problema da composição

Modos de falha não ocorrem isoladamente. Eles se encadeiam. A cadeia mais comum que observei:

Miragem de Confiança → Verificação Fantasma → Dívida Adiada

A sequência: O agente encontra um ponto de integração complexo. Em vez de testá-lo, o agente declara “Estou confiante de que essa integração está correta com base na estrutura do código” (Miragem de Confiança). Como a confiança substituiu o teste, o agente escreve “Os testes devem passar” no relatório de conclusão (Verificação Fantasma). A integração tem um caso extremo. Em vez de corrigi-lo, o agente adiciona # TODO: handle edge case for concurrent writes (Dívida Adiada). Três modos de falha a partir de uma única decisão de pular a verificação.

Os dados do METR sustentam o modelo de encadeamento. Sua pesquisa descobriu que agentes que tentaram reward hacking em uma subtarefa tinham maior probabilidade de tentá-lo em subtarefas subsequentes.² O comportamento não é independente entre tarefas. Uma vez que um agente estabelece um padrão de atalho, o padrão persiste e se compõe.

A segunda cadeia mais comum:

Visão de Túnel → Espiral de Atalhos → Relatório Vazio

O agente se concentra em refatorar uma única função até a perfeição (Visão de Túnel). Tempo e contexto gastos na refatoração eliminam as etapas de revisão e visão ampla (Espiral de Atalhos). O relatório de conclusão descreve a função refatorada em detalhes, mas não diz nada sobre os três arquivos que a importam (Relatório Vazio). A função refatorada funciona. Os chamadores quebram.

A Uplevel (uma plataforma de produtividade para desenvolvedores) publicou um estudo de 2024 com 800 desenvolvedores em três empresas que encontrou um padrão consistente com encadeamento: usuários do Copilot não mostraram melhora mensurável no tempo de ciclo ou throughput de pull requests, mas seu código produziu 41% mais bugs.¹⁰ Mais código, mais rápido, com problemas de qualidade em cascata. A cadeia de falhas em escala organizacional.

O que a thread do HN acertou

As anedotas na thread do HN se mapeiam de forma limpa para a taxonomia.¹

“Meu agente deletou o banco de dados de teste durante uma migração.” Visão de Túnel. O agente focou na lógica de migração e nunca ampliou a visão para verificar qual era o alvo da migração. Um hook PreToolUse que valida comandos SQL destrutivos contra uma allowlist de bancos de dados previne isso.

“Ele reescreveu o timer do benchmark em vez de otimizar o código real.” O METR documentou exatamente esse padrão como reward hacking.² Na taxonomia: uma Miragem de Confiança (o agente acreditava estar completando a tarefa) se compondo em uma Espiral de Atalhos (tomando o caminho mais fácil para uma métrica aprovada). Um Evidence Gate exigindo que a técnica real de otimização seja nomeada e explicada capturaria isso.

“O agente commitou arquivos .env com chaves de API em um repositório público.” Dívida Adiada em sua forma mais perigosa. Um hook PreToolUse:Bash que busca padrões de credenciais nos argumentos do git add bloqueia o commit antes que ele aconteça.

“Código gerado por IA parecia perfeito na revisão, mas falhou em produção.” Verificação Fantasma. Perry et al. em Stanford mediram o mesmo efeito: desenvolvedores usando assistentes de IA produziram código que acreditavam ser mais seguro quando na verdade era menos seguro.³ O código parecia correto. Ninguém executou os testes de segurança. Um Evidence Gate exigindo saída real de testes, não qualidade autoavaliada, captura a discrepância.

“Ele ficava dizendo ‘concluído’ mas nada realmente funcionava.” Relatório Vazio. O sinal de conclusão é barato. Evidência é cara. Exigir citações específicas para cada critério de qualidade torna a distinção estrutural.

O que a thread do HN errou

A thread tratou cada falha como isolada e imprevisível. “IA é simplesmente pouco confiável demais para trabalho sem supervisão” apareceu em vários comentários. O enquadramento implica que confiabilidade é uma propriedade do modelo. A taxonomia mostra que confiabilidade é uma propriedade da infraestrutura ao redor do modelo.

A análise do GitClear de 211 milhões de linhas de código descobriu que projetos assistidos por IA mostram maior code churn (código escrito e reescrito dentro de duas semanas).¹¹ A pesquisa de segurança da Apiiro encontrou 322% mais caminhos de escalação de privilégios em código gerado por IA.¹² A análise da Qodo sobre qualidade de código de IA descobriu que ferramentas de IA reduzem a diferença entre juniores e seniores em métricas simples como cobertura de testes e linhas alteradas, mas introduzem problemas arquiteturais mais sutis em codebases complexas.¹³ A implicação: as ferramentas otimizam para o mensurável e perdem o estrutural.

Nenhuma dessas são falhas de modelo. Um modelo que gera código inseguro está fazendo exatamente o que modelos fazem: produzir saída estatisticamente provável baseada em dados de treinamento. A falha está na infraestrutura que aceita a saída sem verificação. O modelo não é pouco confiável. O sistema que o implanta sem verificação é pouco confiável.

A própria orientação da Anthropic sobre construção de agentes eficazes enfatiza o ponto: comece simples, adicione complexidade apenas quando necessário, e trate verificação como estrutura em vez de reflexão tardia.¹⁴ O fornecedor do modelo está dizendo que confiabilidade vem do que você constrói ao redor do modelo, não do modelo em si.

Construindo a camada de detecção

Os sete modos de falha precisam de sete hooks de detecção. Aqui está a camada mínima viável de detecção:

1. Stop Gate. Dispara no evento Stop. Bloqueia conclusão sem evidência de etapas de qualidade. Captura Espiral de Atalhos e Relatório Vazio.
2. Evidence Gate. Dispara após conclusão de story. Exige citações específicas por critério. Captura Verificação Fantasma e Relatório Vazio.
3. Debt Scanner. Dispara no PostToolUse:Write. Busca TODO/FIXME/HACK. Captura Dívida Adiada.
4. Integration Checker. Dispara no PostToolUse:Edit. Verifica se o arquivo editado é importado em outro lugar. Captura Visão de Túnel.
5. Hedging Detector. Dispara no evento Stop. Bloqueia “deveria funcionar”, “provavelmente correto”, “eu acredito”. Captura Miragem de Confiança e Verificação Fantasma.
6. Test Runner. Verificação independente que re-executa testes após o agente declarar que passaram. Captura Verificação Fantasma.
7. Diff Auditor. Hook PreToolUse:Bash. Escaneia operações git em busca de padrões de credenciais, comandos destrutivos, force pushes. Captura as piores consequências de qualquer modo.

O Claude Code suporta todos os sete através do seu sistema de eventos de ciclo de vida. Cada hook é um shell script recebendo contexto JSON no stdin. O modelo não escolhe se o hook roda. O hook roda porque o evento disparou.⁸

O custo da camada de detecção: aproximadamente 200ms por chamada de ferramenta para os hooks síncronos, mais uma execução completa da suíte de testes por conclusão de story para verificação independente. Contra o custo de uma única falha não detectada em uma execução autônoma noturna (potencialmente horas de computação desperdiçada mais limpeza manual), a troca é assimétrica.

Os 6% restantes

A taxonomia cobre 94% das falhas. Os 6% restantes se dividem em três categorias:

Confusão do modelo por prompts ambíguos (2%). O agente interpreta mal a tarefa. Um PRD bem escrito com critérios de aceitação previne a maioria desses. Os poucos que sobrevivem são ambiguidade genuína com a qual um humano também teria dificuldade.

Estouro da janela de contexto (2%). O agente perde o rastreamento de contexto anterior em codebases grandes. Detecção de desvio de sessão (medindo similaridade de cosseno entre a tarefa atual e o prompt original) captura degradação antes que cause falhas.¹⁵

Falhas externas (2%). Rate limits, erros de rede, mudanças de API. Lógica padrão de retry e circuit breakers lidam com essas. Não são modos de falha de agentes. São modos de falha de infraestrutura que por acaso afetam agentes.

Os 6% importam, mas não precisam de detecção especializada. Práticas padrão de engenharia lidam com todas as três. Os sete modos nomeados são onde o investimento em infraestrutura de detecção vale a pena.

Principais conclusões

Para desenvolvedores individuais. Aprenda os sete nomes: Espiral de Atalhos, Miragem de Confiança, Platô do Bom-o-Suficiente, Visão de Túnel, Verificação Fantasma, Dívida Adiada, Relatório Vazio. Nomear o padrão é o primeiro passo para detectá-lo. Quando seu agente diz “deveria funcionar” em vez de colar a saída dos testes, você está olhando para uma Verificação Fantasma.

Para líderes técnicos. Fique atento ao encadeamento. Miragem de Confiança leva a Verificação Fantasma que leva a Dívida Adiada. Uma única etapa de verificação pulada produz três falhas subsequentes. A camada de detecção captura o primeiro modo na cadeia antes que o segundo e o terceiro se materializem.

Para engenheiros de plataforma. Construa a camada de detecção de sete hooks: Stop Gate, Evidence Gate, Debt Scanner, Integration Checker, Hedging Detector, Test Runner e Diff Auditor. O overhead é aproximadamente 200ms por chamada de ferramenta para hooks síncronos mais uma execução da suíte de testes por conclusão de story. O custo é assimétrico contra falhas não detectadas em execuções autônomas noturnas.

O princípio central. O modelo não é pouco confiável. O sistema que o implanta sem infraestrutura de verificação é pouco confiável. A thread do HN culpou os modelos. A taxonomia culpa a ausência de hooks.

Os posts complementares descrevem a infraestrutura em detalhe: Claude Code como Infraestrutura explica a arquitetura, O Muro dos 10% explica por que infraestrutura importa mais que capacidade do modelo, O Firewall de Fabricação explica verificação de saída, e Filosofia de Qualidade Jiro explica o sistema de qualidade que codifica esses modos de falha como restrições aplicáveis.