Beyond Functional Correctness: Design Issues in AI IDE-Generated Large-Scale Projects

Deze studie toont aan dat Cursor, ondersteund door het FD-HITL-framework, functioneel correcte grote projecten kan genereren, maar dat deze systemen aanzienlijke ontwerpproblemen bevatten die de lange termijn onderhoudbaarheid en evolutie bedreigen.

De kern

De "AI-Codeerders" zijn er, maar zijn ze ook goede architecten?

Stel je voor dat je een enorme, complexe stad wilt bouwen. In het verleden moest je elke baksteen zelf leggen, elke muur metselen en elke leiding leggen. Dat kostte jaren. Nu hebben we een nieuwe, magische bouwploeg: AI-IDE's (zoals Cursor). Deze digitale werknemers kunnen niet alleen bakstenen leggen, maar ze kunnen ook plannen maken, leidingen trekken en hele wijken in een paar uur neerzetten.

Maar hier is de vraag: als je deze AI vraagt om een hele stad te bouwen, is het resultaat dan een stevige, goed ontworpen stad? Of is het een lappendeken van huizen die wel staan, maar waar de fundering wankel is?

Dit is precies wat onderzoekers van de Universiteit van Wuhan en andere instellingen hebben onderzocht in hun paper: "Beyond Functional Correctness: Design Issues in AI IDE-Generated Large-Scale Projects".

Hier is wat ze hebben ontdekt, vertaald naar gewoon Nederlands:

1. De "Magische" Bouwploeg werkt (maar niet zonder hulp)

De onderzoekers wilden weten of Cursor (een AI-IDE) een heel groot softwareproject kan bouwen, niet zomaar een klein stukje code. Ze hebben 10 grote projecten laten bouwen, variërend van een sociale media-app tot een online school en een winkelkassasysteem.

• Het resultaat: Ja, het werkt! De AI kon enorme projecten bouwen met gemiddeld 17.000 regels code en 114 bestanden.
• De truc: De AI deed dit niet zomaar. De onderzoekers gebruikten een slimme methode genaamd FD-HITL.
  • De analogie: Stel je voor dat je een chef-kok bent. Als je de kok alleen maar zegt "Maak een maaltijd", krijg je misschien rommel. Maar als je zegt: "Eerst de soep, dan het vlees, en zorg dat de saus niet te zout is," en je controleert tussendoor of het goed gaat, krijg je een topmaaltijd.
  • De onderzoekers gaven de AI dus geen losse opdracht, maar een stap-voor-stap plan met duidelijke controlepunten. Zo kregen ze projecten die voor 91% correct werkten.

2. De "Schoonmaak" is nog nodig: De verborgen gebreken

Hoewel de gebouwen (de projecten) stonden en de deuren opengingen (ze werkten), keken de onderzoekers naar de kwaliteit van het ontwerp. Ze gebruikten twee digitale inspecteurs (SonarQube en CodeScene) om te kijken of er verborgen gebreken waren.

Het nieuws is minder goed: De AI bouwt veel "slechte" dingen.

Ze vonden 4.498 design-problemen. Hier zijn de meest voorkomende, vertaald naar bouwtermen:

• Dubbel werk (Code Duplication): De AI herhaalt zich vaak.
  • Analogie: Het is alsof de metselaar in elke kamer van het huis exact dezelfde muurtekstuur heeft geplakt, in plaats van één patroon te gebruiken en dat te kopiëren. Als je later de kleur wilt veranderen, moet je dat in 100 plekken doen.
• De "Alles-in-één" kamer (Large Methods): De AI maakt functies die te groot zijn.
  • Analogie: Een kamer waarin de keuken, de slaapkamer, de badkamer én de garage in één ruimte zijn samengevoegd. Het is onmogelijk om te weten wat waar gebeurt, en als je de badkamer wilt renoveren, moet je de hele kamer slopen.
• Verwarrende instructies (Complexity): De logica is te ingewikkeld.
  • Analogie: Een labyrint van gangen met 100 afslagen. Als je een foutje wilt vinden, ben je dagen kwijt.
• Vergeten veiligheidsvoorschriften (Accessibility & Best Practices): De AI vergeet regels.
  • Analogie: De AI bouwt een trap zonder leuning of een deur die niet open gaat voor rolstoelgebruikers. Het werkt voor de "standaardgebruiker", maar faalt voor iedereen die anders is.

