Je systemen hebben al blinde vlekken. AI maakt ze alleen maar erger.

In 2022, voordat generatieve codeertools deel uitmaakten van ons dagelijkse engineeringwerk, schreef ik over mijn filosofie over toolselectie. Het heeft beter standgehouden dan ik had verwacht. Destijds betoogde ik dat je moet beginnen met de problemen die je daadwerkelijk oplost, je zwaktes moet kennen, en prioriteit moet geven aan hoe je de tools gebruikt in plaats van zomaar op elk hulpmiddel te springen dat het beste klinkt en te hopen dat het werkt. Ken jezelf, en je doelen, zodat je realistische verwachtingen voor je tools kunt stellen.

Destijds dacht ik aan SaaS-sprawl, niet aan AI‑gegenereerde code. Maar vandaag is mijn filosofie nog urgenter, en nog belangrijker om vol te houden.

Veel van ons hebben het 2025 DORA-rapport, dat stelde dat, in tegenstelling tot het voorgaande jaar, AI-adoptie nu positief correleert met de leveringssnelheid. De onderliggende bevinding was dat leveringsinstabiliteit bleef toenemen, en ze testten of de snelheidswinst dit compenseert. Dat niet. Dat komt overeen met onze ervaring. Ons team adopteerde agentische softwareontwikkeling en zag een toename van 48 % in doorvoersnelheid over twee kwartalen, gevolgd door een toename van 16 % in stabiliteitsproblemen. Tien personen is een kleine steekproef, maar het is ook een steekproef waaruit ik het volledige plaatje kan zien, en het patroon hield stand. 

AI-adoptie is niet langer een vraag. Je bent of net begonnen of je zit er middenin. Wat nu anders is, is dat van engineeringleiders wordt verwacht AI te adopteren en ook aan te tonen dat het zich uitbetaalt. De CEO, de raad van bestuur en de financiële afdeling willen allemaal weten hoe ze hun AI-investering kunnen optimaliseren. Ze vragen zich af of de tools die je hebt gekozen echte problemen efficiënt oplossen. 

De kloof was er altijd. AI heeft hem alleen maar groter gemaakt.

Als CTO besteed ik een aanzienlijk deel van mijn tijd aan gesprekken met andere engineeringleiders, waaronder klanten, prospects en collega’s, om prestaties en klachten over wat we met AI ervaren te vergelijken. Na voldoende van deze gesprekken ben ik patronen gaan zien in AI-adoptie en de resultaten.

De belangrijkste observatie is niet van mij. DORA heeft hier al twee jaar over gesproken: AI versterkt alles wat al in de organisatie gebeurt, zowel sterktes als zwaktes. Een team met een schone architectuur en gezonde reviewgewoonten wordt sneller. Een team dat net genoeg technische schuld heeft aangepakt om code te leveren, ontdekt nu dat die technische schuld uitgroeit tot een grote blokkade. Wat die framing mist, is waarom dit zoveel teams overvalt. AI verborg deze zwaktes niet; de systemen waarop we vertrouwden, brachten ze nooit aan het licht.

De ticket‑en‑rapportage‑stack waarop de meeste engineeringorganisaties draaien, is gebouwd om vragen te beantwoorden die mensen hebben, op menselijk tempo, door mensen die ruwweg begrepen wat “klaar” betekende voor een bepaald werkstuk. Het was nooit een perfect register. Het was altijd een benadering, aangevuld door iemand die iets ingewikkelder onderliggend samenvatte. Nu voegt AI volume toe, en nieuwe invoer die nieuwe activiteiten genereert. Geen van de systemen (of tools) die voor traditionele, niet‑AI‑ontwikkelingsmethoden werden gebruikt, is daarvoor ooit gebouwd. 

Desondanks blijven we verantwoordelijk voor dezelfde doelstellingen. Je bent nog steeds verantwoordelijk voor snelheid, kwaliteit, uitgaven en hoe je team het daadwerkelijk doet. Je kunt de dashboards van vorig jaar niet meer zomaar aannemen. 

Hier is een terechte bezwaar. DORA’s 2026 ROI-rapport beschrijft een J‑curve: een productiviteitsdaling direct na adoptie, veroorzaakt door de leercurve, de kosten van het verifiëren van AI‑gegenereerde code, en downstreamprocessen die nog niet zijn ingehaald. Ze noemen het de “onderwijs‑kost” van transformatie, en waarschuwen leiders om het niet te verwarren met falen. Gerechtvaardigd. Maar onderwijs‑kosten en een echt probleem zien er identiek uit op een dashboard dat is opgebouwd uit tickets. Als je niet kunt bepalen in welke je zit, ben je niet geduldig. Je raadt.

We moeten terug naar de basis. Ken jezelf. Ken je team. Ken de problemen die je oplost. 

Hoe kun je “Ken jezelf” met AI?

Uit mijn gesprekken heb ik vijf hoofdgebieden geïdentificeerd waar conventionele systemen, gebouwd voor door mensen gegenereerd en gerapporteerd werk, blind voor zijn. Negeer ze niet, want je riskeert je zwaktes te versterken terwijl je AI blijft adopteren.

Blind Spot 1: Velocity Theater

Meer commits en meer PR’s kunnen aanvoelen als vooruitgang, en vaak is dat zo. AI verhoogt beide aantallen automatisch. Een Stanford casestudie toonde aan dat het adopteren van AI het aantal PR’s met 14 % verhoogde. Maar wat je mist, is hoeveel van die activiteit feature‑werk is dat wordt geleverd versus onderhoud, herwerk, of churn door een refactor die niet standhield.

