Hoe ziet AI-code eruit?

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.

Hoe ziet AI-code eruit? Infographic

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:

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

Hoe goed eruitziet

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:

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 💪🙂.

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

  1. Stack Overflow - Stack Overflow Developer Survey 2025 - survey.stackoverflow.co

  2. GitHub - GitHub Octoverse (28 oktober 2025) - github.blog

  3. Google - Google Engineering Practices: De standaard voor codebeoordeling - google.github.io

  4. Abseil - Software-engineering bij Google: Unit Testing - abseil.io

  5. Abseil - Software Engineering bij Google: Code Review - abseil.io

  6. Abseil - Software-engineering bij Google: grotere tests - abseil.io

  7. Martin Fowler - Martin Fowler: Functieschakelaars - martinfowler.com

  8. Martin Fowler - De piramide van de praktische toets - martinfowler.com

  9. OWASP - OWASP Threat Modeling Cheat Sheet - cheatsheetseries.owasp.org

  10. OWASP - OWASP Logging Cheat Sheet - cheatsheetseries.owasp.org

  11. OWASP - OWASP Top 10 2025: Fouten in beveiligingslogboekregistratie en -waarschuwingen - owasp.org

  12. ESLint - ESLint-documentatie - eslint.org

  13. GitHub-documentatie - Code scannen met GitHub CodeQL - docs.github.com

  14. TypeScript - TypeScript: Statische typecontrole - www.typescriptlang.org

  15. mypy - mypy-documentatie - mypy.readthedocs.io

  16. Python - Python-documentatie: De Python-profilers - docs.python.org

  17. pytest - documentatie over pytest-fixtures - docs.pytest.org

  18. Pylint - Pylint-documentatie: bare-except - pylint.pycqa.org

  19. Amazon Web Services - AWS Prescriptive Guidance: Retry with backoff - docs.aws.amazon.com

  20. 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