Programmeren op gevoel in plaats van logica
Wat is vibe coding? De kortste samenvatting: je doet het op basis van vibes. Dat is het tegenovergestelde van wat een programmeur doet. Die doet niets op vibes, kijkt altijd naar de logica en zorgt dat alles klopt op basis van systemen en architectuur. We leggen het begrip volledig uit in wat is vibe coding; dit artikel draait om het verschil met AI-assisted coding.
De AI-assisted coder is nog geïnteresseerd in de output. De vibecoder niet meer. Die is alleen geïnteresseerd in: werkt het, ziet het er goed uit.
Michael Hofman
Bij de meest extreme vorm van vibe coding kijk je helemaal niet meer naar de output. Waarom niet? Omdat je niet geïnteresseerd bent, of omdat je niet eens de kennis hebt om die output te kunnen beoordelen.
Het verschil in één oogopslag
Dezelfde tools, een andere houding tegenover de output. Zo verhouden de twee aanpakken zich:
| Vibe coding | AI-assisted coding | |
|---|---|---|
| Interesse in de output | Alleen of het werkt en er goed uitziet. | Leest de belangrijke stukken en beoordeelt of het echt goed is. |
| Mening over de code | Geen, dus goede en slechte architectuur zien er hetzelfde uit. | Een duidelijke mening, en stuurt de architectuur direct bij. |
| Wat je overhoudt | Per definitie een proof of concept. | Productiecode die je echt kunt uitrollen. |
| Waarvoor geschikt | Prototypes, eenmalige scripts, kleine projecten met weinig risico. | Alles wat naar productie gaat of gaat groeien. |
| Grootste risico | Verborgen fouten blijven onzichtbaar tot ze in productie stukgaan. | Fouten worden tijdens het bouwen gezien en hersteld. |
AI-assisted development en AI-assisted coding betekenen hetzelfde
De terminologie is nog aan het uitkristalliseren, dus je komt AI-assisted development, AI-assisted coding en AI-assisted engineering tegen voor dezelfde praktijk. Ze beschrijven allemaal een developer die een mening houdt over de code die het model produceert. Zie je ergens vibe coding vs AI-assisted development staan, dan gaat het over precies deze scheidslijn: wie de output leest en wie niet.
Daarmee is ook de omgekeerde vraag beantwoord. Het tegenovergestelde van vibe coding is AI-assisted development: dezelfde tools, hetzelfde tempo, met iemand die nog steeds beoordeelt wat eruit komt. Terug naar alles met de hand schrijven is iets heel anders, en dat doet vrijwel niemand.
Van blind vertrouwen tot kritische controle
Het is geen binaire keuze. Er is een spectrum tussen pure vibe coding en pure AI-assisted coding:
Vibe coding (extreem)
Je kijkt niet naar de code. Je ziet alleen of het werkt. Als je dan toch vibecoded, kun je beter iets als Lovable gebruiken waar je de code niet eens ziet.
Vibe coding (mild)
Je kijkt soms naar de code, maar alleen als iets niet werkt. Je kopieert de foutmelding, plakt die terug en snapt niet wat er fout gaat.
AI-assisted coding
Je bent geïnteresseerd in wat er geproduceerd wordt en wil weten of het daadwerkelijk goed is. Je leest de belangrijke stukken code, ook als je niet elke regel langsgaat.
AI-assisted coding (kritisch)
Je controleert de code regel voor regel, ziet wanneer de AI de mist in gaat en stuurt direct bij. Je hebt een duidelijke mening over de architectuur.
Waar sta jij op dit spectrum? En belangrijker: waar zou je moeten staan voor wat je aan het bouwen bent?
Welk gereedschap daarbij hoort, van editors als Cursor tot bouwers als Lovable, zetten we op een rij in vibe coding tools: welke gebruik je?.
Opschuiven op dat spectrum is ook een kwestie van methode. De meest concrete manier is de spec schrijven voordat de AI de code schrijft, wat we vergelijken in vibe coding vs spec-driven development.
Zonder mening over code ben je een vibecoder
Een ander cruciaal verschil: heb je een mening over de code?
Iemand die ervaring heeft met het bouwen van software heeft een mening. Die kan zeggen: “Dit is niet de handigste manier om het te doen.” Of: “Dit past niet bij de architectuur die we hebben.”
Iemand die geen ervaring heeft, heeft geen mening. Die kan naar een stuk code kijken, maar kan niet de beslissing maken: is dit goed of niet? Die ziet alleen maar dat de applicatie doet wat die moet doen. Knopjes klikken, werkt het?
Je kan wel naar de code kijken en netjes alle output controleren. Maar als je er geen mening over hebt, doe je het nog steeds deels op vibes.
Dat geldt ook voor beginners. Als je net begint met programmeren en je wil geen vibecoder zijn, ben je het indirect toch. Je kan wel naar de code kijken, maar je hebt eigenlijk geen mening. Het enige verschil is dat je er wat van kan leren: je ziet de code, je leert de patronen, en misschien ga je over tijd van vibe coding naar AI-assisted coding. De vraag is alleen hoe vaak dat daadwerkelijk gebeurt, want het is heel menselijk om lui te blijven.
Vibe coding heeft zijn plek
Vibe coding is niet per se slecht. Het heeft zijn plek:
Kleine, losstaande projecten
Voor kleine projecten heb ik echt geen enkele moeite om te vibecoden. Het heeft geen impact als het niet werkt, het risico is heel laag.
Prototypes en validatie
Als je snel wil testen of een idee werkt, is vibe coding perfect. Je bouwt iets om te leren, niet om te deployen.
Eenmalige scripts
Een signature generator, een data-exportscript. Het maakt niet uit hoe lelijk de code is als het één keer werkt.
Frontend styling
Snel iets tweaken met Tailwind? Prima. Maar voor een design system van een enterprise dashboard moet je wel degelijk weten wat je doet.
De AI-assisted coder ziet fouten die de vibecoder mist
Een concreet voorbeeld: je bouwt een applicatie met een state machine. Bij AI-assisted coding zie je op een gegeven moment dat de AI de fout in gaat. Je ziet: “Oké, wat je nu gaat doen klopt niet. Dat is gewoon fout.” Je hebt de hele context van de app in je hoofd. Je weet dat dit niet past bij de stijl van de rest, of niet bij de ideologie die je hebt.
Bij vibe coding merk je dit niet. Je ziet alleen dat het werkt of niet werkt. De onderliggende fout blijft verborgen tot het later problemen veroorzaakt.
Vaak mist de AI iets. Dan is de oplossing dat je denkt: dit werkt. Maar ik heb de hele context van de app in mijn hoofd. Dit is niet de ideologie die we hebben.
Drie signalen dat je moet switchen
Er zijn drie duidelijke signalen dat je van vibe coding naar AI-assisted coding moet overstappen:
Te groot voor de context
Zodra het project te groot wordt om in één keer in de context te passen en de AI het niet meer kan overzien, gaat hij de mist in.
Je schrijft productiecode
Als de code daadwerkelijk in productie gaat draaien, moet je weten wat je doet. Vibe coding levert per definitie een proof of concept op, geen productieklare software.
Je weet dat het groot gaat worden
Begin je aan iets waarvan je nu al weet dat het een groot project wordt? Start dan meteen met AI-assisted coding in plaats van later te moeten refactoren.
Als de AI de context verliest, zie je dat hij dingen dubbel gaat doen, features herbouwt die je al hebt, of features bouwt voor iets wat niet bestaat of niet nodig is.
Conclusie: weet waar je staat op het spectrum
Vibe coding en AI-assisted coding zijn beide valide benaderingen. Het probleem ontstaat als je niet weet waar je staat, als je denkt productiecode te schrijven terwijl je eigenlijk een proof of concept maakt.
Vibe coding = proof of concept
De vibecoder maakt altijd een proof of concept, of die nou wil of niet. Als je niet naar de code kijkt en er geen mening over hebt, maak je per definitie een concept.
AI-assisted coding = productiecode
Pas als het gecheckt is door iemand die het werk in de code heeft gestoken en er een mening over heeft, is het productiecode die je kan deployen.
Ken jezelf, weet waar je staat op het spectrum en weet wanneer je moet switchen. Werkend is niet hetzelfde als productiewaardig.
Wat is vibe coding?
Wat is het verschil tussen vibe coding en AI-assisted coding?
Is AI-assisted development hetzelfde als AI-assisted coding?
Is vibe coding slecht?
Wanneer moet ik overstappen van vibe coding naar AI-assisted coding?
Kun je met vibe coding productieklare software maken?
Heb je een vibe-coded project dat productie-klaar moet?
We helpen founders en teams om van proof of concept naar productiecode te gaan: een audit om te weten wat er nodig is, of de techniek volledig uit handen geven.
