AI en Programmeren: Verandert de Rol van de Developer?

De afgelopen twee jaar is er in programmeerkringen nauwelijks een gesprek gevoerd zonder dat AI ter sprake kwam. GitHub Copilot heeft honderd miljoen gebruikers. Cursor groeide in korte tijd van nichetool tot serieuze concurrent van VS Code. Anthropic bracht Claude Code uit, een CLI waarmee je AI direct op je codebase loslaat. En tussendoor kwamen er tientallen tools die beloofden dat je zonder enige codeerkennis een complete applicatie kunt bouwen.

Dat zijn geen kleine ontwikkelingen. Maar er is ook veel ruis. "Developers worden overbodig" is een kop die net zo makkelijk rondgaat als "AI kan geen echte software bouwen". Beide zijn te simpel. Wat er werkelijk verandert, is iets subtieler.

De tools die er nu zijn

Het huidige landschap van AI-codeertools valt grofweg in twee categorieën uiteen: tools die werken binnen je editor, en tools die meer autonoom omgaan met een codebase als geheel.

GitHub Copilot was de vroegste grote speler en is voor veel developers de standaardinstelling geworden. Het integreert in vrijwel elke editor en vult code aan op basis van context in het huidige bestand. Het suggereert functies, schrijft boilerplate, en kent inmiddels ook een chatmodus voor het stellen van vragen over code. Copilot is goed in het afmaken van wat je bent begonnen.

Cursor gaat een stap verder door de gehele editor te herbouwen met AI als kernonderdeel. Je kunt er selecties mee bewerken via taal, vragen stellen over bestanden, en via de "Composer"-modus meerdere bestanden tegelijk laten aanpassen. Windsurf, gemaakt door Codeium, doet vergelijkbaar werk en heeft als eigen feature "Cascade": een systeem waarbij de AI niet alleen code schrijft maar ook bijhoudt wat er in de codebase verandert.

Claude Code is een andere aanpak. In plaats van in de editor te zitten, werkt het vanuit de terminal. Je geeft het een taak, het leest de relevante bestanden, schrijft code, voert commando's uit en itereert. Het begrip van een project als geheel is een van de sterkere kanten: het trekt connecties tussen bestanden, begrijpt afhankelijkheden, en lost problemen op die de grenzen van één bestand overstijgen.

Wat deze tools gemeen hebben: ze zijn allemaal gebaseerd op grote taalmodellen, en ze worden allemaal beter naarmate je ze meer context geeft over wat je wilt bereiken.

Wat ze goed kunnen

Het is niet moeilijk om mensen enthousiast te vinden over wat AI-codeertools voor hen doen. De tijdswinst is in veel gevallen aantoonbaar.

Routinewerk gaat sneller. Boilerplate schrijven, unit tests opstellen voor een bestaande functie, documentatie genereren voor een methode, een datastructuur omzetten naar een ander formaat: dit zijn taken waarbij AI consistent goed presteert. De code is niet altijd perfect, maar hij is een bruikbaar startpunt dat je verder kunt aanscherpen.

Bij bekende technologieën werkt het het best. Als je werkt met een populair framework dat goed vertegenwoordigd is in trainingsdata, zoals React, Django of Rails, is de kwaliteit van de suggesties doorgaans hoog. De AI kent de patronen, de gebruikelijke structuren, de gangbare oplossingen voor veelvoorkomende problemen.

Debuggen wordt ook anders. Vroeger kopieerde je een foutmelding naar Google, las je een Stack Overflow-thread en probeerde je de relevante stukken te vertalen naar je eigen situatie. Nu kun je de foutmelding direct aan een AI geven, met de context van de betrokken code, en krijg je een analyse die specifiek is voor jouw geval. Dat scheelt tijd.

Taalwisseling, code vertalen van Python naar TypeScript, of een algoritme in een onbekende taal begrijpen, is ook een stuk toegankelijker geworden. Je hoeft niet te wachten tot je de nieuwe taal volledig beheerst om productief te zijn.

Waar ze tegenaan lopen

De beperkingen zijn reëler dan de marketingteksten doen vermoeden.

Het grootste probleem is betrouwbaarheid op schaal. Een AI die code schrijft voor een losstaande functie doet dat vaak goed. Een AI die een nieuw systeem ontwerpt dat naadloos moet passen in een grote, complexe codebase met jaren aan beslissingen en technische schuld, maakt fouten die je niet altijd direct ziet. De code compileert, de tests slagen, maar de logica klopt niet. Of de aanpak is suboptimaal voor de context.

AI-tools hebben geen begrip van de bedoeling achter een systeem. Ze kunnen bestaande patronen herkennen en reproduceren, maar ze weten niet waarom bepaalde keuzes zijn gemaakt, wat de historische reden is achter een bepaalde architectuurbeslissing, of wat het effect is van een aanpassing op de rest van het systeem drie lagen dieper.

