AI maakt softwareontwikkeling sneller, maar ook risicovoller. Gemiddeld is AI-gegenereerde code 30% slechter van kwaliteit dan code die door mensen is geschreven. Dat betekent onder andere dat technische schuld zich razendsnel op kan stapelen. We namen een podcast op met Luc Brandts, CEO van Software Improvement Group (SIG), waarin we ingaan op hoe organisaties grip kunnen houden op hun softwarekwaliteit in het AI-tijdperk.
Software Improvement Group (SIG) bestaat 26 jaar en heeft inmiddels meer dan 500 miljard regels code geanalyseerd, verspreid over allerlei sectoren en technologieën, van COBOL tot de nieuwste AI-modellen, van low-code platforms tot Python en Fortran. Die omvangrijke dataset maakt het mogelijk om softwarekwaliteit objectief te benchmarken en te vergelijken, ongeacht de onderliggende technologie.
Organisaties gebruiken het aanbod van SIG onder andere voor Technical Debt Management. Dat is een belangrijk onderdeel van wat het bedrijf doet: organisaties helpen toekomstige problemen te voorkomen door nu inzicht te geven in de kwaliteit van hun software. SIG hanteert daarvoor een vijfsterrenrating die over alle technologieën en programmeertalen heen vergelijkbaar is.
Van spaghetti-code naar onderhoudbare software in vijf sterren
Intuïtief begrijpt iedereen dat er verschillen zijn in de kwaliteit van de code van verschillende stukken software. SIG heeft dat inzicht gekwantificeerd door middel van een sterrenscore. Zo vertaalt het verschil tussen twee sterren en vier sterren zich naar een ontwikkelsnelheid die 3,5 tot 4 keer hoger ligt. Met andere woorden: teams die op vier sterren coderen, leveren tegen vier keer lagere kosten dezelfde functionaliteit als teams op twee sterren. Het marktgemiddelde ligt op drie sterren.
SIG adviseert organisaties standaard om vier sterren als basis te nemen. Vijf sterren is in de meeste gevallen “gold plating“, in de woorden van Brandts, en kost meer dan het oplevert. Lager dan drie sterren levert problemen op voor organisaties, in de vorm van hogere onderhoudskosten, tragere ontwikkeling en groter risico op storingen. Het is belangrijk om realistisch te zijn, horen we van Brandts. Een COBOL-systeem naar vijf sterren brengen is volgens hem vrijwel onmogelijk.
De meetlat van vijf sterren is een absolute. Dat wil zeggen, alle code wordt aan dezelfde standaard gemeten. Dat maakt het ook mogelijk om inzichtelijk te maken wat er gebeurt als je COBOL één op één migreert naar een moderne taal: de kwaliteit verbetert nauwelijks, omdat dezelfde structurele problemen worden gekopieerd. De enige oplossing in zo’n geval is een de onderliggende architectuur opnieuw bouwen.
AI-gegenereerde code is gemiddeld 30% slechter
SIG gaat (en moet) uiteraard ook mee met de tijd en heeft gekeken wat het kan bieden rondom AI-gegenereerde code. Het ontwikkelen van code is immers een van de meest voor de hand liggende (en verst doorontwikkelde) use cases voor de inzet van AI.
SIG heeft onder andere iets ontwikkeld waarmee het mogelijk is om te detecteren of code door AI of door mensen is geschreven. Die detectie is om twee redenen waardevol, geeft Brandts aan. Ten eerste helpt het organisaties te meten of hun investering in AI-licenties daadwerkelijk productiviteitswinst oplevert. Ten tweede maakt het een directe kwaliteitsvergelijking mogelijk.
De conclusie vanuit SIG is duidelijk. AI-gegenereerde code scoort gemiddeld 30% slechter dan menselijk geschreven code. Het grootste probleem is wat Brandts architectural drift noemt. AI legt connecties tussen componenten die een architect nooit zou toestaan, vergelijkbaar met hoe softwaresystemen na tientallen jaren organische groei verstrikt raken in hun eigen complexiteit. Het verschil is dat AI die drift in dagen of weken creëert in plaats van decennia.
Let wel, bovenstaand inzicht betekent niet dat AI-code altijd slecht is. Er bestaan AI-gegenereerde codebases die uitstekend scoren. Gemiddeld genomen is de kwaliteit echter structureel lager. Dat vraagt om goede guardrails en governance rondom het gebruik van AI in softwareontwikkeling.
Analyse van Cursor FastRender
Om het standpunt rondom AI-gegenereerde code duidelijker te maken, heeft SIG een analyse gedaan van Cursor’s Fast Render-project. Cursor liet 2.000 AI-agents in één week een volledige browser bouwen. Het resultaat was drie miljoen regels code die bijna werkten. SIG analyseerde die code en berekende dat een menselijk team er 118 mensjaren over gedaan zou hebben.
Dat klinkt allemaal heel erg indrukwekkend, tot we van Brandts de kwaliteitsscore horen: 1,1 ster. Dat is feitelijk het laagst mogelijke op de schaal. Functioneel werken en een goede architectuur zijn twee fundamenteel verschillende dingen. De code zou in een commerciële context zo’n tien miljoen dollar hebben gekost om te genereren. Vervolgens opnieuw genereren om de kwaliteit te verbeteren kost nog eens tien miljoen dollar. Dit terwijl het resultaat waarschijnlijk vergelijkbaar is. De context van drie miljoen regels code is te groot om volwaardig te kunnen leren van eerdere iteraties.
Volgens Brandts versterkt een lage kwaliteit zichzelf ook als het gaat om code, zeker als AI ermee aan de slag gaat. Dat wil zeggen, naarmate de kwaliteit van code verslechtert, presteert ook AI zelf slechter bij het verder ontwikkelen ervan. Hij komt hier wederom terug op het punt dat vroege architecturele sturing noodzakelijk is
Harness engineering
De oplossing ligt niet in het vermijden van AI. Sterker nog, Brandts is een groot voorstander van het gebruik van AI om code te genereren. Het gebruik ervan moet echter wel goed gestructureerd worden. Brandts waarschuwt expliciet voor het laten samenwerken van uitsluitend AI-agents zonder menselijke of deterministische tussenkomst. AI-agents die alleen met elkaar communiceren, neigen ertoe het met elkaar eens te zijn. Dat leidt tot hallucinaties, architecturele blinde vlekken en onnodige tokenkosten.
Volgens Brandts moeten organisaties aan de slag met harness engineering: het inrichten van een stevige structuur rondom AI-agents, vergelijkbaar met de rol van een architect of projectleider in een menselijk team. Deterministisch toetsen, zoals het raadplegen van een database over kwetsbare libraries, moet de voorkeur krijgen boven het inzetten van dure AI-agents voor taken die ook eenvoudiger opgelost kunnen worden.
SIG’s platform Sigrid integreert in de ontwikkelomgeving (IDE) en reageert identiek op vragen van menselijke ontwikkelaars en AI-agents. Het controleert continu op architectural drift, kwetsbaarheden en andere kwaliteitsproblemen. Dit doet het zowel in de planningsfase als tijdens het bouwen.
Niet alles op vier sterren
Een van de praktische inzichten uit het gesprek is dat het opleggen van uniforme kwaliteitsnormen aan alle systemen onverstandig is. Een systeem dat al twintig jaar stabiel draait en nauwelijks meer wordt doorontwikkeld, hoeft niet naar vier sterren. De interne kwaliteit is misschien laag, maar als er weinig aan wordt gedaan, is de impact beperkt.
Organisaties moeten differentiëren op basis van type systeem: draagt het bij aan concurrentievoordeel? Bevat het gevoelige data? Wordt het actief doorontwikkeld? Op basis van die vragen bepaal je welke kwaliteitsnorm passend is. Security-eisen kunnen daarbij afwijken van eisen rondom onderhoudbaarheid, afhankelijk van de aard van het systeem.
De boodschap waarmee het gesprek begint en eindigt is helder: het grootste risico van AI is het niet gebruiken ervan. Maar wie AI inzet zonder de juiste structuur, bouwt vandaag de legacy van morgen.
Lees ook: AI-code wordt intern omarmd, maar het beheer blijft ver achter