AI schrijft te veel code — en dat kost je straks de kop

Je AI-assistent levert werkende code af. Tests slagen, alles draait. Toch stapelt de technische schuld zich op. Het echte probleem met AI-codegeneratie zit niet in bugs — het zit in overengineering.

Waarom stapelt AI code op code?

Moderne AI-modellen leveren vaak production-ready code. Maar ze missen één cruciaal vermogen: vereenvoudigen. Vraag een AI om een feature uit te breiden, en je krijgt extra tabellen, converters, migraties en tests. Vraag om een refactoring, en het eindresultaat is langer en ingewikkelder dan wat je had.

AI suggereert nooit om drie tabellen te droppen en 30% van je code te verwijderen. Die instinct — om complexiteit terug te dringen — ontbreekt volledig.

Voorbeeld uit de praktijk: Een klein bedrijf met 400 dagelijkse gebruikers krijgt van AI een architectuur met microservices, RabbitMQ, abstract data factories én twee frontend-frameworks (Svelte én React). Een verstandig mens had gekozen voor één simpel dashboard met server-side rendering. Geen API, geen extra lagen.

Wanneer gaat het mis?

Het keerpunt komt wanneer een grote nieuwe feature niet meer past in het bestaande schema. Op dat moment moet je refactoren — maar de codebase is al zo opgeblazen dat AI alleen nog maar rommel produceert. Zelfs zeer ervaren developers lopen hier tegenaan.

De paradox: alles zag er tot dat moment “solid” uit. Tests draaiden, functionaliteit deed wat het moest. Maar de technische schuld accumuleert onzichtbaar, totdat het te laat is.

Wat helpt tegen AI-overengineering?

Concrete aanpak die resultaat oplevert:

Dring simpelheid af — vraag expliciet om de eenvoudigste oplossing, niet “de beste”
Review architectuur handmatig — laat AI geen schema’s of API-specs bepalen, dat doe je zelf
Stel grenzen eerst — definieer je data-modellen en endpoints, AI vult de tussenruimte in
Itereer op papier — werk architectuur en schemas uit voordat je één regel code genereert

Dit vergt senior-niveau inzicht. En daar zit het volgende probleem.

Het GPS-effect: kennisuitholling

AI heeft ervaren babysitters nodig. Maar het voorkomt ook dat nieuwe ervaren mensen ontstaan.

Vergelijk het met GPS-gebruik: je komt wel overal, maar je leert de topologie van je stad nooit echt kennen. Zo ontstaat een generatie IT’ers die AI-prompts schrijven maar geen diep begrip opbouwen van systemen. Dat diepere begrip is juist de voorwaarde om goede technische keuzes te maken.

Uit onderzoek blijkt dat junioren die met AI-assistentie aan de slag gaan minder goed leren debuggen en systeemdenken ontwikkelen dan junioren die zonder AI leren. De tool die productiviteit belooft, holt de vaardigheden uit die je nodig hebt om die tool goed te gebruiken.

Concrete kwaliteitsproblemen in AI-code

Wat je tegenkomt in de praktijk:

Ongebruikte variabelen en methodes
Misleidende of compleet incorrecte comments
Amateur-patronen: lijsten muteren tijdens een loop, regex elke keer opnieuw compileren
Hardcoded waarden waar dependency injection logisch was
Mysterieuze comments over features die niet bestaan

Reëel voorbeeld: Een klasse geschreven voor één specifiek team wordt hergebruikt door anderen. In plaats van de klasse generiek te maken met dependency injection, hardcodeert AI teamspecifieke waarden. Andere teams moeten functionaliteit uitschakelen. Vijf minuten refactoring had het opgelost — maar niemand keek ernaar.

Waarom AI geen goede architectuur kan bouwen

AI-modellen voorspellen tokens op basis van self-attention. Ze kunnen niet redeneren over wat een klant daadwerkelijk nodig heeft. Architectuurkeuzes hangen af van businesscontext: groeiambities, budgetten, teamsamenstelling, bestaande systemen.

Die context ontbreekt volledig. Daarom levert AI code die er “impressive” uitziet maar zowel over- als under-engineered is.

Het vertrouwensprobleem

Naarmate AI beter wordt, wordt het ook beter in het verbergen van zwakke plekken. Bij bekende projecten herken je direct hoe middelmatig het resultaat is. Bij onbekende projecten twijfel je: misschien is dit wel goed?

AI heeft geen accountability. Geen consequenties bij fouten. Geen angst om ontslagen te worden, geen motivatie om het nét iets beter te doen. Die druk — hoe vervelend soms — levert wel betere code op.

Wat kun je deze week proberen?

Direct toepasbaar stappenplan:

Vraag AI expliciet om te vereenvoudigen — “Geef me de simpelste oplossing die functioneert, geen abstracties tenzij ik erom vraag”
Review elke nieuwe tabel of klasse — vraag jezelf: is dit écht nodig, of stapelen we complexiteit?
Werk architectuur uit op papier eerst — gebruik tools als Excalidraw of dbdiagram.io, laat AI niet je data-model bepalen
Budget tijd voor opruimen — plan structureel momenten in om code te versimpelen, niet alleen features toe te voegen

Een klein MKB-bedrijf dat deze aanpak hanteert, bespaart niet alleen ontwikkeltijd — het voorkomt vooral dat het project over zes maanden onwerkbaar wordt. En dat scheelt meer dan een paar uur prompt-engineering.