01 De stagnatie

Inmiddels heeft ieder softwareteam de demo wel een keer gezien. Een agent programmeert in een paar minuten een nieuwe feature en een kamer vol ervaren developers valt helemaal stil. En dan, een jaar later, is er eigenlijk verrassend weinig veranderd aan hoe we software bouwen en live zetten.

De bottleneck is namelijk niet de techniek. De modellen zijn goed genoeg en worden vanzelf beter. Het echte probleem is adoptie. Hoe maak je van een leuk trucje in een testomgeving de standaard manier waarop je team bouwt. Veilig, herhaalbaar en in productie. Die omschakeling is een organisatieding, geen technische uitdaging, en precies daar loopt bijna iedereen vast.

Daar is inmiddels ook hard bewijs voor. In het DORA onderzoek zag je dat bij elke kwart toename in AI gebruik de individuele productiviteit ietsje steeg. Maar bij diezelfde groep daalde de tijd besteed aan echt waardevol werk met bijna drie procent. Op teamniveau was het nog duidelijker: de doorvoer snelheid daalde en de stabiliteit ging fors achteruit. Developers hebben dus het idee dat ze sneller zijn, terwijl het belangrijke werk en het live zetten stiekem vertragen. Als iedereen voor zich sneller gaat werken zonder de juiste kaders, wordt het hele systeem juist minder betrouwbaar.

Dit artikel geeft je twee dingen:

1. Ten eerste een model om te zien waar jouw bedrijf nu echt staat: zes eerlijke fases in plaats van een hype.
2. Ten tweede een manier om verder te komen waarbij adoptie de hoofdrol speelt. Denk aan kleine, goed afgeschermde experimenten die direct waarde opleveren en tegelijkertijd vertrouwen kweken.

02 Waar je nu staat: de zes fases

Adoptie draait hierbij niet om hoeveel AI tools je hebt aangeschaft. Het gaat om een verandering op twee fronten tegelijk: wie de software bouwt en wat die software precies is.

Kijk je naar de mensen, dan zie je de plek van de AI steeds verder opschuiven, van een simpel chatvenster op je tweede scherm naar een agent die echt de regie pakt. Kijk je naar de techniek, dan draait de architectuur om. Code die af en toe een model aanroept verandert in een agent die "echte" (deterministische) code gebruikt als gereedschap, voor momenten dat het antwoord honderd procent kloppend moet zijn.

Zes adoptie fases. Wie bouwt het, waar zit de AI, wat bouwen we eigenlijk als de controle omdraait?. De meeste organisaties zitten tussen 1 en 2.

Alles in dit model is in verandering, maar we gebruiken vier vaste ankers om de voortgang te inzichtelijk te maken:

• De scope: We kijken heel gericht alleen naar productontwikkeling en de software die live gaat.
• De Product Manager: De onmisbare schakel en het schanier tussen de business en de techniek.
• Het developmentteam: De plek waar de transitie echt gebeurt, gewoon met een mix van junior en senior mensen.
• De governance: Technische spelregels zoals de pijplijn, tests en meetgegevens. Met agents erbij wordt dit de onmisbare ruggengraat.

De stappen van handwerk naar agent

Twee van die ankers verdienen extra aandacht, want samen zorgen ze ervoor dat je jezelf niet voor de gek houdt tijdens de "klim" naar de volgende fase. De meetgegevens vertellen je of je echt verbetert of dat je je alleen maar sneller voelt. En dat laatste is precies de valkuil die de data uit het DORA onderzoek blootlegt. De technische discipline is wat een machine snel laat werken zonder de boel kapot te maken. Zonder deze twee pijlers verandert individuele snelheid stiekem gewoon in een enorm risico voor je hele systeem.

