Hoe efficiënt codeert jouw AI-model? Een kritische kijk op AI-gegenereerde code

De cijfers op een rij

Voor we naar de oorzaken gaan, leggen we de basis. De voorbije twee jaar verschenen meerdere grootschalige studies die AI-code systematisch naast menselijk werk leggen. Wat ze samen laten zien:

Waarom een AI meer code schrijft dan een mens

Het model heeft geen geheugen van wat werkt. Het heeft statistieken van wat er geschreven staat.

1. Patronen matchen, niet begrijpen

De architectuur van een taalmodel voorspelt telkens het meest waarschijnlijke volgende stukje code, op basis van statistiek over zijn trainingsdata. Een native instinct voor optimalisatie zit daar niet in, net zomin als een besef van wat te veel is of van wat de codebase al bevat.

Een senior developer die een sorteerfunctie schrijft, weet dat de bestaande util-library al een implementatie heeft. Het model weet dat niet, tenzij die informatie expliciet in de context staat. Dus schrijft het een nieuwe implementatie, compleet met edge case handling, logging en documentatie.

2. Getraind op het internet: kwantiteit boven kwaliteit

Alle grote codemodellen zijn getraind op publieke code: GitHub-repositories, Stack Overflow, technische blogs en documentatie. Dat klinkt goed, maar het internet is geen curated bibliotheek van best practices. Het is een verzameling van alles: uitgebreide tutorials die elke stap uitleggen, gekopieerde Stack Overflow-antwoorden, oude enterprise-code vol historische workarounds en beginnersprojecten met overbodige structuur.

De meeste van die data weerspiegelt de gemiddelde internetontwikkelaar, zelden de meest elegante coder. Modellen leren dan ook de statistisch gemiddelde stijl, niet de optimale. Wat internet-code oververtegenwoordigt:

• Educatieve code die stap voor stap uitlegt (tutorials, cursussen).
• Defensief programmeren met uitgebreide try-catch en foutafhandeling.
• Boilerplate en template-gebaseerde structuren.
• Verouderde patronen die destijds gangbaar waren maar nu overbodig zijn.
• Gekopieerde code zonder aanpassing aan de lokale context.

3. Defensief programmeren als standaard

CodeRabbit-onderzoek toonde aan dat AI-gegenereerde code bijna twee keer zo vaak null-checks, vroege returns en defensieve patterns bevat als menselijke code. In webdevelopment is dat vaak de juiste aanpak. In data-engineering kan het rampzalig uitpakken.

Een concreet voorbeeld van de perverse kant van defensief programmeren in Claude Code (Medium, november 2025). De vraag aan de AI: schrijf een eenvoudige transformatie voor transform_user_record(record).

AI-output (vereenvoudigd):

def transform_user_record(record):
    try:
        user_id = record.get('user_id', -1)          # default -1 als ontbreekt
        email = record.get('email', '').lower()      # lege string als ontbreekt
        created = record.get('created_at', datetime.now())  # nu als ontbreekt
        return {'user_id': user_id, 'email': email, 'created_at': created}
    except Exception as e:
        logger.error(f'transform_user_record failed: {e}')
        return None                                   # stil falen

Het probleem: in een datapipeline verbergt dit patroon corrupte records. Een ontbrekend user_id wordt -1, een op zich geldige waarde die stroomafwaarts onbedoelde effecten heeft. Het model koos voor robuustheid die in een andere context correct zou zijn, maar hier de pipeline vervuilt. De code doet wat gevraagd werd en is toch semantisch fout voor de usecase.

4. Geen context van de bestaande codebase

Een agent die code schrijft zonder volledige codebase-context begint elke functie alsof het het eerste stuk code voor dit project is. Bestaande utility-functies worden opnieuw geschreven, constanten hardcoded in plaats van geïmporteerd, en de naamgevingsconventies van het team blijven links liggen.

GitClear’s longitudinale studie over 211 miljoen regels code toont dat concreet: copy-paste code klom tot 12,3% van alle gewijzigde regels, waar dat in 2021 nog 8,3% was, bijna de helft meer. Tegelijk zakte refactoring (code hergebruiken en verplaatsen) tot minder dan 10%, tegenover 25% eerder. AI dupliceert waar een mens hergebruikt.

