💻 computer science

CodeTeam: An LLM-Powered Multi-Agent Framework for Repository-Level Code Generation

CodeTeam est un framework multi-agents propulsé par les LLM qui répond aux défis de la génération de dépôts à partir du langage naturel en séparant la planification, la prise de décision et l'implémentation en étapes coordonnées, atteignant ainsi des performances de pointe tant en termes de qualité de conception que de justesse fonctionnelle sur les tests de référence.

Auteurs originaux : Yifei Wang, Ruiyin Li, Peng Liang, Qiong Feng, Zengyang Li, Mojtaba Shahin, Arif Ali Khan

Publié 2026-06-23

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Yifei Wang, Ruiyin Li, Peng Liang, Qiong Feng, Zengyang Li, Mojtaba Shahin, Arif Ali Khan

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Le Gros Problème : Construire une Ville Entière à partir d'un Croquis

Imaginez que vous demandiez à un architecte très intelligent, mais un peu éparpillé (une IA), de construire une ville entière à partir d'une seule phrase : "J'ai besoin d'un endroit où les gens peuvent acheter des chaussures."

Si vous demandez simplement à l'IA d'« écrire le code », elle pourrait construire un magnifique magasin de chaussures, mais elle oublie de construire les routes, la centrale électrique ou le système d'égouts. Ou bien, elle pourrait construire le magasin de chaussures avec une porte qui mène à un mur de briques parce qu'elle n'a pas parlé à l'IA « constructrice de routes ».

C'est le défi du NL2Repo (Natural Language to Repository). Il ne s'agit pas seulement d'écrire une seule fonction (comme une seule pièce) ; il s'agit de générer un projet logiciel complet (une ville entière) avec de nombreux fichiers qui doivent communiquer parfaitement entre eux. Les modèles d'IA actuels se perdent souvent dans les détails, oubliant la vue d'ensemble ou créant des désordres « inter-fichiers » où le Fichier A attend quelque chose que le Fichier B n'a pas construit.

La Solution : CodeTeam (L'Équipe de Construction)

Les auteurs proposent CodeTeam, un système qui ne repose pas sur un seul génie de l'IA solitaire. Au lieu de cela, il agit comme une équipe de construction bien organisée avec des rôles spécialisés. Ils décomposent le travail en trois phases distinctes : Planification, Prise de Décision et Construction.

Voici comment l'équipe travaille, étape par étape :

1. Les Architectes (Les Rêveurs)

Au lieu d'une seule personne dessinant les plans, le système engage quatre agents Architectes différents.

Ce qu'ils font : Chacun esquisse un design différent pour le logiciel. L'un pourrait dire : « Utilisons un design modulaire ! ». Un autre pourrait dire : « Non, restons simples et plats ! ».
L'Arme Secrète : Parfois, ces architectes sont autorisés à jeter un coup d'œil à une bibliothèque de projets réussis passés (Génération Augmentée par Récupération / RAG) pour voir comment d'autres ont résolu des problèmes similaires. Cela les aide à éviter de réinventer la roue.
Le But : Créer une variété de « Croquis de Conception Logicielle » (SDS). Considérez cela comme des plans détaillés listant chaque pièce, chaque tuyau et qui est responsable de la construction de quoi.

2. Le CTO (Le Décideur en Chef)

Une fois que les quatre architectes ont présenté leurs plans, un agent Directeur Technique (CTO) intervient.

Ce qu'il fait : Le CTO examine tous les croquis, choisit le meilleur et le transforme en un Contrat Vérifiable par Machine.
Le Contrat : Ce n'est pas seulement un dessin ; c'est un document juridique strict pour l'ordinateur. Il dit : « Le Fichier A doit avoir cette fonction spécifique. Le Fichier B doit dépendre du Fichier A. Le Développeur 1 est responsable de la cuisine ; le Développeur 2 est responsable de la chambre. »
Pourquoi c'est important : Ce contrat empêche les constructeurs de s'égarer et de construire un garage là où la cuisine devrait se trouver. Il fixe les règles avant qu'une seule brique ne soit posée.

3. Les Développeurs (Les Bâtisseurs)

La phase de codage proprement dite commence maintenant. Le système engage un nombre spécifique d'agents Développeurs basé sur le contrat du CTO.

Spécialisation : Contra_irement à une IA générique qui essaie de tout faire, ces développeurs sont assignés à des fichiers spécifiques. Le Développeur 1 construit uniquement la page de connexion. Le Développeur 2 construit uniquement la base de données.
La Coordination Git (Le Contremaître) : Pendant qu'ils construisent, ils utilisent une version légère de Git (un outil utilisé par les développeurs pour suivre les changements). Lorsque le Développeur 1 modifie la page de connexion, il laisse un « message de commit » (une note) disant : « J'ai modifié le bouton de mot de passe. » Le Développeur 2 lit cette note et met à jour son propre code pour correspondre.
Conscience des Dépendances : Le système sait qu'on ne peut pas peindre les murs avant d'avoir construit l'ossature. Il planifie le travail de sorte que les fichiers soient construits dans le bon ordre.

4. L'Agent QA (L'Inspecteur)

