Spec-Driven Development versus Vibe Coding: Waterfall?

Specificaties als enige waarheid, of traad ceremonieel?

Inhoud

Spec-gedreven ontwikkeling kwam in 2026 binnen als het serieuze antwoord van ontwikkelaars op de afwijking van ‘vibe coding’.

Het argument is eenvoudig: AI-agenten produceren betere, consistentere output wanneer ze implementeren op basis van een beoordeelde specificatie in plaats van een ad-hoc prompt. In theorie moeilijk te weerleggen.

In de praktijk noemde Hacker News het “Waterfall Strikes Back”.

Beide partijen hebben een punt.

Spec-gedreven ontwikkeling versus Vibe Coding

Het geval voor SDD in een Vibe-Coding-wereld

Vibe coding – de praktijk van het schrijven van een losse prompt en itereren op wat de AI-agent produceert – werkt opmerkelijk goed voor klein, exploratief en wegwerpwerk. In het eerste halfjaar van 2025 was dit het dominante AI-codingpatroon. Ontwikkelaars leverden scripts, prototypes en simpele tools sneller dan ooit.

Toen groeiden de projecten. Multi-bestandsfeatures begonnen te drijven. Grenzen die in sessie één werden vastgesteld, werden vergeten in sessie drie. Security-aannames werden gedroppt. Architectuurkeuzen verschoven midden in een feature omdat de agent geen duurzame geheugen van intentie had.

Spec-gedreven ontwikkeling (SDD) verscheen als het gedisciplineerde antwoord. De kernclaim: maak de specificatie het centrale artefact, niet de prompt. Schrijf eerst de vereisten, een ontwerp en een takenplan. Laat de agent implementeren tegen die artefacten, slice per slice. Houd de specificatie geverstond en bijgewerkt.

AI-codingtools – GitHub Spec Kit, Kiro, BMAD en een groeiend aantal aangepaste workflows voor Claude Code – zijn allemaal implementaties van dit idee. De tools zijn echt. De interesse is echt. De weerstand is ook echt.

Waar Vibe Coding goed in is

Voordat je vibe coding afdoet, is het de moeite waard om precies te zijn over wat het goed doet.

Exploratieve prototypes. Als je niet zeker weet wat je wilt bouwen, is het snelste pad iets ruws bouwen en daarop reageren. SDD vereist dat je weet wat je moet specificeren. Als je het nog niet weet, zijn specificaties prematuur.

UI-experimenten. Visuele lay-out en interactiegevoel zijn moeilijk vooraf te specificeren. Vibe coding laat je opties snel zien, de meeste verwerpen en convergeren naar iets dat er echt goed uit ziet. Een vereistendocument helpt je hier niet.

Wegwerpautomatisering. Eenmalige scripts, data-extractiejobs, migratiehelpers – deze hebben zelden een document nodig. De kosten van het iets fout krijgen zijn laag. De kosten van een traag, ceremonieel proces zijn daarentegen reëel.

Snelle feedback. Wanneer je snel iets wilt leren – werkt deze API zoals ik denk dat het werkt? – verkort vibe coding de leercyclus tot minuten. SDD zou dat vertragen zonder voordeel.

De fout is om de succespatronen uit deze contexten te nemen en toe te passen op productiefeatures met echte beperkingen, echte gebruikers en echte consequenties bij het fout krijgen.

Waar Vibe Coding faalt

Vibe coding degradeert voorspelbaar naarmate de scope en inzet toenemen.

Multi-bestandsveranderingen. Zodra een feature vijf of meer bestanden raakt, begint de contextvenster van de agent de invarianten te verliezen. Zonder een documentatie moet elke prompt de context opnieuw vaststellen die in een eerdere sessie werd vastgesteld en vergeten.

Architectuurdrift. Zonder expliciete non-goals implementeren agenten dingen. De agent voegt een cachinglaag toe omdat het redelijk lijkt. Drie sessies later is de cachingaanname ingebakken in het datamodel en is het verwijderen ervan duur.

Vergeten beperkingen. “Alleen geauthenticeerde gebruikers kunnen dit triggeren” is een zin in een vereistendocument. In een vibe-codingsessie is het iets wat je eenmaal noemde in sessie één en de agent onthoudt het niet in sessie vier wanneer het het nieuwe eindpunt schrijft.

Verborgen security-aannames. Autorisatieregels, inputvalidatiegrenzen, omgaan met geheimen – dit zijn precies de soort impliciete vereisten die worden gemist wanneer de agent optimaliseert voor plausibele werkende code in plaats van correcte, beperkte code.

