2026-03-20

Spec Driven Development - Ta kontroll over kodeassistent

De siste årene har kodeassistenter drevet av kunstig intelligens (AI) blitt stadig bedre og mer populære. Mange programmere benytter seg nå av AI-assistenter mens de utvikler kode. Disse kan hjelpe deg med alt fra spesifikke forslag på en ny kodelinje, hjelp under feilsøking, eller planlegging og implementering av ny funksjonalitet.

Kodeassistentene har blitt så dyktige at de ofte kan bygge fulle prosjekter basert på et enkelt prompt. Det er tydelig at AI vil spille en sentral rolle innen programmering fremover. Vibe coding er et nytt begrep som beskriver hvordan alle, selv uten spesiell programmeringserfaring, kan bygge enkle applikasjoner i naturlig språk.

"I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works." - Andrej Karpathy

Mange har opplevd suksess med både kodeassistenter og vibe coding, men samtidig dukker det også opp flere historier hvor ting går galt:

Utviklingen går mot tryggere arbeidsflyter. Kodeassistentene har fått dedikerte planleggingsmoduser, og flere og flere utviklere finner egne måter å kontrollere assistentene på. Et eksempel er Boris Tane som tvinger Claude Code til å skrive en detaljert plan før den gjør noen kodeendringer i det hele tatt.

Spec Driven Development (SDD) eller spesifikasjonsdrevet utvikling er en ny metodikk utviklet på toppen av kodeassistenter som sikrer deg mer kontroll, selv i store prosjekter.

I XLENT har vi tatt i bruk SDD i våre AI-assistentdrevne prosjekter. I denne artikkelen viser vi deg noen eksempler på hvordan SDD brukes i praksis.

Spesifikasjonsdrevet utvikling

Spec Driven Development (SDD) har sine aner i NASAs arbeidsmetoder på 1960-tallet, men har nå blitt funnet frem igjen og tilpasset en AI-assistert hverdag. Spesifikasjoner er sentrale i SDD, men metoden er likevel veldig langt unna fossefallmodellen som ble mye brukt i tidlig systemutvikling.

AI-drevet SDD er fortsatt nytt og man får stadig nye erfaringer om hvilken arbeidsform som fungerer best. Likevel er det noen grunnprinsipper de fleste er enige om.

I spesifikasjonsdrevet utvikling jobber du gjennom arbeidssykler med fire grovt definere steg:

Spesifiser
Planlegg
Beskriv oppgaver
Implementer

I praksis kan slike arbeidssykler brukes på både små og store endringer, og du kan til en viss grad iterere frem og tilbake mellom stegene.

Umiddelbart kan dette virke tungvint og unødvendig formelt, men i moderne SDD er det AI som gjør mesteparten av jobben. Gjennom å bruke disse stegene tvinger du assistenten inn i en rutine med flere fordeler:

Spesifikasjonene virker som et minne gjennom hele prosjektet og gjør at AI-assistentene i større grad tar hensyn til hva som er bestemt tidligere i prosjektet.
Planlagte oppgavelister har vist seg å være et effektivt verktøy for å sikre at AI-agenter ikke roter seg bort når de implementerer endringer eller ny funksjonalitet.
Dokumentene som genereres gir deg mulighet til å gripe inn og styre AI-assistentene underveis, slik at endringen blir nærmest mulig slik du ønsker.

I tillegg kan du ta vare på endringsdokumentene og skape en tydelig og lesbar historikk gjennom prosjektet.

Gjennom 2025 dukket det opp flere verktøy for å støtte AI-drevet spesifikasjonsdrevet utvikling:

Kiro fra AWS er et agentisk utviklingsmiljø som inkluderer en VS Code-basert editor, utvidet med vinduer og paneler for SDD.
GitHub Spec Kit er et kommandolinjeverktøy og et malsett som kan integreres inn i ditt eksisterende miljø. Malsettet gir deg nye kommandoer du kan bruke i en SDD arbeidsflyt.
Tessl er et vektøy for håndtering av agent skills and context. Tessl inkluderer en egen pakke for spesifikasjonsdrevet utvikling.
Openspec er et planleggingslag du integrerer inn i ditt eksisterende miljø på samme måte som Spec Kit.

Alle løsningene støtter forskjellige AI-modeller, slik at du fortsetter å bruke dine eksisterende abonnement. Videre i denne artikkelen vil du lære mer om Openspec.

Bli kjent med Openspec

