Kan vibe coding bij de tijd blijven in de toekomst?

Vibe coding is haast een nieuw muziekgenre. Althans, dat willen de platform engineers die deze vorm van programmeren populair hebben gemaakt, ons doen geloven. In tegenstelling tot ‘imperatieve’ codering, waarbij een ontwikkelaar werkt met stapsgewijze logica, loops en statuswijzigingen, maakt vibe coding gebruik van hoogwaardige prompts. Dit moet AI-agents aansturen die de creatieve intentie van een gebruiker (ook wel de ‘vibe’ van wat ze willen) codificeren. Daarmee bouwen ze een deel of het geheel van de vereiste codebase, of een kleiner onderdeel van een applicatie of dataservice. Maar muzikale trends veranderen, dus kan vibe-codering altijd gelijke tred houden?

Laten we ons een typisch scenario voorstellen dat een ontwikkelaar zou kunnen meemaken. Ze krijgen een nieuw idee (of een vibe) en openen hun IDE en beginnen te hacken. Om het proces te versnellen, gooien ze een paar prompts in een LLM, zoals “bouw een dashboard dat modern aanvoelt” en het proces begint.

Het model bouwt vervolgens een interface op, d.w.z. het genereert de basisstructuur, lay-out en standaardcode… en fabriceert vervolgens een /stats-eindpunt. Dat is bijvoorbeeld een API-route die realtime gegevens, statistieken of gebruiksanalyses levert. Dit doet men om de UI te vullen; men gaat ervan uit dat authenticatie al is afgehandeld met een automatisch verlengende sessie. Maar het probleem is dat geen van die contracten daadwerkelijk in het systeem van de ontwikkelaar bestaat. Dit betekent dat wanneer ze de outputs gaan samenvoegen, ze er al snel onhandig uitzien op de dansvloer, omdat de vibe minder funky wordt.

Oh oh oh, het is magie

Een paar uur lang voelde het als magie, maar het duurt niet lang voordat de onduidelijkheid zich opstapelt. Het is een realiteit die Cian Clarke vaker heeft zien gebeuren dan hij zich kan herinneren. Clarke is hoofd AI bij Nearform, een bedrijf dat bekend staat als een digitaal adviesbureau van experts die hoogwaardige AI-oplossingen, softwareplatforms en datagestuurde producten voor ondernemingen bouwen.

“Vage prompts leiden uiteindelijk tot meer hallucinaties en het model begint druk werk voor zichzelf te creëren. Uiteindelijk heb je een opslagplaats vol rommel. Hoewel context windows kunnen helpen bij de prompt om het probleem te verzachten, zijn ze geen architectonisch geheugen. Uiteindelijk helpt deze aanpak je niet echt om een functie te bouwen, het creëert alleen maar technische schuld,” aldus Clarke.

In plaats daarvan, zegt hij, zijn de teams die winnen degenen die “de intentie nauwkeurig coderen”, omdat daar de echte waarde ligt. Het is bijna alsof je, zelfs als de vibe funky is, de moeite neemt om een paar danspasjes vast te leggen om de weg te wijzen. In termen van softwareontwikkeling noemen we dat spec-driven development (SDD) en het is een van de sterkste opkomende methoden die engineers helpt om in de vibe te blijven.

Dit komt omdat het de zakelijke intentie vertaalt naar machine-readable beperkingen, die zowel mensen als AI kunnen volgen.

Context engineering

“Dit betekent dat de meest cruciale vaardigheid voor de moderne ontwikkelaar niet langer het uit het hoofd leren van syntaxis is, maar context engineering. Dat betekent niet dat we creativiteit verliezen. Het betekent dat we creativiteit op een andere manier kanaliseren. Dit is het tijdperk waarin ontwikkelaars het vak van het achterhalen van invarianten en het coderen van contracten moeten aanscherpen – en zich moeten richten op het tot stand brengen van de enige bron van waarheid die het ontwerp, de generatie en de verificatie stuurt,” aldus Clarke. “Laten we eerst eerlijk zijn over waarom vibe coding aan het verdwijnen is. Het werkte toen teams nog klein waren en er weinig op het spel stond, want in de beginfase van een startup of tijdens rapid prototyping is snel handelen en dingen kapotmaken een geldige strategie.”

