Vorige week testte ik specification-driven development (SDD) op vijf projecten. Niet om mee te zijn met de hype, maar om problemen op te lossen. Samenwerking gebeurt heel vaak binnen onze bedrijven, en te veel miscommunicatie die pas laat naar boven komt ook. Alles is goedbedoeld, maar fouten zijn frustrerend en kostelijk.
Het idee achter SDD is simpel. Je schrijft exact op wat software moet doen, als een formeel contract, vóór iemand ook maar één lijn code schrijft. Die spec is de source of truth. De code volgt, niet andersom. Ook goed om interpretatie van vibe-coders te voorkomen, die bij ons elke dag meer code schrijft.
In theorie: elegant en logisch. In de praktijk: efficiënt, maar heftig.
Het eerste wat opvalt: changes zijn zwaar. Als een developer iets wil bijsturen omdat het in de flow net iets anders aanvoelt, is dat direct veel werk. Spec aanpassen, tests aanpassen, review, validatie en dàn pas developpen.
By design - maar frustrerend als dat vroeger sneller ging. De hoop is dat je die late changes gewoon vermijdt omdat je vroeger beter nadenkt. Dat moet zich nog bewijzen.
Het tweede: AI-assisted spec generation produceert snel te veel. Bloated, moeilijk te overzien voor niet-technische profielen (analisten of product owners). Als de spec een ondoorzoekbaar boek wordt en niks écht gevalideerd wordt, heb je het probleem alleen maar verplaatst. Templates en discipline zijn nodig en de business moet het ook zien zitten.
Wat wel overtuigt: de meerwaarde voor AI-driven development. Hoe preciezer de spec, hoe beter en voorspelbaarder de output. Garbage in, garbage out geldt nog steeds, maar goeie specs geven een scherp resultaat. QA-agents die waken over dev-agents hebben eindelijk een duidelijk script.
En voor samenwerking over meerdere teams, is de pijn is het grootst aan de grenzen. Twee agencies die dezelfde API anders implementeren, data die niet matcht, integraties die laat fout lopen, UI die er plots anders uitziet. SDD dwingt die coördinatie naar het begin, in een versioned contract. Minder "wij dachten dat jullie X bedoelden."
Vandaag zoek ik nog welke tooling past bij welke projecten. Spec-kit is uitgebreid maar overweldigend. OpenSpec is lichter en makkelijker aanpasbaar. Tessl meer allesomvattend. En dan spreek ik enkel over development, niet over functionele analyse of design.
Nu, SDD is sowieso overkill voor experimenten en one-pagers. En het werkt pas goed als je ook serieus investeert in opleiding — hoe denk je beter na over specs, hoe valideer je de output, hoe bewaak je de groei. Sla je dat over, krijg je slechte specs en slechte output.
We beginnen klein. Eén gedeelde interface tussen twee dochterbedrijven in een projectje, specs uitschrijven, contract tests in CI zetten. Geen grote uitrol, gewoon leren of het in onze context werkt.
Over 60 dagen weten we meer.