Specificatiegestuurde ontwikkeling: de praktijk waar de categorie op samenkwam

Elk noemenswaardig AI-hulpmiddel voor code bracht binnen ongeveer een jaar dezelfde functie uit, en dat gebeurt bijna nooit per ongeluk.

In 2025 was de interessante vraag hoe goed de modellen werden. In 2026 is de interessante vraag wat je ze overhandigt.

GitHub bracht Spec Kit uit. AWS bracht Kiro uit, een ontwikkelomgeving die rond het idee is gebouwd. BMAD-METHOD, OpenSpec en Tessl deden er elk een poging toe. Cursor kwam er via regelbestanden. Martin Fowler heeft een vergelijking van de uitvoeringen gepubliceerd. Wanneer zes onafhankelijke teams binnen twaalf maanden op hetzelfde antwoord samenkomen, kopiëren ze elkaar niet. Ze lopen allemaal tegen dezelfde muur.

De muur heeft nu een naam. De oplossing ook.

Wat specificatiegestuurde ontwikkeling werkelijk is

Schrijf de eisen, de randvoorwaarden en de succescriteria voordat er code wordt opgeleverd. Behandel dat document als de bron van waarheid. Laat de agent daartegen bouwen.

Dat is alles. Het is geen nieuw idee: het is eisenanalyse, die de sector dertig jaar slecht heeft gedaan en daarna grotendeels als te langzaam heeft opgegeven. Wat veranderd is, is niet het begrip. Het is de economie.

Specificaties waren duur om te schrijven en duur om bij te houden, wat betekende dat de meeste teams de grote lijnen schreven en al het overige in de coderevisie ontdekten. Dat was een redelijke ruil zolang iemand toch drie weken over de functie deed. Het hield op redelijk te zijn toen het opleveren snel werd, want nu is de specificatie het langzame deel, en in het langzame deel woont al het oordeel.

De manier van falen waartegen het is bedacht

Hulpmiddelen die met de prompt beginnen, slaan de specificatie volledig over. Je beschrijft een uitkomst, het hulpmiddel levert iets op dat erop lijkt, en elke beslissing die de beschrijving niet dekte, wordt stilzwijgend door de generator genomen.

Welke beslissingen? Die welke belangrijk blijken. Of een e-mailadres uniek is, en uniek ten opzichte van wat. Wat een opgezegd account nog mag zien. Wat er gebeurt wanneer twee mensen hetzelfde record bewerken. Of die lijst paginering nodig heeft voordat er tienduizend rijen in staan.

Niemand heeft die vragen gesteld, dus niemand heeft ze beantwoord, maar de toepassing heeft op elke ervan een antwoord, gekozen door gevolgtrekking uit een context waarin jouw bedrijf nooit voorkwam.

Dezelfde dynamiek verschijnt in elk hulpmiddel dat de bepalingsstap overslaat. Het is het mechanisme achter het 70-procentprobleem: de voortgang loopt niet vast omdat het resterende werk moeilijk is, maar omdat het geblokkeerd wordt door een architectonische beslissing die honderden generaties eerder stilzwijgend is genomen en niet meer te veranderen valt zonder het systeem uit elkaar te trekken.

De cijfers over wat er zonder gebeurt

Het DORA-rapport van 2025 over de stand van door AI ondersteunde softwareontwikkeling is de helderste beschikbare lezing. 90 procent van de mensen die in de techniek werken gebruikt nu AI op het werk en meer dan 80 procent gelooft dat het hun productiviteit heeft verhoogd. En een hogere inzet van AI gaat samen met een toename van de leveringsproductiviteit en met een toename van de leveringsinstabiliteit, op hetzelfde moment.

Sneller in het uitbrengen. Slechter in het in de lucht houden. Beide, samen.

De analyse van GitClear uit 2026 over 623 miljoen codewijzigingen laat de vorm van de schade zien. Tegenover de basislijn van 2023: verdubbelde codeblokken 81 procent hoger, kopiëren en plakken binnen dezelfde inzending gestegen van 9,4 procent in 2022 naar 15,7 procent in de eerste helft van 2026, constructies die fouten verhullen 47 procent hoger. Tegelijk functieaanroepen over bestanden heen, de beste beschikbare maatstaf voor hergebruik van code, 35 procent lager, en herstructureringswerk ingestort van 21 procent van de wijzigingen in 2022 naar 3,8 procent in 2026.

Wie ontwikkelt kopieert en plakt nu ongeveer vijf keer zo vaak als hij herstructureert. In 2022 liep die verhouding de andere kant op.

