Maand: februari 2025

ASML engineer Buket Şahin is de eerste persoon die het ECP2 Silver certificaat heeft behaald. Voor Şahin is dat slechts het neveneffect van haar passie voor leren. Ze verdiept zich graag in nieuwe vakgebieden en is daardoor een betere system engineer geworden.

Toen Buket Şahin haar bachelor werktuigbouwkunde deed in Istanbul, sloot ze zich aan bij de zonnewagen- en formule SAE-teams van haar universiteit. Een beslissing die haar al snel de beperkingen van haar kennis deed inzien. Het zette haar op een levenslang spoor om meer te leren over andere vakgebieden dan haar eigen vakgebied.

“Toen is het allemaal begonnen”, herinnert Şahin zich. “Ik zag hoe noodzakelijk het was om andere disciplines te leren kennen. Uiteraard kende ik het mechanische domein goed, maar opeens moest ik samenwerken met bijvoorbeeld elektrotechnici. Ik begreep niet waar ze het over hadden, en dat wilde ik wel.”

Şahin studeerde uiteindelijk af met een bachelor in werktuigbouwkunde en een master in mechatronica, naast een MBA. Ze werkte eerst als systeemingenieur in de Turkse defensie-industrie, voordat ze in 2012 de overstap maakte naar ASML. Ze begon met werken in development & engineering op de NXT en NXE platforms. Momenteel werkt ze als product safety system engineer voor de EUV machines van ASML.

Tijdens die reis zocht ze hardnekkig naar nieuwe kennis en volgde ze een groot aantal cursussen op het gebied van elektronica, optica en mechatronica. Eind 2024 werd zij de persoon die het eerste ECP2 Silver certificaat behaalde. ECP2 is het Europees gecertificeerde cursusprogramma voor precisietechniek dat is voortgekomen uit een samenwerking tussen euspen en DSPE. Om het certificaat te behalen moest ze 35 punten aan ECP2-gecertificeerde cursussen volgen.

“Mijn doel was niet om deze certificering te behalen”, lacht ze. “Maar uiteindelijk bleek ik de eerste te zijn die het haalde.”

Helikopter uitzicht

In haar functie bij ASML combineert Şahin system engineering met een visie op veiligheid. “Wij zijn vanuit veiligheidsoogpunt verantwoordelijk voor de hele EUV-machine”, merkt ze op. “Dit omvat interne en externe afstemming, het overzien van het programma en het managen van ingenieurs en architecten.”

Het team waarin ze werkt bestaat uit honderden mensen, waaronder een kernteam van ongeveer vijftien system engineers. Een daarvan is een veiligheidsspecifieke systeemingenieur, zoals zij doet.

Ze houdt van dat bredere systeemperspectief, dat verschillende vakgebieden combineert. Het stelt haar in staat om de verschillende dingen die ze tijdens haar carrière heeft geleerd in de praktijk te brengen. “Ik heb brede interesses”, zegt Şahin. “Ik hou van allerlei deelgebieden van wetenschap en techniek. Bij systems engineering kan ik die nieuwsgierigheid volgen. Dat is ook de reden waarom ik zo graag leer en cursussen volg. Als systeemingenieur moet je een complex systeem en de technische achtergrond van de onderdelen kennen. Je moet dieper in het ontwerp kunnen duiken. Je moet in de verschillende disciplines kunnen duiken, maar tegelijkertijd een helikopterview behouden. Dat evenwicht bewaren is iets wat ik erg leuk vind.”

Buket Şahin in het ervaringscentrum van ASML.

NASA handboek

Şahin begon cursussen te volgen zodra ze bij ASML aan de slag ging. Ze realiseerde zich dat ze haar kennis verder moest uitbreiden dan wat haar diploma’s haar hadden geleerd. “Ze waren erg theoretisch”, geeft ze toe. “Ze waren niet erg toegepast. De onderzoeks- en ontwikkelingsindustrie in Turkije is niet zo volwassen als in Nederland, vooral niet voor halfgeleiders. In Nederland is er een heel goede interactie tussen universiteiten en de industrie. Ik wilde die praktische kennis opdoen. Dus begon ik met cursussen in mechatronica en elektronica. Daarna wilde ik meer leren over optica, een zeer relevant vakgebied als je bij ASML werkt. Van daaruit ben ik gewoon verder gegaan.”

