GitHub har open-sourcet Spec-Kit, et værktøjssæt til Spec-Driven Development: skriv en struktureret specifikation først, lad agenterne bygge bagefter. Ifølge MarkTechPost lå repoen ved offentliggørelsen 8. maj 2026 på over 90.000 stjerner og mere end 8.000 forks. Tallene ændrer sig hurtigt, men signalet er klart.
Hvorfor betyder det noget? Fordi AI-kodning har udviklet en dårlig vane: vibe-coding. Kode der kompilerer, måske endda ser pæn ud, men glider forbi forretningsintentionen. GitHub peger på, at problemet ofte ikke er agenternes evner, men måden de bruges på. Vi skriver til dem som til en søgemaskine i stedet for at give entydige instruktioner. Det genkender vi.
Fra vibe-coding til specifikationer som referencepunkt
Vibe-coding er, når man siger til en agent: “Lav et endpoint der håndterer supporttickets” og får 300 linjer, som teknisk set virker, men overser, at billetter ikke må lukkes uden SLA-check, og at labels skal spejle CRM’et. Næsten rigtigt — og næsten gør ondt i produktion. MarkTechPost beskriver fænomenet præcist, og vi har set samme mønster hos flere kunder: en prototype bliver til et offentligt endpoint uden governance. To gange i år måtte vi skimme logs og finde en uautoriseret dev-app, der kørte videre. Ikke ondsindet, bare glemt.
Spec-Driven Development forsøger at bryde den vane. I SDD er specifikationen den styrende kontrakt: du beskriver hvad og hvorfor, ikke hvordan, og lader agenterne udlede plan, opgaver og implementering. PRD’en bliver et levende artefakt, ikke en mappe der samler støv. Det er iteration på et maskinlæsbart fundament, som både mennesker og agenter kan arbejde ud fra.
Hvad indeholder Spec-Kit
Spec-Kit rummer to hoveddele ifølge MarkTechPost og projektdokumentationen: Specify CLI samt templates og hjælpescripts. CLI’en er skrevet i Python og kræver Python 3.11 eller nyere. Anbefalet installation går via uv, fx: uv tool install specify-cli –from git+https:\/\/github.com\/github\/[email protected] og derefter specify init . Ikke svært, men det kræver en moderne Python-runtime; ældre build-images skal opdateres.
Efter init får man kommandoer, der afspejler SDD-flowet: \/speckit.constitution til ufravigelige principper, \/speckit.specify til det forretningsvendte hvad og hvorfor, \/speckit.plan til teknisk plan, \/speckit.tasks til en ordnet opgaveliste, \/speckit.taskstoissues til at oprette GitHub-issues, og \/speckit.implement til at køre opgaverne med en AI-agent. Dertil \/speckit.clarify til at finde huller i kravene, \/speckit.analyze til konsistenskontrol og \/speckit.checklist til kvalitetstjeklister.
Konstitutionen der bider sig fast
En detalje vi kan lide: constitution.md. Et lille dokument med store tænder. Her kan man fastlåse sikkerhedskrav, arkitekturprincipper og naming conventions, som både agenter og mennesker skal følge. Tørt på papiret, men ofte det, der holder projekter på skinner, når tempoet stiger.
Begrænsningerne er væsentlige. Spec-Kit er ikke en tryllebro til jeres legacy-monolit. Det styrer processen, ikke jeres datamodeller. Og det kræver, at agenterne faktisk forstår spec-formatet og kan holde kontekst på tværs af artefakter. De fleste moderne agenter kan det, men kvaliteten varierer.
Hvad ændrer det i hverdagen
Workflowet ændres. Først: ejerskabet til specs. Nogen skal skrive dem, vedligeholde dem og have mandat til at sige nej. I praksis lander det mellem produkt og tech lead. Teams undervurderer typisk opgaven de første uger. Det er ikke sværere end god user-story-skrivning, men mindre tilgivende. Maskiner læser ikke mellem linjerne.
Dernæst en ny arbejdsdeling. Mennesker skriver krav, konstitution og godkender planer. Agenter leverer planudkast, bryder opgaver ned, implementerer og foreslår tests. Når det spiller, føles det som at skifte fra frihånd til byggeklodser: hurtigere, men mere firkantet. Med vilje.
CI og tests bliver klogere, ikke kun flere
CI\/CD-pipelines skal ikke kun køre enhedstests. De skal validere, at koden matcher specifikationen: spec-coverage, kontrakttests og automatiske diffs mellem spec, plan og implementering. \/speckit.analyze peger den vej. I praksis giver det nye gates: må en feature merge, hvis 30 procent af kravene står som uklare efter \/clarify? Det lyder rigidt. Netop pointen. Rigidhed i pipeline er billigere end krisepatches.
Testtyperne flytter sig også. Vi har bedst erfaring med at lægge en kontrakt-test mellem frontend og backend og lade agenterne generere stub-tests ud fra specifikationen. Mennesker holder øje med kanter, performance og datakvalitet. Ikke alt skal automatiseres. Nogle ting lugter man sig frem til — som da vi opdagede en for langsom pagination på et testmiljø, fordi Grafana-grafen hoppede i små trappetrin hver tredje sekund. Den slags står ikke i en spec.
Sikkerhed og governance kan ikke være en eftersætning
Hvis nogen stadig tror, at automation er safe by default, så kig på de seneste tal. VentureBeat refererer RedAccess’ research: cirka 380.000 offentligt tilgængelige assets bygget med vibe-coding-værktøjer, og omtrent 5.000 af dem indeholdt følsomme virksomhedsdata, omkring 1,3 procent. Axios og Wired bekræftede eksempler, inkl. sundhedsdata og finansielle oplysninger, der aldrig burde have ligget åbent. Det er ikke skræmmehistorier. Det er hverdag.
SDD og Spec-Kit løser ikke sikkerhed alene, men de reducerer sandsynligheden for, at en hurtig weekend-app går live uden sanity checks — forudsat at man faktisk bruger constitution.md, adgangskontrol og versionsstyring. I modsætning til en løs chat-historik efterlader Spec-Kit spor: hvad var kravet, hvem ændrede det, hvilke tests dækker det. Audit bliver muligt. Ikke nemt, men muligt.
Hvad kan gå galt alligevel
Tre ting springer frem. Læringskurven: Vi ser typisk 2–4 uger, før et team skriver specs, som agenter forstår uden efterfølgende omskrivning. Ikke fordi værktøjet er svært, men fordi præcis kravformulering er en disciplin. Man bliver bedre. Det kræver omhu.
Integrationerne: Spec-Kit antager, at jeres agenter kan køre i den pipeline, I har. Hvis GitHub Actions, GitLab eller Jenkins ikke har Python 3.11 og adgang til de rette modeller og kontekstkilder, skal I bygge den bro. Der er opsætningsarbejde. Og i enterprise-miljøer vil nogen spørge til audit-logs, RBAC og data residency. Dokumentationen kan være mere eksplicit her; vi savner stadig helt klare svar på, hvad der følger med, og hvad der kræver egen lim.
Og så bureaukratiet
Risikoen er, at SDD bliver papirhelvede. Hvis man overgør konstitutioner og checklister, kvæles tempoet. Fristelsen er at kræve fem underskrifter for et ordskift i en spec. Lad være. Hold artefakterne lette og operative: en side for konstitution, én for specifikation, én for plan. Resten som issues. Nok til, at en agent kan handle, og et menneske kan se hvorfor.
Der er også ting, Spec-Kit ikke hjælper med: tværfaglig forretningsforståelse; at oversætte marketingmål til tekniske succeskriterier; at refaktorere et 12 år gammelt modul, hvor halvdelen af adfærden er historisk arv. SDD kan tegne mål og vej, men ikke løfte jer over al legacy alene.
Sådan ville vi pilotere det
Vi ville køre en lille, seriøs pilot: én backend-feature med klart forretningsmål, to integrerede tests, en agentkonfiguration, to sprints. Start med \/speckit.constitution for sikkerhed og arkitekturprincipper. Skriv specifikationen tæt med produktet, kør \/clarify for at jagte huller, og accepter først planen, når en tech lead har godkendt den. Lad agenterne implementere, men kræv menneskelig review på alle PR’er. Kør \/analyze og mål, hvor meget manuel omskrivning der var nødvendig pr. opgave.
Vi gjorde noget i den stil for nylig. Anonym kunde, almindeligt API-arbejde. Agenten ramte en tricky datavalidering forkert første gang, men gengav audit-kravene perfekt fra konstitutionen. Præcis det kompromis vi forventer: stærk på formalia, svagere på kontekstuelle undtagelser. Efter justering kørte løsningen stabilt på test. Solidt, ikke mirakuløst.
Tjekliste til sikkerhed og governance
Inden I åbner repoet for agenter:
- Dataafgrænsning først: hvilke datasæt må agenterne se, hvilke ikke. Dokumentér det i constitution.md.
- Policy for offentlige endpoints: kræv eksplicit godkendelse før deploy til internet. Ingen undtagelser.
- Audit og log-lagring: versionshistorik på specifikationer og planer. Gem agent-run logs i mindst 90 dage.
- CI-gates: afvis merges, når \/speckit.analyze melder uafdækkede krav eller manglende tests.
- Sårbarhedsscanning: behold SCA og SAST, og læg en spec-drift-check oveni.
Målepunkter bør være jordnære: time-to-value for feature-bundter, fejlrate i QA, andel af ændringer der kræver menneskelig omskrivning, antal utilsigtede eksponeringer pr. kvartal. Falder de tal? Så virker processen.
For ledere og CISOs
Det her er ikke en “AI-satsning”. Det er en procesændring. Sæt audits op for at finde skyggeapps og uautoriserede deploys. Stil simple scopingspørgsmål: Hvad er kilden til sandhed for denne feature? Hvor er den versioneret? Hvem må ændre den? Hvilke tests beviser, at implementeringen følger specifikationen? Hvor lang tid går der fra specrevision til deploy — og hvorfor?
Få også styr på kommandoveje. Når \/speckit.clarify viser uklare krav, hvem retter så — produkt, arkitekt eller team lead? Uden en svarperson bliver SDD til en debatklub. CISOs bør desuden kræve, at alle agent-initierede deployments kun går via godkendte pipelines. Det er dér, skygge-AI siver ud, hvis man ikke er opmærksom.
Modargumenter og åbne spørgsmål
Er vi ved at overhype et værktøj? Måske. Repo-stats er ikke lig med produktionseffekt. Vi mangler uafhængige casestudier med tal på kvalitetsforbedring og fejlreduktion i drift. Integrationsdækningen på tværs af agenter er heller ikke fuldt dokumenteret i de åbne kilder. Officiel guidance for enterprise—inkl. audit-logging og RBAC—ville klæde projektet.
Der er også en menneskelig faktor. Selv med SDD kan agenter misforstå nuancer. Hvis specifikationen er forkert, bliver koden nøjagtigt forkert. Et fremskridt, men også et ansvar. Nogle teams vil finde formatet tungt i starten. Fair. Tempoet kommer igen, når strukturen sidder i fingrene.
Hvor lander vi
Spec-Kit er vigtigt. Ikke fordi det er det pæneste værktøj i skuffen, men fordi det peger væk fra friskfyragtig prompt-magi og hen mod styrbar automatisering. Det løser ikke alt. Det fjerner ikke behovet for dygtige mennesker, gode tests og klar governance. Men det gør det lettere at fange fejlene, før de bliver til hændelser. Resten ser man først i praksis. På en tirsdag.
