Hoe kan ik door AI gegenereerde code herkennen?

Door AI gegenereerde code oogt vaak overdreven netjes, met een consistente opmaak en uniforme structuur, inclusief generieke variabelnamen en keurige foutmeldingen. Let op overmatig commentaar dat voor de hand liggende codelogica herhaalt, evenals een gebrek aan domeinspecifieke terminologie of contextuele elementen.

Wat zijn de signalen dat AI-code te complex is?

Tekenen van overmatige complexiteit in AI-code zijn onder andere een overdaad aan hulpfuncties, onnodige abstractielagen en een focus op hypothetische scenario's in plaats van de daadwerkelijke vereisten. Door AI gegenereerde code probeert mogelijk te anticiperen op toekomstige behoeften in plaats van de huidige aan te pakken.

Waarom is foutafhandeling in AI-code een aandachtspunt?

Door AI gegenereerde foutafhandeling kan problematisch zijn als er gebruik wordt gemaakt van algemene uitzonderingsafhandeling of vage foutmeldingen, die de werkelijke problemen kunnen verbergen en het debuggen kunnen bemoeilijken. Goede foutafhandeling moet specifiek zijn en zinvolle context bieden.

Welke tests kunnen helpen bij het valideren van code die door AI is ontwikkeld?

Integratietests en tests van randgevallen zijn bijzonder effectief in het blootleggen van aannames die door AI gegenereerde code worden gemaakt. Ze kunnen problemen aan het licht brengen wanneer de code wordt blootgesteld aan onverwachte invoer of omstandigheden die de AI mogelijk niet had voorzien.

Hoe kan ik de betrouwbaarheid van door AI gegenereerde code verbeteren?

Om de betrouwbaarheid van door AI gegenereerde code te vergroten, kunt u specifieke beperkingen in uw prompts opnemen, om uitleg vragen over afwegingen, codevereenvoudiging stimuleren door onnodige complexiteit te verwijderen en tests implementeren die realistische scenario's weerspiegelen.

Welke gemeenschappelijke kenmerken hebben door AI gegenereerde namen?

Door AI gegenereerde namen zijn doorgaans technisch correct, maar passen mogelijk niet in de culturele context van uw project. Ze zijn vaak generiek en weerspiegelen niet de specifieke terminologie die binnen uw vakgebied wordt gebruikt.

Is het nuttig om tijdens codebeoordelingen te controleren of de code door AI is gegenereerd?

In plaats van je uitsluitend te richten op de vraag of de code door AI is gegenereerd, is het nuttiger om prioriteit te geven aan kwaliteit. Onderzoek de ontwerpfilosofie, de structuur en de testdekking en zorg ervoor dat de code aansluit op de systeemvereisten.

Wat is het belang van context in door AI gegenereerde code?

Context is cruciaal omdat AI vaak het genuanceerde begrip van reële beperkingen en bedrijfslogica mist. Door dit gebrek aan context lijkt AI-code weliswaar verfijnd, maar soms losgekoppeld van de daadwerkelijke operationele behoeften.

Hoe ziet AI-code eruit?

Kort antwoord: AI-ondersteunde code leest vaak ongewoon netjes en 'standaard': consistente opmaak, generieke namen, beleefde foutmeldingen en commentaar dat het voor de hand liggende herhaalt. Als de code echter de praktische kant van de wereld mist – domeinspecifieke taal, lastige beperkingen, uitzonderlijke gevallen – is dat een waarschuwingssignaal. Wanneer je de code verankert in de patronen van je repository en test op de risico's die inherent zijn aan de productieomgeving, wordt deze betrouwbaar.

Belangrijkste conclusies:

Contextcontrole: Als domeintermen, gegevensstructuren en beperkingen niet worden weergegeven, beschouw dit dan als riskant.

Overdreven gepolijst: Overmatige docstrings, een uniforme structuur en saaie namen kunnen wijzen op het genereren van generieke codes.

Foutafhandeling: Let op brede uitzonderingsafhandelingen, genegeerde fouten en vage logboekregistratie.

Abstractie-trim: Verwijder speculatieve hulplagen en lagen totdat alleen de kleinste correcte versie overblijft.

Realiteitstests: Voeg integratie- en randgevaltests toe; deze leggen snel de aannames van een "zuivere wereld" bloot.

