EvoCode-Bench: Evaluating Coding Agents in Multi-Turn Iterative Interactions
En 3 lignesEvoCode-Bench évalue 13 agents de codage sur 26 tâches avec 5-15 tours itératifs. Les agents doivent maintenir un codebase fonctionnel face à des changements de spécifications. Résultat : écart de 22-40 points entre performance single-round (SR) et multi-tour (MT@4), avec succès <50% en multi-tour et dégradation progressive (taux de réussite divisé par 2 au tour 5).
## EvoCode-Bench : quand les agents de code s'effondrent dès le 5e tour
### 1. Ce qui est mesuré — et pourquoi ça manquait
La quasi-totalité des benchmarks de génération de code (HumanEval, MBPP, SWE-bench dans sa forme classique) évaluent une tâche atomique : une spécification → une solution → un verdict. Ce protocole ignore la réalité du développement logiciel, où les exigences évoluent et où le code produit au tour N doit rester fonctionnel au tour N+5. EvoCode-Bench comble ce vide avec 26 tâches *stateful* et 227 rounds évalués, chaque tâche s'étendant sur 5 à 15 tours itératifs. L'espace de travail de l'agent est préservé entre les tours — les fichiers écrits au tour 1 sont toujours là au tour 8. Les tests sont cumulatifs : chaque nouveau round vérifie les nouvelles exigences *et* toutes les exigences antérieures encore actives. C'est un test de régression automatisé intégré au benchmark lui-même.
### 2. Les chiffres qui comptent
Deux métriques structurent l'analyse : - **SR (Single-Round)** : score sur un état de référence pré-complété, équivalent au paradigme classique. - **MT@4** : score multi-tour avec 4 tentatives maximum par round avant arrêt sur échec.
L'écart SR − MT@4 varie de **22 à 40 points** selon les agents. Ce n'est pas un artefact de difficulté intrinsèque des tâches : c'est la dégradation causée par l'accumulation d'état et le suivi de spécifications changeantes.
Le cas le plus instructif : l'agent au **SR le plus élevé (78,9)** ne se classe que **troisième en MT@4 (44,0)**. Un agent capable de résoudre des problèmes isolés avec excellence peut être médiocre dès qu'il doit maintenir un codebase cohérent sur la durée. Les classements établis par les benchmarks single-round sont donc partiellement trompeurs pour prédire l'utilité réelle en développement itératif.
Autre donnée critique : **le taux de réussite agrégé passe sous 50% du score du round 1 dès le round 5**. Autrement dit, même les meilleurs agents voient leur performance divisée par deux en cinq tours. Aucun agent ne dépasse ~50% de succès sur les métriques multi-tours.
### 3. Comportements différenciés par niveau
L'analyse des échecs révèle une stratification nette : - **Agents faibles** : échec précoce, souvent dès les premiers tours, sur des tâches de base. - **Agents forts** : survivent plus longtemps mais exposent des défaillances qualitativement différentes — *specification tracking* (perte de contexte sur les exigences antérieures) et *regression failures* (modifications qui cassent du code précédemment fonctionnel).
Cette distinction est importante pour l'ingénierie des agents : les problèmes des agents forts ne sont pas des problèmes de capacité de génération de code brute, mais de gestion de contexte long et de cohérence d'état. Ce sont des problèmes d'architecture (fenêtre de contexte, mémoire externe, stratégie de relecture du codebase) autant que de modèle.
### 4. Infrastructure Harbor et implications pratiques
Les auteurs publient également **Harbor**, l'infrastructure multi-tour utilisée pour orchestrer les évaluations. C'est potentiellement aussi important que le benchmark lui-même : Harbor permet de rejouer des séquences de tours avec préservation d'état, ce qui ouvre la voie à des évaluations reproductibles d'agents dans des scénarios itératifs.
**Perdants directs de cette publication :** - Les agents dont le SR élevé masquait une faiblesse multi-tour — leur positionnement marketing devient contestable. - Les équipes qui ont optimisé leurs agents exclusivement sur HumanEval/MBPP : ces benchmarks ne prédisent pas le comportement en contexte itératif. - Les évaluations internes d'entreprises basées sur des métriques single-round pour décider de déployer des agents de code en production.
**Ce que ça change concrètement :** avant EvoCode-Bench, il n'existait pas de protocole standardisé pour mesurer la dégradation progressive des agents de code. Les praticiens qui déploient des agents sur des tâches de refactoring, de maintenance ou d'évolution de features travaillaient sans signal quantitatif sur la fiabilité au-delà du premier tour. Avec 26 tâches, 227 rounds et une infrastructure open-source, le benchmark est suffisamment concret pour être intégré dans des pipelines d'évaluation internes — même si 26 tâches restent un corpus limité pour des conclusions définitives sur des domaines spécifiques.
Résumé généré par Claude — vérifié par l'humain