AI bouwt een werkend prototype tegenwoordig in enkele minuten, maar dat betekent niet dat het bouwt wat er is gevraagd. Volgens een recent artikel op Search Engine Land ontbreekt in vibe coding structureel dezelfde stap die softwareontwikkeling al jaren parten speelt: verifiëren of het opgeleverde resultaat daadwerkelijk overeenkomt met de afgesproken eisen, in plaats van alleen te checken of het er goed uitziet.
De oplossing is volgens de auteur simpel te formuleren, maar wordt in de praktijk vaak overgeslagen. Leg voor elke eis vooraf vast hoe je die gaat testen, en toets het live resultaat daadwerkelijk tegen die standaard voordat je iets als 'klaar' bestempelt.
Vibe coding verplaatst het probleem, het lost het niet op
Door rechtstreeks te prompten in plaats van een developer in te schakelen, valt de traditionele overdracht weg. Dat voelt als winst, want er zit een stap minder tussen idee en werkend product.
Alleen verdwijnt het onderliggende risico niet mee. Een vage specificatie die je aan een AI voorlegt, kan tot dezelfde drift leiden als een vage specificatie die je aan een developer geeft, met als verschil dat een AI zelden uit zichzelf aangeeft dat er iets ontbreekt of onduidelijk is.
Acht maanden status updates zonder dat iemand het zag
De auteur van het bronartikel deed eerder dit jaar een regel-voor-regel audit van zijn eigen platform tegen de oorspronkelijke specificatie. Daaruit bleek dat een kerncomponent voor het scoren van contentbetrouwbaarheid wel in documentatie en klantmateriaal stond beschreven, maar simpelweg niet in productie draaide.
Niet half gebouwd, niet buggy, gewoon afwezig. De werkende prototypecode bestond al maanden in losse bestanden, maar was nooit overgezet naar het live platform, en dat bleef acht maanden lang onder de radar van reguliere statusupdates.
Een tweede probleem kwam boven water toen bleek dat iets wat de backend berekende, intern werd gerapporteerd alsof de klant het al te zien kreeg. Dat zijn twee verschillende claims, en zodra er expliciet werd gevraagd of het resultaat de klant ook echt bereikte, doken er nog twee vergelijkbare gaten op.
Een SEO-crawl is geen specificatie
Hetzelfde patroon speelt in technische SEO. Je draait een crawl, de tool spuwt een lijst fouten uit zoals gebroken canonicals, ontbrekende hreflang of verweesde pagina's, en die output plak je in een ticket voor het devteam.
Het probleem is dat de tool alleen meldt wát er is gedetecteerd. Niet waarom het ertoe doet, niet wat 'opgelost' op deze specifieke site concreet betekent, en niet hoe je de fix straks controleert.
Vertaal de output van de scanner daarom altijd naar je eigen specificatie, met een eigen verificatiestap eraan gekoppeld, voordat een ticket bij een developer terechtkomt. Doe je dat niet, dan loop je het risico dat een probleem over een half jaar nog steeds bestaat, terwijl het al lang als 'opgelost' te boek staat.
De vibe-and-verify checklist
Voordat je iets als af bestempelt, raadt de auteur aan telkens drie vragen expliciet te beantwoorden in plaats van te vertrouwen op een onderbuikgevoel:
- Wat is er precies stuk of ontbreekt er, geformuleerd in de taal van het systeem zelf en niet als 'dit zou beter moeten werken'.
- Welke specifieke verandering dicht dat gat, en hoe ziet de eindsituatie er concreet en controleerbaar uit.
- Bij een technische SEO-bevinding: benoem het exacte mechanisme, bijvoorbeeld TTFB, DOM content loaded of een renderblokkerend script, in plaats van de generieke label 'paginasnelheid'.
Wie geen concreet antwoord op deze punten kan geven, heeft daarmee meteen de bevinding te pakken: dat is precies de plek waar het misgaat. Vibe coding is een uitstekend middel om snel te schetsen en te testen, maar zodra klanten op het resultaat gaan vertrouwen, verschuift de verantwoordelijkheid naar wie kan aantonen dat het resultaat ook echt overeenkomt met wat er bedoeld was.
Bron: Search Engine Land