Can AI Agents Generate Microservices? How Far are We?

Hoewel AI-agenten microservices kunnen genereren met code van hoge kwaliteit en sterke API-contracten, toont dit onderzoek aan dat onvolledige consistentie en de noodzaak van menselijk toezicht volledige autonomie nog niet mogelijk maken.

De kern

Kunnen AI-agenten microservices bouwen? Een simpele uitleg

Stel je voor dat je een enorme, drukke stad wilt bouwen. In plaats van één gigantisch gebouw (een monoliet), bouw je honderden kleine, zelfstandige huisjes die allemaal met elkaar praten via straten en brievenbussen. In de softwarewereld noemen we deze huisjes microservices. Elke service doet één specifieke taak (zoals "betalen" of "bestellingen beheren"), maar ze moeten perfect op elkaar aansluiten.

De vraag die deze onderzoekers zich stelden, is simpel: Kunnen slimme AI-assistenten (AI-agenten) deze huisjes voor ons bouwen, of moeten we dat nog steeds zelf doen?

Hier is wat ze ontdekten, vertaald in alledaags taal:

1. De twee manieren van bouwen

De onderzoekers lieten de AI op twee verschillende manieren werken, net als een aannemer die een nieuw huis bouwt:

• De "Aanbouw" (Incremental): De stad bestaat al. De AI moet een nieuw huisje bouwen dat perfect past bij de bestaande straten en buren. De AI mag de blauwdrukken van de oude huizen bekijken.
  • Het resultaat: Dit ging redelijk goed (ongeveer 50-76% van de tests slaagde), maar de AI werd soms verward door te veel informatie. Als je de AI te veel details gaf over hoe het er nu uitziet, vergat hij soms de basisregels.