• Metrics: Denk aan hoe vaak je live gaat, de doorlooptijd van wijzigingen, het percentage foute releases en de tijd om fouten te herstellen. Zodra je met agents gaat werken, voeg je daar nog twee aan toe: hoe vaak de agent werk opnieuw moet doen en hoe vaak een mens moet ingrijpen.
• Engineering discipline: Dingen als testgedreven ontwikkelen, continu integreren, kritische code reviews, kleine doorlopende releases, code opschonen en samen verantwoordelijk zijn voor de volledige codebasis.

Dit model geeft een eerlijk beeld van de realiteit: de meeste bedrijven blijven ergens tussen fase één en twee hangen. Fase drie, waar de Product Manager echt de eigenaar wordt van de specificaties, is niet voor niets de moeilijkste stap. Het is namelijk geen IT upgrade maar een transformatie van je bedrijf. Het dwingt de Product Manager en de business daarachter om compleet anders na te denken over beslissingen nemen en specificeren. Het model laat je precies zien waar je nu staat. De rest van dit artikel gaat over hoe je daadwerkelijk in beweging komt.

03 De paradox van ons vak

Het klinkt misschien gek: wij zeggen altijd dat we in een vakgebied zitten dat draait om mensen en ambacht en nu breken we een lans voor machines die de code schrijven. Toch klopt dat helemaal.

AI zorgt er vooral voor dat het typen van code straks bijna niks meer kost. Wat AI niet kan is bepalen wát we moeten bouwen, inschatten of een oplossing werkt in de "echte wereld" en bepalen wat waarde toevoegt voor het bedrijf. Dat is het echte vakmanschap en dat wordt nu juist meer waard in plaats van minder.

Het ambacht verdwijnt dus niet, het schuift gewoon een niveau omhoog. De focus komt te liggen op de achterliggende intentie, de regels rondom hoe je bouwt, de kaders voor veilige snelheid en de brug slaan tussen techniek en de business. Een team dat alleen maar sneller leert typen, heeft uiteindelijk niet zo heel veel gewonnen.

Daar zien we wel één groot risico. Als juniors nooit meer die vlieguren maken om zelf code te schrijven, waar halen we straks dan onze seniors vandaan? Dit werkt alleen als we de basis blijven trainen. Je moet blijven leren over debuggen en snappen hoe netwerken en systemen echt werken, zodat de mensen die de agents aansturen direct zien wanneer de output niet klopt. Sla je dat over, dan word je volledig afhankelijk.

Het ambacht schuift omhoog. Het werk dat vroeger je hele dag vulde besteed je nu uit aan de machine. Wat overblijft is het deel dat eigenlijk altijd al het meest waardevol was en daar heb je nu eindelijk de tijd voor!

‍

04 Doen om te leren

Je rolt het gebruik van AI niet zomaar even uit. Je zet stappen door middel van losse experimenten. Zorg dat elk experiment klein genoeg is om veilig te zijn, concreet genoeg om waarde op te leveren en zichtbaar genoeg om draagvlak te creëren.  

Dit is meer een mindset dan een project. Een topsporter is ook nooit klaar met trainen, die training is gewoon een vast onderdeel van het vak. Adoptie werkt precies zo. Het is geen programma met een einddatum en een feestelijk lintje, maar een vast ritme dat je bedrijf blijft aanhouden lang nadat je het eerste succes hebt geboekt.  

Dat ritme is simpel en vormt de motor van het hele model. Kies een doel dat er echt toe doet, formuleer een hypothese over hoe AI daarbij kan helpen, doe het allerkleinste experiment dat je antwoord kan geven, meet de boel en hak dan een knoop door. Opschalen, aanpassen of direct stoppen. Live zetten om te leren en dan weer opnieuw beginnen.

De cyclus. Het is geen trechter, maar een route die het team steeds opnieuw aflegt. Elke ronde lever je iets echts op en verzamel je nieuw bewijs.

‍

‍

Niet elk probeersel met AI mag de naam experiment dragen. De acties die je bedrijf echt verder helpen voldoen aan een vaste set voorwaarden. Mis je er eentje, dan wordt je experiment al snel een poppenkast of zelfs een gevaar.  

