Vibecoding is leuk. Maar wie bewaakt de kwaliteit?
Vibecoding is in korte tijd van grap naar werkwijze gegaan. Je beschrijft in gewone taal wat je wilt, de AI schrijft de code, jij draait het en beschrijft je volgende wensen. Geen syntax, geen uren zoeken op Stack Overflow, gewoon ‘vibes’ en iteratie. Het is nu sneller dan ooit, en toegankelijk voor mensen zonder diepe technische kennis. Dat is geweldig. Toch roept het voor ons als QA-ers een nuchtere vraag op: wie bepaalt eigenlijk of die code goed genoeg is?
Waarom het in het begin
zo goed werkt
Voor de eerste fase van een product is vibecoding fantastisch. Je gaat in een middag van idee naar iets dat echt werkt. Je test of iemand er enthousiast van wordt voordat je er echt geld in steekt. Je loopt een sales gesprek binnen met een demo in plaats van een powerpoint presentatie. Om een idee te valideren en te leren wat je eigenlijk wilt bouwen, is er nooit iets zo snel geweest.
En dat is pure winst. Wie zelf een prototype heeft gevibecode, snapt zijn eigen product beter dan wie een specificatie schreef en het door een ander liet uitvoeren. Dat geeft je als opdrachtgever een voordeel; jij weet exact wat je wilt en kunt dit ook exact zo bouwen.
Waar de vibe
ophoudt
Het wordt lastig op het moment dat de app geen speeltje meer is en jouw hele bedrijf ermee gaat werken. Dezelfde loop die het prototype zo snel bouwde, is niet altijd het juiste gereedschap voor de fase daarna.
Om een paar hardnekkige redenen:
- Je kunt niet debuggen wat je niet begrijpt. Als er iets breekt op een manier die de AI niet in een paar pogingen oplost, sta je stil. Er is geen model in je hoofd om op terug te vallen.
- Security is onzichtbaar tot het een krantenkop wordt. Gevibecode apps gaan regelmatig live met open sleutels, onbeveiligde databases en geen enkele controle op invoer. In de demo werkt het prima.
- Het schaalt niet, en je ziet het niet aankomen. Code die goed genoeg is voor tien gebruikers, bezwijkt bij tienduizend. De oplossing vraagt om begrip van het systeem, niet om opnieuw prompten.
- De codebase is mogelijk een doolhof. (maar dat weet je niet zeker). Duizenden regels AI-code zijn voor iedereen lastig om later veilig aan te passen, mens of AI.
Wordt de tester
overbodig?
Zie vibecoding als een briljante stagiair die alles durft en niks hoeft te verantwoorden. Hij of zij heeft enorm veel zelfvertrouwen, ook als hij ernaast zit. Dat is snel en handig voor een eerste versie, maar het is niet iemand aan wie je zo. maar de gegevens van je klanten toevertrouwt.
Je zou denken dat AI de tester overbodig maakt. Het tegenovergestelde lijkt waar. Hoe sneller je bouwt, hoe belangrijker het wordt om scherp te blijven kijken. Kwaliteit begint, net als bij traditioneel bouwen, bij de eerste prompt. Je schetst context en geeft kaders mee. Je begrijpt waar een systeem op termijn aan moet voldoen. Vanaf scratch denk je mee over wat je bouwt, of het klopt en of het mee kan groeien. Business analisten en quality engineers zijn hier onmisbaar. Zij weten wat er nodig is voor een systeem dat robuust is en kan meegroeien.
Dit is geen
AI tegen mensen
Het idee dat AI de ontwikkelaar of tester vervangt, mist wat er echt gebeurt. De beste vakmensen van nu vibecoden zelf ook. Ze doen het alleen met het inzicht om te zien wanneer AI ernaast zit, het gevoel om te vangen wat er is gemist en de ervaring om iets te bouwen dat groei overleeft. Vervangen is (nog) niet ter sprake, maar samenwerking is wel key om succesvol te kunnen vibecoden.
Zo houd je
grip
Een paar nuchtere vragen helpen al enorm, van de eerste prompt tot vlak voor de livegang:
- Weten we of we het juiste bouwen, en aan welke eisen het op termijn moet voldoen?
- Begrijpen we wat deze code doet, ook nog over een half jaar?
- Is het getest op meer dan “het werkt op mijn scherm”?
- Houdt het stand als er straks veel meer gebruikers en echte data op zitten?
- Is de security op orde, met afgeschermde sleutels en data?
- Weten we welk risico we nemen als het misgaat, en wie het dan oppakt?
Zorg dat het snelle bouwen er niet voor zorgt dat je blind gaat bouwen. En zorg dat je vibecoding echt gaat inzetten als een tool waar je voordeel mee gaat behalen!
FAQ
Vibecoding is software bouwen door in gewone taal te beschrijven wat je wilt, waarna een AI de code schrijft. Je draait het resultaat, beschrijft de volgende stap en itereert zo verder, zonder zelf regels code te typen. Het maakt bouwen snel en toegankelijk, ook voor mensen zonder technische achtergrond. De term werd populair in 2025 en is inmiddels een normale manier om een eerste versie van een product te maken.
Voor prototypes en experimenten is vibecoding uitstekend, voor een livegang met echte gebruikers meestal niet zonder extra werk. Gevibecode software werkt vaak prima in een demo, maar mist regelmatig aandacht voor security, schaalbaarheid en onderhoud. Voordat echte mensen en echte data in beeld komen, wil je de code laten nakijken, de beveiliging dichttimmeren en de onderdelen die mee moeten kunnen steviger opbouwen.
Nee, AI vervangt het vakmanschap niet, het verschuift juist waar dat vakmanschap zit. Wie prompt, weet wát hij vraagt. Een ervaren ontwikkelaar of tester weet waaróm iets zo moet, hoe het schaalt en waar het kan breken. De beste vakmensen gebruiken AI zelf ook, maar met het inzicht om te zien wanneer de output niet klopt. Je gebruikt AI om te starten en mensen om het betrouwbaar te maken.
Vanaf scratch. QA is geen fase achteraf, maar een manier van kijken die vanaf de eerste prompt meebouwt: bouwen we het juiste, werkt het goed genoeg, kan het mee groeien? Het punt waar echte mensen en echte data in beeld komen is dan geen startsein, maar de harde ondergrens: vóór de livegang moet het op orde zijn, niet pas na de eerste storing of het eerste datalek.
