Het demomoment is overtuigend. Iemand uit je team laat een applicatie zien die grotendeels door AI is geschreven, en alles doet het: inloggen werkt, de cijfers verschijnen netjes op het scherm. Toch is de vraag op tafel niet of het werkt. De vraag is of je dit wilt loslaten op klantdata en op processen waar je organisatie op draait.
Voor die beoordeling hoef je niet te kunnen programmeren. De fouten die ervaren AI-gebruikers maken zijn voorspelbaar, juist omdat werkende output ze aan het zicht onttrekt. Dit zijn de vijf grootste valkuilen, omgezet in toetsvragen die je aan de maker kunt stellen.
Niemand heeft de code gelezen
Een AI-tool is tevreden zodra de uitkomst doet wat je vroeg; veiligheid en onderhoudbaarheid komen in dat oordeel niet voor. Hardgecodeerde toegangssleutels, ontbrekende invoercontroles of authenticatie die net niet klopt: in een demo valt het niet op, in productie wel. Tegen die tijd verwerkt de applicatie al gegevens van klanten.
De eerste toetsvraag: wie heeft de gegenereerde code regel voor regel gelezen, en zou diegene het zelf zo geschreven hebben? Blijft het antwoord steken bij vertrouwen in de AI, dan is er geen review geweest.
De applicatie kent jullie werkelijkheid niet
Zonder context levert AI een generieke oplossing: technisch correct, gemaakt voor een gemiddeld bedrijf dat niet bestaat. Denk aan een inlogscherm zonder rollen en rechten, of een koppeling die alleen de foutloze route afhandelt en struikelt over alles daarbuiten.
Vraag welke context de AI heeft meegekregen over gebruikers, bedrijfsregels en uitzonderingen. Hoe algemener het antwoord, hoe groter de kans dat de applicatie het begeeft op precies de situaties die in jullie praktijk wekelijks voorkomen.
Onder de motorkap stapelt de schuld zich op
Elke prompt legt een nieuwe laag over de vorige, en de AI heeft geen geheugen voor de keuzes van gisteren. Na tientallen iteraties werkt de applicatie nog steeds, maar hangt hij intern aan elkaar van dubbele logica en tegenstrijdige patronen. Die technische schuld merk je aan het tempo: elke aanpassing duurt langer en breekt vaker iets anders.
Toets daarom of er onderweg ooit is opgeruimd, of alleen toegevoegd. En of de belangrijkste keuzes ergens buiten de chatgeschiedenis staan beschreven.
Stellige antwoorden zijn geen onderbouwing
AI presenteert een verkeerde aanpak net zo zelfverzekerd als een goede, en geeft geen signaal wanneer hij buiten zijn kennisgrens werkt. Bij een klein onderdeel zie je dat snel. Bij architectuur, beveiliging of database-ontwerp openbaart een verkeerde beslissing zich pas als de applicatie in gebruik is.
Vraag welke beslissingen met grote gevolgen zijn voorgelegd aan een tweede bron: documentatie, een collega met vakkennis, een externe review. Was de AI de enige autoriteit, dan rust het fundament op een overtuigend verhaal.
De kennis van het systeem zit nergens
De sluipendste valkuil is niet technisch maar organisatorisch. Wie vooral met AI bouwt, traint zijn eigen probleemoplossend vermogen steeds minder; we schreven eerder al waarom vibe coding niet betekent dat je niets hoeft te leren. Voor jou telt de consequentie: valt de applicatie uit en geeft de AI geen bruikbaar antwoord, dan moet iemand zelfstandig over het systeem kunnen redeneren.
De laatste toetsvraag is daarmee de eenvoudigste: wie kan deze applicatie uitleggen en repareren zonder AI ernaast? Is dat niemand, dan heb je geen software in beheer, maar een risico in productie.
Vallen meerdere antwoorden tegen, gooi het project dan niet weg. Een vibe-coded applicatie is vaak een prima prototype: hij bewijst dat het idee werkt en maakt concreet wat je nodig hebt. Alleen is een bewezen idee nog geen productiewaardige software. Wij ontwikkelen zelf AI-assisted, met engineers die elke regel kunnen verantwoorden, dus we kennen beide kanten van deze grens. Wordt het prototype van je team serieus, dan maken we er met doorontwikkeling en beheer software van die je met een gerust hart op je klanten loslaat.