Auditoria forense de quantas vezes o feedback de teste entregou a resposta esperada a agentes de código

O problema

Um agente de código que repara uma função costuma rodar em loop: propõe um patch, executa um teste, lê a mensagem que volta, tenta de novo. Quando o loop recebe o feedback de um executor de testes e a taxa de reparo sobe, o mérito da melhora é atribuído ao feedback. A pergunta que o programa de pesquisa do fundador se propôs a testar era mais estreita: a confiabilidade depende de quem é dono do veredito que encerra o loop, o próprio modelo ou um supervisor cujo veredito não pode ser forjado?

Essa pergunta não tem resposta enquanto a mensagem de feedback carrega a resposta. Um traceback que imprime assert f(x) == y faz mais do que reportar uma falha. Ele revela a relação que o teste visível verifica e o valor alvo literal. Qualquer ganho medido depois de uma mensagem assim está confundido com uma dica específica da tarefa, e o estudo chama isso de problema de medição.

O que foi construído

O preprint "When Execution Feedback Reveals the Expected Output: A Forensic Study of Answer Leakage in Agentic Code Repair" foi publicado no Zenodo em 10 de julho de 2026 como preprint do autor, versão 1.0.0, sem revisão por pares, sob licença Creative Commons Atribuição 4.0. O autor é o fundador da NASCIA, escrevendo sob sua afiliação à Universidade de São Paulo. É um estudo forense do próprio programa de pesquisa dele, não um produto, e não encontra nenhuma evidência positiva limpa e validada para o benefício que o programa fora desenhado para mostrar.

Três desenhos experimentais foram auditados, cada um com seu benchmark e seu status forense: dez tarefas criadas pelo autor com o Qwen2.5-Coder 14B; o HumanEvalFix com o Qwen2.5-Coder 1.5B em 80 tarefas e três seeds; o QuixBugs com o mesmo modelo 1.5B em 29 tarefas e três seeds, o que dá 87 observações por braço. O artigo contribui com duas auditorias de vazamento específicas para essas bancadas, um diagnóstico vinculado à proveniência e um protocolo de controle para estudos futuros.

As auditorias são simples de enunciar. Para o QuixBugs, uma busca pela palavra "expected" em toda mensagem de feedback consumida, seguida de uma recontagem estrita que exige o template da própria bancada, "Input gave X, expected Y". Para o HumanEvalFix, um comparador que toma cada linha de asserção do teste de exemplo oficial e exige que a linha completa, específica da tarefa, apareça no feedback, admitindo uma rodada apenas se o SHA-256 da última mensagem de usuário da transcrição coincidir com o hash gravado na linha de resultado. Rodadas que não podem ser vinculadas contam como limpas, então toda fração reportada para o HumanEvalFix é um limite inferior.

O artigo substitui um preprint anterior do mesmo programa. Aquele trabalho foi retirado por completo depois que uma auditoria forense constatou que seus resultados não tinham sido produzidos por um loop com modelo ao vivo, e nenhum de seus números entra na nova análise. O registro nomeia o preprint retirado na própria página, e o artigo diz por quê: revelar a falha faz parte do resultado.

Como funciona

O diagrama mostra o loop em estudo e a auditoria construída em volta dele. Um modelo de linguagem propõe um patch; um teste visível o executa; uma mensagem de feedback volta para o modelo. A auditoria lê as próprias strings devolvidas e vincula cada mensagem à sua linha de resultado por hash; ao lado do verificador real, três braços de controle do mesmo loop entregam ao modelo uma mensagem errada, desatualizada ou embaralhada no lugar do feedback real.

A campanha no QuixBugs teve sete braços pré-registrados: uma linha de base cega, feedback no prompt, parada pelo próprio modelo, verificação out-of-band com feedback rico e os três controles de integridade. A regra de invalidação foi fixada antes da primeira tentativa de campanha: o desenho é inválido se qualquer controle superar a linha de base em pelo menos 0,07 com p exato de McNemar pareado abaixo de 0,05. Só depois que a campanha primária fechou e a regra disparou é que dois braços exploratórios foram especificados, cada um com carimbo de tempo anterior à própria execução: um loop só de estrutura, com mensagens sem conteúdo, e um verificador out-of-band cuja mensagem diz apenas se passou ou falhou.

A inferência é agrupada por tarefa. As 87 observações por braço são 29 tarefas repetidas em três seeds, então a tarefa é a unidade do teste do sinal bilateral e do bootstrap pareado. Intervalos de Wilson descrevem as taxas por célula, e o teste de McNemar é mantido onde decidiu uma regra registrada. Nenhuma margem de equivalência foi pré-registrada, então um valor p grande nunca é lido como prova de ausência de efeito.

Evidências

No braço primário do QuixBugs com o modelo 1.5B, 156 das 169 mensagens de feedback consumidas, 92,3%, renderizaram o campo fixo de saída esperada (descrição do registro no Zenodo e seção 6 do artigo, fato answer-leakage-study-08). No HumanEvalFix, pelo menos 316 das 417 rodadas de feedback out-of-band, 75,8%, expuseram a asserção renderizada específica da tarefa, e 289 das 417, 69,3%, expuseram uma igualdade explícita com um valor esperado; ambos são limites inferiores (Tabela 4 do artigo, página 8, fato answer-leakage-study-09). O desenho mais antigo emitia a saída bruta do pytest, que nunca foi varrida, por isso continua sem resolução (seção 8 do artigo, fato answer-leakage-study-10).