Openspec utvider din eksisterende kodeassistent med ferdigheter som gjør at den kan utføre en SDD-arbeidsflyt. Sammenlignet med tilsvarende verktøy er Openspec mer fleksibelt enn Kiro, og noe mer lettvekt enn Spec Kit. Du bør teste de forskjellige verktøyene for å se hva som passer best for deg, men Openspec er et bra sted å starte.

Openspec er et kommandolinjeverktøy du installerer med Node. Noe av filosofien til prosjektet er at det ikke er veldig strengt i forhold til din arbeidsflyt, samtidig som det holder AI'en i tømmene.

Du kan for eksempel jobbe deg stegvis gjennom de forskjellige endringsdokumentene eller bare be agenten din om å lage alle dokumenter før du begynner å se på dem. Samtidig støtter Openspec både nye greenfield og eksisterende brownfield prosjekter, samt alt fra personlige hobbyprosjekter til større teamprosjekter på jobben.

Openspec integrerer seg inn i miljøet du allerede bruker. Det støtter mange forskjellige verktøy inkludert alle de mest brukte som Claude Code, Cursor, Gemini CLI, GitHub Copilot, Opencode, Windsurf, og så videre. I praksis definerer Openspec nye skills som du aktiverer med slash-kommandoer.

For å bruke Openspec i et prosjekt åpner du en terminal i prosjektkatalogen og skriver:

openspec init

Du blir deretter tatt gjennom et raskt oppsett hvor du forteller hvilket AI-verktøy du bruker i prosjektet. Du kan velge flere verktøy om du vil. Etter at oppsettet er ferdig må du starte AI-verktøyet ditt på nytt for at det skal oppdage de nye kommandoene.

Du kan bruke Openspec i både nye og eksisterende prosjekter.

Start et nytt prosjekt

For å starte et nytt prosjekt trenger du bare å lage en ny katalog og kjøre openspec init som vist over. Skriv gjerne en styringsfil som AGENTS.md i prosjektet. Her kan du fortelle kodeassistenten om prosjektet og dine kodepreferanser.

Deretter åpner du AI-assistenten din på vanlig måte. I dette eksempelet lager du en liten .NET-prototyp på et verktøy som kan hente transkriberinger på YouTube-videoer. For å starte enn SDD-drevet endring gir du en Openspec Propose-kommando.

Avhengig av verktøyet du bruker vil du finne denne som /opsx:propose eller noe lignende. Inkluder et prompt som beskriver endringen:

/opsx:propose init-dotnet-project
Create a new project. The project will use .NET and provide a tool that can transcribe Youtube videos. Initially, you should set up the project folder using best practices. Keep the code as simple as possible. Only implement one feature: the user provides a URL to a video and the tool replies with a transcript. More features will be added later.

I promptet gir du endringen din et navn, init-dotnet-project, og beskriver deretter hva du ønsker at assistenten skal gjøre. I dette eksempelet beskriver du en ganske stor oppgave hvor assistenten skal sette opp en første versjon av programmet. Samtidig legger du klare begrensninger ved å si at den bare skal implementere en kommando.

Når du bruker Openspec sin endringsflyt vil assistenten sette opp fire dokumenter før den begynner med noen kodeendringer:

proposal.md beskriver endringen mer detaljert. Her inkluderes også argumenter for hvorfor du ønsker endringen.
design.md beskriver også endringen, men er mer teknisk enn proposal.md. Her dokumenteres også designavgjørelser som gjøres.
specs skrives i en eller flere filer og beskriver endringen som krav med tilhørende "WHEN ... THEN ..." scenariobeskrivelser.
tasks.md beskriver eksplisitt hvilke endringer som skal gjøres. Det er disse som vil bli utført av kodeassistenten.

For eksempel, promptet ovenfor genererte en design.md fil som starter slik:

## Context

This is a greenfield .NET project creating a command-line tool for YouTube video transcription. The tool accepts a YouTube URL as input and returns the video's transcript as text output. The primary constraint is simplicity - we want a minimal viable implementation that establishes good patterns for future feature additions.

Current state: Empty project directory. No existing code or infrastructure.

## Goals / Non-Goals

**Goals:**
- Create a functional .NET CLI tool that extracts YouTube video transcripts
- Follow .NET best practices for project structure and code organization
- Minimize dependencies and complexity
- Establish a clean foundation for future feature additions
- Provide clear error handling and user feedback

**Non-Goals:**
- Audio transcription (generating transcripts from video audio) - we'll use existing YouTube captions/transcripts
- Video downloading or local processing
- GUI or web interface - CLI only for now
- Support for non-YouTube video platforms
- Advanced features (multiple formats, translation, etc.)

...

Videre går dokumentet gjennom viktige avgjørelser med begrunnelser:

Use the YoutubeExplode library to fetch YouTube transcripts.
Use .NET 8 console application with top-level statements.
Start with a single-project solution.
Accept YouTube URL as command-line argument, output transcript to stdout.

Selv om kodeagenten allerede har utarbeidet et forslag til hvordan den vil gjøre ting, kan du overstyre den der du er uenig. Assistenten har aldri den fulle oversikten over prosjektet, og din jobb er å hjelpe den i riktig retning.

Etterhvert som dokumentene genereres må du lese gjennom dem. Du kan gjøre mindre endringer direkte i dokumentene, mens det ofte er lettere å be AI-assistenten om å gjøre de større endringene, spesielt om de omhandler flere filer.

Merk: Du kan aktivere en mer detaljert arbeidsflyt i Openspec hvor du i stedet for Propose bruker New og Continue for å generere endringsdokumentet stegvis. Skriv openspec config profile for å sette opp hvilke Openspec-kommandoer du vil ha tilgjengelig i prosjektet.

Når du er fornøyd med beskrivelsene ber du AI-assistenten din om å implementere endringen ved å gi en Apply-instruksjon:

/opsx-apply

Etterhvert som AIen fullfører hver enkelt oppgave vil tasks.md bli oppdatert. Du kan da se over prosjektet og sjekke at endringene er som forventet.

Til slutt avslutter du oppgaven med Archive, /opsx-archive. Å arkivere endringene er viktig av flere grunner:

Endringsdokumentene flyttes til en archive/ katalog slik at de ikke "roter til" arbeidskatalogen din hvor du skal jobbe med nye endringer.
Endringen får status som ferdig, slik at AI-assistenten ikke må spørre om den skal fortsette å jobbe med denne.
Spesifikasjonene for endringen blir integrert inn i prosjektspesifikasjonene.

Det siste punktet er sentralt for den langsiktige styringen av prosjektet.

Gjør endringer i et eksisterende prosjekt

Ovenfor så du hvordan du starter, utfører, og avslutter en endring med Openspec. Denne arbeidsflyten er lik, uansett om du starter et nytt prosjekt eller tar Openspec inn i et eksisterende prosjekt.

Før du starter din første Openspec-endring i et eksisterende prosjekt bør du bruke litt tid på å gjøre AI-assistenten din kjent med prosjektet. De fleste verktøy har en /init-kommando som ber assistenten se gjennom prosjektet og lagre informasjon om kodestil, testing, brukte pakker, og så videre i en Markdownfil.

En viktig vurdering når du bruker Openspec er hvor store endringer du gjør om gangen. Her er det ikke noe fasitsvar. I stedet bør du teste litt på egenhånd og bygge egne erfaringer. Vær bevisst på følgende:

For at Openspec skal gi deg den nødvendige kontrollen må du se nøye gjennom alle endringene. Dette blir nødvendigvis en større jobb, jo større endringene er.
Forskjellige språkmodeller og AI-assistenter har ulike grenser for hvor mye de håndterer før de begynner å rote.

En nyttig mental modell er å koble sammen en Openspec-endring med endringer du vanligvis gjør i en Git feature branch eller en pull request. God praksis i begge tilfeller er å holde disse fokusert til noe som er lett å beskrive.

En Openspeckommando som blir nyttigere etterhvert som prosjektet vokser er Explore. Med /opsx:explore starter du en endring med en diskusjon med kodeassistenten hvor dere sammen utvikler kontekst for hva som skal bygges. Denne går ofte naturlig over i dokumentasjonsfasen som du har sett tidligere.

Konklusjon

Openspec er et av flere verktøy for å drive spesifikasjonsdrevet utvikling med AI-assistenter. De fleste verktøyene bygger opp under en arbeidsflyt hvor du og kodeassistenten din først setter opp spesifikasjoner. Kodeendringer blir ofte et mindre steg etter at planleggingen er ferdig.

Med SDD beholder du oversikten i prosjektene dine, og du står bedre rustet mot feil som AI-er vil gjøre. Samtidig er heller ikke spesifikasjonsdrevet utvikling et gullegg som løser alle problemer. Noen punkter du bør være oppmerksom på:

Både SDD og verktøyene er nye og til dels umodne. Utviklingen raser fremover og nye best practices blir stadig etablert. Følg med og oppdater både Openspec og assistentverktøyet ditt.
De ekstra stegene i SDD bruker også tokens. Du vil merke at enkeltendringer koster flere tokens enn tilsvarende vibe-kodete endringer.

I XLENT bygger vi stadig mer erfaring med bruk av spesifikasjonsdrevet utvikling i både små og store prosjekter. Kontakt oss for mer informasjon.