Pendant que l'équipe construit, un agent d'Assurance Qualité (QA) agit comme un inspecteur de bâtiment.

Ce qu'il fait : Il lance des tests pour voir si le bâtiment tient debout. Si une porte ne s'ouvre pas ou qu'un tuyau fuit, l'agent QA ne se contente pas de dire « Erreur ». Il identifie qui a cassé quoi et envoie un ticket de réparation à ce développeur spécifique.
La Boucle : Le développeur corrige le problème, l'inspecteur vérifie à nouveau, et ils répètent l'opération jusqu'à ce que le bâtiment soit parfait.

Qu'ont-ils trouvé ? (Les Résultats)

Les chercheurs ont testé CodeTeam contre d'autres méthodes (comme une seule IA essayant de tout faire, ou d'autres équipes multi-agents) en utilisant deux principaux « examens » :

L'Examen du Plan (SketchEval) : Ils ont vérifié si le code généré présentait une structure correcte par rapport à des exemples du monde réel.
- Résultat : CodeTeam a gagné. Il a construit des structures qui ressemblaient beaucoup plus à de vrais logiciels. Les étapes « Architectes » et « CTO » les ont aidés à réussir la disposition, tandis que les étapes « QA » ont réparé les petites fissures.
- Idée Clé : L'« Allocation Dynamique des Développeurs » (embaucher le bon nombre de bâtisseurs pour le travail spécifique) a été le facteur de succès le plus important. Si vous embauchez trop peu ou trop de personnes, ou si vous assignez les mauvaises personnes aux mauvaises pièces, le bâtiment échoue.
Le Test en Direct (NL2Repo-Bench) : Ils ont réellement essayé de faire fonctionner le logiciel généré pour voir s'il fonctionnait.
- Résultat : CodeTeam a eu le taux de réussite le plus élevé. Il ne se contentait pas de bien paraître sur papier ; il fonctionnait réellement.
- Idée Clé : En corrigeant les erreurs structurelles tôt (comme les fichiers manquants ou les connexions brisées), le produit final était beaucoup plus susceptible de réussir les tests « en direct ».

Ce qu'il faut retenir

L'article soutient que construire un logiciel à partir de zéro n'est pas seulement une tâche d'« écriture » ; c'est une tâche de gestion.

L'Ancienne Méthode : Demander à une IA d'écrire un livre entier. Elle oublie souvent des points d'intrigue ou écrit des personnages qui ne correspondent pas.
La Méthode CodeTeam : Engager une équipe. Avoir une personne pour planifier l'intrigue, une personne pour éditer les chapitres et une personne pour vérifier les fautes de frappe.

En séparant la planification (Architectes/CTO) de l'exécution (Développeurs) et en ajoutant la vérification (QA), CodeTeam crée des logiciels qui sont non seulement plus intelligents, mais aussi plus fiables. Cela prouve que pour des tâches complexes, une équipe coordonnée d'agents d'IA est bien meilleure qu'une seule IA super intelligente travaillant seule.

Résumé Technique : CodeTeam

Énoncé du Problème

Le document traite du défi de la génération de Natural Language to Repository (NL2Repo) : construire l'intégralité d'un dépôt logiciel à partir d'un document de spécifications en langage naturel. Contrairement à la génération de code au niveau de la fonction (ex. HumanEval), le NL2Repo nécessite des horizons de planification longs, des interfaces inter-fichiers stables et un débogage itératif d'incohérences qui ne se manifestent que lors de l'intégration au niveau du système.

