ProgramBench : tous les IA publiques obtiennent 0% au test de codage le plus difficile

ProgramBench est un nouveau benchmark de codage LLM difficile qui cible une capacité que la plupart des classements effleurent à peine : un modèle peut-il reconstruire un programme entier à partir d'un comportement observé, sans jamais voir le code source ? the-verification-horizon-why-rewarding-coding-agents-is-getting-harder

La configuration est simple mais impitoyable. Un agent reçoit un exécutable compilé et sa documentation d'utilisation. Sa mission : sonder le programme, déduire son fonctionnement, choisir une stratégie d'implémentation, écrire le code source, élaborer un script de construction et soumettre un programme candidat. La sortie est ensuite comparée à l'original via des tests comportementaux cachés.

C'est bien loin d'écrire une simple fonction, de résoudre un problème de compétition ou de corriger un dépôt connu.

Ce que ProgramBench teste et que les autres benchmarks ne testent pas

ProgramBench importe surtout pour évaluer les agents de codage plutôt que les modèles de chat. Si votre workflow est « demander au modèle d'écrire une petite fonction », ProgramBench est probablement trop difficile et trop indirect. HumanEval, LiveCodeBench et les évaluations de codage spécifiques à un langage vous en diront plus. Si votre workflow est « demander au modèle de corriger un dépôt connu », SWE-bench Pro, SWE-Rebench et SWE-bench Verified restent plus directement pertinents.

ProgramBench devient intéressant lorsque le travail est moins structuré. Pour les acheteurs de modèles, ce n'est pas encore un classement « choisissez le meilleur modèle et déployez-le ». C'est plutôt un avertissement : les agents de codage actuels trébuchent encore lorsque le code source, la description du problème et l'échafaudage disparaissent. Pour les développeurs d'agents, c'est un outil de diagnostic : il révèle si l'agent peut enquêter avant d'implémenter. the-verification-horizon-why-rewarding-coding-agents-is-getting-harder

ProgramBench est construit autour du concept de reconstruction en salle blanche. Chaque tâche commence par un exécutable compilé et une documentation. Le modèle doit décider quelles questions poser à l'exécutable. Il peut exécuter le programme avec des entrées et observer les sorties, mais il ne peut pas regarder l'implémentation sous-jacente. Cela fait de ProgramBench un benchmark pour l'architecture et la découverte de spécifications, pas seulement pour l'écriture de code.

Comment ProgramBench se compare aux principaux benchmarks de codage

La plupart des benchmarks de codage fournissent encore beaucoup de structure aux modèles. HumanEval donne une signature de fonction et une docstring. SWE-bench Verified donne un dépôt existant et un problème spécifique. LiveCodeBench donne des énoncés de problèmes de type programmation compétitive. ProgramBench retire la majeure partie de cet échafaudage. Il demande si l'agent peut reconstruire le comportement cible à partir de la seule interaction.

Cette distinction compte car le génie logiciel réel commence souvent par des spécifications partielles. Les développeurs rétro-ingénieurisent des workflows, sondent des API, explorent des systèmes vieillissants et infèrent des cas limites à partir du comportement observé. ProgramBench condense ce type de travail dans un cadre d'évaluation. why-your-ai-agent-might-ace-the-task-but-flunk-the-process-enter-skillcoach

La comparaison la plus proche est SWE-bench, mais la forme de la tâche est presque inversée. SWE-bench demande si l'agent peut modifier correctement une base de code réelle. ProgramBench demande si l'agent peut découvrir ce que fait un programme et construire une nouvelle base de code qui se comporte de manière identique. the-migration-isnt-finished-until-the-build-server-says-it-is-why-ai-agents-keep-failing-at-enterprise-java

Classement actuel : un aperçu sobre

Le classement public initial est délibérément sobre :

• Claude Opus 4.7 : 0,0 % entièrement résolu, 3,0 % presque résolu
• Claude Opus 4.6 : 0,0 % entièrement résolu, 2,5 % presque résolu
• Claude Sonnet 4.6 : 0,0 % entièrement résolu, 1,0 % presque résolu
• GPT 5.4 : 0,0 % entièrement résolu, 0,0 % presque résolu
• Gemini 3.1 Pro : 0,0 % entièrement résolu, 0,0 % presque résolu