Nieuwsgierigheid is een drijvende kracht voor Şahin. “Sommige cursussen heb ik gevolgd omdat ik de kennis nodig had voor mijn werk, maar andere waren uit nieuwsgierigheid. Ik wilde mezelf ontwikkelen en nieuwe dingen leren. De cursussen stelden me daartoe in staat.”

Interessant genoeg volgde ze echter geen cursussen over systeemtechniek. “Ik was vooral op zoek naar verdieping in verschillende technische disciplines”, blikt ze terug. “Mijn eerste baan was als system engineer, maar de manier waarop de rol in verschillende bedrijven wordt gedefinieerd verschilt sterk. Systeemingenieurs in de halfgeleiderindustrie vereisen kennis van de verschillende deelgebieden van de industrie. Een ASML machine is ook erg complex, dus je moet echt bijhouden wat je weet. Dingen kunnen snel veranderen en je moet up-to-date blijven. Daarom is leren zo’n belangrijk onderdeel van mijn carrière.”

Ze heeft wel geleerd hoe ze een system engineer moest zijn binnen ASML, zowel door on-the-job te leren, als door interne cursussen te volgen. “Er zijn interne ASML system engineering trainingen”, zegt Şahin. “Daarom had ik geen externe cursussen nodig. Ook heb ik het vak geleerd uit het NASA System Engineer Handbook in Turkije. Dat is ook de methodologie die ASML gebruikt.”

Praktische kennis

Als Şahin terugkijkt op alle cursussen die ze volgde sinds ze naar Nederland verhuisde, zijn het vooral de praktische cursussen die eruit springen. “Het belangrijkste wat ik heb geleerd was toegepaste kennis”, zegt ze. “Door naar de universiteit te gaan leerde ik de theorie, maar het zijn de dagelijkse inzichten die belangrijk zijn. Ik vind het vooral leuk als cursussen je vuistregels, pragmatische benaderingen en voorbeelden uit de branche zelf leren. Dat is de belangrijkste kennis voor mij. Het helpt vooral als de docenten uit de industrie komen, zodat ze ons kunnen laten zien waar ze zelf aan gewerkt hebben.”

Sinds 2012 is het leren ook gemakkelijker geworden. “Toen ik begon waren er niet zoveel leerstructuren om je te begeleiden. Het huidige High Tech Institute heeft bijvoorbeeld een gemakkelijk toegankelijke cursuslijst. In 2012 moest ik echter veel meer onderzoek doen, en er werd niet zoveel geadverteerd voor cursussen en ze waren zelfs alleen in het Nederlands. Ik moest collega’s vragen en het zelf uitzoeken. Als ik vandaag had moeten beginnen, was het veel gemakkelijker geweest.”

“Als het je helpt om je doel te bereiken, is het heel gemakkelijk om cursussen te volgen als je bij ASML werkt”, zegt Şahin.

Bij ASML zijn ze blij met de nieuwe certificering van Şahin en de honger die ze toont om nieuwe dingen te leren. “Mijn managers hebben me altijd gesteund”, zegt Şahin. “We definiëren ontwikkelingsdoelen en selecteren de training waarmee we die doelen kunnen bereiken. Als het je helpt om je doel te bereiken, is het heel gemakkelijk om cursussen te volgen als je bij ASML werkt.”

Şahin is voorlopig nog lang niet klaar. Voor haar houdt het leren nooit op. “Ik ben net begonnen met een masteropleiding aan de KU Leuven. Het is een geavanceerde master in veiligheidstechniek, en het is verbonden aan mijn functie bij ASML. Mijn doel op korte termijn is om deze master af te ronden. Daarna wil ik mijn carrière hier bij ASML voortzetten als system engineer. Leren is voor mij echter een doel op zich, of het nu met mijn baan te maken heeft of niet.”