Les approches existantes font face à trois lacunes critiques dans ce domaine :

Absence de contrats vérifiables par machine : Les méthodes précédentes manquent souvent d'une spécification formelle et lisible par machine de la structure du dépôt avant le début du codage.
Incohérence inter-fichiers : Les agents peinent à maintenir la cohérence des interfaces entre plusieurs fichiers pendant l'implémentation.
Déficits de coordination : Les flux de travail actuels échouent souvent à coordonner l'implémentation de contextes délimités par rapport à un plan global avec une planification sensible aux dépendances et une réparation itérative.

Alors que des benchmarks comme RepoBench et FEA-Bench se concentrent sur la complétion ou les changements incrémentiels au sein de bases de code existantes, le cadre NL2Repo (génération à partir de zéro) exige une conception architecturale, une gestion des dépendances et un packaging à partir d'un espace de travail vide.

Méthodologie : Le Framework CodeTeam

CodeTeam est un framework multi-agents piloté par LLM qui sépare la planification, la prise de décision et l'implémentation en étapes distinctes et coordonnées. Il utilise un Software Design Sketch (SDS) comme un contrat central, vérifiable par machine.

1. Étape de Planification : Compétition d'Architectes et Sélection du CTO

Agents Architectes : Plusieurs agents Architectes ( $N=4$ $N = 4$ ) rédigent de manière indépendante des SDS concurrents. Ces croquis définissent la pile technologique, la structure des fichiers, les interfaces publiques et un plan d'allocation des développeurs (spécifiant la taille de l'équipe et la propriété des fichiers).
- Ancrage RAG : Les architectes peuvent optionnellement extraire des références de conception d'un corpus de dépôts publics pour ancrer leurs croquis, empêant ainsi la convergence de conception et l'omission de modules.
- Mécanismes de Diversité : Les architectes utilisent des préférences de conception randomisées et ne reçoivent que des résumés de haut niveau des candidats précédents pour garantir des solutions diverses.
Agent CTO : Un agent Chief Technical Officer évalue les candidats sur la base de la validité structurelle, de la cohérence des interfaces, de l'implémentabilité et de l'adéquation de l'équipe. Il sélectionne le meilleur SDS et le normalise en un contrat canonique, actionnable par machine (format JSON), qui sert de "source unique de vérité".

2. Étape d'Implémentation : Exécution Sensible aux Dépendances

Agents Développeurs : Sur la base du plan sélectionné par le CTO, des agents Développeurs spécifiques sont instanciés. Chaque agent possède un sous-ensemble spécifique de fichiers.
Contexte et Planification : Les développeurs opèrent sous un ordonnanceur sensible aux dépendances. Ils reçoivent un contexte compact contenant le fichier cible, des fragments pertinents du SDS et des brèves d'interface pour les dépendances (signatures, invariants), plutôt que le contenu complet des fichiers.
Coordination basée sur Git : Les agents travaillent sur des branches isolées. À la fin d'un fichier, ils valident les changements avec un message structuré update_reason. Cela permet aux autres agents de mettre à jour leurs brèves d'interface sans accéder au contenu complet des fichiers, maintenant ainsi la cohérence inter-fichiers.

3. Étape de Réparation : Itération Pilotée par la QA

Agent QA : Un agent de Quality Assurance exécute des tests légers générés contre les couches de dépendances terminées.
Boucle de Rétroaction : Si des échecs surviennent, l'agent QA diagnostique la cause racine (ex. décalage d'interface, symbole manquant) et route la demande de réparation vers le propriétaire spécifique du fichier source. Les fichiers dépendants ne sont re-mis en file d'attente que si le changement d'interface se propage.
Terminaison : La boucle continue jusqu'à ce qu'aucun échec ne soit détecté, qu'une limite soit atteinte ou que les ressources soient épuisées.

Contributions Clés

Framework CodeTeam : Un nouveau système multi-agents pour le NL2Repo qui intègre la compétition de SDS, l'ancrage RAG optionnel, la normalisation de contrat par le CTO, l'allocation dynamique de développeurs, l'exécution sensible aux dépendances, la coordination basée sur Git et la réparation pilotée par la QA.
Évaluation Complète : Une évaluation rigoureuse sur le benchmark SketchEval (comparant les variantes Prompt-Engineering et Supervised Fine-Tuning par rapport à CodeS et d'autres bases) et un protocole de validation externe sur NL2Repo-Bench (tests basés sur l'exécution).
Insights d'Ablation : Une analyse systématique démontrant que la planification augmentée par la recherche (retrieval) et l'allocation dynamique de développeurs sont les principaux moteurs de performance, tandis que la coordination basée sur Git fournit une stabilité complémentaire.

