AI en de toekomst van systeemprogrammering

Gepubliceerd op: 18 maart 2025

Expert:

Ir. Kris van Rens

Trainer

Lees meer over Kris van Rens

Deel

---

Kris van Rens kijkt naar de toekomst van systeemontwikkeling en hoe het geluk van ontwikkelaars een belangrijk aspect is van software engineering

Kunstmatige intelligentie in het algemeen en grote taalmodellen (LLM’s) in het bijzonder veranderen ontegenzeggelijk de manier waarop we werken en code schrijven. Vooral voor het leren, uitleggen, refactoren, documenteren en reviewen van code blijken ze erg nuttig te zijn.

Voor mij is het genereren van productiecode door een LLM in chatstijl echter nog steeds een twijfelgeval. De zorgvuldig ontworpen prompt voor een complexe, beperkte taak is vaak vele malen groter dan de resulterende code, waardoor ik de productiviteitswinst in twijfel trek. Soms betrap ik mezelf erop dat ik de prompt iteratief moet bevechten om de juiste code voor mij te genereren, om er vervolgens achter te komen dat de prompt terloops is vergeten om een van mijn eerdere vereisten te implementeren. Soms ook genereren de LLM’s code met ongeldige constructies: ze hallucineren antwoorden, steevast met veel zelfvertrouwen. Sterker nog, gezien de manier waarop LLM’s werken, kunnen de antwoorden compleet anders zijn elke keer dat je een soortgelijke vraag invoert of in ieder geval sterk afhankelijk zijn van de gegeven prompt.

OpenAI medeoprichter Andrej Karpathy verwoordde het goed: “In zekere zin is hallucinatie alles wat LLM’s doen. Het zijn droommachines.” Dit schijnbaar ‘zwarte magie’ gedrag van LLM’s is enigszins onverenigbaar met mijn innerlijke tech-gedreven drang om een deterministisch proces te volgen. Misschien komt het door mijn volslagen incompetentie in prompt engineering, maar van waar ik sta, ondanks de kracht van generatieve AI binnen handbereik, moeten we nog steeds absoluut begrijpen wat we doen in plaats van blindelings te vertrouwen op de juistheid van de code die door deze droommachines is gegenereerd. Het vreemde gevoel en de eigenaardigheid van LLM’s zullen in de toekomst waarschijnlijk slijten, maar ik wil nog steeds graag de code begrijpen die ik produceer en waar ik verantwoordelijk voor ben.

Waarschijnlijk zal AI in het algemeen een abstractieverschuiving mogelijk maken in toekomstige softwareontwikkeling, waardoor we op een hoger abstractieniveau kunnen ontwerpen dan we nu vaak doen. Dit zou op zijn beurt de noodzaak om handmatig code te schrijven kunnen verminderen. Toch zie ik niet in hoe het gebruik van gegenereerde code in productie goed zal werken zonder de correctheidsgaranties van rigoureus testen en formele verificatie – dit is niet de realiteit van vandaag.

Positief verschil

Een ander toepassingsgebied van LLM’s is in-line code voltooiing in een editor/IDE. Zelfs dit is voor mij geen onverdeeld succes. Meer dan eens ben ik overweldigd door de LLM-gebaseerde code completer die een multiline oplossing voorstelt van wat hij denkt dat ik wilde typen. In plaats van het code-idee direct uit mijn verbeelding te implementeren, lees ik een klodder gegenereerde suggestiecode en vraag ik me af wat het doet en waarom. Het is raak en mis met deze aanvullingen en ze zetten me vaak op het verkeerde been. Ik heb de laatste tijd geëxperimenteerd met ingebedde ontwikkeling voor microcontrollers en ik heb gemerkt dat vooral met code in deze context, de LLM-gebaseerde aanvulling gewoon gissingen doet, soms zelfs onbestaande GPIO (general-purpose IO) pinnummers verzint. Ik hou wel van de combinatie van code completion LLM’s met een AI-model dat editorbewegingen voorspelt voor refactoring. Refactoren zijn vaak reeksen van vergelijkbare kleine bewerkingen die de modellen goed kunnen voorspellen.

Een aspect van software-engineering waar LLM’s een algemeen positief verschil kunnen maken, is het interpreteren van compilerfeedback. C++ is bijvoorbeeld berucht om zijn moeilijk te lezen en vaak erg lange compilerfouten. De komst van concepten in C++20 zou hier voor een drastische verbetering moeten zorgen, maar ik heb het niet zien gebeuren. Misschien is dit nog werk in uitvoering, maar tot die tijd moeten we het doen met complexe en vaak lange foutmeldingen (soms zelfs honderden regels lang). Vanwege hun vermogen om compilerberichten te interpreteren of samen te vatten, gecombineerd met hun educatieve en generatieve functies, zijn LLM’s met een groot contextvenster geschikt om dergelijke feedback te verwerken, waardoor ze een geweldig hulpmiddel zijn voor C++ ontwikkelaars. Er is een enorme hoeveelheid reeds bestaande C++ code en documentatie om van te leren, wat een goede basis vormt voor het trainen van een LLM.

Andere nadelen van C++ zijn de steeds toenemende complexiteit van de taal en de neiging van de compiler om te vechten in plaats van te helpen. Effectief gebruik van LLM’s om deze problemen te bestrijden zou de taal op korte termijn kunnen redden. De evolutie van de C++-taal gaat langzaam, maar het potentieel van de tools is enorm. Gezien de enorme hoeveelheid bestaande C++ code die vandaag de dag in gebruik is, is de taal een blijvertje en elk hulpmiddel dat ontwikkelaars helpt ermee te werken wordt gewaardeerd.

Ontwikkelaarsgeluk

Het gebruik van LLM’s voor het genereren van code neemt voor mij ook een deel van het plezier in programmeren weg. Voor mij is het schrijven van code een zeer creatieve, leerzame en plezierige bezigheid, waarbij ik al doende mijn vaardigheden aanscherp; door een magische doos het werk voor mij te laten doen, gaat deze ervaring tot op zekere hoogte verloren – zelfs het handmatig schrijven van de saaie stukken en de tests heeft enige leerzame waarde.

Collega-ontwikkelaar Ger Cloudt beweert in zijn werk over softwarekwaliteit dat organisatorische kwaliteit, waarvan ontwikkelaarsgeluk een onderdeel is, het halve verhaal is. Volgens hem is organisatorische kwaliteit de sleutel tot ontwerp-, code- en productkwaliteit. Natuurlijk, schone code en architectuur zijn belangrijk, maar zonder de juiste hulpmiddelen, mentaliteit, cultuur, opleiding enzovoort, zal het ontwikkelingsproces uiteindelijk tot stilstand komen.

LLM’s helpen ongetwijfeld op het gebied van tools en opleiding, maar er komt meer kijken bij programmeren dan alleen code produceren als een robot. Een deel van het ambacht van software engineering – zoals bij elk ambacht – is het ervaren van plezier en trots in je werk en de resultaten die je produceert. Ik vind het maar raar, maar het geeft me enorm veel voldoening om met mijn eigen handen mooie code te maken.