Guide · Hverdags-AI
Vibecoding er den hurtigste vej til en prototype og den langsomste vej til noget, der holder. Modtrækket hedder spec-driven development: du skriver, hvad du vil have, før AI'en skriver koden. Her er metoden, også hvis du ikke er udvikler. Det er jeg heller ikke.
Beskrivelse først. Kode bagefter.
Første version går stærkt. Anden version slår tilbage.
Jeg bygger mine egne værktøjer med AI, blandt andet et todo-system og det website, du læser det her på. Første version går altid stærkt. Man beskriver løst, hvad man vil have, AI'en spytter noget ud, det ser rigtigt ud, man klikker rundt, og det virker næsten. Det er blevet døbt vibecoding, og til en prototype er det fantastisk.
Problemet med vibecoding kommer i version to. Du beder om én ændring, og noget andet går i stykker. Du beder om en rettelse, og AI'en bygger en hel ny løsning ved siden af den gamle.
Efter en uge har du et projekt, hvor du ikke længere kan forklare, hvorfor tingene ser ud, som de gør. Det kan AI'en heller ikke, for forklaringen står ingen steder.
GitHub beskrev problemet præcist, da de præsenterede værktøjskassen Spec Kit den 2. september 2025: du beskriver dit mål, får en blok kode tilbage, og den ser rigtig ud, men virker ikke helt. Ifølge GitHub bruger vi kodeagenter som søgemaskiner, når de i virkeligheden er bogstavtro makkere, der skal have entydige instruktioner (GitHub-bloggen, 2. september 2025).
Svaret er gammelt og kedeligt og virker: skriv ned, hvad du vil have, før du beder om koden. Metoden hedder spec-driven development, og en international oversigt på dev.to fra juni 2026 kalder den mainstream blandt udviklere i år (dev.to, 19. juni 2026).
Rækkefølgen er metoden: beskrivelse før kode.
En spec siger hvad, ikke hvordan.
En spec (specifikation) er en kort, skriftlig beskrivelse af, hvad noget skal kunne, før det bliver bygget. Den siger ikke, hvordan det skal kodes. Den siger, hvad det skal gøre, for hvem, og hvad der skal ske i grænsetilfældene.
Hvem skal bruge det, og hvilket problem løser det for dem? "Min kollega skal kunne se sine egne timer, ikke mine" er en spec-sætning. "Byg med React" er det ikke.
Hvad skal der ske, når feltet er tomt, eller når to poster har samme navn? Det er her, vibecoding fejler: AI'en gætter, og den gætter anderledes end dig.
Hvordan ved I begge to, at opgaven er løst? "Manuelle poster uden type skal stadig ende i fakturagrundlaget" kan testes. "Det skal bare virke" kan ikke.
Grunden til, at en spec virker, er banal: en sprogmodel er god til at fuldføre mønstre og dårlig til at læse tanker. GitHub bruger selv eksemplet "tilføj billeddeling til min app". Sådan en løs prompt tvinger modellen til at gætte på potentielt tusindvis af uudtalte krav, og nogle af gættene rammer forkert (GitHub-bloggen, 2. september 2025).
Ifølge GitHub opdager du ofte først de forkerte gæt, når du er langt inde i byggeriet. En spec fjerner gættene, før de bliver til kode.
Fire faser, og et stop mellem hver.
Den udgave af metoden, GitHub beskrev i september 2025, har fire faser med et stop imellem hver. Du går ikke videre, før den forrige fase er på plads (GitHub-bloggen, 2. september 2025).
Du giver en overordnet beskrivelse af hvad og hvorfor. AI'en folder den ud til en fuld spec med brugerrejser, grænsetilfælde og succeskriterier. Din opgave er at læse den igennem og rette de steder, hvor den har gættet forkert. Her fanger du de fejlgæt, du ellers først ville opdage langt inde i byggeriet.
Nu kommer teknikken. Du fortæller, hvilke rammer der gælder: hvilke systemer det skal spille sammen med, og hvad der ikke må røres. AI'en skriver en teknisk plan. Har du allerede faste instruktioner til dit AI-værktøj, fx en projektbeskrivelse eller en gemt systemprompt, er det i planlægningen, de arbejder sammen med spec'en. Guiden om context engineering viser, hvordan du sætter dem op.
AI'en bryder spec og plan ned i små, afgrænsede opgaver, som hver kan bygges og tjekkes for sig. GitHubs eget eksempel: i stedet for "byg login" får du en opgave som "lav en tilmelding, der afviser ugyldige mailadresser". Små bidder gør, at du kan se, om hver enkelt virker, i stedet for at få hele featuren på én gang.
AI'en tager opgaverne én ad gangen, og du gennemgår små, fokuserede ændringer i stedet for et kodedump. Går noget skævt, retter du i spec'en og lader AI'en lave planen igen, i stedet for at lappe med nye prompts oven på gamle.
Du kan starte i det værktøj, du allerede har åbent.
Du kan komme langt uden at installere noget. Vil du have metoden sat på skinner, findes der værktøj til det.
| Niveau | Værktøj | Sådan bruger du det |
|---|---|---|
| Uden installation | Dit nuværende AI-værktøj | Skriv spec'en som et almindeligt dokument, og bed AI'en bygge ud fra den, fase for fase. Princippet virker i ethvert værktøj. |
| Indbygget | Plan mode i kodeagenter | I Claude Code læser AI'en dine filer og foreslår en plan, men ændrer intet, før du godkender. Du slår den til med Shift+Tab (Claude Code-dokumentationen, Anthropic). Flere kodeværktøjer har en tilsvarende tilstand. |
| Dedikeret | GitHub Spec Kit | Open source-værktøjskasse med en fast kommando til hver fase: /speckit.specify, /speckit.plan, /speckit.tasks og /speckit.implement. Ifølge projektet virker den med over 30 kodeagenter, blandt andre GitHub Copilot, Claude Code, Gemini CLI og Cursor (Spec Kit, liste over integrationer). |
Spec Kit har et begreb, der er værd at stjæle, uanset værktøj: en "constitution". Det er et dokument med projektets faste principper og retningslinjer, som AI'en arbejder ud fra i al videre udvikling. I Spec Kit laver du det med kommandoen /speckit.constitution (Spec Kit på GitHub).
En constitution minder om de faste instruktioner, du måske allerede har sat op i Claude eller ChatGPT, bare skrevet til ét projekt. De to arbejder fint sammen: de faste instruktioner bærer reglerne, spec'en bærer den konkrete opgave.
Spec Kit nåede version 1.0.0 i august 2026, et år efter første commit, ifølge projektets egen README. Det er stadig et udviklerværktøj, der installeres og køres fra kommandolinjen.
Hvor udbredt metoden er, har jeg ikke fundet målinger af, hverken danske eller internationale. Oversigten på dev.to fra juni 2026 kalder den mainstream blandt udviklere, men skriver selv, at leverandørernes egne tal om bedre resultater skal læses som en retning, ikke et bevis (dev.to, 19. juni 2026).
Metoden har en pris. Betal den kun når det kan betale sig.
Metoden har en pris, og den skal siges højt: den er langsommere at starte på. François Zaninotto fra udviklerbureauet Marmelab kaldte i november 2025 spec-driven development for "vandfaldsmodellens genkomst". Han peger på lange markdown-dokumenter, der skal læses igennem for at finde fejlene, og foretrækker selv at bygge små funktioner én ad gangen (Marmelab, 12. november 2025).
Zaninotto giver metoden ret i én ting: den virker bedst, når et projekt startes fra bunden. Kritikken af metoden rammer hårdest de steder, hvor opgaven er lille eller udforskende.
Skal andre end dig bruge det, eller skal det stadig virke om et halvt år? Så betaler spec'en sig. Er det en engangsprototype, så vibe løs.
Rører opgaven ved data, penge eller andres arbejde, skal gættene ud af koden. Er det værste udfald, at en farve er forkert, kan du springe spec'en over.
Kan ønsket ikke være i tre sætninger, kan AI'en ikke gætte det. Små rettelser og enkeltstående spørgsmål kræver ingen spec. En hel feature gør.
Min egen tommelfingerregel: prototyper og eksperimenter vibecoder jeg stadig, for det er dét, formen er god til. Men alt, hvad jeg ved, jeg skal bygge videre på, starter som tekst før kode.
At starte med tekst føles langsommere den første time. Det er hurtigere allerede i den anden.
Den slags, hvor version et var sjov, og version to slår tilbage. Skriv til mig, så kigger vi på, hvordan du får styr på det uden at starte forfra.
Skriv til mig →AI'en koder godt og gætter dårligt. En spec fjerner gættene, mens de stadig er billige at rette.
Fire faser med stop imellem: beskriv, planlæg, opdel, byg. Din opgave er at efterse ved hvert stop.
Brug spec'en, når resultatet skal leve videre, og drop den, når du bare skal se en idé i hænderne.
Nej. En spec skrives i almindeligt sprog og beskriver, hvad noget skal kunne, for hvem, og hvornår det er færdigt. Selve koden skriver AI'en stadig. Det du skal kunne, er at læse AI'ens forslag igennem ved hvert stop og sige til, når den har gættet forkert om det, du vil have.
Den tekniske plan i fase to kræver lidt mere, fordi du skal fortælle hvilke systemer der skal spille sammen. Her kan du bede AI'en foreslå rammerne og selv nøjes med at sige, hvad der ikke må røres.
En spec beskriver hvad der skal bygges og hvorfor, mens plan mode i Claude Code beskriver hvordan AI'en vil ændre koden. I plan mode læser Claude dine filer og foreslår en plan, men ændrer intet, før du godkender. De to kan bruges sammen: skriv spec'en først, og lad plan mode lave planen ud fra den.
Plan mode slås til med Shift+Tab eller ved at starte med claude --permission-mode plan. Uden en spec planlægger AI'en ud fra det, den selv gætter, du vil have.
Ikke helt, selvom udviklerbureauet Marmelab kalder spec-driven development for vandfaldsmodellens genkomst. François Zaninotto fra Marmelab pegede i november 2025 på lange markdown-dokumenter, der skal læses igennem for at finde fejlene. Forskellen fra vandfald er, at spec'en kan rettes undervejs: går noget skævt, retter du spec'en og lader AI'en lave planen igen.
Zaninotto giver dog metoden ret i én ting: den virker bedst, når et projekt startes fra bunden. Er opgaven lille eller udforskende, foretrækker han selv at bygge små funktioner én ad gangen.
Kilde: Marmelab, 12. november 2025
Ja. GitHub Spec Kit er open source under MIT-licensen og kan bruges gratis. Det installeres som et kommandolinjeværktøj med pakkehåndteringen uv og kører sammen med den kodeagent, du allerede bruger. Projektet nåede version 1.0.0 i august 2026, et år efter første commit, ifølge projektets egen README på GitHub.
Spec Kit er gratis, men det er kodeagenten ikke nødvendigvis. Den agent, du kører Spec Kit sammen med, har sine egne vilkår og sit eget abonnement.
Ja. Spec Kits egen liste over integrationer nævner både Claude Code og Cursor, sammen med blandt andre GitHub Copilot, Gemini CLI og Codex CLI. Projektet skriver selv, at det virker med over 30 kodeagenter, både kommandolinjeværktøjer og assistenter indbygget i en kodeeditor, og at listen kan ses med kommandoen specify integration list.