Vibe Coding vs Spec-Driven Development [Vergelijking]

De manier waarop apps worden gebouwd verandert

Voor AI-codeertools was code schrijven en reviewen het moeilijkste deel van softwareontwikkeling. Die drempel verdwijnt snel. Maar hier mist men iets: het moeilijke deel is niet verdwenen — het is alleen verschoven. Nu is het moeilijkste weten hoe je effectief kunt overbrengen wat je wilt bouwen aan een LLM. En de methode die dit het beste doet heet spec-driven development.

Om te begrijpen waarom spec-driven development belangrijk is, moet je eerst begrijpen waartegen het reageert: vibe coding.

Wat is vibe coding?

Vibe coding is wat de meeste mensen denken als ze AI-ondersteunde ontwikkeling visualiseren. Je opent je AI-codeeragent — of het nu Cursor, GitHub Copilot, Claude of een browsergebaseerde tool is — schrijft een prompt die beschrijft wat je wilt, en het model begint code te genereren op basis van wat het denkt dat je bedoelt.

De typische flow ziet er zo uit: je schrijft een initiële prompt, het model genereert boilerplate, je ziet dat het niet helemaal klopt, bewerkt de prompt en laat het model opnieuw proberen. Dit gaat heen en weer totdat je ergens in de buurt komt van wat je wilde.

En eerlijk? Voor veel taken werkt dit prima. Vibe coding is fantastisch voor:

• Snel een idee prototypen om te testen of het de moeite waard is
• Boilerplate genereren die je anders met de hand zou schrijven
• Verkennen wat een library of API kan doen
• Kleine, op zichzelf staande scripts en utilities

Vibe coding: de flow

De loop is eenvoudig: schrijf een prompt, ontvang AI-gegenereerde code, beslis of je tevreden bent, bewerk de prompt als dat niet zo is, herhaal. Het model neemt alle implementatiebeslissingen op basis van jouw beschrijving in natuurlijke taal.

Het probleem met vibe coding

Dit is het fundamentele probleem: hoe besloot het model welke architecturale keuzes het maakte? Je kunt dezelfde prompt honderd keer uitvoeren en honderd verschillende implementaties krijgen. Elke keer neemt het model een stille beslissing waar jij nooit over geraadpleegd bent.

Die onvoorspelbaarheid frustreert ontwikkelaars die aan iets meer dan een eenvoudig prototype werken. En er is een dieper probleem: vibe coding slaat de traditionele softwareontwikkelingscyclus volledig over.

• Geen requirementsfase: het model raadt wat je nodig hebt in plaats van expliciet verteld te worden
• Geen ontwerpfase: implementatiebeslissingen worden impliciet genomen, niet bewust
• Geen traceerbaarheid: als iets kapot gaat, is er geen spec om te raadplegen
• Hoge heen-en-weer kosten: aannames van het model corrigeren na het schrijven van code is trager dan ze vooraf definiëren

De traditionele SDLC

Voor AI volgde professionele softwareontwikkeling de software development lifecycle (SDLC). De fasen zijn consistent:

• Planning en requirements: wat moet het systeem doen? Documenteer als PRD
• Ontwerp: hoe wordt het gebouwd? Architectuur, datamodellen, interfaces
• Implementatie: schrijf de code tegen het ontwerp
• Testen en QA: verifieer dat de code overeenkomt met de requirements
• Deployment: van dev naar staging naar productie
• Onderhoud: actief houden, bugs fixen, features toevoegen

Vibe coding negeert dit grotendeels. Spec-driven development brengt deze disciplines terug — maar met het LLM dat het implementatiewerk afhandelt.

Wat is spec-driven development?

Spec-driven development (SDD) begint niet met een prompt voor code, maar met een prompt voor een specificatie. Je vertelt het model niet wat het moet bouwen — je vertelt het wat het systeem moet doen: zijn gedrag, zijn beperkingen, zijn requirements. Die specificatie wordt dan een contract.

