← Nieuwste papers
💻 computer science

A Pilot Study on Detecting Software Design Patterns with Large Language Models: An Empirical Evaluation

Deze pilotstudie evalueert empirisch de prestaties van vier Large Language Models en ensemble-methoden bij het detecteren van vijf softwareontwerppatronen in broncode, PlantUML-visualisaties en tekstuele beschrijvingen, waarbij NextCoder en Gemma 3 de beste resultaten laten zien.

Oorspronkelijke auteurs: Oishik Chowdhury, Bastin Tony Roy Savarimuthu, Sherlock A. Licorish

Gepubliceerd 2026-04-21
📖 4 min leestijd☕ Koffiepauze-leesvoer

Oorspronkelijke auteurs: Oishik Chowdhury, Bastin Tony Roy Savarimuthu, Sherlock A. Licorish

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 softwareontwikkeling net zo is als het bouwen van een enorme stad. Ontwikkelaars bouwen huizen, bruggen en wegen. Maar als je naar een oude stad kijkt die door generaties is gebouwd, is het soms lastig om te begrijpen waarom bepaalde gebouwen zo staan of hoe ze met elkaar verbonden zijn.

In de softwarewereld noemen we deze bewezen bouwplannen ontwerppatronen. Het zijn slimme, herhaalbare oplossingen voor veelvoorkomende problemen. Als je deze patronen herkent, snap je de stad (of het programma) veel sneller. Maar als ze verkeerd zijn toegepast, krijg je een stad vol met "codegeur" (dure fouten) of zelfs "anti-patronen" (slechte ideeën die er goed uitzien).

De vraag is: Hoe vinden we deze patronen snel en goed?

Vroeger deden onderzoekers dit met strenge, statische regels (alsof je een plattegrond met liniaal en passer bestudeert). Maar nu hebben we Grote Taalmodellen (LLMs) – denk aan super-intelligente AI's die net als mensen kunnen lezen en redeneren.

Deze paper is een proefstudie (een pilot) om te kijken of deze AI's goed kunnen werken als "detective" voor softwarepatronen. Hier is wat ze hebben gedaan, vertaald naar alledaags taal:

1. De Proef: De AI's in de Loods

De onderzoekers hebben vier verschillende AI-modellen getest. Je kunt ze zien als vier verschillende detectives:

  • Qwen2.5 Coder, NextCoder en Nxcode-CQ: Dit zijn gespecialiseerde "coder-detectives". Ze zijn getraind op code en weten precies hoe software werkt.
  • Gemma 3: Dit is een "algemene detective". Hij is niet specifiek getraind op code, maar is een slimme, algemene denker.

Ze hebben vijf specifieke patronen opgezocht (zoals de Singleton – een unieke sleutel voor een deur, of de Decorator – een verpakking die iets mooier maakt).

2. De Drie Manieren om te Kijken (De Input)

De onderzoekers gaven de detectives drie verschillende soorten "dossiers" om te analyseren:

  1. De Ruwe Code: De originele, soms rommelige bouwtekeningen (de programmeertaal).
  2. PlantUML: Een vereenvoudigde schets of een cartoon-versie van de bouwplannen.
  3. Een Tekstbeschrijving: Iemand die het verhaal van het gebouw in gewone taal uitlegt, zonder technische jargon.

3. Wat Vonden Ze? (De Resultaten)

  • De Specialisten vs. De Algemene Denker:
    De gespecialiseerde coder-detectives deden het over het algemeen goed, maar de Gemma 3 (de algemene detective) verraste iedereen! Wanneer de AI's een tekstuele beschrijving kregen, was Gemma 3 vaak de beste. Dit suggereert dat je niet altijd een gespecialiseerde "coder-AI" nodig hebt; soms is een slimme, algemene denker die het verhaal begrijpt, juist beter.

  • Het Teamwerk (Ensembles):
    De onderzoekers probeerden ook een jury-systeem. Als drie detectives samenwerken en meer dan de helft zegt "Ja, dit is een patroon!", dan is het een "Ja". Dit teamwerk (de ensemble-methode) gaf vaak de meest betrouwbare resultaten. Het is alsof je drie experts vraagt om samen een oordeel te vellen in plaats van één persoon.

  • Wat is het beste dossier?
    Je zou denken dat de ruwe code het beste is, of misschien de schets (PlantUML). Maar het verrassende nieuws is: het maakt niet uit. Of je de AI nu de ruwe code, de schets of de tekstbeschrijving geeft, ze presteerden ongeveer even goed.

    • De schets (PlantUML) gaf heel weinig fouten (hoge precisie), maar miste soms patronen.
    • De tekstbeschrijving vond het meeste (hoge recall), maar maakte soms wat meer fouten.
    • Conclusie: Je kunt kiezen wat voor jou het makkelijkst is om te genereren; de AI haalt er wel iets uit.

4. Waarom is dit belangrijk?

Stel je voor dat je een nieuw team binnenkomt in een bedrijf met een oud, complex systeem.

  • Vroeger: Je moest urenlang door de code graven om te begrijpen hoe het werkt.
  • Nu: Met deze AI-tools kan een nieuwe developer (of een ervaren developer) in seconden zien: "Ah, hier gebruiken ze het Decorator-patroon!" of "Oeps, hier is het Singleton-patroon verkeerd toegepast."

Dit helpt om:

  1. Nieuwe mensen sneller op te leiden (ze begrijpen de architectuur direct).
  2. Fouten sneller te vinden (zoals slechte bouwplannen die later duur worden).
  3. Betere gesprekken te voeren (teams kunnen praten over "de brug" in het systeem in plaats van over duizenden regels code).

Samenvattend

Deze studie laat zien dat AI's (zowel gespecialiseerde als algemene) steeds beter worden in het vinden van de "bouwplannen" in software. Het is alsof we een magische bril hebben gekregen die ons laat zien hoe de stad is opgebouwd, ongeacht of we naar de blauwdrukken, de schetsen of de verhalen kijken. Het is nog niet perfect, maar het is een enorme stap voorwaarts om software makkelijker te begrijpen en te verbeteren.

Verdrinkt u in papers in uw vakgebied?

Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.

Probeer Digest →