Ik schrijf de meeste code voor deze site niet meer zelf. Een agent doet het voorstel, ik lees het na, en er staan zes controles tussen die aanroep en de deploy. Die controles zijn er niet uit voorzorg gekomen. Elke gate is toegevoegd nadat er iets doorheen was geglipt.
Dat het schrijven sneller gaat, staat vast. De vraag die in de discussie meestal ontbreekt gaat over wat er daarna gebeurt, in de uren die niemand meet omdat ze verspreid liggen over review, debuggen en de incidenten van volgende maand.
Er zijn inmiddels een paar metingen die daar wél naar kijken. Ik heb ze alle vier bij de bron opgehaald, want ik kreeg ze aangeleverd via onderzoeksrapporten en die bleken bij eerdere stukken de strekking van een bron te kunnen omdraaien.
De meting die iedereen citeert, en wat er daarna gebeurde
METR deed in de eerste helft van 2025 een gerandomiseerde studie met 16 ervaren open-source-ontwikkelaars. Ze werkten aan 246 echte taken in hun eigen repositories, gemiddeld twee uur per taak, en per taak werd geloot of AI-gereedschap wel of niet was toegestaan. De uitkomst haalde overal de koppen: met AI duurden de taken 19 procent langer, terwijl dezelfde mensen achteraf dachten dat ze 20 procent sneller waren geweest.
Wat er zelden bij staat, is wat METR in februari 2026 zelf publiceerde. Ze begonnen in augustus 2025 een nieuw experiment met nieuwere modellen en een grotere groep, en de resultaten wijzen de andere kant op. Voor de deelnemers uit de oorspronkelijke groep komt de schatting nu uit op 18 procent sneller, met een betrouwbaarheidsinterval van 38 procent sneller tot 9 procent langzamer. Bij nieuw geworven ontwikkelaars is dat 4 procent sneller, tussen 15 procent sneller en 9 procent langzamer. METR schrijft er zelf bij dat hun data door zelfselectie maar zwak bewijs levert voor die versnelling, en dat ze de opzet daarom veranderen.
Wie de 19 procent nog steeds als knuppel gebruikt, citeert dus gereedschap uit februari tot juni 2025 en negeert wat de onderzoekers erna zelf hebben opgeschreven. Eerlijker is een smaller gebruik van die studie. Hij laat zien dat de inschatting van ontwikkelaars over hun eigen snelheid in beide richtingen onbetrouwbaar is.
Waar de tijd naartoe verschuift
De interessantere cijfers komen uit telemetrie in plaats van uit een vragenlijst. Faros AI publiceerde in 2026 een rapport op basis van meetdata van ongeveer 22.000 ontwikkelaars, waarin teams met hoge AI-adoptie worden vergeleken met teams die er weinig mee doen.
De winst is er, en die is niet klein:
| Wat er omhoog gaat | Verandering |
|---|---|
| Afgeronde epics per ontwikkelaar | +66,2% |
| Taken per ontwikkelaar | +33,7% |
| Samengevoegde pull requests per ontwikkelaar | +16,2% |
En in dezelfde dataset, bij dezelfde teams:
| Wat er ook omhoog gaat | Verandering |
|---|---|
| Mediane tijd in code review | +441,5% |
| Mediane wachttijd tot de eerste review | +156,6% |
| Pull requests die zonder enige review worden samengevoegd | +31,3% |
| Incidenten per pull request | +242,7% |
| Bugs per ontwikkelaar | +54% |
| Code churn | +861% |
AI verplaatst de flessenhals naar de plek waar mensen zitten. Schrijven werd goedkoop, lezen niet, en review is het enige moment in de keten waar iemand nog echt begrijpt wat er gebeurt.
Twee dingen om hierbij te weten. Dit is telemetrie van een leverancier die review-gereedschap verkoopt, geen gecontroleerd experiment, dus causaliteit is een interpretatie en geen meting. En één van de meest dramatische cijfers uit het rapport, een toename van 480,4 procent in doorlooptijd van commit tot productie, is volgens de tekst zelf op maar 10 procent van de dataset gemeten. Dat cijfer heb ik daarom niet in de tabel gezet.
Wat er in de code zelf verandert
Veracode liet in 2025 meer dan 100 taalmodellen dezelfde programmeeropdrachten uitvoeren in Java, Python, C# en JavaScript, en toetste de uitkomst op beveiliging. In 45 procent van de gevallen introduceerde de gegenereerde code een kwetsbaarheid uit de OWASP Top 10. Java was het slechtst met een faalpercentage van 72 procent, JavaScript 43, C# 45 en Python 38. Bij cross-site scripting faalde 86 procent van de relevante voorbeelden.
Belangrijk voor de interpretatie: dit meet wat modellen produceren op een kale opdracht, niet wat er na review in productie belandt. Het zegt iets over de grondstof, niet over het eindproduct. Precies daarom telt wat er tussen die twee in staat.
GitClear keek naar de code zelf, over vijf jaar en 211 miljoen gewijzigde regels uit repositories van onder meer Google, Microsoft en Meta. Gekopieerde blokken namen sterk toe, en in 2024 overtrof gekopieerde code voor het eerst verplaatste code. Dat laatste is het signaal dat mij het meest zegt: verplaatsen betekent dat iemand bestaande code hergebruikt, kopiëren betekent dat er een tweede exemplaar bijkomt dat voortaan apart onderhouden moet worden. De koppeling met AI is hier een gevolgtrekking uit gelijktijdigheid, niet uit een gecontroleerde vergelijking.
De kanttekening
De besparing en de rekening staan in verschillende budgetten. De tijd die je wint bij het schrijven is zichtbaar, valt in dezelfde week en is van dezelfde persoon. De tijd die je verliest ligt bij een reviewer, bij de dienst die het incident afhandelt, en bij degene die over een jaar moet uitzoeken waarom iets zo gebouwd is. Wie alleen het eerste meet, meet zichzelf rijk.
Review is een menselijke bezigheid geworden met een machinaal aanbod. De aantallen kloppen niet meer: meer pull requests, groter, sneller geproduceerd, beoordeeld door hetzelfde aantal mensen. Dat 31 procent meer wijzigingen zonder enige review wordt samengevoegd is waarschijnlijk geen besluit maar een gevolg. Niemand heeft besloten de poort open te zetten.
Wat er van de ontwikkelaar wegstroomt is het lezen. Code die vloeiend leest en door de bestaande tests komt, ziet er af als hij het niet is. Dat is een ander soort fout dan een syntaxfout, want die laatste valt om. Deze wacht.
Wat ik zelf doe
In deze site staan zes controles die de deploy blokkeren, en ze zijn allemaal geschreven ná een misser. Eentje kwam er nadat een artikel de hele redactionele keten had doorlopen en er nog vier patronen in stonden die een regex had kunnen vangen. Een andere na drie reviewronden waarin steeds hetzelfde soort detail opdook: een plausibel getal zonder grond.
Dat is de vorm die voor mij werkt. Een instructie wordt vergeten, een gate niet. En elke gate is klein, want een controle die je niet kunt uitleggen ga je uitzetten.
Verder houd ik wijzigingen expres klein. Niet omdat kleine wijzigingen beter zijn, maar omdat ik ze nog kan lezen. Op het moment dat ik een voorstel doorbladerkijk in plaats van lees, heb ik de winst al ingeleverd zonder het te merken.
Veelgestelde vragen
Betekent dit dat AI-gereedschap ontwikkelaars langzamer maakt?
Nee, en dat is precies de valkuil van de bekendste meting. De 19 procent vertraging bij METR gaat over gereedschap uit begin 2025, en dezelfde onderzoekers meten met nieuwere modellen eerder versnelling, al noemen ze hun eigen bewijs daarvoor zwak. Wat consistent blijft over alle metingen heen, is dat de winst bij het schrijven zit en de kosten bij het beoordelen.
Hoe weet ik of dit bij mijn team ook speelt?
Kijk naar de doorlooptijd van een pull request in plaats van naar het aantal. Twee getallen zijn genoeg om te beginnen: hoeveel tijd zit er tussen openen en de eerste reactie van een reviewer, en welk deel wordt samengevoegd zonder dat iemand ernaar heeft gekeken. Gaat het eerste omhoog terwijl het aantal wijzigingen ook stijgt, dan schuift de last precies zoals in de telemetrie hierboven.
Wat is de goedkoopste maatregel?
Kleinere wijzigingen, en een controle die automatisch draait voor de dingen die je toch elke keer nakijkt. Het tweede kost eenmalig werk en scheelt daarna elke review aandacht, en aandacht is het schaarse goed geworden, niet tijd.
Bronnen
- METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, 10 juli 2025, plus het bijbehorende paper.
- METR, “We are Changing our Developer Productivity Experiment Design”, 24 februari 2026.
- Faros AI, “AI Engineering Report 2026: The Acceleration Whiplash”, 2026.
- Veracode, “2025 GenAI Code Security Report”, blogsamenvatting van 30 juli 2025.
- GitClear, “AI Copilot Code Quality: 2025 Look Back at 12 Months of Data”, over 211 miljoen gewijzigde regels uit 2020 tot en met 2024.
Gecontroleerd op 21 augustus 2026. Alle cijfers hierboven heb ik bij de bron zelf nagelezen en niet uit een samenvatting overgenomen. Wat ik niet heb kunnen verifiëren en daarom heb weggelaten: cijfers van Apiiro over kwetsbaarheden in AI-code, waarvan de pagina een 403 gaf, en de cijfers over brutomarges van AI-bedrijven die ik alleen via secundaire bronnen zag. Twee van de vier bronnen komen van leveranciers die gereedschap in dit domein verkopen, en dat is een belang dat je moet meewegen: hun telemetrie is echt, hun keuze welke snede ervan gepubliceerd wordt niet neutraal.