Slik setter du opp Spec Kit i Claude Code i 2026: Spesifikasjoner i stedet for ledetekster

Hva skjedde med vibe-koding i mai 2026?#

Et år senere, 4. februar 2026, publiserte han en retrospektiv tråd:

I foredraget sitt på Sequoia Ascent 2026 uttrykte han det enda mer presist: «Vibe-koding løfter gulvet – hvor mye alle kan gjøre innen programvare. Agentisk utvikling bevarer taket – kvalitetsnivået i profesjonell utvikling.» På samme scene kom han med en formulering som gikk inn i bransjens vokabular: «Du kan ikke innføre sårbarheter på grunn av vibe-koding. Du er fortsatt ansvarlig for programvaren din, som før.»

To ting skjedde samtidig. I september 2025 publiserte GitHub verktøyet Spec Kit – det samlet 107 000 stjerner på 8 måneder. I februar 2026 publiserte AWS en detaljert casestudie om legemiddeloppdagelse som rapporterte «95 % av forretningslogikken generert fra spesifikasjonen, med en besparelse på over 80 timer».

Ved utgangen av mai 2026 hadde det dannet seg enighet i det engelskspråklige informasjonsrommet: vibe-koding som arbeidsmetode er nybegynnernivået. Deretter kommer Spec-Driven Development. Denne veiledningen forklarer hvordan du installerer og bruker tilnærmingen.

Hva er Spec Kit og Spec-Driven Development?#

Kjernen i metodikken oppsummeres i én setning fra GitHubs offisielle dokumentasjon:

I praksis utspiller dette seg i 4 faser (Spec Kit legger til én til, en fase null – konstitusjonen, beskrevet nedenfor):

1. Specify – skriv en spesifikasjon av hva du ønsker, på naturlig språk. HVA som skal gjøres og HVORFOR. Ikke HVORDAN.
2. Plan – agenten tar spesifikasjonen og setter sammen en teknisk plan: hvilke teknologier, hvilken arkitektur og hvilke komponenter.
3. Tasks – agenten deler planen opp i konkrete, verifiserbare oppgaver med avhengigheter.
4. Implement – agenten (eller underagentene) arbeider seg gjennom oppgavene og skriver koden.

Etter Implement har den nåværende versjonen av Spec Kit et verifiseringstrinn kalt Converge: agenten kontrollerer den ferdige koden mot spesifikasjonen, planen og oppgavene, og legger deretter til det som mangler i tasks.md. Kjør Implement og Converge i en løkke til Converge svarer «Converged».

Hver fase er en egen Markdown-fil i repoet. Hver fase er en egen skråstrekkommando i Claude Code: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, mens kontrollen er /speckit-converge. Spec Kit-dokumentasjonen skriver de samme kommandoene med punktum (/speckit.specify), men i Claude Code installerer Spec Kit dem som ferdigheter, og de kalles med bindestrek. Hvis noe går galt i et trinn, redigerer du Markdown-filen og kjører neste fase på nytt.

Spec Kit er en konkret implementering av SDD. I mai 2026 hadde det allerede over 30 integrasjoner med ulike AI-agenter. I ett repo fungerer Spec Kit på samme måte med Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose og et dusin andre.

Etter en kjøring inneholder repoet altså ikke bare kode, men også spesifikasjonen, planen og oppgavene. En måned senere kan du gå tilbake til prosjektet, lese spec.md og forstå hva som ble gjort og hvorfor. Dette er ikke lenger «vibe-koding, der man glemmer at koden finnes» – det er prosjektets arbeidsminne.

Hvorfor trenger en vibe-koder som ikke skriver kode dette?#

Spec Kit formaliserer planlegging på separate trinn med 4 skråstrekkommandoer. Logikken er den samme: skill «å tenke det gjennom» fra «å implementere det», slik at de skjer i ulike kontekstvinduer. Hvert trinn får en ren kontekst som ikke er rotet til av den forrige fasen.

Tre konkrete fordeler for en vibe-koder:

