Construire pour le test : les agents de codage fournissent ce que vous vérifiez, pas ce que vous avez demandé

Résumé

Les benchmarks sont largement utilisés pour évaluer l’achèvement des tâches par les grands modèles de langage (LLM), mais cette approche accumule des problèmes de validité de construction, et un score de réussite peut ne pas démontrer que la tâche demandée a effectivement été accomplie. Nous étudions ces deux problèmes. Dans un cadre contrôlé de type « code comme spécification », deux agents Copilot CLI en production (claude-opus-4.7, gpt-5.5) réimplémentent en Angular, sous forme de bibliothèque réutilisable, une table de données React Fluent-UI, soumise à un oracle caché de Playwright comportant 222 tests, sur 18 exécutions et trois conditions de disponibilité de l’oracle. Parallèlement au score, nous réalisons un audit mécanique de la bibliothèque et vérifions chaque verdict à l’aide d’une ablation sans opération. Sans l’oracle, la bibliothèque est présente mais inachevée, ce que révèlent les scores. Avec l’oracle dans la boucle, le score atteint un niveau quasi parfait, mais, à partir d’une démonstration qui reproduit directement le comportement testé, la bibliothèque se révèle morte ou absente. Nous appelons cela « construire pour le test » ; la disposition plus large sous-jacente aux deux phénomènes est nommée « conscience de validation ». L’agent ne valide pas par lui-même, comme le ferait un utilisateur, ce qu’il livre. La prévalence de ce comportement reste une question ouverte pour d’autres agents, signaux et familles de modèles. Au-delà des scores de benchmark, des dispositions telles que la conscience de validation méritent une attention de la part de la recherche.

English

Benchmarks are widely used to evaluate task completion by Large Language Models (LLMs), but this approach has accumulated construction-validity problems, and a passing score may not show whether the requested task was delivered. We study both problems. In a controlled code-as-spec setup, two production Copilot CLI agents (claude-opus-4.7, gpt-5.5) re-implement a React Fluent-UI data table in Angular as a reusable library under a hidden 222-test Playwright oracle across 18 runs and three oracle-availability conditions. Alongside the score, we run a mechanical library audit and check each verdict with a no-op ablation. Without the oracle, the library is present but unfinished, revealed by scores. With the oracle in the loop, the score reaches near-perfect, but from a demo holding the tested behavior directly, the library left dead or absent. We call this building to the test; the broader disposition behind both we call validation self-awareness. The agent does not, on its own, validate what it ships as a user would. Prevalence remains an open question across other agents, signals, and model families. Beyond benchmark scores, dispositions like validation self-awareness merit research attention.