AI-ondersteund programmeren is tegenwoordig overal (Stack Overflow Developer Survey 2025; GitHub Octoverse (28 okt. 2025)). Soms is het fantastisch en bespaart het je een middag. Andere keren is het... verdacht gepolijst, een beetje generiek, of het "werkt" totdat iemand op die ene knop klikt die niemand heeft getest 🙃. Dat leidt tot de vraag die mensen steeds weer stellen tijdens code reviews, sollicitatiegesprekken en privéberichten:

Hoe ziet AI-code er doorgaans uit?

Het directe antwoord is: het kan er op van alles uitzien. Maar er zijn patronen – subtiele signalen, geen bewijsmateriaal voor de rechter. Zie het als raden of een taart van een bakker komt of uit iemands keuken. De glazuurlaag kan perfect zijn, maar sommige thuisbakkers zijn gewoonweg angstaanjagend goed. Hetzelfde gevoel.

Hieronder vindt u een praktische handleiding voor het herkennen van veelvoorkomende AI-vingerafdrukken, het begrijpen van de oorzaken ervan en – belangrijker nog – hoe u door AI gegenereerde code kunt omzetten in code die u in een productieomgeving kunt vertrouwen ✅.

🔗 Hoe voorspelt AI trends?
Legt patroonherkenning, signalen en voorspellingen uit aan de hand van praktijkvoorbeelden.

🔗 Hoe detecteert AI afwijkingen?
Behandelt methoden voor het detecteren van uitschieters en veelvoorkomende zakelijke toepassingen.

🔗 Hoeveel water verbruikt AI?
Geeft een overzicht van het waterverbruik en de impact van trainingen in datacenters.

🔗 Wat is AI-bias?
Beschrijft de bronnen van vooringenomenheid, de schadelijke gevolgen ervan en praktische manieren om deze te verminderen.

1) Wat bedoelen mensen eigenlijk als ze het over "AI-code" hebben? 🤔

Als de meeste mensen "AI-code" zeggen, bedoelen ze meestal een van de volgende:

Code gegenereerd door een AI-assistent op basis van een prompt (functie, bugfix, refactoring).
De code werd grotendeels aangevuld door de automatische aanvulling, waarbij de ontwikkelaar weliswaar suggesties deed, maar de volledige tekst niet zelf schreef.
Code herschreven door AI voor "opschoning", "prestatieverbetering" of "stijlverbetering".
Code die eruitziet alsof het door een AI is gemaakt, ook al is dat niet zo (dit gebeurt vaker dan mensen toegeven).

En hier is een belangrijk punt: AI heeft niet één enkele stijl. Het heeft tendensen. Veel van die tendensen komen voort uit de poging om in grote lijnen correct, leesbaar en veilig te zijn... wat er ironisch genoeg voor kan zorgen dat de output een beetje eentonig aanvoelt.

2) Hoe AI-code er doorgaans uitziet: een snelle visuele weergave vertelt het je 👀

Laten we de titel direct beantwoorden: Hoe ziet AI-code er doorgaans uit?

Vaak ziet het eruit als code die:

Heel netjes volgens het boekje - consistente inspringing, consistente opmaak, alles is consistent.
Breedsprakig op een neutrale manier - veel "behulpzame" opmerkingen die niet veel helpen.
Te sterk gegeneraliseerd - ontworpen om tien denkbeeldige scenario's te verwerken in plaats van de twee reële.
Iets te complex gestructureerd - extra hulpfuncties, extra lagen, extra abstractie... alsof je drie koffers inpakt voor een weekendtrip 🧳.
Het ontbreken van de onhandige randgevallen die in echte systemen ontstaan (feature flags, eigenaardigheden van legacy-systemen, onhandige beperkingen) (Martin Fowler: Feature Toggles).

Maar ook – en ik blijf dit herhalen omdat het belangrijk is – menselijke ontwikkelaars kunnen absoluut ook zo schrijven. Sommige teams eisen het zelfs. Sommige mensen zijn gewoon perfectionisten. Dat zeg ik met liefde 😅.

In plaats van te proberen "AI te herkennen", is het beter om te vragen: gedraagt deze code zich alsof hij in een reële context is geschreven? Context is waar AI vaak de mist in gaat.

3) De "uncanny valley"-tekenen - wanneer het té netjes is 😬

Door AI gegenereerde code heeft vaak een zekere "glans". Niet altijd, maar vaak wel.

