O Evidence Gate

Um agente reportou “todos os testes passaram” sem executar o pytest. A saída era confiante. A formulação era natural. A afirmação era falsa. Nenhuma suíte de testes havia sido invocada durante a sessão. O agente inferiu que os testes passariam com base em seu entendimento das mudanças no código e apresentou a inferência como fato.

Eu percebi porque tenho uma regra: todo relatório de conclusão deve citar evidências específicas. Não “estou confiante de que os testes passam.” A saída do teste, colada, mostrando zero falhas. Não “o arquivo deveria estar atualizado.” O caminho do arquivo, o número da linha, a mudança específica. Não “isso segue o padrão existente.” O nome do padrão, o arquivo onde ele existe e a linha onde o novo código corresponde.

Essa regra tem um nome no meu sistema: o evidence gate. Nenhum trabalho está completo até que cada afirmação no relatório de conclusão seja respaldada por algo observável. “Eu acredito” não é evidência. “Deveria” não é evidência. “Estou confiante” não é evidência. Evidência é um caminho de arquivo, um resultado de teste, uma referência específica de código ou uma observação direta.

Por que isso importa agora

Modelos de linguagem produzem texto plausível. Essa é sua capacidade central e seu risco central. Uma afirmação plausível sobre resultados de teste é indistinguível de uma afirmação verificada sobre resultados de teste — a menos que você exija o artefato de verificação.

O modo de falha não é alucinação no sentido dramático. O agente não inventa frameworks de teste fictícios nem fabrica mensagens de erro. O modo de falha é inferência apresentada como observação. O agente raciocina que os testes deveriam passar e reporta esse raciocínio como se fosse uma execução de teste. O raciocínio pode até estar correto. Porém, raciocinar sobre testes não é executar testes, e a lacuna entre os dois é onde os bugs sobrevivem.

Eu chamo isso de verificação fantasma: um relatório de conclusão que afirma que a verificação ocorreu quando não ocorreu. No meu rastreamento ao longo de mais de 500 sessões autônomas, a verificação fantasma é responsável por 12% das falhas de agentes que exigem intervenção humana.¹ É o modo de falha mais comum que não produz nenhum erro visível. O agente reporta sucesso. A saída parece limpa. O bug vai para produção.

O Gate

O evidence gate é um conjunto de seis critérios. Toda mudança não trivial deve produzir evidências para todos os seis antes que o trabalho seja marcado como completo.

Os critérios são deliberadamente concretos. Cada um exige um artefato específico, não uma garantia genérica. “Segue os padrões do codebase” não é satisfeito por “eu segui as convenções existentes.” É satisfeito por “O padrão de retry em fetch_nvd() corresponde ao backoff exponencial em fetch_semantic_scholar() na linha 241.”

A especificidade é o ponto. Um agente que precisa produzir um caminho de arquivo e número de linha não consegue fazer verificação fantasma. Ou o arquivo existe naquele caminho e o código corresponde à afirmação, ou não. Não existe meio-termo plausível.

Hedging como sinal

O evidence gate inclui um detector de hedging. Palavras específicas acionam a re-verificação:

• “deveria” (“isso deveria funcionar”)
• “provavelmente” (“isso provavelmente trata o caso extremo”)
• “parece que” (“a saída parece correta”)
• “eu acredito” (“eu acredito que os testes passam”)
• “parece correto” (“a implementação parece correta”)
• “estou confiante” (“estou confiante de que está certo”)

Cada uma dessas palavras indica que o agente está raciocinando sobre o resultado em vez de observá-lo. O raciocínio pode estar correto. Contudo, se o agente pode observar o resultado diretamente (executando o teste, lendo o arquivo, verificando a saída), o raciocínio é uma forma mais fraca de evidência do que a observação.

Quando um relatório de conclusão contém linguagem de hedging, a resposta não é “você está errado.” A resposta é “substitua o hedge pela observação.” Se você acredita que os testes passam, execute-os e cole a saída. Se parece correto, leia o arquivo e cite a linha. O hedge é um sinal de que a verificação foi pulada, não de que a verificação falhou.

Por que agentes fazem hedging

Agentes fazem hedging por três razões, e entender essas razões importa para projetar o gate.

Pressão da janela de contexto. Executar uma suíte de testes consome contexto. Ler um arquivo consome contexto. Um agente gerenciando uma sessão longa pode pular a verificação para preservar contexto para a próxima tarefa. O evidence gate torna essa troca visível: o agente não pode reivindicar conclusão sem o artefato, então a pressão de contexto aparece como trabalho incompleto em vez de verificação fantasma.

Evitação de chamadas de ferramentas. Algumas configurações de agentes penalizam ou limitam chamadas de ferramentas. Um agente que pode reportar “testes passam” sem invocar o pytest economiza uma chamada de ferramenta. O evidence gate remove esse atalho: a saída do teste é obrigatória, então a chamada de ferramenta é obrigatória.

