De kans is groot dat iemand in je organisatie al met vibe coding tools werkt. Een marketeer die met Lovable een campagnetool in elkaar zet, een analist die ChatGPT code laat schrijven voor een rapportage, een ontwikkelaar die in Cursor werkt zonder dat daar ooit een besluit over is genomen. De vraag is dan niet meer welke tool de beste is. De vraag is op welke gronden jij zo’n tool goedkeurt.
Dat onderscheid is wezenlijk. Welke tool voorop loopt, wisselt per kwartaal; de criteria waarop je beoordeelt, houden jaren stand. Daarom hier geen ranglijst, maar een beoordelingskader dat ook bruikbaar blijft als het toollandschap er volgend jaar anders uitziet.
Vier soorten tools, vier risicoprofielen
Onder de noemer vibe coding vallen nogal verschillende gereedschappen. AI-editors en assistenten zoals Cursor en GitHub Copilot helpen een ontwikkelaar die de code zelf blijft zien en beoordelen. Generatieplatforms zoals Lovable en Bolt maken van een beschrijving in gewone taal een complete webapplicatie. Replit combineert genereren, testen en hosting in de browser. En chattools zoals Claude en ChatGPT schrijven losse stukken code die iemand daarna zelf ergens inzet.
Voor jou als beslisser telt vooral wie er meekijkt en waar het resultaat terechtkomt. Een AI-editor in handen van een ervaren ontwikkelaar valt binnen je bestaande kwaliteitscontrole. Een platform waarmee een collega zonder technische achtergrond een applicatie genereert en meteen live zet, omzeilt diezelfde controle volledig. Hetzelfde etiket, een heel ander risico.
Eigenaarschap van de code komt eerst
Het grote verschil met klassieke no-code platforms is dat vibe coding tools daadwerkelijke broncode opleveren. Dat voordeel bestaat alleen als je die code ook kunt meenemen. Controleer of je de code kunt exporteren, elders kunt hosten en door een andere partij kunt laten doorontwikkelen. Een tool die de code opsluit in zijn eigen omgeving is functioneel een no-code platform, met dezelfde vendor lock-in: je zit vast aan de leverancier, zijn prijzen en zijn voortbestaan.
Veiligheid gaat over datastromen, niet alleen over code
Twee vragen bepalen het veiligheidsbeeld. Waar gaan je prompts, code en data naartoe, en traint de leverancier daar zijn modellen op? Wie een klantbestand in een prompt plakt, deelt persoonsgegevens met een externe partij; de AVG geldt dan onverkort. En hoe goed is wat er terugkomt? Gegenereerde code is geoptimaliseerd om te werken, niet om veilig te zijn. Authenticatie, autorisatie en de omgang met gebruikersinvoer verdienen een controle door iemand die weet waar hij op moet letten. Welke fouten daarbij het vaakst opduiken, lees je in ons artikel over de valkuilen waar ook gevorderde gebruikers intrappen.
Een goedkeuringskader in vijf vragen
Wil je deze tools gecontroleerd toelaten in plaats van ze stilzwijgend te gedogen, leg dan elke kandidaat langs dezelfde meetlat:
- Wie is eigenaar van de gegenereerde code, en kunnen we die exporteren en elders hosten?
- Waar staan onze prompts en onze data, en worden ze gebruikt om modellen te trainen?
- Welke gegevens mogen erin? Klantdata en bedrijfskritische informatie horen niet in een prototype.
- Wie beoordeelt de code voordat er iets draait met echte gebruikers of hun gegevens?
- Wat gebeurt er met onze applicaties als de tool stopt, wordt overgenomen of fors duurder wordt?
Een tool die hier geen bevredigend antwoord op heeft, wijs je niet af omdat AI onbetrouwbaar zou zijn, maar omdat hij niet voldoet aan de eisen die je aan elke leverancier stelt.
Gereedschap, geen eindproduct
Zo kijken wij er zelf ook naar. Onze engineers ontwikkelen AI-assisted: de tools versnellen het werk, het vakmanschap bepaalt wat de productie haalt. Voor een prototype, een demo of een interne wegwerptool is vibe coding uitstekend gereedschap. Voor software die klantdata verwerkt of een bedrijfskritisch proces draagt, is het dat niet. Daar is iemand nodig die de gegenereerde code kan lezen, toetsen en verbeteren.
Wordt een vibe-coded prototype in je organisatie serieus, dan hoeft het niet terug naar de tekentafel. Wij maken er robuuste software van: we beoordelen de code, dichten de gaten en zetten hem op een fundament dat groei en onderhoud aankan. Hoe die stap eruitziet, lees je bij doorontwikkeling en beheer.