L'indicateur principal est le nombre de tâches entièrement résolues. Chaque modèle public se situe actuellement à 0 %. ProgramBench rapporte également les tâches « presque résolues », c'est-à-dire les exécutions qui réussissent au moins 95 % des tests comportementaux. BenchLM utilise cet indicateur auxiliaire sur la page d'affichage car c'est le seul séparateur visible entre les modèles pour l'instant.

Comment lire correctement le classement

Le classement ProgramBench exige une lecture plus attentive qu'un benchmark de codage normal. Dans la plupart des classements de codage, un score plus élevé signifie directement plus de tâches résolues. Sur ProgramBench aujourd'hui, l'indicateur principal officiel est plat : tous les modèles publics évalués sont à 0 % entièrement résolus. La seule séparation provient du taux auxiliaire de « presque résolu ».

Cela signifie trois choses. Premièrement, ne surclassez pas les trois premiers actuels. Claude Opus 4.7 en tête avec 3,0 % de presque résolus est un signal significatif qu'il s'est approché plus souvent, mais ce n'est pas un taux de succès pour la production. Deuxièmement, ne traitez pas 0,0 % de presque résolus comme une qualité de modèle identique. Un modèle peut échouer à ProgramBench de nombreuses façons. Troisièmement, attendez-vous à ce que les effets de cadre comptent : ProgramBench est un benchmark d'agent, pas un benchmark de modèle pur.

Échecs exposés : pourquoi les scores sont proches de zéro

Les faibles scores de ProgramBench exposent plusieurs modes d'échec à la fois. Un sondage superficiel amène les agents à inférer trop à partir de trop peu d'observations. L'implémentation prématurée, encouragée par de nombreux workflows d'agents optimisés pour une édition rapide, nuit lorsque le défi principal est de découvrir la spécification. Les cas négatifs manquants signifient que les agents négligent les indicateurs invalides, les erreurs et les codes de sortie. Une architecture faible sans squelette conduit à des implémentations fragiles qui ne peuvent pas passer à l'échelle. Un mauvais auto-test empêche les agents de valider leurs remplacements. La confiance excessive est un problème pratique sérieux : les agents déclarent souvent la tâche terminée et soumettent un travail incomplet, comme noté dans la discussion de lancement de LocalLLaMA. La fragilité de la boucle d'outils peut tuer même les modèles de base solides.

Ces modes d'échec sont précisément la raison pour laquelle ProgramBench est utile. C'est aussi pourquoi un futur classement public devrait rapporter plus d'un chiffre. Pour une analyse sérieuse, nous avons besoin de savoir si les échecs proviennent d'un mauvais sondage, d'un mauvais code, de constructions échouées, de limites de temps, de cas limites manquants ou de mauvaises décisions d'arrêt. why-your-ai-agent-might-ace-the-task-but-flunk-the-process-enter-skillcoach

Comment exécuter ProgramBench

L'équipe a publié le dépôt GitHub, les ensembles de données Hugging Face et les matériaux Docker/d'inférence. Le workflow local de base consiste à installer le package et à évaluer une soumission avec programbench eval. Les agents doivent respecter la configuration du benchmark : pas d'accès Internet, pas de recherche directe de source et pas de raccourcis de décompilation. Pour les équipes construisant des agents de codage, la valeur pratique réside moins dans la poursuite du classement actuel que dans la réalisation d'expériences internes contrôlées.

Prochaines étapes pour le benchmark

ProgramBench deviendra plus utile si les soumissions publiques séparent la qualité du modèle de la qualité du cadre, si les résultats des modèles open-weight obtiennent une couverture plus large et si l'indicateur principal résolu évolue. BenchML suit ProgramBench sur une page de benchmark dédiée et le maintient affiché uniquement sur le classement de codage jusqu'à ce que le signal devienne plus stable. Pour l'instant, il est préférable de le traiter comme un feu d'avertissement de pointe sur les limites des agents de codage actuels en reconstruction en salle blanche. all-llms-corrupt-your-documents-when-you-delegate-a-close-look-at-the-delegate-52-benchmark