Vraag een developer hoeveel sneller AI hem heeft gemaakt en je krijgt een factor te horen. Vraag dezelfde developer hoeveel meer waarde hij oplevert en het getal zakt, meestal tot ongeveer de helft.
Dat gat komt uit één enquête.
METR hield hem tussen februari en april 2026 onder 349 mensen in technische beroepen: 87 software engineers, 71 onderzoekers, 129 academici en promovendi, 48 oprichters en managers. De uitkomst is een mediane zelfgerapporteerde snelheidswinst van 3x, en een mediane zelfgerapporteerde toename in de waarde van het werk van 1,4 tot 2x.
Dezelfde mensen. Hetzelfde gereedschap. Dezelfde week. Eén vraag over snelheid, één over waarde, en een factor twee ertussen.
Moet je voor je werk inschatten hoe lang iets gaat duren, dan is dat gat je hele probleem.
Het getal dat iedereen aanhaalt is het ruimste
Drie dagen eerder publiceerde dezelfde club de verklaring voor dat gat. Task substitution and uplift, van Tom Cunningham en Parker Whitfill, laat zien dat er niet één grootheid bestaat die "hoeveel sneller AI mij maakt" heet. Het zijn er drie, en ze staan in deze volgorde:
uplift on old tasks ≤ uplift in value ≤ uplift on new tasks
Oude taken zijn het werk dat je in 2021 zou hebben gedaan. Nieuwe taken zijn het werk dat je nu kiest, in de wetenschap dat er een agent klaarstaat. Waarde is wat je er werkelijk aan overhoudt.
Hun rekenvoorbeeld is met opzet klein. Een engineer verdeelt een werkdag van acht uur over documenten schrijven en pull requests maken, een uur per stuk. AI halveert de kosten van een PR en doet niets voor documenten. Meet je dat op de oude takenlijst, dan is de winst 33%. Meet je het op de nieuwe, waarin de engineer nu acht PR's schrijft in plaats van vier, dan is het 50%. De waarde ligt daar ergens tussenin.
Vergroot je het verschil tussen die twee bezigheden, dan lopen de grenzen ver uit elkaar. In hun extremere geval, waarin een PR van vijf uur naar één uur gaat, komen de drie maten uit op +67%, +124% en +200%.
Drie getallen, één engineer, één middag. Alle drie eerlijk.
En dit is wat dat met je schatting doet. Zegt iemand dat zijn team 3x sneller is, dan rapporteert hij vrijwel zeker de winst op nieuwe taken, want dat is het getal dat je als mens kunt voelen. Het is ook de ruimste van de drie, en dat is precies waar de auteurs op wijzen.
Ze houden een slag om de arm, en dat moet jij ook doen: de volgorde geldt onder vereenvoudigende aannames, en in hun eigen voetnoot staat dat hij in de praktijk kan omdraaien. Wat je er wel uit haalt, is op welke van de drie vragen je antwoord krijgt. De deelnemers aan wie naar waarde werd gevraagd in plaats van naar snelheid, kwamen uit op 1,4 tot 2x. Het waren dezelfde mensen.
Iedereen in die enquête antwoordde eerlijk. Ze beantwoordden alleen een andere vraag dan die jij beantwoord wilt hebben op het moment dat je een datum toezegt.
Je doet het oude werk niet sneller
Dit is het deel dat inschatten echt sloopt, en het is erger dan een meetfout.
Een schatting is een vergelijking. Je zegt: dit nieuwe ding lijkt op dat oude ding, en dat oude ding kostte twee weken. De hele methode staat of valt met de vergelijkbaarheid van die twee.
Taakverschuiving haalt die weg. Welke factor je er ook op loslaat, je laat hem los op een takenlijst die je in 2024 nooit had opgeschreven, omdat de helft ervan niet uit kon.
Het dashboard waar niemand om vroeg. De refactor door veertig bestanden. De tweede implementatie die je bouwde om hem met de eerste te vergelijken. Het prototype dat donderdag de prullenbak in ging, en dat vier uur kostte waar het vroeger vier dagen had gekost.
Een deel daarvan is echte waarde en een deel is drukte. Waar het om gaat: je hebt niets meer om mee te vergelijken. Het oude ticket en het nieuwe ticket delen een titel en verder niets.
Ik heb eerder geschreven dat het geaggregeerde snelheidscijfer niets meer zegt zodra developers per taak gaan kiezen waar ze hulp bij willen. Dit is dezelfde constatering, een niveau hoger. Inschatten liep stuk om dezelfde reden als het vervolgonderzoek van METR: de gemeten groep bleef stilletjes veranderen wat ze inleverde.
Waar die middag werkelijk in ging zitten
Neem een ticket zoals je ze in het echt krijgt. Een exportendpoint met filters, in een rapportageservice die al drie jaar in productie staat. Ingeschat op twee dagen, in de tijd vóór de agents, en die twee dagen klopten aardig.
Hetzelfde ticket, uitgesplitst naar waar het werk werkelijk uit bestaat:
| Onderdeel | Toen | Nu |
|---|---|---|
| Het probleem en de omliggende code begrijpen | 4u | 4u |
| Het schrijven | 6u | 1u |
| Het reviewen | 1u | 4u |
| Inpassen: de migratie, de config, drie aanroepende plekken | 3u | 3u |
| Nasleep: de bug die in week twee bovenkomt | 2u | 3u |
| Totaal | 16u | 15u |
Het schrijven kromp met vijf zesde. Het totaal kromp met een uur.
Drie van die vijf regels bewogen geen millimeter, want geen ervan gaat over typen. Een codebase begrijpen is lezen en onthouden, en een agent die hem voor je leest laat je met lege handen achter. Inpassen is onderhandelen met systemen die er al staan en al een mening hebben. De nasleep komt wanneer het hem uitkomt.
De regel die de verkeerde kant op ging is de review, en dat komt doordat er iets anders op tafel ligt. Code reviewen die je zelf schreef is je eigen redenering ophalen. Code reviewen die je niet schreef is die redenering opnieuw opbouwen, en dat is inmiddels de dure helft van het werk. Vier uur review op één uur gegenereerde code is gewoon wat het kost, en de reden dat zoveel teams een mooiere doorlooptijd laten zien, is dat ze die prijs niet betalen.
Bij jou zien die regels er anders uit. Bij mij verschillen ze per codebase, en de verhouding schuift flink op als ik het subsysteem goed ken. Wat overal overeind blijft is de vorm: de enige regel die instortte, was nooit het grootste deel van de schatting.
Wat ik nu inschat
Ik schat de controle, niet het genereren. De vraag die ik bij een ticket stel is niet meer hoe lang ik erover doe om het te bouwen, maar hoe lang het duurt tot ik het kan verdedigen. Toen ik alles zelf typte lagen die twee getallen dicht bij elkaar. Dat doen ze niet meer, en het tweede is het getal waar de release aan hangt.
Ik schat in onbekenden, niet in uren. Hoeveel dingen weet ik nog niet? Welke daarvan kan ik alleen beantwoorden door aan productiedata te komen, of in een gesprek met iemand die op vakantie is? Aan dat lijstje heeft genereren niets veranderd. Het is hetzelfde lijstje als in 2019, en het verklaart nog steeds het grootste deel van de spreiding.
Ik herzie mijn schatting niet zodra de diff er ligt. Deze is het verleidelijkst, en de reden dat zoveel tickets van twee dagen pas op dag drie worden opgeleverd. Een diff die er om elf uur 's ochtends compleet uitziet, voelt als bewijs dat het werk bijna klaar is. Het is bewijs dat één regel uit die tabel bijna klaar is. Een ongelezen diff is voorraad. Pas als je hem hebt nagekeken telt hij als voortgang, en daar ben je om elf uur nog niet aan begonnen.
Ik noteer wat ik deed, niet wat ik gedaan zou hebben. Zelf inschatten wat er zonder AI zou zijn gebeurd, is het onbetrouwbaarste instrument in deze hele discussie, en de enquête zegt dat over zichzelf. Ze zet de gemiddelde overschatting van wat AI met je tijd doet op 40 procentpunt, op basis van het METR-onderzoek uit 2025, en waarschuwt dat haar eigen deelnemers waarschijnlijk dezelfde fout maken. Bij dat onderzoek staat inmiddels een melding dat het hoofdresultaat achterhaald is. Wat overeind bleef, is het gat tussen gevoel en meting.
Dus ik ben gestopt met de vraag hoeveel sneller ik was. Ik schrijf op wat het ticket kostte, en zet dat naast de schatting die ik maakte voordat ik de editor opende. Dat getal is saai en het is gemeten, en juist daarom heb je er iets aan.
Hier worden schattingen niet goed van. Schattingen zijn nooit goed geweest. Wat er veranderde, is dat het enige voorspelbare deel van het werk, het typen zelf, niet langer het deel is waar je schatting over ging. En een hoop teams hebben hun toezeggingen aangepast alsof dat nog wel zo was.
Vertelt iemand je dus dat zijn team 3x sneller is geworden, geloof hem dan. Hij rapporteert keurig de winst op nieuwe taken, over een takenlijst die niet meer lijkt op de lijst waarop jullie roadmap gebouwd is.
Vraag daarna wat er de deur uit ging.