Maar volgens Clarke zijn AI-tools geen gedachtenlezers, dus kunnen ze geen vibes interpreteren. Wanneer je een LLM dubbelzinnige, hoogwaardige instructies voert, zal deze onvermijdelijk dubbelzinnige, verzonnen code genereren. In werkelijkheid verhoogt dubbelzinnigheid in prompts de entropie, leiden ontbrekende beperkingen tot verzonnen afhankelijkheden en zorgen ontbrekende schema’s ervoor dat modellen structuren verzinnen. Op korte termijn kan dit oppervlakkig indrukwekkende code opleveren, maar op lange termijn betekent het dat de ontwikkelaar zichzelf opzadelt met een heleboel herwerk, inconsistentie en lage reproduceerbaarheid.

AI vereist precisie om bruikbare, schaalbare output te genereren. Zonder die precisie besteden ontwikkelaars meer tijd aan het debuggen van de fouten van de AI dan ze zouden hebben besteed aan het zelf schrijven van de code vanaf nul.

Vervallen in silo’s

Vibe coding creëert ook enorme silo’s van kennis. Dit omdat kennis alleen bestaat in het hoofd van de oorspronkelijke ontwikkelaar (of in de context window van een chatsessie die al lang voorbij is). Dit maakt schaalbaarheid bijna onmogelijk, omdat de codebase een begraafplaats wordt van halfbakken ideeën die aan elkaar zijn geplakt door intuïtie in plaats van architectuur, en het inwerken van nieuwe teamleden wordt een nachtmerrie,” legt Clarke uit.

We hebben dit proces al eens gezien. De opkomst van PowerApps, low-code platforms en snelle WYSIWYG-bouwers beloofde hetzelfde. Het resultaat was een reeks onbeheersbare black boxes, zonder versiebeheer of governance voor de implementatie.

De zakelijke impact hiervan is onmiskenbaar. Betrouwbare software kan niet op basis van gevoel worden geleverd en noch nieuwe engineers, noch AI-agenten zullen in staat zijn om de intentie te reconstrueren. Dit betekent dat de levering onvoorspelbaar wordt en het bedrijf de prijs betaalt voor niet-afgestemde functies en gemiste deadlines.

Clarke denkt dat spec-gedreven ontwikkeling (en we zullen dit hierna SDD noemen) deze uitdaging oplost door de productintentie te coderen als machinaal leesbare context, inclusief API’s, datavormen, statusstromen, niet-functionele aspecten en acceptatietests. Een plan splitst het werk op in een taakgrafiek, waarna de code – of deze nu door mensen of door een model is geschreven – aan de orakels moet voldoen voordat deze kan worden uitgebracht. Dit zet ambiguïteit om in duidelijke beperkingen en stelt het systeem in staat om te evolueren. In wezen neemt het de eerste creatieve vonk en dwingt deze door een prisma van duidelijkheid.

“Dit is misschien wel het tegengif voor de chaos van vibe-coding, maar het is geen terugkeer naar de zware, watervalachtige documentatie van de jaren 90. SDD creëert een gestroomlijnd, rigoureus proces, waarbij gedetailleerde functionele vereisten, beperkingen en gewenst gedrag worden gedefinieerd voordat er ook maar één regel code wordt geschreven. Het is een natuurlijke evolutie van vibe-coding, waarbij het primaire artefact verschuift van prompts of documenten naar gestructureerde, machinaal leesbare intenties waar zowel mensen als agents over kunnen redeneren,” aldus Clarke.

De technische methodologie

SDD volgt over het algemeen een gestructureerde workflow, die weerspiegelt hoe goed presterende, menselijke teams werken (maar op een manier die ook is geoptimaliseerd voor AI-uitvoering):

1. Het begint met het definiëren van specificaties: belanghebbenden en senior engineers beginnen met het gezamenlijk opstellen van gedetailleerde vereisten – hoe een ‘happy path’ door het systeem eruitziet, foutstatussen, aanvaardbare time-outs, API-contracten, acceptatietests en vereiste beveiligingsbeperkingen.

2. Vervolgens ontleedt AI de specificaties: zodra de specificaties zijn gedefinieerd, splitst een AI-model deze op in een gedetailleerde takenbacklog, met expliciete afhankelijkheden. Taken die geschikt zijn voor parallel werk door teams van agents worden op dit punt ook gemarkeerd.

