Quality Assurance of LLM-generated Code: Addressing Non-Functional Quality Characteristics

Deze studie onthult een significante discrepantie tussen academische focus, industriële prioriteiten en het gedrag van LLM's met betrekking tot niet-functionele kwaliteitskenmerken van gegenereerde code, en pleit voor de integratie van kwaliteitsborging in generatiepijplijnen om technische schuld te voorkomen.

De kern

Stel je voor dat je een zeer slimme, maar soms wat ongeduldige assistent hebt die alles kan schrijven: van recepten tot complexe computerprogramma's. Deze assistent is een LLM (een groot taalmodel voor code). Hij is razendsnel en kan in seconden duizenden regels code genereren.

Maar hier is het probleem: deze assistent is net als een beginnende kok die een gerecht maakt dat er perfect uitziet en smaakt (het werkt), maar misschien te veel zout bevat, te snel opwarmt of na een week in de koelkast rot.

Dit artikel van onderzoekers van de Linköping Universiteit in Zweden kijkt niet alleen naar of het gerecht werkt, maar vooral naar de kwaliteit ervan. Ze noemen dit "niet-functionele eigenschappen". Laten we dit uitleggen met een paar creatieve vergelijkingen.

1. Het Grote Misverstand: "Het werkt, dus het is goed"

Vroeger keken onderzoekers alleen naar of de code deed wat hij moest doen (functionele juistheid). Het was alsof je alleen keek of de auto startte.

• De realiteit: De auto start misschien, maar hij verbruikt misschien 50 liter benzine per 100 kilometer (slechte prestatie), hij heeft een slechte rem (slechte veiligheid), of hij is zo ingewikkeld gebouwd dat niemand hem ooit kan repareren (slechte onderhoudbaarheid).

De onderzoekers wilden weten: Is de code die deze AI schrijft ook echt goed voor de lange termijn?

2. Drie Manieren om het Te Onderzoeken

De onderzoekers hebben drie verschillende methoden gebruikt, alsof ze een detective zijn die een zaak oplost:

• De Literatuuronderzoek (Het Boek van de Geschiedenis):
  Ze hebben 109 wetenschappelijke artikelen gelezen.

  • Wat vonden ze? De academische wereld is heel bezorgd over veiligheid (zodat hackers niet inbreken) en snelheid. Maar ze kijken vaak niet genoeg naar hoe makkelijk de code is om te lezen of te onderhouden. Het is alsof ze alleen kijken of de auto niet ontploft, maar vergeten te kijken of de stoelen comfortabel zijn.

• De Werkplaatsen (De Praten met de Vaklieden):
  Ze hebben met 15 echte software-ontwikkelaars uit de industrie gepraat.

  • Wat vonden ze? De praktijk is anders! Voor bedrijven is onderhoudbaarheid en leesbaarheid het allerbelangrijkste. Ze maken zich zorgen dat als AI te veel code schrijft die "raar" of onduidelijk is, het bedrijf later vastloopt in een berg aan technische schuld.
  • De analogie: De wetenschappers kijken naar de motor, maar de vaklieden zeggen: "Hé, de motor is misschien sterk, maar als de bedrading zo rommelig is dat niemand hem kan repareren, is het een ramp."

• Het Experiment (De Proef in het Lab):
  Ze hebben drie verschillende AI-modellen (GPT-4o, Claude, DeepSeek) laten werken aan echte problemen in grote softwareprojecten. Ze hebben gekeken naar drie dingen:

  1. Veiligheid: Is er een gat voor hackers?
  2. Onderhoudbaarheid: Is de code netjes en logisch?
  3. Prestaties: Is het snel en zuinig?

3. De Verbluffende Resultaten: De "Gouden Kooi"

Wat bleek er uit het experiment?

• De AI is niet perfect: De code die de AI schreef, werkte vaak wel (de auto startte), maar was vaak rommeliger, trager of onveiliger dan code die door een mens was geschreven.
• De "Prompt" is geen toverstaf: De onderzoekers probeerden de AI te corrigeren door haar specifieke instructies te geven (bijvoorbeeld: "Maak het veiliger!" of "Maak het sneller!").
  • Het probleem: Als je de AI vraagt om sneller te zijn, wordt hij vaak trager in andere dingen, of hij breekt zelfs de code. Het is alsof je een kok vraagt om het eten sneller te bakken, en hij gooit er zo veel vuur op dat het verbrandt.
  • Trade-offs: Je kunt niet alles tegelijk optimaliseren. Als je de code veiliger maakt, wordt hij soms trager. Als je hem sneller maakt, wordt hij soms onveiliger. De AI kan dit evenwicht niet goed vinden zonder hulp.

