Har du noen gang følt at AI-koden din fungerer lokalt, men ødelegger alt når den treffer produksjonen? Det er ofte fordi vi hopper rett over planleggingen. Vi ber om kode, får kode, og håper det beste. Denne metoden kalles ofte «vibe coding» - raskt, intuitivt, men farlig.
Løsningen heter vibe speccing. Det handler ikke om å sløyfe AI-en, men om å bruke den til å tenke først. Ved å tvinge AI-assistenten til å generere strukturerte krav, arkitektur-diagrammer og oppgavelister *før* én eneste linje med implementeringskode skrives, kan du kutte feil med opptil 80 %. Det er forskjellen mellom å bygge et hus på sand og å legge et fundament i betong.
Hva er egentlig vibe speccing?
Vibe speccing er en arbeidsmetode der utviklere bruker AI for å generere kravspesifikasjoner og design-dokumenter før selve kodingen starter. Den kombinerer hastigheten fra vibe coding med disiplinene fra spec-driven development.
Tradisjonell «vibe coding» er som å be en kokt lage middag uten å si hva du liker å spise eller hvilke allergier du har. Du får kanskje noe spiselig, men sjelden noe som passer perfekt. Vibe speccing endrer dette ved å innføre en stopp-klaff. Før AI-en skriver kode, må den levere en spesifikkasjon (ofte i Markdown-format) som du godkjenner manuelt.
Metoden ble popularisert av praktisk rettede utviklere som Luke Bechtel og Erik Hanchett rundt 2024-2025. De observerte at timene spart på «rask koding» ofte ble tatt igjen av timer brukt på debugging og arkitektoniske justeringer senere. Ved å investere 5-30 minutter i en AI-generert spesifisering, redder man prosjektet fra å gå i vrang course tidlig.
De fire fasene i spec-driven workflow
For å få dette til å virke, trenger du en strukturert syklus. Pockit Tools-teamet og andre ledere innen feltet foreslår en fire-fasers løkke som erstatter den kaotiske «prompt → kode»-tilnærmingen:
- Krav (Requirements): Hva bygger vi? AI-en intervjuer deg om formål, brukeropplevelse og suksesskriterier. Resultatet lagres i en fil som `requirements.md`.
- Design: Hvordan bygger vi det? Her defineres teknologivalg, dataflyt og systemgrenser. Dette stadiet inkluderer ofte AI-genererte diagrammer.
- Oppgaver (Tasks): Hvilke konkrete steg tas, og i hvilken rekkefølge? En detaljert TODO-liste (`tasks.md`) genereres her.
- Implementering: Nå, og bare nå, skriver AI-en kode og tester basert på de tidligere dokumentene.
Hver fase produserer en fysisk fil i prosjektet ditt. Disse filene blir «sannhetsgrunnlaget» for AI-en. Når den skal skrive kode, leser den ikke bare kildeteksten, men også disse spesifikasjonsfilene for å forstå konteksten.
AI-genererte diagrammer: Fra tekst til visuelle oversikter
Et av de kraftigste verktøyene i vibe speccing er evnen til å visualisere logikk før den eksisterer. Tekstuelle beskrivelser kan være uklare, men et diagram avslører manglende koblinger umiddelbart.
De fleste moderne LLM-baserte IDE-verktøy (som GitHub Copilot Chat, Cursor eller Claude Code) kan generere kodeblokker i språk som Mermaid er et open-source diagramspråk som konverterer tekst til flytdiagrammer, sekvensdiagrammer og klasse-diagrammer direkte i nettleseren eller PlantUML.
| Diagramtype | Bruksområde | Eksempel på verdi |
|---|---|---|
| Seqvensdiagram (Sequence) | Viser samhandling mellom komponenter over tid | Frontend → API Gateway → Database |
| Komponentdiagram | Viser statisk arkitektur og avhengigheter | Mikrotjenester, kø-systemer, cache-lagring |
| Flytdiagram (Flowchart) | Logikk og beslutningstagning i business rules | Betalingsvalidering: Succes vs Feilhåndtering |
Når du ber AI-en om et design, bør du spesifikt be om et Mermaid-sekvensdiagram hvis funksjonen involverer flere tjenester. Et slikt diagram hjelper deg med å se om AI-en har glemt en kritisk valideringssteg eller feilhåndteringsrutine før koden faktisk skrives.
Slik setter du opp Cursor eller Windsurf for vibe speccing
Teorien er fin, men hvordan gjør man det i praksis? Nøkkelen ligger i «varige regler» (persistent rules) i IDE-en din. Hvis du bruker Cursor er en AI-integrert kodeeditor som tillater prosjektspesifikke regler og kontekst-styring, kan du automatisere hele prosessen.
Luke Bechtels metode innebærer å lage en regel som alltid er aktiv. Regelen instruerer AI-en slik:
- Når brukeren ber om en ny funksjon, spør AI-en: «Skal jeg lage en spesifisering for denne oppgaven først?»
- Hvis ja, lager AI-en en fil i `.cursor/scopes/[FunksjonsNavn].md`.
- AI-en intervjuer brukeren om formål, begrensninger og akseptanskriterier.
- AI-en presenterer utkastet for gjennomgang. Ingen kode genereres ennå.
- Brukeren godkjenner med en tydelig kommando (f.eks. «GO!»).
- Nå starter implementeringen.
Dette krever ingen ekstra kostnader utover abonnementet ditt på verktøyet. Det koster deg kun tid - typisk 5 minutter ekstra per liten funksjon. For større epics kan det ta 30-90 minutter, men gevinsten i redusert rework er enorm.
Struktur for spesifikasjonsfiler
En god spesifiseringsfil bør ikke bli et monumentalt dokument. Pockit Tools anbefaler at hovedfilen (ofte kalt `CLAUDE.md`, `CURSOR.md` eller lignende) holdes under 200-300 linjer. Den fungerer som et kart som peker mot mer detaljerte dokumenter.
Her er et eksempel på hvordan en enkel spesifiseringsfil for en «Betalings-API-endepunkt» kan se ut:
# Formål
Tillate brukere å initiere betalinger via Stripe.
# Krav
1. Valider beløp > 0.
2. Logg transaksjon i DynamoDB.
3. Send webhook til frontend ved suksess.
# Begrensninger
- Må bruke eksisterende auth-middleware.
- Tidsbegrensning: Maks 2 sekunder svar.
# Ut av scope
- Refunderinger (håndteres separat).
- Abonnementer.
# Akseptanskriterier
- Testen 'create_payment_success' grønn.
- Ingen logging av sensitive kortdata.
Merk hvordan dette er konkret. Ikke «gjør betaling bra», men «logg i DynamoDB» og «bruk eksisterende middleware». Jo mer kontekst du gir AI-en her, jo bedre vil koden passe inn i resten av systemet.
Fordele vs risiko: Er det verdt bryet?
La oss være ærlige: Vibe speccing legger til overhead. For en enkel refaktorering av en enkelt funksjon, er det kanskje overkill. Men for komplekse endringer, kryss-tjeneste-integrasjoner eller nye datamodeller, er fordelene klare.
Pockit Tools rapporterer internt om en reduksjon på 60-80 % i regresjoner knyttet til AI-generert kode når teamet deres gikk over til spec-driven development kombinert med test-driven development (TDD). AugmentCode understreker at arkitektonisk konsistens forbedres dramatisk; AI-en slutter å foreslå generiske lærebok-løsninger og begynner å respektere dine eksisterende mønstre.
Risikoen ligger i «spec drift». Hvis du endrer koden manuelt eller via raske prompts uten å oppdatere spesifikasjonsfilen, blir dokumentet utdatert. Da vil AI-en neste gang basere seg på feil informasjon. Spesifikasjoner må behandles som kode: De må versjonskontrolleres, gjennomgås i pull requests, og oppdateres jevnlig.
Vanlige fallgruver og hvordan unngå dem
En stor fare med AI-genererte spesifikasjoner er hallusinasjoner. Modellen kan oppfinne plausible hørende begrensninger eller teknologier som ikke eksisterer i ditt prosjekt. Derfor er menneskelig gjennomgang mellom fase 1 (krav) og fase 2 (design) avgjørende. Som Erik Hanchett sier i sine foredrag: «Det er iterasjon; det er du som ser på dokumentene.»
Unngå også å behandle spesifikasjonen som en stiv kontrakt. Den er et levende dokument. Hvis du oppdager en bedre løsning under implementeringen, oppdater spesifiseringen først, så fortsett kodingen. Dette holder konteksten ren for fremtidige AI-interaksjoner.
Hvor lang tid tar vibe speccing sammenlignet med vanlig coding?
For små funksjoner legger det til omtrent 5-10 minutter. For komplekse, fler-tjenestebaserte features kan det ta 30-90 minutter før koding starter. Imidlertid sparer dette ofte timer med debugging og arkitektoniske justeringer senere, noe som reduserer total leveranstid for store prosjekter.
Fungerer vibe speccing med alle AI-verktøy?
Metoden fungerer best med IDE-integrerte verktøy som støtter varige regler og store kontekstvindu, som Cursor, Windsurf, GitHub Copilot Chat og Claude Code. Verktøy som lar deg lagre og referere til lokale Markdown-filer (.md) er ideelle for å opprettholde kontekst over tid.
Hva skjer hvis spesifikasjonen blir utdatert?
Dette kalles «spec drift». Hvis koden endres uten at spesifikasjonsfilen oppdateres, vil AI-en basere fremtidige forslag på feil informasjon, noe som kan føre til inkonsistent kode og nye feil. Spesifikasjoner bør oppdateres parallelt med koden, helst automatisk eller via strenge review-prosesser.
Trenger jeg ekspertkunnskap for å bruke Mermaid-diagrammer?
Nei, ikke nødvendigvis. Siden AI-modeller er svært gode på å generere Mermaid-syntaks, kan du la AI-en lage diagrammene basert på tekstuelle beskrivelser. Din rolle er å vurdere om diagrammet korrekt reflekterer logikken og arkitekturen du ønsker.
Er vibe speccing egnet for små prosjekter eller scripts?
For veldig små, engangs-scripts eller proof-of-concept-konsepter kan vibe speccing være overkill. Her er tradisjonell «vibe coding» ofte rask nok. Metoden virkelig skiner når du jobber med fler-fil-funksjoner, kryss-tjeneste-integrasjoner eller systemer hvor arkitektonisk konsistens og vedlikebarhet er kritisk.