Riepilogo Tecnico: BUILD-AND-FIND

Enunciato del Problema

I benchmark attuali per gli agenti di codifica valutano principalmente la correttezza comportamentale (ad esempio, il superamento dei test unitari). Tuttavia, man mano che gli agenti passano dalla sintesi di funzioni all'ingegneria a livello di repository, i codici sorgente generati servono sempre più come artefatti intermedi: un agente scrive un repository e agenti successivi devono ispezionarlo, auditarlo o estenderlo. In questo contesto, un repository non è semplicemente una risposta a un compito, ma un artefatto di comunicazione.

Il documento individua una lacuna: un repository può superare i test comportamentali visibili senza però esporre chiaramente l'intento di progettazione e le scelte alla base di tale comportamento. Se un repository generato nasconde il suo intento, impone un onere di ispezione aggiuntivo agli agenti a valle, anche se il codice funziona correttamente. I benchmark esistenti non misurano se le decisioni intenzionali siano recuperabili dall'artefatto stesso prima di tentare qualsiasi modifica.

Metodologia: Il Protocollo BUILD-AND-FIND

Gli autori propongono BUILD-AND-FIND, un protocollo progettato per valutare il recupero basato su evidenze dell'artefatto. Questo approccio separa la capacità di costruire codice dalla capacità di recuperare l'intento da tale codice.

Ruoli Principali

1. Costruttore (Builder): Riceve una specifica nascosta (che definisce comportamenti intenzionali e scelte di progettazione) e genera un codice sorgente autonomo.
2. Ricerca (Finder): Riceve solo il codice sorgente generato e un banco di domande a scelta multipla tracciato sulla specifica. La specifica nascosta rimane inaccessibile. Il ricercatore deve ispezionare i file, effettuare chiamate agli strumenti e rispondere alle domande basandosi esclusivamente sull'artefatto.

Livelli di Valutazione

Il protocollo definisce tre distinti livelli di valutazione:

1. Correttezza Comportamentale: Il codice supera i test? (Focus standard dei benchmark).
2. Recuperabilità dell'Intento dal Lato dell'Artefatto: Un agente a valle può recuperare i comportamenti intenzionali e le scelte di progettazione dal solo artefatto? (Il focus di BUILD-AND-FIND).
3. Successo della Modifica a Valle: Un agente successivo può modificare in sicurezza il repository? (Lavoro futuro).

Metriche e Controlli

Il protocollo riporta quattro metriche chiave, con una gerarchia rigorosa di interpretazione:

• Accuratezza del Recupero: Accuratezza di corrispondenza esatta sul banco di domande.
• Stabilità/Ripetibilità: Coerenza delle risposte attraverso prove ripetute.
• Copertura dell'Implementazione: La frazione di affermazioni della specifica effettivamente implementate nell'artefatto (verificata per garantire che i ricercatori non siano penalizzati per affermazioni "gold" non implementate).
• Sforzo di Ispezione: Misurato in byte di ispezione nuovi dell'agente (nuovi byte recuperati tramite chiamate agli strumenti, escludendo prompt di sistema e sovraccarico di trasporto).

Vincolo Cruciale: Lo sforzo di ispezione è interpretato come un proxy per la leggibilità dell'artefatto solo dopo che sono stati superati i gate di accuratezza e stabilità del recupero. Se il recupero fallisce, lo sforzo è privo di significato.

Controlli:

• Solo Domande: I ricercatori vedono solo le domande (misura i prior generici di ingegneria).
• Solo Specifica: I ricercatori vedono la specifica (misura la rispondibilità al limite superiore).
• Fallimento di Compilazione: Gli artefatti che falliscono la compilazione sono mantenuti come diagnosi di stress.
• Audit delle Evidenze: Controlli post-hoc per verificare se le risposte corrette citano evidenze specifiche dell'artefatto (file sorgente, configurazioni) piuttosto che fare affidamento sui prior.

Contributi Chiave

