"Vibe coding" deed zijn intrede in het vocabulaire in 2025, bedacht om een nieuwe manier van software bouwen te beschrijven: je beschrijft wat je wilt in gewone taal, een AI genereert de code, en je schroeft eraan tot het goed aanvoelt. De belofte was verleidelijk. Iedereen kon software bouwen door te "viben" met een AI.
En de demo's waren verbluffend. In video's van vijf minuten bouwden mensen wat leek op complete applicaties: dashboards, landingspagina's, zelfs SaaS-producten. Social media stond bol van de voorbeelden. De boodschap was duidelijk: traditionele softwareontwikkeling was voorbij.
Toen probeerden mensen deze applicaties in de echte wereld te gebruiken. En de scheuren werden zichtbaar.
Dit artikel is geen aanval op vibe coding. Het gaat over het begrijpen van een cruciaal onderscheid dat iedereen die investeert in software moet kennen: het verschil tussen code die er goed uitziet en code die goed werkt. Tussen een prototype en een product. Tussen AI-ondersteund coderen en AI-gedreven ontwikkeling.
Wat vibe coding precies is
Vibe coding houdt doorgaans in dat je in een code-editor zit die versterkt is met AI (Cursor, GitHub Copilot, Windsurf) of werkt in een prompt-naar-app tool zoals Lovable, Bolt of v0, en code genereert door middel van conversatie. Je vertelt de AI wat je wilt, die schrijft de code, je draait het, bekijkt wat er gebeurt en vraagt om aanpassingen.
De workflow ziet er ongeveer zo uit:
- "Bouw me een dashboard dat verkoopdata toont"
- AI genereert een React-component met grafieken
- "Maak de grafieken blauw en voeg een datumfilter toe"
- AI past de component aan
- "Het crasht als ik op het filter klik"
- AI fixt de directe fout
- Herhaal tot het er goed uitziet op je scherm
Dit werkt opmerkelijk goed voor bepaalde dingen. Landingspagina's, visuele prototypes, proof-of-concept demo's, persoonlijke projecten en hackathon-inzendingen profiteren enorm van deze aanpak.
Het probleem ontstaat wanneer mensen de output aanzien voor productiesoftware.
Het ijsbergprobleem
Wat je op het scherm ziet bij vibe coding is het topje van de ijsberg. Een werkende interface met data die erdoorheen stroomt. Wat je niet ziet — wat onder het wateroppervlak leeft — is alles wat een demo scheidt van een product.
Wat zichtbaar is (boven de waterlijn)
- De gebruikersinterface
- Eenvoudige dataweergave
- Simpele interacties (klikken, typen, versturen)
- Het "happy path": wat er gebeurt als alles goed gaat
Wat verborgen is (onder de waterlijn)
- Foutafhandeling: Wat gebeurt er als de database onbereikbaar is? Als de sessie van de gebruiker halverwege een formulier verloopt? Als iemand een emoji invoert in een telefoonnummerveld?
- Beveiliging: Is de API geauthenticeerd? Kan de ene gebruiker de data van een andere gebruiker inzien door een URL-parameter te wijzigen? Zijn wachtwoorden gehasht? Is invoer gesanitized tegen injection-aanvallen?
- Data-integriteit: Wat als twee mensen tegelijk hetzelfde record bewerken? Wat als de server crasht midden in een transactie? Kun je herstellen van datacorruptie?
- Performance onder belasting: Het werkt prima met één gebruiker. Maar met vijftig? Vijfhonderd? Werkt de pagina die in 200ms laadt met tien records nog steeds met tienduizend?
- Toegankelijkheid: Kan iemand met een schermlezer door de applicatie navigeren? Werkt het met alleen toetsenbordinvoer?
- Randgevallen: Wat gebeurt er op de laatste dag van de maand? Tijdens zomer-/wintertijdovergangen? Als een gebruiker een extreem lange naam heeft? Als het bestandsupload een video van 500MB is in plaats van een afbeelding van 2MB?
- Deployment en operations: Hoe komt dit in productie? Wie monitort het? Wat gebeurt er om 3 uur 's nachts als het SSL-certificaat verloopt?
Vibe coding levert doorgaans code op die de bovenkant van de ijsberg goed afhandelt en de onderkant volledig negeert. Dit is geen fout in de tools. Het is inherent aan de aanpak. Wanneer je itereert op gevoel, focus je van nature op wat je direct kunt zien en ervaren.
Gevolgen in de praktijk
Dit zijn geen theoretische zorgen. Hier zijn patronen die we herhaaldelijk zien wanneer vibe-gecodeerde applicaties in productie gaan.
Het beveiligingsincident
Een startup bouwde hun klantenportaal via vibe coding. De interface was gepolijst. De demo maakte indruk op investeerders. Toen ontdekte een beveiligingsonderzoeker dat het wijzigen van de klant-ID in de URL de data van elke willekeurige klant toonde. Er was geen autorisatiecontrole op de API: de AI had endpoints gegenereerd die data teruggaven op basis van de ID-parameter zonder te verifiëren of de aanvragende gebruiker toestemming had om het te zien.
Dit is een van de meest voorkomende beveiligingskwetsbaarheden (bekend als IDOR, oftewel Insecure Direct Object Reference), en het is precies het soort ding dat niet naar boven komt tijdens achteloos testen maar serieuze aansprakelijkheid creëert.
Het dataverlies
Een klein bedrijf verving hun spreadsheet-gebaseerd voorraadsysteem door een vibe-gecodeerde applicatie. Het werkte prima gedurende drie maanden. Toen veroorzaakte een serverupdate het falen van een databasemigratie. Omdat de applicatie geen backupstrategie had, geen migratietesten en geen rollback-mechanisme, verloren ze twee maanden aan voorraaddata.
De oorspronkelijke ontwikkelaar (een niet-technische oprichter die AI-codeertools gebruikte) had nooit nagedacht over deployment-infrastructuur omdat de AI-assistent er nooit naar had gevraagd.
De schalingsfout
Een bureau bouwde een boekingssysteem voor een klant via vibe coding. Het werkte perfect tijdens ontwikkeling en de eerste lancering. Tijdens hun eerste drukke seizoen, met 200 gelijktijdige gebruikers in plaats van 20, gingen de laadtijden van 1 seconde naar 45 seconden. De AI-gegenereerde database-queries haalden hele tabellen op in het geheugen en filterden client-side, een patroon dat prima werkt met kleine datasets maar instort op schaal.
Hoe methodische AI-ontwikkeling eruitziet
Het alternatief voor vibe coding is niet teruggaan naar traditionele ontwikkeltijdlijnen en -budgetten. Het is AI-ontwikkeling die engineeringdiscipline volgt.
Het verschil zit in de methodiek. Dit is wat een gedisciplineerde AI-ontwikkelaanpak onderscheidt van informeel vibe coding:
Gestructureerde requirements-analyse
In plaats van itereren op gevoel, begint het proces met gestructureerde requirements. De briefing wordt geanalyseerd en opgebroken in specifieke, testbare eisen voordat er code wordt gegenereerd. Dit vangt ambiguïteiten en hiaten op voordat ze bugs worden.
Test-driven development
Code wordt gegenereerd samen met geautomatiseerde tests. Elke feature heeft tests die verifiëren dat het correct werkt, fouten afhandelt en beveiliging waarborgt. Deze tests draaien automatisch bij elke wijziging en vangen regressies op voordat ze gebruikers bereiken.
Dit is een fundamenteel verschil. Bij vibe coding is testen handmatig: je klikt rond en kijkt of dingen er goed uitzien. Bij methodische AI-ontwikkeling is testen geautomatiseerd en uitgebreid.
Beveiliging standaard ingebouwd
Authenticatie, autorisatie, invoervalidatie en databescherming zijn geen bijzaak die er aan het eind wordt opgeplakt. Ze worden vanaf het begin ingebouwd in de gegenereerde code. API-endpoints controleren rechten. Gebruikersinvoer wordt gevalideerd en gesanitized. Gevoelige data wordt versleuteld. Datzelfde geldt voor privacy: wie met persoonsgegevens werkt, wil weten waar die data staat. Een methodische aanpak maakt AVG-naleving en dataopslag binnen de EU een expliciete ontwerpkeuze in plaats van toeval.
Deployment pipeline
Productiesoftware heeft meer nodig dan code. Het heeft een deployment pipeline nodig: staging-omgevingen om te testen, preview-URL's voor klantbeoordeling, geautomatiseerde deployments, monitoring, backups en rollback-mogelijkheden.
Wanneer er iets misgaat in productie (en er gaat uiteindelijk altijd iets mis), is de vraag niet of het zal gebeuren, maar hoe snel en netjes je kunt herstellen.
Codekwaliteitsstandaarden
AI kan enorm inconsistente code genereren. Zonder vangrails krijg je een codebase waar elk bestand eruitziet alsof het door een andere developer op een andere dag is geschreven. Methodische AI-ontwikkeling dwingt consistentie af: naamgevingsconventies, bestandsorganisatie, foutafhandelingspatronen en architectuurbeslissingen worden gestandaardiseerd.
Dit is belangrijk omdat software onderhouden moet worden. Zelfs als AI het heeft gebouwd, zal iemand (of een AI) het later moeten aanpassen. Consistente, goed georganiseerde code is dramatisch eenvoudiger te onderhouden dan een lappendeken van ad-hoc oplossingen.
Een zij-aan-zij vergelijking
| Dimensie | Vibe Coding | Methodische AI-ontwikkeling |
|---|---|---|
| Startpunt | "Bouw me een dashboard" | Gestructureerde briefing met requirements |
| Ontwikkelproces | Itereren tot het er goed uitziet | Requirements, tests, implementatie, review |
| Testen | Handmatig doorklikken | Geautomatiseerde testsuites |
| Foutafhandeling | Crashes fixen als ze verschijnen | Uitgebreide foutafhandeling vanaf het begin |
| Beveiliging | Toegevoegd als iemand erom vraagt | Standaard ingebouwd |
| Deployment | "Het werkt op mijn machine" | CI/CD pipeline, staging, productie |
| Rollback | Niet mogelijk | Eén-klik versie-rollback |
| Onderhoud | Fragiel, moeilijk aan te passen | Gestructureerde, onderhoudbare codebase |
| Geschikt voor | Prototypes, demo's, persoonlijke projecten | Bedrijfsapplicaties, klantgerichte software |
Wanneer vibe coding de juiste keuze is
Om eerlijk te zijn, vibe coding heeft legitieme toepassingen:
- Een idee verkennen: Voordat je budget vastlegt voor een volledige build, kan een snel vibe-gecodeerd prototype valideren of je concept hout snijdt.
- Interne tools voor één persoon: Als jij de enige gebruiker bent en de risico's laag zijn, is de engineeringoverhead van productiekwaliteit software wellicht niet gerechtvaardigd.
- Leren en experimenteren: Vibe coding is een fantastische manier om programmeerconcepten te leren en te ontdekken wat mogelijk is.
- Statische websites en landingspagina's: Sites die voornamelijk content weergeven zonder complexe bedrijfslogica of gebruikersdata kunnen prima zijn wanneer ze vibe-gecodeerd zijn.
De problemen ontstaan wanneer vibe-gecodeerde software wordt gedeployed alsof het productiesoftware is, met echte gebruikersdata, echte transacties of echte bedrijfsprocessen.
Wanneer je meer nodig hebt
Als een van deze punten van toepassing is op jouw project, heb je meer nodig dan vibe coding:
- Andere mensen zijn ervan afhankelijk. Klanten, medewerkers of partners gebruiken deze software om hun werk te doen.
- Het verwerkt gevoelige data. Persoonlijke informatie, financiële gegevens, gezondheidsdata of wat dan ook dat onder privacyregelgeving valt.
- Het moet betrouwbaar draaien. Downtime kost geld, reputatie of vertrouwen.
- Het is onderdeel van je businessmodel. Omzet hangt af van het correct functioneren van deze software.
- Meerdere gebruikers benaderen het tegelijk. Gelijktijdigheid creëert complexiteit die informeel testen niet zal vangen.
- Het moet kunnen groeien. Vandaag zijn het tien gebruikers; volgend jaar duizend.
Voor deze gevallen brengen prompt-naar-app tools als Lovable, Bolt of v0 je snel bij een werkend prototype, maar heb je uiteindelijk AI-ontwikkeling met een methodische aanpak nodig (zie ook: een Lovable-alternatief voor productiesoftware). Platforms zoals Turtleship bestaan specifiek om deze kloof te overbruggen. Ze geven je de snelheid en toegankelijkheid van AI-aangedreven ontwikkeling terwijl de kwaliteitsstandaarden worden gehandhaafd die productiesoftware vereist. Functies zoals goedkeuringsworkflows, preview-URL's en rollbacks met één klik bestaan omdat productiesoftware vangrails nodig heeft, niet alleen generatie.
Het volwassenheidsspectrum
Zie AI-softwarecreatie als een spectrum:
Handmatig coderen (langzaamst, meeste controle) → AI-ondersteund coderen (sneller, vereist developer) → Vibe coding (snel, onzekere kwaliteit) → Methodische AI-ontwikkeling (snel, productiekwaliteit)
De industrie wordt volwassener. Net zoals vroege webontwikkeling evolueerde van "iedereen kan een website maken in FrontPage" naar professionele webontwikkelpraktijken, evolueert AI-aangedreven softwarecreatie van "kijk wat ik in 5 minuten heb gebouwd" naar "hier is een productieapplicatie gebouwd volgens professionele standaarden."
De winnaars in deze ruimte zullen niet de tools zijn die het snelst code genereren. Het zullen degenen zijn die code genereren die het beste werkt: betrouwbaar, veilig en op schaal.
De juiste keuze maken
Voordat je aan je volgende softwareproject begint, stel jezelf één vraag: is dit een prototype of een product?
Als het een prototype is — iets om een idee te testen, een concept te tonen of van te leren — is vibe coding geweldig. Het is snel, het is leuk en de risico's zijn laag.
Als het een product is — iets waar mensen op vertrouwen, dat echte data verwerkt, dat je bedrijf vertegenwoordigt — investeer dan in een aanpak die het ook zo behandelt. De kosten vooraf om dingen goed te doen zijn altijd lager dan de kosten om dingen te repareren die verkeerd zijn gedaan.
Het tijdperk van AI-gebouwde software is aangebroken. De vraag is niet langer of AI jouw software kan bouwen. Het is of de AI-gebouwde software voldoet aan de standaarden die jouw bedrijf vereist. Kies dienovereenkomstig.
Twijfel je of jouw idee een prototype of een product is? Start gratis en laat Turtleship je briefing omzetten in geteste, productieklare software. Ben je nieuw met dit soort tools? Lees dan eerst hoe je software bouwt zonder developers.
Verder lezen
Vond je dit nuttig? Lees dan verder: