Waarom AI-gegenereerde code altijd menselijke controle nodig heeft (en dat prima is)

De wereld van softwareontwikkeling verandert razendsnel. Met tools als Claude of ChatGPT ga je van idee naar werkende code in dagen, niet weken. Je beschrijft een functie, past een diff aan, herhaalt en deployt. Dat boost je snelheid enorm.

Toch zit er een adder onder het gras.

Laatst dook ik in code voor een simpele interne tool. Niets cruciaals, maar typisch voor hoe we in 2024 bouwen. Geen wilde AI-fouten, maar 28 problemen – vooral beveiligingslekken uit de OWASP Top 10 van twintig jaar geleden. Simpele, alledaagse blunders.

Dit draait niet om gevaarlijke AI. Het gaat over snelheid die architecturaal inzicht voorblijft.

Het probleem zit niet in de AI, maar in je vraagstelling

De code zag er solide uit. Goede opbouw, slimme componenten, logische libraries. Zelfs ik had zoiets in een weekend kunnen tikken.

Het verschil? De voorbereiding. AI excelleert in uitvoeren van je opdracht. 'Maak een usermanagementsysteem', en je krijgt er een. Maar het vraagt niet: wie mag dit bereiken? Welke data is gevoelig? Waar zit de auth? Wat als iemand de frontend omzeilt?

AI levert features. Geen slapeloze nachten door slimme beveiliging.

Voorbeeld: de admin-functie zonder slot

Stel: een serverless functie voor admin-taken zoals users aanmaken, wachtwoorden resetten of accounts wissen. Slim gehouden server-side, geen credentials in de browser.

Maar geen auth-check. Helemaal niks. Open DevTools, vind de endpoint en iedereen kan via POST admins maken of databases leegtrekken.

De frontend blokkeerde de knop voor niet-admins. Netjes, maar zinloos. Security via UI is nepbeveiliging.

Klassiek bypass-lek, sinds 2003 bekend. AI miste het omdat de prompt luidde: 'Bouw een functie voor admins om users te maken.' Die doet dat. En meer, want je zei niet 'alleen admins'.

AI raadt niet wat je vergat.

De database die veilig leek op papier

Je database heeft row-level security (RLS) voor restricties per user. Sterk, zeker met API-keys in frontend-JS.

AI kreeg de opdracht voor multi-user support. Het maakte nieuwe tabellen met RLS. Top.

Maar de vijf oude tabellen met je echte data? Ongecheckt. Misschien RLS aan, misschien niet. Na npm run db:push stonden nieuwe tabellen dicht, legacy wide open.

AI voldeed aan de opdracht. Het loste het smalle probleem op, zonder je te waarschuwen voor de rest.

Hoe pak je dit aan in je team?

AI-ontwikkeling afschieten? Nee. Snelheid telt. Maar voeg ervaren reviewers toe voor architectuur, niet alleen syntax.

Zo doe je het goed:

Maak een beveiligingschecklist vooraf. Vragen als: wie mag deze endpoint aanroepen? Wat als unauthorized? Is data wereldwijd leesbaar? RLS op álle tabellen? Documenteer aannames.

Laat seniors threat modeling doen. Die 28 issues waren geen tikfouten, maar ontwerpfouten. AI voor code, mensen voor security-denkwerk.

Wees expliciet over auth in prompts. Niet 'maak een usermanagement-endpoint', maar 'maak een endpoint voor ingelogde admins alleen, en leg auth uit.'

Test auth los van functionaliteit. Zorg dat niet-geauthenticeerde users écht niks kunnen.

Het patroon dat je moet snappen

AI maakt geen onveilige code. Het maakt precies wat je vraagt, en slaat over wat je niet vraagt.

Dat is een kracht: geen verzinsels. Maar jij draagt de verantwoordelijkheid. AI voert uit, jij ontwerpt security.

In mijn review zei een mens: 'Deze endpoint mist auth.' Fix in minuten. Oude lekken botsen op nieuwe workflows – en winnen, mits iemand oplet.

Dus: AI voor snelheid, mensen voor structuur. Beide onmisbaar.

Wil je dit in je codebase vermijden? Bij NameOcean zien we startups worstelen met tech debt door snelle features. Onze cloud hosting platform bouwt security in: rate limiting, API-key beheer en audit logs altijd actief. Handig als je team vol gas geeft.