Software niet twee keer schrijven: specificatiegestuurde ontwikkeling en het einde van de herbouw
Waarom software altijd twee keer is geschreven, eerst in specificaties en dan nog eens als code, en waarom die tweede keer eindelijk verdwijnt.
In de softwareontwikkeling moeten we, wanneer het goed gebeurt, software twee keer schrijven: eerst in gedetailleerde specificaties die precies uitleggen wat de software moet doen, en dan nog eens als code die die specificaties tot leven brengt. Maar hier is een harde waarheid: het gebeurt zelden goed de eerste keer.
Het proces valt vaak uit elkaar omdat volledige specificaties opstellen tijd kost en teams zelden alle nodige details vooraf vastleggen. Dat leidt tot gaten, aannames en dure herstelwerkzaamheden. Het gevolg is dat softwareprojecten vaak over de begroting gaan, deadlines missen en iedereen gefrustreerd achterlaten.
De verborgen kosten van software twee keer schrijven
Om te begrijpen waarom twee keer schrijven nodig is maar zelden goed gebeurt, splitsen we de twee fasen.
1. De eerste keer: specificaties in natuurlijke taal
De eerste keer dat software wordt geschreven, schrijven we helemaal geen code. Er ontstaan eisen, gebruikersverhalen en ontwerpdocumenten, opgesteld in natuurlijke taal. Hier beschrijven teams hoe de software moet werken, wat gebruikers kunnen doen en hoe de ervaring moet zijn.
Maar hier is het probleem: geen team heeft ooit de luxe om alle details te schrijven. Wie zich met product bezighoudt moet vaak haasten om strakke tijdlijnen te halen, en in sommige projecten is er zelfs geen professionele productrol. De grote lijnen worden geschetst, maar belangrijke functies en interacties glippen weg. Zoals Steve Jobs zei: «grote producten ontstaan uit 5.000 kleine beslissingen», maar in de meeste projecten nemen we die beslissingen niet vooraf. Ze blijven over voor latere uitleg door de ontwikkeling, wat naar de tweede stap leidt.
2. De tweede keer: specificaties naar code vertalen
Zodra de specificaties zijn overgedragen, is de ontwikkeling verantwoordelijk om die beschrijvingen in werkende code om te zetten. Maar wanneer de eerste keer onvolledig is, moet zij haar voorstellingsvermogen gebruiken om de gaten te vullen. Er worden aannames gedaan, en ook al beheersen mensen in de ontwikkeling de techniek goed, ze hebben mogelijk niet het volledige beeld van de productvisie.
Hier komen de problemen naar boven:
- Ontbrekende details geven wrijving: wanneer productteams een belangrijke functie of situatie niet vastleggen, moet de ontwikkeling gokken of improviseren. Dat levert vaak functionaliteit op die niet aan de verwachtingen voldoet.
- Aannames leiden tot herstelwerk: wanneer de ontwikkeling de gaten vult, kan zij functies bouwen op manieren die niet bij de productvisie passen, wat later in het project zwaar herstelwerk oplevert.
- Vingerwijzen wordt onvermijdelijk: wanneer deadlines schuiven en begrotingen springen, schuiven teams de schuld heen en weer. Productteams verwijten de ontwikkeling dat ze «het niet snapte», terwijl de ontwikkeling naar de onduidelijke specificaties wijst.
Het gevolg is een lawine van problemen die tot gemiste tijdlijnen, overschreden begrotingen en onbevredigende uitkomsten leidt. Het CHAOS-onderzoek van de Standish Group volgt al jaren dat de meeste softwareprojecten over de begroting gaan en leverdata missen. Een studie van McKinsey met de Universiteit van Oxford vond dat grote IT-projecten gemiddeld 45 procent over de begroting en 7 procent over de tijd gaan en daarbij 56 procent minder waarde leveren dan voorspeld, en dat 17 procent van de grote IT-projecten zo slecht loopt dat het het bestaan van het bedrijf bedreigt.
Er is duidelijk iets stuk in dit proces.
De praktijk heeft nu een naam
De sector is het over een term eens geworden terwijl de meeste mensen over prompts discussieerden: specificatiegestuurde ontwikkeling. Schrijf eerst de eisen, de randvoorwaarden en de succescriteria. Behandel die specificatie als de bron van waarheid. Laat de agent daartegen bouwen.
GitHub bracht Spec Kit uit. AWS bracht Kiro uit. BMAD-METHOD, OpenSpec en Tessl deden er elk een poging toe. Martin Fowler heeft erover geschreven. Het samenvallen is geen toeval: het is wat gebeurt wanneer een hele categorie op hetzelfde moment dezelfde manier van falen ontdekt.
En die manier van falen is de manier die hierboven is beschreven. Hulpmiddelen die met de prompt beginnen, slaan de eerste keer volledig over. Ze gaan direct naar de tweede en gokken bij elke beslissing die de specificatie nooit heeft genomen. Wat prima is voor een demonstratie en rampzalig voor een product.
Specificatiegestuurde ontwikkeling schaft de eerste keer niet af. Ze maakt die de enige keer die menselijk oordeel vraagt.
De nieuwe eerste keer: specificaties die je werkelijk kunt afmaken
Hier is wat verandert. De reden dat niemand volledige specificaties schreef, was nooit onwil: het was dat het werk te langzaam was om zich te verantwoorden. Weken verkennen voor een document dat verouderde bij het eerste contact met de eerste werkronde. Dus schreven teams de grote lijnen en lieten de 5.000 kleine beslissingen later ontdekken, één uitleg tegelijk.
Wanneer een specificatie opstellen uren duurt in plaats van maanden, keert de rekensom om. Je kunt je veroorloven volledig te zijn. Functionele eisen, visueel ontwerp, gegevensmodel, randgevallen, vastgelegd voordat iemand een editor opent, en goedkoop genoeg om te herzien wanneer je iets leert.
Dat laatste telt. Een specificatie die niet goedkoop te herzien is, wordt een leugen op het moment dat de werkelijkheid aankomt. Het is hetzelfde instinct als achter API-first bouwen: de dragende beslissingen goed nemen voordat iemand een scherm schrijft, en de rest volgt.
De nieuwe tweede keer: code opleveren, geen vertaling
Zodra de specificatie volledig is, houdt de tweede keer op een vertaalprobleem te zijn. Het wordt een opleverprobleem. Standaardtalen: JavaScript, TypeScript, Python. Standaardframeworks: React, Next.js. Echte code, in de vormen die de ontwikkeling al kent, afgeleid uit een document dat elke beslissing al heeft genomen.
Het verschil is niet dat de ontwikkeling sneller werkt. Het is dat ze ophoudt het deel te doen dat nooit techniek was: het werktuiglijk herhalen van beslissingen die iemand anders al heeft genomen.
Wat verderop verandert
Drie dingen veranderen tegelijk:
- De eerste keer wordt afgemaakt: wanneer specificatiewerk uren kost in plaats van maanden, kunnen teams zich veroorloven de kleine beslissingen vooraf te nemen in plaats van ze in de revisie te ontdekken.
- Niemand vult de gaten: code die uit een volledige specificatie wordt opgeleverd, vraagt van niemand te gokken wat het productteam bedoelde. Gokken was altijd de bron van de gebreken.
- Herstelwerk telt niet meer op: bedoeling en uitvoering beginnen op elkaar afgestemd. Wat vroeger een herbouw was, wordt een wijziging in de specificatie.
De toekomst van software schrijven: natuurlijke taal
Zolang mensen software uitbrengen, vroeg het werk om die twee keer te schrijven: eerst in natuurlijke taal, dan nog eens als code. Die tweede keer was nooit het waardevolle deel. Het was de tol die we betaalden omdat er geen andere weg was.
Het is de zet waar de volgende generatie AI-appbouwers zich rond organiseert: helderheid vóór code. De toepassing als blueprint beschrijven, de architectuur goed krijgen, de code daartegen laten opleveren. Geen sluiproute om het bepalingswerk heen, maar een reden om het eindelijk goed te doen.
Er is nu een andere weg. Software zou altijd één keer moeten worden geschreven.
Verwante lectuur
De volledige gids bij de praktijk: specificatiegestuurde ontwikkeling. Waarom de generatie die met de prompt begon deze stap oversloeg, staat in vibe coding heeft zijn belofte gebroken, en wat de plaats ervan inneemt in wat komt na vibe coding.
Veelgestelde vragen
Wat is specificatiegestuurde ontwikkeling? Specificatiegestuurde ontwikkeling betekent de eisen, randvoorwaarden en succescriteria schrijven voordat er code wordt opgeleverd, en die specificatie behandelen als de bron van waarheid waartegen de AI-agent bouwt. Ze ontstond in 2025 als direct antwoord op manieren van werken die met de prompt beginnen en de bepalingsstap volledig overslaan.
Waarin verschilt specificatiegestuurde ontwikkeling van een klassiek eisendocument? Het document is hetzelfde idee; de economie niet. Klassieke specificaties waren duur genoeg dat teams de grote lijnen schreven en de rest in de coderevisie ontdekten. Wanneer een specificatie uren kost in plaats van maanden en goedkoop te herzien is, wordt het lonend haar af te maken, en lonend haar bij te houden.
Welke hulpmiddelen ondersteunen specificatiegestuurde ontwikkeling? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec en Tessl zijn de uitvoeringen met een naam, en Cursor ondersteunt een lichtere versie via regelbestanden. Ze verschillen vooral in hoe strak de specificatie aan de code vastzit: of ze de generatie één keer aandrijft, naast de code meegroeit of het enige artefact is dat je aanpast.
Vertraagt specificatiegestuurde ontwikkeling teams? Ze verplaatst het werk, ze voegt er niets aan toe. De beslissingen die een specificatie vastlegt, worden toch door iemand genomen: of bewust vooraf, of stilzwijgend doordat de ontwikkeling of een model later gokt. De tweede weg is de bron van het herstelwerk.
Wat gebeurt er met de ontwikkeling als code uit specificaties wordt opgeleverd? Het werktuiglijk herhalen van de beslissingen van iemand anders verdwijnt. Het oordeel over architectuur, afwegingen, juistheid en over wat níet te bouwen verdwijnt niet. Dat waren altijd de delen die iemand uit de techniek vroegen.