5. RLHF: beloond voor uitgebreide antwoorden

Dit is het meest controversiële punt. Modellen worden verfijnd via Reinforcement Learning from Human Feedback (RLHF). Menselijke beoordelaars kozen historisch vaker voor uitgebreidere antwoorden die compleet aanvoelen, ook al is een korter antwoord technisch correcter. Zo ontstaat een structurele voorkeur voor uitvoerigheid.

Dat betekent niet dat modellen bewust zijn ontworpen om meer tokens te factureren. De uitkomst blijft wel dezelfde: modellen die beloond worden voor uitvoerige antwoorden, produceren langere code, en op token-gebaseerde facturering werkt dat rechtstreeks in het voordeel van de provider.

Menselijke code vs AI-code: een vergelijking

Om het concreet te maken, vergelijken we hoe een typische taak eruitziet in menselijke en in AI-stijl. Let op het aantal regels en de impliciete aannames. De taak: een e-mailadres valideren en opslaan in een database.

def save_email(email, db):
    if '@' not in email:
        raise ValueError('Invalid email')
    email = email.strip().lower()
    db.execute(
        'INSERT INTO users (email)'
        ' VALUES (?)', [email]
    )
    return True

import re, logging
from typing import Optional
logger = logging.getLogger(__name__)
EMAIL_REGEX = re.compile(
    r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]'
    r'+\.[a-zA-Z]{2,}$')
def save_email(email: Optional[str], db: DatabaseConnection) -> dict[str, any]:
    """Save email with validation."""
    if not email or not isinstance(email, str):
        logger.warning('Email is None/empty')
        return {'success': False, 'error': 'Email required'}
    email = email.strip().lower()
    if not EMAIL_REGEX.match(email):
        logger.warning(f'Invalid: {email}')
        return {'success': False, 'error': 'Invalid format'}
    try:
        db.execute(...)
        logger.info(f'Saved: {email}')
        return {'success': True, 'email': email}
    except Exception as e:
        logger.error(f'DB error: {e}')
        return {'success': False, 'error': str(e)}

De AI-versie is op zich correct. In bepaalde contexten is ze zelfs beter: striktere e-mailvalidatie, type hints, logging en een expliciet return-object. Wordt dit patroon over een hele codebase op elke utility-functie herhaald, dan levert het duizenden extra regels op die onderhouden, begrepen en gedebugd moeten worden terwijl de businesslogica identiek blijft.

Tokens verbranden of waarde leveren?

AI-bedrijven worden betaald per output token. Uitgebreidere code genereert meer output tokens. De prikkels zijn structureel verkeerd afgestemd.

De incentive-structuur

De huidige tokenpricing is asymmetrisch: output tokens kosten 5 keer meer dan input tokens. Elke extra regel code die een model schrijft, genereert meer output tokens, en meer output tokens betekent een hogere factuur. Op korte termijn heeft de provider er financieel weinig baat bij om beknopt te zijn.

Dat wil niet zeggen dat modellen bewust uitvoerig zijn ontworpen om geld te verdienen. Het blijft wel een structureel probleem van misaligned incentives dat de industrie eerlijk mag erkennen:

• RLHF-training beloont uitgebreide, complete antwoorden, ook bij code.
• Gebruikers, zeker niet-technische, beoordelen uitgebreidere code vaak als ‘meer werk’ en ‘meer waarde’.
• Providers meten kwaliteit via benchmarks (correctheid, testdoorgang), zelden via codelengte of onderhoudbaarheid.
• Een gestandaardiseerde ‘efficiency score’ voor gegenereerde code ontbreekt in publieke benchmarks.

Het tegenargument

De andere kant verdient evenveel aandacht. Er zijn wel degelijk goede redenen waarom AI-code langer uitvalt:

De conclusie ligt genuanceerd. Een deel van de extra code heeft reële waarde. Een ander deel is een artefact van het trainingsproces en de incentivestructuur. Het probleem is dat de industrie beide over dezelfde kam scheert, met concrete financiële en technische gevolgen.

