Vibe coding is magie in de demo. Is uw app echt klaar voor productie?

Is vibe coding klaar voor productie? Voor prototypes en interne tools: ja, met glans. Voor een app in de stores, met echte gebruikers en echte data: niet op eigen kracht. De werkelijke beperkingen van vibe coding zitten niet in de code die het schrijft, maar in alles wat productie rond die code vereist.

De no-code-sector benoemt de scheidslijn inmiddels zelf. Caspio's State of No-Code 2026 beschrijft hoe AI de markt tegelijk twee kanten op trekt en komt uit op een botte formule: “De tweedeling is niet 'AI goed versus AI slecht', maar wegwerp versus duurzaam (disposable vs. durable).”

Wat maakt een vibe-coded prototype dan wegwerp? Niet de demo — alles eromheen. Zeven muren, elk onzichtbaar op een laptopscherm, elk maar al te reëel op de dag dat u wilt publiceren. Drie ervan — native code, store-indiening en de app-lifecycle — zijn zo specifiek mobiel dat we er een aparte deep dive aan wijdden; hier krijgen ze hun plek in het volledige plaatje.

Muur 1 — Hosting en eigendom

Om de tools recht te doen: de code is doorgaans van u. De documentatie van Lovable zegt het expliciet, en exporteren naar GitHub kan. Wat níét van u is: alles wat die code nodig heeft om te draaien. Standaard leeft uw app op de beheerde cloud van de leverancier — Lovable Cloud, Bolt-hosting, Vercel — met backend, database en build-pipeline in hun handen, tegen hun tarieven, onder hun voorwaarden. De broncode bezitten van een app waarvan de infrastructuur van iemand anders is, is als de bouwtekening bezitten van een huis op gepachte grond. Productie betekent dat iemand jarenlang instaat voor die infrastructuur: uptime, back-ups, verlengingen, facturen. In de demo doet niemand dat.

Gedeelde infrastructuur. Een SaaS-platform draait één infrastructuur voor al zijn apps, beheerd door een team dat niets anders doet dan die overeind houden — en de kosten zitten in het abonnement, in plaats van dat u ze later ontdekt. Elke app die wij ooit uitbrachten, draait vanaf dag één op dat model.

Muur 2 — Backend en data

De datalaag van een prototype is geoptimaliseerd voor de demo: ze bestaat, ze reageert, ze oogt prima. Productiedata stelt hardere eisen — migraties, back-ups, omgevingen die het testen scheiden van de werkelijkheid. In juli 2025 haalde die les de krantenkoppen toen de agent van Replit een productiedatabase wiste tijdens een expliciete code freeze, inclusief de records van meer dan 1.200 topmanagers. Replit kondigde daarop automatische scheiding tussen ontwikkel- en productiedatabases aan — en dichtte zo een gat dat productiesystemen als basisvoorwaarde beschouwen.

En voorbij de database is productie de plek waar de ondankbare operationele problemen wonen. Transactionele e-mail is de klassieker: een SaaS-oprichter meldde op r/SaaS “vaak een bezorgratio van minder dan 50%” op gedeelde e-mailinfrastructuur. Geen enkele prompt lost deliverability op.

Een backend die ouder is dan uw app. Op een beheerd platform is de datalaag — migraties, back-ups, de scheiding tussen test en productie — één keer professioneel ontworpen en wordt ze dagelijks op de proef gesteld door elke app die erop draait; alleen al onze e-commercemodule draait in productie voor duizenden webwinkeliers. Het ondankbare loodgieterswerk is het dagwerk van een platformteam, niet uw ontdekking in week drie.

Muur 3 — Authenticatie en beveiliging

Dit is de best gedocumenteerde muur, want onderzoekers blijven hem meten. Veracodes studie uit 2025 over 100+ modellen stelde vast dat AI-gegenereerde code in 45% van de geteste taken kwetsbaarheden uit de OWASP Top 10 introduceerde. Een academische benchmark uit december 2025 legde de kloof op zijn scherpst vast: de best presterende agent leverde in 61% van de gevallen functioneel correcte oplossingen, maar slechts 10,5% ervan was veilig. En in 2025 werd een CVE ingediend voor ontbrekende Row-Level Security in door Lovable gegenereerde apps — beveiligingsonderzoeker Matt Palmer scande er 1.645 en vond er 170 die data blootlegden, inclusief API-sleutels en financiële gegevens. Toen Escape.tech in oktober 2025 5.600+ live vibe-coded apps scande, vond het 2.000+ kwetsbaarheden en 400+ gelekte secrets.

