Vad är specdriven utveckling? Specen som sanningens källa

Specen som källa till sanningen, inte ett sidodokument.

Sidinnehåll

Specdriven utveckling är en av de idéer som mjukvarutekniker har vänt sig till tidigare och sedan lagt åt sidan när insatsen inte längre gav avkastning.

Det som förändrades 2025 är att AI-kodningsagenter kom fram och gjorde frånvaron av explicit intention dyrbar. Prompts är förbigripna. Agentsessioner nollställs. Koden ändras men resonemanget bakom den försvinner. Specifikationen är den artefakt som förhindrar att detta händer.

Vad är specdriven utveckling – specen som källa till sanning för AI-kodning

Specen blir källan till sanning

Under större delen av mjukvaroutvecklingens historia var specifikationen antingen en tillfällig planeringsartefakt eller ett eftertanke. Krav levde i ärenden, arkitekturella beslut levde i chatttrådar, och koden var den faktiska sanningen. Dokumentation beskrev vad som existerade i efterhand.

Specdriven utveckling inverterar detta förhållande. Specifikationen blir den primära artefakten. Koden är det som genereras eller verifieras mot specen, inte tvärtom.

Detta är inte en ny idé. Formella metoder, design-by-contract och BDD innehåller alla versioner av detta. Det som är nytt är den praktiska motivationen: AI-kodningsagenter behöver explicit, hållbar kontext för att producera korrekt och konsekvent output. Prompts är för förbigripna. Specen är den enda artefakt som kan bära intention över agentsessioner, över teammedlemmar och över tid.

Vad specdriven utveckling faktiskt betyder

Specdriven utveckling, oftast förkortat till SDD, är ett arbetsflöde där en versionerad specifikation styr eller genererar implementering. Specifikationen skrivs och granskas innan agenten skriver kod. Den fångar:

  • Vad som ska byggas – användarproblem, mål och icke-mål
  • Vad korrekt beteende ser ut – acceptanskriterier, grannfall, felstater
  • Hur det ska byggas – arkitekturella beslut, datamodell, API-avtal, säkerhetsbegränsningar
  • Hur det ska verifieras – teststrategi, valideringsregler, spårbarhet tillbaka till kraven

Specen är inte ett engångsdocument. Den uppdateras när verkligheten skiljer sig från designen. När agenten upptäcker något under implementeringen som specen fick fel, korrigeras specen innan fortsättningen. Specen förblir ärlig eftersom den behandlas som kod.

Nyligen publicerad akademisk forskning formaliserar denna ram: forskare beskriver SDD som att behandla specifikationer som källan till sanning och kod som genererad eller verifierad mot dem. Den praktiska tolkningen är att specen är den granskade, hållbara posten av intention som både människor och AI-verktyg kan läsa och lita på.

Tre termer fångar olika punkter på spektrumet för specanvändning:

Spec-först betyder att skriva hela specifikationen innan någon implementering påbörjas. Detta är den strängaste tolkningen och den som ligger närmast vattenfallsmodellen om den inte utförs med omsorg.

Spec-ankryrd innebär att hålla en specifikation synkroniserad med implementeringen under hela funktionens livscykel. Specen uppdateras när besluten ändras. Detta är den mest praktiska versionen för de flesta team.

Spec- som-källa innebär att generera eller validera implementering från specen, antingen genom AI-agenter eller genom verktyg som kontrollerar koden mot specbegränsningar. Detta är den riktning som verktyg som GitHub Spec Kit och Kiro rör sig mot.

Varför SDD är viktig nu

Det ärliga svaret är att SDD inte är attraktiv för en ensam utvecklare som bygger ett skript på en dag. Överhuvudet är inte värt det.

SDD blir värdefull när tre förhållanden är närvarande: funktionen är tillräckligt stor för att sträcka sig över flera sessioner, agenten behöver fatta beslut som påverkar arkitekturen, och arbetet kommer att granskas eller fortsättas av någon annan.

Alla tre förhållanden blir allt vanligare med AI-assisterad utveckling.

LLM:er behöver kontext, inte bara prompts. En modell som får en vag prompt fattar vaga beslut. En modell som får en granskad specifikation med explicita begränsningar, icke-mål och acceptanskriterier fattar bättre beslut och är lättare att korrigera när den avviker. Detta kopplar till hur hämtning och representation fungerar: att ge en agent en versionerad spec är en form av strukturerad hämtning av projektintention.

Kodgenerering är billigt; att bestämma vad som ska byggas är fortfarande svårt. Flaschhalsen i AI-assisterad utveckling är inte längre skrivning – det är att veta vad som ska byggas och hur man begränsar agenten. SDD flyttar insatsen dit den betyder något: att specificera intention tydligt innan genereringen börjar.

Prompts är förbigripna. Agenten minns inte vad du sa till den i förra sessionen. En versionerad specifikation lagrad i förlaget gör det. Varje ny session kan läsa samma spec och implementera mot samma intention utan att återigen etablera kontext från scratch.

