Spec-driven development
Het knelpunt bij bouwen met AI is verschoven. Niet het typen van code houdt je tegen. Het echte werk zit eerder. Je moet weten wat je wilt bouwen, voor wie, in welke volgorde, met welke edgecases en ga zo maar door..
Dat klinkt simpel. Tot je begint. Dan blijkt dat een product niet bestaat uit een mooi hoofdscherm. Het bestaat uit keuzes. Wat ziet iemand zonder data? Wat gebeurt er als de API traag is? Welke foutmelding krijgt iemand die iets verkeerd invult? Welke knop krijgt focus na een mislukte betaling? Wat mag de AI nooit zelf invullen?
Met vibe coding kom je een eind. Je prompt, kijkt wat eruit komt en stuurt bij. Voor een demo kan dat werken. Voor een product loop je vast. De AI raadt. Jij corrigeert. De chat wordt langer. Het plan verschuift. Na tien rondes weet niemand meer welke beslissing leidend was.
Eerst de spec, dan de code
Spec-driven development draait die volgorde om. Eerst schrijf je de spec. Daarna komt de code eruit. De spec is de bron van waarheid, niet de chatgeschiedenis.
Voor een design-first studio is dat geen technisch trucje. Voor ons is de spec het ontwerpdocument. Daarin leg je flows, states, edgecases, microcopy en toegankelijkheid vast voordat er één regel code is. Goed speccen is goed ontwerpen.
Een goede spec is 90% van het werk.
Speckit maakt dat praktisch. Het is open source van GitHub en werkt met Claude Code, Copilot en Cursor. Je gebruikt AI als uitvoerder van een helder ontwerp.
Wat spec-driven development is
De vier stappen
- Specify. Wat de gebruiker moet kunnen, welke flows en states, welke teksten.
- Plan. De technische aanpak: routes, componenten, datamodellen, koppelingen.
- Tasks. Het plan opgeknipt in kleine, te reviewen taken.
- Implement. De AI bouwt de taken uit, met spec en plan als leidraad.
Spec-driven development is een manier van bouwen waarbij elk stuk werk begint met een geschreven afspraak. Niet met code. Niet met een losse prompt. Eerst het document dat zegt wat het product moet doen.
Speckit werkt met vier stappen. Elke stap levert een markdown-bestand op dat de volgende stap leest.
Daarboven hangt een constitution. Dat is het bestand met huisregels die altijd gelden. Denk aan je design system, toegankelijke componenten, goedgekeurde libraries, taalgebruik, security-regels en patronen die niet meer terug mogen komen.
De bestanden zijn geen administratie achteraf. Ze sturen het werk. spec.md zegt wat er moet gebeuren. plan.md zegt hoe het gebouwd wordt. tasks.md maakt het uitvoerbaar. De constitution is de vangrail. We bouwen onze eigen producten exact op deze manier omdat het idee, ontwerp en de code dicht bij elkaar blijven.
Vanaf nul: speccen voordat je bouwt
Bij een nieuw product is het grootste risico niet dat je langzaam bouwt. Het grootste risico is dat je snel het verkeerde bouwt.
AI maakt dat risico groter. Je kunt in een middag een dashboard, onboarding of checkout laten genereren. Dat voelt als voortgang. Maar als de flow niet klopt, heb je vooral sneller afval gemaakt.
Een founder voelt die druk vaak als eerste. Je hebt een idee. Je wilt iets laten zien. Je wilt naar gebruikers, investeerders of een eerste klant. Dan is het verleidelijk om meteen te bouwen. Zeker als AI de eerste versie goedkoop lijkt te maken.
Maar code is pas goedkoop als de richting klopt. Een spec vooraf is een kleine investering. Het is onderdeel van het werk zelf, want de AI bouwt wat in de spec staat.
Als je alleen vraagt om "een moderne SaaS onboarding", krijg je een patroon dat de AI al vaak heeft gezien. Drie stappen, wat kaarten, een voortgangsbalk en nette lege schermen. Dat kan er prima uitzien. Het zegt alleen weinig over je product.
Een goede spec zegt iets anders. Bijvoorbeeld: een zzp'er moet in minder dan twee minuten kunnen zien of pensioenaanvulling fiscaal zinvol is. De gebruiker hoeft geen fiscale termen te kennen. Het systeem toont eerst een grove indicatie en vraagt pas daarna om detail. Bij ontbrekende gegevens geeft de interface geen fout, maar een duidelijke vervolgvraag.
Dat is een ontwerpkeuze. En die keuze hoort vóór de code.
De spec dwingt jou en de ontwerper om de beslissingen te nemen die ertoe doen. Niet alle beslissingen. Wel de keuzes die later duur worden.
Wat je vastlegt
- Flows. De route van eerste klik tot waarde.
- States. Leeg, laden, fout, geen toegang, opgeslagen, gelukt.
- Edgecases. Ontbrekende data, dubbele invoer, verlopen sessies, trage API's.
- Microcopy. Klant, gebruiker, deelnemer of rekeninghouder?
- Toegankelijkheid. Focus, toetsenbord, gekoppelde foutmeldingen, screenreader.
Daarom zien wij de spec als ontwerpdocument. Een Figma-scherm laat zien waar de knop staat. Een spec legt vast wat hij doet, wanneer hij uit staat, welke foutmelding volgt, welke API-call nodig is en wat er gebeurt als die call faalt. Samen vormen ze het ontwerp.
Dit maakt bouwen met AI veel scherper. De AI hoeft minder te raden. Jij hoeft minder te herstellen. De review gaat niet over smaak of interpretatie, maar over de vraag of de output de spec volgt.
Dat verandert ook het gesprek met een founder. In plaats van "we bouwen eerst even iets" wordt het: welke ervaring moet je eerste versie bewijzen? Welke aannames moeten erin? Welke aannames mogen eruit? Wat hoeft nog niet?
Dat laatste is belangrijk. Een spec is geen excuus om alles dicht te timmeren. Een goede spec maakt de eerste versie kleiner. Niet groter.
Voor een MVP wil je niet elk toekomstig dashboard beschrijven. Je wilt de waarde scherp krijgen. Wat moet iemand doen, zien en begrijpen om te beslissen dat dit product de moeite waard is?
Daarna kan AI snel bouwen. Maar dan bouwt het op rails die jij hebt gelegd.
Er is wel een grens. Weet je nog niet wat je bouwt, dan moet je niet beginnen met een zware spec. Dan moet je eerst ontdekken.
Soms is een quick prototype beter. Of een snel prototype in Figma. Of een klikbare flow met nepdata. Als de vraag nog is "welk probleem lossen we eigenlijk op?" dan is een spec te vroeg. Je kunt geen spec schrijven voor iets dat je nog aan het ontdekken bent.
Maar zodra de vorm helder is, verandert het spel. Dan is de spec 90% van het werk. Niet omdat code onbelangrijk is. Omdat code pas waarde krijgt als de keuzes kloppen.
En in een grote organisatie?
In een grote organisatie wordt hetzelfde principe belangrijker. Niet minder.
Tools als Cursor, Claude Code en Copilot kunnen werkende code schrijven. Maar ze kennen je organisatie niet. Ze weten niet welke dependencies zijn goedgekeurd. Ze weten niet welke logging verplicht is voor AVG. Ook security-eisen, error-handling en patronen op de no-go-lijst zitten niet vanzelf in hun context.
Daardoor krijg je code die technisch werkt, maar uit een andere wereld komt. Class components terwijl je React-team functional components gebruikt. Axios terwijl fetch de standaard is. API-calls zonder retry. Engelse foutmeldingen in een Nederlandse interface. Logging met persoonsgegevens waar legal meteen op vastloopt.
Dat haalt een review niet. Of erger: het haalt de review wel, omdat niemand tijd had om alle details te controleren.
De constitution is de laag die dit opvangt. Het bestand werkt als hard filter op elke output en zegt welke regels altijd gelden. De AI moet daarbinnen werken.
Voor teams maakt dat verschil. Je hoeft niet in elke prompt opnieuw te zeggen dat API-calls via de centrale client lopen. Ook Nederlandse foutmeldingen, componenten uit het design system en andere basisafspraken staan al in de constitution.
Een goede constitution is leesbaar voor meer dan developers. Security ziet welke logging mag en legal waar de AVG-risico's worden afgevangen. Zo wordt de spec een gedeelde waarheid: product, design, development, security en legal kijken naar hetzelfde uitgangspunt, niet naar vijf losse interpretaties.
Dat werkt ook tussen meerdere AI-agents: de een plant, de ander bouwt, een derde reviewt, allemaal vanuit dezelfde spec. In organisaties lekt anders veel weg tussen wat bedoeld was en wat gebouwd werd. Een security-regel staat in Confluence maar niet in de prompt. Een design-system-afspraak leeft in Figma maar niet in code.
Spec-driven development trekt die afspraken naar één plek. Niet perfect. Wel veel beter controleerbaar.
Volgens Deloitte heeft ongeveer één op de vijf organisaties een volwassen governance-model voor autonome AI-agents. De constitution is precies die laag, en ze zit in de werkstroom zelf.
Voor een design-first studio zit hier nog een tweede voordeel. Je kunt je design system als constitution-regel vastleggen. Als harde afspraak voor elke output.
Schrijf op: gebruik onze componenten. Voldoe aan WCAG. Gebruik deze foutmeldingen. Spreek over "klant" en niet over "gebruiker". Toon bedragen op deze manier. Geef focus terug aan het veld met de fout. Gebruik geen zelfgebouwde dropdown als het bestaande component voldoet.
Dan komt elke AI-output meteen dichter bij je merk, je toegankelijkheidsnorm en je producttaal. Op schaal. We schreven eerder waarom toegankelijkheid geen latere poetslaag is: Achteraf toegankelijk maken is de dure route.
Een concreet voorbeeld: bij NN hebben we de jaarruimte-calculator van een oude Blueriq-engine naar een moderne React-app geport. Het is een berekening waar veel mensen op vertrouwen. Je wilt daar geen AI-output die ongeveer klopt.
NN heeft strikte regels. Functional components. Een centrale API-client met retry. Nederlandse gebruikerstaal. Engels commentaar in code. Voorspelbare foutafhandeling. Geen willekeurige libraries.
Die regels stopten we vooraf in de constitution. De eerste output respecteerde ze meteen. Dat scheelde dagen per iteratie, omdat review niet telkens terug hoefde naar basisafspraken. De discussie ging sneller over gedrag, berekening en edgecases. Niet over stijlbreuk.
Dit zouden wij niet zo bouwen zonder constitution. Maar dat is aan jou. Als je AI in een bank, verzekeraar of overheidsomgeving serieus wilt gebruiken, moet je de regels uit de hoofden en wiki's halen. Ze moeten naast de code staan. Levend in git.
Wat hoort er dan in zo'n constitution?
In een constitution
- Taalregels. Wat vereist is en wat verboden. NL meldingen, EN comments.
- Dependencies. Welke libraries mogen, en de standaard voor formulieren, datums, state, API-calls.
- Architectuur. Hoe routes, services, componenten en tests zijn opgebouwd, met voorbeelden.
- Security en AVG. Welke data nooit gelogd mag, auditregels, foutregistratie.
- Design system en WCAG. Verplichte componenten, focusgedrag, toegankelijkheid per flow.
- Organisatie-taal. Klant, deelnemer, adviseur, gebruiker zijn niet uitwisselbaar.
De kunst is om niet alles dicht te zetten. Een constitution moet richting geven. Geef kaders waar herhaling foutgevoelig is. Laat ruimte waar engineering-oordeel nodig blijft.
Goede regels zijn concreet. "Gebruik veilige logging" is te vaag. "Log geen BSN, geboortedatum, e-mailadres of rekeningnummer. Log wel request-id, flow-id en foutcode" is bruikbaar.
Goede regels hebben voorbeelden. Een AI volgt voorbeelden vaak beter dan abstracte principes. Mensen trouwens ook.
Waar het schittert, en waar niet
Spec-driven development werkt niet overal even goed. Dat is geen probleem, zolang je weet wanneer je het inzet.
Het schittert wanneer de vorm helder is en de uitvoering precies moet zijn.
- Greenfield-producten met duidelijke vorm. Als je weet welke waarde de eerste versie moet leveren, is de spec 90% van het werk. Daarna kan AI snel en gericht bouwen.
- Regel-gedreven domeinen. Calculators, validaties, workflows, aanvragen en beslisbomen passen goed. De regels moeten toch al expliciet zijn.
- Legacy-migraties. Als gedrag al vastligt, kun je de bestaande regels vertalen naar een moderne stack zonder elke afspraak opnieuw te verzinnen.
- Interne tools met compliance-eisen. Rollen, rechten, auditlogs, foutafhandeling en datavelden moeten kloppen. Een spec maakt dat toetsbaar.
Het werkt minder goed wanneer je nog zoekt naar de vorm.
- Producten waarvan je nog niet weet wat je bouwt. Begin dan met prototypen. Test de richting eerst. Schrijf pas een spec als de kern duidelijk is.
- Zwaar creatief UI-werk. Veel beweging, animatie en gevoel in interactie vragen menselijke craft. Een spec helpt, maar vervangt het kijken en finetunen niet.
- Pure architectuurkeuzes. De constitution houdt keuzes consistent. Ze maakt de fundamentele keuze niet voor je. Iemand moet bepalen welke architectuur past.
Dat laatste punt is belangrijk. Spec-driven development vervangt het ontwerp-oordeel niet. Het legt het vast en dwingt het af.
De mens-ontwerper houdt de pixel-, interactie- en animatie-craft. Die ziet wanneer een flow stroef voelt. Die merkt dat een knop te vroeg komt. Een foutmelding kan te streng klinken. Een animatie kan helpen, of alleen tijd kosten.
De spec zorgt dat dat oordeel niet verdampt zodra code wordt geschreven. De spec is de brug tussen ontwerp en code.
Tot slot
De spec maakt het verschil. Of je nu een founder bent die met iets nieuws begint, of een bank die AI wil opschalen. Voor een founder betekent dat: minder bouwen op gevoel, meer keuzes maken op het moment dat ze nog goedkoop zijn. Eerst de ervaring scherp krijgen. Dan de code. Voor een grote organisatie betekent dat: AI-output die past bij je codebase, je regels, je design system en je taal.
Voor ons is spec-driven development daarom hetzelfde als design-first bouwen. De spec is geen technische bijlage. Het is het ontwerpdocument dat bepaalt wat er straks in handen van je gebruiker komt en de perfecte documentatie van je product.
Heb je een productidee en wil je de kracht van speckit ervaren? Neem contact op..
Werk je in een grotere organisatie, dan denken we mee over je constitution en hoe Speckit in je bestaande omgeving past. Met je design system, je security-regels en je manier van bouwen.
Laten we praten
Een idee, een vraag, of even overleggen? Mail of bel ons en we reageren zo snel mogelijk.
even bellen?