Vibe-coding vs. low-code: wat overleeft de productieomgeving?

Twee jaar geleden was low-code het antwoord op alles. Nu is vibe-coding de nieuwe belofte: beschrijf wat je wil, en een AI schrijft de code voor je. Beide beloven hetzelfde: minder tijd tussen idee en werkend product, lagere kosten, minder afhankelijkheid van ontwikkelaars.

Bij Livewall werken we met beide. We gebruiken vibe-coding voor snelle verkenning en rapid prototyping. We kennen low-code-platforms van klanten die er midway mee vastliepen. En we bouwen ook de platforms die daarna de productieomgeving moeten trekken.

De eerlijke conclusie: beide aanpakken hebben een valide plek. Maar ze falen op compleet verschillende manieren. Wie dat verschil niet kent, kiest verkeerd.

Wat vibe-coding feitelijk is

Vibe-coding is een term die Andrej Karpathy populariseerde voor het fenomeen waarbij je code genereert via een AI-model, zonder de output volledig te begrijpen of te reviewen. Je beschrijft wat je wil, de AI genereert code, en je corrigeert op basis van wat je ziet in de browser. De vibe klopt of klopt niet.

Het werkt verbazingwekkend goed voor een specifieke categorie werk: verkenning, interfaces bouwen die er snel uit moeten zien, scripts die eenmalig draaien, prototypes die je aan stakeholders wilt laten zien. De snelheid is reëel. Wat in een normale sprint twee dagen kost, is soms klaar in twee uur.

De keerzijde is even reëel. De code die een AI genereert is niet per definitie slecht, maar hij is ook niet per definitie goed. Zonder een ontwikkelaar die de output bewust reviewt, sluipen er patronen in die later problemen geven: overbodige afhankelijkheden, onveilige standaarden, logica die bij lage gebruikersaantallen werkt maar bij schaal breekt. Vibe-coding vergroot de output per tijdseenheid. Het vergroot ook de kans op technische schuld als er niemand is die de kwaliteit bewaakt.

Wat low-code feitelijk doet

Low-code platforms zoals Bubble, Webflow, Retool of OutSystems bieden een andere belofte: visueel bouwen binnen een gedefinieerd systeem. Je hoeft geen code te schrijven, maar je werkt binnen de grenzen van het platform.

Voor de juiste use case is dat een sterk voordeel. Interne tools, dashboards, formulierenlogica, eenvoudige workflows: low-code levert hier snel en betrouwbaar. Het platform neemt de infrastructuurverantwoordelijkheid over. Hosting, updates, basisbeveiliging: dat zit er standaard in.

Waar low-code structureel tegen zijn grenzen loopt, is maatwerk. Zodra een klant iets wil dat buiten de templates van het platform valt, word je afhankelijk van workarounds en custom code-blokken die de visuele laag doorboren. En op dat moment heb je eigenlijk het slechtste van beide werelden: je zit vast aan de beperkingen van het platform, maar je schrijft ook code die je niet makkelijk kunt onderhouden.

We zien dit patroon terug bij klanten die met een low-code platform zijn begonnen en na twaalf maanden vastlopen: de roadmap vraagt dingen die het platform niet aankan, maar de kosten van migratie zijn inmiddels fors. Die lock-in is de echte risicofactor, niet de snelheid waarmee je begint.

De echte vergelijking: op welk moment faalt elke aanpak?

Vibe-coding faalt bij schaal en onderhoud. Een prototype dat een stakeholder enthousiast maakt, is niet hetzelfde als een systeem dat 50.000 gebruikers aankan. Vibe-coding-output mist vaak testdekking, foutafhandeling en de architectuurkeuzes die je nodig hebt als een product groeit. Als niemand de gegenereerde code bewust heeft beoordeeld, wordt het ook lastig om hem later aan te passen.