Teamoverdracht. Als je het bouwt via iteratief prompten, is het artefact dat vastlegt wat besloten is en waarom… de git-log. Succes met dat.

Wat Spec-gedreven ontwikkeling verandert

SDD claimt niet om iteratie te elimineren. De goede versies van SDD zijn expliciet iteratief. Wat ze verandert, is waar iteratie plaatsvindt. Voor de volledige definitie – inclusief hoe SDD verschilt van TDD, BDD en formele methoden – zie Wat is Spec-gedreven ontwikkeling?

In plaats van te itereren op code en intentie af te leiden uit diffs, itereren je op de spec en implementeer je daarna. De spec wordt het artefact dat vastlegt wat besloten is, waarom, en wat buiten scope valt – een vergelijkbare functie als Architectuurbeslisregistraties maar gericht op feature-intentie in plaats van systeemniveau-keuzes. De code implementeert die intentie.

Een typische SDD-workflow doorloopt vijf fasen:

Specificeren. Probleemstelling, gebruikers, doelen, non-goals, acceptatiecriteria, open vragen.

Plannen. Architectuurkeuzes, betrokken modules, datamodel, API-contracten, securityzorgen, teststrategie.

Takenopsplitsing. Kleine implementatieslices met expliciete validatiecriteria en menselijke reviewcontroles.

Implementeren. Eén taak op een tijd, met contextreset tussen taken, het toepassen van beperkingen van de spec, en het bijwerken van het plan wanneer de realiteit verschilt van het ontwerp.

Valideren. Tests, lint, typechecks, acceptatiecriteria, spec-naar-code diff.

De agent participeert in de meeste fasen – het opstellen van de spec, het genereren van het ontwerp, het voorstellen van taken – maar mensen beoordelen de artefacten voordat de implementatie begint. Die reviewstap is het centrale verschil tussen SDD en vibe coding.

Waarom ontwikkelaars het Waterfall noemen

De waterfall-kritiek is niet onterecht. Het is alleen gericht op slechte SDD, niet op SDD zelf.

De specifieke faalmode is langdurig voorafplannen. De kenmerkende eigenschap van Waterfall is een feedbackloop die uitrekt tot weken of maanden: vereistefase, ontwerpfase, bouwfase, testfase, release. Feedback komt laat. Op het moment dat je ontdekt dat de ontwerpaanname fout was, heb je er al weken op gebouwd.

Wanneer een ontwikkelaar Spec Kit gebruikt en een 200-regelige takenlijst genereert voordat er een enkele regel code wordt geschreven, en vervolgens twee dagen besteedt aan het polijsten van het vereistendocument voordat de agent iets aanraakt, is dat waterfall. Het is waterfall met markdown in plaats van UML, maar de faalmode is identiek.

Een HN-commentator beschreef het gebruik van Spec Kit voor een klein CLI-gereedschap en vond het “te traag, te veel tweaken voordat er code te zien is”. Dat is de slechte versie. Die gebruiker had gelijk om het voor die taak te verwerpen.

De nuttige kritiek is niet “specs zijn slecht”. Het is “langdurig voorafplannen voordat feedback is slecht”. Dat zijn verschillende claims.

Het nuttige midden

Goede SDD vermijdt de waterfall-val door de spec klein te houden en vroeg te beginnen met implementatie.

Kleine specs. Een vereistendocument voor een enkele feature zou op één scherm moeten passen. Als de spec tien pagina’s is, is het ofwel een platformontwerp of moet het worden opgesplitst in kleinere features. Te grote specs kosten te lang om te reviewen en verouderen snel.

Korte taskslices. Elke taak zou in een enkele agentsessie implementeerbaar moeten zijn, reviewbaar als een kleine diff, en testbaar in isolatie. Als taken te groot zijn, rekkt de implementatieloop zich uit en wordt de spec-naar-code-mapping moeilijk te verifiëren.

Vroege implementatie. Specificeer de eerste taak, implementeer het, valideer het, en ga dan naar de volgende taak. Specificeer niet alles voordat je iets implementeert. De eerste implementatie zal dingen onthullen die je spec fout had. Werk de spec bij voordat je doorgaat.

Levende spec. Wanneer de realiteit verschilt van het ontwerp – en dat zal – werk de spec bij, niet alleen de code. De spec is alleen nuttig als het weerspiegelt wat daadwerkelijk is gebouwd.