• Een echt doel:
  Gekoppeld aan iets wat de business of het team daadwerkelijk voelt. Denk aan de doorlooptijd, fouten die erdoorheen glippen of die ene feature op de roadmap die maar niet af komt. Ga dus niet AI gebruiken puur om het gebruiken.  
• Een toetsbare hypothese:
  Zo geformuleerd dat de uitkomst ook kan aantonen dat je ernaast zat. Dus wel "Als we dit doen dan verandert dat met ongeveer zoveel" in plaats van "AI gaat ons vast helpen".  
• Goede vangrails:
  Het release proces kan een foute wijziging opvangen voordat deze in productie belandt. Daardoor is het überhaupt veilig om het experiment uit te voeren. Zie sectie vijf.  
• Klein en terug te draaien:
  Zo afgebakend dat een mislukking gewoon een normale dinsdag is en geen groot incident. Als je het niet goedkoop ongedaan kunt maken, ben je niet aan het experimenteren maar aan het gokken.  
• Snel meetbaar:
  Je wilt binnen een paar dagen signaal krijgen uit data die je al vertrouwt. Aan een resultaat dat je pas over een jaar kunt beoordelen heb je nu helemaal niks.  
• Afgebakend in tijd en het mag fout gaan.
  Een harde deadline en expliciet toestemming om de stekker eruit te trekken. Het hele eieren eten is dat je ervan leert. Snel afscheid nemen van een slecht idee is dus pure winst.  

05 Guardrails zijn vanaf nu een vereiste

De cijfers uit het DORA onderzoek zijn een duidelijke waarschuwing. De snelheid van individuele developers die AI gebruiken holt je opleveringen uit, tenzij er iets in het systeem zit dat de fouten opvangt die mensen over het hoofd zien. Dat iets is je pijplijn. De regel is dus keihard:

Jouw release pijplijn is vanaf nu de baas over je AI veiligheid.

Elke codewijziging moet zijn plek in productie verdienen via exact dezelfde controles. Het maakt daarbij niet uit of een mens of een agent de code schreef. Denk aan automatische tests, beveiligingsscans, een extra kritische beoordeling en een gecontroleerde uitrol die je ook weer makkelijk terugdraait. Een kritische beoordeling is eigenlijk de nieuwe peer review, alleen hoeft de beoordelaar nu geen collega meer te zijn. Het kan een mens zijn of een tweede agent met andere instellingen die als enige taak heeft om de code kapot te maken in plaats van zomaar goed te keuren.  

Dit is n vrijblijvende meer zodra een agent honderd code wijzigingen per dag voorstelt. Handmatig alles doorlezen is dan geen doen meer. De DORA data laat precies zien wat er gebeurt als je dat toch probeert: de tijd die je kwijt bent aan het controleren eet alle tijdwinst van het team weer op. Geautomatiseerde controles zijn de enige manier waarop je code geschreven door AI zonder te vertragen of de boel in productie kapot te maken. Dit bepaalt het tempo voor de rest van de rit. Je bereikt de latere fases niet door nog meer AI te gebruiken, maar door je controles volledig te automatiseren. Niets anders kan het namelijk bijhouden als een agent tien keer zoveel code schrijft.  

Klinkt dat wat streng, kijk dan eens naar wie dit al toepassen. De Linux kernel, misschien wel de plek met de meest veeleisende review cultuur ter wereld, heeft een duidelijke regel ingesteld voor code gemaakt met AI. Hulp van machines is van harte welkom, maar oplossingen die volledig door AI zijn bedacht zonder menselijke inbreng komen er niet in. Een mens blijft verantwoordelijk voor elke geschreven regel. Hoe Linus Torvalds dit zelf verwoordt spreekt boekdelen. Developers klagen al jaren dat er te weinig tijd is voor goede code reviews en AI zou wel eens de oplossing kunnen zijn. Het strengste open source project ter wereld omarmt AI door zwaar op de vangrails te leunen en deze juist niet weg te halen. Dat kun jij dus ook doen.  

