AI-code controleren zonder programmeerkennis: 7 controles

AI heeft op één avond een website of bot voor je gebouwd. Alles opent, de knoppen werken en het lijkt te draaien. Je laat het project aan mensen zien — en een dag later ontdek je dat het betalingsformulier geld afschrijft, maar dat de bestellingen nooit binnenkomen. Of dat de database met telefoonnummers van klanten voor het hele internet openstaat.

Ik lanceerde mijn eerste projecten vroeger ook op die manier: dingen die leken te werken, verrasten echte gebruikers. Nu loop ik het project vóór ik iets aan mensen laat zien langs dezelfde checklist. Ik lees daarbij geen enkele regel code — daarvoor ben ik hier niet, en jij waarschijnlijk ook niet.

En dit is geen paranoia. Anthropic analyseerde 400,000 Claude Code-sessies: in zeven maanden daalde het aandeel werk dat werd besteed aan het repareren van kapotte code van 33% naar 19%. Het daalde, maar verdween niet. Nog altijd gaat elke vijfde sessie over “repareren wat de AI kapot heeft gemaakt”.

Code schrijven zelf is niet langer het knelpunt. Het draait er nu om hoe goed je de taak begrijpt en hoe goed je het resultaat kunt controleren.

Aanvullend materiaal over het instellen van tools vind je in de Ailoot-documentatie.

Waarom AI-gegenereerde code controleren als die al werkt?#

AI schrijft code die er op het eerste gezicht goed uitziet. De code draait, het scherm wordt weergegeven en de demo is overtuigend. Maar door de code te lanceren kom je er niet achter of geld correct wordt berekend, of je database van buitenaf toegankelijk is, of dat alles crasht zodra de honderdste gebruiker arriveert.

De cijfers bevestigen dit. De FrontierCode-benchmark onderzocht in juni 2026 hoe geschikt AI-gegenereerde code zonder aanpassingen was voor echt werk. Zelfs bij de beste modellen voor de moeilijkste taken was dat aandeel ongeveer 13%. Met andere woorden: voor serieuze taken moet de meeste AI-gegenereerde code handmatig worden verfijnd voordat je erop kunt vertrouwen.

Het goede nieuws is dat iedereen de controle kan uitvoeren. Dit concludeerde Anthropic uit diezelfde 400,000 sessies:

Je voordeel ten opzichte van een programmeur die je erbij haalt, is dat jij je taak begrijpt. Controleren draait ook om begrip; je hoeft er geen code voor te lezen. De controles hieronder kun je precies zelf uitvoeren, zonder gedoe.

Wat kan er echt misgaan met AI-gegenereerde code?#

Voordat je gaat controleren, is het handig om te weten waarnaar je op zoek bent. AI-gegenereerde code heeft vijf typische problemen. Je kunt ze alle vijf herkennen zonder code te lezen, door te kijken hoe het project zich gedraagt.

Hierna volgen zeven controles, op volgorde. De eerste vangen problemen op waarbij iets “niet werkt” of “verkeerd werkt”; de middelste gaan over beveiliging en verzinsels; de laatste zijn voorzorgsmaatregelen voordat je publiceert. Je kunt ze het beste in volgorde doorlopen: elke controle bouwt voort op de vorige.

Controle 1: Vraag de AI om de code in gewone taal uit te leggen#

Je hebt de taak in woorden beschreven. De AI heeft die naar code vertaald. Tussen die twee stappen kan betekenis verloren gaan: de AI heeft je misschien anders begrepen, dingen voor je ingevuld of bochten afgesneden. Je kunt de mismatch opsporen zonder code te lezen — vraag hem gewoon in gewone taal te beschrijven wat hij heeft gedaan.

Leg in gewone taal en zonder code precies uit wat je zojuist hebt gedaan:

welke taak deze code oplost

wat er gebeurt wanneer een gebruiker op de knop klikt of het formulier verzendt

waar de gegevens worden opgeslagen en wie er toegang toe heeft

wat er mis kan gaan en in welke situatie

Schrijf alsof je het uitlegt aan iemand die nog nooit heeft geprogrammeerd. Als er iets is waarvan je niet zeker weet of het klopt, zeg dat dan duidelijk.

