AI maakt jouw developers slordiger, niet scherper.

AI zou developers scherper maken. In plaats daarvan maakt het de meesten slordiger. Dezelfde teams die vorig jaar Claude Code, Copilot en een dozijn AI-codeertools omarmden, leveren nu meer bugs per release dan daarvoor. De features die ze bouwen zijn groter, sneller geschreven, en minder goed begrepen door de persoon die ze merged.

Wat is er dan gebeurd? De technologie werkt prima. De mensen die hem gebruiken zijn veranderd in hoe ze te werk gaan. AI-codeerfouten worden in 2026 stilletjes de grootste bedreiging voor softwarekwaliteit, want als AI het denkwerk doet, stop jij met denken.

De belofte versus de realiteit

Twee jaar geleden was de pitch simpel. AI zou het boilerplate-werk afhandelen, tests opstellen, de diff samenvatten, en developers vrijmaken voor de moeilijke problemen. Productiviteit zou stijgen. En de rekensom klopte op papier: als een developer 40 procent van zijn tijd besteedde aan repetitieve code, en AI nam het grootste deel daarvan over, dan zou de output moeten stijgen.

De output steeg inderdaad. De kwaliteit volgde niet. Een taalmodel geeft een antwoord dat qua vorm klopt, en dat is niet hetzelfde als inhoudelijk kloppend, en dat gat wordt pas zichtbaar zodra de code tegen echte data draait, niet wanneer het plausibel oogt in de editor.

Vier AI-codeerfouten die stilletjes de kwaliteit slopen

1. Output vertrouwen omdat het compileert

Code die draait, is geen code die klopt. Een functie kan elke syntax-check doorstaan, voldoen aan het typesysteem, en toch het verkeerde doen bij precies die ene input die ertoe doet. Teams die stoppen met het lezen van gegenereerde code omdat "het werkt", scoren op het verkeerde criterium, en de mislukking wordt pas zichtbaar in productie, weken later, ver verwijderd van de commit die de oorzaak was.

2. De test overslaan omdat de AI het al checkte

Een model kan een test schrijven. Het kan zelf niet bepalen of die test daadwerkelijk het faalscenario test dat ertoe doet, of dat hij geschreven is om te slagen in plaats van om iets op te vangen. Een test die nooit kan falen, bewijst niets, en een team dat een door AI geschreven testsuite behandelt als verificatie, zonder te checken of de tests streng genoeg zijn om te falen, heeft alleen verificatie in naam.

3. De review-spier laten verslappen

Code kritisch lezen is een vaardigheid, en zoals elke vaardigheid verzwakt die zonder oefening. Een developer die stopt met het lastige werk zelf te schrijven, merkt ook niet meer wanneer gegenereerde code een sluiproute neemt die niet zal schalen, omdat het deel van het brein dat dat vroeger opving al maandenlang niet geoefend is. Het team wordt sneller en, stilletjes, slechter in precies het ding dat vroeger dure fouten opving voordat ze werden uitgeleverd.

4. Het model architectuurbeslissingen laten nemen

Een agent die gevraagd wordt een feature toe te voegen, doet dat op de meest lokaal logische manier, niet op de manier die past bij het systeem drie features verder. Niemand besloot dat de database een vierde ad-hoctabel moest krijgen, of dat deze service die andere direct moest aanroepen in plaats van via de interface die al het andere gebruikt. Het stapelde zich op, de ene plausibel ogende wijziging na de andere, omdat niemand verantwoordelijk was gesteld voor de vorm van het systeem als geheel.

AI weerspiegelt de discipline van wie hem gebruikt, en de verkeerde discipline wordt versterkt, niet gecorrigeerd.

Hoe scherper er echt uitziet

De oplossing is niet minder code met de hand schrijven en minder reviewen. Het is precies de omgekeerde discipline, consistent toegepast. Tests die daadwerkelijk kunnen falen, geen tests die geschreven zijn om te slagen. Mutatiechecks bij elke fix, zodat een reparatie die het gedrag bij een kapotte input niet verandert, wordt opgevangen voordat hij uitgeleverd wordt. Onafhankelijke, kritische reviewrondes naast de eigen tests van het team, zodat de agent die iets bouwde niet de enige is die beoordeelt of het klopt. Verificatie op het draaiende systeem, niet op een groene build, want een build kan groen zijn en toch fout zitten in precies dat ene geval dat er voor een echte klant toe doet.

Goed uitgevoerd, werkt één developer op het tempo van drie zonder de kwaliteit van nul. Slordig uitgevoerd, levert dezelfde opzet eerst snelheid en daarna onbeheersbare software op, en die rekening komt later binnen, in een systeem dat niemand meer helemaal begrijpt.

The ODB Way

Bij ODB Growth doen AI-agents de implementatie, analyse en review, binnen een proces dat gebouwd is om precies de vier fouten hierboven op te vangen. Architectuurbeslissingen, kwaliteitscriteria en de eindverantwoordelijkheid blijven bij de persoon die het werk heeft afgebakend, niet bij het model dat de diff schreef.

Dat is geen slogan. Het is de dagelijkse discipline achter elke opdracht: verifiëren voordat je vertrouwt, meten voordat je uitlevert, en nooit snelheid het oordeel laten vervangen over wat de software eigenlijk hoort te doen.