Schattingen lopen sterk uiteen, maar surveys van grote ontwikkelplatformen suggereren dat ergens tussen de 20 en 40 procent van de code die wordt gecommit in actieve codebases, op een of andere manier met AI-ondersteuning tot stand komt. Het getal hangt sterk af van hoe je 'AI-gegenereerd' definieert en welk type werk je meet.
Waarom het getal moeilijk vast te pinnen is
AI-ondersteuning bestaat op een spectrum. Aan de ene kant accepteert een developer een enkele autocomplete-suggestie voor een variabelenaam. Aan de andere kant wordt een hele module door een coding agent opgezet en voor de merge gereviewd. Beide tellen in de meeste surveys als 'AI-gegenereerd', wat de headline-percentages moeilijk te interpreteren maakt.
Het meetprobleem versterkt dit. De meeste organisaties instrumenteren hun editors niet om acceptatiegraden bij te houden. Surveydata steunt op zelfrapportage, wat de neiging heeft te schuiven naar het antwoord dat op het moment van vragen het meest sociaal acceptabel voelt.
Wat duidelijker is, is dat het aandeel stijgt. Schattingen uit 2023 en 2024 laten een consistente opwaartse beweging zien, en de tooling is in die periode aanzienlijk verbeterd.
Waar AI-output het zwaarst is
AI-ondersteuning is niet gelijkmatig verdeeld over een codebase. Het concentreert zich doorgaans in:
- Boilerplate: configuratiebestanden, serializers, test scaffolding
- Repetitieve patronen: CRUD-endpoints, datatransformaties, formuliervalidatie
- Eerste concepten: nieuwe bestanden waarbij de developer een schets geeft en een beginstructuur accepteert
- Documentatie en inline comments
Kernbedrijfslogica, beveiligingsgevoelige code en alles wat diepgaande kennis van de geschiedenis van een specifiek systeem vereist, kent doorgaans meer menselijk auteurschap, of in elk geval zwaardere bewerking van AI-output.
Wat 'AI-gegenereerd' verdoezelt
De bruikbaarste vraag is hoeveel code goed begrepen was voordat die werd gecommit. Hoeveel er uit een model kwam, doet er minder toe. Een developer die door AI voorgestelde code leest, test en er verantwoordelijkheid voor neemt, zit in een wezenlijk andere positie dan iemand die output zonder review plakt.
Dit onderscheid is van belang voor kwaliteit, voor debugging en voor beveiliging. Hoe je AI-gegenereerde code reviewt behandelt de praktische verschillen in wat dat reviewproces zou moeten inhouden. De gewoonten rond human-in-the-loop engineering worden belangrijker naarmate het ruwe volume aan AI-output toeneemt.
Organisaties die het percentage behandelen als een productiviteitsmetric zonder te vragen naar de kwaliteit van de review, bouwen sneller technische schuld op dan ze beseffen. AI-modellen zijn zelfverzekerd en vloeiend; ze produceren plausibel ogende code die een oppervlakkige lezing kan doorstaan, maar faalt onder belasting, faalt bij edge cases of subtiele beveiligingsproblemen introduceert.
Hoe teamstructuur het getal beïnvloedt
Teams die gebruikmaken van agentic coding-workflows, waarbij een agent meerstapstaken autonoom afhandelt, zullen hogere percentages zien dan teams die inline suggestietools gebruiken. De architectuur van hoe werk wordt verdeeld tussen mens en model verschuift het getal aanzienlijk.
Senioriteit speelt ook een rol. Meer ervaren engineers gebruiken AI-ondersteuning voor een groter deel van werk met lage waarde (scaffolding, tests, documentatie) en schrijven meer van de kritieke logica zelf. Junior engineers keren dit soms om: ze genereren complexe logica vanuit prompts die ze niet volledig begrijpen en schrijven de triviale delen zelf.
Wat het getal je niet vertelt
Een team waarbij 50 procent van de code AI-gegenereerd en zorgvuldig gereviewd is, staat waarschijnlijk sterker dan een team waarbij 10 procent AI-gegenereerd is en zonder controle wordt gecommit. Het percentage is een maatstaf voor snelheid, niet voor kwaliteit of risico.
Voor de teams waarbij Miyagami engineers plaatst, is de werkende aanname dat AI-ondersteuning een normaal onderdeel is van hoe productiesoftware wordt gebouwd, en dat de engineering-vaardigheid zit in het aansturen, reviewen en eigenaarschap nemen van wat eruit komt, niet in het vermijden van de tools.
Waar we op testen
Onze selectie weerspiegelt dit direct. Het AI-native assessment scoort engineers op verificatie van AI-output. Het toetst of ze verzonnen API's, subtiel foute logica of beveiligingslekken in gegenereerde code opmerken voordat die live gaat. Risicogericht oordeelsvermogen, gescoord over beide assessments, pakt het bijbehorende probleem aan: een agent levert een tekstwijziging en een betalingsmigratie even snel en met dezelfde stelligheid op, en goede engineers behandelen die twee niet hetzelfde. Lees hoe we selecteren voor het volledige beeld.
Korte antwoorden
Welk percentage van de code is AI-gegenereerd in 2024?
Schattingen lopen uiteen, maar surveys suggereren dat 20-40% van de gecommitte code AI-ondersteuning omvat. Het getal hangt af van hoe ondersteuning wordt gedefinieerd en gemeten, en het is van jaar op jaar consistent gestegen.
Veroorzaakt AI-gegenereerde code meer bugs?
Niet per se. AI-output die zonder goede review wordt gecommit, brengt wel bugs mee die lastiger te traceren zijn. Het risico zit in het reviewproces. Het genereren zelf levert geen extra risico op.
Moeten teams bijhouden hoeveel van hun code AI-gegenereerd is?
Het kan nuttig zijn als baseline, maar de informatievere metric is reviewdekking en het defectpercentage per code-oorsprong. Een kaal percentage vertelt je weinig over kwaliteit of risico.