1. Obiettivo di Valutazione: Definisce il recupero basato su evidenze dell'artefatto come un livello distinto tra la correttezza comportamentale e la modifica a valle.
2. Protocollo Costruttore-Ricerca: Un framework a ruoli separati in cui i costruttori codificano specifiche nascoste nel codice, e i ricercatori tentano di decodificarle senza vedere la specifica.
3. Contratto di Misurazione: Uno standard rigoroso di reporting che separa l'accuratezza (validità) dallo sforzo (leggibilità), garantendo che lo sforzo sia analizzato solo quando il recupero è affidabile.
4. Calibrazione e Rilascio: Un rilascio completo che include l'harness, i compiti (scratch_minidb, scratch_nanoweb), gli artefatti generati, le tabelle canoniche e gli audit delle evidenze. Include diagnosi per l'affinità costruttore-ricerca e la sensibilità ai prior bassi.

Risultati Empirici

Lo studio ha valutato 12 configurazioni di agenti (inclusi GPT-5.5, Opus 4.7, Sonnet 4.6 e varianti MiMo) su due famiglie di compiti.

• Regime di Alto Recupero: Nel pacchetto di compiti ad alto prior rilasciato, l'accuratezza del recupero è vicina alla saturazione (ad esempio, ~98,9% per le esecuzioni condizionate all'artefatto contro il 94,5% per le sole domande). Poiché l'accuratezza è alta, funge principalmente da gate piuttosto che da segnale discriminante.
• Sforzo di Ispezione come Discriminatore: Con i gate di recupero superati, lo sforzo di ispezione condizionato diventa la metrica principale per confrontare la leggibilità degli artefatti.
  • GPT-5.5 ha dimostrato lo sforzo di ispezione più basso (alta leggibilità), con un punteggio di sforzo relativo ($R_b$) di 1,033 nel pannello ad alto sforzo.
  • Le varianti MiMo hanno generalmente richiesto uno sforzo di ispezione più elevato.
  • Claude Sonnet 4.6 e Opus 4.7 hanno mostrato livelli intermedi di sforzo, con alcune variazioni in base alle impostazioni dello sforzo di ragionamento (alto vs. basso).
• Affinità: Lo studio ha rilevato che la leggibilità può dipendere dal lettore. Le coppie costruttore-ricerca della stessa famiglia (ad esempio, costruttore OpenAI + ricercatore OpenAI) hanno mostrato residui di affinità positivi, suggerendo che recuperano l'intento più facilmente rispetto alle coppie di famiglie diverse.
• Audit delle Evidenze: In un campione di 72 risposte corrette, 65 erano "supportate" da evidenze dell'artefatto citate (principalmente file sorgente), confermando che in questa configurazione un'alta accuratezza generalmente si correla con un ragionamento basato sull'artefatto.

Significato e Affermazioni

Il documento afferma che BUILD-AND-FIND stabilisce un contratto di valutazione necessario per i codici sorgente gestiti da agenti. Il suo significato risiede in:

• Spostamento del Focus: Passare dal "funziona?" al "è comprensibile per un altro agente?".
• Proxy di Leggibilità: Trattare lo sforzo di ispezione come un proxy misurabile di quanto bene un artefatto comunichi l'intento di progettazione, purché il recupero sia stabile.
• Separazione delle Preoccupazioni: Disaccoppiare esplicitamente la capacità di implementazione dalla capacità di recuperare l'intento, consentendo un'analisi più sfumata delle prestazioni degli agenti.
• Framework Auditabile: Fornire un'infrastruttura riproducibile e pronta per l'audit che separa i prior generici dal recupero condizionato all'artefatto, impedendo che i benchmark siano risolti solo tramite memorizzazione o conoscenze generiche di ingegneria.

Gli autori mantengono un tono modesto, notando che le attuali affermazioni sono circoscritte al pannello e alle famiglie di compiti rilasciati. Sottolineano che il benchmark non misura la correttezza a runtime, la sicurezza o la manutenibilità umana, ma piuttosto la specifica capacità degli agenti di utilizzare i repository generati come memoria esterna e mezzo di comunicazione.