Spec-Driven Development

Hvad er spec-driven development?

Spec-driven development (SDD) er en metode hvor du skriver en præcis specifikation, og en AI-agent implementerer koden ud fra den. Specifikationen, ikke koden, er kilden til sandhed. I stedet for at bruge tiden på at skrive kode bruger du den på at beskrive nøjagtigt hvad koden skal gøre, og lader agenten om resten.

Ideen er ikke ny. Vi har altid skrevet kravspecifikationer. Det nye er at AI-agenter nu er gode nok til at en velskrevet specifikation faktisk kan oversættes til fungerende kode med begrænset indgriben. Det flytter tyngdepunktet i udviklingsarbejdet fra implementering til præcisering.

Hvorfor det virker

De fleste dårlige resultater med AI-kodning skyldes ikke at modellen er dum, men at den er underspecificeret. Du beder om noget vagt, og modellen gætter. En god specifikation fjerner gætteriet.

1. Præcision slår volumen. En klar specifikation med acceptkriterier giver bedre kode end ti runder af “ikke helt, prøv igen.”
2. Specifikationen er genbrugelig. Den dokumenterer hvad systemet skal gøre, længe efter koden er skrevet.
3. Den tvinger dig til at tænke først. At skrive specifikationen afslører huller i din egen forståelse før de bliver til bugs.

Spec-driven vs. test-driven development

Spec-driven development minder om test-driven development (TDD), men opererer et niveau højere.

1. TDD: du skriver testene først, og koden skal få dem til at passe.
2. SDD: du skriver specifikationen først, og agenten skal implementere den. Tests bliver typisk udledt af specifikationen.

De to udelukker ikke hinanden. En god specifikation indeholder ofte acceptkriterier der direkte bliver til tests.

Spec Kit og værktøjer

GitHub udgav i september 2025 et open source-værktøj kaldet Spec Kit til spec-driven development. Det strukturerer arbejdsgangen i faste trin. Kommandonavnene har skiftet mellem versioner. I dag hedder de fx /speckit-specify, og der er kommet ekstra trin som clarify, analyze og implement til:

1. Constitution. En fil med projektets overordnede principper og ufravigelige regler.
2. /specify. Du beskriver hvad du vil bygge, og værktøjet hjælper med at gøre specifikationen præcis, ofte ved at stille opklarende spørgsmål.
3. /plan. Specifikationen omsættes til en teknisk plan.
4. /tasks. Planen brydes ned i konkrete opgaver en agent kan arbejde igennem en ad gangen.

Mønsteret findes også i andre værktøjer og kan laves manuelt med en PRD og en god agent.

Compound engineering som en form for SDD

Compound engineering er en beslægtet metode der bygger på samme grundtanke: du investerer i en præcis beskrivelse op front, så agenten kan udføre arbejdet pålideligt. Forskellen er at compound engineering går et skridt videre. Hver opgave skal ikke bare løses, den skal også gøre den næste opgave lettere ved at efterlade specifikationer, tests og dokumentation som agenten kan bygge videre på.

Hvor klassisk spec-driven development handler om én specifikation til én feature, handler compound engineering om at opbygge en voksende base af specifikationer og kontekst der gør hele systemet mere produktivt over tid. Læs den praktiske gennemgang i guiden Compound Engineering.

Hvornår spec-driven development giver mening

1. Velafgrænsede problemer. Compilere, parsere, API’er og protokoller med klare regler er ideelle. Specifikationen kan være næsten komplet.
2. Greenfield-udvikling. Nye projekter uden arv af eksisterende kode er lettere at specificere rent.
3. Reverse engineering. Når du genskaber et kendt system eller en kendt API, er specifikationen allerede delvist givet.

Til løst defineret eksplorativt arbejde, hvor du selv opdager kravene undervejs, er vibe coding ofte hurtigere. Spec-driven development betaler sig når kravene kan gøres præcise.