Dit artikel is geschreven door Tom Cassauwers, freelancer bij Bits&Chips.

 

Beginnend met ponskaarten in het begin van de jaren 1980, leerde Ger Cloudt waardevolle lessen over het ontwikkelen van goede software. De nieuwe trainer van het High Tech Institute deelt zijn inzichten over de wisselwerking tussen processen en vaardigheden, over het meten van softwarekwaliteit en over het stimuleren van een organisatiecultuur waarin engineers software van hoge kwaliteit kunnen leveren.

Ger Cloudt kwam voor het eerst in aanraking met programmeren door het gebruik van ponskaarten tijdens zijn studie elektronica aan de Fontys Hogeschool Venlo in het begin van de jaren tachtig. Na zijn afstuderen begon hij aan een carrière als digitaal elektronicus, waarbij hij zich zowel richtte op het ontwerpen van digitale schakelingen als op het ontwikkelen van software om microprocessoren aan te sturen. “Dit was in assembler en ik herinner me dat ik echt ongestructureerde spaghetti-code maakte,” herinnert Cloudt zich. “Dit maakte het natuurlijk buitengewoon moeilijk om problemen op te lossen en bugs te repareren, waardoor ik een harde les leerde dat er een betere manier moest zijn.”

Gelukkig werd Cloudt tijdens zijn tweede opdracht gekoppeld aan een ervaren mentor die hem leerde om te beginnen met gestructureerde pseudocode en deze vervolgens om te zetten in assembler. “Dit was de eerste keer dat ik ervoer dat structuur het maken van robuuste code kan vergemakkelijken en het debuggen makkelijker kan maken.” Deze ervaring leidde er uiteindelijk toe dat hij een paar jaar later overstapte naar softwareontwikkeling.

Proces versus vaardigheid

Cloudt ging bij Philips Medical Systems werken als softwareontwikkelaar en later als softwarearchitect, waar hij leerde hoe processen en vaardigheden elkaar aanvullen. “Om acties uit te voeren, heb je een bepaald vaardigheidsniveau nodig, terwijl om resultaten te bereiken, acties gestructureerd moeten worden door een proces. Het belang van proces of vaardigheid hangt echter af van het soort taak. Aan de ene kant zijn er taken zoals lopendebandwerk of het bouwen van Ikea-meubels die je hebt gekocht, waarvoor een strikt proces nodig is, maar minimale vaardigheidseisen. Aan de andere kant zijn er taken zoals het schilderen van de Mona Lisa, zoals Leonardo da Vinci deed, die minder afhankelijk zijn van processen maar een hoog vaardigheidsniveau vereisen dat slechts weinigen bezitten.”

In deze periode zag Cloudt een sterke nadruk op processen bij softwareontwikkeling. “Dit was de periode van de opkomst van het Capability Maturity Model, gericht op het verbeteren van softwareontwikkelingsprocessen. Maar zelfs met processen blijven vaardigheden essentieel. In het streven naar hoge CMM-niveaus is het onderwaarderen van vaardigheden een reëel gevaar.” Dit inzicht werd verder versterkt toen Cloudt overstapte naar managementfuncties bij Philips Medical Systems, waar hij leiding gaf aan teams van zestig mensen. “Het bereiken van een specifiek CMM-niveau wordt al snel een doel op zich, en zoals de Wet van Goodhart zegt: als een maatregel een doel wordt, is het geen goede maatregel meer. Ik ben er steeds meer van overtuigd geraakt dat het vaardigheidsniveau belangrijker is dan processen voor software engineers. Een proces kan het toepassen van je vaardigheden vergemakkelijken, maar met ontoereikende vaardigheden zal geen enkel proces helpen.”

