💻 computer science

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

CodeTeam is een door LLM aangedreven multi-agent framework dat de uitdagingen van natuurlijke taal naar repository-generatie aanpakt door planning, besluitvorming en implementatie te scheiden in gecoördineerde fasen, waarmee het een state-of-the-art prestatie bereikt in zowel ontwerpkwaliteit als functionele correctheid op benchmarktests.

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

Gepubliceerd 2026-06-23

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

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

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Het Grote Probleem: Een Hele Stad Bouwen vanuit een Schets

Stel je voor dat je een zeer slimme, maar ietwat chaotische architect (een AI) vraagt om een hele stad te bouwen op basis van één enkele zin: "Ik heb een plek nodig waar mensen schoenen kunnen kopen."

Als je de AI alleen vraagt om "de code te schrijven", bouwt hij misschien een prachtige schoenenzaak, maar vergeet hij de wegen, de elektriciteitscentrale of het rioolsysteem te bouwen. Of hij bouwt de schoenenzaak met een deur die naar een bakstenen muur leidt, omdat hij niet met de "wegbouwer"-AI heeft gepraat.

Dit is de uitdaging van NL2Repo (Natural Language to Repository). Het gaat niet alleen om het schrijven van een enkele functie (zoals een enkele kamer); het gaat om het genereren van een heel softwareproject (een hele stad) met veel bestanden die perfect met elkaar moeten communiceren. Huidige AI-modellen raken vaak de draad kwijt in de details, waarbij ze het grote plaatje vergeten of "cross-file" rommel creëren waarbij Bestand A iets verwacht wat Bestand B niet heeft gebouwd.

De Oplossing: CodeTeam (De Bouwploeg)

De auteurs stellen CodeTeam voor, een systeem dat niet vertrouwt op één eenzame AI-genie. In plaats daarvan fungeert het als een goed georganiseerde bouwploeg met gespecialiseerde rollen. Ze breken de taak op in drie duidelijke fasen: Planning, Besluitvorming en Bouwen.

Zo werkt het team, stap voor stap:

1. De Architecten (De Dromers)

In plaats van één persoon die de blauwdrukken tekent, huurt het systeem vier verschillende Architect-agents in.

Wat ze doen: Elke architect schetst een ander ontwerp voor de software. De een zegt misschien: "Laten we een modulair ontwerp gebruiken!" Een ander zegt: "Nee, laten we het simpel en plat houden!"
Het Geheime Wapen: Soms mogen deze architecten even spieken in een bibliotheek van succesvolle eerdere projecten (Retrieval-Augmented Generation) om te zien hoe anderen soortgelijke problemen hebben opgelost. Dit helt hen om het wiel niet opnieuw uit te vinden.
Het Doel: Het creëren van een verscheidenheid aan "Software Design Sketches" (SDS). Denk aan deze als gedetailleerde blauwdrukken die elke kamer, elke pijp en wie verantwoordelijk is voor het bouwen van wat, opsommen.

2. De CTO (De Hoofdbeslisser)

Zodra de vier architecten hun blauwdrukken presenteren, stapt een Chief Technical Officer (CTO) agent in.

Wat hij doet: De CTO beoordeelt alle schetsen, kiilt de beste uit en zet deze om in een Machine-Checkbaar Contract.
Het Contract: Dit is niet zomaar een tekening; het is een strikt juridisch document voor de computer. Het zegt: "Bestand A moet deze specifieke functie hebben. Bestand B moet afhankelijk zijn van Bestand A. Ontwikkelaar 1 is verantwoordelijk voor de keuken; Ontwikkelaar 2 is verantwoordelijk voor de slaapkamer."
Waarom het belangrijk is: Dit contract voorkomt dat de bouwers van het pad af raken en een garage bouwen waar de keuken zou moeten staan. Het stelt de regels vast voordat er ook maar één baksteen is gelegd.

3. De Developers (De Bouwers)

Nu begint de eigenlijke codering. Het systeem huurt een specifiek aantal Developer agents in op basis van het contract van de CTO.