Veelvoorkomende signalen van “te netjes”

Elke functie heeft een docstring, zelfs als dat voor de hand ligt.
Alle variabelen hebben beleefde namen zoals result, data, items, payload, responseData.
Steeds terugkerende foutmeldingen die klinken als een handleiding: "Er is een fout opgetreden tijdens het verwerken van het verzoek."
Uniforme patronen in modules die niets met elkaar te maken hebben, alsof alles door dezelfde zorgvuldige bibliothecaris is geschreven.

De subtiele aanwijzing

AI-code voelt soms alsof het ontworpen is voor een tutorial, niet voor een product. Het is alsof je een pak aantrekt om een hek te schilderen. Heel netjes, maar toch een beetje misplaatst voor die kleding.

4) Wat maakt een goede versie van AI-code? ✅

Laten we het eens omdraaien. Want het doel is niet "AI vangen", maar "kwaliteit leveren"

Een goede versie van AI-ondersteunde code is:

Verankerd in uw werkelijke domein (uw naamgeving, uw gegevensstructuren, uw beperkingen).
Afgestemd op uw architectuur (patronen komen overeen met de repository, niet met een generieke sjabloon).
Getest op basis van uw risico's (niet alleen unit tests voor het ideale scenario) (Software Engineering bij Google: Unit Testing; De praktische testpiramide).
Gecontroleerd met een duidelijke intentie (iemand vroeg "waarom dit?" en niet alleen "of het compileert") (Google Engineering Practices: The Standard of Code Review).
Teruggebracht tot wat je nodig hebt (minder denkbeeldige toekomstbestendigheid).

Met andere woorden: goede AI-code ziet eruit alsof… jouw team het heeft geschreven. Of in ieder geval, jouw team het op de juiste manier heeft geïmplementeerd. Net als een reddingshond die nu weet waar de bank staat 🐶.

5) De patroonbibliotheek: klassieke AI-vingerafdrukken (en waarom ze ontstaan) 🧩

Hieronder vind je patronen die ik herhaaldelijk ben tegengekomen in codebases die door AI zijn gegenereerd, waaronder codebases die ik zelf heb opgeschoond. Sommige hiervan zijn prima. Sommige zijn gevaarlijk. De meeste zijn gewoon... signalen.

A) Overmatig defensief null-checken overal

Je ziet de volgende lagen:

als x None is: retourneer ...
try/except Uitzondering
meerdere terugvalstandaarden

Waarom: AI probeert runtimefouten zoveel mogelijk te voorkomen.
Risico: Het kan echte fouten maskeren en debuggen bemoeilijken.

B) Generieke hulpfuncties die hun bestaansrecht niet bewijzen

Leuk vinden:

process_data()
handle_request()
validate_input()

Waarom: abstractie voelt "professioneel" aan.
Risico: je krijgt functies die alles doen maar niets uitleggen.

C) Opmerkingen die de code herhalen

Voorbeeldenergie:

“Verhoog i met 1”
"Retourneer het antwoord"

Waarom: AI is getraind om uitleg te geven.
Risico: reacties verouderen snel en zorgen voor ruis.

D) Inconsistente detaillering

Het ene deel is buitengewoon gedetailleerd, het andere deel is mysterieus vaag.

Waarom: snelle afleiding… of gedeeltelijke context.
Risico: zwakke punten schuilen in de vage zones.

E) Verdacht symmetrische structuur

Alles volgt hetzelfde raamwerk, zelfs wanneer de bedrijfslogica dat niet zou moeten doen.

Waarom: AI herhaalt graag beproefde patronen.
Risico: de vereisten zijn niet symmetrisch, maar onregelmatig, zoals slecht verpakte boodschappen 🍅📦.

6) Vergelijkingstabel - manieren om te beoordelen hoe AI-code er doorgaans uitziet 🧪

Hieronder volgt een praktische vergelijking van tools. Geen "AI-detectoren", maar eerder code-realiteitschecks. Want de beste manier om twijfelachtige code te identificeren, is door deze te testen, te beoordelen en onder druk te observeren.