Cloudt leerde vervolgens over het belang van transparantie. “In mijn eerste functie als kwaliteitsmanager moest ik een probleem oplossen waarbij twee verschillende softwarestacks moesten worden geïntegreerd. Het ene team ontwikkelde NFC-software, het andere werkte aan software voor een beveiligd element. Het integreren van beide bleek een uitdaging. Toen ik er dieper op in ging, ontdekte ik dat de teams hun software weliswaar testten, maar dat testfouten niet systematisch werden gemonitord. Dus maakten we dagelijks bijgewerkte dashboards met testresultaten en bespraken de ontwikkelaars dagelijks de uitkomsten. We deelden de dashboards zelfs met de klant. Natuurlijk zag alles er aanvankelijk rood uit, maar dit diende als een sterke stimulans voor de ontwikkelaars om zich te verbeteren. En zo slaagde het project.”

Leren door te delen

In zijn rol als software R&D manager bij Bosch begon Cloudt de behoefte te voelen om zijn inzichten over softwarekwaliteit te delen. Hij begon met het delen van artikelen op het interne sociale netwerk van het bedrijf en op Linkedin. “Ik kreeg veel positieve feedback, vooral van Bosch collega’s,” zegt hij. “Dus in 2020 besloot ik een boek te schrijven: ‘Wat is softwarekwaliteit? Deze ervaring was erg verrijkend, omdat het veel van mijn impliciete kennis expliciet maakte en ook hiaten in mijn kennis blootlegde.”

In een kwaliteitscommissie bij Bosch ontmoette Cloudt een jonge afgestudeerde met een masterdiploma in kwaliteitsmanagement. Toen hij vroeg of de afgestudeerde een cursus over softwarekwaliteit had gevolgd, was het antwoord negatief. “Dit was voor mij aanleiding om het Engineering Doctorate programma van de Technische Universiteit Eindhoven te benaderen, waar ze me uitnodigden om een gastcollege te geven. Uiteindelijk werd ik docent voor een cursus kwaliteitsmanagement.” Cloudt begon ook te spreken over softwarekwaliteit op evenementen, zoals een Bits&Chips-evenement in 2021 en hij lanceert momenteel twee trainingsprogramma’s bij het High Tech Institute, een voor ingenieurs en een voor managers. Zijn huidige functie is softwarekwaliteitsmanager voor de ontwikkeling van het Digital Application Platform bij ASML.

Softwarekwaliteit meten

Softwarekwaliteit als zodanig is niet meetbaar, stelt Cloudt, vanwege de diversiteit van het concept. “Je kunt een aantal specifieke aspecten van softwarekwaliteit meten, die bekend staan als ‘gemodelleerde kwaliteit’. Deze omvatten cyclomatische complexiteit van code, afhankelijkheden, codedekking, aantal regels en open bugs. Zulke metrieken zijn nuttig, maar iedereen die er doelen op stelt moet op zijn hoede zijn voor de Wet van Goodhart.”

Een essentieel onderdeel van kwaliteit blijft onmeetbaar: transcendente kwaliteit. Om dit te illustreren vergelijkt Cloudt het met het beoordelen van een schilderij. “Je kunt de dikte van de verf en de afmetingen van het doek meten, maar je kunt de schoonheid van het schilderij niet meten. Hetzelfde geldt voor softwarekwaliteit: je kunt de codedekking van je unit tests meten, maar dat bepaalt nog niet of de tests goed zijn. Daar heb je een expert opinion voor nodig, ondersteund door de gemodelleerde kwaliteit die je meet.”

Als mensen aan softwarekwaliteit denken, noemen ze vaak aspecten als modulariteit, schone code en bruikbaarheid. Dit zijn voorbeelden van ontwerpkwaliteit (bijvoorbeeld modulariteit, onderhoudbaarheid en scheiding van zorgen), codekwaliteit (bijvoorbeeld schone code, overdraagbaarheid en unit tests) en productkwaliteit (bijvoorbeeld bruikbaarheid, veiligheid en betrouwbaarheid). Volgens Cloudt vereisen deze drie soorten kwaliteit echter een element dat vaak over het hoofd wordt gezien: organisatorische kwaliteit. “Dit type kwaliteit bepaalt of je organisatie in staat is om software van hoge kwaliteit te bouwen. Aspecten als software vakmanschap, volwassen processen, samenwerking en cultuur zijn van vitaal belang voor organisatorische kwaliteit. Onderschat cultuur nooit. Een organisatie moet een omgeving koesteren waarin software engineers kunnen gedijen en uitstekende ontwerp-, code- en productkwaliteit kunnen leveren.”