Specialisatie: In tegen tegenstelling tot een generieke AI die alles probeert te doen, krijgt elke developer specifieke bestanden toegewezen. Developer 1 bouwt alleen de inlogpagina. Developer 2 bouwt alleen de database.
De Git Coördinatie (De Voorman): Terwijl ze bouwen, gebruiken ze een lichtgewicht versie van Git (een tool die developers gebruiken om wijzigingen bij te houden). Wanneer Developer 1 de inlogpagina verandert, laten ze een "commit message" (een notitie) achter met de tekst: "Ik heb de wachtwoordknop aangepast." Developer 2 leest deze notitie en past de eigen code aan om overeen te komen.
Afhankelijkheidsbewustzijn: Het systeem weet dat je de muren niet kunt schilderen voordat je het frame hebt gebouwd. Het plant het werk zodat bestanden in de juiste volgorde worden gebouwd.

4. De QA Agent (De Inspecteur)

Terwijl het team bouwt, fungeert een Quality Assurance (QA) agent als een bouwinspecteur.

Wat hij doet: Hij voert tests uit om te zien of het gebouw overeind blijft staan. Als een deur niet opengaat of een leiding lekt, zegt de QA-agent niet alleen "Error". Hij vindt uit wie het heeft gebroken en stuurt een reparatieticket terug naar die specente developer.
De Loop: De developer lost het probleem op, de inspecteur controleert opnieuw, en ze herhalen dit totdat het gebouw perfect is.

Wat hebben ze gevonden? (De Resultaten)

De onderzoekers hebben CodeTeam getest tegen andere methoden (zoals een enkele AI die alles probeert te doen, of andere multi-agent teams) met behulp van twee belangrijke "examens":

Het Blauwdruk Examen (SketchEval): Ze controleerden of de gegenereerde code structureel correct was in vergelijking met echte wereldvoorbeelden.
- Resultaat: CodeTeam won. Het bouwde structuren die veel meer leken op echte software. De stappen van de "Architecten" en de "CTO" hielpen hen om de lay-out goed te krijgen, terwijl de "QA"-stappen de kleine barstjes herstelden.
- Belangrijk Inzicht: De "Dynamic Developer Allocation" (het inhuren van het juiste aantal bouwers voor de specifieke taak) was de grootste factor voor succes. Als je te weinig of te veel mensen inhuurt, of de verkeerde mensen aan de verkeerde kamers toewijst, mislukt het gebouw.
De Live Test (NL2Repo-Bench): Ze hebben de gegenereerde software daadwerkelijk geprobeerd te draaien om te zien of het werkte.
- Resultaat: CodeTeam had het hoogste succespercentage. Het zag er niet alleen goed uit op papier; het functioneerde ook echt.
- Belangrijk Inzicht: Door structurele fouten (zoals ontbrekende bestanden of kapotte verbindingen) vroegtijdig op te lossen, was het eindproduct veel eerder in staat om de "live" tests te halen.

De Kernboodschap

Het paper betoogt dat het bouwen van software vanaf nul niet alleen een "schrijftaken" is; het is een managementtaak.

De Oude Manier: Vraag één AI om een heel boek te schrijven. Het vergeet vaak plotpunten of schrijft personages die niet bij elkaar passen.
De CodeTeam Manier: Huur een team in. Laat één persoon het plot plannen, één persoon de hoofdstukken redigeren en één persoon controleren op typefouten.

Door planning (Architecten/CTO) te scheiden van uitvoering (Developers) en controle (QA) toe te voegen, creëert CodeTeam software die niet alleen slimmer is, maar ook betrouwbaarder. Het bewijst dat voor complexe taken een gecoördineerd team van AI-agents veel beter is dan een enkele, superintelligente AI die alleen werkt.

Technische Samenvatting: CodeTeam

Probleemstelling

Het artikel behandelt de uitdaging van Natural Language to Repository (NL2Repo) generatie: het construeren van een volledige software-repository op basis van een document met natuurlijke taalvereisten. In tegen afstelling tot functie-niveau codegeneratie (zoals HumanEval), vereist NL2Repo een lange planning-horizon, stabiele interfaces tussen bestanden en iteratieve debugging van inconsistenties die pas tijdens systeembrede integratie aan het licht komen.

Bestaande benaderingen kampen met drie kritieke tekortkomingen in dit domein:

Gebrek aan Machine-Controleerbare Contracten: De huidige methoden missen vaak een formele, machine-leesbare specificatie van de repositorystructuur voordat de codering begint.
Inconsistentie tussen Bestanden: Agents hebben moeite om de interface-consistentie over meerdere bestanden te handhaven tijdens de implementatie.
Coördinatiegebreken: Huidige workflows slagen er vaak niet in om de implementatie binnen begrensde contexten te coördineren met een globaal plan via afhankelijkheidsbewuste planning en iteratieve reparatie.