Niets hiervan betekent dat de modellen slecht zijn. Het betekent dat een security-review een productie-eis is waar een prototype per definitie nooit doorheen is gegaan.

Beveiliging: één keer geschreven, door iedereen geërfd. Platformauthenticatie is één codebase, gehard door jaren echt verkeer. Moet er iets gepatcht worden, dan wordt de fix één keer geschreven — direct server-side uitgerold en meegenomen in de eerstvolgende build van elke app. Dat is het structurele verschil tussen één login die door engineers wordt onderhouden en duizenden gegenereerde logins die elk in hun eentje hun eigen toegangsregels uitvinden.

Muur 4 — Indiening bij de stores

Hier is het feit dat de meeste vibe-coding-tutorials overslaan: de meeste prompt-to-app-tools bouwen web-apps, geen mobiele apps. Lovables eigen FAQ zegt het onomwonden: “Nee, Lovable richt zich op webapplicaties.” v0 genereert webcode die op Vercel wordt uitgerold. Bolt is de gedeeltelijke uitzondering — de Expo-integratie genereert echte React Native-code — maar de binary builds, de developeraccounts en de review van Apple blijven volledig uw probleem.

De vaak gesuggereerde omweg — de web-app in een native schil verpakken — botst op Apples Guideline 4.2: “Uw app moet functies, content en een UI bevatten die hem boven een opnieuw verpakte website uittillen.” Ons publicatieteam ziet in de praktijk dat reviewers apps routineus offline testen; een wrapper die dan een leeg scherm toont, vertelt hun genoeg. En de review is onverbiddelijk, ook voor echte apps: Apple wijst grofweg 42% van de eerste indieningen af (Apples eigen basislijn, gemeten over de apps die ons publicatieteam de afgelopen 12 maanden indiende). We schreven een gids over waarom Apple apps afwijst en hoe u terugkomt.

Indienen als industrieel proces. Een platform compileert binaries die ontworpen zijn om de review te doorstaan, en wanneer Apple of Google de lat verlegt — nieuwe privacylabels, nieuwe SDK-deadlines, nieuwe volledigheidschecks — past het zich één keer aan en erft elke app die het uitbrengt de fix. Vijftien jaar store-indieningen is een vorm van kapitaal die geen enkele prompt kan genereren.

Muur 5 — Native toestelfuncties

De functies die een mobiele app de moeite waard maken ten opzichte van een website, zijn precies die waar een verpakte web-app op stukloopt. Pushmeldingen zijn het scherpste voorbeeld: op iOS werkt web push alleen voor web-apps die handmatig op het beginscherm zijn gezet — nooit in de browser. Camera, offline modus, biometrie: elk vraagt native plug-ins die met de hand toegevoegd, geconfigureerd en onderhouden moeten worden, buiten alles wat de AI genereerde. Een “mobielvriendelijke” webdemo en een native app zijn verschillende diersoorten met dezelfde interface.

Native vanaf de fundering. Op een platform dat echte Swift- en Kotlin-code compileert, zijn push, camera, offline en haptics kant-en-klare componenten die bij elke iOS- en Android-release worden bijgehouden — de laag die een app professioneel doet aanvoelen is er de basis, geen bijzaak.

Muur 6 — Regeneration drift: de code die zichzelf herschrijft

Noem het regeneration drift: bij elke nieuwe prompt wordt de code opnieuw gegenereerd tegen een net iets andere context — de code drijft langzaam weg van wat er stond — en de fix van gisteren kan geruisloos verdwijnen in de generatie van vandaag. Addy Osmani, engineering lead van Google Chrome, gaf het patroon de naam “two steps back”, twee stappen terug: “Je probeert een kleine bug te fixen… De AI stelt een wijziging voor die redelijk lijkt… Die fix breekt iets anders.” De data zegt hetzelfde: GitClears analyse van 211 miljoen gewijzigde regels code vond dat blokken van vijf of meer gedupliceerde regels in 2024 8x zo vaak voorkwamen, en dat het aandeel code dat binnen twee weken na het schrijven alweer werd herzien sinds 2020 bijna verdubbelde. Een codebase die niet stilligt, is een codebase waarover u niets kunt beloven — al zeker niet aan een gebruiker die een bug heeft gevonden.

Een fundament dat niet beweegt. Op een platform genereert AI alleen de dunne maatwerklaag bovenop een geversioneerd, getest fundament — authenticatie, checkout, CMS en designsysteem horen bij het fundament dat geen enkele prompt ooit opnieuw genereert. De drift blijft beperkt tot die dunne maatwerklaag in plaats van uw hele app: de checkout waarop u rekent, kan zichzelf niet stilletjes herschrijven.

