AI integreren in softwareontwikkeling: van losse tools naar proces

Je team heeft Copilot-licenties. Misschien gebruikt de helft ook nog Cursor of Claude Code erbij. Iedereen tikt sneller, iedereen is enthousiast, en toch staat de teller voor wat je écht oplevert ongeveer stil. De doorlooptijd is niet korter geworden. De productie valt niet vaker uit dan vroeger, maar ook niet minder. En dan, in de sprintreview, vraagt iemand: "wat levert AI ons nou eigenlijk op?" Het blijft even stil. Iedereen tikt sneller, niemand kan het in een cijfer vangen.

Herkenbaar? Je bent niet alleen. Het grootste onderzoek naar AI in development, het DORA-rapport van 2025 met bijna 5.000 deelnemers, laat zien dat 90% AI op het werk gebruikt. Dat is bijna iedereen. In Nederland gebruikt op dit moment volgens Capgemini 46% van de software engineers generatieve AI, en dat groeit hard. Maar slechts 11% van de organisaties heeft het echt geïntegreerd in hun werkwijze.

En daar zit het probleem. Tussen "iedereen gebruikt het" en "het is ingebouwd in hoe we werken" gaapt een gat. Dat gat dichten is geen kwestie van betere tools kopen. Het is een kwestie van proces.

Waarom losse Copilot-licenties geen strategie zijn

Er is één zin uit het DORA-rapport die je moet onthouden: "AI doesn't fix a team; it amplifies what's already there." AI repareert geen team, het versterkt wat er al is. Heb je een team met sterke tests, schone versiebeheerpraktijken en snelle feedback? Dan maakt AI dat beter. Heb je chaos? Dan maakt AI dat sneller chaotisch.

Het bewijs is hard. DORA vond een negatieve relatie tussen AI-adoptie en de stabiliteit van je software-levering, behalve waar sterke controles aanwezig zijn. Met andere woorden: zet je AI los op een team zonder goed vangnet, dan lever je sneller, maar ook brozer. Meer haastwerk dat in productie omvalt.

Dit is precies waarom een stapel individuele licenties geen strategie is. Een licentie geeft een developer gereedschap. Het zegt niets over wanneer je dat gereedschap inzet, hoe je de output controleert, en hoe je weet of het werkt. Dat zijn afspraken op teamniveau. Die maak je niet per ongeluk.

Dit artikel gaat specifiek over het ontwikkelteam. Wil je het bredere plaatje voor je hele bedrijf, met afdelingen als marketing, HR en sales erbij? Lees dan hoe je AI breder in je organisatie implementeert. Hier zoomen we in op de code.

Welke AI-tool voor welke taak?

De meeste teams gebruiken AI op gevoel. Je opent wat je gewend bent en typt erin los. Handiger is om per taak te kiezen, want AI-gereedschap valt grofweg in drie soorten. Dit is een conceptuele indeling, geen merkenlijst, en die houdt stand ook als de tools veranderen.

Hoe meer een tool zelf doet, hoe meer toezicht je nodig hebt. Autocomplete kun je grotendeels vertrouwen, want je ziet elke regel langskomen en keurt hem in je hoofd direct goed of af. Een autonome agent die zelf tien bestanden aanpast, vraagt om een serieuze review achteraf. Niet omdat de agent dom is, maar omdat jij niet hebt gezien hoe hij tot het resultaat kwam.

Per taak kiezen, niet per gewoonte

De simpele regel: kies het lichtste gereedschap dat de klus aankan. Voor een bekende, kleine wijziging is autocomplete genoeg. Voor "leg uit waarom deze test faalt" pak je de chat. Voor een grotere refactor die je goed kunt afbakenen, zet je een agent in en plan je daarna tijd voor de review.

En hier gaat het meestal mis: teams kiezen niet, ze grijpen. De agent-fan zet een autonome agent op een wijziging van twee regels en zit daarna tien minuten een diff te controleren die hij in dertig seconden zelf had getikt. De autocomplete-fan vraagt zijn editor om een architectuur te verzinnen en snapt niet waarom het resultaat rammelt. Niet de tool faalt, de keuze faalt. Het lichtste gereedschap dat de klus aankan, dat is de hele kunst.

Wat mij opvalt bij teams: zodra dit een afspraak wordt in plaats van een gewoonte, daalt de frustratie. Mensen verwachten niet meer dat autocomplete een architectuur verzint, en ze gebruiken een agent niet voor iets wat in tien seconden zelf te tikken was. Maar welk gereedschap je ook kiest, er komt een moment waarop de code terugkomt en iemand moet beoordelen of die deugt. En juist daar verschuift het werk het meest.