Hoewel benchmarks zoals RepoBench en FEA-Bench zich richten op voltooiing of incrementele wijzigingen binnen bestaande codebases, vereist de NL2Repo-setting (generatie vanaf nul) architecturaal ontwerp, beheer van afhankelijkheden en packaging vanuit een lege werkruimte.

Methodologie: Het CodeTeam Framework

CodeTeam is een door LLM's aangedreven multi-agent framework dat planning, besluitvorming en implementatie scheidt in afzonderlijke, gecoördineerde fasen. Het maakt gebruik van een Software Design Sketch (SDS) als een centraal, machine-controleerbaar contract.

1. Planningsfase: Architect Competitie & CTO Selectie

Architect Agents: Meerdere Architect-agents ( $N=4$ $N = 4$ ) ontwerpen onafhankelijk van elkaar concurrerende SDS'en. Deze schetsen definiëren de technologie-stack, bestandsstructuur, publieke interfaces en een developer allocatieplan (dat de teamgrootte en bestandseigendom specificeert).
- RAG Grounding: Optioneel halen architecten ontwerpreferenties op uit een gecureerde corpus van publieke repositories om hun schetsen te onderbouwen, wat voorkomt dat ontwerpen convergeren of cruciale modules worden vergeten.
- Diversiteitsmechanismen: Architecten gebruiken gerandomiseerde ontwerpvoorkeuren en ontvangen alleen hoogwaardige samenvattingen van voorgaande kandidaten om diverse oplossingen te waarborgen.
CTO Agent: Een Chief Technical Officer-agent evalueert kandidaten op basis van structurele validiteit, interface-consistentie, implementeerbaarheid en teamgeschiktheid. Het selecteert de beste SDS en normaliseert deze naar een canoniek, machine-actiebaar contract (JSON-formaat) dat dient als de "single source of truth".

2. Implementatiefase: Afhankelijkheidsbewuste Executie

Developer Agents: Op basis van het door de CTO gekozen plan worden specifieke Developer-agents geïnstantieerd. Elke agent is eigenaar van een specifieke subset van bestanden.
Context & Planning: Developers werken onder een afhankelijkheidsbewuste scheduler. Ze ontvangen een compacte context bestaande uit het doelbestand, relevante SDS-fragmenten en interface-briefings voor afhankelijkheden (signatures, invarianten), in plaats van volledige bestandinhoud.
Git-gebaseerde Coördinatie: Agents werken op geïsoleerde branches. Bij het voltooien van een bestand committen zij wijzigingen met een gestructureerd update_reason bericht. Dit stelt andere agents in staat om hun interface-briefings bij te werken zonder toegang te krijgen tot de volledige bestandinhoud, waardoor de consistentie tussen bestanden behouden blijft.

3. Reparatiefase: QA-gestuurde Iteratie

QA Agent: Een Quality Assurance-agent voert lichte, gegenereerde tests uit tegen voltooide afhankelijkheidslagen.
Feedbackloop: Als er fouten optreden, diagnosticeert de QA-agent de oorzaak (bijv. interface-mismatch, ontbrekende symbolen) en stuurt het reparatieverzoek naar de specifieke eigenaar van het bronbestand. Afhankelijke bestanden worden opnieuw in de wachtrij geplaatst als de interface-wijziging doorwerkt.
Terminatie: De loop gaat door totdat er geen fouten meer worden gedetecteerd, een limiet wordt bereikt of de middelen uitgeput zijn.

Belangrijkste Bijdragen

CodeTeam Framework: Een nieuw multi-agent systeem voor NL2Repo dat SDS-competitie, optionele RAG-grounding, CTO-gestuurde contractnormalisatie, projectspecifieke developer-allocatie, afhankelijkheidsbewuste executie, Git-gebaseerde coördinatie en QA-gestuurde reparatie integreert.
Uitgebreide Evaluatie: Een rigoureuze evaluatie op de SketchEval benchmark (waarbij Prompt-Engineering en Supervised Fine-Tuning varianten worden vergeleken met CodeS en andere baselines) en een extern validatieprotocol op NL2Repo-Bench (executie-gebaseerde testen).
Ablatie-inzichten: Systematische analyse die aantoont dat retrieval-augmented planning en dynamische developer-allocatie de primaire drijvers van prestaties zijn, terwijl Git-gebaseerde coördinatie een complementaire stabiliteit biedt.

