Vibe coding en de verborgen kosten van AI-gegenereerde code

Vorige week mergde ik een pull request en realiseerde me halverwege de review dat ik de code niet echt begreep. Niet omdat die te complex was, maar omdat ik hem niet geschreven had. Een AI-assistent had het meeste werk gedaan, en ik was aan het beoordelen op "werkt het?" in plaats van "snap ik het?"

Het was een klein moment, maar het bleef hangen. Andrej Karpathy heeft hier inmiddels een woord voor: vibe coding. En als je de onderzoeksdata van het afgelopen jaar bij elkaar legt, blijkt dat dit soort momenten niet onschuldig zijn. Er tekent zich een patroon af dat het waard is om eerlijk te bekijken.

De kloof tussen gevoel en meting

Het onderzoek dat mij het meest aan het denken heeft gezet komt van METR. Zij lieten 16 ervaren open-source developers (5+ jaar ervaring, 1.500+ commits) 246 echte taken uitvoeren, de helft met AI-tools, de helft zonder. Het resultaat: ze werden 19% langzamer met AI.

Maar hier wordt het interessant. Vooraf verwachtten deze developers 24% sneller te zijn. Achteraf geloofden ze nog steeds dat ze 20% sneller waren geweest. Een kloof van bijna 40 procentpunten tussen perceptie en werkelijkheid.

Ik denk dat dit iets onthult over hoe wij productiviteit ervaren. AI-tools geven je het gevoel van flow: je typt minder, er verschijnt sneller code op je scherm, je raakt minder "vast". Maar als de gegenereerde code subtiel verkeerd is, of net niet past in de bestaande architectuur, ben je meer tijd kwijt aan debuggen en aanpassen dan je beseft. De snelheid zit in het schrijven. De vertraging zit in alles erna. En dat tweede deel registreren we blijkbaar niet goed.

Andere signalen in dezelfde richting

GitClear analyseerde 211 miljoen coderegels uit 2020-2024. Refactoring stortte in van 24,1% naar 9,5% van alle wijzigingen. Copy-paste code steeg van 8,3% naar 12,3% en overtrof refactoring voor het eerst ooit. Dubbele codeblokken namen achtmaal toe. Dit is precies wat je verwacht als code wordt geproduceerd door een model dat niet nadenkt over de bestaande codebase.

Google's DORA Report 2024 vond dat een 25% toename in AI-gebruik leidde tot een 7,2% daling in delivery stability. Meer output, maar ook meer mislukte deployments. De originele Copilot-studie uit 2023 rapporteerde 55,8% snelheidswinst, maar dat was bij een enkele, gecontroleerde HTTP-server taak. Latere veldexperimenten bij complexer werk vonden slechts 7,5-21,8% meer PRs per week.

Wat wel werkt

Dit is geen verhaal tegen AI-codeertools. Ik gebruik ze dagelijks. GitHub Copilot heeft meer dan 15 miljoen gebruikers en 90% van Fortune 100-bedrijven heeft het geadopteerd. Bij Duolingo leidde het tot 25% snellere onboarding. AI is uitstekend voor boilerplate, testgeneratie, documentatie en prototyping.

De teams die er het meeste uithalen behandelen AI-output niet anders dan code van een junior developer: altijd reviewen, altijd begrijpen, altijd testen. Shopify maakte AI-vaardigheid onderdeel van prestatiebeoordelingen. Thoughtworks plaatste "complacency with AI-generated code" als waarschuwing op hun Technology Radar. Zonder goede AI-prompttraining zien teams 60% lagere productiviteitswinst.

Waar het op neerkomt

De data wijst op een patroon dat lastig te negeren is. AI-gegenereerde code bevat 1,5x tot 2x meer bugs, tussen de 40% en 62% beveiligingskwetsbaarheden, en een achtmaal hogere codedubbelingsgraad. Ervaren developers die denken dat ze sneller werken met AI, werken in werkelijkheid langzamer. Het is niet dat de tools slecht zijn. Het is dat ze ons verleiden tot een manier van werken die we niet gewend zijn kritisch te bekijken.

Het verschil tussen productieve AI-inzet en vibe coding is uiteindelijk geen technisch vraagstuk. Het is een vraag over eigenaarschap. Begrijp je wat er in je codebase staat? Kun je uitleggen waarom een bepaalde keuze is gemaakt? Als het antwoord nee is, dan maakt het niet uit hoe snel de code tot stand kwam.