Hetzelfde model, een ander startpunt
Vibe coding en spec-driven development draaien op dezelfde tools. Cursor, Claude Code, Copilot, het model eronder is identiek. Het verschil zit in wat je meegeeft voordat er iets geschreven wordt.
Bij vibe coding begin je met een prompt en ga je door tot wat er op het scherm staat goed voelt. Bij spec-driven development begin je met opschrijven wat de software moet doen, en genereert de AI code uit dat document. De spec is wat je onderhoudt. De code volgt.
Dat klinkt als procesoverhead. In de praktijk verandert het precies het ene ding dat bepaalt of AI-code iets waard is: of je een meetlat hebt om hem tegen af te zetten. Over de houding erachter schreven we eerder in vibe coding vs AI-assisted coding. Dit artikel gaat over de methode.
Het verschil in één oogopslag
| Vibe coding | Spec-driven development | |
|---|---|---|
| Waar je begint | Een prompt, en daarna nog een prompt. | Een geschreven spec: wat het doet, voor wie, onder welke regels. |
| Wat je onderhoudt | De chatgeschiedenis, tot je die kwijt bent. | De spec. Code wordt daaruit opnieuw gegenereerd. |
| Hoe je het resultaat beoordeelt | Het draait en het ziet er goed uit. | Het komt overeen met de spec, en de gaten zijn zichtbaar. |
| Wat er gebeurt bij een wijziging | Opnieuw vragen en hopen dat de rest heel blijft. | Spec aanpassen, opnieuw genereren, de diff reviewen. |
| Waarvoor geschikt | Prototypes, eenmalige scripts, alles wat weg mag. | Software met gebruikers, data en een tweede jaar. |
Wat er in een spec staat
Een spec in deze zin is een werkdocument. Niemand vraagt om een requirements-map van vijftig pagina’s uit 2008. Teams die dit goed doen houden meestal drie lagen aan, en de AI leest ze alle drie.
Wat het moet doen
Het gedrag in gewone taal. Wie gebruikt dit, wat kan diegene, wat gebeurt er aan de randen. Zo geschreven dat iemand buiten het team kan vaststellen of het gebouwde klopt.
De regels waaraan het moet voldoen
Je stack, je conventies, de security-grenzen, de dingen die verboden zijn. Dit is de laag die voorkomt dat het model elke sessie zijn eigen architectuur verzint.
Het plan ernaartoe
Het werk in stappen die klein genoeg zijn om los te reviewen. Een stap die dertig bestanden raakt is een stap die niemand nakijkt.
Er is inmiddels gereedschap voor. Spec Kit van GitHub en Kiro van Amazon dwingen je door spec, plan en taken heen voordat er iets gegenereerd wordt, en dezelfde discipline werkt met een gewoon markdown-bestand in de repo dat je AI-editor elke sessie inleest.
De spec is eigenlijk een reviewinstrument
Dit is het deel dat telt voor alles wat naar productie gaat. AI-code reviewen zonder spec betekent dat je de bedoeling uit de code zelf moet reconstrueren. Je leest een functie, je vindt hem redelijk, en je hebt geen manier om vast te stellen of hij doet wat er gevraagd was of iets ernaast wat het model makkelijker vond.
Zonder spec review je de code niet. Je raadt wat het had moeten doen, op basis van het enige bewijs dat er is: de code die je probeert te controleren.
Met een spec wordt review een vergelijking. Klopt dit met wat we hebben opgeschreven, ja of nee. Die vraag kan een tweede persoon beantwoorden, een test, en steeds vaker een tweede model. De vage variant van die vraag kan dat niet.
Daarom bouwen we ons eigen proces rond een geschreven briefing en een mens die elke regel ziet voordat het live gaat. Het model doet het typen. Het oordeel over of het resultaat klopt blijft bij een persoon, en die persoon heeft iets nodig om tegen te oordelen.
Vibe coding heeft nog steeds zijn plek
Spec-driven development is niet gratis. De spec schrijven kost echte tijd, en bij een wegwerpproject levert die tijd je niets op.
Je verkent, je bouwt nog niet
Zolang je nog niet weet wat het moet worden, is een spec een opgeschreven gok. Vibe je eerst naar een antwoord en schrijf daarna de spec voor de versie die overeind blijft.
De schade blijft klein
Een script dat één keer op je eigen machine draait heeft geen gebruikers en geen tweede jaar. Lelijke code die werkt is dan de juiste uitkomst.
Je bent drie prompts van klaar
Sommige taken zijn gewoon klein. Een spec schrijven voor een wijziging van een kwartier is ceremonie, en dat voelt iedereen.
Het gaat mis als je in verkenmodus begint en er nooit meer uit komt. Het prototype krijgt een gebruiker, dan een betalende gebruiker, dan een database met echte namen erin, en de spec die het reviewbaar had gemaakt is er nooit gekomen. Dat is dezelfde val die we beschreven in de laatste 20% van een vibe-coded project, nu vanuit een andere hoek.
Vibe engineering is hetzelfde idee onder een andere naam
Je komt dit ook tegen als vibe engineering, een term die Simon Willison introduceerde voor de gedisciplineerde kant van werken met AI: je leunt nog steeds zwaar op modellen, en je neemt het hele engineering-apparaat mee. Specs, tests, review, versiebeheer, CI, en het vermogen om te zeggen wat de software hoort te doen.
Behandel vibe engineering en spec-driven development als hetzelfde instinct met een ander accent. Spec-driven development benoemt het document waar je mee begint. Vibe engineering benoemt de praktijk eromheen. Beide bestaan omdat pure vibe coding vastloopt zodra iets onderhouden moet worden.
Prompt engineering is iets heel anders
Prompt engineering wordt er vaak bijgehaald, en dat zit op een andere as. Prompt engineering gaat over één instructie goed formuleren: context, formaat, voorbeelden, randvoorwaarden. Het maakt elke losse uitwisseling beter.
Spec-driven development gaat over wat blijft bestaan tússen die uitwisselingen. Je spec overleeft de sessie, het contextvenster, de tool waar je vorige maand op overstapte en de collega die het volgend kwartaal oppakt. Een goed geformuleerde prompt geeft je vandaag een goed antwoord. Een spec geeft je een codebase waar je over een jaar nog over kunt nadenken.
Drie signalen dat je vibe coding ontgroeid bent
Je kunt niet zeggen wat het moet doen
Iemand vraagt of gedrag een bug is of bedoeld, en het eerlijke antwoord is dat niemand het heeft opgeschreven. Dat is het moment waarop een spec zichzelf terugverdient.
Wijzigingen slopen andere dingen
Elke fix gooit ergens anders iets om, omdat het model geen beeld van het geheel heeft en jij ook niet. Een spec plus kleine stappen is hoe je dat beeld terugkrijgt.
Er is echte data
Echte gebruikers, echte gegevens, echt geld. Vanaf hier is code die tegen niets gereviewd kan worden een risico in plaats van een shortcut.
Conclusie: de spec maakt AI-code reviewbaar
Vibe coding en spec-driven development zijn twee uiteinden van één vraag: hoeveel van je bedoeling bestaat er buiten je eigen hoofd. Vibecoden houdt het in de chat en in je geheugen. Een spec zet het in de repo, waar een collega, een test en een model het allemaal kunnen lezen.
Vibe coding = snelle antwoorden
Perfect om te ontdekken of een idee iets waard is. Wat je overhoudt is een prototype, en daar is het precies goed voor.
Spec-driven development = iets om te onderhouden
Trager op dag één en veel goedkoper in maand zes, omdat alles wat de AI produceerde te toetsen is aan iets dat je met opzet hebt opgeschreven.
De meeste teams hebben allebei nodig. De kunst is weten wat je op dit moment aan het doen bent, en eerlijk zijn over wanneer het project van het een naar het ander is verschoven.
Wat is spec-driven development?
Wat is het verschil tussen vibe coding en spec-driven development?
Is spec-driven development beter dan vibe coding?
Is vibe engineering hetzelfde als spec-driven development?
Hoe verschilt spec-driven development van prompt engineering?
Wanneer moet ik overstappen van vibe coding naar een spec?
Op vibes gebouwd en moet het nu overeind blijven?
We lezen wat er daadwerkelijk staat, schrijven op wat het hoort te doen, en vertellen je wat er nodig is om van prototype naar productie te komen.
