De twee snelheden: waarom sneller coderen niet beter coderen is

AI belooft software veel sneller te produceren.

Het kan in enkele minuten een functie genereren, een fout uitleggen, een test corrigeren, documentatie schrijven, een pull request voorstellen, een component refactoren of een eerste versie van een applicatie bouwen. Voor product- en techteams is de belofte duidelijk: kortere doorlooptijden, meer volume en vaker opleveren.

Maar één vraag wordt steeds belangrijker: wat gebeurt er als de productiesnelheid de validatiesnelheid overtreft?

Want software is niet zomaar geschreven code. Het is code die begrepen, getest, gereviewd, geïntegreerd, gedeployed, gemonitord, onderhouden en gefikst wordt. En dat hele proces versnelt niet vanzelf omdat een model 200 regels in tien seconden kan genereren.

AI wordt steeds sneller, maar kwaliteit kost nog altijd tijd.

Code produceren was nooit het echte probleem

In veel teams zit de bottleneck niet in het eigenlijke schrijven van de code. Het zit in alles eromheen.

De behoefte begrijpen. De impact inschatten. De juiste architectuur kiezen. Randgevallen controleren. Tests schrijven. Een pull request reviewen. Deployen zonder iets te breken. Productie monitoren. Bijwerkingen fiksen. Het systeem zes maanden later nog onderhouden.

AI versnelt vooral het zichtbare deel: het genereren.

Maar als het meer code produceert dan het team kan reviewen, testen of begrijpen, verkleint het niet noodzakelijk het risico. Het verschuift het alleen.

Dat is de huidige paradox: we winnen snelheid bij het schrijven van code, maar niet altijd bij de kwaliteitsborging.

En in echte software wordt kwaliteit niet afgemeten aan het aantal geproduceerde regels. Ze wordt afgemeten aan het vermogen van het systeem om correct te blijven werken, op lange termijn, in een omgeving die verandert.

IT-projecten faalden al prima zonder AI

We moeten beginnen met een ongemakkelijke waarheid: IT-projecten hadden geen AI nodig om mis te lopen.

Grote studies naar IT-projecten tonen al jaren zeer hoge percentages mislukkingen, vertragingen en budgetoverschrijdingen. Een analyse van McKinsey en Oxford van meer dan 5.400 grote IT-projecten liet zien dat ze gemiddeld 45% boven budget gingen, 7% langer duurden en 56% minder waarde opleverden dan verwacht. Voor grote softwareprojecten waren de cijfers nog zwaarder: ongeveer 66% budgetoverschrijding en 33% vertraging.

Nog zorgwekkender: 17% van de onderzochte grote IT-projecten presteerde zo slecht dat ze het voortbestaan van het bedrijf zelf konden bedreigen.

Dat is belangrijk, want AI komt terecht in een sector waar de uitdaging nooit alleen het coderen was. De historische problemen liggen elders: vage doelstellingen, technische schuld, slechte coördinatie, verborgen afhankelijkheden, onderschatte complexiteit, zwakke governance en onvoldoende validatie.

Met andere woorden: AI komt niet binnen in een perfect geoptimaliseerde fabriek.

Slechte softwarekwaliteit is nu al erg duur

Softwarekwaliteit heeft ook een enorme macro-economische kost.

Het CISQ schatte dat slechte softwarekwaliteit de Verenigde Staten in 2022 2,41 biljoen dollar kostte. Dat cijfer omvat onder meer operationele storingen, mislukte projecten, beveiligingslekken, moeilijk te onderhouden legacysystemen en technische schuld.

Die kost blijft vaak onzichtbaar tot ze acuut wordt. Een logische fout, een kwetsbare dependency, gebrekkige toegangscontrole of een slecht geteste patch kan maandenlang onopgemerkt blijven en dan in productie opduiken als incident, datalek of storing.

AI kan bepaalde kosten verlagen. Maar het kan ook nieuwe creëren als het het codevolume verhoogt zonder de kwaliteit van de vangrails te verbeteren.

De cijfers over AI-gegenereerde code manen tot voorzichtigheid

Recente data zeggen niet dat AI nutteloos is. Ze tonen iets interessanters: AI is nuttig, maar niet gratis.

Veracode analyseerde code die door meer dan 100 modellen werd gegenereerd voor 80 programmeertaken. Resultaat: slechts 55% van de gegenereerde code werd als veilig beoordeeld. Dat betekent dat bijna 45% in de geteste scenario's bekende kwetsbaarheden introduceerde.

