Wat is het verschil tussen model-driven en spec-driven development?

"Vibe coding" als manier van programmeren, snel prompten en aanvaarden wat eruit komt, kreeg in recordtempo een tegenbeweging: spec-driven development. Eerst opschrijven wat je wil, dan pas de AI laten bouwen. Dat klinkt verdacht veel als het model-driven development waar we eerder over schreven. Toch zijn het geen synoniemen. En het interessantste zit precies in de combinatie.

Wat is model-driven development?

Model-driven development (MDD) is het oudste van de twee. Je beschrijft eerst wat je systeem ís in een formeel model: welke gegevens er zijn, welke stappen een dossier doorloopt, welke regels gelden. Uit dat model wordt de applicatie automatisch afgeleid. Het model is het primaire artefact, de code een afgeleide. In de jaren 2000 strandde dat idee grotendeels; waarom het in het AI-tijdperk terug is, legden we uit in die eerdere post.

Wat is spec-driven development?

Spec-driven development (SDD) is een werkwijze uit het AI-tijdperk, bekend geworden via tools als Kiro en GitHub Spec Kit. Het idee: voor een AI-agent ook maar één regel code schrijft, leg je in een gestructureerd document vast wat er moet komen. Requirements, ontwerpkeuzes, taken, in gewone taal en meestal gewoon markdown. Die spec is de bron van waarheid: de AI bouwt ertegen, en jij toetst het resultaat eraan.

Het verschil in drie punten

Beide zeggen hetzelfde: code is niet het primaire artefact, maar een afgeleide van iets abstracters. Het verschil zit in drie dingen.

Het artefact. Bij MDD een formeel model, bij SDD een document in natuurlijke taal.

De generator. Bij MDD wordt de code deterministisch afgeleid: hetzelfde model geeft altijd dezelfde applicatie. Bij SDD interpreteert een AI de spec. Dat is sneller en flexibeler, maar niet gegarandeerd juist.

De sterkte. Een model is ondubbelzinnig maar star: het vat structuur perfect en uitzonderingen slecht. Een spec is flexibel maar vaag: ze vat bedoeling goed, maar laat ruimte voor interpretatie.

De laatste twintig procent

Klassiek MDD strandde in de jaren 2000 op precies die uitzonderingen. Het model genereerde probleemloos schermen, gegevens en standaardflows, maar voor de laatste twintig procent, het "ja maar bij die ene klant werkt het anders", moest je handmatig in de gegenereerde code duiken. En vanaf dat moment loog het model.

SDD lijkt gemaakt om dat gat te vullen: wat niet in het model past, schrijf je uit in tekst en laat je de AI invullen. Structuur waar het kan, gewone taal waar het moet.

Eerlijkheidshalve: dat is geen toverstaf. Wat moeilijk te modelleren valt, is vaak óók moeilijk ondubbelzinnig op te schrijven. En een AI die tekst interpreteert, kan er subtiel naast zitten. Zonder tests die rechtstreeks uit de spec volgen, heb je geen methode maar gewoon vibe coding met een duur voorwoord. Bovendien heb je plots twee bronnen van waarheid (het model én de tekst) die uit elkaar kunnen groeien als je er geen duidelijke afspraken over maakt.

Hoe wij het combineren

Bij Tandem Studio starten we vanuit de user journey: de weg die een klant, dossier of bestelling door je bedrijf aflegt. Die journey vertalen we naar een event model, een schema van alle gebeurtenissen in je proces, gebouwd op event sourcing met DCB. Dat model bezit de structuur: welke gebeurtenissen bestaan er, welke gegevens horen erbij, welke regels moeten gelijktijdig bewaakt worden.

Bij elke stap in dat schema horen concrete voorbeelden: gegeven deze eerdere gebeurtenissen, bij deze actie, verwacht dit resultaat. Die voorbeelden zijn geen documentatie die veroudert. Ze worden één-op-één de tests waar de gebouwde software aan moet voldoen.

En wat niet in een schema te vatten is (waaróm een regel bestaat, wat er moet gebeuren in een randgeval, hoe een scherm zich gedraagt terwijl het systeem verwerkt) schrijven we als kort tekstblok bij die ene stap. Met twee huisregels. Eén: de tekst hangt áán het model, niet in een los document ernaast. Twee: de tekst mag geen nieuwe structuur uitvinden. Heeft ze een gegeven nodig dat niet in het model zit, dan wijzigt eerst het model. Het model is de waarheid over structuur; de tekst is de waarheid over betekenis.

Voor de AI wordt elke stap zo een kleine, controleerbare opdracht: bouw dit stukje, binnen dit model, tegen deze voorbeelden. Het model bewaakt de grenzen, de voorbeelden bewijzen het resultaat.

Kortom

Model-driven development geeft structuur, maar strandde vroeger op de uitzonderingen. Spec-driven development vangt de uitzonderingen, maar mist op zichzelf elke vangrail. De combinatie van een formeel model als skelet, gewone taal als bindweefsel en voorbeelden die tests worden, geeft je software die leesbaar blijft én klopt met wat je bedoelde.

Eerst het model, dan de spec, dan pas de code. Nooit omgekeerd.

Benieuwd hoe zo'n event model er voor jouw proces uitziet? Praat met ons, we tekenen het graag samen uit.