Low-code faalt bij differentiatie. Als jouw platform of product iets moet doen wat andere platforms ook doen, is low-code prima. Zodra je iets wil bouwen wat echt anders is, stuit je op de grenzen van het systeem. Die grenzen zijn niet willekeurig: ze zijn precies daar waar jij je wilt onderscheiden.

De projecten die het meest zijn vastgelopen, zijn die waar een van beide aanpakken werd ingezet als vervanging voor een productstrategie. Snel kunnen bouwen is waardevol. Maar als je niet weet wat je bouwt en voor wie, vergroot snelheid alleen maar de schade.

Dit is precies waarom onze MVP-ontwikkeling aanpak begint met een scherpe definitiefase. Niet als bureaucratische stap, maar als bescherming tegen het bouwen in de verkeerde richting.

Waar vibe-coding echt werkt

We gebruiken vibe-coding actief bij Livewall, maar op een specifieke manier. Voor rapid prototyping en verkenning is het een sterke tool: snel een interface bouwen om een idee te toetsen, een workflow visualiseren voor een klantgesprek, een eerste schets van een user flow om intern te bespreken.

De sleutel is dat de output altijd door een senior ontwikkelaar wordt beoordeeld voordat hij verder het product in gaat. AI genereert, mensen beoordelen. Zonder dat reviewmoment is vibe-coding riskant. Met dat reviewmoment versnelt het de vroege fases van het traject op een manier die direct merkbaar is in de tijdlijn.

Onze samenwerking met Mach8, onze zusterlabel voor AI-automatisering, helpt daarbij. Mach8 bouwt AI-workflows die repetitief werk in het ontwikkelproces overnemen. Livewall bewaakt de productkwaliteit en architectuur. Dat onderscheid tussen genereren en beoordelen is wat het verschil maakt.

Voor KLM werkt dit principe op campagneniveau: AI genereert, mensen bewaken de merkdiscipline. Dezelfde logica geldt voor code.

Waar low-code echt werkt

Low-code is sterk voor interne tools en tijdgebonden toepassingen met een beperkte scope. Als je een dashboard wil bouwen voor een intern team, een formulierenworkflow wil digitaliseren, of een tijdelijk campagnepagina wil lanceren zonder maandenlange development: low-code levert.

De winnende combinatie die we regelmatig toepassen: low-code of een headless CMS voor de lagen die standaard zijn, custom tooling voor de onderdelen die het product echt uniek maken. Lefboom is daar een voorbeeld van: een sustainabilityplatform dat standaardfunctionaliteiten combineert met op maat gebouwde beloningslogica die het onderscheidende karakter van het platform bepaalt.

De platformlaag is generiek. De logica die het platform laat werken voor Lefboom's specifieke aanpak, is custom. Dat onderscheid bewust maken bij de start van een traject scheelt een herstart later.

De keuze die je aan het begin moet maken

De vraag is niet: vibe-coding of low-code? De vraag is: wat is de aard van dit product, en wat zijn de eisen die het over twaalf maanden stelt?

Als het antwoord is: validatie van een aanname, tijdelijk intern gebruik, of een prototype om draagvlak te bouwen, dan zijn vibe-coding of low-code prima keuzes. Ze zijn snel, relatief goedkoop, en voor die use case goed genoeg.

Als het antwoord is: een platform dat schaalt, een product met eigen logica, een systeem dat de komende jaren wordt doorontwikkeld, dan is een custom webapplicatie bijna altijd de betere investering. Niet omdat custom bouwen sneller of goedkoper is in de beginfase, maar omdat je later niet vastloopt in de limieten van een platform dat je niet volledig controleert.

Bij Livewall hanteren we als stelregel: begin zo eenvoudig als het doel toelaat, maar bouw op een manier die uitbreiding niet blokkeert. Die lijn bepaalt in de eerste gesprekken al of vibe-coding, low-code, of custom development de juiste aanpak is.

Een scherpe digitale strategie aan het begin van een traject is geen luxe. Het is de manier om te voorkomen dat je na een jaar opnieuw begint.