Hvad er det?#
Spec-driven development er en softwareudviklingsmetode, hvor man skriver en detaljeret specifikation (spec) før man begynder at kode. Spec’en definerer præcist, hvad systemet skal gøre — interfaces, dataformater, API-kontrakter og adfærd — og fungerer som den centrale kilde til sandhed gennem hele projektet.
Det lyder simpelt, men det er en grundlæggende anderledes tankegang end at sætte sig ned og begynde at kode med det samme.
Arbejdsflowet#
- Skriv specifikationen — definer interfaces, datamodeller og adfærd
- Review og godkend — alle interessenter (frontend, backend, QA, product) når alignment
- Udvikl ud fra spec’en — kode, og evt. auto-genererede stubs, følger spec’en
- Test mod spec’en — spec’en er facit for korrekthed
Pointen er, at fejl og misforståelser opdages i spec-fasen — ikke efter man har brugt to dage på at implementere noget, der viser sig at være forkert.
Fordele#
- Tidlig designtænkning — fejl opdages i spec-fasen, ikke i koden
- Fælles forståelse — alle teams arbejder ud fra samme kilde
- Parallel udvikling — frontend og backend kan starte samtidigt, fordi kontrakten er defineret
- Automatisering — kodegenerering, dokumentation og tests kan udledes af spec’en
Ulemper#
- Kræver disciplin og tid at skrive gode specs
- Kan føles tungt i tidlige, eksperimenterende faser
- Spec og kode kan glide fra hinanden, hvis de ikke vedligeholdes synkront
Eksempler i praksis#
API-udvikling med OpenAPI/Swagger#
Man beskriver alle endpoints, request/response-formater og fejlkoder i en YAML- eller JSON-fil. Derfra kan man auto-generere server-stubs, klientkode og dokumentation. Frontend-udvikleren behøver ikke vente på backend — hun arbejder mod den definerede kontrakt fra dag ét.
gRPC med Protobuf#
Tjenesters interfaces defineres i .proto-filer, som kompileres til kode i mange sprog. Spec’en er kontrakten — der er ingen tvetydighed om, hvad et endpoint returnerer.
Test-Driven Development (TDD)#
Kan ses som en let form for spec-driven development, hvor tests er spec’en — koden skrives for at opfylde dem.
Sammenligning med andre metoder#
| Spec-driven | Code-first | Test-driven (TDD) | |
|---|---|---|---|
| Startpunkt | Formel spec | Koden selv | Fejlende tests |
| Dokumentation | Automatisk/tidlig | Efterfølgende | Via tests |
| Parallelisering | God | Dårlig | Middel |
| Fleksibilitet | Lavere | Højere | Middel |
| Egnet til | Store teams, APIs | Prototyper | Komponentudvikling |
Hvornår giver det mest mening?#
- Projekter med flere teams eller eksterne integrationer
- API-design der eksponeres til tredjepart
- Enterprise-systemer med komplekse krav
- Når kontrakten mellem systemer er vigtigere end implementationsdetaljer
SDD i kontekst af AI-assisteret udvikling#
(Baseret på Birgitta Böckeler, Thoughtworks — martinfowler.com, oktober 2025)
Med fremkomsten af AI-kodningsværktøjer har spec-driven development fået fornyet opmærksomhed. Idéen er, at en velformuleret spec fungerer som fælles kilde til sandhed for både mennesket og AI-agenten — i stedet for at agenten gætter sig frem til, hvad der skal bygges.
De tre niveauer af SDD#
Böckeler identificerer tre implementeringsniveauer, der bygger oven på hinanden:
| Niveau | Beskrivelse |
|---|---|
| Spec-first | En gennemtænkt spec skrives først og bruges i det AI-assisterede udviklingsflow for den konkrete opgave |
| Spec-anchored | Spec’en bevares efter opgaven er løst og bruges løbende til videreudvikling og vedligeholdelse |
| Spec-as-source | Spec’en er det primære artifact over tid — kun spec’en redigeres af mennesket, koden berøres aldrig direkte |
Alle kendte SDD-tilgange er som minimum spec-first, men ikke alle stræber mod spec-anchored eller spec-as-source.
Hvad er en spec?#
En spec er et struktureret, adfærdsorienteret artifact — skrevet i naturligt sprog — der udtrykker softwarefunktionalitet og fungerer som vejledning til AI-kodningsagenter.
Det er nyttigt at skelne mellem to typer kontekstdokumenter:
- Memory bank — generelle kontekstfiler om kodebasen (fx regler, produktbeskrivelse, arkitektur), som er relevante på tværs af alle AI-kodningssessioner
- Specs — dokumenter knyttet til specifikke features eller opgaver, kun relevante når den pågældende funktionalitet oprettes eller ændres
Kritiske observationer#
Én workflow passer ikke alle størrelser Eksisterende værktøjer har tendens til at være for tunge til små opgaver og for lette til store, komplekse features. En lille bugfix kan ende med at generere fire “user stories” med 16 acceptancekriterier.
Review af markdown frem for kode SDD-værktøjer genererer mange, omfattende markdown-filer til review — som kan være mere tidskrævende end blot at reviewe selve koden.
Falsk kontrolfornemmelse Større kontekstvinduer i LLM’er muliggør SDD, men størrelsen alene garanterer ikke, at AI’en følger alle instruktioner. Agenter kan ignorere dele af spec’en eller tolke den forkert og skabe duplikeret kode.
Parallel til Model-Driven Development (MDD)#
Spec-as-source minder om MDD (model-driven development) fra 1990’erne og 2000’erne, hvor modeller (i UML eller DSL’er) var specs, og koden blev genereret fra dem. MDD slog aldrig rigtigt igennem til forretningsapplikationer pga. ufleksibilitet og overhead.
LLM’er fjerner nogle af MDD’s begrænsninger, men introducerer til gengæld ikke-determinisme. Risikoen er at ende med ulemperne fra begge verdener: infleksibilitet og ikke-determinisme.
Konklusion#
Det generelle princip om spec-first er værdifuldt i mange situationer — særligt i projekter med klare interfaces og flere udviklere. Men “spec-driven development” som term er endnu ikke veldefineret og er allerede ved at blive semantisk udvandet: nogle bruger “spec” blot som synonym for “detaljeret prompt”.
Det bedste udgangspunkt er sandsynligvis at starte med spec-first og se, om spec’en holder sin værdi over tid — og først da overveje at investere i spec-anchored eller spec-as-source.
“Design the interface first, then implement it.”