• Forutsigbarhet. Når du sier til agenten «lag et registreringsskjema med e-postbekreftelse», gjetter den 10 detaljer på egen hånd – og tar feil på tre av dem sammenlignet med det du hadde sett for deg. Med en spec.md som inneholder User Stories, Acceptance Scenarios og [NEEDS CLARIFICATION]-markører ved hvert usikre punkt, er det ingenting å gjette.
• Prosjektminne. En måned senere husker du ikke hva du diskuterte med agenten i chatten. Men spec.md, plan.md og tasks.md ligger i repoet, i mappen specs/###-feature/ sammen med koden. De viser deg ikke bare hva som ble gjort, men også hvorfor.
• Skalering. For en funksjon som omfatter 1–2 filer, er forskjellen knapt merkbar. For en funksjon som omfatter 20 filer og 5 dataentiteter, er forskjellen mellom «å skrive om alt etter 4 timer» og «alt er kommet inn i hovedgrenen etter 4 timer». AWS Kiro viste 95 % automatisering av forretningslogikk fra en spesifikasjon i TargetID-prosjektet.

Den største illusjonen ved vibe-koding er at det ser raskere ut i starten. En halvtime, og du har en prototype. Men etter én uke går prototypen i stykker, og det er enklere å kaste den. Spec-Driven Development tar litt lengre tid i starten (en time i stedet for en halvtime), men en uke senere arbeider du fortsatt i det samme repoet.

Slik installerer du Spec Kit i Claude Code (4 trinn)#

Trinn 1. Installer uv. Du trenger bare å gjøre dette én gang; det blir værende på systemet ditt.

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Kontroller at uv ble installert:

uv --version

Trinn 2. Installer Spec Kit. Én kommando:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Kontroller:

specify --version

Trinn 3. Initialiser repoet. Gå til prosjektmappen din (eller opprett en ny) og kjør:

specify init --here --integration claude

Flagget --integration claude velger Claude Code direkte. Uten det ber Spec Kit deg velge en agent fra en interaktiv liste, og kan også spørre om skripttype (for macOS og Linux lar du den stå som sh). Hvis mappen ikke er tom, varsler Spec Kit om at filene vil bli slått sammen med dine: lagre arbeidet ditt først, og kjør deretter kommandoen på nytt med flagget --force.

Etterpå vises følgende i repoet:

.specify/
  memory/
    constitution.md        # prosjektregler, fylles ut av /speckit-constitution
  scripts/
  templates/
    spec-template.md
    plan-template.md
    tasks-template.md
.claude/
  skills/
    speckit-constitution/SKILL.md
    speckit-specify/SKILL.md
    speckit-clarify/SKILL.md
    speckit-plan/SKILL.md
    speckit-checklist/SKILL.md
    speckit-tasks/SKILL.md
    speckit-analyze/SKILL.md
    speckit-implement/SKILL.md
    speckit-converge/SKILL.md
    speckit-taskstoissues/SKILL.md

Trinn 4. Åpne Claude Code og kontroller skråstrekkommandoene. Kjør dette i samme mappe:

claude

Skriv /speckit i økten – speckit-*-kommandoene skal vises i forslagene. Hvis de ikke gjør det, starter du Claude Code på nytt slik at det leser .claude/skills/ på nytt. Hvis du allerede har CLAUDE.md i prosjektroten, lar Spec Kit den være i fred – det fungerer sammen med den, i .specify/memory/constitution.md.

Spec Kit fungerer også uten Claude Code (det støtter over 30 agenter), men denne veiledningen dekker oppsettet spesifikt med Claude. Hvis du vil installere to verktøy med én gang, kan du se de separate veiledningene om å sette opp CLAUDE.md og Plan Mode i Claude Code.

Spec Kit er den første byggesteinen i en «arbeidsavtale for agenter». Det komplette oppsettet omfatter alle tre: en AI-klone (metodikken din i form av Skills og underagenter), en Second Brain (strukturen business/ som agenten vender tilbake til hver gang), og kontekstutvikling (Spec Kit, Plan Mode, /compact). Dette er de tre søylene AI hallusinerer uten.