CodeRabbit vergeleek pull requests van mensen met pull requests die door AI waren gegenereerd. Op 470 pull requests bevatten de AI-gegenereerde wijzigingen gemiddeld 10,83 problemen per PR, tegenover 6,45 bij menselijke PR's. Dat is ongeveer 1,7 keer zoveel problemen.

Apiiro zag nog een zorgwekkende trend: in de onderzochte repositories introduceerde AI-gegenereerde code in juni 2025 meer dan 10.000 nieuwe beveiligingsbevindingen per maand, een vertienvoudiging in zes maanden.

Deze cijfers bewijzen niet dat AI altijd slechte code schrijft. Ze tonen dat de snelheid van codegeneratie defecten kan vermenigvuldigen als ze niet gepaard gaat met betere controles.

Het probleem is niet dat "AI fouten maakt". Mensen doen dat ook. Het probleem is dat AI fouten kan maken op hoge snelheid, met veel zelfvertrouwen, in een vorm die eruitziet als productieklare code.

Productiviteitswinst komt niet vanzelf

Je zou kunnen denken dat AI, zelfs met een paar fouten, rendabel blijft omdat het het werk van developers enorm versnelt. Ook hier is de realiteit minder eenvoudig.

Een gecontroleerde studie van METR, gepubliceerd in 2025, volgde 16 ervaren developers bij 246 taken in open-sourceprojecten die ze goed kenden. De developers dachten dat AI hen ongeveer 24% tijd zou besparen. Achteraf schatten ze nog steeds dat ze 20% hadden bespaard.

Maar de werkelijke metingen toonden het omgekeerde: met AI-tools deden ze er gemiddeld 19% langer over.

Waarom? Omdat de tijd die ze bij het schrijven wonnen, werd opgeslokt door de tijd die ze kwijt waren aan herlezen, corrigeren, de tool bijsturen, wachten op suggesties en die suggesties opkuisen.

Dit resultaat betekent niet dat AI iedereen altijd vertraagt. Het kan heel nuttig zijn voor eenvoudige taken, prototypes, developers die een codebase minder goed kennen of repetitief werk. Maar het onderstreept één essentieel punt: in een complex softwaresysteem volstaat het niet om een plausibele oplossing te produceren. Je moet controleren of ze correct is.

En verificatie blijft duur.

Updates volgen elkaar steeds sneller op

Tegelijk wordt moderne software steeds vaker bijgewerkt.

De beste DevOps-teams deployen on demand, soms meerdere keren per dag. DORA toont al jaren dat de best presterende teams snelheid en stabiliteit combineren: ze deployen vaak, herstellen snel na incidenten en houden wijzigingen klein.

Zelfs grote consumentensoftware versnelt haar releasecycli. Chrome is bijvoorbeeld door de jaren heen van langere naar kortere cycli overgestapt, en Google heeft aangekondigd vanaf Chrome 153 elke twee weken een stabiele release uit te brengen. Microsoft houdt van zijn kant een gestructureerd maandelijks ritme aan voor Windows-beveiligingsupdates, met updates op de tweede dinsdag van elke maand en patches buiten de cyclus wanneer er kritieke problemen opduiken.

Achter die versnelling zit een gezonde logica. Kleinere, frequentere updates kunnen het risico verkleinen: minder wijzigingen tegelijk, snellere feedback, snellere fixes en gebruikers die sneller beschermd zijn.

Maar die logica werkt alleen als de fundamenten er staan: automatisering, betrouwbare tests, observability, feature flags, rollback, grondige review en ingebouwde beveiliging.

Zonder die fundamenten betekenen meer deployments gewoon meer kansen om iets kapot te maken.

Snelheid verwarren met volwassenheid

Snelheid is op zich geen probleem.

Een volwassen team dat tien keer per dag deployt, met degelijke tests, kleine wijzigingen, goede observability en de mogelijkheid om snel terug te rollen, kan betrouwbaarder zijn dan een team dat één keer per kwartaal in paniek deployt.

Het probleem ontstaat wanneer AI een team aanzet om sneller te produceren zonder zijn vermogen om te valideren te verbeteren.

