Résumé technique : BUILD-AND-FIND

Énoncé du problème

Les benchmarks actuels des agents de code évaluent principalement la correction comportementale (par exemple, la réussite des tests unitaires). Cependant, à mesure que les agents passent de la synthèse de fonctions à l'ingénierie au niveau du dépôt, les bases de code générées servent de plus en plus d'artefacts intermédiaires : un agent écrit un dépôt, et des agents subséquents doivent l'inspecter, l'auditer ou l'étendre. Dans ce contexte, un dépôt n'est pas simplement une réponse à une tâche, mais un artefact de communication.

L'article identifie un écart : un dépôt peut passer des tests comportementaux visibles tout en échouant à exposer clairement l'intention de conception et les choix sous-jacents à ce comportement. Si un dépôt généré dissimule son intention, il impose une charge d'inspection supplémentaire aux agents en aval, même si le code fonctionne correctement. Les benchmarks existants ne mesurent pas si les décisions intentionnelles sont récupérables à partir de l'artefact lui-même avant toute tentative de modification.

Méthodologie : le protocole BUILD-AND-FIND

Les auteurs proposent BUILD-AND-FIND, un protocole conçu pour évaluer la récupération étayée par l'artefact. Cette approche sépare la capacité de construire du code de la capacité de récupérer l'intention à partir de ce code.

Rôles principaux

1. Constructeur (Builder) : Reçoit une spécification cachée (définissant les comportements souhaités et les choix de conception) et génère une base de code autonome.
2. Détecteur (Finder) : Reçoit uniquement la base de code générée et une banque de questions à choix multiples tracées à partir de la spécification. La spécification cachée reste inaccessible. Le détecteur doit inspecter les fichiers, effectuer des appels d'outils et répondre aux questions en se basant uniquement sur l'artefact.

Couches d'évaluation

Le protocole définit trois couches d'évaluation distinctes :

1. Correction comportementale : Le code passe-t-il les tests ? (Focus standard des benchmarks).
2. Récupérabilité de l'intention côté artefact : Un agent en aval peut-il récupérer les comportements souhaités et les choix de conception à partir de l'artefact seul ? (Le focus de BUILD-AND-FIND).
3. Succès de la modification en aval : Un agent ultérieur peut-il modifier le dépôt en toute sécurité ? (Travail futur).

Métriques et contrôles

Le protocole rapporte quatre métriques clés, avec une hiérarchie stricte d'interprétation :

• Précision de récupération : Précision de correspondance exacte sur la banque de questions.
• Stabilité/Reproductibilité : Cohérence des réponses sur des essais répétés.
• Couverture de l'implémentation : La fraction des affirmations de la spécification effectivement implémentées dans l'artefact (auditées pour s'assurer que les détecteurs ne sont pas pénalisés pour des affirmations or non implémentées).
• Effort d'inspection : Mesuré en octets d'inspection nouveaux par agent (nouveaux octets récupérés via des appels d'outils, excluant les invites système et la surcharge de transport).

Contrainte cruciale : L'effort d'inspection n'est interprété comme un proxy de la lisibilité de l'artefact qu'après que les seuils de précision de récupération et de stabilité sont franchis. Si la récupération échoue, l'effort est sans signification.

Contrôles :

• Questions uniquement : Les détecteurs ne voient que les questions (mesure les priors génériques d'ingénierie).
• Spécification uniquement : Les détecteurs voient la spécification (mesure la réponse maximale possible).
• Échec de compilation : Les artefacts qui échouent à la compilation sont conservés comme diagnostics de stress.
• Audit de preuve : Vérifications a posteriori pour vérifier si les réponses correctes citent des preuves spécifiques de l'artefact (fichiers sources, configurations) plutôt que de s'appuyer sur des priors.

Contributions clés

1. Cible d'évaluation : Définit la récupération étayée par l'artefact comme une couche distincte entre la correction comportementale et la modification en aval.
2. Protocole Constructeur–Détecteur : Un cadre à rôles séparés où les constructeurs encodent des spécifications cachées dans le code, et les détecteurs tentent de les décoder sans voir la spécification.
3. Contrat de mesure : Une norme de rapport rigoureuse séparant la précision (validité) de l'effort (lisibilité), garantissant que l'effort n'est analysé que lorsque la récupération est fiable.
4. Calibration et publication : Une publication complète incluant le dispositif, les tâches (scratch_minidb, scratch_nanoweb), les artefacts générés, les tableaux canoniques et les audits de preuve. Elle inclut des diagnostics pour l'affinité constructeur–détecteur et la sensibilité aux faibles priors.

Résultats empiriques

L'étude a évalué 12 configurations d'agents (incluant GPT-5.5, Opus 4.7, Sonnet 4.6 et des variantes MiMo) sur deux familles de tâches.

• Régime de récupération élevé : Dans le pack de tâches à fort prior publié, la précision de récupération est proche de la saturation (par exemple, ~98,9 % pour les exécutions conditionnées par l'artefact contre 94,5 % pour les questions uniquement). Comme la précision est élevée, elle sert principalement de seuil plutôt que de signal discriminant.
• Effort d'inspection comme discriminateur : Une fois les seuils de récupération franchis, l'effort d'inspection conditionnel devient la métrique principale pour comparer la lisibilité des artefacts.
  • GPT-5.5 a démontré le plus faible effort d'inspection (haute lisibilité), avec un score d'effort relatif ($R_b$) de 1,033 dans le panneau à fort effort.
  • Les variantes MiMo ont généralement nécessité un effort d'inspection plus élevé.
  • Claude Sonnet 4.6 et Opus 4.7 ont montré des niveaux d'effort intermédiaires, avec certaines variations selon les paramètres d'effort de raisonnement (élevé vs faible).
• Affinité : L'étude a révélé que la lisibilité peut dépendre du lecteur. Les paires constructeur–détecteur de la même famille (par exemple, constructeur OpenAI + détecteur OpenAI) ont montré des résidus d'affinité positifs, suggérant qu'elles récupèrent l'intention plus facilement que les paires de familles différentes.
• Audit de preuve : Sur un échantillon de 72 réponses correctes, 65 étaient « soutenues » par des preuves d'artefact citées (principalement des fichiers sources), confirmant que dans cette configuration, une haute précision est généralement corrélée à un raisonnement ancré dans l'artefact.

Signification et affirmations

L'article affirme que BUILD-AND-FIND établit un contrat d'évaluation nécessaire pour les bases de code gérées par des agents. Sa signification réside dans :

• Changement de focus : Passer de « cela fonctionne-t-il ? » à « est-ce compréhensible par un autre agent ? ».
• Proxy de lisibilité : Traiter l'effort d'inspection comme un proxy mesurable de la façon dont un artefact communique l'intention de conception, à condition que la récupération soit stable.
• Séparation des préoccupations : Découpler explicitement la capacité d'implémentation de la capacité de récupérer l'intention, permettant une analyse plus nuancée de la performance des agents.
• Cadre auditable : Fournir une infrastructure reproductible et prête à l'audit qui sépare les priors génériques de la récupération conditionnée par l'artefact, empêchant les benchmarks d'être résolus par la mémorisation ou les connaissances générales en ingénierie seules.

Les auteurs restent modestes, notant que les affirmations actuelles sont limitées au panneau publié et aux familles de tâches. Ils soulignent que le benchmark ne mesure pas la correction d'exécution, la sécurité ou la maintenabilité humaine, mais plutôt la capacité spécifique des agents à utiliser les dépôts générés comme mémoire externe et support de communication.