Vibe Coding & Cases · Laatst bijgewerkt op 3 juni 2026 · 8 min

Een jaar vibe coding bij Next Day Online: het echte knelpunt is de output controleren

We bouwen bijna alles via Claude Code en AI-agents. Na een jaar is de hardste les niet de code of de prompts, maar dit: AI-output controleren gebeurt te weinig, en dan glippen fouten er stil doorheen. Een eerlijk verhaal met echte voorbeelden.

Acht digitale tool-kaarten in een 3D-grid, vijf actief en twee uitgeschakeld, verbonden door datastromen

We gebruiken vibe coding inmiddels dagelijks bij Next Day Online. Het overgrote deel van ons werk loopt nu via Claude Code en AI-agents: interne tools, onze eigen producten en de content-pipeline achter onze sites. Dit artikel gaat niet over hoe vibe coding in theorie werkt. Het gaat over wat we zelf hebben gebouwd, en over de les die ons het afgelopen jaar het hardst heeft geraakt.

TL;DR: Code genereren is het probleem niet. De AI schrijft sneller dan wij ooit konden. Het echte knelpunt is het controleren van die output, en dat gebeurt in de praktijk te weinig. Wie niet controleert, betaalt de prijs in stille fouten: een artikel dat op de verkeerde site verschijnt, een reactie die nooit aankomt, of tekst die geloofwaardig klinkt maar niet klopt.

Wat vibe coding is (en wat het niet is)

Vibe coding is softwareontwikkeling waarbij je in gewone taal beschrijft wat een tool moet doen, en een AI-model (zoals Claude Code, Cursor of Lovable) schrijft de code. Jij stuurt bij, de AI bouwt verder. Voor eenvoudige tools is geen programmeeropleiding vereist. Maar voor een productie-omgeving met externe gebruikers, koppelingen en klantdata heb je nog altijd technisch inzicht nodig om het goed op te zetten, en vooral: om te controleren wat er uitkomt.

Aspect	Traditionele development	Vibe coding
Doorlooptijd prototype	3-6 weken	1-4 dagen
Benodigde kennis opdrachtgever	Laag (agency regelt alles)	Middel (jij moet je proces kennen)
Schaalbaarheid	Hoog (mits goed gebouwd)	Middel (afhankelijk van complexiteit)
Onderhoud achteraf	Agency of interne developer	Zelf of met begeleiding

Waar wij vibe coding echt voor gebruiken

Geen verzonnen voorbeelden. Dit zijn drie dingen die we daadwerkelijk hebben gebouwd en die draaien.

1. JustCast: narrowcasting voor verenigingen

JustCast is een narrowcasting-tool voor sportclubs en buurtverenigingen: afbeeldingen zoals uitslagen, het kantinemenu of sponsoruitingen die automatisch rouleren op een scherm in het clubhuis. De interessantste ontwerpbeslissing was wat we er níet in stopten. Geen template-editor, geen drag-and-drop layout-builder, geen ingewikkelde rollenstructuur. Een vrijwilliger moet het zonder handleiding kunnen: openen, uploaden, klaar. Vibe coding hielp ons om snel een werkende versie bij echte gebruikers te krijgen en de scope bewust klein te houden.

2. De content-pipeline achter onze eigen sites

Voor onze eigen portfolio van sites draaien we een keten van AI-agents die samen content voorbereiden: een agent die onderwerpen voorstelt, een die research en een brief maakt, een die het concept schrijft, en een reviewer-agent die het beoordeelt voordat er iets gepubliceerd wordt. Het draait grotendeels autonoom op een vast schema. Dit is intern werk, geen klantproduct, en precies hier liepen we tegen het knelpunt aan dat de kern van dit artikel vormt.

3. Aansturing en terugkoppeling via Slack

We sturen die agents intern aan via Slack en krijgen de resultaten in dezelfde thread terug. Handig, omdat je niet in een dashboard hoeft te duiken om iets in gang te zetten of goed te keuren. Ook hier kwam de echte les niet uit de code, maar uit wat er gebeurt als output níet gecontroleerd wordt.

Het echte knelpunt: niet de code, maar het controleren van de output

De gangbare opvatting is dat het moeilijkste van vibe coding het schrijven van de juiste prompts is. Dat klopt niet. Dat is hooguit een uitdaging in het eerste uur. Het echte probleem zit aan de andere kant: de AI produceert snel iets dat er klopt uit, en als niemand dat tegen de werkelijkheid houdt, glippen fouten er stil doorheen.

Een voorbeeld uit onze eigen pipeline. Op een dag verschenen er twee artikelen op nextdayonline.nl die er niet thuishoorden: een stuk over loopbaankeuze na een burn-out (bedoeld voor onze beroepskeuze-site) en een stuk over een cadeau voor de juf (bedoeld voor onze cadeau-site). De inhoud zelf was prima. Het ging mis in de routing: de tool die artikelen wegschrijft viel stil terug op een standaardsite in plaats van een foutmelding te geven toen de juiste site ontbrak. Het pijnlijkste detail: de schrijf-agent had de mismatch zélf gesignaleerd en in zijn eigen kwaliteitsnotitie gezet, maar publiceerde alsnog. Niemand controleerde de output voordat die live ging.