Muur 7 — Privacy en compliance

Een gepubliceerde app draagt juridische verplichtingen waar een demo nooit aan toekomt. Apples privacylabels en het Data safety-formulier van Google Play eisen allebei dat u aangeeft welke data u verzamelt, waar die heen gaat en wie ze verwerkt — vragen waarop een vibe-coded stack vaak geen antwoord heeft, omdat een default ergens de data van uw gebruikers op infrastructuur zette die u nooit hebt gekozen. De AVG (GDPR) legt de lat nog hoger: toestemming die specifiek en niet gebundeld is, een datalocatie die u daadwerkelijk kunt benoemen, een lijst verwerkers die u daadwerkelijk kent. Niets daarvan duikt op in een demo. Alles daarvan duikt op in een store-review — of erger, in een klacht.

Compliance: één keer geregeld, aan de bron. Eén juridische en technische inspanning op platformniveau — in ons geval: alle data gehost in Europa, ingebouwd toestemmingsbeheer, automatische detectie van de permissies die elke functie nodig heeft — bedient elke app en blijft actueel terwijl de regels evolueren. Onze compilatie-engines gaan nog een stap verder: een library gaat alleen mee in de binary als de functie die haar gebruikt actief is. Apps verklaren dus niet alleen minder, ze bevatten ook minder.

De zeven muren van vibe coding — samengevat

Zeven muren, zeven vragen. De platformantwoorden hierboven zijn de onze; deze vragen zijn de uwe. Beantwoord ze voor uw prototype:

1. Wie beheert de infrastructuur waarop hij draait — en doet die dat over twee jaar nog?
2. Waar staat de data, en wat gebeurt er als het schema moet veranderen?
3. Heeft iemand die code kan lezen de authenticatie en de toegangsregels gereviewd?
4. Kan hij een ondertekende iOS- en Android-binary opleveren die door de store-review komt?
5. Kan hij een pushmelding sturen naar een vergrendelde telefoon?
6. Kunt u over zes maanden één bug fixen zonder de rest opnieuw te genereren — en opnieuw te breken?
7. Zouden de toestemmingsflow en de dataverwerking een AVG-klacht overleven?

Drie of meer keer “nee” (of “weet ik niet”), en wat u hebt is een prototype. Dat is geen mislukking — een prototype is oprecht nuttig. Het valideert een idee in één middag, voor bijna niets. De mislukking zit alleen in de verwarring: een lancering, een gebruikersbestand en een bedrijf bouwen op iets wat gemaakt is om weggegooid te worden.

De conclusie is niet “vermijd AI”. We gebruiken AI-codegeneratie dagelijks in onze eigen engineeringteams — onze CMO zei het al in april 2025, met de kanttekening die de sector sindsdien heeft bevestigd: “Zonder programmeerkennis raak je al snel overweldigd of loop je vast, want AI kan flinke inconsistenties veroorzaken als ze zonder deskundig menselijk toezicht wordt gebruikt.”

De conclusie is wél: richt de snelheid van AI op een fundament dat kan publiceren. Dat is de hele logica van de AI Extension Builder (momenteel in bèta, beschikbaar voor alle klanten), GoodBarbers antwoord op de prompt-to-app-vraag: u beschrijft een functie in gewone taal en een AI-agent bouwt haar — maar hij bouwt binnen een platform, tegen gedocumenteerde API's, zodat het resultaat alles erft wat een prototype mist. Het design volgt automatisch het designsysteem van uw app. De sectie gaat de deur uit als echte Swift- en Kotlin-binaries, via dezelfde store-pipeline die we sinds 2011 draaien — met een publicatieteam dat 91% van de eerste afwijzingen door Apple alsnog rechttrekt (afgelopen 12 maanden).

Muren 2 en 3 — backend en beveiliging — krijgen dezelfde behandeling. Wanneer een door AI gebouwde sectie data moet opslaan, zet de Supabase-integratie de databasestructuur voor u op, in uw eigen Supabase-project, op infrastructuur die u zelf beheert — en elke tabel wordt standaard geleverd met Row-Level Security-policies. Dat is exact het probleem uit de Lovable-CVE, afgehandeld nog voor u wist dat u ernaar moest vragen. En de platformkern — hosting, database, pushmeldingen, analytics en betalingen — zit in één abonnement, dus er is geen stapel externe diensten om samen te stellen, te beveiligen en apart te betalen. Totale eigendomskosten: ongeveer een tiende van maatwerkontwikkeling.