Tests als uitvoerbare feedback. Elk acceptatiecriterium zou minstens één test moeten hebben. De testsuite is de machine-leesbare versie van de spec. Als de spec zegt “alleen geauthenticeerde gebruikers kunnen dit triggeren”, moet er een test zijn die verifieert dat niet-geauthenticeerde verzoeken worden afgewezen.

Deze hybride – kleine specs, korte taken, vroege implementatie, levende documenten – is wat daadwerkelijk werkt. Het is geen vibe coding en het is geen waterfall. Het is gecontroleerde iteratie met duurzame artefacten.

Wanneer SDD beter is dan Vibe Coding

Gebruik SDD – zelfs lichtgewicht SDD – wanneer de kosten van het fout krijgen reëel zijn.

Risicovolle businesslogica. Facturatie, machtigingen, datamigraties, idempotentie – elke logica waarbij onjuist gedrag duur of moeilijk omkeerbaar is. Vibe coding laat deze soort vereisten impliciet. SDD maakt ze expliciet en reviewbaar voordat implementatie.

Productie API-veranderingen. Elke verandering in een openbaar of intern API-contract moet een documentatie hebben. Het documentatie is wat je reviewt voordat de agent code schrijft die callers breekt.

Multi-agent workflows. Wanneer meerdere agenten verschillende delen van een feature implementeren, is de spec de gedeelde bron van waarheid. Zonder dit optimaliseert elke agent lokaal en passen de stukken mogelijk niet samen.

Teamoverdracht. Als een andere ontwikkelaar of agent dit werk voortzet, is de spec het overdrachtsartefact. Een git-log en een README zijn niet genoeg.

Significante refactors. Refactors die kernabstracties raken, hebben een expliciete verklaring nodig van wat hetzelfde moet blijven (gedrag) en wat mag veranderen (structuur). Zonder dat kan de agent contracten breken die je dacht behouden te zijn.

Wanneer Vibe Coding nog steeds beter is

SDD is overhead. Soms is overhead niet de moeite waard.

Snelle scripts. Een script van 50 regels om bestanden te hernoemen of JSON te transformeren heeft geen vereistendocument nodig. Schrijf de prompt, controleer de output, release het.

Experimenten. Als je leert of een aanpak haalbaar is – een API verkennen, een library testen, een hypothese valideren – heb je snelheid nodig, geen structuur. Experimenteer eerst, specificeer als het experiment slaagt.

UI-schetsen. Interactiedesign profiteert van zien in plaats van specificeren. Bouw snel meerdere ruwe variaties, reageer op wat je ziet, en specificeer alleen wat je daadwerkelijk gaat releaseën.

Afvalautomatisering. Eenmalige scripts, data-imports, migratiehelpers – de kosten van een iets fout resultaat zijn meestal laag, en het artefact wordt toch na gebruik verwijderd.

Solo-prototypes. Als jij de enige bent die deze code ooit zal zien en het doel leren is in plaats van productie, is vibe coding sneller en zijn de nadelen begrensd.

Een eenvoudig besliskader

De praktische vraag is niet “SDD of vibe coding?” Het is “hoeveel spec heb ik nodig voor deze specifieke taak?”

Gebruik vibe coding wanneer:

  • De taak minder dan een dag duurt
  • Je verkent of leert
  • Het artefact wegwerp is of lage inzet heeft
  • Jij de enige bent die hieraan raakt
  • Feedbacksnelheid belangrijker is dan correctheid

Gebruik lichtgewicht SDD wanneer:

  • De taak twee of meer dagen duurt
  • Meerdere bestanden worden beïnvloed
  • Er expliciete security- of correctheidvereisten zijn
  • Een andere persoon of agent het werk voortzet
  • Je tests moet schrijven die overeenkomen met vereisten

Gebruik volledige SDD wanneer:

  • De feature een openbaar interface of datacontract raakt
  • Meerdere agenten of teamleden betrokken zijn
  • De organisatie een ontwerpreview vereist voordat implementatie
  • Compliance of audittrails vereist zijn

De meest voorkomende fout is het toepassen van volledige SDD op taken die alleen lichtgewicht SDD nodig hebben, en het toepassen van geen enkele spec op taken die ten minste een lichtgewicht een nodig hebben.

Slechte SDD is waterfall met markdown. Goede SDD is gecontroleerde iteratie met duurzame artefacten. Vibe coding is het juiste gereedschap voor de juiste taken – en het verkeerde gereedschap voor de verkeerde. Het kennen van het verschil is de vaardigheid.

Abonneren

Ontvang nieuwe berichten over systemen, infrastructuur en AI-engineering.