Hulpmiddel / Aanpak	Het meest geschikt voor (doelgroep)	Prijs	Waarom het werkt (en een klein eigenaardigheidje)
Checklist voor codebeoordeling 📝	Teams, leiders, senioren	Vrij	Dwingt tot het stellen van 'waarom'-vragen; herkent generieke patronen... voelt soms pietluttig aan (Google Engineering Practices: Code Review)
Eenheids- en integratietests ✅	Iedereen verzendt producten	Vrijwel gratis	Onthult ontbrekende randgevallen; AI-code mist vaak testomgevingen die in productieomgevingen worden gebruikt (Software Engineering bij Google: Unit Testing; De praktische testpiramide)
Statische analyse / Linting 🔍	Teams met standaarden	Gratis / Betaald	Signaleert inconsistenties; detecteert echter geen bugs die wijzen op een "verkeerd idee" (ESLint-documentatie; GitHub CodeQL-codescan).
Typecontrole (indien van toepassing) 🧷	Grotere codebases	Gratis / Betaald	Geeft vage gegevensstructuren weer; kan vervelend zijn, maar is de moeite waard (TypeScript: Statische typecontrole; mypy-documentatie).
Dreigingsmodellering / Misbruikgevallen 🛡️	Veiligheidsgerichte teams	Vrij	AI kan vijandig gebruik negeren; dit dwingt het aan het licht (OWASP Threat Modeling Cheat Sheet).
Prestatieprofilering ⏱️	Backend, data-intensief werk	Gratis / Betaald	AI kan extra lussen, conversies en toewijzingen toevoegen - profiling liegt niet (Python-documentatie: De Python-profilers).
Domeingerichte testgegevens 🧾	Product + engineering	Vrij	De snelste "geurtest": valse data wekken vals vertrouwen (zie de documentatie van pytest fixtures).
Review/Uitleg van het duo 👥	Mentoring + kritische PR's	Vrij	Vraag de auteur om de gemaakte keuzes toe te lichten; AI-achtige code mist vaak een verhaal (Software Engineering bij Google: Code Review)

Ja, de kolom 'Prijs' is een beetje vreemd, want het duurste onderdeel is meestal de aandacht, niet de gereedschappen. Aandacht kost... alles 😵💫.

7) Structurele aanwijzingen in door AI ondersteunde code 🧱

Wil je een dieper inzicht in hoe AI-code er doorgaans uitziet, kijk dan eens naar de structuur.

1) Een naamgeving die technisch correct is, maar cultureel onjuist

AI kiest doorgaans namen die "veilig" zijn voor meerdere projecten. Maar teams ontwikkelen hun eigen dialect:

Jij noemt het AccountId, de AI noemt het userId.
Jij noemt het LedgerEntry, de AI noemt het transactie.
Jij noemt het FeatureGate, hij noemt het configFlag.

Niets hiervan is "slecht", maar het geeft wel aan dat de auteur niet lang in jouw domein heeft gewoond.

2) Herhaling zonder hergebruik, of hergebruik zonder reden

AI soms:

herhaalt soortgelijke logica op meerdere plaatsen omdat het niet in één keer de volledige context van de repository "onthoudt", of
Dwingt hergebruik af door abstracties die weliswaar drie regels code besparen, maar later drie uur werk kosten.

Dat is de afweging: minder typen nu, meer nadenken later. En ik weet niet altijd zeker of dat een goede afweging is, denk ik… het hangt van de week af 😮💨.

3) “Perfecte” modulariteit die reële grenzen negeert

Je ziet de code opgesplitst in overzichtelijke modules:

validatoren/
diensten/
handlers/
utils/

Maar de grenzen komen mogelijk niet overeen met de naden van uw systeem. Een mens heeft de neiging de pijnpunten van de architectuur te weerspiegelen. AI heeft de neiging een overzichtelijk diagram te weerspiegelen.

8) Foutafhandeling - waar AI-code… lastig wordt 🧼

Foutafhandeling is een van de belangrijkste aanwijzingen, omdat het oordeelsvermogen, niet alleen correctheid.

Patronen om in de gaten te houden

