--- title: "Het Day Two-probleem: Wanneer je vibe-coded app echte gebruikers ontmoet" description: "Dag één van vibe coding is de demo. Dag twee zijn de echte gebruikers, beveiligingslekken en onderhoudsschuld. Wat gaat er precies kapot, en wat zijn de twee eerlijke oplossingen?" date: 2026-06-10 language: nl canonical: https://best-vibe-coding-tools.com/nl/posts/the-day-two-problem source: "Best Vibe Coding Tools posts" --- Dag één van een vibe-coded app is de beste demo die je ooit hebt gegeven. De prompt werkte, de schermen zijn strak, de database bevat rijen en je hebt een tweet geplaatst met een schermopname. We hebben die dag vaak meegemaakt. We zijn er niet om die ervaring af te pakken. We zijn hier om te praten over dag twee, want niemand behandelt dat in hun launch thread. Dag twee is wanneer een echte gebruiker inlogt, iets doet wat je niet had getest en je app de kloof tussen "gegenereerd" en "engineered" ervaart. ## Hoe dag twee er echt uitziet Het begint zelden met een crash. Het begint met iets vreemds: een formulier dat onzin accepteert, een pagina die vastloopt voor één specifieke gebruiker, een getal dat op een manier fout is die niemand kan reproduceren. Je plakt de fout in de chat. De AI lost het zelfverzekerd op. De oplossing sloopt iets anders. Welkom bij prompt whack-a-mole. Omdat de AI symptomen oplost in plaats van grondoorzaken, stapelt elke patch zich op bovenop de vorige. De codebase wordt stilletjes wat bouwers Frankenstein-code noemen: een lapwerk van tegenstrijdige stijlen, dubbele functies en verstrengelde logica waarbij database-queries in de interface-code leven. Naarmate het project groeit voorbij het contextvenster van de AI, begint het model zijn eigen eerdere beslissingen te vergeten en stelt het code voor die daarmee in strijd is. Je onderhoudt geen app meer. Je onderhandelt met een app. Er is een nog wreedere variant: de stille deploy-fout. Je hosting-build faalt door een kleine fout, de live URL blijft de oude versie tonen en jij, omdat je geen wijziging ziet, vertelt de AI dat de oplossing "niet werkte". Dus genereert het een compleet andere, complexere oplossing voor een probleem dat al was opgelost. Enkele rondes later heb je een opgeblazen v5 van code waarvan v1 prima was. Elke snelle fix kan het probleem verplaatsen in plaats van oplossen. ## Het deel dat je niet ziet De debugging-loop is tenminste zichtbaar. De beveiligingsproblemen zijn dat niet, en dat is de reden waarom we hier streng in zijn bij zakelijke builds. Het onderzoek hierover is echt ongemakkelijk. LLM-gegenereerde code compileert ongeveer 90% van de tijd succesvol, maar ongeveer 45% bevat OWASP Top 10 kwetsbaarheden, zoals omzeilbare login-checks en injectiefouten. AI-tools optimaliseren voor een werkende demo, wat leidt tot voorspelbare shortcuts: toegangscontrole geïmplementeerd in de browser waar elke gebruiker deze kan omzeilen door de pagina te bewerken, database-rechten die wagenwijd openstaan zodat er niets fout gaat tijdens de build, en API-keys die hardcoded in bestanden staan omdat de bouwer niet weet wat een environment variable is. Die bestanden worden vervolgens gepusht naar publieke GitHub repo's, waar credential scrapers ze stipt op tijd vinden. Dit is wat dit specifiek een dag-twee-probleem maakt: een exploiteerbare app draait perfect. Er is geen foutmelding voor "klant A kan technisch gezien de records van klant B lezen". Je komt erachter via een gebruiker, als je geluk hebt, of veel erger als dat niet zo is. En het standaardadvies ("test het gewoon!") botst met de realiteit: niet-technische bouwers testen het ideale scenario, terwijl de fouten in de edge cases zitten, de concurrency bug, de vergeten wachtwoord-reset flow die de AI nooit genereerde omdat de demo die niet nodig had. De demo kan werken terwijl voorspelbare shortcuts de app kwetsbaar maken. ## De onderhoudsschuld die niemand optekent Stapel deze mechanismen over maanden op en je krijgt wat we zien als de flitskrediet van technische schuld: direct software nu, samengestelde rente later. Elke shortcut die de AI nam, is een toekomstige fix. Elke fix kost een paar credits extra en zorgt voor meer code-bloat. Platform-updates worden uitgerold en breken dingen die je niet hebt aangeraakt, langdurige bouwers op prompt-to-app platforms melden dat ze maandelijkse onderhoudskosten in rekening brengen bij klanten, puur om regressies van het platform zelf op te vangen. Dit is de bittere grap in het midden: vibe coding beloofde software te democratiseren, en voor productie-apps heeft het vooral technische schuld gedemocratiseerd. De niet-technische bouwer eindigt precies met datgene wat ze met AI wilden vermijden, een codebase die het oordeel van een ontwikkelaar vereist, behalve dat het nu de fundering is van hun bedrijf en ze het niet kunnen lezen. ## De eerlijke splitsing Dus wat doe je nu echt? Na veel builds en een paar littekens denken we dat het neerkomt op een splitsing met twee eerlijke paden, en het oneerlijke midden is het enige foute antwoord. **Pad één: leer code te onderhouden.** Als je dit genoeg leuk vindt om dieper te gaan, wordt vibe coding een legitieme versneller in plaats van een valstrik. Lees wat de agent schrijft. Leer wat RLS betekent voordat je een app shipped die er afhankelijk van is. Stap over van prompt-only tools naar [Cursor](/nl/reviews/cursor) of [Replit](/nl/reviews/replit), waar de code de interface is en je echt inzicht kunt opbouwen. Dit pad is oprecht geweldig, het is gewoon een pad waar je maanden op moet lopen, en doen alsof je op dat pad zit terwijl je ongelezen code naar klanten shipped, is de valstrik. **Pad twee: zet de gevaarlijke delen op een fundering die niet gegenereerd is.** Wees eerlijk dat je app een zakelijke tool is, een klantportaal, een tracker, een intern CRM, en merk op dat 80% daarvan precies het loodgieterswerk is dat AI het slechtst genereert: auth, permissies, wachtwoord-resets, data-toegang. Bouw die categorie op een no-code platform zoals [Softr](/nl/reviews/softr), waar het loodgieterswerk geteste infrastructuur is die je visueel configureert, en de AI Co-Builder je nog steeds de snelheid van dag één geeft. Wanneer je custom flair wilt, beperkt het vibe-coding blok de gegenereerde code tot één component, zodat de AI het huis kan decoreren zonder het dak in te laten storten. Dag twee op dit pad is een bewerking, geen archeologische opgraving, dat is waarom het bovenaan onze [klantportalen ranking](/nl/rankings/best-vibe-coding-tools-for-client-portals) staat. Blijf onbezonken vibe coden voor de leuke dingen, prototypes, speeltjes en weekendexperimenten zijn precies waar deze tools briljant in zijn. Beslis alleen, voordat er echte gebruikers komen, aan welke kant van de splitsing je staat. Dag twee vraagt niet beleefd. Voordat de echte gebruikers komen, hebben we twee eerlijke paden om uit te kiezen.