SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration

Le papier présente SWE-CI, le premier benchmark de niveau dépôt basé sur l'intégration continue, conçu pour évaluer la capacité des agents LLM à maintenir la qualité du code sur le long terme au-delà des simples corrections statiques.

L'essentiel

🚀 Le Concept : Au-delà du "Patch Rapide"

Imaginez que vous engagez un architecte pour rénover une vieille maison.

• Les anciens tests (comme SWE-bench) demandaient à l'IA : "Voici une fenêtre cassée. Répare-la maintenant." Si l'IA collait un morceau de scotch, elle était notée "parfaite" car la fenêtre ne laissait plus passer le vent.
• Le problème : Dans la vraie vie, on ne répare pas juste une fenêtre. On doit agrandir la maison, ajouter une cuisine, changer les fondations, et tout cela sur plusieurs années. Si l'IA a mis du scotch, la prochaine fois qu'on veut ajouter une cuisine, tout s'effondre.

SWE-CI est un nouveau test qui ne demande pas à l'IA de faire un "patch rapide". Il lui demande de gérer la maison pendant 200 jours, en faisant des centaines de petites modifications, tout en s'assurant que la maison ne s'écroule pas à chaque étape.

🏗️ La Méthode : Le Duo "Architecte" et "Maçon"

Pour simuler cette réalité complexe, les chercheurs ont créé un système avec deux agents IA qui travaillent ensemble, comme dans une vraie équipe de développement :

1. L'Architecte (Le Chef de Projet) : Il regarde ce qui ne va pas (les tests qui échouent) et dit : "Il faut qu'on ajoute une nouvelle porte ici, mais attention, ne cassons pas le mur du fond." Il écrit un cahier des charges.
2. Le Maçon (Le Codeur) : Il lit le cahier des charges et modifie le code (les briques de la maison).

Ensuite, on teste la maison. Si ça passe, on passe à la prochaine étape. Si ça casse, on recommence. C'est une boucle infinie appelée Intégration Continue.

📊 Le Score : "EvoScore" (Le Score d'Évolution)

Comment juge-t-on si l'IA est bonne ?

• L'ancien système disait : "Tu as réparé la fenêtre ? Bravo, 10/10."
• Le nouveau système (EvoScore) dit : "Tu as réparé la fenêtre, mais est-ce que tu as rendu le mur si fragile que le prochain maçon ne pourra plus rien y accrocher ?"

Si l'IA fait un travail propre et solide, elle gagne des points. Si elle fait un travail "sale" (qu'on appelle de la dette technique, comme empiler des cartons dans un couloir), elle perd des points à chaque nouvelle modification, car cela devient de plus en plus dur de continuer.

🔍 Ce que les chercheurs ont découvert (Les Résultats)

Ils ont testé les IA les plus puissantes du monde sur 100 scénarios réels (des projets qui ont évolué sur 233 jours en moyenne). Voici ce qu'ils ont vu :

1. Les IA s'améliorent vite : Les modèles les plus récents sont bien meilleurs que les anciens, un peu comme un joueur de tennis qui s'entraîne tous les jours.
2. Le style compte : Certaines IA préfèrent aller vite (gagner le point tout de suite), d'autres préfèrent jouer pour le long terme (construire une stratégie). Cela dépend de la "famille" de l'IA (Google, OpenAI, etc.).
3. Le gros problème : La "Chute" (Regression) : C'est le point le plus important. Même les meilleures IA ont du mal à ne pas casser ce qui fonctionnait déjà.
   • Analogie : Imaginez que vous réparez la plomberie, mais que vous faites fuir le robinet de la cuisine.
   • Résultat : La plupart des IA réussissent à peine à éviter de casser quelque chose dans 25 % des cas sur le long terme. Elles sont excellentes pour résoudre un problème isolé, mais elles oublient souvent les conséquences de leurs actions sur le futur.

💡 En Résumé

SWE-CI nous dit que l'avenir de l'IA ne consiste pas seulement à écrire du code qui fonctionne aujourd'hui, mais à écrire du code qui reste solide et facile à modifier demain.

C'est la différence entre un bricoleur du dimanche qui répare un robinet avec du ruban adhésif (ça marche tout de suite, mais ça lâche demain) et un maître artisan qui pose des tuyaux en cuivre (ça prend du temps, mais ça dure des décennies). Aujourd'hui, nos IA sont encore trop souvent des bricoleurs du dimanche.

Résumé technique

Titre : SWE-CI : Évaluation des capacités des agents à maintenir des bases de code via l'Intégration Continue

1. Problématique

Bien que les agents pilotés par de grands modèles de langage (LLM) aient démontré des performances impressionnantes dans l'automatisation de tâches d'ingénierie logicielle (comme la correction de bugs statiques via des benchmarks tels que SWE-bench), une lacune fondamentale persiste.

• Limitation des benchmarks existants : La plupart des évaluations actuelles suivent un paradigme "instantané" (snapshot) : l'agent reçoit une exigence unique et doit produire une solution en une seule fois (one-shot).
• La réalité du développement logiciel : Dans la pratique, le développement logiciel mature repose sur des changements de exigences complexes et des itérations de fonctionnalités à long terme. Un code qui passe tous les tests initiaux peut être difficilement maintenable si sa structure est fragile.
• Le besoin : Il manque un cadre d'évaluation capable de mesurer la capacité d'un agent à maintenir la qualité du code sur le long terme, où les décisions prises tôt dans le processus impactent la facilité des modifications futures (dette technique).

2. Méthodologie

Le papier propose SWE-CI, le premier benchmark au niveau du dépôt (repository-level) basé sur une boucle d'Intégration Continue (CI) dynamique.

