De belofte van AI coding agents is verleidelijk: je developer typt een beschrijving van wat hij wil, en een AI-agent bouwt het. Tien keer sneller. Voor een fractie van de kosten. De marketingpagina's van Cursor, Devin en GitHub Copilot liegen er niet om.
Maar er is een MIT-studie die je eerst moet lezen.
De cijfers die de marketing niet laat zien
Onderzoekers van MIT analyseerden de output van meer dan 100.000 developers die AI coding agents gebruiken. De resultaten zijn ontnuchterend. Het volume geschreven code steeg met ongeveer 180%. Maar de hoeveelheid code die daadwerkelijk in productie ging — code die écht werkt, getest is, en waarde levert — steeg met slechts 30%.
Laat dat even landen. Bijna twee keer zoveel code. Maar je product gaat er nog geen derde op vooruit.
De rest? Die verdwijnt in een zwart gat van pull requests die nooit gemerged worden, features die bijna werken maar net niet, en code die er op het eerste gezicht goed uitziet maar bij edge cases breekt. AI-agenten zijn meesterlijk in het genereren van code die er correct uitziet. Ze zijn aanzienlijk minder goed in code die correct ís.
Waarom "bijna goed" duurder is dan "fout"
Verrassend genoeg is het probleem niet dat AI-agents slechte code schrijven. Het probleem is dat ze code schrijven die er goed uitziet maar subtiele fouten bevat. En subtiele fouten zijn duurder dan overduidelijke fouten.
Een overduidelijke fout — een syntax error, een missende import — zie je in 5 seconden. Je fixet hem, je gaat door. Een subtiele fout — een race condition die alleen optreedt bij 10.000+ gelijktijdige gebruikers, een off-by-one error in een zelden gebruikte codepath — die zie je pas in productie. En dan kost het je uren debuggen, een hotfix, en mogelijk een klant die afhaakt.
De MIT-studie vond dat AI-gegenereerde code 3,4 keer vaker subtiele logische fouten bevat dan menselijk geschreven code. Niet omdat de AI slechter is in logica — maar omdat hij geen begrip heeft van de context waarin de code draait. Een AI-agent weet niet dat jouw database een specifieke index-structuur heeft. Hij weet niet dat jouw API-rate-limiter anders werkt dan de standaard. Hij genereert code voor een generiek systeem, niet voor jouw systeem.
De echte bottleneck: niet schrijven, maar begrijpen
The Decoder rapporteerde over een aanvullende studie die het probleem nog scherper stelt: AI coding agents vinden wél het juiste bestand, maar missen de exacte regels die ertoe doen. Ze kunnen een codebase doorzoeken en het relevante bestand identificeren — maar als het aankomt op de specifieke 3 regels die aangepast moeten worden, falen ze in 40% van de gevallen.
Dit is de kern van het probleem. Softwareontwikkeling is niet "code schrijven". Het is "begrijpen wat er moet veranderen, en precies dát veranderen zonder iets anders te breken." AI-agents zijn goed in het eerste. Ze zijn nog steeds slecht in het tweede.
Noam Brown, die OpenAI's reasoning-modellen leidde, vatte het samen: de enige betrouwbare manier om een AI-agent over een periode van een jaar te evalueren, is hem een jaar te laten draaien. Alles korter is een momentopname die je een vals gevoel van productiviteit geeft.
Wat dit betekent voor jouw MKB-bedrijf
Als je een developmentteam van 3-5 man hebt, is de verleiding groot: "we zetten iedereen op Cursor of Copilot, en we bouwen 2x sneller." De data zegt: je schrijft 2x meer code, maar je product gaat er 30% sneller op vooruit. En je introduceert 3,4x meer subtiele bugs.
Dat betekent niet dat je AI-tools moet negeren. Het betekent dat je ze anders moet inzetten.
1. AI voor boilerplate, mens voor logica
Laat AI-agents de repetitieve code genereren: CRUD-endpoints, formuliervalidatie, configuratiebestanden. Maar laat een menselijke developer de businesslogica schrijven — de code die bepaalt wát je product doet, niet hoe het eruit ziet.
2. Verhoog je review-tijd, niet je schrijftijd
Als AI 180% meer code genereert, moet je review-capaciteit meegroeien. Een pull request van 200 regels menselijke code kost 15 minuten review. Een pull request van 500 regels AI-code kost 45 minuten — omdat je niet alleen op stijl let, maar ook op verborgen aannames.
3. Meet shipped features, niet geschreven regels
De enige metric die telt is: hoeveel features gingen deze sprint live? Niet: hoeveel code is er gecommit. Als je team 3 features shippede vóór AI-tools en 4 features erna, is dat een winst van 33% — precies in lijn met de MIT-data. Claim geen 2x productiviteit als je product er 30% op vooruit gaat.
De AI coding revolutie is echt. Maar het is geen snelweg — het is een tool die je sneller laat graven, niet een tool die je vertelt wáár je moet graven. En het verschil tussen die twee is precies 150 procentpunten.