Vibe coding

Wat is vibe coding?

Vibe coding is software bouwen door in gewone taal te beschrijven wat je wil, de code die het model teruggeeft aannemen zonder ze te lezen, en dan verder sleutelen aan het draaiende resultaat. Je blijft kijken naar wat werkt en wat niet werkt. De code zelf open je nooit echt.

Andrej Karpathy gaf de praktijk die naam in een bericht begin februari 2025: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." In datzelfde bericht beschreef hij hoe hij elke voorgestelde wijziging aanvaardde zonder de diffs te bekijken, foutmeldingen zonder uitleg terug in de tool plakte, en de code liet groeien tot voorbij het punt waarop hij nog zou kunnen zeggen wat ze deed. Hij had het over zijn eigen weekendprojecten.

De term raakte veel verder dan dat. Collins Dictionary koos vibe coding op 6 november 2025 tot woord van het jaar, met als omschrijving "the use of artificial intelligence prompted by natural language to write computer code".

Die omschrijving is ruimer dan wat Karpathy bedoelde, en dat verschil is het onthouden waard. Bij Collins doet elke ontwikkelaar die een AI-assistent iets laat schrijven aan vibe coding. Bij Karpathy zit de kern in wat je overslaat: het nalezen.

Waar vibe coding wel werkt

De gevallen waarin het goed uitdraait, hebben iets gemeen. Niemand moet achteraf nog met die code leven.

• Wegwerpprototypes. Je wil het idee op een scherm zien voor je beslist of er budget naartoe gaat. Een versie die draait, beantwoordt vragen waar een document twee weken over discussieert.

• Scripts die je één keer draait. Vierduizend bestanden hernoemen, een lastige CSV-export in vorm trekken, een cijfer uit een map met pdf's halen. Het script doet zijn werk en mag daarna weg.

• Iets uitzoeken dat je nog niet kan beschrijven. Soms is de snelste weg naar een scherpe vraag drie slechte versies van het antwoord.

• Persoonlijke hulpmiddelen met precies één gebruiker. Als het stukloopt, treft dat alleen de persoon die het heeft gevraagd, en die weet hoe het gemaakt is.

Een voorbeeld. Een salesverantwoordelijke vraagt zich af of marge per klant per maand iets zou veranderen aan hoe het team zijn accounts aanpakt. In plaats van een aanvraag in te dienen, beschrijft ze de berekening aan een model, krijgt ze een klein script dat de export van vorig jaar inleest en er een grafiek van maakt, en kijkt ze ernaar. Die grafiek volstaat om te weten dat het antwoord ja is. Het script heeft zijn nut gehad en hoeft het gesprek daarna niet te overleven.

Vibe coding tegenover nagelezen AI-ondersteund ontwikkelen

Simon Willison, die de term na de hype het scherpst heeft afgebakend, zegt het zonder omwegen: vibe coding is "building software with an LLM without reviewing the code it writes". En aan de andere kant van die lijn: "If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that's not vibe coding, it's software development."

Dat onderscheid gaat in de meeste gesprekken verloren. Een ontwikkelaar die elke wijziging leest, de tests laat lopen en de opzet kan verdedigen in een review, werkt met dezelfde tools een pak sneller, en niets daarvan is vibe coding in de oorspronkelijke betekenis. Willison noemt die professionele variant vibe engineering en stelt dat ze méér discipline vraagt dan werken zonder die tools, want je hebt tests nodig die goed genoeg zijn om een model tegenaan te laten werken.

Het verschil met low-code en citizen development

Een low-codeplatform geeft een medewerker een vaste set bouwstenen in een omgeving die iemand beheert: benoemde connectoren, rechtenmodellen, een overzicht van wat er bestaat. Een citizen developer bouwt binnen die muren, en die muren zijn net het punt.

Bij vibe coding zijn er geen muren. Wat je terugkrijgt is een gewoon codebestand dat alles kan aanspreken waar de machine die het draait bij kan. Precies daarom is het flexibeler, en precies daarom staat het nergens geïnventariseerd.

Waar moet je op letten bij het gebruik van vibe coding

Onderhoud dient zich als eerste aan. Zodra er iets moet veranderen, zit iemand voor code die nooit iemand gelezen heeft. Het geheel terug aan een model geven en de wijziging vragen is een echte optie, en ze werkt tot ze niet meer werkt. Dan is er geen terugval, want er is nooit begrip opgebouwd om op terug te vallen.

Beveiliging dient zich als tweede aan, en stiller. Veracode testte in 2025 meer dan honderd large language models op tachtig programmeeropdrachten en rapporteerde dat 45 procent van de gegenereerde code een beveiligingsfout bevatte. Een model schrijft wat de prompt gevraagd heeft. Stond er niets in over invoercontrole of toegangsrechten, dan staat dat er ook niet in het resultaat, en niemand die het nakijkt merkt het op, want niemand kijkt het na.

Daarnaast is er alles wat veronderstelt dat een mens de software kan uitleggen: een audit, een overdracht wanneer de maker van job verandert, een klant die vraagt hoe een cijfer berekend is, een vraag over waar persoonsgegevens terechtkomen. Voor elk van die momenten is er een antwoord nodig dat vibe coding per definitie niet levert.

Wanneer een vibe-coded tool in dagelijks gebruik belandt

In een kleiner bedrijf loopt dat meestal hetzelfde. Iemand van operations bouwt een klein dingetje dat een echte ergernis oplost. Twee collega's beginnen het te gebruiken. Daarna voedt het een wekelijks rapport, en op een dag ziet een klant een cijfer dat eruit komt. Nergens in dat verhaal heeft iemand beslist dat het nu een systeem is.

Er is daar ook niets misgelopen. Het ding was nuttig en het was sneller gebouwd dan om het even welk alternatief. Wat ontbreekt, is een moment waarop iemand de vraag naar eigenaarschap hardop stelt.

Vier vragen volstaan meestal om dat op tijd te zien:

1. Wie herstelt dit als het op een vrijdag stukloopt?

2. Wat gebeurt ermee als de maker vertrekt?

3. Raakt het aan persoonsgegevens of aan financiële cijfers?

4. Gaat er een cijfer uit naar een klant, een boekhouder of een bank?

Zijn de antwoorden geruststellend, dan is er geen probleem. Zijn ze dat niet, dan is het geen prototype meer en heeft het iemand nodig die de code leest, ze test en er verantwoordelijkheid voor neemt. Op dat moment is dat een kleine stap. Twee jaar later is het een dure.