Slik skriver du din første spesifikasjon (Specify)#

Skriv følgende i Claude Code:

/speckit-specify

Deretter ber agenten om en beskrivelse av funksjonen. På dette trinnet bruker du dagligspråk uten teknisk sjargong:

Jeg vil ha et registreringsskjema i appen min. Brukeren skriver inn en e-postadresse
og et passord, mottar en bekreftelses-e-post og havner på kontrollpanelet etter bekreftelse. Bekreftelse utløper etter 48 timer.
Er e-posten fortsatt ubekreftet, slettes kontoen senest 5 minutter etter
fristen. En bekreftet konto må aldri slettes.

I dette illustrerende eksemplet er slettetoleransen avklart til 5 minutter etter 48-timersfristen. For reelt produkt bekrefter du toleransen før Plan. Eksakt 48-timersfrist krever design og tester som håndhever det strengere kravet. Agenten setter sammen specs/001-registration/spec.md. Åpne den for en struktur som denne:

# Funksjonsspesifikasjon: Brukerregistrering

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "I want a registration form..."

## User Scenarios & Testing *(obligatorisk)*

### Primary User Story
Som ny bruker vil jeg registrere en konto med e-postbekreftelse,
slik at jeg kan få tilgang til kontrollpanelet med en bekreftet identitet.

### Acceptance Scenarios
1. **Given** at jeg er på registreringssiden,
   **When** jeg sender inn en gyldig e-postadresse og et gyldig passord,
   **Then** mottar jeg en bekreftelses-e-post innen 1 minutt.
2. **Given** at jeg klikket på bekreftelseslenken innen 48 timer,
   **When** jeg kommer til kontrollpanelet,
   **Then** ser jeg at e-postadressen min er bekreftet i profilen.
3. **Given** at jeg ikke har bekreftet ved 48-timersfristen,
   **When** opprydding kjører innen de neste 5 minuttene,
   **Then** slettes kontoen og e-postadressen frigis for ny registrering.
4. **Given** at kontoen er like under 48 timer gammel eller allerede bekreftet,
   **When** opprydding kjører,
   **Then** slettes kontoen ikke.

## Requirements *(obligatorisk)*

### Functional Requirements
- **FR-001**: Systemet MÅ godta registrering med [NEEDS CLARIFICATION:
  bare e-post/passord, eller også SSO/OAuth?]
- **FR-002**: Systemet MÅ sende bekreftelses-e-post innen 60 sekunder
- **FR-003**: Bekreftelse MÅ utløpe etter 48 timer. Systemet MÅ slette
  fortsatt ubekreftede kontoer senest 5 minutter etter fristen og MÅ IKKE
  slette bekreftede kontoer
- **FR-004**: Systemet MÅ logge alle registreringsforsøk i [NEEDS
  CLARIFICATION: hvor lenge beholder vi logger – 30 dager, 90 dager, for alltid?]

### Key Entities
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## Success Criteria *(obligatorisk)*
- **SC-001**: 95 % av bekreftelses-e-postene leveres innen 60 sekunder (p95)
- **SC-002**: 0 utilsiktede slettinger av bekreftede kontoer
- **SC-004**: Ingen sletting før 48 timer. Alle kvalifiserte ubekreftede
  kontoer slettes innen alder 48 timer 5 minutter under testet arbeidsmengde
- **SC-003**: Fullføringsgrad for registrering > 60 % (fra åpnet skjema til kontrollpanel)

Legg merke til [NEEDS CLARIFICATION: ...]-markørene. Spec Kit setter dem bevisst inn der agenten ikke fikk et entydig svar fra teksten din. Før du går videre til Plan-fasen, må du enten svare på dem manuelt i spec.md eller kjøre /speckit-clarify, så går agenten gjennom de uklare punktene og stiller spørsmål i dialogen.

I Spec Kit erstatter den innebygde kommandoen /speckit-clarify det muntlige «still meg spørsmål». Effekten er den samme: du går ikke videre til Plan før det ikke finnes noen [NEEDS CLARIFICATION]-markører igjen i spec.md.