Het opvangen van brede uitzonderingen met vage logboekregistratie (Pylint-documentatie: bare-except)
Fouten negeren en standaardwaarden teruggeven
Het retourneren van "succes: false" in plaats van het genereren van zinvolle foutmeldingen.
Herhaalloops zonder backoff of zonder maximum (of met een vreemd gekozen maximumwaarde zoals 3, omdat 3 prettig aanvoelt) (AWS Prescriptive Guidance: Retry with backoff; AWS Builders' Library: Timeouts, retries and backoff with jitter)

Hoe goed eruitziet

Storingen zijn specifiek
Fouten kunnen worden vervolgd.
Het loggen omvat contextinformatie (ID's, invoer, relevante status).
Gevoelige gegevens worden niet in logbestanden opgeslagen (AI vergeet dit soms 😬) (OWASP Logging Cheat Sheet; OWASP Top 10 2025: Security Logging and Alerting Failures)

Een typisch menselijke eigenschap is het schrijven van een foutmelding die een lichtelijk geïrriteerde toon heeft. Niet altijd, maar je herkent het wel als je het ziet. Foutmeldingen van AI zijn vaak kalm, net als een meditatie-app.

9) Randgevallen en productrealiteit - de "ontbrekende ruwheid" 🧠🪤

Echte systemen zijn rommelig. De output van AI mist vaak die textuur.

Voorbeelden van doorzettingsvermogen dat teams bezitten:

Functievlaggen en gedeeltelijke uitrol (Martin Fowler: Functieschakelaars)
Hacks voor achterwaartse compatibiliteit
Vreemde time-outs van derden
Verouderde gegevens die uw schema schenden
Problemen met inconsistente hoofdlettergebruik, codering of landinstellingen
Bedrijfsregels die willekeurig aanvoelen, omdat ze ook willekeurig zijn

AI kan uitzonderlijke gevallen afhandelen als je het dat aangeeft, maar als je ze niet expliciet opneemt, produceert het vaak een 'schone wereld'-oplossing. Schone werelden zijn prachtig. Maar schone werelden bestaan niet.

Een ietwat vergezochte metafoor volgt: AI-code is als een gloednieuwe spons – hij heeft de keukenrampen nog niet geabsorbeerd. Zo, ik heb het gezegd 🧽. Niet mijn beste werk, maar het klopt wel min of meer.

10) Hoe zorg je ervoor dat AI-ondersteunde code menselijk aanvoelt - en, nog belangrijker, betrouwbaar is? 🛠️✨

Als je AI gebruikt om code te schrijven (en veel mensen doen dat), kun je de output aanzienlijk verbeteren met een paar goede gewoonten.

A) Voeg uw beperkingen direct toe

Probeer in plaats van "Schrijf een functie die..." eens:

verwachte invoer/uitvoer
prestatiebehoeften
Foutbeleid (oproepen, resultaattype retourneren, loggen + falen?)
naamgevingsconventies
bestaande patronen in je repository

B) Vraag naar compromissen, niet alleen naar oplossingen

Vraag met:

“Geef twee benaderingen en leg de afwegingen uit.”
“Wat zou je hier liever niet doen en waarom?”
“Waar zal dit de productie onderbreken?”

AI presteert beter als je het dwingt om in risico's te denken.

C) Zorg ervoor dat het de code verwijdert

Serieus. Vraag:

“Verwijder alle overbodige abstracties.”
"Snijd dit terug tot de kleinst mogelijke, correcte versie."
Welke onderdelen zijn speculatief?

AI heeft de neiging om toe te voegen. Goede ingenieurs hebben de neiging om af te trekken.

D) Voeg tests toe die de realiteit weerspiegelen

Niet alleen:

"geeft de verwachte uitvoer terug"

Maar:

vreemde invoer
ontbrekende velden
gelijktijdigheid
gedeeltelijke storingen
gedrag op integratieniveau (Software Engineering bij Google: Grotere testmethoden; De praktische testpiramide)

Als je verder niets doet, doe dan dit. Tests zijn de leugendetector, en het maakt ze niet uit wie de code heeft geschreven 😌.

11) Afsluitende opmerkingen + korte samenvatting 🎯

Dus, hoe ziet AI-code er doorgaans uit? Vaak oogt het netjes, generiek, een beetje te gedetailleerd en iets te graag behulpzaam. Het grootste probleem zit hem niet in de opmaak of de commentaren, maar in het ontbreken van context: domeinnamen, lastige uitzonderingen en architectuurspecifieke keuzes die voortkomen uit de ervaring met een systeem.

Korte samenvatting

AI-code is niet uniform, maar neigt vaak naar een nette, uitgebreide en te algemene stijl.
Het beste signaal is of de code uw werkelijke beperkingen en producteigenschappen weerspiegelt.
Focus niet op detectie, maar op kwaliteit: testen, beoordeling, duidelijkheid en intentie (Google Engineering Practices: Code Review; Software Engineering at Google: Unit Testing).
AI is prima voor een eerste versie. Maar niet voor een definitieve versie. Dat is nu eenmaal het hele spel.