A regra de invalidação pré-registrada disparou. Um controle desatualizado (stale), nominalmente inerte, superou a linha de base cega em 0,138, com p exato de McNemar pareado de 0,0018; a análise posterior à campanha, honesta quanto ao agrupamento, corroborou a decisão com um teste do sinal no nível da tarefa com p de 0,0117 e um intervalo bootstrap pareado e agrupado por tarefa de [0,046; 0,241] (descrição do registro no Zenodo e seção 6 do artigo, página 7, fato answer-leakage-study-11). A interpretação causal primária da campanha é, portanto, inválida.

Os braços exploratórios mostram o que resta quando o vazamento é removido. O feedback rico out-of-band resolveu 33 das 87 células de tarefa e seed; o verificador que diz apenas se passou ou falhou resolveu 21 das 87; o loop só de estrutura resolveu 21 das 87; a linha de base cega resolveu 22 das 87. O contraste entre feedback rico e passou ou falhou foi de +0,138, com p do teste do sinal de 0,0020 e intervalo bootstrap de [0,069; 0,230]. Os dois braços limpos não mostraram ganho detectável sobre a linha de base na precisão alcançada, e o artigo é explícito em dizer que isso não é um resultado de equivalência (descrição do registro no Zenodo e Tabelas 2 e 3 do artigo, página 7, fato answer-leakage-study-12).

A execução armazenada do QuixBugs é recomputável forensicamente: nas 870 linhas, a autoauditoria não encontrou nenhuma divergência de modelo na primeira chamada, e nenhum dos 870 desfechos divergiu quando as soluções armazenadas foram reexecutadas em um subprocesso novo; as 2.875 chamadas ao modelo que produziram reparos não foram refeitas (seção 6 do artigo, página 8, e seção 11, página 12, fato answer-leakage-study-18). O corpus do HumanEvalFix não é: uma execução posterior com o modelo 3B sobrescreveu 783 arquivos de transcrição referenciados por linhas de resultado, de modo que suas taxas históricas exatas de vazamento são irrecuperáveis e são reportadas como limites inferiores conservadores (descrição do registro no Zenodo e seção 7 do artigo, fato answer-leakage-study-13).

Os limites estão declarados no próprio artigo. Os experimentos cobrem reparo de Python no nível de função e uma única família de modelos, principalmente o modelo 1.5B servido por uma tag mutável do Ollama; a resolução final no QuixBugs é cerca de 95% colinear com passar no único caso visível; os braços limpos foram especificados depois da campanha; e o achado negativo é uma falsificação da evidência anterior do próprio programa, não uma afirmação universal de que verificação sem vazamento é ineficaz (seção 9 e seção 13 do artigo, fato answer-leakage-study-19). O estudo usou benchmarks públicos e modelos servidos localmente, sem participantes humanos e sem dados pessoais (seção 12 do artigo, fato answer-leakage-study-26).

Tecnologias

As bancadas rodaram localmente: modelos Qwen2.5-Coder servidos pelo Ollama, execução de testes em Python em um subprocesso isolado com limite de CPU, e tracebacks do pytest ou o template de resultado da própria bancada como canal de feedback. O pacote de análise é Python de biblioteca padrão que regenera a tabela de braços e reexecuta toda solução armazenada; o repositório carrega 3.389 entradas de manifesto SHA-256 (seção 11 do artigo, fato answer-leakage-study-24). O repositório de evidências continua privado, e o registro diz que ele não deve ser descrito como um artefato de reprodutibilidade público e completo (fato answer-leakage-study-21).

O que demonstra

Definir. A unidade, o contraste primário, a família de braços e a regra que invalidaria o desenho foram escritos antes dos dados. Quando a regra disparou, o resultado principal foi descartado, em vez de justificado.

Instrumentar. A avaliação não parou no placar. As strings devolvidas ao modelo foram auditadas, a auditoria foi vinculada às linhas brutas por hash, e controles de integridade rodaram ao lado do verificador real. Essa é a disciplina por trás do segundo passo da NASCIA: construir a bancada primeiro, para que uma melhora possa ser distinguida de uma resposta vazada.

Integrar. A proveniência é tratada como parte do estimando. Cada linha nomeia sua execução e seu modelo, guarda a requisição e a resposta exatas e vincula cada mensagem consumida por SHA-256, de modo que uma sobrescrita posterior é detectável e seu dano pode ser delimitado em vez de adivinhado.

Transferir. O artigo fecha com um protocolo mínimo de seis pontos para qualquer estudo futuro: passou ou falhou como feedback padrão, um único pool imutável de candidatos para todo seletor, orçamentos equiparados, identificadores imutáveis, vinculação por hash verificada antes da agregação e uma recomputação nova antes de qualquer narrativa causal. É o mesmo formato do runbook que a NASCIA deixa com o cliente: os testes, os limites e as palavras, tudo por escrito.