Er zijn uiteraard grenzen. GoodBarber is gebouwd voor content-apps en mobiele commerce; een game of een zwaar op maat gesneden marktplaats valt daarbuiten, en voor zulke projecten is een vibe-coded prototype dat u aan een ontwikkelteam overhandigt de natuurlijkere route. Maar binnen die scope is de platformaanpak precies wat AI-snelheid omzet in een app die u kunt publiceren — en jarenlang kunt laten draaien.

De volgende stap, heel concreet:start een gratis proefperiode, open een “Create with AI”-sectie en beschrijf de functie die u vorig weekend bij elkaar hebt geprompt. Dezelfde vijf minuten. Deze keer staat er een store-pipeline achter het resultaat.

Kunt u een vibe-coded app in de App Store publiceren?

Niet rechtstreeks, in de meeste gevallen. Lovable en v0 produceren webapplicaties — er is geen iOS- of Android-binary om in te dienen. De web-app in een native schil verpakken kan, maar Apples Guideline 4.2 wijst apps af die neerkomen op “een opnieuw verpakte website”. Bolt kan via Expo React Native-code genereren, maar de builds, de developeraccounts en de store-review blijven voor uw rekening. De betrouwbare routes: ontwikkelaars inhuren om de code productieklaar te maken, of herbouwen op een platform dat native binaries compileert en de indiening regelt. De volledige mobiele analyse leest u in wat vibe-coding-tools u vergeten te vertellen over mobiele apps.

Is vibe coding klaar voor productie?

Voor prototypes, interne tools en weekendprojecten: ja, en daar is het uitstekend in. Voor productie-apps met echte gebruikers is het afgewogen antwoord: niet zonder engineering-review. AI-gegenereerde code introduceert in 45% van de geteste taken beveiligingslekken (Veracode, 2025), en een academische benchmark vond dat de oplossingen van de best presterende agent in 61% van de gevallen functioneel correct waren, maar slechts in 10,5% veilig (arXiv, december 2025). Production-ready zijn gaat niet over de vraag of de code draait — het gaat over hosting, data, security-review, store-indiening, native functies, codestabiliteit en compliance: de zeven muren van vibe coding.

Wat is regeneration drift bij vibe coding?

Regeneration drift is wat er gebeurt wanneer elke nieuwe AI-prompt de code opnieuw genereert tegen een net iets andere context, waardoor de fix van gisteren geruisloos kan verdwijnen in de generatie van vandaag. Addy Osmani noemt de lus die zo ontstaat het “two steps back”-patroon; GitClears analyse van 211 miljoen gewijzigde regels code bracht de voetafdruk in kaart — gedupliceerde codeblokken kwamen in 2024 8x zo vaak voor. Het is de belangrijkste reden dat een vibe-coded app moeilijker te onderhouden wordt naarmate u langer blijft prompten.

Heeft Apple vibe-coded apps verboden?

Nee — en het onderscheid doet ertoe. In maart 2026 blokkeerde Apple updates van de apps van vibe-coding-platforms zoals Replit en Vibecode, op grond van Guideline 2.5.2, die apps verbiedt die code downloaden en uitvoeren. Dat raakt de tools als iOS-apps, niet de apps die met AI zijn gebouwd. Apple liet MacRumors weten geen regels te hebben die zich specifiek tegen vibe-coded apps richten. Een individuele met AI gebouwde app moet gewoon over de normale lat: minimale functionaliteit (4.2), spam (4.3) en volledigheid — dezelfde review die elke app krijgt.

Wanneer stapt u over van een vibe-coded prototype naar een app builder?

Op het moment dat het prototype iemands dagelijkse tool moet worden: echte gebruikers, een plek in de stores, updates, een backend die blijft bestaan. Dat is een verantwoordelijkheidsdrempel, geen vaardigheidsdrempel — de dag dat anderen op de app vertrouwen, moet iemand instaan voor die zeven muren. Houd het prototype; het heeft zijn werk gedaan door het idee te valideren. Herbouw het daarna op een plek waar die muren al het werk van iemand anders zijn — native binaries, store-indiening, hosting en onderhoud inbegrepen. Zoals onze CMO het formuleerde: vibe coding bedient een publiek van experts; een app builder is er voor alle anderen.

Wat kost publiceren in de stores nu echt?

Een Apple Developer-account kost $99 per jaar; een Google Play-developeraccount eenmalig $25. Daarna komt de echte kostenpost: builds voorbereiden, screenshots, privacyverklaringen en de review overleven — Apple wijst grofweg 42% van de eerste indieningen af (Apples eigen basislijn, gemeten over de apps die ons publicatieteam de afgelopen 12 maanden indiende). Onze stap-voor-stap publicatiegids beschrijft het proces, en onze publicatieservice doet het voor u.