Veiligheid is een consistent aandachtspunt. Gegenereerde code bevat regelmatig kwetsbaarheden: SQL injection als parameterisatie niet expliciet is gevraagd, inadequate inputvalidatie, onjuiste foutafhandeling waarbij gevoelige informatie in logs belandt. Wie AI-code zonder review in productie zet, neemt risico's.

Er is ook het probleem van verouderde kennis. Taalmodellen hebben een kennisdatum. Een library die zes maanden geleden een nieuwe versie uitbracht met een andere API, wordt door de AI nog aangestuurd via de oude methoden. Die fouten zijn soms lastig te spotten als je zelf de library niet goed kent.

De verschuiving in het werk van developers

Wat er in de praktijk verandert aan het werk van een developer, is niet dat er minder kennis nodig is. Het is eerder dat de verdeling van aandacht verschuift.

Minder tijd gaat naar het typen van code die je al weet hoe ze werkt. Meer tijd gaat naar het nadenken over architectuur, het stellen van de juiste vragen, het reviewen van gegenereerde output en het bijsturen waar dat nodig is. De vergelijking die veel developers gebruiken: AI is als een zeer productieve junior die veel werk verzet, maar toezicht nodig heeft.

Dat heeft gevolgen voor hoe een werkdag eruitziet. Taken die vroeger uren kostten, zijn nu soms in twintig minuten gedaan. Maar daarna begint een andere fase: nadenken over of de aanpak klopt, of de code onderhoudbaar is, of er randgevallen zijn die niet zijn behandeld. Het totale volume aan werk dat je kunt aanpakken, neemt toe. Maar de verantwoordelijkheid voor de kwaliteit ervan neemt niet af.

Developers die goed zijn in het formuleren van problemen, het opstellen van heldere requirements en het beoordelen van technische keuzes, profiteren het meest. De developer als architect en beoordelaar, in plaats van de developer als typende producent van regels code.

Communicatieve en analytische vaardigheden wegen zwaarder. Als je AI goed wilt aansturen, moet je precies kunnen uitleggen wat je wilt, inclusief de randgevallen, de gewenste patronen en de context. Dat is in essentie dezelfde vaardigheid die nodig is om andere mensen te sturen.

Junior versus senior: wie profiteert meer?

Dit is een vraag die veel discussie oplevert, en het antwoord is niet eenduidig.

Seniors profiteren op een duidelijke manier: de routineuze delen van hun werk, de boilerplate, de standaardimplementaties, worden sneller afgehandeld. Dat geeft meer ruimte voor het werk dat diepgang vereist. Ze hebben ook de kennis om AI-output te beoordelen, fouten op te sporen en te corrigeren voordat ze schade aanrichten.

Voor juniors is het complexer. Aan de ene kant verlaagt AI de drempel om dingen voor elkaar te krijgen. Je kunt verder komen zonder dat je elk detail al beheerst. Dat is niet niets. Aan de andere kant is er een risico dat het leerpad anders verloopt. Een deel van het leren programmeren zit in het worstelen met problemen, zelf oplossingen zoeken, fouten maken en begrijpen waarom ze fouten waren. Als AI dat worstelen overneemt, leer je misschien minder grondig.

Er is ook een praktisch punt: als je AI-gegenereerde code niet kunt beoordelen op correctheid, kun je niet de verantwoordelijkheid nemen voor wat je inlevert. Dat stelt grenzen aan hoe ver je kunt komen zonder de onderliggende kennis.

De verwachting van veel teams is dan ook dat AI de lat voor juniors eerder verhoogt dan verlaagt. Je kunt meer produceren, maar de kwaliteitsverwachting stijgt mee.

Vibe coding: bouwen zonder te begrijpen

Er is een specifiek fenomeen dat de afgelopen tijd meer aandacht krijgt, en dat gaat verder dan AI als hulpmiddel voor developers: vibe coding.

De term beschrijft een manier van werken waarbij je vrijwel geen code schrijft of leest, maar in gewone taal aangeeft wat je wilt en de AI het laat uitvoeren. Je corrigeert op basis van wat je ziet, niet op basis van wat de code doet. De "vibe" klopt, en dat is genoeg.

Voor bepaalde toepassingen werkt dit. Een eenvoudige webpagina, een script voor persoonlijk gebruik, een prototype om een idee mee te verkennen: het is mogelijk om iets functioneels te maken zonder dat je de code begrijpt. Tools als Bolt en Lovable zijn hier specifiek op gericht.

Maar vibe coding heeft harde grenzen. Zodra er iets misgaat, heb je geen kader om het probleem te begrijpen. Beveiligingsproblemen zijn onzichtbaar als je de code niet kunt lezen. Schaalbaarheid en onderhoud zijn lastig te beoordelen. En als de applicatie groeit, wordt de codebase die je hebt opgebouwd zonder begrip steeds moeilijker te sturen.