Bedoeld en geïmplementeerd ontwerp

Er zijn verschillende bekende best practices voor het ontwikkelen van software van hoge kwaliteit, waaronder testgedreven ontwikkeling (TDD) en pair programming, naast statische codeanalyse. Cloudt voegt daar iets aan toe dat minder gebruikelijk is: statische ontwerpanalyse. “Veel mensen realiseren zich niet dat er een verschil is tussen het beoogde ontwerp en het geïmplementeerde ontwerp van software. Software-architecten documenteren hun beoogde ontwerp in UML-modellen. Er is echter vaak een kloof tussen dit beoogde ontwerp en de implementatie ervan in code. Het is een best practice om dit gat klein te houden. Tools kunnen controleren op consistentie tussen je code en UML-modellen en waarschuwen als er discrepanties ontstaan.”

Deze kloof tussen het beoogde en het uitgevoerde ontwerp ontstaat vaak onder tijdsdruk, bijvoorbeeld vanwege deadlines van projecten. “In zulke gevallen neem je een kortere weg door een oplossing te ‘hacken’ waarmee je de deadline haalt, met minder nadruk op kwaliteit,” legt Cloudt uit. “Dit is een bewuste keuze om technische schuld te introduceren vanwege tijdsdruk. Hoewel dit misschien de enige directe oplossing is, is het cruciaal om deze technische schuld later aan te pakken. Nadat de release is opgeleverd, moet je tijd vrijmaken om een goede oplossing van hoge kwaliteit te ontwikkelen. Helaas gebeurt dit niet vaak. Managers moeten de noodzaak inzien om ontwikkelaars de tijd te geven om dit gat en deze technische schuld te verkleinen om toekomstige problemen te voorkomen. Door hun beslissingen dragen managers in belangrijke mate bij aan de kwaliteit van de organisatie en hebben ze een directe invloed op de kwaliteit van software.”

Dit artikel is geschreven door Koen Vervloesem, freelancer voor Bits&Chips.

Nu AI-technologieën worden ingebed in softwareontwikkelingsprocessen vanwege hun productiviteitswinst, worden ontwikkelaars geconfronteerd met complexe beveiligingsuitdagingen. Ga mee met Balázs Kiss en verken de essentiële beveiligingspraktijken en herinneringstechnieken die nodig zijn om AI verantwoord en effectief te gebruiken.

Het gebruik van kunstmatige intelligentie (AI) bij de ontwikkeling van software is de afgelopen jaren toegenomen. Zoals met elke technologische vooruitgang, brengt dit ook implicaties voor de beveiliging met zich mee. Balázs Kiss, product development lead bij de Hongaarse aanbieder van opleidingen Cydrill Software Security, had de beveiliging van machine learning al onder de loep genomen vóór de wijdverspreide aandacht voor generatieve AI. “Terwijl iedereen het tegenwoordig heeft over grote taalmodellen, lag de focus in 2020 voornamelijk op machine learning, waarbij de meeste gebruikers wetenschappers op R&D-afdelingen waren.”

Toen Kiss de stand van de techniek onderzocht, ontdekte hij dat veel fundamentele concepten uit de softwarebeveiligingswereld werden genegeerd. “Aspecten zoals inputvalidatie, toegangscontrole, beveiliging van de toeleveringsketen en het voorkomen van overmatig gebruik van bronnen zijn belangrijk voor elk softwareproject, inclusief machine learning. Dus toen ik me realiseerde dat mensen zich niet aan deze praktijken hielden in hun AI-systemen, heb ik gekeken naar mogelijke aanvallen op deze systemen. Het resultaat is dat ik er niet van overtuigd ben dat machine learning veilig genoeg is om te gebruiken zonder menselijk toezicht. AI-onderzoeker Nicholas Carlini van Google Deepmind vergeleek de huidige staat van ML-beveiliging zelfs met de begindagen van cryptografie vóór Claude Shannon, zonder sterke algoritmen ondersteund door een rigoureuze wiskundige basis.”