Résultats Expérimentaux

Performance sur SketchEval (Similarité Structurelle)

Prompt-Engineering (PE) : CodeTeam a atteint un SketchBLEU global de 51,7 %, surpassant la base la plus forte, CodeS (PE), de 4,1 points absolus (8,6 % relatifs).
Supervised Fine-Tuning (SFT) : CodeTeam a atteint 60,9 %, dépassant CodeS (SFT) de 2,9 points.
Analyse des Sous-scores : Les améliorations ont été plus prononcées dans le Structural Matching et le Dataflow Matching, indiquant une meilleure intégrité au niveau du dépôt et une meilleure cohérence inter-fichiers par rapport au simple chevauchement de jetons de surface.
Échelle de Difficulté : L'écart de performance s'est considérablement élargi sur les dépôts Hard (dépendances denses), où CodeTeam a progressé de 4,7 points par rapport à CodeS (PE).

Performance sur NL2Repo-Bench (Basée sur l'Exécution)

Taux de Réussite (Pass Rate) : CodeTeam a obtenu le taux de réussite moyen le plus élevé dans les deux configurations : 34,6 % (PE) et 42,3 % (SFT).
Analyse d'Erreur : CodeTeam a considérablement réduit les erreurs de packaging (de 34,2 % à 22,1 %) et les erreurs d'importation (de 28,7 % à 19,4 %) par rapport à CodeS. Cela confirme que le contrat SDS prévient efficacement les omissions structurelles (ex. manque de __init__.py ou noms de packages incorrects).
Décalage des Modes de Défaillance : À mesure que les erreurs structurelles diminuaient, la proportion d'erreurs de logique augmentait, suggérant que CodeTeam traite avec succès les problèmes organisationnels, déplaçant le goulot d'étranglement vers la correction sémantique.

Résultats de l'Étude d'Ablation

RAG (Génération Augmentée par la Recherche) : Supprimer le RAG a provoqué une chute relative de 8,1 % du SketchBLEU. Il a principalement amélioré l'étape de planification (succès du parsing du SDS et validité structurelle) ainsi que la diversité des plans.
Allocation Dynamique de Développeurs : La suppression de ce mécanisme a causé la chute la plus importante (9,9 % relatif). Elle est cruciale pour aligner la taille de l'équipe et la propriété des fichiers avec la structure modulaire du dépôt, réduisant les cycles de QA et les décalages d'interface.
Coordination Git : Sa suppression a causé une baisse plus faible mais constante (2,9 % relatif), agissant comme un mécanisme réactif pour stabiliser la dérive des interfaces pendant les réparations.

Signification et Revendications

L'article affirme que le NL2Repo n'est pas simplement une tâche de génération de code à long contexte, mais un processus de génie logiciel coordonné.

Workflow plutôt que Capacité du Modèle : Les résultats suggèrent que les flux de travail multi-agents structurés (planification, spécialisation des rôles, réparation itérative) apportent des bénéfices mesurables même lorsque le modèle de base est affiné (fine-tuned). Le workflow compense les limitations de cohérence inter-fichiers que le simple prompting ou le SFT ne peuvent pleinement résoudre.
Contrats Explicites : Le SDS sert de contrat vérifiable par machine qui lie les frontières de fichiers et les dépendances, permettant un routage précis des réparations et évitant le "rework en cascade" courant dans les systèmes à agent unique ou faiblement coordonnés.
Déploiement Pratique : L'étude démontre qu'investir des jetons (tokens) dans la planification architecturale initiale (génération du SDS) et l'allocation dynamique réduit le travail de reprise en aval. Elle suggère également qu'un nombre limité d'itérations de QA (2 à 3 cycles) capture la majorité des améliorations de qualité, rendant le framework viable pour des scénarios à ressources contraintes.

Les auteurs concluent que CodeTeam démontre comment la génération de dépôts par LLM peut être rendue plus structurée, inspectable et extensible en traitant les agents comme une équipe de développement coordonnée plutôt que comme des générateurs de code isolés.