De verborgen kost: technische schuld op schaal

Uitvoerige AI-code heeft een direct effect op je tokenkost, maar de indirecte kost weegt zwaarder: technische schuld die zich opstapelt naarmate AI een groter deel van de codebase schrijft.

Het 80%-probleem

Augment Code (april 2026) documenteerde wat het het 80%-probleem noemt: AI-agents leveren code die functioneel werkt maar structureel onvolledig blijft. Een typisch gegenereerd dashboard-component haalt data op en rendert een grid. Wat ontbreekt: error state handling, loading skeleton, data refresh-logica, accessibility attributen, ARIA labels en een authenticatiecheck.

Het venijn zit in de staart: de ontbrekende 20% achteraf toevoegen kost meer dan het van meet af aan correct bouwen. Elke fix vraagt eerst begrip van de intentie achter de gegenereerde code, terwijl agents hun architecturale keuzes zelden documenteren.

Vier mechanismen van schuld-accumulatie

• Begripsschuld: voor elke fix moet een engineer de intentie van de gegenereerde code reconstrueren.
• Duplicatieschuld: gekopieerde code vraagt synchrone updates op meerdere plaatsen bij elke bugfix.
• Testschuld: gegenereerde code optimaliseert voor de tests die er zijn, zelden voor de edge cases die er zouden moeten zijn.
• Architectuurschuld: code gegenereerd zonder systeeminzicht past niet in de bestaande abstractielagen.

Waar haalt het model zijn mosterd? De trainingsdatavraag

Om het codeergedrag van AI ten gronde te begrijpen, kijken we naar de bronnen. De grote codemodellen zijn getraind op sterk overlappende datasets.

• GitHub public repositories: de grootste bron. Bevat uitmuntende code naast eerstejaarsstudentprojecten, verlaten projecten en code vol quick-fixes.
• Stack Overflow: antwoorden onder CC-BY-SA licentie. Populaire antwoorden zijn niet per definitie de beste, ze zijn de meest gelikte, en likes worden mee bepaald door toegankelijkheid.
• Technische blogs en tutorials: per definitie educatief van opzet, dus uitgebreid en stap voor stap met maximale uitleg.
• Officiële documentatie en API-referenties.
• CodeSearchNet, The Pile en vergelijkbare geaggregeerde datasets met wisselende kwaliteitsnormen.

Onderzoek van Cracks in The Stack (arXiv 2025) analyseerde The Stack v2-dataset en vond verkeerde bestandsoorsprong-attributies. Die leiden tot code met onverenigbare licenties en, wat zwaarder weegt, tot buggy code die onterecht als geldig is gemarkeerd. Modellen die op buggy data trainen, leren buggy patronen. Hubinger et al. toonde bovendien aan dat LLM’s kwetsbaarheden kunnen introduceren en dat dat gedrag bijzonder moeilijk te verwijderen is via fine-tuning. Een eenmaal geleerd patroon blijft in het model aanwezig.

Een taalmodel leert de statistische verdeling van zijn trainingsdata. Het schrijft dus code die lijkt op het gemiddelde van GitHub, niet op de beste 5% ervan. De top-engineers die bekendstaan om elegante, minimale code, denk aan een one-liner van Linus Torvalds of een Rust-bijdrager die unsafe-blokken vermijdt, vormen een kleine minderheid in de data. Instructie-tuning en RLHF corrigeren dat deels, nooit volledig. Het model reikt nooit verder dan zijn trainingsdata, en die data weerspiegelt de gemiddelde internetontwikkelaar, zelden de allerbeste.

Hoe haal je er het beste uit? Praktische aanbevelingen

De boodschap luidt duidelijk: blijf AI gebruiken, want de productiviteitswinst is echt. Doe het met open ogen, met heldere richtlijnen en met technische tegengewichten.

1. Geef altijd codebase-context mee.
Zorg dat de agent toegang heeft tot de relevante bestaande modules, conventies en stijlgidsen voor de code gegenereerd wordt. Zonder die context vindt de agent het wiel opnieuw uit, dan met extra spaken en reflectoren die niemand vroeg.