3. De incrementele build begint: Meerdere bijdragers (mens of agent) werken vervolgens parallel aan de opgesplitste taken. Laag voor laag (boilerplate, UI, backend-logica) groeit de software. Elke laag wordt incrementeel ontwikkeld, waarbij verschillende teamleden of agenten elk hun eigen ‘deel’ voor hun rekening nemen.

4. Testen: Unit-, eigenschappen-, integratie- en automatiseringstests worden uitgevoerd op voltooide PR’s om te garanderen dat het werk de kwaliteitscontroles doorstaat, geen regressie veroorzaakt en voldoet aan de acceptatiecriteria zoals vastgelegd in de specificatie. Cruciaal is dat SDD teams dwingt om vooraf kritisch na te denken over het probleem waarmee ze worden geconfronteerd. Het overbrugt de kloof tussen menselijke intentie en machine-uitvoering, en een goede specificatie dwingt je om het ‘waarom’ achter het ‘wat’ te begrijpen.

“Veel ontwikkelaars vrezen dat een dergelijke structuur creativiteit in de weg staat, maar dat is bij SDD niet het geval. SDD kanaliseert de creativiteit van vibe-coding in een workflow die daadwerkelijk schaalbaar is. Het stuwt bijdragers hoger in de waardeketen, waarbij de technische controle gericht blijft op de doelarchitectuur, overkoepelende patronen en de gezondheid van de bredere codebase. Ingenieurs besteden minder tijd aan discussies over de plaatsing van accolades of het repareren van gebroken afhankelijkheidsketens, en meer tijd aan het vormgeven van de architectuur en de gebruikerservaring,” verduidelijkte Clarke.

Belangrijk is echter dat SDD niet de wondermiddel is voor elk scenario. Het gedijt waar complexiteit en noodzaak samenkomen. Dit betekent dat het perfect is voor projecten waarbij je vanaf nul aan nieuwe applicaties begint, of wanneer je goed gedefinieerde, afzonderlijke functionaliteit aan een legacy-systeem wilt toevoegen.

De opkomst van een nieuwe ontwikkelaar

Dit alles betekent dat de traditionele rol van de ontwikkelaar verschuift van het schrijven van individuele regels code naar het orkestreren van het gehele ontwikkelingsproces. In wezen maakt dit de weg vrij voor een nieuwe ‘context engineer’.

Context engineers zijn geen ‘holbewoners’ die wachten tot er een Jira-ticket onder de deur door wordt geschoven, maar actieve deelnemers die samenwerken met productmanagers, ontwerpers en gebruikers om te achterhalen wat er precies gebouwd moet worden voordat ze daarmee beginnen. Ze leiden sessies voor het verzamelen van vereisten en leggen technische beperkingen uit aan niet-technische belanghebbenden, zonder zich te verschuilen achter jargon. Ze richten zich op flow in plaats van op functie, en beginnen altijd met na te gaan hoe nieuwe functies zowel in het grotere ecosysteem als in de beoogde architectuur van het systeem passen.

“De toekomst van coderen draait niet om vervanging door AI, maar om het leren sturen ervan. Als je niet precies kunt verwoorden wat je wilt, kan AI het niet bouwen. Het beheersen van SDD is de sleutel om de controle te behouden en een onmisbaar onderdeel van het moderne softwareteam te worden. Maar we moeten ook realistisch zijn – als je alleen snelle prototyping nodig hebt om een vaag idee snel te testen, is vibe-coding beter geschikt. Zodra het prototype echter is gevalideerd, is het tijd om het opnieuw op te bouwen met SDD: gedragingen uitwerken in contracten, het schema stabiliseren, acceptatietests schrijven en de implementatie opnieuw opbouwen op basis van die artefacten,” concludeerde Clarke van Nearform.

We zien deze evolutie in realtime. De plan-modus in moderne editors en andere AI-native benaderingen die door teams als Anthropic worden gebruikt, leveren sterke resultaten op omdat ze vertrouwen op context, niet op vibes.

Misschien is het tijd om onze dansschoenen te verwisselen, te stoppen met gissen en te beginnen met specificeren.

Lees ook: De onvermijdelijke schrikreflex tegen vibe coding