Lees het antwoord en vergelijk het met wat je zelf voor ogen had. Komt het overeen, ga dan verder. Als de AI “om de hete brij heen draait”, in zijn eigen uitleg in de war raakt of iets anders beschrijft dan je hebt gevraagd, begrijpt hij niet helemaal wat hij heeft gebouwd. Laat hem het met een verduidelijking aanpassen in plaats van hem op zijn woord te geloven.

Trouwens, als de AI regelmatig iets anders doet dan je hebt gevraagd, ligt dat vaak aan de manier waarop de taak is geformuleerd en niet aan het model zelf. Ik heb een aparte uitleg over waarom Claude niet doet wat je vraagt.

De uitvoer van AI controleren is onderdeel van context engineering: je bepaalt zowel wat je als invoer aan de AI geeft als hoe je het resultaat als uitvoer beoordeelt.

Controle 2: Doorloop de scenario’s zoals een echte gebruiker dat zou doen#

Een AI-demo volgt altijd het ideale pad: correcte gegevens, één klik en alles gaat goed. Een echte gebruiker gedraagt zich niet zo. Mensen maken fouten, klikken op het verkeerde ding of voeren een emoji in het telefoonnummer in. Jouw taak is om het project te gebruiken zoals zij dat zouden doen.

1. Doorloop het belangrijkste scenario van begin tot eind

   Doe waarvoor het project bestaat: registreer je, plaats een bestelling, verstuur een aanvraag. Ga helemaal door tot het einde, niet slechts tot halverwege.

2. Controleer de betaling apart en in de praktijk

   Als het project geld accepteert, voer dan zelf een betaling uit voor het minimale bedrag in de testmodus. Controleer of de bestelling wordt aangemaakt, de status verandert en er een e-mail naar jou en de klant gaat. Een betaling die “doorgaat” maar geen bestelling aanmaakt, is een klassieke stille fout.

3. Zorg bewust voor problemen

   Laat velden leeg. Voer letters in waar cijfers worden verwacht. Klik twee keer achter elkaar op “Verzenden”. Upload een bestand met een verkeerd formaat. Een goed project zegt beleefd “dat kan niet”; een slecht project crasht of slikt de gegevens ongemerkt in.

4. Open het op een telefoon

   De helft van je mensen komt via een telefoon. Controleer of de lay-out intact is en of dezelfde knoppen daar ook werken.

Geef de AI alles wat je hebt gevonden in één lijst: “Dit ging er in deze stappen mis; herstel het en leg uit waarom het gebeurde.” Pak problemen niet één voor één aan — geef de AI de lijst, zodat hij het hele plaatje kan zien en minder snel één ding kapotmaakt terwijl hij iets anders repareert.

Controle 3: Vraag de AI naar beveiliging — hier is een prompt#

Een kapotte knop valt meteen op. Een beveiligingslek niet: het project blijft werken alsof er niets aan de hand is, totdat iemand er misbruik van maakt. De meest voorkomende problemen in vibe-coded projecten zijn geheime sleutels die rechtstreeks in de code staan, een database die aan het internet is blootgesteld en formulieren waarmee iemand schadelijke invoer kan versturen. De AI kan dit allemaal vinden als je er rechtstreeks naar vraagt.

Voer een audit uit op beveiligingsproblemen in dit project en leg elke bevinding in gewone taal uit, zonder jargon. Loop deze lijst na:

Controleer of geheime sleutels, wachtwoorden of tokens rechtstreeks in de code staan. Privégeheimen mogen alleen op de server worden gebruikt, met lokale geheime configuratie zoals .env buiten Git. Een .env-bestand en .gitignore voorkomen niet dat frontend-/public-variabelen in de browserbuild terechtkomen. Bekijk de echte JavaScript, sourcemaps, HTML en netwerkantwoorden voor de client en controleer dat privésleutels ontbreken.

Controleer of de database aan het internet is blootgesteld en wie er toegang toe heeft.

Controleer of invoer de formulieren kan breken: injecties in databasequery’s of extra code in tekstvelden.

Wat gebeurt er als een gebruiker schadelijke gegevens verstuurt?

Controleer of interne pagina’s of het beheerderspaneel zonder wachtwoord toegankelijk zijn.