2. Definieer een coding style guide voor AI.
Schrijf expliciet in je prompt of systeeminstructie: ‘Gebruik bestaande utility-functies uit /utils, volg onze naamgeving uit CONVENTIONS.md, schrijf geen inline logging tenzij gevraagd.’ AI volgt instructies beter dan dat het ze extrapoleert.

3. Vraag bewust om beknopte code.
Voeg aan je prompt toe: ‘Schrijf zo weinig mogelijk regels code die de taak volledig oplost.’ Modellen reageren goed op expliciete instructies om beknopt te zijn. Zonder die instructie kiezen ze voor volledigheid.

4. Review gegenereerde code structureel, niet enkel functioneel.
Test coverage garandeert niet dat de code de juiste architecturale keuzes maakt. Beoordeel ook: past dit in de bestaande structuur, zitten er duplicaten in, past de error handling bij deze context?

5. Gebruik linting en statische analyse als poortwachter.
Tools zoals Pylint, SonarQube of ESLint detecteren automatisch duplicatie, code smell en stijlafwijkingen in gegenereerde code. Integreer ze als verplichte stap in je CI/CD pipeline, voor het mergen.

6. Meet je code churn per developer en per AI-tool.
GitClear’s bevinding dat churn klom tot 7,9% legt een probleem bloot dat onzichtbaar blijft zonder meting. Voeg churn-metrics toe aan je engineering dashboard, want een hoge churnrate is een vroeg signaal van kwaliteitsproblemen.

7. Stel model-specifieke verwachtingen bij.
Haiku schrijft sneller maar minder genuanceerd, Opus schrijft trager maar met meer architectuurbesef. Weet welk model welke taak uitvoert en stem je review-intensiteit af op het model dat de code genereerde.

8. Behandel AI-code als externe code.
De beste praktijk in de industrie: behandel AI-gegenereerde code zoals code uit een externe library. Vertrouw ze niet blind, begrijp wat ze doet, test ze expliciet en documenteer de herkomst voor toekomstig onderhoud.

Conclusie: productiviteit en kwaliteit zijn twee dingen

AI schrijft code sneller. Dat staat vast. Snelheid en kwaliteit blijven alleen twee verschillende zaken, en meer regels code staat niet gelijk aan meer waarde. De cijfers zijn ontnuchterend: 1,7 keer meer problemen, 4 keer meer duplicatie, een refactoring-activiteit die halveerde en een churn-rate die verdubbelde.

Een deel van die uitvoerigheid levert reële waarde: betere type-annotaties, robuustere foutafhandeling, expliciete documentatie. Een substantieel deel is een artefact van hoe modellen leren, namelijk op het gemiddelde internet, beloond voor volledigheid en zonder zicht op de codebase waaraan ze bouwen.

Of tokens bewust verbrand worden, heeft geen simpel antwoord. De incentives staan structureel verkeerd afgestemd, en dat vraagt om bewuste tegenmaatregelen: duidelijke instructies, codebase-context, peer review, linting en churn-monitoring. Zie het als verantwoord omgaan met een krachtig instrument dat zijn grenzen kent.

Over de auteur

Peter Verrykt is Business Unit Lead Data & AI bij Xylos en begeleidt organisaties in het omzetten van data naar concrete businesswaarde. Wil je AI-code in je team onder controle houden? Ik praat er graag over.

Bronnen

CodeRabbit: State of AI vs Human Code Generation (dec. 2025) | GitClear: AI Copilot Code Quality 2025 (211M regels) | Cotroneo et al. arXiv 2508.21634 (aug. 2025) | Monash/Otago: Comparing Human and LLM Generated Code (jan. 2025) | Augment Code: The 80% Problem (apr. 2026) | METR: AI tooling slowed developers down (jul. 2025) | Stack Overflow: Bugs and Incidents with AI Coding Agents (jan. 2026) | Cracks in The Stack arXiv 2501.02628

Disclaimer: codevoorbeelden zijn illustratief vereenvoudigd. De weergegeven studies zijn peer-reviewed of gepubliceerd door erkende instituten en worden correct geciteerd naar aard, niet letterlijk gereproduceerd.