A. Formalisation de la tâche (Évaluation basée sur l'évolution)
Contrairement aux approches statiques où l'exigence est fixe, SWE-CI adopte une boucle itérative :

1. Définition : Soit $c_0$ la base de code initiale et $c^*$ la cible (oracle).
2. Boucle : À chaque itération $i$, l'agent génère une exigence $r_i$ basée sur l'écart entre le code actuel $c_i$ et l'oracle, puis met à jour le code $c_{i+1}$.
3. Objectif : L'agent doit passer tous les tests associés à l'oracle après plusieurs cycles d'analyse et de codage.

B. Métriques d'évaluation

• Changement Normalisé ($a(c)$) : Une métrique asymétrique qui mesure l'amélioration par rapport à la base ($c_0$) et par rapport à la cible ($c^*$). Elle pénalise les régressions (tests qui passent puis échouent) et récompense les améliorations, normalisant le score sur une échelle de $[-1, 1]$.
• EvoScore (Evolution Score) : Une métrique agrégée calculée comme une moyenne pondérée des changements normalisés sur toutes les itérations.
  • Formule : $e = \frac{\sum \gamma^i a(c_i)}{\sum \gamma^i}$
  • Le paramètre $\gamma \ge 1$ accorde un poids plus important aux itérations tardives. Cela récompense les agents qui maintiennent une codebase facile à modifier au fil du temps, plutôt que ceux qui obtiennent des gains rapides mais accumulent de la dette technique.

C. Protocole d'évaluation : Agent Architecte-Programmeur
Pour simuler un environnement de développement réel, SWE-CI utilise deux agents collaboratifs :

1. L'Agent Architecte : Analyse les échecs de tests, identifie les causes racines et rédige un document d'exigences à haut niveau (naturel, incrémental, limitant le nombre de tâches urgentes).
2. L'Agent Programmeur : Comprend les exigences, planifie l'implémentation et écrit le code pour satisfaire ces exigences sans avoir accès direct à l'écart de tests (simulant le flux CI).

D. Construction des Données (Data Curation)
Le dataset comprend 100 tâches extraites de 68 dépôts GitHub réels (Python).

• Critères de sélection : Dépôts maintenus depuis 3+ ans, >500 étoiles, licence permissive, présence de tests unitaires.
• Processus : Extraction de séquences de commits où les dépendances restent inchangées, filtrage pour s'assurer d'un écart significatif (au moins 500 lignes modifiées, 233 jours d'historique en moyenne, 71 commits consécutifs).
• Environnement : Chaque tâche est livrée avec un environnement Docker pré-construit pour garantir la reproductibilité.

3. Résultats Expérimentaux

Les auteurs ont évalué 18 modèles de différents fournisseurs (Claude, GPT, GLM, DeepSeek, etc.) en consommant plus de 10 milliards de tokens.

• Progression des capacités : Les capacités de maintenance des LLMs s'améliorent rapidement. Les modèles plus récents (post-2026) obtiennent des scores nettement supérieurs, indiquant une évolution vers la maintenance à long terme. La série Claude Opus et GLM-5 se distinguent comme les meilleurs performants.
• Influence de la stratégie de maintenance (Paramètre $\gamma$) :
  • Les modèles de différents fournisseurs montrent des préférences différentes. MiniMax, DeepSeek et GPT privilégient les gains à long terme (scores élevés avec $\gamma > 1$), tandis que Kimi et GLM semblent optimiser pour des gains immédiats.
  • Cela suggère que les stratégies d'entraînement varient selon les fournisseurs.
• Problème de régression (Zero-Regression Rate) :
  • C'est le point faible majeur. La majorité des modèles ont un taux de "zéro régression" inférieur à 0,25 (moins de 25 % des tâches où aucun test n'a échoué après avoir passé).
  • Seuls deux modèles de la série Claude Opus dépassent 0,5.
  • Conclusion : Bien que les LLMs soient bons pour la modification de code statique, ils peinent encore à éviter la dégradation de la qualité (régressions) lors de cycles de maintenance longs et multi-tours.

4. Contributions Clés

1. Changement de paradigme : Passage d'une évaluation statique (correctitude fonctionnelle immédiate) à une évaluation dynamique (maintenabilité à long terme via CI).
2. SWE-CI Benchmark : Création d'un dataset réaliste de 100 tâches complexes, basées sur l'histoire réelle de développement de dépôts Python, avec des environnements d'exécution reproductibles.
3. Nouvelle Métrique (EvoScore) : Introduction d'une métrique pondérée temporellement pour quantifier la dette technique et la stabilité du code au fil des itérations.
4. Protocole Dual-Agent : Mise en place d'une interaction Architecte/Programmeur pour mimer les flux de travail professionnels et l'itération continue.

5. Signification et Impact

Ce travail est crucial car il met en lumière une faille critique dans l'état de l'art actuel des agents de codage : la capacité à écrire du code fonctionnel ne garantit pas la capacité à le maintenir.

• Pour la recherche : SWE-CI offre un nouveau standard pour évaluer la robustesse des agents au-delà des tests unitaires simples, en se concentrant sur la durabilité du code.
• Pour l'industrie : Il souligne que pour une adoption réelle des agents IA dans le cycle de vie logiciel (SDLC), il faut non seulement qu'ils corrigent des bugs, mais qu'ils évitent d'introduire de la dette technique qui rendrait le code ingérable à l'avenir.
• Perspective : Les résultats indiquent que malgré les progrès rapides, les LLMs actuels ne sont pas encore prêts pour un développement logiciel entièrement automatisé et à long terme sans supervision humaine stricte pour gérer les régressions.