Resumo Técnico: BUILD-AND-FIND

Declaração do Problema

As atuais avaliações de agentes de codificação avaliam principalmente a correção comportamental (por exemplo, a aprovação de testes unitários). No entanto, à medida que os agentes evoluem da síntese de funções para a engenharia em nível de repositório, os repositórios de código gerados servem cada vez mais como artefatos intermediários: um agente escreve um repositório, e agentes subsequentes devem inspecioná-lo, auditá-lo ou estendê-lo. Neste contexto, um repositório não é meramente uma resposta a uma tarefa, mas um artefato de comunicação.

O artigo identifica uma lacuna: um repositório pode passar em testes comportamentais visíveis, mas falhar em expor claramente a intenção de design e as escolhas por trás desse comportamento. Se um repositório gerado ocultar sua intenção, isso impõe um fardo extra de inspeção aos agentes a jusante, mesmo que o código funcione corretamente. As avaliações existentes não medem se as decisões pretendidas são recuperáveis a partir do próprio artefato antes que qualquer modificação seja tentada.

Metodologia: O Protocolo BUILD-AND-FIND

Os autores propõem o BUILD-AND-FIND, um protocolo projetado para avaliar a recuperação evidenciada por artefatos. Esta abordagem separa a capacidade de construir código da capacidade de recuperar a intenção a partir desse código.

Papéis Principais

1. Construtor: Recebe uma especificação oculta (definindo comportamentos pretendidos e escolhas de design) e gera um repositório de código autossuficiente.
2. Procurador: Recebe apenas o repositório de código gerado e um banco de questões de múltipla escolha rastreado pela especificação. A especificação oculta permanece inacessível. O procurador deve inspecionar arquivos, fazer chamadas de ferramentas e responder a perguntas baseando-se exclusivamente no artefato.

Camadas de Avaliação

O protocolo define três camadas distintas de avaliação:

1. Correção Comportamental: O código passa nos testes? (Foco padrão das avaliações).
2. Recuperabilidade da Intenção no Lado do Artefato: Um agente a jusante consegue recuperar comportamentos pretendidos e escolhas de design a partir do artefato sozinho? (O foco do BUILD-AND-FIND).
3. Sucesso de Modificação a Jusante: Um agente posterior consegue modificar o repositório com segurança? (Trabalho futuro).

Métricas e Controles

O protocolo relata quatro métricas-chave, com uma hierarquia estrita de interpretação:

• Precisão de Recuperação: Precisão de correspondência exata no banco de questões.
• Estabilidade/Repetibilidade: Consistência das respostas em ensaios repetidos.
• Cobertura de Implementação: A fração de afirmações da especificação realmente implementadas no artefato (auditada para garantir que os procuradores não sejam penalizados por afirmações de ouro não implementadas).
• Esforço de Inspeção: Medido em novos bytes de inspeção do agente (novos bytes recuperados via chamadas de ferramentas, excluindo prompts do sistema e sobrecarga de transporte).

Restrição Crucial: O esforço de inspeção é interpretado como um proxy para a legibilidade do artefato apenas após o passar das barreiras de precisão de recuperação e estabilidade. Se a recuperação falhar, o esforço é sem sentido.

Controles:

• Apenas Questões: Os procuradores veem apenas as questões (mede priores gerais de engenharia).
• Apenas Especificação: Os procuradores veem a especificação (mede a respondibilidade limite superior).
• Falha de Compilação: Artefatos que falham na compilação são retidos como diagnósticos de estresse.
• Auditoria de Evidências: Verificações a posteriori para verificar se as respostas corretas citam evidências específicas do artefato (arquivos de origem, configurações) em vez de depender de priores.

Contribuições Principais

1. Alvo de Avaliação: Define a recuperação evidenciada por artefatos como uma camada distinta entre a correção comportamental e a modificação a jusante.
2. Protocolo Construtor–Procurador: Um framework de papéis divididos onde construtores codificam especificações ocultas em código, e procuradores tentam decodificá-las sem ver a especificação.
3. Contrato de Medição: Um padrão rigoroso de relatórios que separa a precisão (validade) do esforço (legibilidade), garantindo que o esforço seja analisado apenas quando a recuperação é confiável.
4. Calibração e Lançamento: Um lançamento abrangente incluindo o harness, tarefas (scratch_minidb, scratch_nanoweb), artefatos gerados, tabelas canônicas e auditorias de evidências. Inclui diagnósticos para afinidade construtor–procurador e sensibilidade a baixos priores.

Resultados Empíricos

O estudo avaliou 12 configurações de agentes (incluindo GPT-5.5, Opus 4.7, Sonnet 4.6 e variantes MiMo) em duas famílias de tarefas.

• Regime de Alta Recuperação: No pacote de tarefas de alto prior liberado, a precisão de recuperação está próxima da saturação (por exemplo, ~98,9% para execuções condicionadas ao artefato versus 94,5% para apenas questões). Como a precisão é alta, ela serve principalmente como uma barreira e não como um sinal discriminativo.
• Esforço de Inspeção como Discriminador: Com as barreiras de recuperação superadas, o esforço de inspeção condicional torna-se a métrica principal para comparar a legibilidade do artefato.
  • O GPT-5.5 demonstrou o menor esforço de inspeção (alta legibilidade), com uma pontuação de esforço relativo ($R_b$) de 1,033 no painel de alto esforço.
  • As variantes MiMo geralmente exigiram maior esforço de inspeção.
  • Claude Sonnet 4.6 e Opus 4.7 mostraram níveis intermediários de esforço, com alguma variação baseada nas configurações de esforço de raciocínio (alto versus baixo).
• Afinidade: O estudo constatou que a legibilidade pode ser dependente do leitor. Pares construtor–procurador da mesma família (por exemplo, construtor OpenAI + procurador OpenAI) mostraram resíduos de afinidade positivos, sugerindo que recuperam a intenção mais facilmente do que pares de famílias diferentes.
• Auditoria de Evidências: Em uma amostra de 72 respostas corretas, 65 foram "suportadas" por evidências de artefato citadas (principalmente arquivos de origem), confirmando que alta precisão geralmente se correlaciona com raciocínio fundamentado no artefato nesta configuração.

Significado e Alegações

O artigo alega que o BUILD-AND-FIND estabelece um contrato de avaliação necessário para repositórios de código gerenciados por agentes. Seu significado reside em:

• Mudança de Foco: Ir além de "funciona?" para "é compreensível para outro agente?".
• Proxy de Legibilidade: Tratar o esforço de inspeção como um proxy mensurável de quão bem um artefato comunica a intenção de design, desde que a recuperação seja estável.
• Separação de Preocupações: Desacoplar explicitamente a capacidade de implementação da capacidade de recuperar intenção, permitindo uma análise mais matizada do desempenho do agente.
• Framework Auditável: Fornecer uma infraestrutura reproduzível e pronta para auditoria que separa priores gerais da recuperação condicionada ao artefato, impedindo que as avaliações sejam resolvidas apenas por memorização ou conhecimento geral de engenharia.

Os autores permanecem modestos, observando que as alegações atuais são limitadas ao painel liberado e às famílias de tarefas. Eles enfatizam que a avaliação não mede correção em tempo de execução, segurança ou manutenibilidade humana, mas sim a capacidade específica dos agentes de usar repositórios gerados como memória externa e meio de comunicação.