METR wilde één vraag beantwoorden: word je als ervaren developer sneller van AI?
Dat is niet gelukt.
Hun update van februari legt uit waarom ze niet achter de cijfers van het vervolgonderzoek staan. Developers haakten af, want meedoen betekende dat je de helft van je taken zonder AI moest doen. En van de mensen die zich wel aanmeldden, koos 30 tot 50% stilletjes uit wat ze inleverden: het werk dat ze niet met de hand wilden doen, hielden ze achter.
Het onderzoek moest meten of AI helpt. Het liep stuk doordat developers per taak bepaalden waar ze die hulp wilden hebben.
Dat is de interessante uitkomst, en niemand haalde hem aan.
Het geaggregeerde cijfer zegt niets meer
De kop die iedereen onthoudt komt uit het eerste onderzoek: 16 ervaren open source-developers, 246 echte taken in repositories waar ze al jaren in werkten, en 19% vertraging zodra AI was toegestaan. Diezelfde developers dachten achteraf dat ze 20% sneller waren geweest.
Herhaal het een jaar later en de schatting staat op 18% sneller voor dezelfde groep. Nieuw geworven developers kwamen uit op 4% sneller, met een betrouwbaarheidsinterval dat ruim over nul heen loopt. METR noemt het allemaal zeer zwak bewijs.
Het cijfer ging dus in ongeveer een jaar van 19% langzamer naar 18% sneller, en de onderzoekers die beide getallen produceerden zeggen er zelf bij dat je op geen van beide moet vertrouwen.
Een grootheid die zo snel van teken wisselt zegt vooral iets over waar je het gereedschap op hebt ingezet, en nauwelijks iets over het gereedschap zelf. "Word je sneller van AI" is een te grove vraag, zoals vragen of elektrisch gereedschap je een betere timmerman maakt zonder erbij te zeggen of je een wand timmert of een zwaluwstaart zaagt.
De vraag die overblijft, stel je per taak. Precies de vraag die de deelnemers van METR in stilte beantwoordden toen ze bepaalde tickets niet inleverden.
Wat uitbesteden echt heeft opgeleverd
De cijfers van DORA zijn duidelijk over de doorstroom. Het aantal afgeronde epics per developer ligt 66,2% hoger. Releasesnelheid lijdt niet meer onder AI-adoptie, wat een jaar geleden nog nieuws was en inmiddels gewoon de standaard is.
Diezelfde cijfers laten zien wat er meekwam. Pull requests zijn 51,3% groter geworden. De mediane doorlooptijd van een review steeg met 441%. En 31% meer pull requests worden gemerged zonder dat iemand ernaar heeft gekeken.
Genereren werd goedkoop. Alles ná het genereren werd duurder, en een deel ervan wordt gewoon overgeslagen. DORA zelf noemt AI een versterker, wat een nette manier is om te zeggen dat het niets voor je beslist.
Moeilijkheidsgraad is de verkeerde maatstaf
De meeste developers sorteren op hoe zwaar een taak voelt. Zwaar betekent "de agent gaat dit verprutsen", dus zwaar werk houd je zelf en makkelijk werk gooi je over de schutting.
Die vuistregel klopt niet, want waar een model op stukloopt heeft weinig te maken met wat wij moeilijk vinden. Een model schrijft je een werkende red-black tree en gaat vervolgens de mist in op een datumvergelijking van twee regels, omdat het eerste veel in zijn trainingsdata voorkomt en het tweede afhangt van wat jouw codebase precies onder een werkdag verstaat. Het heeft geen wereldmodel dat vertelt welke van die twee het risico is.
Dit is het onderzoek dat mijn eigen denken op de kop zette. Een inventarisatie van operationele fouten bij agentic coding assistants telde 547 bevestigde incidenten uit de praktijk, opgehaald uit de issuetrackers van de grote codemodellen en agent-frameworks, verdeeld over 33 risicotypen. De grootste categorie is het negeren van expliciete instructies en randvoorwaarden, met 40,4%. Destructieve operaties volgen met 24,5%. Zestig procent van alle incidenten kreeg het label hoog of kritiek, bij 170 ervan ging data verloren.
Dan het deel dat telt voor je taakverdeling. Bugs oplossen en setup- of configuratiewerk zijn samen goed voor ruim 65% van alle waargenomen incidenten, en van de hele lijst scoren ze het slechtst op ernst: 65,1% en 68,4% van die incidenten waren hoog of kritiek.
Bugs oplossen. De taak die iedereen als eerste weggeeft, omdat die afgebakend voelt, goed te controleren lijkt en weinig kan kosten als het misgaat.
Het is het gevaarlijkste werk op de lijst, en daar is een simpele verklaring voor. Bugfixes en configuratie zijn precies de twee categorieën waarin de agent iets moet wijzigen wat er al staat en waar iemand anders van afhankelijk is. Bij nieuwe code zie je in review meteen wat er mis is. Een slechte migratie, een herschreven config, een "fix" die het gedrag drie modules verderop verandert: die gaan stilletjes stuk, in productie, later.
De drie vragen die ik echt stel
Ik sorteer op wat een fout me kan kosten. Drie vragen:
Kan ik het goedkoper controleren dan schrijven? Dit is de hele economische afweging, en juist deze slaat iedereen over. Als het nakijken langer duurt dan het maken, heeft uitbesteden me tijd gekost en iets opgeleverd wat ik slechter begrijp. Boilerplate, een testsuite tegen een contract dat ik zelf al had vastgelegd, een bekend patroon doorvoeren in veertig bestanden: goedkoop te controleren. Een cachinglaag met subtiele invalidatieregels: daar moet ik sowieso elk pad doordenken, dus dan schrijf ik het net zo goed zelf en houd ik die redenering meteen in mijn hoofd.
Is het terug te draaien? Alles wat de agent aanraakt en wat ik kan weggooien kost me niets als het fout is. Alles wat hij aanraakt en wat echte toestand wijzigt kost me een incident. Een agent heeft ooit een productiedatabase gewist op een machine van mij, en het cijfer hierboven over destructieve operaties laat zien dat zulke verhalen vaak genoeg voorkomen om een eigen categorie te krijgen.
Moet ik dit om drie uur 's nachts kunnen overzien? Is het antwoord ja, dan schrijf ik het, of ik lees het regel voor regel tot ik het zelf had kunnen schrijven. Dit is de praktische kant van het eigenaarschap. Dat je de code merget en hem daarmee bezit, bepaalt wie verantwoordelijk is. Het zegt nog niets over welk werk je überhaupt onder je naam wilt hebben.
Wat ik nog steeds zelf doe
Nieuw ontwerp. Alles waarbij de eerste goede beslissing gaat over welke vorm het probleem heeft. Modellen zijn uitstekend in het tweede, derde en honderdste exemplaar van een patroon en zwak in het eerste. Zodra ik een ontwerp heb, laat ik er graag een model tegenin gaan.
Subtiele toestand. Concurrency, cache-invalidatie, transactiegrenzen, alles waar een verhaal over gedeeltelijk falen bij hoort. Agents schrijven het prachtig, en dat is precies de valkuil: de fout is een race die eens per twee weken opduikt, en ik heb het hele model in mijn hoofd nodig om hem te herkennen.
De commit die ik zou moeten verdedigen. Code die met beveiliging te maken heeft, code die met geld te maken heeft, alles waar ik in een postmortem naar gevraagd word. Een agent mag dat reviewen. Schrijven zonder dat ik het lees, niet.
Iets leren. Als het hele punt van een taak is dat ik daarna het subsysteem ken, dan haalt uitbesteden de zin uit de taak. Deze moet ik bij mezelf afdwingen, want op een drukke dag is dit altijd het eerste wat sneuvelt.
De rest, en dat is verreweg het meeste werk, gaat naar de agent binnen de werkwijze die ik hanteer: met een spec, ingekaderd en gereviewd.
Schrijf je eigen grens op
De deelnemers van METR die taken achterhielden, deden precies waar dit hele stuk over gaat. Ze gingen af op een oordeel dat ze niet konden uitleggen, en dat belandde toevallig in een dataset waar het op ruis leek.
Jij hebt dat oordeel ook. Je hebt het deze week gebruikt zonder erbij stil te staan. Het verschil tussen dat oordeel hebben en het als vaardigheid hebben, is of je de regel hardop kunt uitspreken, hem kunt verdedigen tegenover een collega en merkt wanneer hij niet blijkt te kloppen.
De mijne past in één zin. Is het goedkoop te controleren en veilig terug te draaien, en hoef ik het onder druk niet uit te leggen, dan gaat het naar de agent.
De rest typ ik nog steeds zelf.