Det skal ikke stå teknologier i spec.md. Ingen omtale av React, Postgres, Prisma eller Redis. Spesifikasjonen beskriver hva systemet gjør sett fra brukerens og virksomhetens perspektiv. Teknologistakken kommer i neste fase.

Hva gjør Claude i Plan-fasen?#

Når spec.md er klar, kjører du:

/speckit-plan

Du kan eventuelt sende teknologitips direkte i kommandoen:

/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email

Claude leser tre kilder: spec.md, CLAUDE.md (eller memory/constitution.md) og den eksisterende koden i repoet. Resultatet er en plan.md med en struktur omtrent som denne:

# Implementeringsplan: Brukerregistrering

## Teknisk kontekst
- Rammeverk: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- E-post: Resend (én transport)
- Validering: Zod-skjema i felles lib
- Autentisering: NextAuth.js med legitimasjonsleverandør

## Arkitekturbeslutninger

### 1. Lagring av token
Token lagres i DB (tabellen ConfirmationToken), ikke i JWT.
Årsak: vi trenger tilbakekalling på serversiden ved ny e-postregistrering.

### 2. E-postlevering
Asynkront via cron `/api/cron/send-confirmation`, utløst umiddelbart
etter registrering. Resend håndterer nye forsøk.

### 3. Automatisk slettejobb
Kjør `/api/cron/cleanup-unconfirmed` hvert minutt. Slett bare rader der
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
Det avklarte eksemplet tillater høyst 5 minutters sletteforsinkelse.
Verifiser planleggerforsinkelse og fullføringstid mot grensen. Rapporter
overskridelse som feil, ikke som vellykket daglig opprydding.

## Datamodell
Se data-model.md

## API-kontrakter
Se contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## Implementeringsfaser
1. Databasemigrering (Prisma-skjema + migreringsfil)
2. API-ruter (3 endepunkter)
3. Grensesnitt: registreringsskjema + side for bekreftelse
4. Cron-jobber (sending + opprydding)
5. E-postmal
6. Integrasjonstester

data-model.md beskriver entitetene og forholdene mellom dem. contracts/ inneholder utkast til API-kontrakter (enten OpenAPI YAML eller TypeScript-forespørsels-/svar-typer). Dette er ikke kode – det er en hensikt Claude senere skal omsette til faktiske ruter.

Den største fordelen med Plan-fasen er ren kontekst. Claude forsøker ikke å ha både spesifikasjonen og implementeringen i tankene samtidig. Først tenker den gjennom løsningen, registrerer avgjørelsen i en fil og går deretter videre.

Deretter finnes den valgfrie kommandoen /speckit-analyze. Den kjøres etter Tasks-fasen og før Implement: den gjennomgår settet spec.md + plan.md + tasks.md for motsetninger og kontrollerer om alle spesifikasjonskravene dekkes av planen og oppgavene. Den redigerer ikke filer; den lager bare en rapport. I praksis er det en formell rimelighetskontroll før implementering.

Slik deler du arbeidet opp i oppgaver (Tasks)#

Når du har spec.md og plan.md, kjører du:

/speckit-tasks

Claude utvider planen til tasks.md:

# Oppgaver: Brukerregistrering

## Fase 1: Database (ingen avhengigheter)
- [ ] T-001: Legg til User-modellen i prisma/schema.prisma (kan kjøres parallelt)
- [ ] T-002: Legg til ConfirmationToken-modellen i prisma/schema.prisma (etter T-001)
- [ ] T-003: Generer migreringen `add-user-registration` (etter T-002)

## Fase 2: API-kontrakter (ingen avhengigheter)
- [ ] T-004: Opprett Zod-skjemaer i shared/validation/auth.ts
- [ ] T-005: Definer TypeScript-typer i shared/types/auth.ts (etter T-004)

## Fase 3: Ruter (avhengig av fase 1+2)
- [ ] T-006: Implementer POST /api/auth/register
- [ ] T-007: Implementer POST /api/auth/confirm
- [ ] T-008: Implementer GET /api/auth/resend-confirmation