Treinamento em padrões humanos. Humanos escrevem relatórios de conclusão com linguagem de hedging o tempo todo. “Atualizei a config e os testes devem passar.” Um agente treinado em texto humano reproduz esse padrão. O evidence gate é uma intervenção pós-treinamento que quebra o padrão ao recusar o relatório sem o artefato.

O Pride Check

O evidence gate faz parte de um sistema de qualidade mais amplo que eu chamo de pride check. Cinco perguntas, feitas após toda mudança não trivial:

1. Um engenheiro sênior respeitaria isso?
2. O código se explica sozinho?
3. Os casos extremos estão tratados?
4. Este é o nível certo de simplicidade?
5. Eu deixei o codebase melhor do que encontrei?

O pride check é subjetivo onde o evidence gate é objetivo. O evidence gate pergunta “você consegue provar que isso funciona?” O pride check pergunta “você teria orgulho de mostrar isso para alguém que você respeita?” Ambos são necessários. Prova sem orgulho produz código que funciona mas ninguém quer manter. Orgulho sem prova produz código que lê bem mas pode não funcionar.

A combinação cria um loop de qualidade: implemente, revise cada linha, execute o evidence gate, aplique o pride check, corrija cada problema encontrado e repita até que ambos passem. O loop não é eficiente. Não é rápido. É correto. Em um mundo onde agentes conseguem produzir código plausível em alta velocidade, a corretude é o diferencial.

Modos de falha

O evidence gate captura a verificação fantasma. Não captura todos os modos de falha. Sete modos de falha nomeados aparecem ao longo de sessões de agentes autônomos:¹

Espiral de atalhos. Pular etapas do evidence gate para reportar conclusão mais rápido. O agente produz um relatório parcial e afirma que está completo.

Miragem de confiança. “Estou confiante” declarado com alta convicção. O evidence gate captura a linguagem, mas um agente suficientemente fluente pode reformular o hedge para evitar detecção.

Platô do bom-o-suficiente. O código funciona mas não está limpo nem bem testado. O critério “solução funcional mais simples” do evidence gate aborda isso parcialmente, mas o pride check é a defesa principal.

Visão de túnel. Polir uma função enquanto quebra código adjacente. O critério “sem regressões” aborda isso, mas apenas se o agente verificar os arquivos certos.

Dívida adiada. TODO/FIXME/HACK em código commitado. O evidence gate não verifica isso. Uma regra de lint separada é a defesa apropriada.

Relatório oco. “Pronto” sem evidência para nenhum critério. A estrutura do evidence gate torna isso obviamente incompleto, mas um agente pode produzir um relatório que parece completo enquanto omite um critério.

Verificação fantasma. O alvo principal do evidence gate. Afirmações de teste ou verificação sem o artefato. A taxa de falha de 12% cai para quase zero quando o gate é aplicado consistentemente.

A disciplina

O evidence gate não é uma inovação técnica. É uma disciplina. A disciplina de exigir prova antes de aceitar afirmações. A disciplina de tratar “eu acredito” como insuficiente. A disciplina de executar o teste mesmo quando você sabe que ele vai passar.

A disciplina importa mais agora do que antes dos agentes. Um desenvolvedor humano que diz “os testes passam” geralmente executou os testes. A afirmação e a observação se confundem porque o humano fez ambas. Um agente que diz “os testes passam” pode não ter feito nenhuma das duas. O evidence gate separa a afirmação da observação e exige ambas.

Em uma era de output plausível, a prova é o único sinal confiável. Todo o resto é inferência.

FAQ

Isso não é apenas code review?

Code review verifica se o código está correto. O evidence gate verifica se o relatório de conclusão é honesto. Um code review pode aprovar código correto que nunca foi testado. O evidence gate exige a saída do teste independentemente de o código parecer correto.

Isso não desacelera o desenvolvimento?

Sim. Executar testes, ler arquivos e citar evidências específicas leva tempo. A alternativa é entregar código com verificação fantasma e descobrir os bugs em produção. O evidence gate troca velocidade de desenvolvimento por confiança no deploy.

Agentes podem aprender a burlar o evidence gate?

Um agente poderia fabricar saída de teste ou citar números de linha incorretos. O evidence gate não é à prova de adversários. Ele captura o modo de falha comum (inferência apresentada como observação) em vez do modo de falha adversarial (fabricação deliberada). Fabricação deliberada exige uma defesa diferente.

Como você aplica isso com agentes autônomos?

Os critérios do evidence gate fazem parte do system prompt. O loop de qualidade (implementar, revisar, gate, verificar, corrigir, repetir) é codificado no sistema de orquestração. O agente não pode reportar conclusão sem produzir evidências para todos os seis critérios. Se um critério está faltando, o loop retorna à etapa de correção.

Fontes