Spec-driven development: eerst de tekening, dan de bouw

Bijgewerkt: 6 augustus 2026 · 5 min leestijd

Stel je een architect voor die een huis moet ontwerpen. Die begint niet met stenen te stapelen, maar maakt eerst een gedetailleerde bouwtekening: hoeveel kamers, waar de leidingen lopen, welke belasting het dak moet dragen. Pas als die tekening klopt, gaan de aannemers aan de slag. Spec-driven development (specificatiegestuurd ontwikkelen) past dit idee toe op software: eerst schrijf je een precieze, leesbare beschrijving van wat een programma moet doen, en pas daarna wordt die beschrijving omgezet in werkende code — steeds vaker door een AI-systeem.

Het begrip is niet gloednieuw, maar heeft de laatste jaren een nieuwe lading gekregen door de opkomst van AI-codeerassistenten: computerprogramma's die op basis van tekst zelfstandig programmeercode kunnen schrijven. Die assistenten zijn snel, maar maken ook fouten als je ze een vaag verzoek geeft. Een uitgeschreven specificatie ('spec') werkt dan als een soort contract: het dwingt mens én machine om eerst precies te bepalen wát er gebouwd moet worden, voordat er één regel code valt.

Wat is het precies?

Bij gewoon programmeren typt een ontwikkelaar direct code en test die al doende: schrijven, uitproberen, bijschaven. Bij spec-driven development wordt er een tussenstap ingebouwd. Eerst wordt in gewone taal, aangevuld met gestructureerde lijstjes, vastgelegd wat de software moet doen: welke functies er zijn, hoe het systeem zich moet gedragen bij foutieve invoer, welke gegevens waar vandaan komen.

Veel hedendaagse gereedschappen splitsen dit proces in duidelijke stappen. Eerst worden de requirements (eisen) beschreven: wat moet het systeem kunnen. Daarna volgt een design of plan: hoe wordt dat technisch aangepakt, welke bouwstenen zijn nodig. Vervolgens worden concrete taken uitgeschreven, kleine, behapbare stukjes werk. Pas in de laatste stap genereert een AI-agent — een programma dat zelfstandig meerdere stappen achter elkaar uitvoert — de daadwerkelijke code op basis van die documenten.

Het belangrijkste verschil met vroegere planningsmethodes is dat de specificatie niet wordt weggegooid zodra het programmeren begint. De spec blijft bestaan naast de code, in hetzelfde projectarchief, en wordt bijgewerkt als de eisen veranderen. Verandert de spec, dan kan de code er automatisch opnieuw uit worden afgeleid. Dat is een andere aanpak dan de klassieke 'waterval'-methode uit de jaren tachtig en negentig, waarbij een dik requirementsdocument één keer werd geschreven en daarna nauwelijks meer werd aangeraakt.

Wat wil men ermee bereiken?

De kern van het probleem dat spec-driven development probeert op te lossen is miscommunicatie. Wie een AI-assistent losjes vraagt 'bouw een inlogscherm', krijgt een resultaat dat toevallig kan kloppen of juist compleet mist wat er eigenlijk nodig was — bijvoorbeeld hoe wachtwoordfouten worden afgehandeld, of welke gegevens bewaard mogen blijven. Een uitgeschreven specificatie dwingt om die aannames vooraf expliciet te maken.

Een tweede doel is herhaalbaarheid. Code die een AI-model genereert op basis van een losse chatvraag is vaak lastig te reproduceren of aan te passen: de volgende keer geeft hetzelfde model misschien een ander antwoord. Een spec ligt vast, kan worden gecontroleerd door collega's, en kan dienen als basis om tests automatisch af te leiden: klopt de gegenereerde code wel met wat er beloofd werd?

Achterliggend idee is dat, nu AI-modellen code steeds sneller kunnen typen, het schaarse goed niet meer 'typen' is maar 'helder nadenken over wat je wilt'. Voorstanders zien de specificatie daarom als het nieuwe primaire werkproduct van software-ontwikkelaars, met code als een soort automatisch gegenereerd bijproduct — vergelijkbaar met hoe een architect wordt afgerekend op de tekening en niet op het metselwerk.

Voorbeelden uit de praktijk

GitHub Spec Kit — Softwareplatform GitHub (onderdeel van Microsoft) bracht in 2025 een opensource-gereedschap uit met de naam Spec Kit. Het reikt een vaste werkwijze aan met commando's als /specify, /plan en /tasks, bedoeld om samen met AI-codeerassistenten zoals GitHub Copilot te werken volgens het spec-eerst-principe.