## Fase 4: Grensesnitt (parallelt med fase 3)
- [ ] T-009: Bygg /register-siden med skjema
- [ ] T-010: Bygg /register/confirm/[token]-siden
- [ ] T-011: Bygg /register/success-siden

## Fase 5: Cron + integrasjon (avhengig av fase 3+4)
- [ ] T-012: Cron /api/cron/send-confirmation
- [ ] T-013: Cron /api/cron/cleanup-unconfirmed
- [ ] T-014: E-postmal registration-confirmation.tsx
- [ ] T-015: Integrasjonstester (Playwright), inkludert opprydding like
  før 48h, nøyaktig ved 48h, sletting innen 48h 5m, forsinket-jobb-feil
  og beskyttelse av bekreftede kontoer

## Merknader
- T-001, T-004, T-009–T-011 kan kjøres parallelt (ulike filer)
- T-002 er i konflikt med T-001 (samme fil: schema.prisma) – kjør sekvensielt
- T-006 krever T-003 (migrering brukt) og T-005 (typer)

Legg merke til markørene parallel-safe og after T-NNN. Dette er avhengighetsgrafen som senere lar deg kjøre flere faser parallelt. Hele Spec Kit-metodikken for å øke tempoet hviler på denne mekanismen: noen oppgaver kan gis til fem ulike Claude Code-økter samtidig, mens andre må kjøres strengt sekvensielt.

Spec Kit gjør dette automatisk med én kommando, rett ut av boksen.

Den valgfrie kommandoen /speckit-taskstoissues tar tasks.md og oppretter GitHub Issues fra listen, hver med en lenke tilbake til spec.md. Dette er nyttig hvis du jobber i et team eller vil følge fremdriften gjennom GitHub Projects.

Slik implementerer du med underagenter (Implement)#

/speckit-implement

Claude begynner med den første oppgaven i tasks.md. Hver oppgave går gjennom en liten syklus: les de relevante filene, skriv en diff, kjør testene, kryss av [x]. Underagenter kalles inn automatisk når det trengs: én til kodegjennomgang, én til å kjøre linteren og én til å kontrollere om det finnes regresjoner.

Og separat, om regler:

I Spec Kit formaliseres denne syklusen. Du har spec.md som sannhetskilde, plan.md for tekniske beslutninger og tasks.md som sjekkliste. Hvis Claude kommer ut av kurs i et trinn, går du tilbake til spesifikasjonen og sier: «Dette samsvarer ikke med FR-003; gjør det på nytt.» Ingen lange ledetekster som sier «husk hva vi diskuterte ...» – hele historikken ligger i filene.

Hvis du har koblet til Dynamic Workflows i Opus 4.8, kan du sette Spec Kit i fullautomatiseringsmodus: én /speckit-implement-kommando, så parallelliserer Claude arbeidet, samler resultatene og kontrollerer dem. Grensen er 1000 underagenter samtidig. For de fleste funksjoner holder 10–30.

Når alle [x]-boksene er krysset av og kontrollen i neste del svarer «Converged», gjennomgår du PR-en (eller flere PR-er hvis det er mange oppgaver) og slår den sammen. Artefaktene – spec.md, plan.md, tasks.md – blir værende i repoet som dokumentasjon for funksjonen. Et år senere trenger du ikke å reversere logikken fra koden.

Slik kontrollerer du at agenten ikke har oversett noe (Converge)#

/speckit-converge

Først gir agenten et sammendrag av det den fant, med alvorlighetsgrader, og deretter ett av to utfall. «Converged» betyr at det ikke finnes mangler, tasks.md er uendret byte for byte, og du kan gå videre til gjennomgang. «Tasks appended» betyr at mangler ble funnet, lagt til i Convergence-delen i tasks.md, og at agenten forteller deg hvor mange det er.