Het is bruikbaar als experimenteertool. Als productiebasis voor iets dat ertoe doet, is het een ander verhaal.

Kan iedereen nu programmeren?

"Je hoeft niet meer te leren programmeren, AI doet het voor je" is een claim die regelmatig opduikt. Het klopt gedeeltelijk, en is gedeeltelijk misleidend.

Het is waar dat de drempel om iets werkends te maken is gedaald. Iemand zonder programmeerervaring kan met de juiste tools en genoeg doorzettingsvermogen een eenvoudige applicatie in elkaar krijgen. Dat was tien jaar geleden niet haalbaar.

Maar de drempel om iets te bouwen dat betrouwbaar werkt, dat veilig is, dat onderhoudbaar is en dat je kunt aanpassen als de requirements veranderen, is niet fundamenteel gedaald. Daarvoor heb je nog steeds begrip nodig van wat je bouwt.

Er is een analogie die hier helpt. Tekstverwerkers hebben schrijven toegankelijker gemaakt. Spellingscorrectie helpt. Grammarly markeert stijlproblemen. Maar niemand beweert dat je daarmee geen taalvaardigheid meer nodig hebt als je overtuigende teksten wilt schrijven. Het gereedschap helpt, maar het vervangt niet het begrip.

Hetzelfde geldt voor programmeren. AI verlaagt de kosten van het uitvoeren van standaardtaken. Het verandert niet fundamenteel wat er nodig is om goede software te maken.

Wat er wel verandert: de soorten problemen die mensen zonder formele programmeerachtergrond kunnen aanpakken, worden breder. En dat is waardevol. Een domeinexpert die data wil analyseren, een ontwerper die een idee wil prototypen, een ondernemer die een tool wil bouwen voor intern gebruik: de afstand tussen "ik wil dit" en "dit bestaat" is kleiner geworden. Dat heeft echte waarde, ook als het niet hetzelfde is als het werk van een ervaren developer.

Codekwaliteit: een groeiend vraagstuk

Naarmate meer code wordt gegenereerd door AI, ontstaat er een vraag die de industrie nog niet goed heeft opgelost: hoe houd je de kwaliteit bewaakt?

AI-modellen zijn getraind op enorme hoeveelheden code. Daarin zit ook veel code van wisselende kwaliteit. Het model reproduceert patronen, maar onderscheidt niet altijd wat goed onderhoudbaar is van wat niet. Code die syntactisch correct is en de tests doorstaat, kan nog steeds slecht zijn in de zin dat het moeilijk te lezen is, inconsistent is met de rest van de codebase, of problemen introduceert die pas later zichtbaar worden.

Er zijn ook structurele risico's. Als teams minder tijd besteden aan het doorgronden van de codebase, omdat AI veel schrijft en het er op het eerste gezicht goed uitziet, wordt het risico van verborgen technische schuld groter. De codebase groeit sneller dan het begrip ervan.

Reviews zijn daardoor belangrijker geworden, niet minder. De aanname dat AI-gegenereerde code goed genoeg is, is een aanname die teams duur kan komen te staan. De tools die het best presteren zijn die waarbij de developer de output kritisch blijft beoordelen en bijsturen.

Wat er daadwerkelijk verandert

Een eerlijk beeld van de huidige situatie: AI-tools veranderen het dagelijkse werk van developers merkbaar, maar ze vervangen het niet.

De routineuze, repetitieve delen van het werk gaan sneller. Dat is aantoonbaar en breed gedragen. De diepere verantwoordelijkheden, architecturale keuzes, kwaliteitsbewaking, veiligheid, begrijpen wat er in de codebase staat en waarom, die blijven mensenwerk, en vragen misschien meer aandacht dan voorheen.

De developer als vakman die elke regel zelf typt en volledig overziet, is in de praktijk aan het veranderen. De developer als iemand die verantwoordelijk is voor de uitkomst van softwareprojecten, en daar de juiste middelen voor inzet waaronder AI, blijft bestaan.

Wat dat vraagt: goed kunnen beoordelen wat AI levert, duidelijk kunnen formuleren wat je wilt bereiken, en de bereidheid om verantwoordelijkheid te nemen voor code die je niet elke regel zelf hebt geschreven. Dat zijn vaardigheden die je kunt ontwikkelen, en die in de praktijk al onderscheidend zijn.

De vraag of de rol van de developer verandert, is ondertussen al beantwoord door de praktijk. Hij verandert. Hoe snel en hoe fundamenteel dat verder gaat, hangt af van hoe de tools zich ontwikkelen. Maar de richting is duidelijk genoeg om je er nu al op voor te bereiden.

---

Herken je dit in je eigen werk, of zie jij het anders? Ik ben benieuwd wat jouw ervaring is met AI-tools in de praktijk.