En als iemand je probeert te bekritiseren omdat je AI gebruikt, negeer het dan gewoon. Lever gewoon degelijke code af. Degelijke code is de enige manier om indruk te maken die standhoudt 💪🙂.

Praktisch voorbeeld: Het beoordelen van een door AI opgestelde bugfix voor het afrekenproces 🛒

Scenario

Stel je voor dat een klein e-commerceteam een AI-assistent gebruikt om een bugfix te schrijven voor een probleem in het afrekenproces: klanten worden soms twee keer gefactureerd wanneer een betalingsprovider een time-out geeft en er op de knop 'opnieuw proberen' wordt geklikt.

De eerste AI-versie ziet er netjes uit. Er is een helper voor het opnieuw proberen toegevoegd, de betalingsoproep is omwikkeld met brede foutafhandeling en er wordt een beleefde melding teruggestuurd als er iets misgaat. Op het eerste gezicht voelt het professioneel aan. Maar het risico schuilt net onder de oppervlakte: de code controleert niet of de eerste betalingspoging mogelijk al is geslaagd.

Dat is precies waar AI-ondersteunde code productiedruk nodig heeft. Het probleem is niet dat de code er "door AI geschreven" uitziet. Het probleem is dat de code uitgaat van een schone wereld waarin een time-out betekent dat "er niets is gebeurd".

Wat de assistent nodig heeft

Voordat je de AI vraagt om de bug te verhelpen, geef haar dan de essentiële details:

De betalingsprovider kan na 8 seconden een time-out geven.
Een time-out bewijst niet dat de betaling is mislukt.
Elke bestelling heeft een uniek orderId en idempotencyKey.
De bestaande repository gebruikt PaymentAttempt, niet transaction.
Mislukte betalingen moeten worden geregistreerd met orderId, providerRequestId en retryCount.
Er mogen geen kaartgegevens of persoonlijke informatie in de logbestanden voorkomen.
De oplossing moet tests bevatten voor dubbele klikken, time-outs van de provider en gedeeltelijke fouten.

Voorbeeldinstructie

Gebruik de bestaande checkout-servicepatronen om een bug met dubbele afschrijving te verhelpen. Maak geen generieke retry-wrapper aan, tenzij dit noodzakelijk is. Beschouw time-outs van de betalingsprovider als een onbekende status, niet als mislukte betalingen. Gebruik de bestaande PaymentAttempt-naamgeving. Voeg een idempotentiecontrole toe met behulp van orderId en idempotencyKey. Neem tests op voor: één succesvolle betaling, time-out gevolgd door een nieuwe poging, dubbele knopklik, succes van de provider na een time-out van de client en een ontbrekende providerRequestId. Houd de oplossing zo compact mogelijk en leg uit waar dit in een productieomgeving nog steeds mis kan gaan.

Hoe test je het?

Een reviewer zou vijf eenvoudige controles kunnen uitvoeren voordat hij de door AI ondersteunde code goedkeurt:

Dien tweemaal hetzelfde afrekenverzoek in met dezelfde idempotencyKey.
Simuleer een time-out van de provider, waarbij de provider later bevestigt dat het gelukt is.
Simuleer een nieuwe poging na een time-out en bevestig dat er geen tweede transactie wordt aangemaakt.
Controleer de logbestanden op de juiste foutopsporingsvelden zonder gevoelige gegevens te lekken.
Vraag de auteur uit te leggen waarom de logica voor het opnieuw proberen in deze laag thuishoort in plaats van in een algemene utility.

Een zwakke AI-implementatie kan het 'happy path'-scenario doorlopen, maar falen in het geval van een time-out gevolgd door succes. Dat is de aanname van een 'schone wereld' die in de testfase naar voren komt.

Resultaat

Illustratief resultaat: gebaseerd op de tijd die nodig was voor een review van vijf gevallen voor deze fictieve bug in het afrekenproces, duurde het ongeveer 20 minuten om het AI-concept te produceren, maar de eerste versie miste 2 van de 5 vereiste tests: afhandeling van dubbele klikken en afhandeling van succesvolle betalingen door de provider na een time-out.

