Het Dag Twee-probleem: Wanneer je vibe-coded app echte gebruikers ontmoet

Het Dag Twee-probleem: Wanneer je vibe-coded app echte gebruikers ontmoet

10 juni 2026

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. Die dag hebben we vaak meegemaakt. We zijn er niet om die ervaring af te nemen.

We zijn hier om het over dag twee te hebben, omdat niemand dat in zijn launch-thread bespreekt. Dag twee is wanneer een echte gebruiker inlogt, iets doet waar je niet aan had gedacht om te testen, en je app de kloof ontmoet tussen “gegenereerd” en “geengineerd”.

Hoe dag twee er in de praktijk 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 fout is op een manier die niemand kan reproduceren. Je plakt de fout in de chat. De AI lost het vol vertrouwen op. De fix sloopt iets anders.

Welkom bij prompt-whack-a-mole. Omdat de AI symptomen bestrijdt in plaats van grondoorzaken, landt elke patch bovenop de vorige. De codebase verandert stilletjes in wat builders ‘Frankenstein-code’ noemen: een lappendeken van tegenstrijdige stijlen, dubbele functies en verwarde logica waarbij database-queries in de interface-code staan. Zodra 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 tegenspraak is. Je onderhoudt geen app meer; je onderhandelt ermee.

Er is een nog wreder scenario: de stille deploy-fout. Je hosting-build faalt door een kleine fout, de live URL blijft de oude versie tonen, en jij — die geen wijziging ziet — vertelt de AI dat de fix “niet werkte”. Dus genereert de AI een compleet andere, complexere oplossing voor een probleem dat al was opgelost. Een paar rondes later heb je een opgeblazen v5 van code, terwijl v1 prima was.

Het deel dat je niet ziet

De debugging-loop is tenminste zichtbaar. Beveiligingsproblemen zijn dat niet, en dat is de reden dat we hier zo streng in zijn bij zakelijke builds.

Het onderzoek hierover is ronduit ongemakkelijk. Door LLM’s gegenereerde code compileert in ongeveer 90% van de gevallen 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 die in de browser is geïmplementeerd (waardoor elke gebruiker deze kan omzeilen door de pagina te bewerken), database-rechten die wijd openstaan zodat er niets fout gaat tijdens de build, en API-keys die hardcoded in bestanden staan omdat de builder niet weet wat een omgevingsvariabele is. Die bestanden worden vervolgens gepusht naar publieke GitHub-repo’s, waar credential-scrapers ze stipt op tijd vinden.

Dit is precies waarom dit een dag twee-probleem is: een exploiteerbare app draait perfect. Er is geen foutmelding voor “klant A kan technisch gezien de gegevens van klant B lezen”. Dat kom je erachter via een gebruiker, als je geluk hebt, of op een veel ergere manier als je dat niet hebt. En het standaardadvies (“test het gewoon!”) botst met de realiteit: niet-technische builders testen het ‘happy path’, terwijl de fouten in de edge cases zitten — de concurrency-bug, de vergeten wachtwoord-resetflow die de AI nooit heeft gegenereerd omdat de demo die niet nodig had.

De onderhoudsschuld die niemand opmerkt

Stapel deze mechanismen over enkele maanden op en je krijgt wat we de ‘flitskrediet’ van technische schuld noemen: 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 slopen dingen die je niet eens hebt aangeraakt — langdurige builders op prompt-to-app platforms rapporteren 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, maar voor productie-apps heeft het vooral technische schuld gedemocratiseerd. De niet-technische builder eindigt precies met datgene wat hij met AI wilde vermijden — een codebase die het oordeel van een ontwikkelaar vereist — behalve dat het nu de fundering is van zijn bedrijf en hij de code niet kan 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; de oneerlijke middenweg 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 accelerator in plaats van een valstrik. Lees wat de agent schrijft. Leer wat RLS betekent voordat je een app lanceert die erop vertrouwt. Stap over van prompt-only tools naar Cursor of Replit, waar de code de interface is en je echt een gevoel voor kwaliteit kunt ontwikkelen. Dit pad is echt geweldig — het is alleen een pad waar je maanden voor moet lopen. Doen alsof je op dit pad zit terwijl je ongelezen code naar klanten stuurt, is de valstrik.

Pad twee: plaats de gevaarlijke onderdelen op een fundament dat niet is gegenereerd. Wees eerlijk: je app is een zakelijke tool — een klantportaal, een tracker, een interne CRM — en merk op dat 80% daarvan precies het loodgieterswerk is waar AI het slechtst in is: auth, rechten, wachtwoord-resets, datatoegang. Bouw die categorie op een no-code platform zoals 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 naar beneden te halen. Dag twee op dit pad is een bewerking, geen archeologische opgraving — dat is waarom het bovenaan onze ranglijst voor klantportalen staat.

Blijf met volle overgave vibe coden voor de leuke dingen — prototypes, speeltjes, weekendexperimenten zijn precies waar deze tools briljant in zijn. Beslis alleen, voordat de echte gebruikers verschijnen, aan welke kant van de splitsing je staat. Dag twee vraagt niet beleefd.

Tools vergelijken

Klaar om te beginnen met vibe coding?

We rangschikken tools op basis van echte projecten. Bekijk waar elke builder staat voordat je aan je volgende project begint.

Bekijk de ranglijsten →