Spec-driven development

Het knelpunt bij bouwen met AI is verschoven. Niet het typen van code houdt je tegen, maar weten wat je wilt bouwen. Voor wie, in welke volgorde, met welke edgecases. Dat klinkt simpel, tot je begint. Dan blijkt dat een product niet bestaat uit een mooi hoofdscherm maar uit keuzes. Wat ziet iemand zonder data? Wat gebeurt er als de API traag is? 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 werkt dat. Voor een product loop je vast. De AI raadt, jij corrigeert, de chat wordt langer en 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. De spec is het ontwerpdocument: flows, states, edgecases, microcopy en toegankelijkheid liggen 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, gemaakt door GitHub, en werkt met Claude Code, Copilot en Cursor. Je gebruikt AI als uitvoerder van een helder ontwerp.

Wat spec-driven development is

            <div class="aside aside-float aside-top" data-anchor="sdd-vier-stappen">

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. Speckit werkt met vier stappen, en elke stap levert een markdown-bestand op dat de volgende stap leest. Daarboven hangt een constitution: het bestand met huisregels die altijd gelden, van je design system en goedgekeurde libraries tot security-regels en patronen die niet meer terug mogen komen.

Die bestanden zijn geen administratie achteraf, ze sturen het werk. spec.md zegt wat er moet gebeuren, plan.md hoe het gebouwd wordt, tasks.md maakt het uitvoerbaar en de constitution is de vangrail. We bouwen onze eigen producten exact zo, omdat idee, ontwerp en code dan dicht bij elkaar blijven.

Vanaf nul: speccen voordat je bouwt

Bij een nieuw product is het grootste risico niet dat je langzaam bouwt, maar dat je snel het verkeerde bouwt. AI maakt dat risico groter: je genereert in een middag een dashboard of checkout, en dat voelt als voortgang. Maar als de flow niet klopt, heb je vooral sneller afval gemaakt. Code is pas goedkoop als de richting klopt.

            <div class="aside aside-float">

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.

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. 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 zien of pensioenaanvulling fiscaal zinvol is, hoeft daarvoor geen fiscale termen te kennen, en bij ontbrekende gegevens geeft de interface geen fout maar een duidelijke vervolgvraag. Dat zijn ontwerpkeuzes. En die horen vóór de code.

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 en wat er gebeurt als de API-call faalt. De review gaat daarna niet over smaak, maar over de vraag of de output de spec volgt.

Een spec is geen excuus om alles dicht te timmeren. Een goede spec maakt de eerste versie juist kleiner: wat moet iemand doen, zien en begrijpen om te beslissen dat dit product de moeite waard is? De rest hoeft nog niet. Daarna kan AI snel bouwen. Maar dan bouwt het op rails die jij hebt gelegd.

Waar het schittert, en waar niet

Spec-driven development werkt niet overal even goed. 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.

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.

Spec-driven development vervangt het ontwerp-oordeel dus niet, het legt het vast en dwingt het af. De ontwerper ziet wanneer een flow stroef voelt of een knop te vroeg komt; 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: je neemt de keuzes op het moment dat ze nog goedkoop zijn. Eerst de ervaring scherp, dan de code. Voor ons is spec-driven development daarom hetzelfde als design-first bouwen. De spec is geen technische bijlage, maar het ontwerpdocument dat bepaalt wat er straks in handen van je gebruiker komt. En meteen de documentatie van je product.

Heb je een productidee dat nog vorm moet krijgen? Voor € 750 maken we er een klikbaar prototype van, dan weet je of het klopt voordat je een spec schrijft. Is de kern al scherp? Neem contact op, dan speccen en bouwen we hem samen.