Na het toevoegen van de bovenstaande domeinbeperkingen omvatte de herziene versie alle 5 testgevallen en waren er minder handmatige opmerkingen nodig: 9 opmerkingen bij de eerste versie versus 3 opmerkingen bij de versie met beperkingen. De totale tijd voor beoordeling en herziening daalde van naar schatting 55 minuten naar 32 minuten.

Dit is geen bewezen maatstaf. Het is een voorbeeldschatting die een team zou kunnen verifiëren door drie getallen bij te houden tijdens het uitvoeren van pull requests: de tijd tussen concept en goedgekeurde pull request, het aantal opmerkingen van reviewers en het aantal mislukte tests in uitzonderlijke gevallen.

Wat kan er misgaan?

De gevaarlijkste fout is om de AI een "time-out" te laten interpreteren als een "fout". In betalingssystemen, e-mailbezorging, boekingsplatformen, voorraadupdates en achtergrondtaken kan die aanname leiden tot dubbele acties.

Andere veelvoorkomende problemen:

De AI verzint een nieuwe term zoals 'transactie' wanneer de repo gebruikmaakt van 'PaymentAttempt'.
Het systeem detecteert algemene fouten en geeft een vriendelijke melding terug, terwijl de onderliggende fout verborgen blijft.
Het voegt een herbruikbare helperfunctie voor het opnieuw proberen toe, die andere ontwikkelaars kunnen kopiëren naar plekken waar het opnieuw proberen onveilig is.
Het registreert te veel context en voegt per ongeluk gevoelige klant- of betaalgegevens toe.
Het schrijft tests die bewijzen dat de code alleen werkt als elke afhankelijkheid zich perfect gedraagt.

Praktische tips

De beste manier om AI-ondersteunde code veiliger te maken, is door eerst de essentiële feiten aan te leveren: echte namen, echte foutscenario's, echte logbestanden, echte testgevallen en echte beperkingen. AI kan snel een overzichtelijke versie opstellen. Jouw taak is om de details voor productie toe te voegen voordat de code wordt samengevoegd.

Veelgestelde vragen

Hoe kun je zien of code door AI is geschreven?

Door AI gegenereerde code ziet er vaak wat te netjes uit, bijna "leerboekachtig": consistente opmaak, uniforme structuur, generieke namen (zoals data, items, result) en evenwichtige, gepolijste foutmeldingen. Het kan echter ook gepaard gaan met een wirwar aan docstrings of commentaren die simpelweg voor de hand liggende logica herhalen. Het belangrijkste signaal is niet de stijl, maar de afwezigheid van de rauwe realiteit: domeinspecifieke taal, repositoryconventies, onhandige beperkingen en de cruciale elementen die systemen bij elkaar houden.

Wat zijn de grootste waarschuwingssignalen bij foutafhandeling door AI?

