Andrej Karpathy — co-founder OpenAI, voormalig AI-director bij Tesla — bedacht de term "Vibe Coding" in februari 2025. Zijn exacte woorden:
"I fully give in to the vibes. I 'Accept All' always. I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment." — Andrej Karpathy, X/Twitter, 3 februari 2025
Collins Dictionary riep het uit tot Woord van het Jaar 2025. 25% van de Y Combinator W25-batch claimt dat 95% van hun code door AI is geschreven.
Klinkt als een revolutie. Maar laten we even inzoomen.
De cijfers die niemand op LinkedIn deelt
Lees die laatste nog eens. Langzamer. Terwijl ze dachten dat ze sneller waren.
Wat er gebeurt als "iedereen kan coderen"
"100% AI-geschreven code." Dagen na launch bleek de beveiliging alleen client-side te bestaan. Wachtwoorden lagen in JavaScript-variabelen.
170 van 1.645 apps hadden geen database-beveiliging (row-level security).
Verwijderde autonoom 1.206 records uit een productiedatabase — ondanks expliciete instructies in HOOFDLETTERS om niets aan te raken.
Een scan van 5.600 vibe-coded apps vond 2.000+ kritieke kwetsbaarheden in productie, 175 gevallen van persoonsdata-exposure en 400+ gelekte secrets.
Wat Karpathy vergat te vermelden
Hij is een van de meest ervaren computerwetenschappers ter wereld. Hij KAN de code lezen als het misgaat. Dat onderscheid is essentieel — en gaat structureel verloren in de hype.
"Fine for learning. Horrible, horrible idea from a maintenance standpoint." — Linus Torvalds
"It's misleading a lot of people into thinking, just go with the vibes." — Andrew Ng
"If an LLM wrote the code and you then reviewed it — that's not vibe coding, it's software development." — Simon Willison
Uit de praktijk — waarom de eerste worp niet genoeg is
Ik werk dagelijks met AI als co-piloot. Niet als piloot. Het verschil wordt zichtbaar zodra je voorbij de eerste worp gaat.
Bug-escalatie die geen prompt oplost
Een Android audio-opname feature leek te werken na de eerste AI-gegenereerde code. Maar de opnames waren stil. Debuggen onthulde dat de OEM een interne UID-restrictie toepast op audio-streams: hun eigen telefoon-app mag de gespreksstroom opnemen, derde-partij apps worden actief onderdrukt door het AudioPolicy-framework. Zonder root geen workaround. De gehele architectuur — 27 bestanden, 5 services — moest worden weggegooid en herbouwd als 22 bestanden met 1 service en een compleet ander ontwerpmodel.
Dat is geen "paste the error and try again." Dat is architectuur.
6 sessies voor één root cause
Een API-integratie faalde op authenticatie. Zes opeenvolgende sessies lang werden configuratiebestanden aangepast, tokens ververst, binaries vervangen. Niets werkte. De doorbraak kwam pas toen ik met procesdiagnostiek de environment variables van het draaiende proces inspecteerde en ontdekte dat het systeem een ander configuratiebestand laadde dan gedocumenteerd. Vijf eerdere fixes waren in het verkeerde bestand gezet.
Root cause analyse op drie niveaus lost dit op. Niet "een betere prompt."
De onzichtbare systeembug
Een standaard shellscript gebruikte een gangbare variabelenaam. In de specifieke shell-omgeving bleek die naam een reserved keyword te zijn dat direct de systeemvariabele PATH overschrijft. Eén toewijzing, en alle standaard commando's verdwijnen. Dit is geen bug die je in je code ziet. Dit is infrastructuurkennis. De fix moest ecosysteembreed worden uitgerold: 4 beveiligingsniveaus, 11 verboden variabelenamen.
Platform-kennis die geen LLM heeft
Een video-overlay voor inkomende gesprekken werkte perfect op stock Android. Op een specifiek merk werd de overlay onzichtbaar — de OEM-skin claimt een hogere z-order dan het standaard overlay-windowtype. De oplossing: een AccessibilityService met een specifiek windowtype. Dit staat in geen enkele tutorial. Dit leer je door 11 builds in één sessie te doorlopen. Iteratief, gedocumenteerd, traceerbaar.
Wat ik wél doe — en waarom het werkt
Mijn ecosysteem omvat 34 projectgroepen, 49 repositories, 3 AI-agenten die op dezelfde codebases werken. Eén project alleen al heeft 143 builds doorlopen — elk met een semantisch versienummer, buildnummer en thematische codenaam.
Dit is geen chaos. Dit is gedisciplineerde engineering MET AI:
WhatIf Protocol
Begrip terugkoppelen, plan voorleggen, impactanalyse, akkoord vragen — vóórdat er ook maar één regel code wordt geschreven. Ontstaan nadat AI tegenstrijdige implementaties bouwde.
Root Cause Analyse op 3 niveaus
Functioneel, technisch, architectonisch. Niet "het werkt weer" maar "waarom brak het en hoe voorkomen we dit structureel."
23 architectuurprincipes (Dragon1)
Over 7 Design Areas — elk principe voortgekomen uit een concrete fout. Niet theoretisch, maar empirisch.
Volledige traceerbaarheid
Elke wijziging gedocumenteerd, elk besluit vastgelegd, elke sessie reproduceerbaar. Met encrypted dossiers en meerdere agenten is een audit trail geen luxe.
Memory als architectuurlaag
Kennis die niet verloren gaat tussen sessies, agenten of maanden. Geen "even opnieuw uitleggen wat we vorige keer deden."
AI is een fantastisch hulpmiddel voor de eerste worp. Een prototype, een proof of concept, een snelle verkenning. Daar is niets mis mee.
Maar als je na die eerste worp kwalitatief voorspelbaar verder wilt — als je wilt dat iteratie N+1 beter is dan N zonder N-1 onderuit te halen — dan heb je nodig wat geen prompt je geeft:
Architectuurkennis. Proceskennis. Methodische discipline. Wetenschappelijk denken. Platform-expertise.
En het vermogen om te herkennen wanneer de AI het niet weet — want dat zegt hij er niet bij.
Vibe Coding is leuk voor de vibe.
Voor alles daarna heb je een engineer nodig.
Christian Glebbeek — iCt Horse · Connecting the dots