SWE-agent, un agent de développement automatisé avec un taux de résolution de 12 % sur les issues GitHub

• SWE-agent corrige des bugs et des issues dans de vrais dépôts GitHub en transformant des modèles de langage (LMs) comme GPT-4 en agents d’ingénierie logicielle
• Il a résolu 12,29 % des issues sur l’ensemble du jeu de test SWE-bench, atteignant ainsi la meilleure performance sur l’ensemble du benchmark

Interface agent-ordinateur (ACI)

• Ces résultats ont été obtenus en concevant des commandes centrées sur le LM et des formats de retour qui permettent à l’agent d’explorer facilement le dépôt, de consulter, modifier et exécuter des fichiers de code.
• Cela est appelé interface agent-ordinateur (ACI), et le dépôt SWE-agent a été créé pour permettre d’itérer facilement sur le design d’ACI pour des agents de codage au niveau dépôt.
• Il est montré qu’un bon design d’ACI produit des résultats nettement meilleurs lors de l’utilisation d’agents.

Configuration

• Installer Docker et le lancer en local.
• Installer Miniconda et créer l’environnement swe-agent avec conda env create -f environment.yml.
• L’activer avec conda activate swe-agent.
• Exécuter ./setup.sh pour créer l’image Docker swe-agent.
• Créer un fichier keys.cfg à la racine de ce dépôt et y renseigner les clés API requises ainsi que le token GitHub.

Utilisation

• Le pipeline SWE-agent comporte deux étapes. La première est une étape d’inférence qui prend une issue GitHub en entrée et renvoie une pull request visant à la résoudre.
• La deuxième étape n’est possible que pour les issues du benchmark SWE-bench, et consiste en une étape d’évaluation qui vérifie si la pull request générée résout réellement l’issue.

Évaluation

• Cette étape n’est possible que pour les issues du jeu SWE-bench.
• Pour évaluer la pull request générée, se déplacer dans le répertoire evaluation/ puis exécuter ./run_eval.sh .

L’avis de GN⁺

• SWE-agent présente une approche innovante qui exploite les modèles de langage pour résoudre de vraies issues GitHub, élargissant ainsi les possibilités d’automatisation dans le processus de développement logiciel.
• Cette technologie a le potentiel de permettre aux développeurs de se libérer des tâches répétitives de correction de bugs afin de se concentrer sur des problèmes plus créatifs et plus complexes.
• En soulignant l’importance du design d’ACI, elle met aussi en avant le rôle essentiel de la conception d’interfaces optimisant l’interaction entre la machine et l’humain.

[botplaysdice]

Si ce genre d’agent travaille en posant aussi des questions comme ça aux développeurs, ça pourrait vraiment être très bien.

« J’ai transformé la méthode de reproduction décrite dans le bug report en code de test qui reproduit le problème. Tu peux jeter un œil à ce code pour me dire si j’ai bien compris ? »

« Plutôt que ce design, si on refactorise de telle et telle manière, je pense qu’on pourrait réduire le projet de 20 312 lignes de code au total ; do you approve? »

[fastkoder]

Voilà un projet open source séduisant.

[GN⁺]

Avis sur Hacker News

• Commentaire sur les rapports de bug :

  • La démo montre un rapport de bug clair concernant des opérations matricielles.
  • Dans la réalité, la plupart des rapports de bug sont vagues, du type : « j’ai cliqué sur X et Y s’est produit ».
  • La difficulté à corriger un bug réside dans l’identification de sa cause.
  • On sait que les LLM peuvent corriger des défauts simples, mais cela amène à se demander ce que cela prouve réellement.
  • La personne se demande si quelqu’un a examiné l’article en détail et quelles sont les différences avec ces problèmes.

• Commentaire sur le projet :

  • Le projet est jugé très impressionnant.
  • La personne a déjà tenté des expériences similaires, mais elles ont souvent abouti à des échecs chaotiques et coûteux.
  • Même si le taux de réussite sur swe-bench est de 12 %, qu’en est-il des 88 % restants ?
  • Elle se demande si swe-bench a été créé par ce groupe et si un score de « plafond humain expérimenté » a déjà été mesuré.
  • Elle partage l’expérience selon laquelle des tâches swe-bench choisies au hasard étaient elles aussi difficiles à « résoudre » même pour des humains expérimentés.

• Commentaire sur la méthodologie utilisée :

  • Il semble que la méthodologie langchain ait été utilisée.
  • Quelques prompts sont donnés en exemple, avec un lien GitHub.

• Commentaire sur l’IA et les bug trackers :

  • Si les pull requests générées par l’IA deviennent populaires, cela pourrait annoncer la fin des bug trackers publics.
  • L’idée n’est pas que les bugs disparaîtront, mais que le coût de revue des pull requests pourrait représenter une perte bien plus importante que le bénéfice pour le projet.

• Commentaire sur le benchmark SWEbench :

  • Le benchmark SWEbench n’inclut que des projets en code Python et ne représente donc pas l’ensemble des langages de programmation et frameworks.
  • La personne indique développer un framework d’évaluation plus général pour les tâches SWE, destiné notamment à JS, SQL et Python.

• Commentaire sur la comparaison avec la démo :

  • La démo semblait très similaire au projet Devin, ce qui a poussé la personne à vérifier.
  • Elle remet en question la fiabilité de la démo et aimerait entendre une évaluation tierce.

• Commentaire sur le travail de revue :

  • Question sur la quantité de travail supplémentaire réellement générée pour les humains chargés de revoir les correctifs proposés par l’IA.

• Commentaire sur les projets similaires :

  • La personne présente un projet similaire en cours, avec un lien GitHub.
  • L’accent est mis sur la manière de gérer les cas où le modèle part dans la mauvaise direction.
  • Elle souligne que boucler la boucle de feedback développeur-IA est la vraie clé d’un gain de productivité.

• Commentaire de suggestion aux auteurs :

  • Il est souligné que le taux de réussite n’a de sens que pour les chercheurs, et il est proposé d’ajouter au README des exemples de tests réussis et non réussis par SWE-agent.

• Commentaire sur la contribution aux projets open source :

  • En tant que développeur débutant, la personne souhaite un outil qui aide à trouver comment contribuer à des projets open source.
  • Elle partage son expérience du packaging Python, dont la documentation semblait ésotérique, mais qu’elle a fini par maîtriser pour rendre cela plus simple.
  • Elle prévoit de repérer des projets qui n’ont pas été modernisés, puis de proposer et implémenter des améliorations.
  • Elle aimerait échanger des idées avec des personnes ayant des inspirations ou idées similaires.