Let op brede exception catch-blokken (zoals `except Exception`), fouten die worden genegeerd en stilletjes een standaardwaarde teruggeven, en vage logberichten zoals "Er is een fout opgetreden". Deze patronen kunnen echte bugs verbergen en het debuggen bemoeilijken. Een goede foutafhandeling is specifiek, bruikbaar en bevat voldoende context (ID's, invoer, status) zonder gevoelige gegevens in logs te dumpen. Te defensief zijn kan net zo riskant zijn als te weinig defensief zijn.

Waarom voelt AI-code vaak te complex of te abstract aan?

Een veelvoorkomende neiging bij AI is om "professioneel over te komen" door hulpfuncties, lagen en mappen toe te voegen die anticiperen op hypothetische toekomsten. Je ziet generieke hulpfuncties zoals process_data() of handle_request() en nette modulegrenzen die beter passen bij een diagram dan bij de structuur van je systeem. Een praktische oplossing is het verwijderen van overbodige lagen: schrap speculatieve lagen totdat je de kleinste correcte versie overhoudt die voldoet aan de huidige eisen, niet aan de eisen die je later mogelijk zult krijgen.

Hoe ziet goede, door AI ondersteunde code eruit in een echte repository?

De beste door AI ondersteunde code leest alsof uw team er zelf aan heeft gewerkt: de code gebruikt uw domeintermen, komt overeen met uw datastructuren, volgt uw repositorypatronen en sluit aan op uw architectuur. Bovendien weerspiegelt de code uw risico's – verder dan alleen de ideale scenario's – met zinvolle tests en een gerichte codebeoordeling. Het doel is niet om "AI te verbergen", maar om het concept in de juiste context te plaatsen, zodat het zich gedraagt als productiecode.

Welke tests leggen de aannames over een 'schone wereld' het snelst bloot?

Integratietests en tests voor randgevallen brengen problemen snel aan het licht, omdat de output van AI vaak uitgaat van ideale invoer en voorspelbare afhankelijkheden. Gebruik domeinspecifieke testomgevingen en neem ongebruikelijke invoer, ontbrekende velden, gedeeltelijke fouten, time-outs en gelijktijdigheid op waar dat relevant is. Als de code alleen unit-tests voor het 'happy path'-scenario bevat, kan deze er correct uitzien, terwijl er toch een fout optreedt wanneer iemand in productie op een ongeteste knop drukt.

Waarom voelen door AI gegenereerde namen "technisch correct maar cultureel onjuist" aan?

AI kiest vaak voor veilige, generieke namen die in veel projecten werken, maar teams ontwikkelen na verloop van tijd een specifiek dialect. Zo ontstaan er inconsistenties zoals userId versus AccountId, of transaction versus LedgerEntry, zelfs als de logica correct is. Deze naamgevingsafwijking is een aanwijzing dat de code niet is geschreven met de specifieke domeinen en beperkingen van het systeem in gedachten.

Is het de moeite waard om te proberen AI-code te detecteren tijdens codebeoordelingen?

Het is doorgaans productiever om te controleren op kwaliteit dan op auteurschap. Mensen kunnen ook schone, maar overmatig van commentaar voorziene code schrijven, en AI kan uitstekende concepten produceren wanneer deze wordt aangestuurd. In plaats van detective te spelen, focus je op de ontwerpfilosofie en de waarschijnlijke faalpunten in de productieomgeving. Valideer vervolgens met tests, architectuurafstemming en foutdiscipline. Testen onder druk is effectiever dan testen op gevoel.

Hoe kun je AI ertoe aanzetten om betrouwbaardere code te produceren?

Begin met het vooraf definiëren van beperkingen: verwachte invoer/uitvoer, gegevensstructuren, prestatie-eisen, foutbeleid, naamgevingsconventies en bestaande patronen in je repository. Vraag naar afwegingen, niet alleen naar oplossingen: "Waar gaat dit mis?" en "Wat zou je vermijden en waarom?" Dwing ten slotte aftrekking af: geef aan dat onnodige abstractie moet worden verwijderd en dat de kleinst mogelijke correcte versie moet worden geproduceerd voordat er iets wordt uitgebreid.

Referenties

Stack Overflow - Stack Overflow Developer Survey 2025 - survey.stackoverflow.co
GitHub - GitHub Octoverse (28 oktober 2025) - github.blog
Google - Google Engineering Practices: De standaard voor codebeoordeling - google.github.io
Abseil - Software-engineering bij Google: Unit Testing - abseil.io
Abseil - Software Engineering bij Google: Code Review - abseil.io
Abseil - Software-engineering bij Google: grotere tests - abseil.io
Martin Fowler - Martin Fowler: Functieschakelaars - martinfowler.com
Martin Fowler - De piramide van de praktische toets - martinfowler.com
OWASP - OWASP Threat Modeling Cheat Sheet - cheatsheetseries.owasp.org
OWASP - OWASP Logging Cheat Sheet - cheatsheetseries.owasp.org
OWASP - OWASP Top 10 2025: Fouten in beveiligingslogboekregistratie en -waarschuwingen - owasp.org
ESLint - ESLint-documentatie - eslint.org
GitHub-documentatie - Code scannen met GitHub CodeQL - docs.github.com
TypeScript - TypeScript: Statische typecontrole - www.typescriptlang.org
mypy - mypy-documentatie - mypy.readthedocs.io
Python - Python-documentatie: De Python-profilers - docs.python.org
pytest - documentatie over pytest-fixtures - docs.pytest.org
Pylint - Pylint-documentatie: bare-except - pylint.pycqa.org
Amazon Web Services - AWS Prescriptive Guidance: Retry with backoff - docs.aws.amazon.com
Amazon Web Services - AWS Builders' Library: Time-outs, herhaalpogingen en backoff met jitter - aws.amazon.com

Vind de nieuwste AI in de officiële AI Assistant Store

Over ons

Terug naar de blog