MarkTechPost gennemgik 8. maj 2026 ni værktøjer til spec‑driven development. Pointen for teams nu er jordnær: AI‑agenter sender kode afsted på minutter, mens krav og sporbarhed sakker bagud. Vi har selv siddet i et sprint review hvor en feature virkede, men brød en intern afregningsregel, som stod i en email og ikke i kravene. Tre dages efterarbejde. SDD rammer lige dér, ifølge MarkTechPost og vores egne erfaringer.
Det her er ikke kun en værktøjsliste. Kiro og GitHub Spec Kit leverer konkrete artefakter, som passer ind i rigtige teams med rigtige deadlines. Mindre show, mere struktur.
Hvad er spec‑driven development
SDD tager en struktureret specifikation som sandhedskilde; koden følger efter. MarkTechPost beskriver den tilgang, og vi nikker genkendende. Når specifikationen ændres, skal kode og tests følge med. Simpelt at sige, svært at gøre. Men muligt.
Det hjælper på tempo‑uden‑klarhed, fordi kvalitetssikringen rykker opstrøms. Acceptance criteria bliver maskinlæsbare. PR‑reviews får sporbarhed. Når noget fejler i drift, kan man pege på den sætning i kravene, der blev misforstået, i stedet for at rode i commit‑historik.
Snapshot over værktøjerne
MarkTechPosts liste rummer ni SDD‑værktøjer. Vi fremhæver de tre mest konkrete i kilden og henviser til den fulde gennemgang for resten.
- Kiro. Agentisk IDE bygget til SDD med tre faser og tre artefakter; EARS‑user stories; agent hooks; Auto router for modeller; Code OSS, CLI og web, ingen AWS‑krav.
- GitHub Spec Kit. Open source Python‑CLI med 93.000+ stjerner; version v0.8.7 7. maj 2026; fire‑fase workflow og en persistent constitution som kontrakt.
- BMAD‑METHOD. MIT‑licenseret framework der orkestrerer 12+ specialiserede agenter på tværs af SDLC via filbaserede håndtryk og sporbare dokumentkæder.
De øvrige seks ligger i MarkTechPosts artikel. Vi remser dem ikke op her. Sagen er, at SDD er gået fra niche til værktøjskasse.
Dybde Kiro
Kiro fører udviklere gennem tre faser: Requirements, Design og Tasks. Ud af det falder tre filer i repoet: requirements.md, design.md og tasks.md. Ikke pynt, men arbejdspapirer, som både agenter og mennesker kan forstå og reviewe som kode.
Kiro genererer user stories i EARS‑notation. Det strammer acceptance criteria op og får hjørnerne med: undtagelser, timing, præ‑ og postbetingelser. I en intern enkelt‑team pilot hos os gav en tidlig workflow brugbare EARS‑stories i første iteration. Vi justerede domæneord på få minutter for at lande rigtigt.
Agent hooks er Kiros praktiske særkende: event‑drevne automationer, der kører når filer oprettes eller gemmes. Testopdateringer. README‑sync. Sikkerhedsscans. Ingen prompts. I en af vores små piloter blev en test‑hook for ivrig og ændrede fixtures for tit, hvilket udløste et tocifret antal ekstra kommentarer i to PR’er samme uge. Læringen var enkel: læg guardrails ind, fx mappede stier og frekvensbegrænsning.
Om modeller: Ifølge MarkTechPost bruger Kiro som standard en Auto router, der kombinerer flere frontier‑modeller, herunder Claude Sonnet, Qwen, DeepSeek, GLM og MiniMax. Man kan også pinne en model. Vi kan ikke verificere, hvornår eller hvorfor routeren skifter model. Valglogikken er ikke dokumenteret offentligt. Tag derfor modellisten som kildeciteret, ikke som uafhængigt bekræftet.
Kiro er bygget på Code OSS. VS Code‑vante teams er hurtigt med. Dertil kommer CLI og web. Og ingen AWS‑konto er nødvendig for at komme i gang, ifølge kilden. Det gør en lille pilot nem at sætte op.
Dybde GitHub Spec Kit
Spec Kit er en Python‑CLI, open source, med 93.000+ stjerner og seneste release v0.8.7 fra 7. maj 2026, jf. MarkTechPost. Det er ikke en IDE, men en bærbar pipeline, der kan køre ved siden af jeres editor. Kilden nævner støtte til bl.a. Claude Code, Copilot, Amazon Q og Gemini CLI.
Workflowet går i fire faser med klare checkpoints: Specify, Plan, Tasks, Implement. Først forretningskontekst og succeskriterier. Så arkitekturvalg. Så opgaveopdeling. Så implementering under de rammer. Den rækkefølge kan mærkes i PR’erne, som bliver kortere og mere fokuserede.
Kernen er en constitution — en markdown‑fil med principper, der ikke må brydes. Den er den vedvarende kontrakt mellem udvikler og agent på tværs af sessioner. For audits og change management er det en gave: du kan se regelændringen og hvem der godkendte den.
Sammenligning og konsekvenser i praksis
Vil I have en IDE‑oplevelse med indbyggede automationer og let adgang til hooks, peger pilen mod Kiro. Har I fastlåst IDE‑standard eller stramme klientpolitikker, er Spec Kit lettere at indføre. CLI ind, eksisterende CI/CD ud — minimal friktion.
Modelstyring er et valg, ikke pynt. Kiros Auto router lover den “rigtige” model pr. opgave, men er en black box set fra governance. Pinning giver forudsigelighed. I Spec Kit lever beslutningen i jeres opsætning og constitution; eksplicit, men med lidt mere håndarbejde.
Afhængigheder tæller. Kiro kører uden AWS‑binding, har web og CLI og hviler på kendt editorfundament. Spec Kit har nær nul afhængigheder ud over Python og agent‑integrationer. BMAD‑METHOD er tungere og henvender sig til teams, der vil orkestrere mange roller som separate agenter. Vi så et finans‑team gå for bredt ud og bruge en uge på at styre agenter frem for at bygge. Skaler langsomt.
Tre implementeringsmønstre fra Snillds playbook
Workshops først. Tag eksisterende krav og omsæt dem til maskinlæsbare specs. Vi bruger ofte en halv dag på sproghygiejne. EARS hjælper, fordi det låser sætninger fast i klare mønstre. Ja, ordvalg bliver en diskussion. Det er pointen.
CI‑checks for kontraktvalidering. Byg et step, der matcher PR‑diff mod krav og tasks. Hvis koden ændrer dokumenteret adfærd uden en tilsvarende spec‑ændring, fejler builden med en kort forklaring. Læg en styret undtagelsesvej ind (label + godkendelse), ellers finder folk en bagdør.
Agent hooks i praksis. Start med få: testopdatering, README‑sync og et let sikkerhedstjek. Mål støj og lead‑time. Vi oplevede i en lille intern pilot, at hooks på on‑save gav for mange små commits; at flytte to af dem til nightly reducerede review‑støj mærkbart ugen efter.
Testgenerering fra specs og falsk tryghed
Automatisk testgenerering fra specs er fristende. Brug det, men mål på mismatch — ikke bare antal tests. En kontrakttest som første gate er effektiv: stemmer output mod specifikationen ord for ord. Når det fejler, lærer man mest. De første to sprint kan føles hårde; så bliver det nemmere.
Største risiko er falsk tryghed. En udfyldt requirements.md er ikke lig med korrekt adfærd. Uklare specs giver blot automatiseret fejlproduktion. Vi har set feature‑grene, der passerede alle automatiske checks og stadig var forkerte i forretningslogik. Læg et kort menneskeligt sanity‑review ind. Altid.
Risici, begrænsninger og tradeoffs
Hvis domænet ændrer sig dagligt, kan selve vedligeholdelsen af specifikationer blive flaskehalsen. Vi så i en enkelt‑team pilot, at en udefineret “policy‑sektion” i constitution voksede uden versionsdisciplin og skabte modstridende regler. Resultatet var tre PR’er, der hver overholdt forskellige udgaver af sandheden. Fixet var banalt: versionsnummer i filens header og tvungen sign‑off.
Modelskift kan også drille. Når underliggende LLM opdateres, kan tonen og strukturen i genererede artefakter skifte. Pinning og versionslog i constitution hjælper, men vær forberedt på at regenerere tests og beskrivelser, når modellen ændres i jeres miljø.
Dependency management vokser. Hooks, agenter og policies skal versionsstyres som kode. Tildel ejerskab. Enterprise‑spørgsmål som SSO, roller og audit er ikke dækket i MarkTechPosts artikel for Kiro, så stil de spørgsmål, før udrulning.
Hvem passer hvad til
Små til mellemstore produktteams med VS Code‑kultur og lyst til automatiske hjælpeopgaver vil ofte trives i Kiro. Enterprise‑teams med stram klientstyring af udviklermiljøet eller regulerede domæner får hurtig værdi af Spec Kit, fordi det kan bo i eksisterende CI/CD uden ny IDE. BMAD‑METHOD er til dem, der vil orkestrere roller og dokumenthåndtryk bredt — start smalt.
Gennemgå Kiro‑hooks som enhver anden automatisering i jeres sikkerhedsmodel. Ingen auto‑commits til main. Begræns skriveadgang og log alt. I Spec Kit: behandle constitution som en change‑kontrolleret policyfil med versionsnummer, reviewer og beslutningslog.
Anbefalinger til beslutningstagere
Kør en 4‑ugers pilot på én service og én feature. Mål tre ting med simple metoder: 1) Kravmismatch: antal kontrakttest‑fejl pr. PR (CI‑job output) og andel PR’er med påkrævet spec‑ændring. 2) Review‑tid: median tid fra PR‑åbning til merge (from/to‑tidsstempler i Git). 3) Genåbnede tickets: antal issues med status Reopened pr. sprint. Sæt baseline i uge 0 og sammenlign uge 4. Hvis mismatch falder, er I på rette vej.
Vælg platform efter kontekst: Skal I skifte IDE? Hvor meget automation tåler processen? Hvem ejer specifikationerne? Overvej ekstern sparring de første uger — ikke for et framework, men for at få de første kontrakter på plads, CI‑checks kodet og hooks tunet.
Konklusion og næste skridt
SDD er en arbejdsrutine, ikke et trick. Kiro og Spec Kit giver hver sin indgang og adresserer tempo‑uden‑klarhed med konkrete artefakter og automations. Start med en lille pilot, mål mismatch og review‑tid, og hold specs levende. Forskellen mærkes først, når man sidder med det i hænderne.
Kilde og metode
Tekniske beskrivelser af Kiro, GitHub Spec Kit og BMAD‑METHOD er baseret på MarkTechPosts gennemgang 8. maj 2026. Vi har ikke uafhængigt verificeret Kiros Auto router eller dens valgkriterier; modellisten er som i kilden. Stjerneantal og versionsdato for Spec Kit er angivet som i kilden; se også projektets repo. Vores anekdoter er enkelt‑team piloter hos Snilld og ikke generelle effektmålinger.