Converge redigerer eller sletter ikke kode; den eneste skrivingen er nye oppgaver i tasks.md. Derfor kan du kjøre den uten bekymring, men bare etter at /speckit-implement har arbeidet seg gjennom den gjeldende tasks.md. Hver påfølgende gjennomgang finner færre mangler.

Hvordan skiller Spec Kit seg fra CLAUDE.md og Plan Mode?#

Sammenlign dem på 5 egenskaper:

I Spec Kit-termer er dette .specify/memory/constitution.md. Under initialiseringen kan Spec Kit enten bruke den eksisterende CLAUDE.md som grunnlag for konstitusjonen eller opprette en egen fil ved siden av. Jeg pleier å beholde CLAUDE.md som den globale «avtalen» (stakk, ordliste, utrullingsprotokoll), og bruke Spec Kit-konstitusjonen til regler som gjelder spesifikt for funksjonen – for eksempel «alle skjemaer valideres gjennom Zod; ingen manuelle kontroller».

Koblingen til Plan Mode er enklere. Plan Mode er en rask modus for «planlegging før kode skrives» i én enkelt økt. Den fungerer bra for små endringer (rette en feil, refaktorere en funksjon). For en stor funksjon kommer Plan Mode til kort fordi kontekstvinduet i én økt er for lite til en plan på 3000 linjer – slik jeg forklarer direkte i direktesendingen:

Spec Kit er et konkret verktøy for kontekstutvikling. Det flytter den «arkitektoniske duken» fra chatten til filer. Spec.md blir værende i repoet, og hver nye Claude-økt leser den på nytt – du trenger ikke å gjenta deg selv.

Et oppsett for et stort prosjekt:

1. CLAUDE.md – stakk, ordliste og hva man ikke skal gjøre. Den ligger i roten.
2. .specify/memory/constitution.md for Spec Kit – regler som gjelder denne arbeidsflyten.
3. specs/001-feature-A/spec.md, plan.md, tasks.md – første funksjon.
4. specs/002-feature-B/spec.md, plan.md, tasks.md – andre funksjon.
5. Til daglig arbeid bruker du enten /speckit-implement (for ferdige oppgaver) eller /plan (en rask dobbeltsjekk før en endring).

Hvilke eksempler fra virkeligheten fungerer?#

Konkrete eksempler:

• AWS Kiro – agent for legemiddeloppdagelse. I et blogginnlegg fra AWS Industries datert 18. februar 2026 beskriver teamet TargetID-prosjektet. Tre utviklere, tre uker, en agent for legemiddeloppdagelse. Tallene i artikkelen: Kiro genererte mer enn 95 % av koden for forretningslogikken, og sparte mer enn 80 utviklingstimer. I tillegg: «README-dokumentasjonen skrevet av Kiro sparte oss anslagsvis 8 timer» og «40 % færre iterative prompt-og-rett-sykluser».
• Rackspace Technology. I den samme AWS-bloggen rapporterer Rackspace: «fullførte 52 ukers beregnet arbeid på bare 3 uker», «90 % økning i effektivitet». Dette er ikke lenger en liten funksjon – det er et fullstendig bedriftsprosjekt.

For leseren betyr dette at tilnærmingen ikke er teoretisk: seriøse team bruker den allerede i produksjon.

Når passer Spec Kit IKKE?#

Passer ikke #1 – små redigeringer. Hvis oppgaven er «gi nytt navn til en variabel», «rett en skrivefeil i teksten» eller «legg til en logg», tar det lengre tid å gå gjennom Specify → Plan → Tasks enn å gjøre selve redigeringen. For små redigeringer går Plan Mode eller en direkte ledetekst i Claude Code raskere.

Passer ikke #2 – live-eksperimenter. Når du ennå ikke vet hva du vil og trenger å «prøve deg fram» i grensesnittet eller raskt sette sammen en prototype for å se «om det fungerer», er en spesifikasjon meningsløs. Verdien ligger nettopp i at du improviserer. På nivået «å leke med en idé» er vibe akkurat det som fungerer, ikke en spesifikasjon.