3. Waarom gebeurt dit?

De AI is als een supersnelle, maar ongeduldige stagiair.

• Hij is geweldig in het snel neerzetten van muren (functies).
• Hij is echter slecht in het nadenken over de lange termijn. Hij denkt niet: "Hoe ziet dit eruit over 5 jaar als we iets moeten aanpassen?"
• Hij volgt regels niet altijd strikt (zoals de "DRY"-regel: Don't Repeat Yourself of "Doe niet twee keer hetzelfde").

4. Wat betekent dit voor ons?

De conclusie van de onderzoekers is duidelijk: AI kan de bouwvakkers vervangen, maar niet de architect.

• Voor ontwikkelaars: Je kunt AI gebruiken om snel te bouwen, maar je mag nooit stoppen met controleren. Je moet de "hoofdarchitect" blijven. Je moet de AI vertellen wat er gebouwd moet worden en hoe het eruit moet zien, en daarna elke stap controleren.
• De waarschuwing: Als je AI alleen maar laat werken zonder toezicht, krijg je een "snel gebouwde stad" die er mooi uitziet, maar die over een paar jaar instort omdat de fundering te zwak is.

Samenvattend in één zin:

De AI kan een heel huis in een dag bouwen, maar zonder een menselijke architect die de plannen controleert, is het huis waarschijnlijk vol met lekke daken, dubbele muren en trappen die nergens naartoe leiden. De snelheid is geweldig, maar de kwaliteit heeft nog steeds een mens nodig.

Technische samenvatting

Probleemstelling

De integratie van kunstmatige intelligentie (AI), en specifiek Large Language Models (LLM's), heeft de softwareontwikkeling getransformeerd. Eerdere AI-tools (zoals GitHub Copilot) konden voornamelijk code-snippets genereren, maar hadden moeite met het genereren van volledige projecten binnen de ontwikkelomgeving. Een nieuwe generatie van AI-IDE's (zoals Cursor, Claude Code) beschikt over "agente" capaciteiten, waardoor ze context kunnen begrijpen en code op projectniveau kunnen genereren.

Er zijn echter twee belangrijke kennisgaten:

1. Er is beperkt empirisch bewijs over de capaciteit van AI-IDE's om grootschalige softwaresystemen (met complexe architectuur en grote codebases) te genereren.
2. Bestaande studies focussen vaak op functionele correctheid of beveiliging, maar er is een gebrek aan evaluatie van de ontwerpkwaliteit (design quality) van gegenereerde projecten. Het is onduidelijk of deze systemen ontwerpprincipes zoals Single Responsibility Principle (SRP) of Don't Repeat Yourself (DRY) naleven, wat essentieel is voor onderhoudbaarheid op lange termijn.

Methodologie

De auteurs voerden een empirische studie uit met als doel het genereren en evalueren van grote softwareprojecten met behulp van Cursor.

1. Het FD-HITL Framework:
Om de beperkingen van ad-hoc prompting (zoals "Vibe Coding") te overwinnen, stelden de auteurs een Feature-Driven Human-In-The-Loop (FD-HITL) framework voor. Dit framework bestaat uit vier fasen:

• Project Initialisatie: Definieer de context en kies de technologie-stack via samenwerking met Cursor.
• Requirements & Design: Genereer een requirements.md en een gedetailleerde tasklist.md die het project opdeelt in onafhankelijk testbare features.
• Implementatie: Iteratieve ontwikkeling per feature. Eerst backend/database, dan frontend. Constante menselijke feedback en debugging (via logs en screenshots) zijn cruciaal.
• Systeemreview & Testing: Manuele validatie van het volledige systeem tegen de eisen.

2. Data Generatie:

• Er werden 10 grote projecten gegenereerd in drie domeinen: Web-applicaties, Mobiele apps en Utility-tools.
• Gebruikte technologieën: React, Spring Boot, Django, React Native, PHP/WordPress, etc.
• Inclusiecriteria: Minimaal 8.000 regels code (LoC), minimaal 3 technologieën, complexe architectuur (client-server of monolithisch) en externe afhankelijkheden.

3. Evaluatie:

• Functionele Correctheid: Handmatige evaluatie door de auteurs om te controleren of de gegenereerde projecten voldoen aan de specificaties.
• Ontwerpissues Detectie: Gebruik van twee statische analyse-tools:
  • CodeScene: Voor hoog-niveau ontwerpissues (complexiteit, duplicatie).
  • SonarQube: Voor laag-niveau issues (code smells, best practices).
• Filtering: Handmatige verificatie om valse positieven (bijv. regels die strijdig zijn met tool-rules maar conform de technologie-documentatie zijn) te verwijderen.

Belangrijkste Bijdragen

1. FD-HITL Framework: Een gestructureerde aanpak voor het systematisch genereren van grote projecten met AI-IDE's.
2. Groot Dataset: Een dataset van 10 gegenereerde projecten met in totaal 169.646 regels code en bijbehorende projectbeschrijvingen (beschikbaar als DIinAGP).
3. Empirische Analyse: Een uitgebreide kwantitatieve en kwalitatieve analyse van ontwerpissues in AI-genererde code.
4. Aanbevelingen: Praktische richtlijnen voor ontwikkelaars om AI-IDE's effectiever en veiliger te gebruiken.

Resultaten

1. Functionele Correctheid (RQ1):

• Met het FD-HITL framework kon Cursor functionele grote projecten genereren.
• Gemiddelde grootte: 16.965 regels code (LoC) en 114 bestanden per project.
• Gemiddelde functionele correctheid: 91%. De projecten draaiden en voldeden grotendeels aan de eisen, hoewel er soms logische fouten of ontbrekende features waren (bijv. geen update-functionaliteit in een social app).

2. Ontwerpissues (RQ2):
Ondanks de hoge functionele correctheid bevatten de projecten aanzienlijke ontwerpissues die de onderhoudbaarheid bedreigen.

• Aantal issues: CodeScene identificeerde 1.305 issues (9 categorieën) en SonarQube 3.193 issues (11 categorieën).
• Meest voorkomende issues:
  • Code Duplication: De meest frequente issue (28,4% bij CodeScene), wat het DRY-principe schendt.
  • Complexiteit: Hoge cyclomatische complexiteit, grote methoden (Large Methods) en complexe conditionals.
  • Best Practices: Schendingen van framework-specifieke regels (bijv. ontbrekende props-validatie in React, gebruik van verouderde API's).
  • Foutafhandeling: Onjuiste of generieke exception handling.
  • Toegankelijkheid (Accessibility): Ontbrekende labels voor formulieren en niet-toegankelijke interactieve elementen.
• Ontwerpprincipes: De gegenereerde code schendt vaak principes zoals SRP (Single Responsibility Principle), SoC (Separation of Concerns) en KISS (Keep It Simple, Stupid).
• Overlap: Er was een kleine overlap (133 issues) tussen de twee tools, maar deze hadden allemaal een kritieke ernst (Critical severity) en betroffen voornamelijk code-complexiteit.
• Technologie-specifiek: 59% van de SonarQube-issues was technologie-specifiek (voornamelijk JavaScript/React/Node.js en Java/Spring Boot).

Betekenis en Conclusie

De studie concludeert dat AI-IDE's zoals Cursor, wanneer ze worden gebruikt met een gestructureerd mens-in-de-lus framework, in staat zijn om grootschalige, functionele softwaresystemen te produceren. Echter, deze systemen zijn niet direct productieklaar zonder grondige menselijke inspectie.

• Kwaliteitsrisico: De gegenereerde code bevat veel "technische schuld" in de vorm van ontwerpissues die op lange termijn de evolutie en het onderhoud van het systeem in gevaar brengen.
• Rol van de Mens: Menselijke ontwikkelaars moeten zich richten op hoog-niveau taken (vereistenanalyse, architectuur, decompositie in features) en de AI gebruiken voor de uitvoering van laag-niveau taken.
• Aanbeveling: Ontwikkelaars moeten niet alleen focussen op "werkt het?", maar ook op "is het goed ontworpen?". Het gebruik van statische analyse-tools en het expliciet specificeren van ontwerpeisen (zoals toegankelijkheid) is essentieel bij het gebruik van AI-IDE's.

Kortom: AI-IDE's zijn krachtige hulpmiddelen voor snelheid en prototyping, maar vervangen momenteel niet de engineering-vaardigheden van ervaren ontwikkelaars, vooral niet voor het waarborgen van ontwerpkwaliteit.