Geef voor elk punt aan of er een probleem is, geef een duidelijk voorbeeld van het risico en leg uit hoe je het kunt oplossen. Begin met het gevaarlijkste probleem.

Controleer ook of je project niet blindelings alles uitvoert wat het van buitenaf ontvangt. Dit heet indirecte promptinjectie: er wordt een opdracht verstopt in een e-mail, opmerking of bestand van iemand anders, waarna je AI-agent die uitvoert omdat hij denkt dat het een taak is. Als het project externe gegevens leest en ernaar handelt, vraag de AI dan wat er zou gebeuren als die gegevens een verborgen instructie bevatten.

Dit is een diepgaand onderwerp en één prompt kan het niet volledig behandelen. Als het project geld of persoonsgegevens van klanten verwerkt, lees dan de aparte gids over beveiliging bij vibe-coding.

Controle 4: Heeft de AI bibliotheken of gegevens verzonnen?#

De AI schrijft vol vertrouwen dingen die niet bestaan. Hij kan een bibliotheek met een aannemelijke naam toevoegen die in werkelijkheid niet bestaat. Hij kan testplaatsaanduidingen in het project laten staan: een product met de naam “Example”, het e-mailadres example@example.com of opvultekst in plaats van echte inhoud. In een demo zie je dat gemakkelijk over het hoofd, maar voor een echte gebruiker is het gênant of werkt het niet.

Je kunt dit in twee stappen opsporen. Vraag eerst rechtstreeks:

Loop het project na en controleer eerlijk:

Bestaan alle externe tools en bibliotheken die je hebt toegevoegd echt en kunnen ze correct worden geïnstalleerd? Heb je iets verzonnen?

Staan er nog testplaatsaanduidingen, voorbeelden of opvultekst in plaats van echte gegevens?

Zijn alle links, adressen en contactgegevens in het project echt en geen plaatsaanduidingen?

Noem wat je hebt gevonden en stel voor waardoor je het kunt vervangen.

Voer het project vervolgens gewoon uit en bekijk het. Een verzonnen bibliotheek veroorzaakt bijna altijd een fout bij het opstarten. En plaatsaanduidingen zijn gemakkelijk te zien: als er “Product 1” op de pagina staat, heb je ze niet vervangen.

Verzonnen bibliotheken vormen een apart gevaar, omdat aanvallers bewust tools registreren met namen die AI graag verzint. Installeer je er een, dan komt de code van iemand anders in je project terecht. Neem de vraag “bestaat deze bibliotheek eigenlijk wel?” daarom serieus — die gaat rechtstreeks over de beveiliging van je project.

Controle 5: Laat een tweede model het eerste controleren#

AI heeft een vervelende eigenschap: hij stemt in. Vraag “is alles hier in orde?” en hij zal bevestigen dat alles in orde is, omdat hij zich aanpast aan het antwoord dat hij verwacht. Dit heet AI-sycophantie, en ik heb er apart over geschreven. Zo’n gesprekspartner zal mild zijn voor zijn eigen werk.

De oplossing is eenvoudig: vraag om een tweede mening. Open een nieuwe sessie of gebruik een ander model en geef het project om te controleren met dezelfde prompt als bij Controle 3, met één toevoeging: “een andere AI heeft deze code geschreven; zoek de zwakke punten.” Een vers model zit niet vast aan het eerdere gesprek en zal problemen eerder aanwijzen.

1. Open een schone sessie of gebruik een ander model

   Gebruik een tweede model, of hetzelfde model in een nieuw venster zonder taakgeschiedenis.

2. Geef het model het project en de juiste formulering

   Zeg duidelijk: “een andere AI heeft deze code geschreven; het is jouw taak om fouten en risico’s te vinden, niet om hem te prijzen.” Dat remt sycophantie af.

3. Vergelijk de twee meningen

   Als beide het eens zijn, hebben ze waarschijnlijk gelijk. Als ze het oneens zijn, onderzoek dat punt — daar wordt het interessant.

Dit is precies wat er nu in de sector gebeurt: AI schrijft, AI controleert en de uiteindelijke beslissing blijft bij een mens. Je kunt dat niet aan het model overlaten — dat is jouw taak.