Vibe coding fungerar tills det inte gör det. För prototyper och engångsarbete är ad-hoc-promptning snabbare och lämplig. Så snart en funktion kräver säkerhetsbegränsningar, arkitekturella beslut över flera filer, eller en överlämning till ett team, blir frånvaron av en spec den huvudsakliga källan till drift och defekter. Se jämförelsen i SDD vs Vibe Coding för när varje approach passar.

Kernartefakter

En praktisk SDD-arbetsflöde producerar fyra huvudartefakter. Varje en minskar en specifik typ av tveksamhet innan den når agenten.

Kravspecifikation. Problemformuleringen, de påverkade användarna, målen, de explicita icke-målen och acceptanskriterierna. Icke-mål är lika viktiga som mål – de berättar för agenten vad den inte ska bygga och förhindrar scope creep. Acceptanskriterierna är tillräckligt precisa så att varje en mappar till minst ett test.

Designspecifikation. De arkitekturella besluten relevanta för denna funktion: påverkade moduler, ändringar i datamodellen, API-avtal, migrationer, säkerhetsbegränsningar, observabilitetskrav och kända felmoder. Detta är inte ett fullständigt systemdesign-dokument – det är den del av arkitekturella besluten som behövs för att implementera denna funktion korrekt.

Aktivitetsplan. En sekvens av små implementeringsuppgifter, var och en med explicita beroenden, förväntade filändringar och valideringskriterier. Uppgifterna är små nog att implementera i en enda agentsession och verifiera med en fokuserad diff. Varje uppgift har en mänsklig granskningspunkt.

Spårbarhetspost. En mappning från acceptanskriterier till tester, från arkitekturella beslut till påverkade filer, och från uppgifter till commits. Detta är det som skiljer SDD från dokumentation som blir föråldrad: spårbarhet gör det möjligt att verifiera att specen faktiskt implementerades, inte bara skrevs.

Dessa artefakter behöver inte vara tunga. En enkel funktion kan producera ett enda tvåsidigt markdown-dokument som täcker alla fyra områden. Formatet spelar mindre roll än vanan att skriva ner intention innan implementeringen börjar.

Hur SDD skiljer sig från dokumentation

Den vanligaste förvirringen är att behandla SDD-artefakter som dokumentation. De är inte dokumentation i konventionell mening.

Dokumentation beskriver. Den berättar för dig vad systemet gör, hur man använder det och vad det innehåller. Den skrivs i efterhand och uppdateras när systemet ändras.

Specar begränsar. En spec berättar för agenten vad den har rätt att bygga och vad den inte har rätt att göra. Den är auktoritativ innan implementeringen börjar. Den valideras efter att implementeringen är klar. En spec som beskriver vad som faktiskt byggdes – snarare än att begränsa vad som bör byggas – har redan misslyckats med sitt syfte.

Exekutabla specar styr generering och validering. De bästa SDD-specarna är tillräckligt nära maskinläsbara så att en agent kan implementera mot dem och en testsvit kan verifiera dem. Acceptanskriterier skrivna som “ändpunkten måste avvisa oautentiserade förfrågningar med ett 401-svar” är en exekutabel spec; “ändpunkten är säker” är dokumentation.

Beslutsprotokoll – ADR:er, PDR:er och DDR:er – är komplementära till SDD-artefakter men tjänar ett annat syfte. Beslutsprotokoll fångar varför ett val gjordes och vad som avvisades. SDD-specifikationer fångar vad som ska byggas och hur det ska verifieras. Båda hör hemma i förlaget. Tillsammans ger de AI-agenter den fulla bilden: den aktuella intentionen och resonemanget bakom den.

Hur SDD skiljer sig från TDD

Testdriven utveckling och specdriven utveckling förväxlas ofta eftersom båda producerar explicita artefakter innan kod existerar. Skillnaden är startpunkten.

TDD börjar med tester. Du skriver ett misslyckat test som beskriver beteendet du vill ha, och skriver sedan den minimala koden för att få det att passera. TDD är en återkopplingsslinga på enhetsnivå. Den producerar bra tester men besvarar inte frågan om du bygger rätt sak.

SDD börjar med intention. Innan tester existerar, innan arkitekturen är beslutad, besvarar specen: vem har detta problem, vad ser korrekt beteende ut, vad är explicit utanför scope. Specen informerar sedan vilka tester som ska skrivas, vilket är varför bra SDD och bra TDD är komplementära snarare än konkurrerande.

Ett praktiskt sätt att tänka på det: SDD driver TDD. Acceptanskriterierna i specen blir testscenarierna. Designspecen identifierar integrationsgränserna som behöver kontraktstester. Aktivitetsplanen identifierar vilka enhetsbeteenden som behöver testtäckning innan agenten implementerar dem.

Hur SDD skiljer sig från BDD

Beteendedriven utveckling använder naturligspråksscenarier – vanligtvis i Gherkin-format – för att beskriva förväntat beteende från användarens perspektiv. Dessa scenarier brygger gapet mellan affärsintention och teknisk implementering.

SDD är bredare. Den inkluderar beteendebeskrivningar (som kan använda BDD-språk eller vanlig prosa) men täcker också arkitekturella beslut, datamodeller, säkerhetsbegränsningar, aktivitetsplanering och spårbarhet. BDD kan vara ett användbart format för att skriva acceptanskriterier inuti en SDD-kravspecifikation. Specen är behållaren; BDD-scenarier är ett sätt att skriva vad som går in i den.