Met de toename in populariteit van grote taalmodellen merkte Kiss dat dezelfde fundamentele beveiligingsproblemen weer opdoken. “Zelfs dezelfde namen doken op in onderzoekspapers. Carlini was bijvoorbeeld betrokken bij het ontwerpen van een aanval om automatisch jailbreaks te genereren voor elke LLM – een afspiegeling van aanvallen van tegenstanders die al een decennium worden gebruikt tegen computervisiemodellen.”

Gefabriceerde afhankelijkheden

Wanneer ontwikkelaars momenteel een LLM gebruiken om code te genereren, moeten ze onthouden dat ze in wezen een geavanceerde autoaanvulfunctie gebruiken. “De uitvoer zal lijken op code waarop het is getraind, en ziet er heel overtuigend uit. Dat is echter geen garantie voor correctheid. Wanneer een LLM bijvoorbeeld code genereert die een bibliotheek bevat, verzint het vaak een valse naam omdat het een woord is dat logisch is in die context. Cybercriminelen maken nu bibliotheken met deze fictieve namen, sluiten malware in en uploaden deze naar populaire code-repositories. Dus als je deze gegenereerde code gebruikt zonder het te verifiëren, kan je software onbedoeld malware uitvoeren.”

In de VS heeft het National Institute of Standards and Technology (NIST) zeven essentiële bouwstenen van verantwoorde AI geschetst: validiteit en betrouwbaarheid, veiligheid, beveiliging en veerkracht, controleerbaarheid en transparantie, uitlegbaarheid en interpreteerbaarheid, privacy en eerlijkheid met beperking van schadelijke vooroordelen. “De aanval met gefabriceerde bibliotheken is een voorbeeld waarbij veiligheid en veerkracht in het gedrang komen, maar de andere bouwstenen zijn net zo belangrijk voor betrouwbare en verantwoorde AI. Validiteit en betrouwbaarheid’ betekent bijvoorbeeld dat resultaten consistent correct moeten zijn: de ene keer een correct resultaat krijgen en de volgende keer dat je de LLM vraagt om dezelfde taak uit te voeren, is niet betrouwbaar.”

Wat bias betreft, dit wordt vaak begrepen in andere domeinen, zoals grote taalmodellen die stereotype veronderstellingen over beroepen van mannen en vrouwen uitdrukken. Een dataset met code kan echter ook bias vertonen, legt Kiss uit. “Als een LLM alleen is getraind op open-source code van Github, kan het bevooroordeeld zijn ten opzichte van code die dezelfde bibliotheken gebruikt als de code waarop het is getraind, of code met Engelse documentatie. Dit beïnvloedt het type code dat de LLM genereert en zijn prestaties op taken die worden uitgevoerd op code die afwijkt van wat hij heeft gezien in zijn trainingsset, waardoor hij het mogelijk slechter doet wanneer hij interfaced met een aangepaste closed-source API.”

Balasz Kiss
Credits: Egressy Orsi Foto

Effectief vragen stellen

Volgens Kiss zijn veel best practices voor het verantwoord gebruik van AI in softwareontwikkeling niet nieuw. “Valideer gebruikersinvoer in je code, controleer bibliotheken van derden die je gebruikt, controleer op kwetsbaarheden – dit is allemaal algemeen bekend in het beveiligingsdomein. Er zijn veel tools beschikbaar om te helpen bij deze taken.” Je kunt zelfs AI gebruiken om AI-gegenereerde code te verifiëren, stelt Kiss voor. “Voer de gegenereerde code terug naar het systeem en vraag het om kritiek. Zijn er problemen met deze code? Hoe zouden die opgelost kunnen worden?” De resultaten van deze aanpak kunnen heel goed zijn, stelt Kiss, en hoe preciezer je vragen zijn, hoe beter de prestaties van de LLM. “Vraag niet alleen of de gegenereerde code veilig is. Als je je bewust bent van het soort kwetsbaarheden dat je kunt verwachten, zoals cross-site scripting kwetsbaarheden in webapplicaties, specificeer deze dan in je vragen.”