AWS Kiro — Techgigant Amazon presenteerde in 2025 Kiro, een zogeheten agentic IDE (een programmeeromgeving waarin een AI-agent zelfstandig taken uitvoert). Kiro laat gebruikers eerst documenten als requirements.md en design.md opstellen voordat het de bijbehorende code genereert.

Tessl — Techondernemer Guy Podjarny, eerder oprichter van het beveiligingsbedrijf Snyk, richtte een nieuw bedrijf op dat zich volledig toelegt op wat het 'spec-centric' softwareontwikkeling noemt: software waarbij de specificatie, niet de code, het leidende document is.

TLA+ bij Amazon — Een oudere, minder AI-gedreven variant van hetzelfde principe: de formele specificatietaal TLA+, ontwikkeld door informaticus Leslie Lamport, wordt bij Amazon al ruim een decennium gebruikt om ingewikkelde, foutgevoelige systemen zoals opslagdienst S3 vooraf wiskundig te beschrijven en op fouten te controleren, nog voordat er code wordt geschreven. Amazon-ingenieurs beschreven deze werkwijze in het vakblad Communications of the ACM.

API-first met OpenAPI — Al langer bestaande praktijk in webontwikkeling: voordat een programmeerinterface (API, de manier waarop programma's met elkaar praten) wordt gebouwd, schrijven ontwikkelaars eerst een specificatie in het OpenAPI-formaat (voorheen Swagger geheten). Daaruit worden vervolgens automatisch documentatie, testcode en soms zelfs delen van de programmacode gegenereerd.

Hoe ver is de techniek?

Hier moet onderscheid gemaakt worden tussen twee lagen. De oudere laag — formele specificatie zoals TLA+, en spec-first API-ontwikkeling met OpenAPI — is volwassen technologie met jarenlange praktijkervaring, maar wordt vooral toegepast in specifieke niches: complexe gedistribueerde systemen, of het bouwen van webinterfaces. Het is geen mainstream werkwijze voor alledaagse software.

De nieuwere laag — specs als sturingsmiddel voor AI-codeerassistenten — is daarentegen nog erg jong. De genoemde gereedschappen van GitHub, Amazon en Tessl dateren stuk voor stuk uit 2025 en bevinden zich grotendeels in een preview- of vroege-adoptiefase. Er is nog geen gestandaardiseerd bestandsformaat: elk platform gebruikt zijn eigen conventies voor hoe een specificatiedocument eruit moet zien.

Er kleven ook bekende obstakels aan. Specs kunnen net zo ambigu of onvolledig zijn als gewone code-commentaar, en 'garbage in, garbage out' blijft gelden: een slordige specificatie levert nog altijd slordige code op. Een ander veelgenoemd risico is spec drift: de specificatie en de daadwerkelijke code raken na verloop van tijd uit de pas, bijvoorbeeld doordat ontwikkelaars snel iets in de code repareren zonder de spec bij te werken. Ten slotte blijft een AI-model, ook met een heldere spec in de hand, gevoelig voor het letterlijk volgen van de tekst terwijl de bedoeling erachter gemist wordt. Het is op dit moment niet uit te sluiten dat spec-driven development over een paar jaar wordt gezien als één van meerdere werkwijzen naast elkaar, in plaats van de dominante aanpak waarvoor sommige voorstanders het nu verslijten.

Wie werken eraan?

Aan de AI-gedreven variant werken vooral grote softwarebedrijven met eigen codeerassistenten: Microsoft/GitHub met Spec Kit en Copilot, en Amazon Web Services met Kiro. Daarnaast zijn er gespecialiseerde start-ups zoals Tessl, opgericht door voormalig Snyk-oprichter Guy Podjarny, die zich volledig richten op deze werkwijze.

Aan de formelere, wiskundige kant van specificatie-onderzoek is informaticus Leslie Lamport een centrale naam; hij ontwikkelde TLA+ en werkte lange tijd bij Microsoft Research. Amazon paste die taal in de praktijk toe voor zijn cloudinfrastructuur. Voor het API-first-domein is de OpenAPI Initiative, ondergebracht bij de Linux Foundation, de partij die de gedeelde specificatiestandaard beheert. Een breder, overkoepelend standaardisatieorgaan voor AI-gedreven spec-driven development bestaat vooralsnog niet: elk platform ontwikkelt zijn eigen aanpak.