Passer ikke #3 – eldre kode med kompleks tilstand. Et sterkt motargument er at virkeligheten endres raskere enn spesifikasjoner. Ta abonnementskjøp som eksempel: Teamet beskrev faktureringssykluser og skatteregler, og en uke senere ba økonomiavdelingen om europeisk merverdiavgift – spesifikasjonen var utdatert før lanseringen. Når forretningslogikken utvikler seg raskt, blir vedlikehold av spesifikasjoner en byrde.

En ekstra risiko er en falsk følelse av kontroll: strukturene er elegante, men agenter ignorerer ofte instruksjoner eller følger tvert imot malene altfor bokstavelig. Resultatet er kode som er strukturelt riktig, men ikke passer til det bestemte repoet ditt – spesifikasjonen garanterer ikke at agenten forsto den slik du mente.

Bransjeanalytikere har advart mot fossefallsmodellen: å skrive en stor spesifikasjon før koden er en vei som allerede har ført bransjen på avveie én gang, tilbake på tiden med kravspesifikasjoner på 200 sider. Ingeniører har vært forsiktige med denne tilnærmingen siden, og den forsiktigheten er berettiget.

Hva bør du gjøre? Jeg foreslår en enkel regel: funksjonsstørrelse opp mot tiden det tar å skrive en spesifikasjon. Hvis det tar mindre enn 2 timer å implementere en funksjon, bør du ikke skrive en spesifikasjon – Plan Mode går raskere. Hvis en funksjon vil ta en uke, bør du definitivt bruke Spec Kit; tidsbesparelsen vil betale tilbake timen brukt på spesifikasjonen fem ganger. Mellom 2 timer og en uke bruker du skjønn, selv om jeg personlig skriver en spesifikasjon også for funksjoner som tar en halv dag, fordi artefaktet i repoet er mer verdt enn de 30 minuttene du sparer.

Hva nå: hvordan integrerer du Spec Kit i prosjektet ditt?#

En konkret plan for de neste 7 dagene:

• Dag 1. Installer uv og Spec Kit (5–10 minutter). Kontroller at /speckit-*-kommandoene vises i Claude Code. Ikke prøv å bruke dem på et eksisterende prosjekt – start med et nytt.
• Dag 2. Velg en reell funksjon du planlegger å bygge. Kjør /speckit-specify med en beskrivelse i fritekst. Åpne spec.md, les den, og besvar hver [NEEDS CLARIFICATION]. Ikke gå for raskt videre til Plan.
• Dag 3. Kjør /speckit-plan med tips om stakken din. Les plan.md, særlig delen Architecture Decisions. Hvis noe ikke passer for deg, redigerer du det manuelt.
• Dag 4–5. Kjør /speckit-tasks, deretter /speckit-analyze for å dobbeltsjekke settet med spesifikasjon, plan og oppgaver, og så /speckit-implement. Følg med på hvordan Claude krysser av [x] i tasks.md. Det kan hende den står fast et sted – det er normalt. Gå tilbake til spec.md, presiser kravet, og start /speckit-implement på nytt med en konkret oppgave. Når oppgavene er lukket, kjører du /speckit-converge og gjentar Implement- og Converge-sekvensen til den svarer «Converged».
• Dag 6–7. Gjennomgå PR-en (eller flere PR-er). Slå den sammen. Les spec.md og plan.md – de er funksjonsdokumentasjonen din for det kommende året.

Dette foreslår jeg at du leser parallelt:

• Slik setter du opp CLAUDE.md i 2026 – grunnlaget for Spec Kit-konstitusjonen.
• Plan Mode i Claude Code – et raskt alternativ for små oppgaver.
• Kontekstutvikling i 2026 – hvorfor Spec Kit fungerer.
• Skills, Subagents, MCP eller Plugins – hva du kan legge til i Spec Kit for arbeidsflyten din.
• Dynamic Workflows i Claude Code – slik starter du mange underagenter samtidig i Implement-fasen.

Den komplette kontekstflyten: AI-klone + Second Brain + Context Engineering.

Mer materiale er tilgjengelig på Ailoot.