Meer gegenereerde code betekent meer pull requests. Meer pull requests betekenen meer code reviews. Meer code reviews betekenen meer cognitieve belasting. Meer wijzigingen betekenen meer interacties tussen componenten. Meer interacties betekenen meer subtiele bugs.

Als teams hun werkwijze niet aanpassen, kan AI trage technische schuld omzetten in snelle technische schuld.

Vroeger schreven we moeizaam slechte code. Nu kunnen we die massaal genereren. Het probleem zit in de doorvoer.

AI versterkt de bestaande organisatie

Recente DORA-rapporten zijn op dit punt bijzonder leerzaam. In 2024 ging de adoptie van AI gepaard met een geschatte daling van de softwaredoorvoer en, belangrijker nog, een daling van de stabiliteit. In 2025 werd het verband met de doorvoer positiever: teams lijken te leren hoe ze AI in hun workflows integreren. Maar DORA blijft een negatief verband met stabiliteit vaststellen.

Die nuance is belangrijk.

AI is niet zomaar een individuele tool. Het is een organisatorische versterker.

In een team met goede tests, snelle CI, degelijke reviews, beveiligingspraktijken en een heldere architectuur kan het nuttige taken versnellen.

In een ongeorganiseerd team met weinig tests, fragiele deployments en slecht begrepen technische schuld kan het sneller problemen creëren dan het team nu al aankan.

AI vervangt de basis niet. Het maakt haar zichtbaarder.

Wat teams moeten meten

Als bedrijven AI serieus willen inzetten in softwareontwikkeling, moeten ze ophouden met alleen volume te meten.

Het aantal gegenereerde regels is geen zinvolle metriek. Het aantal gesloten tickets evenmin, als die tickets terugkomen als bugs. Het aantal pull requests kan zelfs een indicator van ruis worden.

De juiste vragen zijn veeleisender:

• Hoeveel bugs halen productie na AI-ondersteunde code?
• Hoelang duren code reviews?
• Wat is het rollbackpercentage?
• Wat is de change failure rate?
• Hoeveel kwetsbaarheden worden er geïntroduceerd?
• Hoeveel van de gegenereerde code wordt in de weken erna verwijderd of herschreven?
• Hoeveel tijd wordt er echt gewonnen tussen het idee en een stabiele feature in productie?

We moeten de hele cyclus meten: generatie, review, testen, deployment, incidenten en onderhoud.

Anders meten we alleen het gaspedaal, nooit de remmen.

Wat dit betekent voor softwarekwaliteit

Softwarekwaliteit moet mee evolueren met AI.

Ten eerste moet testen belangrijker worden, niet minder belangrijk. Hoe sneller AI code genereert, hoe crucialer geautomatiseerde tests worden die fouten snel kunnen wegfilteren.

Ten tweede moet code review veranderen. AI-gegenereerde code reviewen vraagt bijzondere aandacht: bedrijfslogica, beveiliging, randgevallen, dependencies, duplicatie en onderhoudbaarheid. De code kan netjes geformatteerd zijn en toch fout.

Ook beveiliging moet vroeger in het proces worden ingebouwd. Als kwetsbaarheden pas aan het einde van de pipeline worden ontdekt, heeft AI het aantal te corrigeren wijzigingen al vermenigvuldigd. Tools zoals SAST, SCA, secret scanning, dependency-analyse en policy-as-code worden nog belangrijker.

Tot slot moeten teams de omvang van wijzigingen verkleinen. AI maakt het verleidelijk om grote aanpassingen in één keer te vragen. Dat is vaak een vergissing. Kleinere wijzigingen blijven makkelijker te reviewen, testen, deployen en terug te draaien.

De juiste strategie is niet om AI af te remmen. Het is om zijn werk op te knippen, zodat de kwaliteit kan volgen.

En de toekomst?

De toekomst van softwareontwikkeling wordt niet gewoon "meer code, sneller".

Het wordt een race tussen twee snelheden.

Aan de ene kant de snelheid waarmee modellen, agents, copilots, frameworks, prompts en automatisering genereren.

Aan de andere kant de snelheid van validatie via testen, beveiliging, observability, architectuur en begrip van de business.

Als alleen de generatie versnelt, stapelen bedrijven meer technische schuld, meer bugs en meer risico's op. Als ook de validatie versnelt, kan AI de softwarelevering echt verbeteren.

Het probleem is dus niet hoe snel AI code kan schrijven, maar hoe snel wij die kunnen reviewen en corrigeren.