4. De Belangrijkste Les: "Passen" is niet genoeg

De grootste conclusie van het artikel is dit:
In de huidige wereld van AI-programmeren is het doel vaak: "Laat de code de tests halen."
Maar dit is gevaarlijk. Het is alsof je een huis bouwt dat voldoet aan de bouwvergunning (de tests), maar dat na tien jaar instort omdat de fundamenten slecht waren.

De onderzoekers zeggen: "We moeten stoppen met alleen kijken of de code werkt, en gaan kijken of de code goed is."

Samenvatting in één zin

Deze AI-assistent is een wonder van snelheid, maar zonder menselijke controle en betere kwaliteitschecks, bouwt hij een huis dat wel staat, maar dat vol zit met lekkages, trage deuren en gevaarlijke bedrading. We moeten de AI leren om niet alleen te werken, maar om te bouwen met kwaliteit.

De toekomst: De onderzoekers pleiten ervoor dat we in de software-ontwikkeling "kwaliteitscontroleurs" inbouwen die de AI in real-time controleren, zodat we niet alleen code krijgen die werkt, maar code die ook veilig, snel en makkelijk te onderhouden is.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het artikel "Quality Assurance of LLM-generated Code: Addressing Non-Functional Quality Characteristics" in het Nederlands.

1. Probleemstelling

Hoewel Large Language Models (LLMs) voor codegeneratie (zoals GitHub Copilot) wijdverbreid zijn geïntegreerd in software-engineering workflows, focussen eerdere evaluaties bijna uitsluitend op functionele correctheid (werkt de code?). Er is echter een gebrek aan inzicht in de niet-functionele kwaliteitskenmerken (NFQCs) van gegenereerde code, zoals beveiliging, onderhoudbaarheid en prestatie-efficiëntie.

De auteurs identificeren drie kernproblemen:

• Misalignement: Academische onderzoeken focussen vaak op beveiliging en prestaties, terwijl industriële professionals zich zorgen maken over onderhoudbaarheid en leesbaarheid (en het risico op technische schuld).
• Gebrek aan systematische evaluatie: Er ontbreekt een unified framework om NFQCs te meten; bestaande studies gebruiken vaak inconsistente terminologie en tools.
• Interactie en Trade-offs: Het is onduidelijk hoe verschillende NFQCs met elkaar interageren en of het optimaliseren van één kenmerk (bijv. snelheid) ten koste gaat van andere (bijv. beveiliging of onderhoudbaarheid) in realistische scenario's.

2. Methodologie

De studie hanteert een mixed-methods benadering bestaande uit drie complementaire onderdelen, allemaal gestructureerd rond het ISO/IEC 25010 kwaliteitsmodel:

1. Literatuurreview:

   • Analyse van 109 papers (gepubliceerd tussen 2022 en 2025) die zich richten op NFQCs van gegenereerde code.
   • Doel: In kaart brengen van trends, gaten in het onderzoek en de huidige evaluatiemethoden.

2. Industriële Workshops:

   • Twee sessies met 15 praktijkmensen uit zeven verschillende organisaties (waaronder leden van het Software Center).
   • Doel: Het verzamelen van perspectieven over prioriteiten, pijnpunten en risico's bij het integreren van gegenereerde code in bestaande workflows.

3. Empirische Evaluatie:

   • Dataset: Gebruik van SWE-bench Lite (300 real-world GitHub issues uit Python-repositories zoals Django en SymPy).
   • Modellen: Drie LLMs: Claude 4 Sonnet, DeepSeek-Reasoner en GPT-4o.
   • Opzet: Een driedelige experimentele pijplijn:
     1. Baseline: Generatie van patches via SWE-agent en evaluatie op functionele correctheid, runtime, geheugen, beveiliging en onderhoudbaarheid (via CodeQL).
     2. Filter & Prompt Design: Selectie van instances die door alle modellen correct zijn opgelost. Ontwerp van specifieke prompts die feedback van CodeQL (voor beveiliging/onderhoudbaarheid) of prestatie-eisen (runtime/geheugen) bevatten.
     3. Regeneratie & Evaluatie: Opnieuw genereren van patches met de geoptimaliseerde prompts en vergelijken met de baseline om trade-offs te analyseren.

