NAME
vibe-coding-agentic-engineering — Vibe-codering, na de huwelijksreis
SYNOPSIS
cat vibe-coding-agentic-engineering.md
DESCRIPTION
Vibe-codering is een van die uitdrukkingen die geboren lijken te worden gehaat en vervolgens langzaam nuttig worden.
In eerste instantie klinkt het als: ik denk niet na, ik vraag het aan de AI, ik accepteer wat eruit komt, ga door. Een vrolijke manier om technische schulden te produceren met een muzikale achtergrond.
Maar het zou te gemakkelijk zijn om het zo af te doen. De waarheid is dat vibe-codering iets echts heeft onderschept: programmeren met een model verandert de relatie tussen idee en prototype.
Eerst had je een gedachte en daarna een lange klim. Nu heb je vaak een gedachte en een half uur later beweegt er iets op het scherm. Het is moeilijk om je er niet door te laten verleiden.
De interessante vraag in 2026 is niet of vibe-codering waar is. Het is. De vraag is: wat gebeurt er na de huwelijksreis?
Het prototype is zuinig geworden
Dit is het belangrijkste onderdeel.
AI-tools hebben de emotionele kosten om aan de slag te gaan verlaagd. Vroeger, als je een idee wilde uitproberen, moest je al het werk doen: stapel kiezen, project maken, boilerplate onthouden, lay-out schrijven, API's verbinden, ruzie maken met saaie details.
Nu kun je zeggen: geef mij een eerste versie.
En er komt een eerste versie.
Niet altijd mooi. Niet altijd juist. Vaak kwetsbaar. Maar het komt. En als het arriveert, verandert het het gesprek. Je discussieert niet langer in een vacuüm. Je raakt iets aan.
Dit is zeer krachtig voor ontwerpers, oprichters, productmanagers, senior ontwikkelaars die het herschrijven van steigers beu zijn, en nieuwsgierige mensen die voorheen geen editor zouden hebben geopend.
Vibe-codering is een hype omdat het meer mensen de fysieke sensatie geeft van de software die wordt gemaakt.
Het probleem is dat de software voortleeft
Het deel dat de meme het minst vertelt, is de dag erna.
Het prototype moet worden gelezen. Juist. Getest. Ingezet. Beveiligd. Heb het van iemand anders gekregen. Verbonden met echte data. Toegankelijk gemaakt. Wordt onderhouden wanneer een afhankelijkheid verandert.
Hier komt pure vibe-codering tegen de muur.
Een model kan snel veel code genereren, maar code op zichzelf heeft geen waarde. Het is een belofte van gedrag. En een belofte moet worden geverifieerd.
Het risico van vibe-codering is niet het schrijven van lelijke code. We hebben het altijd gedaan, zelfs zonder AI. Het risico is dat je het gevoel van eigenaarschap verliest: ‘het model heeft het gedaan’ wordt een excuus om niet genoeg te begrijpen.
Maar de runtime accepteert geen excuses. Als de code in productie wordt uitgevoerd, is deze van jou.
Van sfeercodering tot agentische engineering
De volwassen versie van vibe-codering is niet stoppen met het gebruik van agenten. Het is om ze te gebruiken met een serieuzere cyclus.
Niet: het genereert alles en dat hopen we.
Maar:
- beschrijf de bedoeling;
- laat een concept genereren;
- vraag de agent om het plan uit te leggen;
- maak kleine verschillen;
- lanceringstests;
- doe beoordelingen;
- juist;
- Doe dan pas mee.
Dit ding verdient een andere naam. Ik hou van agent-engineering, ook al klinkt het een beetje plechtig. Het betekent dat agenten niet als speelautomaten worden gebruikt, maar als medewerkers binnen een engineeringproces.
Het punt is niet om energie weg te nemen van vibe-codering. Het geeft haar sporen.
Waar het geweldig werkt
Vibe-codering werkt wanneer de kosten van fouten laag zijn en de waarde van verkenning hoog is.
Voorbeelden:
- interface-prototypes;
- persoonlijke hulpmiddelen;
- interne dashboards;
- kleine spelletjes;
- eenmalig script;
- API-scans;
- proof-of-concept;
- mechanische refactoren met goede tests;
- technische inhoud die in demo's moet worden omgezet.
In deze gevallen is snelheid het punt. Je wilt zien of het idee benen heeft. Je wilt weten wat je niet hebt begrepen. Je wilt tot een concreet gesprek komen.
Vibe-codering is perfect om vorm te laten ontstaan.
Waar het gevaarlijk wordt
Het wordt gevaarlijk als het systeem consequenties heeft en niemand vertraagt.
Betalingen, persoonlijke gegevens, authenticatie, machtigingen, infrastructuur, databasemigraties, gevoelige oude code, compliance, productie. Hier is de sfeer niet genoeg. We hebben nauwkeurigheid nodig.
Dat betekent niet dat AI niet kan helpen. Sterker nog, het kan veel helpen. Maar het moet binnen nauwe grenzen werken: branch, sandbox, test, lint, review, feature flag, rollback.
De zin die op de monitor moet worden getatoeëerd is simpel: hoe sneller de agent, hoe leesbaarder het proces moet zijn.
Als je niet kunt uitleggen wat er is veranderd, heb je niet versneld. Je hebt zojuist de schuld verschoven van tijd naar begrip.
De nieuwe rol van de ontwikkelaar
Het meest interessante is dat de taak van de ontwikkelaar niet verdwijnt. Verander de dichtheid.
Minder tijd op de boilerplate. Meer tijd voor intentie, ontleding, beoordeling, integratie, testen, grenzen.
De ontwikkelaar wordt een soort technisch redacteur. Niet in de flauwe zin van ‘proeflezen’. In de sterke zin van het woord: het besluit wat moet bestaan, waar moet op worden bezuinigd, wat consistent is met het systeem, wat vertrouwen verdient.
Een goede redacteur neemt niet alles wat hij krijgt. Hij herschrijft het niet eens allemaal uit trots. Herkent goed materiaal, brengt het in vorm, beschermt de lezer.
Bij agenten is de lezer ook de toekomstige onderhouder. Vaak ben jij dat over drie weken.
Het patroon dat ik zie ontstaan
Het gezondste patroon is dit:
- menselijk: intentie, beperkingen, smaak, verantwoordelijkheid;
- agent: varianten, steigers, zoeken, lokale aanpassingen, repetitieve tests;
- infrastructuur: sandbox, CI, trace, rechten, implementatie;
- team: review, eigenaarschap, standaarden.
Wanneer een van deze stukken ontbreekt, raakt er iets vervormd.
Alleen maar menselijk: langzaam, vaak verzand door repetitief werk.
Alleen agent: snel, maar zonder gesitueerd oordeel.
Gewoon infrastructuur: elegant proces voor het produceren van nutteloze dingen.
Alleen team: zeer ordentelijk vergaderen rond een prototype dat nooit arriveert.
Het beste gebeurt als de stukken met elkaar praten.
Een kleine checklist
Voordat ik een vibe-gecodeerd prototype laat groeien, zou ik mezelf deze vragen stellen:
- begrijp ik de structuur van de code?
- bestaan er tests voor kritisch gedrag?
- weet ik welke bestanden de agent heeft aangeraakt?
- heb ik gegenereerde maar niet gebruikte code verwijderd?
- Zijn er geheimen, tokens of valse gegevens op de verkeerde plaats terechtgekomen?
- wordt de minimale toegankelijkheid gerespecteerd?
- Heeft de implementatie een rollback?
- Kan iemand anders dan ik het houden?
Als het antwoord op te veel vragen nee is, is het geen mislukking. Het is gewoon een prototype dat nog wat langer een prototype moet blijven.
Mijn lezing
Vibe-codering is een luid woord voor iets teders: de vreugde om een idee vorm te zien krijgen voordat de angst het tegenhoudt.
Ik wil het niet weggooien. Dat zou snobistisch zijn. Veel goede dingen worden zo geboren, half krom en levend.
Maar de resterende software heeft meer nodig. Het heeft begrip, testen, eigenaarschap, infrastructuur en grenzen nodig. Er is iemand nodig die zegt: cool, laten we het nu werkelijkheid maken.
Misschien gaat het in de toekomst niet om het kiezen tussen 'serieus' programmeren en 'vibe'-programmeren. Misschien is het leren om van versnelling te veranderen: licht verkennen en dan consolideren met respect.
Het menselijke deel is aanwezig. Weet wanneer je moet rennen en wanneer je moet zitten en het verschil moet lezen.
Bronnen
METADATA
- date: 2026-06-30
- reading: 6 min
- author: Filippo Spinella
- tags: AI, Coding, Agents, Developer Tools