Bij de Slack-koppeling liepen we tegen dezelfde dynamiek aan, maar dan technisch. Een antwoord van een agent kwam soms niet terug in Slack. Geen foutmelding, gewoon stilte. De oorzaak lag in de runtime: een verzoek dat je niet expliciet laat doorlopen, wordt afgekapt zodra de functie klaar is. Het werkte pas toen we dat expliciet afdwongen. In een ander geval faalde code stil in productie omdat hij gebouwd was op een aanname over een externe API die in de praktijk niet meer klopte. We kwamen er pas achter door de logs te lezen.

De rode draad in alle drie de gevallen: het probleem was niet dat de AI slechte code of slechte tekst maakte. Het probleem was dat er geen harde controlestap tussen "AI levert op" en "het gaat live" zat. Stille fouten zijn het duurst, omdat je ze pas ontdekt als de schade er al is.

Onze fix: een controle die je niet kunt overslaan

De oplossing was niet "betere prompts". Het was de output dwingender controleren:

Geen stille standaardwaarden. Tools die iets wegschrijven, geven nu een foutmelding als een verplicht gegeven ontbreekt, in plaats van stil terug te vallen op een default. Een fout die hard stopt is beter dan een fout die doorgaat.
Een reviewstap met meerdere uitkomsten. Onze reviewer-agent kan een concept goedkeuren, markeren voor handmatige controle, of terugsturen naar de schrijver met feedback. Dat is minder werk dan alles met de hand nalopen, en veel veiliger dan blind publiceren.
Mens aan het einde van wat naar buiten gaat. Alles wat publiek wordt, krijgt een laatste menselijke blik. Dat is precies de stap die te vaak wordt overgeslagen omdat de output er al "af" uitziet.

Checklist: AI-output controleren voordat het live gaat

OUTPUT-CONTROLE: voordat AI-werk naar buiten gaat

1. Klopt het feitelijk?
   Cijfers, namen, claims en citaten nagelopen tegen een echte bron? <ja / nee>

2. Komt het op de juiste plek terecht?
   Juiste site / kanaal / ontvanger / database? Niet op een default? <ja / nee>

3. Heeft het systeem zélf iets gemarkeerd?
   Foutmeldingen, waarschuwingen of kwaliteitsnotities gelezen en opgevolgd? <ja / nee>

4. Faalt het luid in plaats van stil?
   Bij ontbrekende of foute input: foutmelding, geen stille fallback? <ja / nee>

5. Heeft een mens het laatste woord gehad?
   Alles wat publiek of naar een klant gaat, met de hand bekeken? <ja / nee>

Wanneer doe je het zelf, en wanneer haal je hulp erbij?

Doe het zelf als:

De tool puur intern is, zonder klanten als gebruikers.
Er geen koppeling met bestaande systemen nodig is.
De data geen persoonsgegevens van klanten bevat (of heel weinig).
Iemand in je team tijd heeft om te itereren én de output te controleren.
Het een vervangbaar experiment is: als het mislukt, is dat geen ramp.

Haal hulp erbij als:

Externe gebruikers (klanten, leveranciers) toegang hebben.
Er koppelingen zijn met CRM, boekhoudpakket of agenda.
De tool AVG-gevoelige data verwerkt.
De tool in productie draait met continuïteitseisen.
Niemand intern tijd of affiniteit heeft om na oplevering te beheren én te controleren.

Voor de meeste MKB-tools is de tussenvorm het verstandigst: wij verzorgen de technische bouw en de controlestappen, jij levert het proces en draagt de tool daarna over aan iemand intern. Bekijk onze vibe coding-aanpak of onze services voor hoe dat eruitziet.

AVG, security en onderhoud: wat niemand je vertelt

Vibe-coded tools slaan data op. Maar waar precies? Wie heeft toegang? Wat gebeurt er bij een datalek? Vijf concrete checks voor elke tool die in productie gaat:

Waar staat de data? Supabase staat standaard op EU-datacenters. Sommige SaaS-tools staan standaard in de VS. Controleer dit vóór je bouwt, niet achteraf.
Is er toegangsbeheer per gebruiker? Elke gebruiker een eigen login, geen gedeeld wachtwoord. Definieer rollen (lezen, schrijven, beheren) en bouw die direct in.
Wordt er gelogd wie wat doet? Bij medewerkers die klantdata bewerken is een audit-trail het minimum: wie wijzigde wat, en wanneer.
Wat is het bewaarbeleid? Data die je niet meer nodig hebt, verwijder je. De AVG verwacht dat je hier aantoonbaar over hebt nagedacht.
Is er een verwerkersovereenkomst? Gebruik je een SaaS-platform om klantdata te verwerken, dan heb je een DPA nodig met die aanbieder. Grote providers bieden dit standaard aan.

De Autoriteit Persoonsgegevens heeft praktische richtlijnen voor kleine organisaties op autoriteitpersoonsgegevens.nl die ook voor vibe-coded tools gelden.

Wat je meeneemt uit dit artikel

Vibe coding werkt. De AI bouwt sneller dan wij ooit konden, en voor een afgebakende MKB-tool lever je in dagen wat vroeger weken kostte. Maar de snelheid aan de bouwkant verschuift het werk naar de controlekant. Het hardste deel is niet meer "hoe maak ik dit", maar "klopt wat hier uitkomt, en komt het op de juiste plek terecht". Die stap overslaan is de duurste fout die je kunt maken, juist omdat de output er zo overtuigend uitziet.

Heb je een concreet intern probleem en wil je weten of vibe coding daarvoor de juiste aanpak is? Bekijk onze cases of neem contact op. We kijken dan samen of maatwerk, bestaande SaaS of een hybride aanpak het beste past, en hoe we de controle goed inrichten.