Er is gelukkig ook een enorme k en dat is de echte reden om hier enthousiast over te zijn. De strakke discipline die AI veilig maakt zoals goede tests, snelle pijplijnen en kleine releases is exact het vakwerk waar de meeste teams nooit de tijd voor hadden. AI geeft ons eindelijk de uren terug die normaal opgingen aan adusjes en brandjes blussen. Die tijd kun je nu steken in echt vakmanschap. De vangrails zijn geen blok aan je been. Ze vormen juist het fundament om echt vaart te maken.

_{BRON · DORA 2024 STATE OF DEVOPS}

_{Per 25% rise in AI adoption: +2.1% individual productivity, and at the team level −1.5% delivery throughput and −7.2% delivery stability. Individual output up, system reliability down. The teams that kept quality did it with strong delivery practices, not by slowing AI down.}

_{BRON · LINUX KERNEL AI-TOOLING POLICY (2025)}

_{The kernel now accepts AI-assisted patches but bars purely machine-generated ones — "human accountability for patches is critical." Torvalds' angle: teams have long lacked review, and LLMs may finally solve that, maintainers report automated review is already useful around 60% of the time. The strictest review process in software is leaning on its guardrails, not lowering them.}

Eén proces voor iedere change. De code van mens en agent gaat door exact dezelfde poortjes. De reviewer kan gewoon een anders afgestelde agent zijn. Niets bereikt ooit de productieomgeving zonder dat het succesvol door de vangrails is gekomen.

‍

06 Probeer dit: legacy systemen temmen met AI

Twaalf losse testjes met AI geven je misschien het gevoel van vooruitgang, maar leveren onderaan de streep helemaal niks op. Het is veel actie zonder duidelijk doel, waardoor het bedrijf alsnog stil blijft staan. De oplossing is simpel. Stop met in het wilde weg experimenteren, focus al die energie op één concreet bedrijfsdoel en meet het resultaat. Weer grip krijgen op een stuk stokoude software is hier het perfecte voorbeeld van. Een heel nieuw project bouwen met AI is snel, leuk en vooral een grote afleiding. De echte waarde, en de angst, zit in de oude software. De code die eigenlijk niemand durft aan te raken, zonder tests om foutjes op te vangen en die stiekem de hele planning gijzelt.  

De klassieke manier om dit veilig te moderniseren is door de oude boel langzaam te wurgen. Je pakt het oude systeem in, haalt er telkens één functionaliteit uit, linkt die naar een nieuwe oplossing en herhaalt dat totdat de oude kern volledig overbodig is. Dit werkt goed. Wat het zo pijnlijk duur maakte was de belangrijkste voorwaarde . Je moest uitgebreide tests schrijven die precies vastlegden wat de oude code eigenlijk deed, zodat je kon bewijzen dat de nieuwe versie exact hetzelfde reageerde. Dat was zulk monnikenwerk dat het zelden echt gebeurde.  

Dit is nou precies het soort werk dat je heel lekker aan een machine kunt overlaten. Denk aan een experiment zoals we in sectie vier bespraken. Het doel is het risico en de kosten verlagen bij het vervangen van oude code die de planning in de weg zit. De hypothese is dat als AI bots een flinke berg tests genereren die het huidige gedrag vastleggen, we de oude code in stukjes kunnen vervangen zonder dat er dingen stuk gaan. De uitvoering is dat de bots de tests schrijven, het systeem checkt of ze slagen en zo creëer je vangrails. Vervolgens helpt de AI bij het herschrijven van de code achter dat vangnet, terwijl de gebruikers stapsgewijs naar de nieuwe onderdelen worden geleid.  

Tien jaar geleden deed je dit met de hand voor de projecten die zo een investering waard waren. Tegenwoordig doen de bots het saaie werk. Daardoor wordt het betaalbaar voor ieder project en krijg je eindelijk de dekkende tests die je zelf anders toch nooit had geschreven.  

Dit werkt in de praktijk al fantastisch. Tijdens de Sonar conferentie in 2026 deelde Laura Tacho een mooi voorbeeld van Bookingcom. Zij focusten AI op één heel concreet en meetbaar doel in plaats van het overal een beetje in te zetten. Het resultaat was zestien procent meer opleveringen met exact dezelfde kwaliteit. Dat is snelheid die je terugziet in de bedrijfsresultaten en niet alleen in een medewerkerstevredenheidsonderzoek.

Strangler: langzaam vervangen, met hulp van bots. De tests komen eerst en leggen het gedrag vast. De nieuwe code wordt veilig daarachter gebouwd en het verkeer wordt stap voor stap omgeleid totdat de oude kern weg is.

‍

07 Het ankerpunt is waar de waarde zichtbaar wordt

Dit is het scharnierpunt tussen de business en IT. Het is ook precies de stap die veel v stiekem overslaan. Doe je dit goed, dan wordt de meerwaarde direct zichtbaar voor het hele bedrijf. Sla je dit over, dan blijven de voordelen hangen op de IT afdeling. De tijdwinst is er dan wel, maar je kunt het nooit hardmaken richting de mensen die het werk f.  

Houdt deze simpele gedachte centraal bij elke keuze: AI versnelt het hele bedrijf, niet de IT afdeling. Als je het puur ziet als een leuk nieuw stuk gereedschap voor ontwikkelaars, blijf je voor altijd hangen in fase twee waarbij iedereen alleen maar wat sneller typt. De echte hefboom zit namelijk in het product zelf en in wat die software voor een klant oplost. Daarom zie je in dit adoptie model dat de AI uiteindelijk doorschuift naar het eindproduct en niet alleen maar een handig tooltje op de achtergrond blijft.   

De Product Manager is die onmisbare schakel. Die zorgt voor de verbinding tussen zakelijke waarde aan de ene kant en technisch vakmanschap aan de andere kant. Veranker het werk op dit punt, zorg dat de vangrails staan en richt je op een probleem waar de business echt wakker van ligt, zoals oude code die alles vertraagt. Zo presenteer je de behaalde resultaten in een taal die iedereen in het bedrijf begrijpt. Laat je dat ankerpunt los, dan wordt het werk nog steeds gedaan maar ziet niemand buiten het technische team er de waarde van in. En dat brengt ons bij het laatste punt: het verzilveren van die waarde.

Anker op het snijvlak. Blijf precies tussen de business en de techniek in zitten, zo trek je aan beide kanten de boel vooruit. Schuif je het puur in de schoenen van techniek, dan wordt het al snel een typisch IT project waarbij iedereen wat sneller typt maar de klant er uiteindelijk helemaal niets van merkt.

‍

08 Zorgen dat AI ook echt geld oplevert

Waar je begint is één ding. De vraag die de directie gaat stellen is natuurlijk of het allemaal wel wat oplevert. En geloof me, je kunt makkelijk een jaar lang druk zijn met allerlei AI initiatieven zonder dat je daar onderaan de streep ook maar iets van terugziet.  

Meet de uitkomst in plaats van het gereedschap. Dingen als het aantal gegenereerde regels code of hoe vaak een tool is geopend klinken leuk, maar die cijfers stijgen toch wel, ongeacht of je daadwerkelijk iets verbetert. Het enige cijfer dat er echt toe doet is het zakelijke doel dat je aan je experiment hebt gekoppeld. Denk aan hoe snel je een nieuw product lanceert, die ene feature die nu eindelijk af is of de bugs die de klant nooit hebben bereikt. Kan je een experiment niet koppelen aan zo een meetbaar doel, dan ben je er nog niet klaar voor om te starten.  

Haal het weg bij IT. De echte kracht van AI zit in het product en de waarde die het levert aan de klant. Het hoort dus thuis in het hele proces en niet alleen bij het tikken van code. Dat betekent dat de mensen die bepalen wat er gebouwd wordt vanaf dag één aan tafel moeten zitten. Zodra adoptie alleen op de ontwikkelafdeling blijft hangen verzand je in een situatie waarbij iedereen wel wat sneller typt, maar die snelheid stiekem weer verdampt voordat de rest van het bedrijf er ook maar iets van merkt.  

Vakmanschap is de versneller. De teams die de vaart van AI succesvol weten om te zetten in harde resultaten, zijn de teams die hun vaardigheden het snelst naar een hoger niveau tillen. Het gaat dan om inschatten wat je precies moet bouwen, het gevoel hebben voor wanneer iets echt goed is en het hebben van de discipline om een machine snelheid te laten maken zonder dat alles direct in de soep loopt. Dat is geen enkele bedreiging voor een organisatie die draait op mensen en talent. Het is juist het moment waarop echt vakmanschap meer telt dan ooit tevoren.  

Begin met één concreet doel dat ertoe doet. Doe één goed afgeschermd experiment precies op het grensgebied van de techniek en de business. Meet hoeveel waarde het oplevert. En doe het daarna gewoon nog een keer, want met dit werk ben je eigenlijk nooit helemaal klaar.  

Een laatste gedachte om mee af te ronden. Bouw eerst je fundament. We beginnen niet voor niets bij het ontwikkelproces. Als eerste heb je discipline nodig, want daar rolt een strakke manier van software bouwen uit. Een strak proces levert je schone data op, en die data maakt op zijn beurt weer goede systemen mogelijk. Alleen met dat fundament kun je de juiste keuzes maken en dat is precies waar goed product management omdraait. Pas dan blijft een verbetering in je bedrijf ook echt hangen. De volgorde van deze stappen is geen toeval. Draai je het om, dan eindig je met een totaal onbelangrijk proces dat vooral heel snel draait op een brak gebouwd systeem met data die je voor geen meter kunt vertrouwen. AI gaat dat echt niet voor je oplossen. AI zorgt er in zo een geval alleen maar voor dat je op industriële schaal de mist in gaat.  

De meeste bedrijven rennen blind af op die snelle zakelijke winst en lopen vervolgens allemaal stuk op AI output die geen sterveling durft te vertrouwen. Voorsprong zit hem namelijk helemaal niet in simpelweg sneller werken. De echte voorsprong is het fundament dat je bouwt om die snelheid ook veilig in de praktijk te brengen.

_{SOURCES & REFERENCES}

1. _{DORA: Accelerate State of DevOps Report 2024 (Google Cloud / DORA), Figures 7 and 10. Per +25% AI adoption: +2.1% productivity, −1.5% delivery throughput, −7.2% delivery stability — verified against the report PDF.}
2. _{DX: Highlights from the 2024 DORA Report: the "verification tax" and team-level outcomes.}
3. _{Baseflow: AI-native Product Development Adoption Model (internal): the six stages, the anchor, and the guardrails backbone.}
4. _{Model landscape context: Gartner, Maturity Model for AI-Native Software Engineering (2026); SEI / Accenture, AI Adoption Maturity Model (2026).}
5. _{Technique: Martin Fowler, StranglerFigApplication; Michael Feathers, Working Effectively with Legacy Code (characterization tests).}
6. _{Linux kernel:" Toward a policy for machine-learning tools in kernel development (LWN, 2025): AI-assisted patches welcome, purely machine-generated ones barred, humans accountable; review named as AI's best use.}
7. _{Booking.com throughput figure: Laura Tacho, session on the transformation toward an AI-native SDLC, Sonar Summit 2026 (YouTube); consistent with the DX summary above.}