💻 computer science

Can LLMs Produce Better Object-Oriented Designs than Human-Involved Development?

Deze studie vergelijkt de kwaliteit van objectgeoriënteerd ontwerp in Java-projecten uit de periode voor de komst van LLM's, na de komst van LLM's en in zuivere LLM-projecten, en stelt vast dat hoewel door LLM's gegenereerde code minder complexiteit vertoont en minder codegeuren bevat, deze vaak te kampen heeft met oververeenvoudiging en een zwakke scheiding van verantwoordelijkheden, wat onderstreept dat menselijke begeleiding bij het ontleden van ontwerpen nog steeds noodzakelijk blijft.

Oorspronkelijke auteurs: Zushuai Zhang, Elliott Wen, Ewan Tempero

Gepubliceerd 2026-05-20

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Zushuai Zhang, Elliott Wen, Ewan Tempero

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

Stel je voor dat je een meesterarchitect bent die de opdracht heeft gekregen een complex huis te bouwen. Je hebt drie verschillende teams om uit te kiezen voor de daadwerkelijke bouw:

De Oude Garde (PreAI): Ervaren bouwers die nooit een computerassistent hebben gebruikt. Ze tekenen hun eigen blauwdrukken en bouwen alles met de hand.
Het Hybride Team (PostAI): Ervaren bouwers die nu een krachtige computerassistent hebben. Ze tekenen nog steeds de blauwdrukken en nemen de grote beslissingen, maar ze laten de computer hen helpen bij het leggen van bakstenen en het zagen van hout.
Het Robotteam (PureAI): Een team geavanceerde robots dat een eenvoudige mondelinge beschrijving van het huis ontvangt en het hele gebouw van begin tot eind bouwt, zonder dat een mens een gereedschap aanraakt.

Dit artikel stelt een simpele vraag: Welk team bouwt het beste huis? Specifiek: creëert het "Robotteam" een ontwerp dat net zo goed is, of zelfs beter, dan de menselijke teams?

Het Experiment

De onderzoekers stelden een "bouwuitdaging" op met behulp van een klassiek bordspel genaamd Kalah. Ze vroegen drie groepen een Java-softwareprogramma te bouwen om dit spel te spelen:

Groep 1 (PreAI): Studenten uit 2021 (voordat AI-codingtools gebruikelijk waren).
Groep 2 (PostAI): Studenten uit 2024 (nadat AI-tools populair werden).
Groep 3 (PureAI): Dezelfde opdracht gegeven aan drie verschillende top-tier AI-modellen, die de code volledig zelf genereerden.

Ze keken niet alleen of het spel werkte; ze bekeken de kwaliteit van het ontwerp. Denk hierbij aan het controleren of het huis een logische indeling heeft, of de kamers de juiste grootte hebben en of de loodgieterswerkzaamheden niet verward zijn.

Wat Ze Vonden

1. Het Robotteam Bouwde "Kleinere" Huizen, Maar Ze Waren Te Eenvoudig

De PureAI (Robot)-teams bouwden code die er aan de oppervlakte zeer schoon uitzag.

Het Goede Nieuws: Hun code had minder "geuren" (slechte gewoonten zoals rommelige code) en leek over het algemeen minder complex. Het was als een huis met zeer weinig muren en een zeer open plattegrond.
Het Slechte Nieuws: Deze eenvoud was eigenlijk een probleem. De robots vereenvoudigden het ontwerp te veel. In plaats van aparte kamers te bouwen voor de "Speler", het "Bord" en de "Gaten" (de gaten in het spel), smolten de robots alles vaak samen in één of twee gigantische kamers.
De Metafoor: Stel je een huis voor waar de keuken, slaapkamer en badkamer slechts één grote kamer zijn zonder deuren. Het is zeer eenvoudig en makkelijk schoon te maken (lage complexiteit), maar het is vreselijk om in te wonen omdat je je activiteiten niet kunt scheiden (slechte "scheiding van verantwoordelijkheden"). De robots misten de belangrijke "abstracties" (de onderscheidende concepten) die een systeem begrijpelijk maken.

2. Het Hybride Team (PostAI) Begon Te Gedragen Als Robots

De studenten uit 2024 (die AI-helpers gebruikten) bouwden niet helemaal zo "robotachtig" als het PureAI-team, maar ze waren dichter bij de robots dan de studenten uit 2021.

Hun ontwerpen werden ook iets te eenvoudig, waarbij ze enkele van de onderscheidende "kamers" (concepten) misten die de studenten uit 2021 wel hadden opgenomen.
In tegenstelling tot de robots, had de code van het Hybride Team echter meer rommelige gewoonten (codegeuren) dan de studenten uit de oude school. Het lijkt erop dat wanneer mensen proberen robotgegenereerde code te repareren of te bewerken, ze soms lokaal nieuwe rommel introduceren, zelfs als de algehele structuur er simpel uitziet.

3. De "Prompt" Maakt Uit, Maar Het Is Geen Magische Staf

De onderzoekers probeerden de robots meer specifieke instructies te geven, zoals "Zorg ervoor dat je een aparte klasse hebt voor de Speler en een aparte voor het Bord."

