Afgelopen juli schreef ik een artikel over software-engineering die mogelijk wordt beïnvloed door de toenemende integratie van op LLM gebaseerde code-assistenttools. Helaas voor mij schreef ik dat artikel onmiddellijk na de eerste grote, functioneel geavanceerde release van Claude Code. Hoewel Claude Code technisch al in februari 2024 bestond, duurde het tot mei 2025 voordat het werd uitgebreid om het soort verfijning in code-ondersteuning te bieden dat het en enkele van de andere code-assistenttools bezitten. Daarom hielden mijn gedachten in dat artikel echt geen rekening met enkele van de veranderingen die we sindsdien hebben gezien.
Nu ga ik opnieuw kijken naar de stand van zaken bij het gebruik van op LLM gebaseerde codetools en kijken waar we staan. Ik wil vooral nadenken over de implicaties van deze technologie voor de manier waarop we ons werk doen, zowel nu als in de toekomst.
1. Functionaliteit
Wat is die verfijning waar ik het over heb? Welnu, ik heb in mijn eigen werk een aantal verschillende codeassistentoplossingen (Github Copilot, Claude Code) gebruikt, en ik heb software-ingenieurs geraadpleegd die ook andere hebben uitgeprobeerd (Cursor, Replit, enz.). Ze hebben verschillende vaardigheidsniveaus, maar enkele van de belangrijkste elementen zijn:
- toegang hebben tot alle bestanden in uw project, ze kunnen doorzoeken en hun inhoud samen kunnen analyseren
- in staat zijn om aanzienlijke stukken code of hele bestanden in uw project te schrijven
- het gebruik van ‘redenerende’ LLM’s die taken in stukjes opsplitsen en deze individueel verwerken, terwijl de verwerking van die stukjes aan de gebruiker wordt verteld
- agenttools, waarbij de modellen onafhankelijk een beroep kunnen doen op verschillende software om taken uit te voeren die de LLM niet goed kan uitvoeren (inclusief zoeken op internet)
Niets van dit alles vereist een verandering in de manier waarop we de LLM als een entiteit en zijn structuur begrijpen, maar we voegen dingen toe aan de basis-LLM die een aantal van zijn mogelijkheden uitbreiden. De ‘redenerende’ LLM’s omvatten eigenlijk alleen maar verschillende strategieën voor het aanzetten tot, en het mogelijk maken van meerdere threads van LLM-werk om te worden gedaan en gecombineerd. Hoewel de LLM nog steeds dezelfde bouwsteen is, combineren we ze op verschillende manieren en maken we verschillende praktische toepassingen mogelijk, zodat ze nu nuttiger en effectiever zijn bij de specifieke taak van het schrijven van code.
Dit is niet bedoeld om de nadelen van deze tools, of van LLM’s in het algemeen, te verminderen. Ik heb gesproken over talloze manieren waarop LLM-technologie ernstige negatieve externe effecten heeft. Maar ik denk niet dat we in de beperkte ruimte van software-engineering kunnen zeggen dat deze technologie niet werkt. Het is duidelijk niet perfect – ik raak nog steeds erg gefrustreerd als ik code schrijf en een vraag stel aan een code-assistent en dat verpest de hele zaak – maar de technologie die we vandaag de dag hebben, kan een nuttige functie vervullen.
2. Hoe mensen reageren
Terwijl ik met vrienden in de machine learning- en software-engineeringwereld over deze stand van zaken praat, hoor ik een paar verschillende perspectieven. Sommige mensen adopteren enthousiast AI-codeassistenten op alle mogelijke manieren. Ze geven het hulpprogramma een prompt en laten het de code schrijven, en komen later terug om het te beoordelen, of laten het hulpprogramma de beoordeling zelf doen. Ze zullen meerdere LLM’s opzetten om samen te werken aan problemen, elkaars werk te beoordelen en grote hoeveelheden code te produceren terwijl mensen slapen. Dit is een vorm van wat lezers wellicht kennen als ‘vibe-codering’. Voor deze mensen is het feit dat ze niet zelf code hoeven te schrijven een puur goed, en ze zijn blij met de productiviteitsstijgingen die ze kunnen bereiken. Voor hen was het schrijven van code altijd vooral een middel om een doel te bereiken, en ze vinden het niet erg om dat werk achterwege te laten. Ze produceren nieuwe software met nooit eerder verwachte snelheden, en over het algemeen voldoet deze aan hun behoeften.
Aan de andere kant zijn er mensen die ik beschouw als ‘ambachtsmensen’. Dit zijn ontwikkelaars en ingenieurs die liefde hebben voor het nadenken over code en het schrijven van code, en die net zoveel genieten van de reis als van de bestemming, zo niet meer. Voor deze mensen is de komst van AI-codeassistenten zeer verontrustend. Wanneer u van uw werk geniet omdat het bedachtzaamheid, creativiteit en veerkracht vereist, en u plezier beleeft aan het harde werk, is het alarmerend om geconfronteerd te worden met een nieuw paradigma dat suggereert dat geen van deze vaardigheden van uw kant noodzakelijk of wenselijk zijn. Enkele van de meest getalenteerde en bekwame software-ingenieurs die ik ken, hebben erover gesproken dat ze het hele beroep wilden verlaten in plaats van in hun dagelijkse werk in een vibe-coding-paradigma te worden geduwd, waarbij het vragen om en het lezen van codebeoordelingen het grootste deel van hun verantwoordelijkheden vormt.
Het nieuwste stuk van Vicki Boykis gaat hier bedachtzaam op in. Haar advies voor degenen onder ons die zich depressief voelen over de richting van ons vakgebied is om onze inspanningen te verdubbelen om manieren te vinden om de kriebel van het willen creatief zijn en betekenis te willen geven aan ons werk te ondervangen. Ik waardeer de waarde die ze aan deze vaardigheden en gevoelens hecht, maar het suggereert wel dat zelfs zij niet ziet dat de eigenlijke baan het kernkarakter behoudt waaraan we gewend zijn geraakt.
Deze theorie is natuurlijk een spectrum, bevolkt door mensen die misschien wel een beetje coderen leuk vinden, maar het grootste deel van dat werk prima uit handen kunnen geven, of mensen die heel graag coderen, maar erkennen dat de druk van het bedrijfsleven vereist dat ze hun processen aanpassen om meer AI op te nemen. Waar je ook terechtkomt, velen, zo niet de meesten van ons, maken zich zorgen over de manier waarop deze verschuiving onze carrières en werkgelegenheidsvooruitzichten zal beïnvloeden, evenals de toestand van het software-engineeringveld als geheel.
De verleiding
Maar wat ervaren we eigenlijk? Hoe is het om voor je toetsenbord te gaan zitten en je IDE op te starten in dit nieuwe tijdperk? Er is iets vreemds verleidelijks aan het hebben van een klein hulpmiddel aan de zijkant van je scherm dat precies een taak voor je kan uitvoeren.
U weet dat de assistent waarschijnlijk de volgende functie kan schrijven die u aan uw code moet toevoegen. Zelfs als je het zelf nog niet hebt gebruikt, heb je je collega’s enthousiast horen zijn over de mogelijkheden ervan. En wat is eigenlijk het nadeel? Waarom ga je niet gewoon voor de code-assistent en laat je hem een kleine taak uitvoeren?
U maakt zich misschien zorgen over de baanzekerheid: zult u verouderd raken als dergelijke hulpmiddelen hun mogelijkheden vergroten of als we effectievere manieren vinden om ze te gebruiken? Zul je de vaardigheden verliezen die je in de loop van je carrière hebt verdiend, als je ze niet meer dagelijks gebruikt en de AI taken laat uitvoeren? Niemand kan je vertellen of dit echte zorgen zijn, omdat we gewoon nog niet zeker weten hoe de werkplek voor software-ingenieurs zich op de langere termijn zal ontwikkelen.
Mogelijk bent u zich ook bewust van de bredere implicaties van generatieve AI. Je zegt impliciet: “Dit werk dat ik moet doen is de negatieve kosten van deze technologie waard.” Door ervoor te kiezen om op de chatknop van de codeassistent te klikken, besluit u dat uw gebruiksscenario de elektriciteit waard is. Dit is het waterverbruik waard. Dit is de moeite waard om een industrie en de technologie te ondersteunen en te stimuleren die op andere gebieden verantwoordelijk is voor aanzienlijke sociale, politieke en culturele negatieve gevolgen. Je zegt: “Ik denk dat het voor mij allemaal de moeite waard is om een tool te krijgen waarmee ik de code kan schrijven die ik nodig heb om dit project te voltooien.”
Maar zelfs als deze afwegingen onder uw aandacht worden gebracht, is het nog steeds moeilijk. Je zit daar naar je code te kijken en een deel van jou zegt: “Ik zou dit gewoon kunnen doen. Ik zou dit onderdeel van deze code kunnen schrijven. Ik weet hoe ik deze functie moet schrijven.” Maar je hebt een klein bugje, een beetje jeuk in de vorm van een chatvenster aan de zijkant van het scherm of een terminalcommando dat wacht. “Het kost me drie uur om deze les te schrijven, het werkend te krijgen en de tests te schrijven. Maar man, ik kan gewoon op die knop drukken. Die knop zit precies daar. Druk op die knop, en dit is binnen een paar minuten klaar, en dan kan ik verder met het volgende. Het zou zelfs beter kunnen werken dan wat ik zou schrijven. Mijn baas zal blij zijn. Ik zou vooruitgang kunnen boeken en vooruitgang kunnen boeken, dus waarom zou ik de AI-tool niet gewoon het werk laten doen?”
Er zijn veel redenen waarom je in je hoofd rondslingert, omdat je weet wat de kosten zijn van het gebruik van deze technologie, maar die verleiding is er nog steeds. Rationaliseren begint bij – je vraagt je misschien af: “Maakt mijn enkele gebruik hiervan echt enig verschil? Ik ben tenslotte maar één gebruiker.” Dit is natuurlijk een redelijke vraag om te stellen. Hoeveel verschil kan één prompt maken? Jouw enige opdracht is echt niet zo intensief, en anderen over de hele wereld gebruiken deze technologie veel meer voor veel minder waardevolle inspanningen.
Aan de andere kant is één opdracht waarschijnlijk nooit slechts één opdracht. Wat als u zich op een gladde helling begeeft en dit een routineonderdeel van uw werk wordt? Als uw vaardigheden afnemen, wordt u dan afhankelijker van het hulpmiddel?
Ligt dit überhaupt nog aan jou? Heeft u het gevoel dat u in de software-engineering kunt blijven werken zonder deze tools op te pakken? Het is zeer aannemelijk dat het behoud van de productiviteit en relevantie op het werk vereist dat u de codeassistent-tools blijft gebruiken. Is het uw persoonlijke verantwoordelijkheid om de stroom van AI-codetools tegen te houden, tegenover een menigte die deze technologie gretig voor elk mogelijk gebruik adopteert? Wat moet een individu doen in de afweging tussen het principieel vermijden van technologie die negatieve sociale gevolgen heeft, en het blijven kunnen voeden van zijn gezin? Voor de meesten van ons moet het materiële overleven winnen.
3. Wat nu?
Deze mentale ruimte is een moeilijke plek om vanuit te opereren. We zijn getuige van een aanzienlijke verandering in de manier waarop ons werk wordt gedaan, en ieder van ons bepaalt hoe we ons daaraan aanpassen. Voor velen is het emotioneel belastend om het veld zo dramatisch te zien veranderen en geconfronteerd te worden met de onzekerheid over wat dit voor ons en de wereld om ons heen betekent.
Hoe dachten onze voorouders in de begindagen van het computerprogrammeren dat dit vakgebied er in de toekomst uit zou zien? Hadden mensen zich, bijvoorbeeld in de jaren zestig, toen ze mainframes zo groot als een kamer gebruikten en code schreven met ponskaarten, het open source-ecosysteem van Python voor kunnen stellen? Dit is ongeveer hoe ik denk over de omvang van de verandering die mogelijk voor ons nu mogelijk is, en die kan in een snel tempo plaatsvinden.
De AI-codeassistenten lijken hier te blijven, in een of andere vorm. De grotere economische toekomst van de grote spelers in LLM’s kan precair zijn, om redenen waar ik al eerder over heb geschreven, maar dat weerhoudt ons er niet noodzakelijkerwijs van om toegang te hebben tot bepaalde soorten code-assistenttools, via open source LLM’s en tools zoals https://ampcode.com/, https://opencode.ai/ of https://www.tabbyml.com/. Als de modellen nooit beter worden dan ze nu zijn, zullen ze nog steeds functioneel bruikbaar zijn.
Onze banen gaan veranderen, omdat deze nieuwe hulpmiddelen beschikbaar zijn, en we moeten uitzoeken hoe we zullen evolueren. Ik geloof niet dat onze banen zullen verdwijnen, ze zullen alleen maar veranderen. We zullen eraan gewend raken om AI-assistenten te gebruiken bij onze codering, en het valt nog te bezien hoe de dagelijkse werkzaamheden er daardoor uit zullen zien. Zal institutionele traagheid de hoeveelheid verandering beperken die we op onze werkplekken zien? Zal er nog plaats zijn voor creativiteit en vakmanschap bij het ontwikkelen en coderen van software? Op de werkplek krijgen mensen al prestatiebeoordelingen op basis van de vraag of ze AI voldoende gebruiken om het management tevreden te stellen, dus we hebben niet veel tijd om erover na te denken.
Hoe gaan we op persoonlijk vlak grip krijgen op de ethische implicaties van onze deelname aan deze sector, en de manieren waarop deze veranderen? Niemand kan dat natuurlijk voor je beantwoorden. Sommige mensen zullen misschien stoppen en van carrière veranderen, terwijl anderen een manier zullen vinden om met het nieuwe paradigma te leven.
We bevinden ons in een specifieke situatie tussen wat de economie en de materiële omstandigheden van ons verwachten of eisen, en de ethische implicaties van die eisen. De overgrote meerderheid van ons moet onze families ondersteunen en verkeert niet in een positie om te weigeren daaraan te voldoen. Ik denk dat velen van ons te maken zullen krijgen met een cognitieve dissonantie over deze twee kanten.
Bewustwording en bewustzijn van de kosten van ons systeem zijn belangrijk, ook als ze ons ongemak bezorgen. Doen alsof de problemen met generatieve AI niet bestaan, is geen oplossing. Zoals sociale wetenschappers weten, is het eerlijk ondervragen van de dynamiek, tekortkomingen en machtsstructuren van het systeem waarin we ons bevinden een voorwaarde voor het verbeteren van dat systeem, hoe stapsgewijs ook. We kunnen de generatieve AI-geest niet terug in de fles stoppen, maar we hoeven ook niet noodzakelijkerwijs het worstcasescenario op sociaal, cultureel, milieu- en politiek gebied te accepteren. Structurele verandering, en niet individuele keuze, is de enige manier om systemen betekenisvol te verbeteren, en als we geïnformeerd zijn over de ethische problemen kunnen we deelnemen aan systemische pogingen tot verbetering.
Lees meer van mijn werk op www.stephaniekirmer.com. Ik spreek eind april 2026 ook bij ODSC East over het onderwerp evaluatiestrategieën voor LLM-ontwikkeling.
