Kwaliteit software onder druk door AI-gegenereerde code

Softwareontwikkeling kan enorm versnellen met de inzet van moderne AI-tools. “Indrukwekkend snel zelfs”, vindt Werner Heijstek. “Wat je krijgt, werkt ook. Alleen zodra je er daarna weer iets aan wilt veranderen, wordt het vaak heel lastig. Eigenlijk is AI een variant van rapid prototyping, maar dan heel rapid.”

SIG heeft de proef op de som genomen en drie werkwijzen vergeleken waarbij AI wordt ingezet voor het creëren van nieuwe software. Daarbij werd een gestandaardiseerde methode ingezet voor de beoordeling van de kwaliteit en onderhoudbaarheid van met AI-gegenereerde software waarbij het cijfer 1 de slechtste score is en 5 een uitstekend resultaat. Nieuwe systemen moeten volgens de methodiek minimaal een score 4 halen en software met een score van minder dan 2 is vergelijkbaar met legacy.
De score voor de onderzochte systemen:

• Volledig door agents gegenereerde code (FastRender): onderhoudbaarheid 1,1 en architectuur 2,2.
• Inzet van een team van verschillende LLM’s die werken alsof ze een menselijk ontwikkelteam vormen (Claude’s C Compiler): onderhoudbaarheid 1,9 en architectuur 2,4.
• Human in the Loop (OpenClaw): onderhoudbaarheid 3,1 en architectuur 4,4.

De conclusie is dus dat twee AI-only systemen uitkomen op een legacy-achtige onderhoudbaarheid en een zwakke tot middelmatige architectuur. Heijstek: “Zo’n volledig door AI gegenereerde code-unit is bovenmatig complex. Als je wat wilt aanpassen, snap je niet wat de code doet en dus ook niet waar je moet beginnen. Het is ook niet duidelijk wat de gevolgen zijn van de aanpassing. De nieuwe code is dus eigenlijk gelijk legacy.”

De oorzaak ligt volgens Heijstek in de training van de LLM’s. Daarvoor gebruikten de makers bijna alle sourcecode die beschikbaar is. Dat levert per definitie een marktgemiddelde op waardoor de tools zonder gerichte optimalisatie, automatisch gemiddelde kwaliteit opleveren. Die is niet goed te noemen en in ieder geval niet acceptabel voor de meeste organisaties.

Meer LLM's toevoegen helpt niet

Menselijke controle levert duidelijk betere evolueerbaarheid en modulariteit op, zoals de derde casus laat zien. Toch kan AI ook daarin een grotere rol spelen, maar niet met de aanpak die veel organisaties kiezen door meer LLM-gebaseerde tools in te zetten, vindt Heijstek. “LLM’s zijn niet-deterministische systemen, dus weet je niet wat ze gaan doen. Als de ene agent de andere aanspreekt op een fout of een kwetsbaarheid, antwoordt die meteen met “oh sorry, het spijt me”, maar zonder garantie dat het volgende antwoord ook beter is. Wanneer je een deterministisch controlesysteem inzet kun je daar eindeloos lief tegen doen, maar als wat je aanbiedt niet voldoet aan de regels, blijft het gewoon “nee” zeggen.” Heijstek legt uit dat een deterministisch systeem een vast stel regels en checks bevat en die toepast op aangeleverde code. Zo’n systeem geeft ook in tegenstelling tot een LLM altijd hetzelfde antwoord op een ingevoerde prompt.

De beste aanpak is om deze deterministische guardrails op drie niveaus in de software delivery-keten toe te passen, namelijk in de ontwikkelingsfase, in de continuous integration-fase vóór de integratie daadwerkelijk plaatsvindt en in de continuous deployment-fase. Die laatste controles vinden plaats voor de livegang en in de runtime zodat detectie ook achteraf kan plaatsvinden. Het geheel moet functioneren als een feedbackloop.

Softwarekwaliteit raakt bedrijfsdoelen

Heijstek waarschuwt dat softwarekwaliteit niet alleen een IT-aangelegenheid is. Softwarekwaliteit raakt direct aan de bedrijfsdoelen. “Performance is gewoon je klantervaring, resilience voorkomt dat de systemen onverwacht down gaan en het bedrijfsbelang van security merk je als de organisatie plotseling in de krant staat en je losgeld moet betalen voor geblokkeerde systemen of gestolen data. Beslissingen over risicoanalyse horen daarom bij senior management, maar belanden vaak bij ontwikkelaars vanwege tijdsdruk. Hij ziet bovendien het dilemma ontstaan dat senior ontwikkelaars nog wel in staat zijn goede kwaliteitscontroles te doen. Junior ontwikkelaars komen echter niet meer in aanraking met het zelf schrijven van software, als AI echter op grote schaal wordt ingezet. Zij missen daardoor de kritische blik op wat de AI-tools opleveren.

Verantwoord AI-gebruik bij softwareontwikkeling bestaat dus uit het vinden van een sweet spot tussen het nalopen van een hype en een verbod op het toepassen van AI. “Bedrijven die gaan voor 100 procent productiviteitswinst overdrijven of krijgen te maken met kwaliteitsproblemen. Door het gebruik van AI te verbieden laten organisaties waarde liggen. Ik durf geen exact percentage te noemen, maar met 15 tot 20 procent productiviteitswinst heb je al een heel goede verbetering in softwareontwikkeling, maar een die realistisch is én waardevol, mits je de kwaliteit waarborgt met guardrails.”