Hoe je door AI gegenereerde code beoordeelt

Om door AI gegenereerde code te beoordelen, begin je met wat er is veranderd — welke bestanden en waarom — en test je daarna zelf het gedrag voordat je ook maar één regel code leest. Daarna controleer je de gebieden waar AI-code het vaakst misgaat: ontbrekende rechtencontroles aan de serverkant, geheimen die aan de browser worden blootgesteld, niet-gevalideerde invoer, pakketten of functies die niet bestaan, en wijzigingen aan dingen die je nooit hebt gevraagd aan te raken.

AI schrijft code die meestal werkt en vaak er netjes uitziet. Dat maakt het makkelijk om iets goed te keuren zonder het echt na te kijken. Deze gids is een beoordelingsroutine die werkt, of je code vloeiend leest of helemaal niet.

Pas de beoordeling aan het risico aan

Niet elke wijziging vraagt om dezelfde aandacht.

Stap 1: Zie wat er is veranderd

Voordat je de code beoordeelt, haal je de lijst met wijzigingen op:

• Staat het project in Git, bekijk dan de diff: de bestanden en regels die sinds de laatste commit zijn veranderd. Zie hoe je Git gebruikt met een door AI gebouwde app.
• Of vraag de AI direct:

Noem elk bestand dat je in de laatste wijziging hebt aangepast, en leg voor elk in één zin uit wat er is veranderd en waarom.

Rode vlaggen in deze fase: bestanden die niets met het verzoek te maken hebben, verwijderde bestanden, wijzigingen aan configuratie of afhankelijkheden die je niet had gevraagd.

Stap 2: Test eerst het gedrag

Code lezen vertelt je wat het bedoeld is; testen vertelt je wat het doet. Voordat je leest:

• Probeer de wijziging als gewone gebruiker, op desktop en op een telefoonscherm.
• Probeer het met verkeerde invoer: lege velden, zeer lange tekst, negatieve getallen, een datum in het verleden.
• Probeer het uitgelogd, en als een andere gebruiker.
• Doorloop de flows die het meest tellen opnieuw: aanmelden, inloggen, de belangrijkste actie, betaling.

Als testen mislukt, heb je leestijd bespaard — meld het duidelijk en laat de AI het oplossen. Zie hoe je een goed bugrapport schrijft.

Stap 3: Controleer rechten op de server

Dit is het belangrijkste om te controleren. AI-tools verbergen vaak een knop in de pagina, maar laten de server de actie toch uitvoeren voor iedereen die erom vraagt.

Vraag bij elke route of functie die gegevens leest of wijzigt:

• Controleert hij of de gebruiker is ingelogd?
• Controleert hij of deze gebruiker toegang mag hebben tot dit record?
• Staat die controle op de server, en niet alleen in de pagina?

Vertel bij elke API-route die je hebt toegevoegd of gewijzigd welke rechtencontrole die aan de serverkant doet, en citeer de regel. Markeer elke route zonder controle.

Test het daarna: meld je aan als gebruiker A, noteer het ID van een record, meld je aan als gebruiker B en vraag het op. De beveiligingschecklist voor door AI gebouwde apps bevat de volledige test.

Stap 4: Zoek naar blootgestelde geheimen

• Zoek in de gewijzigde bestanden naar alles wat op een sleutel of wachtwoord lijkt.
• Controleer of geheime sleutels uit omgevingsvariabelen worden gelezen en alleen in servercode worden gebruikt.
• Let op publieke voorvoegsels zoals VITE_ of NEXT_PUBLIC_ bij geheime variabelen — die worden in de browsercode ingebouwd.

Zie hoe je API-sleutels veilig houdt.

Stap 5: Controleer invoer en fouten

• Validatie op de server. Controles in de browser kunnen worden overgeslagen. Verplichte velden, lengtes, formaten en toegestane waarden moeten ook door de server worden gecontroleerd.
• Databasequery’s gebruiken parameters, niet tekst die gebruikersinvoer in een query samenvoegt.
• Fouten worden niet ingeslikt. Een try/catch die niets doet, verbergt storingen. Fouten moeten worden gelogd, en gebruikers moeten een eenvoudige melding zien.
• Geen interne details aan gebruikers tonen — stacktraces en databasefouten horen in logs.