Controle 6: Hoe kun je wijzigingen terugdraaien als er iets kapotgaat?#

De controles op deze lijst leiden vaak tot wijzigingen, en die wijzigingen maken soms iets kapot dat eerst werkte. Om te voorkomen dat dit een ramp wordt, sla je vóór elke ronde met aanpassingen de werkende versie op in git. Het is net als een spel opslaan: als je iets kapotmaakt, laad je het laatste opslagpunt.

Je hoeft hiervoor geen code te lezen. Vraag de AI gewoon: “sla de huidige werkende versie in git op met een duidelijk label voordat je iets verandert.” En als alles na de wijzigingen misgaat: “zet het project terug naar de eerder opgeslagen versie.”

Als git nog onbekend terrein voor je is, heb ik twee gidsen voor je: wijzigingen terugdraaien in Claude Code en wat je moet doen als AI je database heeft verwijderd. De tweede is bedoeld voor als het al te laat is om terug te draaien, maar herstel nog wel mogelijk is.

Controle 7: Wat moet je als laatste controleren voordat je publiceert?#

De eerste zes controles gaan over wat de code doet. De zevende gaat erover of het project klaar is om mensen te ontmoeten. Hier struikelen mensen het vaakst: het project werkt, maar ze zijn vergeten de betaling van de testsleutel naar de live sleutel om te zetten, waardoor de eerste klanten “voor spek en bonen” betalen.

1. Betaling: van test naar live

   Als je betalingen accepteert, controleer dan of de live sleutel van het betalingssysteem is gekoppeld en niet de testsleutel. Doe één echte betaling voor het minimale bedrag en stort die terug aan jezelf.

2. Geheime gegevens staan op de juiste plek

   Vraag de AI: “Worden privésleutels alleen op de server gebruikt en is .env uitgesloten van Git? Bevat de echte browserbuild of een clientantwoord een privésleutel, ook via frontend-/public-variabelen of sourcemaps?” Controleer gebouwde bestanden en browsernetwerkantwoorden, niet alleen het bronbestand .env. Git-uitsluiting houdt een waarde niet buiten een frontendbundel.

3. Maak een back-up van de gegevens

   Zorg dat de database ergens automatisch wordt opgeslagen. Als je project op je eigen server draait, leg ik in de Coolify-gids uit hoe je het publiceert.

4. Publicatie werkt ook buiten je eigen apparaat

   Open het project op je telefoon via een externe link, niet alleen op je eigen computer. Iets wat lokaal werkt, werkt niet altijd na publicatie.

Doorloop alle vier de punten en je kunt het project met een gerust hart aan mensen laten zien. Als iets niet klopt, kun je beter nu een halfuur besteden dan later met ontevreden klanten te maken krijgen.

Wat als controleren te lang duurt — moet je de AI dan maar vertrouwen?#

Ik begrijp de verleiding. Controleren voelt saai en “niet waarvoor ik AI heb genomen”. Maar jij, niet het model, bent verantwoordelijk voor het resultaat. AI heeft geen reputatie en ondervindt geen gevolgen: hij heeft de code gemaakt en is die weer vergeten. Jij bent degene die antwoord moet geven aan een klant bij wie de betaling niet is gelukt.

De maker van Claude Code kijkt nog breder:

Code schrijven is niet langer het knelpunt — AI heeft dat overgenomen. Waarde ligt nu ergens anders: in de taak begrijpen en controleren wat eruit is gekomen. Dat is jouw kracht: jij weet beter dan welke externe ontwikkelaar ook wat het resultaat voor je klant moet zijn.

Waarom is controleren een vaardigheid en geen eenmalige taak?#

Deze zeven controles vormen het minimum dat het verschil maakt tussen “ik heb het gelanceerd en hoop dat het werkt” en “ik heb het gelanceerd en weet dat het werkt”. Loop ze één keer door en je vangt al de meeste verrassingen op voordat je klanten dat doen.

Daarna wordt het een gewoonte. Geef de AI de juiste context als invoer en controleer het resultaat als uitvoer. Dan komt elk nieuw project sneller tot stand, omdat je niet vanaf nul begint.

Vind aanvullend materiaal over werken met tools in de Ailoot-documentatie.