“Hoeveel sneller ben je nu echt met AI?” Het is de vraag van elke CTO die het MT beloofde dat AI tijd zou besparen. En de bron van eindeloze discussies onder developers. Het eerlijke antwoord is ongemakkelijk: dat hangt ervan af.

Van je codebase, de complexiteit, hoeveel context er al staat. En van iets wat bijna niemand meet: hoe goed je zelf bent in het aansturen van AI. Geen wonder dat je bij de koffieautomaat vaak hoort “ja, het is wel handig”. Dat lauwe gevoel is geen toeval. We schatten structureel verkeerd in wat AI met onze snelheid doet.

Wat zegt het onderzoek?

Infographic: developers voelen zich 20% sneller met AI, maar waren in het METR-onderzoek 19% trager; bij één taak is wachttijd puur verlies
Het gevoel en de meting liggen ver uit elkaar. Bron: METR, 2025.

Een veelbesproken METR-onderzoek zette ervaren developers aan het werk op vertrouwde, volwassen codebases. Met AI dachten ze dat ze ongeveer 20% sneller waren. In werkelijkheid waren ze gemiddeld 19% trager.

Belangrijk detail: dat was begin 2025, met een autocomplete- en chatfunctie, nog niet met agents. Een update begin 2026 wijst op verbetering, maar hard bewijs is er nog niet. Juist omdat developers inmiddels met meerdere agents tegelijk werken, wordt het lastiger om dit netjes te meten.

Waarom voelt het sneller dan het is?

Dat gat tussen gevoel en werkelijkheid zie ik het sterkst bij devs die net met AI beginnen. Ze voelen de versnelling meteen. Alleen is sturen een vaardigheid op zich, en die bouw je niet in een week op. In het begin kost het meestal meer tijd dan het oplevert.

Waar zit de echte winst dan?

Een groot deel van je tijd is wachten. Op specs, agents, builds, tests en reviews. Dode tijd binnen die ene taak. Werk je aan één ding, dan is die dode tijd puur verlies. Laat je meerdere stromen tegelijk lopen, dan kan het enorme tijdswinst opleveren.

Infographic: vier stromen parallel laten lopen vult de wachttijd op; niet sneller per taak, wel meer output door parallel werken
Niet sneller per taak, wel meer output: de dode tijd van één taak vul je op met werk aan een andere.

Maar er zit een prijs aan. Vier stromen tegelijk betekent vier keer verifiëren. Je ruilt wachttijd in voor verificatielast. En precies dat verandert aan het werk: van zelf bouwen naar beoordelen of wat eruit komt goed genoeg is. Netto win je, maar alleen als je dat verifiëren serieus neemt. Hoe ik dat parallel werken met meerdere worktrees in de praktijk doe zonder de ruis, beschreef ik apart.

Je ruilt wachttijd in voor verificatielast.

Wat verschuift er aan het werk?

Voor mij kwam de omslag niet toen ik handiger werd met AI. Hij kwam op de ochtend dat ik inlogde en er veel complex werk af bleek. Werk waar ik nauwelijks aandacht aan had hoeven geven. Mijn aandeel op de dag ervoor: duidelijke specs opstellen, een paar keer op het juiste moment bijsturen en een nacht laten lopen. De code kwam ergens anders vandaan.

Geen euforie. Eerder een rare leegte. Het voelde alsof ik iets uit handen had gegeven zonder het te merken.

Dit is de verschuiving die jullie beste developers als eerste gaan voelen. Hun werk verschuift van code schrijven naar agents op koers houden. Dat is een nieuwe vaardigheid, en eerlijk gezegd is het even wennen. Het is dezelfde beweging die ik beschreef toen ik als .NET-developer met Claude Code ging bouwen: de bottleneck schuift van schrijven naar begrijpen.

Ik zit zelf middenin die overgang. Twee SaaS-producten bouw ik nu zo: de agents doen het grootste deel, ik stuur en bewaak.

Wat zou jij meten als je echt wilt weten of AI je sneller maakt: het gevoel van je team, of wat er ‘s ochtends af is?

Bronnen
  1. METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (juli 2025)
  2. METR: We are Changing our Developer Productivity Experiment Design (februari 2026)