SWE-agent : comment la conception d'interface libère l'ingénierie logicielle automatisée

La semaine dernière, j'ai lu l'article sur SWE-bench et j'en suis reparti avec une conclusion simple : GPT-4 brut résout à peine 1,96 % des problèmes réels de GitHub. Cette semaine, je voulais comprendre la question suivante : qu'est-ce qui fait réellement bouger ce chiffre ? SWE-agent par Yang et al. (NeurIPS 2024) y répond, et la réponse est d'une simplicité désarmante : de meilleures interfaces.

L'article

SWE-agent (John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan et Ofir Press ; Princeton / Stanford) introduit le concept d'Interface Agent-Ordinateur (ACI) — une couche logicielle conçue sur mesure se situant entre un LLM et un environnement Linux, conçue non pas pour les utilisateurs humains, mais pour la façon dont les modèles de langage traitent réellement l'information. L'affirmation est que la conception de cette interface, et non le modèle sous-jacent, est le principal goulot d'étranglement pour les agents d'ingénierie logicielle autonomes.

Le système opère sur les tickets GitHub de SWE-bench : il lit le problème, navigue dans le dépôt, localise le code pertinent, l'édite et exécute des tests pour vérifier le correctif. La contribution novatrice n'est pas un nouveau modèle ou une procédure d'entraînement, mais un ensemble de primitives de commande et de formats de retour soigneusement conçus qui remplacent le shell Linux par défaut.

Idées clés

• L'interface surpasse le shell brut de 10,7 points de pourcentage. Lors d'une ablation sur 300 instances de SWE-bench Lite, SWE-agent résout 10,7 points de plus qu'un agent par ailleurs identique placé dans un shell Linux nu. C'est le levier le plus important de l'article.
• Visionneur de fichiers avec des fenêtres de 100 lignes. Plutôt que d'utiliser cat sur des fichiers entiers, l'ACI affiche environ 100 lignes par tour avec des commandes de défilement. Trop peu de contexte (30 lignes) coûte 3,7 points ; trop (le fichier entier) fait perdre le focus au modèle. La zone idéale est étroite.
• Un linter dans la boucle d'édition. Chaque commande d'édition exécute un vérificateur de syntaxe avant de valider la modification. Cela empêche le modèle de rester bloqué dans des états de code cassés qu'il est difficile de quitter par le seul langage naturel.
• Recherche de répertoire minimaliste. Au lieu d'un grep -r avec le contexte environnant (qui submergeait le modèle), l'ACI ne renvoie qu'une liste de noms de fichiers correspondants. Moins, c'est plus quand le modèle doit décider où regarder ensuite.
• Résultat complet du benchmark : 12,47 % sur SWE-bench avec GPT-4 Turbo, contre 3,8 % pour un système RAG non interactif et 1,96 % pour la base de référence de récupération simple de l'article original SWE-bench. HumanEvalFix a atteint 87,7 %.
• La conception ACI se généralise. Une variante en cybersécurité (SWE-agent EnIGMA) a appliqué la même philosophie ACI aux défis CTF, atteignant 13,5 % — trois fois plus performant que les systèmes précédents — en utilisant des outils d'agents interactifs qui maintiennent des sessions shell simultanées.

Ce qui tient la route — et ce qui ne la tient pas

L'idée centrale — que la conception de l'interface pour les agents est aussi importante que l'ingénierie de prompt — est bien étayée et je la trouve véritablement utile. L'ablation est honnête : les auteurs isolent les composants et montrent la contribution de chacun. Le gain de 10,7 points par rapport à la base de référence du shell brut est un résultat net qui ne peut pas être expliqué par des différences de modèle.

Ce qui me convainc moins : le benchmark lui-même. L'ensemble de tests SWE-bench contient des problèmes dont la complexité, l'ambiguïté et la précision du patch de référence varient énormément. Une variance élevée dans la qualité des tickets signifie que le chiffre de 12,47 % est en partie une déclaration sur les tickets qui se sont retrouvés dans l'ensemble d'évaluation. Les auteurs le notent implicitement en rapportant les résultats sur SWE-bench Lite (300 tickets) pour les ablations, mais la variance au sein de ce sous-ensemble reste élevée.