• De "Lege Veld" (Clean State): De AI krijgt alleen een opdracht: "Bouw een huis voor een treinreis." Er is geen bestaande stad, geen blauwdrukken, alleen de opdracht. De AI moet zelf bedenken hoe de straten eruitzien.
  • Het resultaat: Dit verrassend goed! (81-98% van de tests slaagde). Omdat de AI vrijer was om zijn eigen structuur te bedenken, paste hij zich beter aan de opdracht aan, zolang de "brievenbussen" (de API's) maar werkten.

2. De drie bouwers (AI-agenten)

Ze testten drie verschillende AI-agenten, die we kunnen vergelijken met drie verschillende soorten aannemers:

• De "Snelle, goedkope vakman" (Code Qwen): Hij is snel, kost weinig geld, maar heeft soms hulp nodig om de opdracht goed te begrijpen als hij alleen de basisinformatie krijgt.
• De "Gedetailleerde, dure expert" (Claude Code): Hij is ook snel en maakt zeer nette, korte plannen. Hij is echter de duurste in de uitvoering.
• De "Grondige, maar trage meester" (Codex): Hij maakt vaak prachtige, uitgebreide plannen, maar hij is zeer traag. Soms duurt het uren voordat hij klaar is, en hij kost meer tijd dan geld.

3. De verrassende ontdekkingen

• Minder is meer: Als je de AI te veel details geeft over hoe het oude systeem werkt, gaat hij soms in de war. Soms werkt het beter om de AI alleen de opdracht te geven en te laten zoeken naar de antwoorden.
• Korte plannen zijn goed: De code die de AI schreef was vaak korter en simpeler dan wat menselijke ontwikkelaars zouden schrijven. Dat klinkt raar, maar het betekent dat de AI soms slimme, efficiënte oplossingen vindt zonder onnodig gedoe.
• De "Grootte" van de stad telt: De AI deed het veel beter op bekende, populaire projecten (die waarschijnlijk in zijn trainingsdata zaten) dan op eigen, geheime projecten van studenten. Dit is alsof een aannemer een huis kan bouwen omdat hij er al één van heeft gezien, maar moeite heeft met een compleet nieuw ontwerp.

4. Wat betekent dit voor de toekomst?

De conclusie is: De AI is een geweldige assistent, maar nog geen vervanger.

• Het werkt, maar niet altijd: De AI kan functionerende microservices bouwen, maar je kunt ze niet zomaar loslaten. Je hebt nog steeds een menselijke "hoofdbouwer" nodig om te controleren of alles veilig is en of de nieuwe huisjes echt aansluiten bij de rest van de stad.
• Kies je gereedschap slim: Als je snelheid en prijs belangrijk vindt, kies dan voor de snellere agenten. Als je een heel complex project hebt, moet je misschien wachten tot de langzamere, grondigere agenten klaar zijn (of hun tijdslimiet verhogen).
• Geen magische oplossing: We zijn nog niet op het punt waar we zeggen: "AI, bouw de hele stad," en dan gaan we koffie drinken. De AI moet nog steeds worden begeleid, getest en gecontroleerd.

Kort samengevat:
AI-agenten kunnen tegenwoordig al aardig bouwen, net als een slimme robot die een nieuw huisje kan neerzetten. Maar of dat huisje perfect past in de wijk, hangt af van hoe je de robot instrueert en hoe goed je zelf toekijkt. We zijn nog niet klaar om de sleutel aan de robot over te geven, maar we kunnen hem zeker helpen om sneller te werken!

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Can AI Agents Generate Microservices? How Far are We?" in het Nederlands.

Titel: Kunnen AI-agenten microservices genereren? Hoe ver zijn we?

Auteurs: Bassam Adnan et al. (IIIT Hyderabad, Universiteit van Oulu, Universiteit van Zuid-Denemarken)

---

1. Probleemstelling en Context

Hoewel Large Language Models (LLM's) aanzienlijke vooruitgang hebben geboekt in het genereren van code, blijft hun toepassing voor het genereren van volledige microservices met expliciete afhankelijkheden en API-contracten onderbestudeerd.

• De uitdaging: Microservices vereisen niet alleen lokale correctheid (binnen de service zelf), maar ook globale correctheid (interactie via strikte API-contracten). Bestaande tools worstelen vaak met deze complexiteit.
• De verschuiving: Er is een trend van standalone LLM's naar AI-agenten. Deze agenten kunnen iteratief werken, tools gebruiken (zoals bestandssysteem en commando's uitvoeren), fouten analyseren en hun output verfijnen.
• De vraag: Kunnen deze autonome agenten functionele, onderhoudbare microservices genereren en hoe beïnvloedt de context (bestaande systemen vs. schone start) hun prestaties?

2. Methodologie

De auteurs hebben een empirische studie uitgevoerd om de functionele correctheid, codekwaliteit en efficiëntie te evalueren.

• Experimenteel Ontwerp:

  • Datasets: 4 projecten (2 open-source: PiggyMetrics, Train-Ticket; 2 private/studentprojecten: TeamSync, Project Management).
  • Agents: 3 verschillende AI-coding agents geselecteerd op basis van benchmarks: Claude Code, Codex (GPT-5) en Code Qwen.
  • Scenario's:
    1. Incrementele Generatie (RQ1.1): De microservice wordt verwijderd uit een bestaand systeem, maar de integratiepunten en afhankelijkheden blijven intact. De agent moet het bestaande patroon volgen.
    2. Clean State Generatie (RQ1.2): De microservice wordt volledig verwijderd, inclusief configuratie en API-aanroepen. De agent moet alleen op basis van requirements werken en de architectuur zelf afleiden.
  • Prompt-strategieën:
    • P1 (Minimaal): Alleen naam en pad naar requirements.
    • P2 (Gedetailleerd): Naam, requirements + een gegenereerde samenvatting van de implementatie (functional scope, API-verantwoordelijkheden, etc.).
  • Omvang: Totaal 144 gegenereerde microservices (4 projecten × 3 services/project × 3 agents × 2 scenario's × 2 prompts).

• Evaluatiemetrics:

  • Functionele Correctheid: Gemeten via automatische tests.
    • Incrementeel: Unit tests van de originele service.
    • Clean State: Integratietests van andere services die de gegenereerde API consumeren (omdat de interne structuur kan afwijken).
  • Codekwaliteit: SLOC (Lines of Code), Cyclomatic Complexity en Cognitive Complexity (gemeten met SonarQube).
  • Efficiëntie: Genereertijd, tokenverbruik en kosten.

3. Belangrijkste Resultaten

A. Functionele Correctheid (RQ1)

• Incrementele Generatie:
  • Verrassende bevinding: Minimale prompts (P1) presteerden beter dan gedetailleerde prompts (P2).
  • Reden: Gedetailleerde samenvattingen leidden tot "anchoring" (de agent baseerde zich te sterk op de samenvatting en negeerde subtiele details in de bestaande codebase).
  • Pass-rates: 50% - 76% (Codex presteerde het beste met ~76% bij P1).
• Clean State Generatie:
  • Agenten presteerden aanzienlijk beter in schone start-scenario's (81% - 98% pass-rates).
  • Reden: Integratietests zijn toleranter voor structurele verschillen (zoals package-namen) zolang de API-contracten kloppen.
  • Code Qwen had moeite met P1 (loop-fouten), maar herstelde volledig met P2, wat aantoont dat expliciete richtlijnen cruciaal zijn voor open-source modellen in schone start-scenario's.
• Statistiek: Het verschil tussen de twee scenario's is statistisch significant (p < 0.001).

B. Codekwaliteit

• De gegenereerde code was over het algemeen minder complex (lagere Cyclomatic en Cognitive Complexity) dan de menselijke baselines, terwijl de functionaliteit behouden bleef.
• De code was vaak beknopter (lagere SLOC) zonder in te leveren op correctheid.

C. Efficiëntie (RQ2)

• Tijd:
  • Claude Code en Code Qwen waren het snelst (gemiddeld ~7,5 - 8 minuten).
  • Codex was aanzienlijk trager (gemiddeld ~16,6 minuten) met extreme outliers tot 1,74 uur per service.
• Kosten:
  • Code Qwen was het goedkoopst (~$2,98 per service).
  • Claude Code was het duurst (~$13,28 per service), ondanks dat het minder output-tokens gebruikte.
• Tokengebruik: Er was geen correlatie tussen de hoeveelheid gegenereerde tekst (tokens) en de functionele correctheid. Beknopte code (Claude) was net zo correct als uitgebreide code (Codex).

4. Belangrijkste Bijdragen

1. Eerste empirische studie die AI-agenten evalueert voor het genereren van volledige microservices in verschillende contexten (incrementeel vs. clean state).
2. Inzicht in Prompt-strategieën: Bewijs dat "less is more" kan zijn in incrementele scenario's (minimal prompts werken beter), terwijl expliciete samenvattingen nodig zijn voor schone start-scenario's, afhankelijk van het model.
3. Efficiëntie-analyse: Een gedetailleerde vergelijking van tijd, kosten en tokenverbruik tussen state-of-the-art agents, met waarschuwingen voor tijdsout-risico's bij bepaalde modellen.
4. Data Contaminatie: De studie bevestigt dat agents beter presteren op populaire open-source repositories (waarschijnlijk door memorisatie) dan op private codebases, wat de noodzaak benadrukt van private datasets voor eerlijke evaluatie.

5. Betekenis en Conclusie

• Haalbaarheid: AI-agenten kunnen microservices genereren met onderhoudbare code en hoge integratie-succespercentages, maar volledige autonomie is nog niet haalbaar. Menselijke supervisie is noodzakelijk om API-contracten en architecturale consistentie te waarborgen.
• Praktische Implicaties:
  • Ontwikkelaars moeten experimenten uitvoeren (pilot studies) om te bepalen welke agent en prompt-strategie het beste werkt voor hun specifieke codebase.
  • Er moet rekening worden gehouden met time-out-risico's (vooral bij Codex).
  • Kostenbesparing mag niet ten koste gaan van betrouwbaarheid; het prijsverschil tussen de agents is klein vergeleken met de tijd van een menselijke ontwikkelaar.
• Toekomstig Onderzoek: Er is behoefte aan specifieke benchmarks voor software-architectuur (niet alleen repository-tasks) en methoden om data-contaminatie te detecteren.

Conclusie: Hoewel AI-agenten een krachtig hulpmiddel zijn voor microservice-ontwikkeling, zijn ze context-afhankelijk. Ze zijn het meest succesvol bij het genereren van nieuwe diensten op basis van requirements (clean state), maar vereisen zorgvuldige afstemming bij het toevoegen aan bestaande systemen.