Iedereen die over AI en code review schrijft, citeert hetzelfde cijfer. De mediane reviewtijd van een pull request is met 441% gestegen.
Het wordt toegeschreven aan DORA. Daar komt het niet vandaan, en van de drie reviewgetallen in het rapport waar het wél vandaan komt, is dit het minst bruikbare.
Van wie het cijfer echt is
De 441% staat in het AI Engineering Report 2026 van Faros AI, met als ondertitel The Acceleration Whiplash. Twee jaar telemetrie van 22.000 developers verspreid over ruim 4.000 teams, waarbij per organisatie de periode met de laagste AI-adoptie is afgezet tegen de eigen periode met de hoogste.
Op de pagina van DORA staat niets van dien aard. Dat is een enquête onder 1.110 respondenten. Daaruit komt dat 90% van de technologieprofessionals AI op het werk gebruikt, dat ruim 80% denkt er productiever van te worden, en dat hogere adoptie samenhangt met zowel meer doorstroom als meer instabiliteit. Prima onderzoek, en een heel ander soort bewijs. Een enquête legt vast wat developers zeggen. Telemetrie legt vast wat hun git-historie deed.
Dit reken ik mezelf aan. In mijn stuk over wanneer je werk beter zelf houdt schreef ik deze cijfers aan DORA toe, met een link naar dora.dev. Dat klopte niet en het is inmiddels rechtgezet.
Het gaat hier om meer dan muggenziften. Als je in een planningsoverleg om reviewcapaciteit vraagt, is "uit een enquête blijkt dat mensen vinden dat reviews trager gaan" iets heel anders dan "telemetrie over vierduizend teams meet een stijging van 441,5% in de mediane tijd in review", en maar één van de twee overleeft een sceptische directeur.
Drie getallen, en het beroemdste zegt het minst
Faros splitst de review-pipeline op in drie metingen:
| Meting | Verandering |
|---|---|
| Mediane tijd tot de eerste review | +156,6% |
| Gemiddelde tijd in review | +199,6% |
| Mediane tijd in review | +441,5% |
Iedereen citeert de derde.
De eerste is het getal dat ik voor een manager op tafel zou leggen. Tijd tot de eerste review is wachttijd in de rij. Het is de tijd tussen het openen van een pull request en het moment dat er überhaupt een mens naar kijkt. Dat getal staat helemaal los van hoe moeilijk de code leest, want op dat moment heeft nog niemand er een regel van gezien.
Een stijging van 156,6% in die wachttijd betekent dat je reviewers al overbelast zijn voordat de moeilijkheidsgraad van welke PR dan ook meespeelt. Daar helpt betere reviewtooling niet tegen. Alleen meer reviewcapaciteit of minder binnenkomend werk brengt dat getal omlaag.
Kleinere PR's helpen, maar daar houdt het verhaal niet op
Het advies dat standaard bij de 441% hoort, is: schrijf kleinere pull requests. De gemiddelde PR-grootte is met 51,3% gestegen, dus daar zit iets in.
Lees wel even de voetnoot. Faros merkt op dat die 51,3% lager ligt dan de 154% uit hun vorige rapport, en zegt er eerlijk bij dat "the two datasets differ in size, composition, and time period, so direct comparison should be treated as directional".
Ook als je het alleen als richting leest, wringt het met het simpele verhaal. De groei in PR-grootte lijkt af te vlakken terwijl de reviewtijd juist hard de andere kant op gaat. Er gaat dus tijd van je reviewers op aan iets anders dan het aantal regels.
De bevinding die onder de kop verdween
Faros geeft zelf een verklaring, en dat is de nuttigste zin uit het hele rapport:
the code arriving for review is often not review-ready. Reviewers are not just assessing more code, they appear to be working harder to bring that code up to a standard it should have met before the PR was opened.
Daarmee kantelt het hele probleem. De reviewwachtrij was de plek waar code werd gecontroleerd en is de plek geworden waar code wordt afgemaakt.
Het rapport benoemt ook het mechanisme. AI-code is vaak "superficially convincing: idiomatic, well-named, stylistically consistent with the surrounding codebase". De structurele en logische fouten zitten onder dat oppervlak, en om die te vinden moet je aandachtig lezen, nadenken over de bedoeling en reconstrueren welk probleem de code moest oplossen. Faros noemt dat "slow, expensive cognitive work" en wijst aan wie het uiteindelijk doet: je senior engineers, precies de mensen die je hoopte vrij te spelen.
De rest van de cijfers volgt daaruit. Merges zonder enige review zijn met 31,3% toegenomen. Bugs per developer stegen met 54%. Het aantal incidenten per PR ging met 242,7% omhoog. En code churn, gemeten als verwijderde regels tegenover toegevoegde regels in gemergede code per kwartaal, steeg met 861%.
Bij die laatste loont het om even stil te staan. Churn van die omvang betekent dat een flink deel van wat er gemerged werd kort daarna alweer weg was, waardoor elk doorstroomcijfer in datzelfde rapport een te rooskleurig beeld geeft van wat er werkelijk bleef staan.
Wat dit verandert aan je werkwijze
Zorg dat de code review-klaar is voordat hij een pull request wordt. Dat is de conclusie van het rapport zelf en het levert hier het meeste op. Elke controle die een reviewer zou draaien, draai je eerst: de testsuite, de linter, een eigen leesronde over de volledige diff. Een agent die een PR opent zodra de code compileert, heeft het onaffe werk verplaatst naar andermans wachtrij, waar het seniortijd kost in plaats van agenttijd.
Keur het plan goed zolang dat nog goedkoop is. Beslissen wat er gebouwd wordt is ook een review, en dat doen voordat de diff bestaat kost minuten in plaats van uren. Plan mode wordt meestal verkocht als planningsfunctie, terwijl de echte winst is dat de diff al vorm heeft als hij binnenkomt en je reviewer de bedoeling niet uit 900 regels hoeft af te leiden.
Werk de wachtrij af op risico, niet op volgorde van binnenkomst. Omdat het eerste getal wachttijd is, zit de winst in welke PR als eerste wordt opgepakt. Een migratie, een wijziging in authenticatie en een permissiegrens verdienen vandaag een senior reviewer. Een dependency-bump kan wachten.
Kijk wat "gereviewd" in je eigen cijfers betekent. Als een bot opmerkingen achterlaat bij een pull request en die wordt gemerged, telt dat in de meeste dashboards als gereviewd. De bureaucratie van bots is wat je daarvan op schaal krijgt: een bot die een bot beoordeelt, met aan geen van beide kanten iemand die achteraf uitlegt waarom. Het is de moeite waard om te weten bij welke reviews er een mens aan te pas kwam. En als er wel een mens bij zit: waar je in de pull request van een agent op let is iets anders dan wat je bij een collega nakijkt.
Helemaal nieuw is het probleem niet. Je 10x-developer zit vast in een 0,1x-pipeline voerde de structurele versie van dit argument aan: code werd goedkoop, de machinerie die code in waarde omzet niet, en dus verschoof de beperking naar verderop in de keten. Faros meet nu waar die terechtkwam.
De wachtrij is inmiddels de plek waar code wordt afgemaakt. Dat werk moest sowieso ergens gebeuren. Op dit moment gebeurt het op de duurste plek die je hebt, door de mensen die je daar het minst kunt missen, en het staat geboekt als review.