La limite la plus importante est la portée : SWE-bench mesure la résolution d'un seul ticket de manière isolée. Il n'y a pas de mémoire de session entre les tickets, pas de compréhension de l'historique de la base de code, et pas de suivi des dépendances multi-tickets. SWE-Bench Pro (arXiv:2509.16941, 2025) a montré plus tard que même les modèles de pointe chutent en dessous de 25 % lorsque les problèmes nécessitent des modifications coordonnées sur plusieurs fichiers — les performances se dégradent fortement à mesure que le nombre de fichiers augmente. L'ACI aide pour un ticket unique, mais le problème difficile est le cas à long horizon sur plusieurs fichiers que SWE-agent n'a jamais été conçu pour traiter.

Il y a aussi une question de reproductibilité sur laquelle je reviens sans cesse : les choix de conception de l'interface (fenêtre de 100 lignes, sortie de recherche minimaliste) ont été trouvés par expérimentation itérative sur la répartition entraînement/développement. Ces choix ne sont pas manifestement transférables à de nouveaux domaines sans un effort d'ajustement similaire. C'est un coût réel.

Pourquoi cela est important pour l'IA financière

Le cadre de l'ACI s'applique directement au problème de conception d'un agent pour Beancount. Un grand livre Beancount n'est pas une ligne de commande, mais c'est un artefact structuré qu'un modèle doit lire, parcourir et modifier. Les leçons sont transposables :

• Un visionneur de grand livre qui affiche 20 à 50 transactions à la fois — avec des commandes de défilement et de filtrage — sera plus performant qu'un outil qui déverse 10 ans de données d'un coup. Le dépassement de la fenêtre de contexte est le même mode d'échec.
• Un validateur d'écriture qui vérifie l'équilibre de la comptabilité en partie double et l'existence du compte avant de valider une écriture est l'équivalent pour le grand livre du linter de SWE-agent. Sans lui, un agent qui produit une écriture syntaxiquement fausse n'a aucune issue de secours.
• La recherche minimaliste est importante : demander « montre-moi toutes les transactions du compte X entre les dates Y et Z » devrait renvoyer une liste compacte et facile à parcourir, et non un déversement verbeux avec tout le contexte environnant.

L'article définit également un point de référence pratique pour ce que l'on peut attendre des premières versions d'un agent de rétro-écriture Beancount. Un taux de résolution de 12,47 % sur des problèmes GitHub bien définis est le plafond actuel pour un agent de résolution de problème unique soigneusement conçu. La saisie d'écritures dans un grand livre implique une structure de tâche similaire — une intention de l'utilisateur, un fichier structuré, une sortie requise, un vérificateur — et je m'attendrais à des taux comparables sur des tâches bien définies, avec une dégradation brutale sur les flux de travail multi-écritures et multi-comptes.

Lectures complémentaires

• MemGPT: Towards LLMs as Operating Systems [arXiv:2310.08560] — La gestion du contexte de SWE-agent est réactive (tronquer en cas de dépassement) ; MemGPT propose une mémoire hiérarchisée proactive, ce qui semble nécessaire pour les agents devant raisonner sur des grands livres Beancount s'étalant sur plusieurs années.
• SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? [arXiv:2509.16941] — Fait directement suite aux points où SWE-agent échoue ; les données sur la dégradation multi-fichiers sont une lecture essentielle pour concevoir la sécurité d'écriture dans des grands livres complexes.
• Gorilla: Large Language Model Connected with Massive APIs [arXiv:2305.15334] — Si l'ACI concerne la conception d'interface, Gorilla concerne la récupération d'API ; les deux se combinent pour offrir une vision plus complète de la manière dont les agents devraient sélectionner et invoquer des outils de manière fiable.