Wat komt na vibe coding: de stand van de AI-appbouwers in 2026

Waarom de volgende generatie AI-appbouwers niet magisch probeert te zijn, en waarom dat precies het punt is.

De term «vibe coding» kwam begin 2025 in omloop, toen Andrej Karpathy die gebruikte om de ervaring te beschrijven van software schrijven door te typen wat je wilt en te kijken hoe het verschijnt. Hij vatte een echte verschuiving. Voor het eerst kon iemand zonder technisch profiel een hulpmiddel openen, een idee beschrijven en binnen minuten een werkende interface op het scherm hebben. De demonstraties waren werkelijk magisch. De categorie die rond de term groeide (Lovable, Bolt, Base44, v0) bewoog erg snel, haalde veel kapitaal op en bracht miljoenen nieuwe «bouwers» in de software-economie.

Ze liep ook tegen de werkelijkheid aan.

Besteed wat tijd aan de oprichterscommunities die het afgelopen jaar op deze hulpmiddelen bouwden en dezelfde bekentenissen blijven opduiken. De app werkte in de demonstratie. Ze brak bij de derde gebruiker. De authenticatie werd brak op het moment dat echte accounts erop kwamen. De database liet stilzwijgend rijen vallen. De fout die niemand kon reproduceren was de fout die klanten kostte. In de forums van bouwers is in 2025 en 2026 een echt en waarneembaar patroon te zien: het gesprek is verschoven van «kijk wat ik dit weekend heb uitgebracht» naar «hoe voorkom ik dat dit omvalt».

Dat patroon is de proef die de eerste golf AI-appbouwers niet doorstond. Niet de proef van de demonstratie. De proef van de productie.

De volgende generatie wordt gebouwd door teams die de tijd van vibe coding zagen gebeuren en de enige vraag stelden die telde: wat komt daarna? Het antwoord is geen iets slimmer hulpmiddel van prompt naar prototype. Het is een fundamenteel andere architectuur, gericht op een ander doel.

Wat vibe coding goed deed

Voordat de gebreken worden benoemd: geef de categorie haar krediet. Vibe coding was geen bedrog. Het maakte drie dingen voor het eerst werkelijk beter.

Het liet de afstand tussen idee en zichtbaar artefact instorten. Een oprichter die zes maanden eerder niets had kunnen bouwen, kan nu op dezelfde dag dat hij het idee had een werkend scherm aan een klant tonen. Dat is een echte en blijvende verschuiving. Die gaat niet weg.

Het maakte de aanvankelijke aanloop toegankelijk. De drempel om te beginnen bouwen zakte tot het typen van een alinea. Mensen die vastliepen op de arbeidsmarkt voor ontwikkeling, op de kosten van een bureau of op hun eigen gebrek aan ervaring met code, konden eindelijk bewegen. Aanvankelijke aanloop telt op in startups. Vibe coding gaf veel mensen hun eerste centimeter.

Het herbedraadde wat mensen in design en product alleen kunnen doen. De regel «ik moet met de ontwikkeling praten om dit te zien» is grotendeels opgelost. Wie zich met product bezighoudt, kan nu op een dinsdag om elf uur ’s avonds zelf aan gangen schaven. De samenwerkingslus werd sneller voor iedereen die in de kamer overbleef.

Dat zijn geen kleine overwinningen. De volgende generatie hulpmiddelen erft ze. De vraag is wat eraan vastzit.

Wat vibe coding verkeerd deed

De categorie heeft stilzwijgend twee verschillende producten samengevoegd: een manier om een app te genereren en een manier om er een uit te brengen. Dat is niet hetzelfde, en in het gat tussen die twee wonen de productiestoringen.

De taak van een generator is uit een prompt iets op te leveren dat samenhangend genoeg is om op het ding te lijken. De taak van wie uitbrengt, is een idee omzetten in infrastructuur die een klantenbestand, een veiligheidscontrole, een schemawijziging over zes maanden en een overdracht aan een nieuwe persoon in de ontwikkeling overleeft. De meeste hulpmiddelen van de eerste golf optimaliseerden de taak van de generator. De taak van wie uitbrengt was het probleem van iemand anders, meestal van de gebruiker, en meestal nadat die al beloften aan klanten had gedaan.

De architectonische gebreken verschijnen op voorspelbare plekken. De gegenereerde code draagt patronen die de AI uit haar trainingsgegevens heeft opgepikt zonder context over de specifieke toepassing: prima voor een prototype, brak in productie. Het schema van de database is gevormd zodat de zichtbare app vandaag werkt, zonder voorziening dat een team het volgende kwartaal veilig moet laten meegroeien. De authenticatiegang neemt de weg van de minste weerstand om de demonstratie uit te brengen, wat zelden de weg is die onder echt gebruik houdt. De stap «uitrollen» eindigt bij de zichtbare app, niet bij het bedieningssysteem eromheen: toezicht, logboeken, kopieën, snelheidsgrenzen, observeerbaarheid, allemaal het probleem van iemand anders.