Niets daarvan is een kwestie van modelkwaliteit. Het is wat gebeurt wanneer opleveren goedkoop is en structuur uitdrukkelijk niemands taak.

De drie gradaties van toewijding

Niet iedereen bedoelt hetzelfde met deze uitdrukking, en de verschillen tellen in de praktijk. De kadering van Martin Fowler is de helderste die ik heb gezien.

Specificatie eerst. Je schrijft de specificatie, levert daaruit op en onderhoudt de code daarna met de hand. De specificatie drijft de eerste bouw aan en wordt daarna geleidelijk historisch. Het gemakkelijkst in te voeren, met de zwakste garanties: zes maanden later beschrijft het document een systeem dat niet meer bestaat.

Specificatie als anker. Specificatie en code groeien samen mee. Je verandert de specificatie, levert de betrokken delen opnieuw op, houdt beide bij. Meer discipline, en de opbrengst is dat het document betrouwbaar blijft.

Specificatie als bron. De specificatie is het enige artefact dat je aanpast. Code is uitvoer, zoals een gecompileerd bestand uitvoer is: je lapt het niet met de hand op. De sterkste garanties en de grootste sprong in de manier van werken van een team.

De meeste teams die zich specificatiegestuurd noemen, doen specificatie eerst. Dat is een echte verbetering ten opzichte van blind prompten, en het is ook de versie die stil vervalt.

Wat in de specificatie hoort

De nuttige proef: als de generator zou moeten gokken, hoort het in het document.

• Het gegevensmodel. Entiteiten, relaties, kardinaliteit, wat een record uniek maakt, wat er bij verwijderen gebeurt. Dit is het meest waardevolle onderdeel en het onderdeel dat het vaakst wordt overgeslagen.
• Gebruikerstypes en rechten. Wie er bestaat, wat elk mag zien en doen, wat er aan de grenzen gebeurt.
• De invarianten. Regels die nooit geschonden mogen worden, ronduit gesteld. Niet «fouten elegant behandelen»: dat is een wens en geen randvoorwaarde.
• Succescriteria. Hoe je weet dat het ding werkt, in termen die precies genoeg zijn dat een meningsverschil erover oplosbaar is.

Wat er niet in hoort: uitvoeringsdetails die de generator beter kiest dan jij. Een specificatie die variabelen benoemt, is geen specificatie, het is code met slechter gereedschap.

Het deel dat iedereen verkeerd doet

Een specificatie helpt alleen als die ergens anders dan in prozavorm afdwingbaar is.

Als een randvoorwaarde alleen in het document leeft, is het een suggestie. De generator heeft die één keer gelezen en kan die in het veertiende aangeraakte bestand hebben gerespecteerd of niet. Randvoorwaarden moeten belanden waar het systeem controleert: «niet leeg» en «uniek» in de database in plaats van in een formulierverwerker, typen op de grenzen in plaats van in een opmerking, autorisatie als beleid dat het systeem beoordeelt in plaats van als voorwaarde die iemand zich herinnerde te schrijven.

Dat is het verschil tussen specificatiegestuurde ontwikkeling als praktijk en specificatiegestuurde ontwikkeling als soort document. Het document is hoe je beslist. De afdwinging is hoe je de beslissing behoudt.

Hoe je weet of je het werkelijk doet

Vier vragen, en ze zijn met opzet ongemakkelijk.

1. Wanneer iets breekt, repareer je de code of de specificatie? Als het antwoord altijd de code is, doe je op zijn best specificatie eerst, en is het document al verouderd.
2. Zou een nieuw iemand de specificatie kunnen lezen en voorspellen hoe het systeem zich gedraagt? Als die daarvoor de code zou moeten lezen, is de specificatie een samenvatting in plaats van een bron.
3. Staat er iets in de specificatie dat het systeem niet kan schenden? Als elke regel proza is, is er geen gegarandeerd.
4. Kijk je de specificatie of de diff na? Duizenden regels opgeleverde code nakijken is theater. Discussieer over het document terwijl discussiëren nog weinig kost.

Waar dit de hulpmiddelen laat

De meeste huidige uitvoeringen zijn specificatiegestuurd specifiek voor het opleveren van code. Ze leveren een specificatie op en leveren daartegen een uitvoering, en het artefact waarop ze werken is een codebasis.