Stap 6: Controleer of het echt is

AI-modellen maken soms code die er juist uitziet maar verwijst naar dingen die niet bestaan.

• Pakketten: elke nieuwe afhankelijkheid moet een echt, onderhouden pakket zijn met precies die naam. Wees voorzichtig met namen die op typefouten van populaire pakketten lijken.
• Functies en API-opties: als de code een bibliotheekfunctie of een externe API-optie aanroept die je nog nooit hebt gezien, controleer dan de officiële documentatie.
• Placeholdercode: zoek naar TODO, mock, fake, hardgecodeerde voorbeelddata, of functies die een vaste waarde teruggeven.

Heb je nieuwe pakketten toegevoegd? Geef voor elk de exacte naam, waarvoor het dient, en of we het zouden kunnen missen.

Stap 7: Controleer of het past

Code kan werken en de app toch moeilijker maken om later te wijzigen:

• Dubbele code. Dezelfde logica die op meerdere plekken is gekopieerd, loopt uit elkaar.
• Consistentie. Het moet de patronen volgen die de rest van de app gebruikt.
• Omvang. Een verzoek van 20 regels dat 600 regels oplevert, verdient een vraag.
• Dode code. Oude versies die naast nieuwe blijven staan.

Is er code in het project die door deze wijziging nu ongebruikt is, of logica die elders dubbel staat? Verander niets; noem het alleen.

Veelgemaakte fouten

• Goedkeuren omdat het er schoon uitziet. Netjes ogende code kan nog steeds een rechtencontrole overslaan.
• Lezen in plaats van testen. Test eerst; lees daarna.
• Alleen het ideale pad testen. Probeer slechte invoer, de verkeerde gebruiker en uitgelogd.
• Wijzigingen in niet-gerelateerde bestanden negeren. Vraag waarom elk bestand is veranderd.
• Een zelfbeoordeling helemaal vertrouwen. Gebruik de review van de AI als eerste ronde en bevestig door te testen.
• Een week aan wijzigingen in één keer beoordelen. Beoordeel kleine wijzigingen zodra ze plaatsvinden.

Checklist

• Ik weet welke bestanden zijn veranderd en waarom, en niets onverwants is gewijzigd.
• De wijziging werkt op desktop en telefoon, met slechte invoer, uitgelogd en als een andere gebruiker.
• Elke route met gegevens controleert inloggen en eigenaarschap op de server.
• Geen geheimen in code of browser-bundels.
• Invoer wordt op de server gevalideerd; query’s gebruiken parameters.
• Fouten worden gelogd, niet ingeslikt, en niet in detail aan gebruikers getoond.
• Nieuwe pakketten zijn echt en nodig; er blijven geen verzonnen functies of placeholders over.
• Wijzigingen met een hoog risico zijn zorgvuldig gelezen en waar nodig door een tweede beoordelaar gecontroleerd.

Code beoordelen op Mythex

• Ask-modus beantwoordt vragen over de code zonder die te bewerken — ideaal voor prompts als „leg elke wijziging uit” en „welke routes hebben geen rechtencontrole”. Zie Chat.
• Codeweergave toont de bestandsboom, editor en terminal op elk abonnement (alleen lezen op Free, bewerkbaar op Pro), zodat je zelf kunt lezen wat er is veranderd. Zie Codeeditor.
• /test laat de agent de preview als gebruiker doorklikken en kapotte flows melden.
• Checkpoints laten je een wijziging terugdraaien die de beoordeling niet haalt.

Beoordeelt een ontwikkelaar voor jou, dan behandelt hoe je met een ontwikkelaar werkt aan een door AI gebouwde app de overdracht; levert de beoordeling een bug op, zie dan hoe je een door AI gebouwde app debugt.

Veelgestelde vragen