Experimentele Resultaten

Prestaties op SketchEval (Structurele Gelijkenis)

Prompt-Engineering (PE): CodeTeam behaalde een algemene SketchBLEU van 51,7%, waarmee het de sterkste baseline, CodeS (PE), versloeg met 4,1 absolute punten (8,6% relatief).
Supervised Fine-Tuning (SFT): CodeTeam behaalde 60,9%, waarmee het CodeS (SFT) versloeg met 2,9 punten.
Sub-score Analyse: De verbeteringen waren het meest uitgesproken in Structural Matching en Dataflow Matching, wat duidt op een betere repository-brede integriteit en consistentie tussen bestanden vergeleken met oppervlakkige token-overlap.
Schaalbaarheid van Moeilijkheidsgraad: Het prestatieverschil werd aanzienlijk groter bij Hard repositories (met dichte afhankelijkheden), waar CodeTeam met 4,7 punten boven CodeS (PE) uitkwam.

Prestaties op NL2Repo-Bench (Executie-gebaseerd)

Pass Rate: CodeTeam behaalde de hoogste gemiddelde test-pass rate in beide settings: 34,6% (PE) en 42,3% (SFT).
Foutanalyse: CodeTeam verminderde packaging errors (van 34,2% naar 22,1%) en import errors (van 28,7% naar 19,4%) aanzienlijk vergeleken met CodeS. Dit bevestigt dat het SDS-contract structurele weglatingen (bijv. ontbrekende __init__.py of incorrecte pakketnamen) effectief voorkomt.
Verschuiving in Foutmodi: Naarmate de structurele fouten afnamen, nam het aandeel van logische fouten toe, wat suggereert dat CodeTeam succesvol structurele fouten aanpakt en de bottleneck verschuift naar semantische correctheid.

Bevindingen uit de Ablatie-studie

RAG (Retrieval-Augmented Generation): Het verwijderen van RAG veroorzaakte een relatieve daling van 8,1% in SketchBLEU. Het verbeterde primair de planningsfase (SDS parse succes en structurele validiteit) en de diversiteit van het plan.
Dynamische Developer Allocatie: Het verwijderen van dit mechanisme veroorzaakte de grootste daling (9,9% relatief). Het is cruciaal voor het afstemmen van de teamgrootte en het bestandseigendom op de modulaire structuur van de repository, wat de QA-rondes en interface-mismatches vermindert.
Git Coördinatie: Het verwijderen hiervan veroorzaakte een kleinere maar consistente daling (2,9% relatief), wat fungeert als een reactief mechanisme om interface-drift tijdens reparaties te stabiliseren.

Betekenis en Claims

Het artikel claimt dat NL2Repo niet louter een taak is van lang-context codegeneratie, maar een gecoördineerd software engineering proces.

Workflow boven Modelcapaciteit: De resultaten suggereren dat gestructureerde multi-agent workflows (planning, rolspecialisatie, iteratieve reparatie) meetbare voordelen bieden, zelfs wanneer het basismodel is gefinetuned. De workflow compenseert voor de beperkingen in de consistentie tussen bestanden die pure prompting of SFT niet volledig kunnen oplossen.
Expliciete Contracten: De SDS dient als een machine-controleerbaar contract dat bestandsgrenzen en afhankelijkheden bindt, wat precieze reparatie-routing mogelijk maakt en de "cascaderende herwerking" voorkomt die gebruikelijk is bij single-agent of losjes gecoördineerde systemen.
Praktische Implementatie: De studie toont aan dat investeren in tokens voor voorafgaande architecturale planning (SDS-generatie) en dynamische allocatie de downstream herwerking vermindert. Het suggereert ook dat een beperkt aantal QA-iteraties (2–3 rondes) de meerderheid van de kwaliteitsverbeteringen oplevert, wat het framework levensvatbaar maakt voor scenario's met beperkte middelen.

De auteurs concluderen dat CodeTeam laat zien hoe LLM-gebaseerde repository-generatie gestructureerder, inspecteerbaar en uitbreidbaar kan worden gemaakt door agents te behanden als een gecoördineerd development team in plaats van geïsoleerde code-generators.