Bij frontend check je de code zonder het te weten
Een vibecoder kijkt niet naar de code. Maar bij frontend kijkt hij wel naar het resultaat. En dat is het cruciale verschil: frontendcode zit bijna een-op-een vast aan het visuele. Een knop die op de verkeerde plek staat, spacing die niet klopt, een formulier dat er raar uitziet. Door het resultaat te inspecteren, inspecteer je indirect de code.
Iedereen heeft een mening over design. Iedereen kan ergens naar kijken. Alle code is er alleen maar om die output te genereren. Je kan wel zeggen “ik kijk niet naar de code”, maar je kijkt wel naar de output.
Dat maakt frontend uniek geschikt voor vibe coding. Je hebt een directe feedbackloop: je maakt een verandering, je ziet het resultaat, je past aan. Zelfs als je geen regel code leest, doe je toch een vorm van kwaliteitscontrole via het visuele.
Neem Tailwind als voorbeeld: elke pagina is op zichzelf staand. Je kunt experimenteren, fouten maken en opnieuw beginnen zonder dat het de rest van je applicatie beïnvloedt. En omdat elke visuele fout direct zichtbaar is, vang je de meeste problemen op door simpelweg naar je scherm te kijken.
Bij backend bestaat die indirecte check niet
Backend is per definitie onzichtbaar. Er is geen visueel resultaat dat je kunt inspecteren. Je hebt alleen een endpoint, een response, een side effect. En het gevaarlijke: de output kan er compleet correct uitzien terwijl de onderliggende logica fout is.
Bij frontend, als jij een foutje maakt in die pagina, dan heeft het verder nul implicaties voor het vervolg. Bij backend is dat anders, daar zit heel vaak businesslogica. Als het daar iets in niet klopt, dan heb je meteen best wel grote problemen.
Er is geen visuele proxy
Bij frontend is het visuele resultaat een directe afspiegeling van de code. Bij backend is er geen equivalent. Je ziet niet of je authenticatie correct werkt door ernaar te kijken.
Fouten zijn latent
Een bug in je backend kan maanden onopgemerkt blijven, tot iemand een specifieke actie doet en alles breekt.
Businesslogica is kritiek
Backend bevat vaak de regels van je bedrijf. Als daar iets fout zit, neem je verkeerde beslissingen op basis van verkeerde data.
Security is onzichtbaar
Je ziet niet of je SQL-injecties hebt of je API-keys lekt. Geen enkel visueel signaal waarschuwt je, tot het te laat is.
Hoe complexer de frontend, hoe minder de visuele check volstaat
De visuele check werkt perfect voor styling: een kleur aanpassen in Tailwind, een margin tweaken, een layout fixen. Dat is een-op-een visueel werk. Maar niet alle frontend is styling.
Ga je echt naar best wel grote webapplicaties, dan kom je op een gegeven moment op het probleem dat je architectuur ook goed moet zijn. En dat is niet iets wat je ziet.
Zodra je een design system bouwt met gedeelde componenten, formuliervalidatie toevoegt of state management nodig hebt, verschuift frontend richting onzichtbare logica. Een validatieregel die in één formulier werkt maar in een ander formulier niet, zie je niet door naar je scherm te kijken. Een component die op pagina A goed werkt maar op pagina B breekt door een gedeelde state, evenmin. Hoe meer je frontend op backend begint te lijken (gedeelde logica, herbruikbare abstracties, complexe flows) hoe minder het visuele resultaat je vertelt over de kwaliteit van je code.
Waar de visuele check genoeg is
Statische websites
Zoals onze eigen website. Markdownbestanden, geen database. Het resultaat is het enige dat telt, en dat kun je volledig visueel beoordelen.
Landingspagina's
Eenmalige pagina's waar niemand ooit meer naar kijkt. Als het er goed uitziet, is de code goed genoeg.
Prototypes
Snel iets op het scherm kwakken om te testen of een idee werkt. De visuele output is precies wat je wilt valideren.
Designiteraties
Tweaken hoe iets eruitziet is per definitie visueel werk. Dat is prima om te vibecoden.
Waar geen visuele check mogelijk is
Authenticatie en autorisatie
Je ziet niet of iemand data kan benaderen die ze niet mogen zien. Er is geen visueel signaal dat je waarschuwt.
Betalingslogica
Je ziet niet of de berekening klopt tot je verkeerde bedragen int of uitkeert.
Datatransformaties
Je ziet niet of je data corrupt raakt tot je rapportages niet kloppen.
State machines
Complexe flows met meerdere statussen. De output kan er correct uitzien terwijl de onderliggende state fout is.
Conclusie: hoe visueler het werk, hoe beter vibe coding werkt
Moet ik eerlijk zeggen, bij frontend dingen ben ik daar wat minder kritisch in over het algemeen. Maar bijvoorbeeld de backend, daar heb ik echt naar gekeken. En dan zag ik op een gegeven moment dat die ook gewoon de fout in ging.
Het is geen simpele frontend-vs-backend-scheidslijn. Het gaat erom hoeveel van je code je indirect kunt checken door naar het resultaat te kijken. Hoe dichter je werk bij het visuele zit, hoe effectiever vibe coding is. Hoe meer onzichtbare logica erbij komt, hoe riskanter het wordt.
Puur visueel werk: vibe coding werkt
Styling, layouts, landingspagina's, prototypes. Het visuele resultaat is een directe afspiegeling van de code. Fouten zijn zichtbaar en geïsoleerd.
Onzichtbare logica: vibe coding faalt
Design systems, validatie, state management, businesslogica, security. De output kan er correct uitzien terwijl de onderliggende code fout is.
Kies ook je stack op basis van hoe je gaat werken. Als je gaat vibecoden, kies dan tools waar de output direct zichtbaar is: statische sites, serverless functies, zo min mogelijk onzichtbare logica. Onze eigen website is gebouwd met Astro en markdownbestanden, precies omdat het resultaat daar het enige is dat telt.
Hulp nodig met je backend?
We helpen teams die een vibe-coded frontend hebben maar worstelen met de backend. Van architectuuradvies tot hands-on development.