Het diepere gebrek is moeilijker te benoemen. De hulpmiddelen van de eerste golf beginnen bij het scherm en werken achterstevoren naar het gegevensmodel en de infrastructuur. Dat is de verkeerde richting. Het scherm is het meest vluchtige deel van een toepassing. Het gegevensmodel en de API dragen het meeste gewicht. Bij het scherm beginnen levert een architectuur op die geoptimaliseerd is voor het deel van het systeem dat vervangbaar zou moeten zijn.

De vorm van wat komt

De hulpmiddelen na vibe coding zijn georganiseerd rond een andere eerste zet: helderheid vóór code.

In plaats van van prompt naar gegenereerde schermen te springen, begint de volgende generatie met een gestructureerde blueprint: een beschrijving van de modules, gebruikerstypes, diensten, integraties, het gegevensmodel en de architectuur die de toepassing nodig heeft. De blueprint is aanpasbaar, in te zien en na te kijken. Het is het contract over wat er gebouwd wordt. Alleen nadat de blueprint goed is, begint de codegeneratie, en de code wordt gegenereerd om de blueprint te vervullen, niet om te vervullen wat de AI zich toevallig voorstelde.

Het is de zet waar Archie rond is gebouwd. De productlus is idee → blueprint → aanpassen → bouwen. De blueprintfase is het deel dat de eerste golf oversloeg, en het blijkt het deel dat bepaalt of de toepassing overleeft.

Drie andere verschuivingen gebeuren parallel.

De eerste is dat de API ophoudt een nagedachte te zijn. De gegenereerde toepassing krijgt vanaf dag één een deugdelijke, volledige, voor agenten gereede API. Niet als documentatie maar als rugsteun. Het argument voor API-first-architectuur staat los van het gesprek over AI-bouwers, maar landt daar het hardst: een gegenereerde app zonder echte API is een gesloten systeem dat geen ander hulpmiddel, integratie of agent kan uitbreiden.

De tweede is dat de backend deel wordt van het geleverde. De eerste golf leverde frontends op en wees naar de backend van iemand anders, meestal Supabase of Firebase. De volgende golf brengt de backend in het platform zelf. Archie Core levert bijvoorbeeld bij elke toepassing een GraphQL-first backend; de klant plakt geen Supabase aan de frontend en daarna Vercel daaraan. De stapel is één ding.

De derde is dat hosting en bedieningsinfrastructuur ophouden «vanaf hier jouw probleem» te zijn. Uitrol, omgevingen, observeerbaarheid, groei, schemamigraties: alles inbegrepen. De taak van de klant is de toepassing beschrijven; die van het platform is haar in de lucht houden.

Zet die drie verschuivingen bij elkaar en je hebt iets wat de eerste golf niet had: een toepassing die haar eigen succes kan overleven.

Waar de spelers nu staan

De markt sorteert zichzelf nog. Een grove indeling van waar de belangrijkste hulpmiddelen medio 2026 landen:

Hulpmiddel	Hoofdtaak	Backend inbegrepen	Hosting inbegrepen	Resultaat gereed voor productie
Lovable	Generatie van frontend	Nee (Supabase voor eigen rekening)	Nee (Vercel/Netlify voor eigen rekening)	Prototypeniveau
Bolt	Generatie van frontend in de browser	Nee (Supabase voor eigen rekening)	Deels (StackBlitz-containers)	Prototypeniveau
Base44	Frontend en lichte generatie van backend	Deels (ingebouwde gegevenslaag)	Deels	Prototypeniveau
v0	Generatie van componenten en interfaces	Nee	Nee	Componentniveau
Cursor	AI-assistent voor code (hulpmiddel voor ontwikkeling)	Niet van toepassing: codehulpmiddel	Niet van toepassing: codehulpmiddel	Via de ontwikkeling bemiddeld
Claude Code	AI-assistent voor code (hulpmiddel voor ontwikkeling)	Niet van toepassing: codehulpmiddel	Niet van toepassing: codehulpmiddel	Via de ontwikkeling bemiddeld
Supabase	Backend als dienst	Zichzelf	Zelf hosten of Supabase Cloud	Gereed voor productie
Vercel	Frontendhosting en randnetwerk	Nee	Zichzelf	Gereed voor productie (alleen hosting)
Archie	Full-stackapp uit een blueprint	Ja (Archie Core)	Ja (in het pakket)	Gereed voor productie

Dit is geen aanval op een van deze producten. Elk is werkelijk goed in het werk waarvoor het gebouwd is. Cursor en Claude Code zijn bijvoorbeeld uitstekende hulpmiddelen voor de ontwikkeling en staan helemaal niet in dezelfde categorie als Lovable of Archie, omdat ze aannemen dat er iemand uit de ontwikkeling in de lus zit. De zin van de tabel is dat de categorie na vibe coding die is die alles in de rechterkolommen omvat.

Wat kopers werkelijk zouden moeten beoordelen

Als een team in 2026 een AI-appbouwer kiest, zijn de vragen die het waard zijn te stellen anders dan die van 2024.

Levert het hulpmiddel een blueprint of alleen een artefact? Als het antwoord is «je geeft een prompt en je krijgt schermen», dan is het een hulpmiddel van de eerste golf. Dat kan nog steeds de juiste keuze zijn voor een weekendprototype, een verkoopdemonstratie of een statische site. Het is de verkeerde keuze voor alles waarvoor een klant gaat betalen.