Om dit aan te pakken, houd de verdeling tussen feature‑werk en onderhoud in de gaten, en houd de frequentie van deployments en doorlooptijd ten opzichte van je eigen historische basislijn, niet een industriegemiddelde, in de gaten. Zonder die verdeling rapporteer je vooruitgang die je niet daadwerkelijk kunt onderbouwen.

Blind Spot 2: Review Debt

Reviewcapaciteit schaalt niet automatisch mee met de output. De verificatiebelasting is geen fase die je doorkomt; het is onderdeel van de vaste kosten voor agentische ontwikkeling. Een recente enquête onder technische leiders vond dat 80% van de teams minstens 10% van hun tijd aan review besteedt, en ongeveer één op de tien meer dan 40% besteedt. Onder die belasting swingt het team tussen een groeiende achterstand en rubberstempelen, en geen van beide is een echte oplossing.

De beperking bij het uitrollen is niet meer hoe snel code wordt geschreven. Het is hoe snel een mens daadwerkelijk ervan overtuigd kan zijn dat een wijziging correct is, hoe snel en nauwkeurig defecten kunnen worden opgespoord en aangepakt. Let op hoe de reviewbelasting daadwerkelijk over je team wordt verdeeld; anders loop je het risico senior engineers te overbelasten, je releases te vertragen, of grote productieproblemen te veroorzaken.

Blind Spot 3: Verborgen Werk

Refactorings en architectuurverschuivingen hebben de neiging zich te verbergen in andere tickets, als ze al in het ticketsysteem verschijnen. AI produceert meer van dit soort werk, niet minder. Een agent aarzelt niet om twaalf bestanden aan te raken om één bug te verhelpen, terwijl een mens misschien pauzeert en opnieuw overweegt. Werk dat het registratiesysteem omzeilt, omzeilt ook de planning, wat betekent dat je capaciteitsmodel onjuist is, en elke voorspelling die erop is gebaseerd ook onjuist is.

Om te begrijpen hoeveel werk er daadwerkelijk wordt gedaan, moet je kijken hoeveel er echt verandert in de codebasis en in de pull‑requestgeschiedenis. Zonder dat is je capaciteitsplan gebaseerd op wat mensen zich herinnerden te loggen, niet op wat ze daadwerkelijk hebben gedaan.

Blind Spot 4: Kwaliteitsdrift

Dezelfde enquête vond dat bijna de helft van de technische leiders moeite heeft om wekelijks beveiligingsproblemen te detecteren. Complexiteit, duplicatie en afhankelijkheden die niet helemaal passen, stapelen zich op over veel kleine, op zichzelf redelijke wijzigingen. Geen van hen lijkt op zichzelf alarmerend. In dezelfde Stanford‑case‑study daalde de codekwaliteit met 9% en meer dan verdrievoudigde de variantie. Terwijl het gemiddelde een beetje verschuift, beweegt de spreiding (het deel dat je opvalt) sterk. Bij AI‑volume nemen ze sneller toe dan de meeste reviewprocessen kunnen bijhouden. Drift komt vaak naar voren als een on‑call‑alert die terug te voeren is op een afhankelijkheid die niemand meer herinnert te hebben gereviewd. Tegen de tijd dat dit gebeurt, is er een redelijke kans dat een klant het eerst heeft opgemerkt.

Let de trendlijnen van beveiligingsbevindingen, afhankelijkheden en falen en herstel zien — niet de individuele commit. Complexiteit en duplicatie die zich over meerdere weken ophopen, wegen zwaarder dan één enkele wijziging die in een review wordt gemarkeerd. Zonder dat vang je drift op de manier waarop de meeste teams nog steeds doen: nadat het al een incident heeft veroorzaakt.

Blind Spot 5: Onbewezen Uitgaven

Zodra AI‑adoptie geen debat meer is, worden AI‑uitgaven en ROI de vraag waar iedereen zich op richt. Finance wil weten wat kapitaliseerbaar is versus operationeel. Het leiderschap wil weten wat de investering heeft opgeleverd. De meeste teams nemen nog steeds beslissingen over tooling, licenties en personeelsbestand op basis van intuïtie, niet op basis van bewijs van de koppeling tussen geld en geleverd werk.

Let zien waar de engineeringinspanning daadwerkelijk door de codebasis stroomt, kwartaal na kwartaal — niet waar de roadmap zegt dat het zou moeten stromen. Zonder die koppeling verdedig je het budget voor volgend jaar met anekdotes, en anekdotes overleven geen hard gesprek met een CFO.

Begin met wat je niet kunt zien

De vraag van Finance over gekapitaliseerde uitgaven en een on‑call‑pagina om 2 uur ’s nachts lijken niet gerelateerd, maar dat is ze niet. Beide kunnen worden ‘geschat’ op basis van activiteit. Maar beide zijn feitelijk beantwoordbaar, met bewijs, vanuit de code zelf.

Het antwoord van DORA op dit alles is het engineering‑systeem zelf: platformkwaliteit, workflow‑duidelijkheid, team‑afstemming. Dat klopt, en het is ook niet stap één. Je kunt geen systeem repareren dat je niet kunt zien. Elk van die vijf gebieden is iets dat je moet kunnen observeren voordat je kunt pleiten voor investering erin.

De eerste bruikbare stap is geen nieuw hulpmiddel of nieuw proces. Het is jezelf eerlijk kennen en bepalen welke van deze vijf gebieden blinde vlekken zijn waar je geen echt bewijs hebt. De meeste leiders kunnen meteen problemen in een van deze gebieden identificeren (en letten erop). Echter, het zijn juist de gebieden waar je het minste informatie hebt die het meest waarschijnlijk opduiken en je bijten naarmate je AI blijft adopteren.