3. Belangrijkste Bijdragen

• Kwantificering van de Kwaliteitskloof: Het artikel toont aan dat LLM-generatie vaak functioneel correcte code produceert die echter aanzienlijk meer technische schuld introduceert (meer CodeQL-waarschuwingen, grotere patch-grootte, cyclische imports) dan door mensen geschreven "gold patches".
• Ontmaskering van Trade-offs: De studie levert empirisch bewijs dat het optimaliseren van één NFQC via prompts vaak leidt tot verslechtering van andere kenmerken of zelfs tot het falen van de functionele correctheid.
• Misalignement tussen Theorie en Praktijk: Het documenteert een duidelijke discrepantie tussen wat onderzoekers meten (veiligheid, snelheid) en wat ontwikkelaars nodig hebben (onderhoudbaarheid, leesbaarheid op lange termijn).
• Instabiliteit van Prompt-Optimalisatie: Het bewijst dat het sturen van LLMs via prompts om specifieke NFQCs te verbeteren in complexe, repository-level taken onbetrouwbaar is en vaak tot regressies leidt.

4. Resultaten

De empirische resultaten tonen de volgende patronen:

• Functionele Correctheid: Alle modellen presteerden aanzienlijk slechter dan de menselijke "gold patches" (oplossingspercentages varieerden van 16% tot 36%). Veel pogingen faalden door omgevings- of shell-commando-fouten in plaats van code-logica.
• Onderhoudbaarheid (Maintainability):
  • Gegenereerde patches veroorzaakten aanzienlijk meer CodeQL-rules dan menselijke patches (bijv. GPT-4o: 423 aanbevelingen vs. 30 bij menselijke patches).
  • Een specifiek probleem is cyclische imports, die zelden voorkomen in menselijke patches maar dominant zijn in LLM-generaties, wat wijst op een gebrek aan project-brede contextbegrip.
• Beveiliging (Security):
  • Hoewel het totale aantal beveiligingsissues laag bleef, introduceerden LLMs nieuwe kwetsbaarheden (voornamelijk clear-text-storage-sensitive-data).
  • Het optimaliseren voor beveiliging via prompts leidde vaak tot een daling van de functionele correctheid (bij GPT-4o daalde het oplossingspercentage naar 12%).
• Prestaties (Runtime & Geheugen):
  • LLM-patches waren over het algemeen trager en verbruikten meer geheugen dan menselijke patches.
  • Trade-offs: Het optimaliseren voor snelheid leidde vaak tot een explosie in geheugenverbruik (en vice versa). In sommige gevallen verslechterde de prestatie zelfs in de richting die geoptimaliseerd moest worden.
• Modelverschillen: Er is geen "beste" model voor alle doelen. Claude 4 Sonnet presteerde het meest robuust bij onderhoudbaarheid en beveiliging, terwijl DeepSeek-Reasoner beter presteerde bij geheugenoptimalisatie. GPT-4o had de hoogste syntactische succesratio maar de laagste functionele oplossingsratio.

5. Betekenis en Conclusie

De studie concludeert dat het huidige paradigma van "code genereren die de tests haalt" onvoldoende is voor professionele software-engineering. LLMs hebben geen intrinsiek besef van kwaliteit en behandelen alle test-passende oplossingen als gelijkwaardig, wat leidt tot een opeenhoping van technische schuld.

Kernboodschap:
Om LLM-generatie veilig en bruikbaar te maken, moeten kwaliteitsborgingsmechanismen (QA) worden geïntegreerd in de generatiepijplijn. Dit betekent niet alleen het testen van functionaliteit, maar het actief monitoren en sturen van NFQCs (zoals onderhoudbaarheid en beveiliging) tijdens het generatieproces. Toekomstig werk moet zich richten op het ontwikkelen van systemen die feedback van statische analyse tools direct gebruiken om de generatie te sturen, in plaats van te vertrouwen op statische prompts of post-hoc evaluaties.

De studie benadrukt dat zonder deze integratie, het gebruik van LLMs in real-world systemen het risico vergroot op het introduceren van fragiele, onveilige en moeilijk onderhoudbare codebases.