Distinktionen betyder i praktiken: BDD-verktyg fokuserar på att göra scenarier exekutabla. SDD-praxis fokuserar på att göra intention hållbar – över verktyg, över sessioner och över teammedlemmar.

Hur SDD skiljer sig från formella metoder

Formella metoder använder matematisk notation och automatisk verifiering för att bevisa egenskaper hos mjukvarusystem. De är extremt rigorösa och extremt dyra för de flesta produktionsutvecklingskontexter.

SDD kräver inte formell notation. En markdown-fil med acceptanskriterier och arkitekturella beslut är en specifikation. Den begränsar utan att vara matematiskt formell. Nivån av rigor skaleras med vad som står på spel: en spec för en fakturerings tjänst bör vara mer precis och noggrannare granskad än en spec för en dokumentationsida.

Relationen är ett spektrum:

  • Informell prosaspec (minst möjliga SDD)
  • Strukturerad markdown med acceptanskriterier och icke-mål
  • Maskinläsbar spec med schemavalidering
  • Kontraktstester härledda direkt från specen
  • Formell spec med automatisk bevis

De flesta team opererar i mitten av detta spektrum. Målet är inte matematisk rigor – det är att göra intention explicit nog så att en AI-agent kan implementera mot den och en mänsklig granskare kan verifiera resultatet.

Fördelar med specdriven utveckling

Mindre intentionsdrift. Specen är referensen. När agenten drifter – och den kommer att göra det – har granskaren något att jämföra implementeringen mot. Utan en spec är drift osynlig tills något går sönder.

Bättre AI-output. Agenter som får explicita begränsningar, icke-mål och acceptanskriterier producerar implementeringar som ligger närmare det som var avsett och är lättare att korrigera när de missar. Kontextkvalitet bestämmer direkt outputkvalitet.

Enklare granskning. En pull request kopplad till en spec är lättare att granska än en pull request som kräver att granskaren rekonstruerar intentionen från koden. Specen är granskningschecklistan.

Teamöverensstämning. När flera personer eller agenter arbetar på samma funktion är specen det delade avtalet. Utan den optimerar varje bidragande lokalt och delarna kanske inte passar ihop.

Bättre testplanering. Acceptanskriterier i specen mappar direkt till testfall. Testtäckning blir en fråga om spektäckning: täcks varje acceptanskriterium av minst ett test?

Hållbar överlämning. När en funktion byter händer – mellan ingenjörer, mellan agentsessioner, mellan sprintar – är specen överlämningsartefakten. Den fångar vad som besluts, vad som var utanför scope, och vad som återstår att validera.

Kostnader med specdriven utveckling

Insats i förväg. Att skriva en bra spec innan man skriver någon kod tar tid. För små funktioner är denna overhead verklig och ibland inte värd det.

Falsk trygghet. En spec som existerar men inte valideras mot implementeringen ger en falsk känsla av korrekthet. Föråldrade specar är ibland sämre än ingen spec: de missledde granskare och agenter som läser dem.

Föråldrade specar. Specar drifter när teamet behandlar dem som planeringsartefakter snarare än levande dokument. Att uppdatera specen när implementeringen skiljer sig från designen är inte valfritt – det är det som skiljer SDD från dokumentation som ackumuleras och ruttnar.

Genererad byråkrati. AI-agenter kan generera uttömmande aktivitetslistor och verbala specifikationer snabbt. En 200-uppgifts spec genererad på trettio sekunder är inte en användbar spec – det är en byråkratigenerator. Bra SDD kräver bedömning om vad som ska specificeras och vad som ska lämnas implicit.

Verktygsbindning. Vissa SDD-verktyg är åsiktsfulla gällande format, filstruktur och arbetsflöde. En spec skriven i ett proprietärt format är svårare att bära över verktyg än en markdown-fil med tydliga rubriker och acceptanskriterier.

Slutsats

Specdriven utveckling är inte en ny metodik. Det är en gammal disciplin som blir praktisk igen eftersom kostnaden för implicit intention nu är synlig i AI-genererad kod.

Disciplinen är enkel: skriv ner vad du avser att bygga, granskat och versionerat, innan agenten bygger det. Håll den posten ärlig genom att uppdatera den när verkligheten skiljer sig. Använd den som referens för granskning, testning och överlämning.

Specen är inte magi. En spec som inte valideras blir den dyraste typen av dokumentation: en som missleder med självförtroende. Bra SDD är praxisen att hålla specar ärliga – tillräckligt små för att underhålla, tillräckligt precisa för att begränsa, och tillräckligt hållbara för att överleva varje enskild agentsession.

SDD sitter vid skärningspunkten mellan dokumentationspraxis, testarkitektur och koddesign – allt täckt i App Arkitektur i Produktion-klustret tillsammans med beslutsprotokoll, API-design och dataåtkomstmönster.

Användbara länkar

Prenumerera

Få nya inlägg om system, infrastruktur och AI-ingenjörskonst.