Code-reviewbeleid voor AI-gegenereerde code

In de teams die ik begeleid is dit de plek waar het echt schuurt. Vroeger schreef een mens code en controleerde een andere mens of die klopte. Nu schrijft AI een groot deel van de code, en dan moet die nog steeds gecontroleerd worden. Maar je controleert iets anders.

Google-engineer Addy Osmani beschrijft die verschuiving goed in Code Review in the Age of AI. Vroeger keek je vooral naar de regels: klopt de syntax, zit er een typefout in, mist er een puntkomma. Dat soort dingen vangt de machine zelf al af. Nu kijk je naar de intentie en de architectuur. Doet deze code wat we bedoelden? Past het bij hoe de rest van het systeem werkt? Klopt het verhaal achter de code, niet alleen de code zelf?

GitHub zegt zonder omwegen dat de mens eindverantwoordelijk blijft. In de officiële documentatie over Copilot code review staat letterlijk dat Copilot niet gegarandeerd alle problemen vindt, dat je de feedback altijd zorgvuldig moet valideren, en dat je het moet aanvullen met een menselijke review. AI is dus een eerste pass, geen laatste oordeel.

Wat verandert er aan de reviewer-rol

Zie AI als de collega die snel een eerste blik werpt. Die vangt de domme dingen, wijst op een paar zwakke plekken, en maakt jouw review lichter. Maar de beslissing om iets goed te keuren blijft van de mens. AI levert feedback, jij keurt goed.

De tooling rijpt hier snel. Op dit moment is er bijvoorbeeld een GitHub-functie in preview waarmee teams de diepte van de review kunnen instellen en eigen kennis kunnen koppelen. Handig, maar het verandert het principe niet. Hoe slim de eerste pass ook wordt, de goedkeuring blijft mensenwerk.

AI in je CI-pijplijn

Reviews zijn één vangnet. Je CI/CD-pijplijn is het tweede, en juist nu AI meer code produceert, wordt dat vangnet belangrijker. Want als de hoeveelheid code omhoog gaat, gaat de hoeveelheid mogelijke fouten mee omhoog.

Een geautomatiseerde pijplijn vangt veel van wat een vermoeide reviewer mist: draaien de tests, klopt de stijl, zitten er bekende kwetsbaarheden in, breekt er iets verderop. Dit is precies een van de sterke controles waar DORA op wijst. Sterke tests en snel terugkoppelen zijn het verschil tussen AI die je helpt en AI die je instabiliteit oplevert.

Een mooie vuistregel komt uit de best practices van Claude Code: "Never send an LLM to do a linter's job." Stuur geen taalmodel op een klus die een linter beter, sneller en goedkoper doet. Een LLM is geweldig voor nadenken en ontwerpen. Voor het strak afdwingen van regels gebruik je deterministische tools die altijd hetzelfde antwoord geven. Die twee vullen elkaar aan, ze vervangen elkaar niet. Het omgekeerde zie je trouwens net zo vaak: teams die hun hele kwaliteitsbewaking in de review proppen omdat de CI nog uit 2019 stamt. Dan stapelt AI code op een vangnet met gaten, en merk je de breuk pas in productie.

Zo werkt het twee kanten op: je vangt fouten vroeg en je ontlast je reviewers. Hoe meer de machine automatisch afhandelt, hoe meer aandacht er overblijft voor de dingen waar een mens echt nodig is.

Kennis borgen: conventies vastleggen die AI snapt

Hier komt iets wat bijna geen enkel team goed doet, terwijl het misschien wel de grootste winst geeft. AI-tools weten niets van jouw codebase, jouw afspraken, jouw stijl. Tenzij je het ze vertelt. En als je het ze elke keer opnieuw moet vertellen, ben je het voordeel kwijt.

De oplossing is verrassend simpel: leg je conventies vast in een bestand dat zowel mensen als AI lezen. De best practices van Claude Code noemen dit een CLAUDE.md, en het idee werkt breder. GitHub gebruikt vergelijkbare instructiebestanden, korte stukjes natuurlijke taal in de repo die de AI meegeeft hoe jullie werken.

Een paar regels maken dit goed in plaats van rommelig:

• •Check het bestand in git. Dan kan het hele team eraan bijdragen en groeit het mee met jullie afspraken, in plaats van dat iedereen z'n eigen versie heeft.
• •Hou het kort. De test uit de docs is scherp: zou het weglaten van deze regel ervoor zorgen dat de AI fouten maakt? Zo nee, weg ermee. Lange instructiebestanden worden genegeerd, door mensen én machines.
• •Splits kennis die er soms toe doet af in losse stukken (skills), zodat je hoofdbestand schoon blijft.
• •Wat altijd moet gebeuren, automatiseer je met hooks of CI, niet met een instructie waar de AI zich aan moet herinneren.

Zo'n bestand betaalt zich twee keer terug. Een nieuwe collega leest het en snapt binnen tien minuten hoe jullie werken. De AI leest hetzelfde en houdt zich aan jullie stijl. Je hebt je teamkennis één keer opgeschreven en twee keer geoogst. Wil je dit concreet zien werken, dan laten we het je graag zien bij conventies vastleggen met Claude Code.

Meten of het werkt (zonder schijnzekerheid)

Nu het moeilijkste deel, en meteen het belangrijkste. Hoe weet je of dit alles iets oplevert? Ik vraag teams nooit of AI sneller voelt. Dat antwoord is altijd ja, en het zegt niets.

Het bewijs hiervoor is bijna ongemakkelijk. Onderzoeksinstituut METR deed een gecontroleerd experiment en liet zestien ervaren developers 246 taken doen. Met AI waren ze 19% langzamer, terwijl ze 20% sneller dachten te zijn. Vooraf hadden ze zelfs verwacht 24% sneller te worden.

Belangrijk om dit eerlijk te framen, want het is geen anti-AI-verhaal. METR zegt zelf nadrukkelijk dat dit géén bewijs is dat AI de meeste developers niet versnelt. Het ging om ervaren developers, in volwassen codebases met hoge kwaliteitseisen, met de tools van begin 2025. In een andere situatie kan het anders uitpakken. De les is niet "AI is traag". De les is dat zelfs experts er fors naast zitten als ze op hun gevoel afgaan.

Dus meet je het. Niet met fancy nieuwe dashboards, maar met de signalen die teams al jaren gebruiken om hun gezondheid te peilen. Denk conceptueel aan vier dingen:

• •Doorlooptijd: hoe lang van idee tot in productie?
• •Hoe vaak je levert: gaat het tempo van releases omhoog of omlaag?
• •Hoe vaak het misgaat: veroorzaken nieuwe releases vaker problemen?
• •Hoe snel je herstelt: als er iets stuk gaat, hoe snel staat het weer?

Dit zijn de zogeheten DORA-metrics, het standaardraamwerk om software-levering te meten. De exacte definities vind je het beste op dora.dev zelf. De kern is dit: snelheid en stabiliteit horen samen gemeten te worden. Want sneller leveren is waardeloos als je vier keer zo vaak iets sloopt. Pas als je beide volgt, zie je of AI je echt vooruithelpt of alleen maar harder laat rennen.

Valkuilen: review-moeheid en blind vertrouwen

Twee gevaren komen er bovenop, en ze versterken elkaar.

Het eerste is review-moeheid. Als AI veel code produceert, moet er veel gecontroleerd worden. En de mens is daar slecht in over lange tijd. Atomic Robot beschrijft drie mechanismen die samen toeslaan: je oplettendheid zakt weg bij lange controletaken, je gaat de machine te makkelijk vertrouwen, en het constante wisselen van context sloopt je focus. Na de twintigste AI-pull request van de dag lees je niet meer echt. Je scrollt en klikt goedkeuren.

Het tweede is blind vertrouwen. De cijfers van Clutch zijn confronterend: 96% van de developers gelooft dat AI-code niet volledig correct is. Iedereen wéét het dus. Maar slechts 48% controleert die code altijd vóór een commit. Meer dan de helft laat dus regelmatig code door die ze zelf niet helemaal vertrouwen.

Dit is de automation complacency waar Atomic Robot voor waarschuwt, het onderliggende fenomeen heet ook wel automation bias: de neiging om wat een machine zegt klakkeloos over te nemen, juist omdat het van een machine komt. En het is precies de reden waarom je processen nodig hebt in plaats van goede voornemens. Een afspraak dat AI-code altijd door CI én een menselijke review gaat, beschermt je tegen de momenten waarop je moe bent en even niet oplet. En die momenten komen. Bij iedereen.

Zo begin je deze maand

Het verleidelijke aan dit soort verhalen is dat je denkt: dat is een heel project. Dat is het niet. Begin klein, meetbaar, en met één ding tegelijk.