Het contract stuurt alles downstream: requirementsdocumenten, ontwerpdocumenten, implementatieplannen, testcases en documentatie. Het LLM doet nog steeds het zware werk — code genereren, tests uitvoeren, docs schrijven — maar het werkt vanuit een overeengekomen, expliciete basis in plaats van te raden van een enkele prompt.

Het belangrijkste verschil: niets wordt geïmplementeerd totdat de spec goedgekeurd is. Op elk beslissingspunt review, keur je goed of bewerk je voordat de volgende fase begint.

Spec coding: de flow

De flow heeft expliciete goedkeuringspoorten. Je definieert een spec, het model genereert requirements. Als je tevreden bent met de requirements, genereert het een ontwerpdocument met implementatie to-dos. Als je tevreden bent met het ontwerp, implementeert het model. Op elk punt kun je bewerken en teruglopende — maar nu bewerk je een gestructureerd document, niet opnieuw een prompt.

Spec coding vs traditioneel vs TDD

Het helpt om spec-driven development in de context van andere aanpakken te plaatsen:

Spec-driven development is in wezen test-driven development en behavior-driven development op steroïden. Je begint met wat het systeem moet doen, maakt dat expliciet en goedgekeurd, en laat dan het model code schrijven die eraan voldoet.

Een praktisch voorbeeld: gebruikersauthenticatie

Beschouw het bouwen van een gebruikersauthenticatiefunctie. Zo gaat elke aanpak ermee om:

Vibe coding aanpak: je prompt het model met "voeg een /login pagina toe voor gebruikers om te authenticeren." Het model kiest een library, beslist over session vs JWT, kiest een UI-framework en genereert iets. Het kan prima zijn. Het kan drie rondes correctie nodig hebben.

Spec-driven aanpak: voordat er code wordt geschreven, definieer je de spec:

Feature: Gebruikersauthenticatie

Endpoint: POST /login
Accepteert: { user: string, pass: string }
Succes: 200 OK + sessietoken
Fout (ontbrekende gebruikersnaam): 400 Bad Request
Fout (verkeerde credentials): 401 Unauthorized

Testcases:
- Geldige credentials → 200
- Ontbrekende gebruikersnaam → 400
- Verkeerd wachtwoord → 401

Je reviewt dit. Als het overeenkomt met wat je wilt, keur je goed en genereert het model een ontwerpdocument. Alleen daarna begint de implementatie — zonder ambiguïteit over wat het model moet bouwen.

Wanneer gebruik je welke aanpak?

De twee aanpakken sluiten elkaar niet uit. Gebruik vibe coding om te verkennen en spec-driven development om te shippen. Begin snel met vibe coding om een idee te valideren, formaliseer dan met een spec voordat de productie-implementatie begint.

Bekijk de volledige uitleg

We hebben vibe coding vs spec-driven development volledig behandeld op ons YouTube-kanaal. Bekijk de video hieronder voor een visuele walkthrough van beide workflows, de vergelijkingsdiagrammen en een echt voorbeeld van het bouwen van een login endpoint op beide manieren:

Conclusie

Vibe coding heeft veranderd wat mogelijk is voor bouwers die kunnen beschrijven wat ze willen. Spec-driven development verandert wat mogelijk is voor bouwers die iets betrouwbaars willen shippen. De eerste is geweldig voor verkenning; de tweede is wat productiesoftware daadwerkelijk nodig heeft.

De belangrijkste vaardigheid in AI-ondersteunde ontwikkeling in 2026 is niet het schrijven van prompts — het is weten hoe je je intentie zo duidelijk kunt structureren dat een LLM het kan implementeren zonder te raden. Spec-driven development is die vaardigheid, geformaliseerd in een workflow.

Als je nog steeds alles vibe codet, laat je veel betrouwbaarheid en onderhoudbaarheid op tafel liggen.

Bronnen