Er zijn veel best practices in opkomst voor het maken van effectieve prompts, oftewel de vragen die je voorlegt aan de LLM. One-shot of few-shot prompting, waarbij je één of enkele voorbeelden van de verwachte uitvoer aan de LLM geeft, is volgens Kiss een krachtige techniek om betrouwbaardere resultaten te verkrijgen. “Als je code op dit moment bijvoorbeeld XML-bestanden verwerkt en je wilt overschakelen op JSON, dan kun je simpelweg vragen om de code te transformeren om JSON te verwerken. De gegenereerde code zal echter veel beter zijn door een voorbeeld van je gegevens in XML-formaat toe te voegen naast dezelfde gegevens in JSON-formaat en te vragen om code om gegevens in plaats daarvan in JSON te verwerken.”

Een andere nuttige promptingtechniek is chain-of-thought prompting – een LLM opdragen om zijn redeneerproces voor het verkrijgen van een antwoord te laten zien, waardoor het resultaat wordt verbeterd. Kiss heeft deze en andere promptingtechnieken, naast belangrijke valkuilen, samengebracht in een eendaagse training over verantwoorde AI in softwareontwikkeling aan het High Tech Institute. “Zo zijn unit tests die door een LLM worden gegenereerd vaak nogal repetitief en dus niet zo nuttig. Maar de juiste prompts kunnen ze verbeteren, en je kunt ook aan testgedreven ontwikkeling doen door zelf de unit tests te schrijven en de LLM te vragen de bijbehorende code te genereren. Deze methode kan heel effectief zijn.”

Hier blijven

Met al deze voorzorgsmaatregelen kun je je afvragen of de grote belofte van AI-codegeneratie, verhoogde productiviteit van ontwikkelaars, nog steeds geldt. “Een recent onderzoek op basis van gerandomiseerde gecontroleerde onderzoeken bevestigt dat het gebruik van generatieve AI de productiviteit van ontwikkelaars met 26 procent verhoogt,” merkt Kiss op, met nog grotere voordelen voor minder ervaren ontwikkelaars. Toch waarschuwt hij dat dit een valkuil kan zijn voor jonge ontwikkelaars. “Met de huidige stand van generatieve AI is het mogelijk om code te schrijven zonder verstand te hebben van programmeren. Prominent AI-onderzoeker Andrej Karpathy merkte zelfs op: ‘De populairste nieuwe programmeertaal is Engels’. Maar als je de gegenereerde code niet begrijpt, hoe wil je die dan onderhouden? Dit leidt tot technische schuld. We weten nog niet welk effect het langdurige gebruik van deze tools zal hebben op onderhoudbaarheid en robuustheid.”

Hoewel het gebruik van AI bij de ontwikkeling van software een aantal problemen met zich meebrengt, is het volgens Kiss ongetwijfeld een blijvertje. “Ook al lijkt het vandaag op een zeepbel of een hype, er zijn aantoonbare voordelen en de technologie zal breder geaccepteerd worden. Veel tools die we vandaag zien, zullen worden verbeterd en zelfs worden ingebouwd in geïntegreerde ontwikkelomgevingen. Microsoft integreert zijn Copilot al strak in zijn Visual Studio producten, en ze zijn niet de enige. Menselijk toezicht zal echter altijd nodig blijven; uiteindelijk is AI slechts een hulpmiddel, net als elk ander hulpmiddel dat ontwikkelaars gebruiken. En LLM’s hebben inherente beperkingen, zoals hun neiging om te ‘hallucineren’ – verzinsels te creëren. Zo werken ze nu eenmaal vanwege hun probabilistische aard en gebruikers moeten zich hier altijd van bewust zijn als ze ze gebruiken.”

Dit artikel is geschreven door Koen Vervloesem, freelancer voor Bits&Chips.