De moeilijkere versie breidt dezelfde logica uit naar de hele toepassing (het gegevensmodel, het API-oppervlak, de authenticatiegrens, de interface) zodat de specificatie niet alleen dekt wat de code doet maar wat het systeem is. Dat is precies de blueprintfase van Archie, en daarom beschrijf ik die als specificatiegestuurde ontwikkeling toegepast op de hele stapel in plaats van op een repository. Ander bestek, hetzelfde beginsel: bepalen vóór opleveren.

Redelijke mensen zijn oneens over hoe ver je dit moet doortrekken. Niemand die het serieus meent, pleit voor teruggaan.

Wat het kost

Oordeel naar voren halen is langzamer in de eerste week van een project en sneller in elke week daarna. Die kosten zijn echt en worden precies betaald op het moment dat aanloop het meest waardevol lijkt, terwijl een concurrent iets zichtbaars uitbrengt. Er zullen werkrondes zijn waarin het team dat dit oversloeg lijkt voor te lopen.

De discipline vervalt ook. Randvoorwaarden opschrijven is minder prettig dan een interface zien verschijnen, en een document nakijken is minder bevredigend dan code nakijken. Die gewoonten eroderen onder tijdsdruk, en dat is dezelfde druk die ze belangrijk maakt.

En het geldt werkelijk niet voor alles. Als je dit weekend een idee toetst en het resultaat wilt weggooien, gooi het weg. Niets hiervan is de moeite waard voor software met twee dagen levensduur.

De reden dat dit is gebleven

Elke eerdere poging om teams eerst specificaties te laten schrijven mislukte, en die mislukte om een goede reden: de specificatie was extra gewicht boven het echte werk. Je schreef het document en daarna moest je het ding nog steeds bouwen.

Dat is niet meer de ruil. Nu is het document het grootste deel van het werk, en het bouwen is het goedkope deel. Zes onafhankelijke teams merkten dat binnen een jaar op omdat het het duidelijke gevolg was van het feit dat het model goed werd.

De praktijk heeft geen discussie gewonnen. De economie is eronder verschoven.

Verwante lectuur

De oorspronkelijke diagnose: vibe coding heeft zijn belofte gebroken. Waar de categorie daarna heen ging: wat komt na vibe coding. Hetzelfde argument toegepast op hele systemen: AI-first-softwareontwerp vanuit eerste principes. En de oudere formulering van hetzelfde idee: software niet twee keer schrijven.

Veelgestelde vragen

Wat is specificatiegestuurde ontwikkeling? 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 en 2026 als direct antwoord op manieren van werken die met de prompt beginnen en de bepalingsstap overslaan.

Waarin verschilt het van klassieke eisendocumenten? Het begrip is hetzelfde; de economie niet. Klassieke specificaties waren duur genoeg dat teams de grote lijnen schreven en de rest tijdens de uitvoering ontdekten. Wanneer er een opstellen uren kost in plaats van maanden en goedkoop te herzien is, wordt het lonend haar af te maken en 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, ernaast meegroeit of het enige artefact is dat je aanpast.

Wat zijn de drie gradaties van specificatiegestuurde ontwikkeling? Specificatie eerst, waarbij de specificatie de eerste bouw aandrijft en je de code daarna met de hand onderhoudt. Specificatie als anker, waarbij specificatie en code samen meegroeien. Specificatie als bron, waarbij de specificatie het enige is dat je aanpast en code als uitvoer wordt behandeld. De meeste teams die het doen, doen specificatie eerst.

Vertraagt specificatiegestuurde ontwikkeling teams? Ze verplaatst het werk in plaats van het toe te voegen. De beslissingen in een specificatie worden of bewust vooraf genomen of stilzwijgend door een generator die later gokt, en de tweede weg is de bron van het herstelwerk. Ze is langzamer in de eerste week en sneller daarna.

Wat hoort er in een specificatie? Alles wat de generator anders zou moeten gokken: het gegevensmodel met relaties en regels voor uniekheid, gebruikerstypes en rechten, invarianten die nooit geschonden mogen worden en succescriteria die precies genoeg zijn om een meningsverschil te beslechten. Laat de uitvoeringsdetails weg die de generator beter kiest dan jij.

Is specificatiegestuurde ontwikkeling hetzelfde als AI-first-ontwerp? Specificatiegestuurde ontwikkeling is de praktijk van bepalen vóór opleveren. AI-first-ontwerp is de ruimere verzameling architectonische gevolgen, die ook dekt waar randvoorwaarden worden afgedwongen, in welke volgorde je beslissingen neemt en hoe je ontwerpt voor afnemers die agenten zijn naast afnemers die mensen zijn.