Resultaat: Wanneer de instructies specifieker waren, deden de robots het beter in het creëren van aparte "kamers" (concepten).
Beperking: Zelfs met de beste instructies haalden de robots de kwaliteit van de door mensen ontworpen huizen nog niet helemaal. Ze neigden nog steeds tot vereenvoudiging.

De Grote Conclusie

Robots zijn geweldig in het leggen van bakstenen, maar mensen zijn nog steeds nodig om de blauwdrukken te tekenen.

Het artikel concludeert dat AI weliswaar code kan schrijven die werkt en er schoon uitziet, maar dat het worstelt met het grote plaatje van Object-Oriented Design. Het neigt ertoe alles samen te voegen om dingen "eenvoudig" te maken, wat de software op de lange termijn eigenlijk moeilijker onderhoudbaar maakt omdat de onderscheidende onderdelen van het systeem verloren gaan.

PureAI (Robots): Uitstekend in het vermijden van kleine fouten, maar slecht in het begrijpen van de grote structuur.
PostAI (Mensen met AI): Beginnen wat van de structurele diepte te verliezen en maken de code soms rommeliger in het proces.
De Les: Als je AI gebruikt om software te schrijven, moet je optreden als de architect. Je moet de AI precies vertellen hoe het probleem in onderscheidende delen moet worden opgesplitst (decompositie) en waarvoor elk deel verantwoordelijk is. Als je gewoon zegt "bouw een spel", zal de AI een rommelige, te eenvoudige versie bouwen die er schoon uitziet, maar moeilijk te repareren is later.

Technische Samenvatting: Kunnen LLMs Betere Object-Oriented Ontwerpen Produceren dan Menselijk Betrokken Ontwikkeling?

Probleemstelling

Hoewel Large Language Models (LLMs) steeds bekwaamer worden in het genereren van code, blijft hun vermogen om hoogwaardige Object-Oriented Design (OOD) voor projecten met meerdere klassen te produceren onduidelijk. Eerdere onderzoek heeft zich grotendeels gericht op:

Functionele correctheid op probleemniveau (enkele methoden of klassen) in plaats van projectarchitectuur.
Pre-LLM-baselines, waarbij de impact van door LLM's ondersteunde menselijke ontwikkeling (PostAI) niet in aanmerking wordt genomen.
Hoogwaardige artefacten (bijv. UML-diagrammen) in plaats van de onderhoudbaarheid en structurele kwaliteit van geïmplementeerde code.

Deze studie adresseert het gat in het begrip hoe de OOD-kwaliteit in projecten die end-to-end door LLM's worden gegenereerd (PureAI) vergeleken kan worden met menselijk betrokken projecten die zijn geproduceerd voor (PreAI) en na (PostAI) de wijdverbreide adoptie van LLM's.

Methodologie

De auteurs voerden een vergelijkende casestudie uit met behulp van een postdoctorale Java-opdracht: het implementeren van het Kalah-bordspel. De studie analyseerde 11 datasets over drie auteurschapsvoorwaarden:

PreAI (Menselijk Betrokken, Pre-LLM): 93 inzendingen uit maart 2021, voorafgaand aan de publieke release van grote LLM-coding-assistenten.
PostAI (Menselijk Betrokken, Post-LLM): 57 inzendingen uit augustus 2024, nadat LLM-tools mainstream waren geworden.
PureAI (LLM-gegenereerd): 810+ generatieruns met drie hedendaagse modellen (gpt-5.4, gemini-2.5-pro, gemini-3.1-pro-preview) over drie promptvarianten die varieerden in specificiteit van OOD-gidsing (Geen, Breed, Specifiek). Alleen runs die alle 19 functionele testcases haalden (na maximaal vijf reparatieiteraties) werden behouden.

Evaluatiemetrics

De studie hanteerde een multidimensionaal evaluatiekader:

OOD-metrics: 13 metrics die structurele kenmerken vastleggen, waaronder Weighted Methods per Class (WMC), Coupling Between Object Classes (CBO), Lack of Cohesion in Methods (LCOM), Depth of Inheritance Tree (DIT), Aantal Klassen (#Cl) en Lines of Code (LOC).
Code Smell-dichtheid: Projectniveau-dichtheid van 30 gedetecteerde smell-types (11 op methodeniveau, 19 op klassenniveau), genormaliseerd naar grootte (KLOC).
Domeinmodellering:
- Conceptrepresentatie: Of zes sleuteldomeinconcepten (Board, Game, Player, Pit, House, Store) expliciet als klassen waren gemodelleerd.
- Runtime-conformiteit: Of het aantal geïnstancieerde objecten overeenkwam met de eisen die door de domeinconcepten werden geïmpliceerd.

Statistische Analyse

Vergelijkingen maakten gebruik van de Mann–Whitney U-test met Cliff's delta ( $\delta$ ) voor effectgrootte op niet-binair metrics, en Chi-kwadraat/Fisher's exacte tests met Odds Ratios (OR) voor binaire metrics. Resultaten werden gecorrigeerd voor meervoudige vergelijkingen met de Benjamini–Hochberg-procedure.

Belangrijkste Bijdragen

Eerste Vergelijkende Analyse: Dit is de eerste studie die OOD-kwaliteit vergelijkt tussen PreAI-, PostAI- en PureAI-voorwaarden in een projectniveau-omgeving.
Multidimensionale Evaluatie: De studie combineert kwantitatieve OOD-metrics, code smell-analyse en op vereisten gebaseerde domeinmodellering om een holistisch beeld van ontwerpkwaliteit te geven.
Empirisch Bewijs over Vereenvoudiging: Het artikel levert bewijs dat hoewel door LLM's gegenereerde code vaak "schoner" lijkt (lagere smell-dichtheid), dit vaak geassocieerd is met oververeenvoudiging (ontbrekende abstracties, zwakkere verantwoordelijkheidsafscheiding).
Inzichten in PostAI-trends: De studie toont aan dat menselijk betrokken projecten in het LLM-tijdperk (PostAI) ontwerptendensen vertonen die dichter bij PureAI liggen (vereenvoudiging) dan bij PreAI, maar zonder dezelfde reductie in code smells.

Resultaten

RQ1: Verschillen tussen PreAI, PostAI en PureAI

Structurele Eenvoud versus Oververeenvoudiging: PureAI-projecten vertonen over het algemeen minder klassen, lagere totale complexiteit, grootte en koppeling in vergelijking met menselijke projecten. Deze "eenvoud" correleert echter met oververeenvoudiging:
- Hogere gemiddelde en maximale percentage complexiteit/koppeling per klas (last geconcentreerd in minder klassen).
- Lagere coherentie (hogere LCOM), aangezien enkele klassen vaak meerdere domeinconcepten vertegenwoordigen.
- Minder expliciet vertegenwoordigde domeinconcepten (ontbrekende abstracties).
Code Smells: PureAI-projecten vertonen een significant lagere code smell-dichtheid (zowel op methodeniveau als klassenniveau) in vergelijking met menselijk betrokken projecten.
PostAI-convergentie: PostAI-projecten zijn statistisch dichter bij PureAI dan bij PreAI op veel OOD-metrics, met vergelijkbare tendensen tot vereenvoudiging en ontbrekende domeinconcepten. In tegenstelling tot PureAI hebben PostAI-projecten echter een hogere code smell-dichtheid dan PreAI, met name op methodeniveau.
Runtime-conformiteit: Zodra een domeinconcept wordt vertegenwoordigd, is de kans dat PureAI-projecten runtime-conform zijn groter dan bij menselijke projecten.

RQ2: Effect van Prompt Specificiteit in PureAI

Impact van Gidsing: Het verhogen van prompt specificiteit (van Geen $\to$ $\to$ Breed $\to$ $\to$ Specifiek) leidt over het algemeen tot:
- Meer klassen en hogere totale complexiteit/grootte/koppeling (weg van oververeenvoudiging).
- Lagere gemiddelde en maximale percentage complexiteit/koppeling per klas.
- Verminderde algehele en methodeniveau code smell-dichtheid.
- Verbeterde representatie van domeinconcepten (hoewel effecten variëren per model).
Beperkingen: Specificere prompts sluiten de kloof met menselijk betrokken projecten niet volledig. Voor sommige modellen (bijv. O54) levert het verhogen van specificiteit van Breed naar Specifiek beperkte extra verbetering op.

Betekenis en Implicaties

Het artikel concludeert dat hoewel LLM's effectief kunnen omgaan met implementatiedetails (het produceren van code met minder smells en hoge runtime-conformiteit), ze moeite hebben met object-georiënteerde decompositie en toewijzing van verantwoordelijkheden zonder expliciete menselijke gidsing.

Risico op Oververeenvoudiging: PureAI-projecten lijken vaak eenvoudiger en minder "stinkend", maar dit maskeert een gebrek aan juiste abstractie en verantwoordelijkheidsafscheiding, wat de lange termijn onderhoudbaarheid kan schaden.
Waarschuwing voor PostAI: De beschikbaarheid van LLM-tools kan menselijke ontwikkelaars ertoe brengen ontwerpen te produceren die LLM-oververeenvoudiging nabootsen (ontbrekende concepten) terwijl ze nieuwe lokale problemen introduceren (smells op methodeniveau), wat productiviteitswinsten mogelijk tenietdoet.
Noodzaak van Mens-in-de-Lus: Passende menselijke gidsing op hoog niveau over decompositie en domeinmodellering blijft cruciaal. Het uitsluitend vertrouwen op generieke of zelfs specifieke OOD-prompten is onvoldoende om mensvergelijkbare ontwerpkwaliteit te bereiken.
Reviewstrategie: Code reviews in door LLM's ondersteunde omgevingen moeten expliciet controleren op ontbrekende domeinconcepten en oververeenvoudigde structuren, in plaats van alleen functionele correctheid of lokale code smells.

De studie suggereert dat het meest effectieve gebruik van LLM's in OOD is om ze te benutten voor implementatie binnen een structuur die is gedefinieerd door menselijke experts die het domein en de gewenste architectuur begrijpen.