AI maakt technische kennis belangrijker. Juist nu.

In mijn vorige artikel stelde ik de vraag: als iedereen straks code kan maken, wie bepaalt dan of het de juiste code is?

Hoe meer ik AI om mij heen gebruikt zie worden, hoe sterker ik tot één conclusie kom: AI maakt technische kennis belangrijker, niet minder. Dat klinkt tegenstrijdig, want als AI steeds beter wordt in het schrijven van code, zou je verwachten dat technische expertise aan waarde minder waard wordt. Waarom zou je nog diepgaande kennis nodig hebben als een AI-assistent binnen korte tijd werkende code genereert?

Toch gebeurt precies het tegenovergestelde, juist omdat AI steeds beter wordt.

De afgelopen jaren is er veel veranderd. Het zal niemand ontgaan zijn dat AI-tools tegenwoordig complete functies, tests en zelfs applicaties genereren. Dat is indrukwekkend en waardevol. Softwareontwikkeling wordt sneller, en juist daar zat een grote frustratie bij de business: waarom duurt het allemaal zo lang (en daarmee zo kostbaar)? Met AI kunnen teams meer realiseren in minder tijd. Goede ideeën worden sneller getoetst, getest en naar productie gebracht.

Dat beeld wordt ook bevestigd door recent DORA-onderzoek naar AI in softwareontwikkeling. Organisaties ontwikkelen sneller met behulp van AI, maar besteden tegelijkertijd meer aandacht aan kwaliteitsbewaking, verificatie en governance. AI versnelt het ontwikkelproces, maar maakt technische keuzes niet minder belangrijk.

Maar er schuilt een risico in de manier waarop we naar deze ontwikkeling kijken. Werkende code is namelijk niet hetzelfde als een goede oplossing. Dat zie je ook terug in recente onderzoeken van GitLab naar AI-gegenereerde code. De hoeveelheid geproduceerde code neemt toe, maar tegelijkertijd groeit de behoefte aan code reviews, refactoring en kwaliteitscontrole. 3 van de 4 developers maakt zich zorgen over de onderhoudbaarheid van AI code. Meer code betekent dus niet automatisch betere software.

Een applicatie kan precies doen wat je vandaag nodig hebt en tegelijkertijd keuzes bevatten die morgen problemen veroorzaken. Dat 'morgen' is met AI vaak nog goed te overzien. Juist de langere termijn maakt het lastig. We zagen dit eerder bij de low-code-hype rondom 'citizen development', toen de business zelf ging ontwikkelen. De voorkant ziet er altijd mooi uit; daar zit het probleem niet. De problemen zitten rondom architectuur, beveiliging, schaalbaarheid, onderhoud en integratie met andere systemen. En andersom gedacht, hoe beter de basis is gelegd, hoe beter AI ermee verder kan.

Juist daar begint het verschil tussen software bouwen en software ontwikkelen.

Organisaties zochten developers die complexe oplossingen konden realiseren en systemen konden bouwen die bedrijfsprocessen ondersteunden. Die behoefte blijft bestaan, maar de schaarste verschuift. Niet iedereen hoeft straks nog zelf alle code te schrijven, want AI neemt een groot deel van dat werk over.

Wat niet verdwijnt, is de behoefte aan mensen die begrijpen wat die code doet. Mensen die kunnen beoordelen of een oplossing veilig is, of een architectuur toekomstbestendig is, of een technische keuze over twee jaar nog steeds de juiste blijkt en of een business requirement überhaupt gebouwd moet worden. En vandaag de dag een erg belangrijke vraag: wat kost deze applicatie nu, en in de toekomst, nu we er een LLM in hebben verwerkt?

Ook McKinsey beschrijft deze ontwikkeling. Niet het schrijven van code wordt schaarser, maar het vermogen om AI-gegenereerde oplossingen te beoordelen, architectuurkeuzes te maken en technische kwaliteit te bewaken. Upskilling is daarbij ontzettend belangrijk.

Hoe makkelijker het wordt om software te bouwen, hoe belangrijker die vragen worden. Snelheid vergroot namelijk niet alleen de kans op succes, maar ook de impact van verkeerde keuzes. En zeker ook op financieel vlak. Dat wordt extra relevant nu AI onderdeel wordt van veel applicaties en bedrijfsprocessen. Voor je het weet zijn niet alleen je tokens opgebrand, maar heb je een applicatie gebouwd waarin een AI- of LLM-aanbieder diep verweven zit in een core businessproces. Functioneel kan dat fantastisch werken, terwijl er tegelijkertijd een stevige financiële afhankelijkheid ontstaat. Verhoogt die aanbieder zijn tarieven of past hij zijn licentiemodel aan, dan raakt dat direct de businesscase en de operationele kosten. Precies wat nu regelmatig gebeurt. Daarom hoort dit vanaf het begin onderdeel te zijn van de technische afweging: welke afhankelijkheid accepteren we, waar bouwen we flexibiliteit in, en welke financiële risico's nemen we mee in het ontwerp?

Developers worden dus belangrijker, alleen verschuift de rol van hun expertise. Steeds minder tijd gaat zitten in het produceren van code, en steeds meer waarde ontstaat bij het beoordelen, verbeteren en richting geven van oplossingen:

• Kan deze oplossing meegroeien met de organisatie?
• Tot hoever moeten deze überhaupt mee kunnen groeien?
• Hoe afhankelijk worden we van bepaalde technologieën?
• Welke risico's introduceren we vandaag zonder ze direct te zien?
• Welke risico's accepteren we wel, en welke niet?
• Welke financiële risico's lopen we?
• Hoe zorgen we dat snelheid niet ten koste gaat van kwaliteit?

En maken we, als we een keuze maken, een bewuste en afgewogen keuze?

Dat zijn vraagstukken die je niet oplost met een betere prompt. Daar heb je mensen voor nodig die technologie begrijpen, die verder kijken dan de code alleen en de gevolgen van keuzes kunnen overzien.

Misschien is dat daarom wel de grootste misvatting rondom AI in softwareontwikkeling: het idee dat technische kennis minder belangrijk wordt. Ik denk dat het omgekeerde waar is. Doordat AI steeds meer taken overneemt, wordt juist zichtbaar waar expertise echt waarde toevoegt. Niet in het schrijven van code, maar in het maken van de juiste langetermijnkeuzes. En dat zijn de keuzes die uiteindelijk bepalen of software succesvol is.

AI helpt ons sneller bouwen, maar bepaalt niet wat de beste keuze is. Daarom wordt technische kennis belangrijker.

Herken je deze ontwikkeling binnen jouw organisatie? Ik ben benieuwd hoe jullie omgaan met de balans tussen AI, technische expertise en kwaliteit.

Jeroen

Bronnen

• Google Cloud DORA (2026). Impact of Generative AI in Software Development.
• McKinsey & Company (2026). The AI Revolution in Software Development.
• GitLab (2026). Global DevSecOps Report.