Bevat het hulpmiddel de backend, of hangt het van een ander product af? Als het antwoord is «we werken met Supabase, Firebase en dergelijke», dan krijgt de klant een stapel om samen te stellen en geen toepassing om te bedienen. Die montagekosten zijn echt en terugkerend.

Bevat het hulpmiddel hosting en bedieningsinfrastructuur? «Verbind je Vercel-account» is prima voor wie technisch is. Voor een oprichter zonder technisch profiel is het dat niet, en zeker niet wanneer om drie uur ’s nachts iets breekt en de klant niet kan vinden op welk dashboard hij moet inloggen.

Heeft de toepassing vanaf dag één een echte API, of is de API een punt op een toekomstige routekaart? Als agenten de komende vijf jaar een aanzienlijk deel bemiddelen van hoe software wordt gebruikt (en dat zullen ze) dan brengt een toepassing zonder echte API uit in een leeg kanaal.

Is het resultaat iets wat iemand uit de ontwikkeling zou willen erven? Op een zeker moment wordt elke geslaagde toepassing aan een echt technisch team overgedragen. Als code, schema en architectuur die overdracht niet overleven, wordt de door AI gegenereerde start later een herbouwbelasting van meerdere kwartalen.

De slotsom

Vibe coding was een echte verschuiving, geen mode. Het heeft een generatie nieuwe bouwers in beweging gezet, en het spiergeheugen voor «ik beschrijf de app en zie hem» gaat niet terug in de fles. De volgende generatie AI-appbouwers erft dat vermogen en voegt het deel toe dat de eerste golf oversloeg: een architectuur die het moment overleeft waarop de demonstratie eindigt.

De teams die verder gaan, laten door AI gegenereerde software niet varen. Ze doen het in de juiste volgorde. Eerst de blueprint, tweede de code, derde het scherm: het omgekeerde van hoe de eerste golf werkte, en de enige volgorde die een toepassing oplevert in plaats van een prototype.

De categorie heeft nu een naam, ook al heeft de markt die nog niet ingehaald. De bedrijven die erin bouwen, zijn die welke de tijd van vibe coding hebben gezien en eindelijk hebben begrepen dat een werkend scherm nooit hetzelfde was als een werkend systeem.

Verwante lectuur

De diagnose waarop dit stuk rust, is vibe coding heeft zijn belofte gebroken. Voor de praktijk zelf, zie specificatiegestuurde ontwikkeling en het einde van de herbouw en de gids voor specificatiegestuurde ontwikkeling.

Hulpmiddel voor hulpmiddel: Lovable · Bolt · Base44 · Supabase · Vercel. Voor het hele landschap, de beste AI-appbouwers in 2026.

Veelgestelde vragen

Wat betekent «wat komt na vibe coding»? Het verwijst naar de volgende generatie AI-appbouwers die toepassingen opleveren die gereed zijn voor productie in plaats van prototypes. De bepalende verschuiving is beginnen met een gestructureerde blueprint (modules, gebruikerstypes, gegevensmodel, integraties, architectuur) voordat er code wordt gegenereerd, zodat het resultaat iets is waarop een toepassing gebouwd kan worden en niet louter een zichtbaar artefact.

Waarin verschilt Archie van Lovable, Bolt of Base44? Archie heeft een blueprintfase vóór de codegeneratie, levert bij elke toepassing een volledige backend (Archie Core) en hosting mee, en levert een resultaat op dat is ontworpen om gebruik in productie te overleven. De hulpmiddelen van de eerste golf richten zich op het genereren van de frontend en hangen ervan af dat klanten hun eigen backend (doorgaans Supabase) en hosting (doorgaans Vercel of Netlify) aanplakken.

Zijn Cursor of Claude Code concurrenten in deze categorie? Nee. Cursor en Claude Code zijn hulpmiddelen voor de ontwikkeling: ze nemen aan dat er iemand uit de ontwikkeling in de lus zit die code schrijft en aanpast. AI-appbouwers als Archie, Lovable en Bolt richten zich op gebruikers die zelf geen code schrijven. Andere categorie, ander publiek.

Waarom telt de blueprintfase zo zwaar? Omdat het scherm het meest vluchtige deel van elke toepassing is, terwijl gegevensmodel en API het meeste gewicht dragen. Hulpmiddelen die bij het scherm beginnen, leveren architecturen op die geoptimaliseerd zijn voor het vervangbare deel van het systeem en brak zijn in de delen die stabiel zouden moeten zijn. De blueprintfase dwingt de dragende beslissingen naar voren.

Moet ik voor prototypes nog een hulpmiddel van de eerste golf gebruiken? Voor prototypes, demonstraties en weekendprojecten zijn de hulpmiddelen van de eerste golf nog steeds uitstekend in wat ze doen. Het argument gaat over welk hulpmiddel te gebruiken wanneer het doel iets is waarvoor klanten betalen en de toepassing moet blijven. Andere taken, andere hulpmiddelen.