Kies één team en één taak. Bijvoorbeeld: vanaf nu krijgt elke pull request eerst een AI-review als eerste pass, daarna een mens die goedkeurt. Niks meer. Schrijf in één kort bestand in je repo op hoe jullie werken, zodat de AI jullie stijl kent. Zet een paar basismetingen aan zodat je over een maand kunt terugkijken, niet terugraden.

Laat het een maand draaien. Kijk dan naar de cijfers, niet naar het gevoel. Werkt het? Breid uit naar een tweede taak of een tweede team. Werkt het niet? Mooi, dat weet je nu zwart op wit, en je past het aan. Zo bouw je een werkwijze die staat, in plaats van een stapel licenties die hoopt.

Eén op de zes Nederlandse bedrijven gebruikt op dit moment AI, ongeveer een verdubbeling in twee jaar, met de sector informatie en communicatie voorop op 54% (CBS). De adoptie raast door. De teams die straks voorop lopen, zijn niet degenen met de meeste tools. Het zijn degenen die er een proces omheen bouwden toen de rest nog losse licenties uitdeelde.

Wil je je team hierin meenemen, met jullie eigen codebase, jullie eigen afspraken en een aanpak die op meten leunt in plaats van op hoop? Dan kun je je team structureel opleiden in AI een goede volgende stap maken.

Bronnen

• •DORA / Google Cloud — 2025 State of AI-assisted Software Development
• •DORA — 2025-rapport
• •DORA — AI Capabilities Model
• •METR — Measuring the Impact of Early-2025 AI on Experienced OS Developer Productivity
• •Addy Osmani — Code Review in the Age of AI
• •Atomic Robot — AI Writes Better Code. We're Getting Worse at Reviewing It.
• •Clutch — Blind Trust in AI
• •GitHub Docs — About Copilot code review
• •GitHub Changelog — Shape Copilot code review around your team
• •Claude Code — Best practices
• •CBS — Hoeveel bedrijven gebruiken AI? (2025)
• •Capgemini NL — Generatieve AI in Softwareontwikkeling

Veelgestelde vragen

Welke AI-tool gebruik je voor welke taak in development?

Kies het lichtste gereedschap dat de klus aankan. Autocomplete is goed voor bekend werk en boilerplate, waar je elke regel ziet langskomen. Een chat of assistent helpt bij ontwerpen, debuggen en uitleg. Een autonome agent zet je in voor grotere klussen over meerdere bestanden. Hoe meer een tool zelf doet, hoe meer toezicht je nodig hebt: een agent die tien bestanden aanpast, vraagt om een serieuze review achteraf.

Hoe review je code die door AI is gegenereerd?

Behandel AI als een eerste pass, niet als eindoordeel. De machine vangt de kleine fouten; de mens controleert de intentie en de architectuur: doet de code wat we bedoelden en past het bij de rest van het systeem? GitHub stelt het zelf zo dat je AI-feedback altijd zorgvuldig moet valideren en aanvullen met een menselijke review. AI levert feedback, een mens keurt goed. Combineer dit met geautomatiseerde checks in je CI-pijplijn.

Maakt AI developers echt sneller?

Niet automatisch, en gevoel is geen betrouwbare maat. In een gecontroleerd onderzoek van METR waren ervaren developers 19% langzamer met AI, terwijl ze dachten 20% sneller te zijn. METR benadrukt dat dit geen algemeen bewijs is dat AI de meeste developers niet versnelt: het ging om ervaren devs in volwassen codebases met hoge eisen en de tools van begin 2025. De les is om te meten in plaats van te vertrouwen op je onderbuik.

Hoe meet je of AI in je dev-team werkt?

Meet snelheid en stabiliteit samen, niet apart. Kijk conceptueel naar doorlooptijd (idee tot productie), hoe vaak je levert, hoe vaak releases iets breken en hoe snel je herstelt. Dit zijn de DORA-metrics. Sneller leveren is waardeloos als je vaker dingen sloopt, dus alleen door beide te volgen zie je of AI je echt vooruithelpt of alleen harder laat rennen. De exacte definities staan op dora.dev.

Hoe leg je AI-conventies voor je team vast?

Schrijf je werkwijze in een kort instructiebestand in je repo, zoals een CLAUDE.md, dat zowel mensen als AI lezen. Check het in git zodat het hele team bijdraagt en het meegroeit. Hou het kort: zou het weglaten van een regel de AI fouten laten maken? Zo nee, weg ermee. Wat altijd moet gebeuren automatiseer je met hooks of CI, niet met een instructie. Zo borg je teamkennis één keer en oogst je hem twee keer.