Lad os være ærlige. Mange AI‑kodningssessioner starter som en fornøjelse og ender i knuder. Efter tre timer har man tre fine funktioner, en halv feature og en TODO, der fordoblede sig. Det er præcis det problem, Rick Hightower beskriver i sin gennemgang af Claude Code på Towards AI, senest opdateret 26. maj 2026. Nyheden hos ham: Claude Code bevæger sig mod et specifikationsdrevet værktøj med fire lag, som holder kursen efter time tre. Vi ser idéen. Vi ser også, hvor der mangler svar i kilden: låsning af todos.json, multi‑udvikler konflikter og konkrete CI‑integrationer.
Hightower skriver, at ingeniører kan lide Claude Code til enkeltfunktioner, men at den vakler på hele features uden en stram spec. Hans påstand er, at kuren ikke er endnu et plugin, men et workflow der starter med en plan, uddybes via et interview til en specifikation, kører med en live task‑liste og forankres i en vedvarende todos.json. Han formulerer det som “hand Claude a spec and walk away”. Vi vil tilføje med det samme: gå først, når governance, reviewpunkter og adgangskontrol er på plads.
Hvorfor AI‑sessioner kollapser efter tre timer
Vi genkender symptomerne. TODOs driver. “Lille bugfix” bliver til omfaktorering. Kontekst forsvinder fra chatten, så modellen gætter på navne og grænseflader. Koden ser fornuftig ud i diffen, men bryder et hjørneflag, som kun produktteamet kan huske. Hightower advarer mod præcis det: halvfærdige features, svære at overskue, dyre at redde ugen efter.
Vi så det for nylig hos et anonymt kundeteam på et event‑streamingprojekt. Efter 2,5 time stod der en flot parser, men idempotent lagring og backfill‑kantcases var uklare. Chatten var fuld af hensigtserklæringer. Repoet var tavst om kontrakterne. Stemningen? Den der blanding af kold kaffe og travlhed.
Hvad Claude Code tilbyder ifølge Towards AI
Hightower beskriver fire indbyggede lag i Claude Code som grundlag for en spec‑drevet proces:
Plan mode. Et overblikslag hvor Claude reducerer konteksthop og foreslår en rækkefølge, før der skrives kode. Interview‑to‑spec. Claude “interviewer” udvikleren og former en maskinlæsbar specifikation, som modellen selv kan slå op i. Som Hightower rammer det: mindre løs snak, mere reference.
Live task list og todos.json med attribution
Live task list. En kørende opgaveliste, som Claude vedligeholder, så scopeændringer ikke dør i chatten. Hightower skriver, at Claude Code “already ships a complete task list” og et spec‑drevet projektstyringslag. Todos.json. Et vedholdende spejl af opgaver og status i repoet, der kan versioneres med koden. Pointen hos Hightower: tråden bliver, når chatten dør ud.
Hvis de fire lag hænger sammen, rammer de de klassiske tre‑timers‑symptomer: planlægning holder, opgaver forsvinder ikke, og specifikationen lever i repoet. Vi er enige i retningen — med forbeholdene om styring og sikkerhed nævnt ovenfor.
Sådan kan en spec‑drevet session se ud
Hightowers flow i korte træk: start i plan mode for retning. Lad Claude interviewe udvikleren til en maskinlæsbar spec. Når spec’en er på plads, kobles live task list på, og todos.json bliver single source i repoet. Hans formulering “hand Claude a spec and walk away” kræver i praksis et par faste menneskepunkter: godkend spec før eksekvering og gennemgå ændringer i todos.json via PR.
I kodebasen betyder det mindre, mere ensartede PRs. Testbarheden stiger, når trin i spec’en mappes til tests. Tilbageførsel bliver enklere: en fejlet feature svarer til en gruppe opgaver i todos.json — man ruller præcis det sæt tilbage, ikke “seneste fem commits”.
Mini‑eksempel fra praksis
Et forsimplet, illustrativt flow uden kundedata:
- Spec:
specs/fe-142.ymldefinerer “Task 3: persist events idempotent”. - Todos:
todos.jsonindeholder post med idFEAT-142-task-3, link tilspecs/fe-142.yml#task-3, statusin_progress. - PR: gren
feat/fe-142-task-3refererer task‑id i titel og commit‑beskeder. - Test:
tests/fe142/task3.spec.tsnavngivet efter task‑id. CI kræver match mellem PR‑referencer, todos.json og tests.
Det er kedeligt at sætte op første gang. Og netop derfor virker det i hverdagen.
Snillds vurdering og anbefalinger
Vi har set samme mønster i kundecases: AI kan skrive meget, men uden en skarp, maskinlæsbar spec mangler kanterne. Når specifikationen bor i repoet fra start, falder to ting hurtigere på plads: forudsigelighed og genbrug. Det er vores observation, ikke et løfte.
Vores anbefaling, baseret på Snillds interne brief, er at koble til CI/CD, versionsstyring af både specs og prompts og tydelig ejerskab. Ikke pynt. Fundament. Ellers ender det som et langt Confluence‑dokument, ingen opdaterer. Vi siger det så direkte, fordi vi har set den film før.
Begrænsninger og uafklarede punkter
Hightower beskriver lagene og workflowet, men ikke låsemekanismer til todos.json i multi‑udviklerscenarier. Hvordan undgå konflikter, når to agenter og tre mennesker rører samme fil? Kilden er tavs. Vores forslag: kodeejer‑regler, pre‑merge checks, og automatiske CI‑afvisninger ved divergens mellem live task list og todos.json.
Det er også uklart, hvordan Claude Code knytter sig til etablerede CI/CD‑platforme som GitHub Actions eller GitLab CI i praksis. Vi har ikke set officiel referenceintegration. Læg dertil klassiske risici: komplekse legacy‑API’er, stateful systemer, og sikkerhedsfølsomme miljøer hvor secrets ikke må snige sig ind i chat eller logs. Ingen af delene er belyst i kilden — så planlæg som om de ikke findes, før I selv har dokumenteret dem.
Implementering i et rigtigt team
Vil I i gang, så start småt. Ét team. Udpeg en spec‑forvalter pr. feature. Opgaven er at sikre, at interview‑to‑spec lander i /specs som maskinlæsbar fil. Todos.json ligger i roden, versionsstyres og navngiver tasks efter jeres issue‑tracker.
Tilpas CI: hver PR refererer ét eller flere spec‑elementer. Tests opdateres mod de referencer. Automatiske checks måler mismatch mellem live task list og todos.json. Og vigtigst: hvem må godkende ændringer i spec? Produkt? Tech lead? Begge. Lås det, før I skalerer.
Operativ drift og support
For driften flytter artefakterne fokus. Rollback på opgavesæt i todos.json frem for “seneste grønne build”. Observability binder incidents til den spec‑version, der introducerede ændringen. En lille metadatakrog i loggerne med spec‑ID og task‑ID gør fejlsøgning hurtigere.
Når en feature bryder i produktion, kan resterende tasks i todos.json sættes på pause. Tråden bevares. Det sænker mængden af halvt færdige features, fordi halvfærdigheden nu er beskrevet — ikke glemt i Slack.
Governance og compliance, helt konkret
Versioner både spec og prompts. Vi anbefaler et separat lager for godkendte specs med bred læseadgang og snæver skriveadgang. Behandl todos.json som kode: PR, review, audit. Og styr adgang til AI‑artefakter og interviewhistorik. Hvor ligger det fysisk? Hvem må læse? Det er compliance, ikke pynt.
Sporbarhed kræver mapping mellem commit‑SHA, spec‑version og build‑nummer. Det er tungt i uge 1. Og uundværligt, når en revisor beder om dokumentation for en ændring i Q3.
Brancheperspektiv på mere handlekraftige agenter
MarkTechPost omtaler Microsoft Researchs Webwright 24. maj 2026: agenten får et terminalmiljø, skriver og kører Playwright‑scripts og bash, og efterlader vedvarende artefakter i filsystemet. Tendensen er klar: når modeller bliver bedre til at skrive og fejlfinde kode, kræver de rigere eksekveringskontekster end klik‑for‑klik.
Vi kan ikke overføre Webwrights Odysseys‑score direkte til Claude Code — det ville være uunderbygget — men retningen matcher: væk fra engangsinteraktioner, hen mod kode‑artefakter, der kan testes, versioneres og genkøres. Hightowers speclag peger samme vej.
Konkrete tradeoffs
Tid kontra opsætning: gevinsten kommer først, når repo‑struktur, CI‑skabeloner og governance er på plads. Vores erfaringsbaserede bud for et mellemstort team er 2–6 ugers opsætning. Automatisering kontra gennemgang: lad AI skrive, men lad mennesker definere og godkende specs. Hurtig prototyping kontra drift: den første uge frister til at springe governance over. Det koster siden.
Rytmen i interview‑to‑spec betyder også noget. Hvis den bliver for tung, drukner man i proces. For let, og man er tilbage i tre‑timersfælden. Vores tommelfingerregel, ud fra cases vi har set: 20–30 minutters skarp specifikation pr. større feature betaler sig i test og drift.
Hvad vi tester næste hos Snilld
Vi måler på to ting i vores egne forsøg: 1) cyklustid fra godkendt spec til merge, 2) andelen af PR’er med AI‑genereret kode, der kræver menneskelig omskrivning ud over review. Data er ikke klar til offentliggørelse, så tag det som arbejdsnoter. Tendensen vi ser: kortere cyklustid, når spec’en er stram.
I et anonymt finans‑team oplevede vi færre regressioner, da tests blev mappet direkte til spec‑trin. Ikke nul. Men færre. Og roligere sprintplanning ugen efter.
En kort 6‑ugers startguide
Uge 1–2: lav skabelon for interview‑to‑spec, opret /specs og todos.json‑kontrakt, sæt CI‑checks for spec‑referencer i PR’er. Uge 3–4: kør to features gennem plan mode, brug live task list og todos.json som styring, mål cyklustid. Uge 5–6: stram governance, gennemgå fejltyper, justér skabeloner. Involver produkt, udviklingsledere og drift fra start. Én ejer for specs, én for CI, og en fælles ceremoni til at godkende spec‑ændringer.
Det lyder tørt. Til gengæld kan alle finde tråden tirsdag morgen.
Hvor vi stadig er skeptiske
Der mangler uafhængige benchmarks for hele features med Claude Code versus klassiske workflows. Towards AI beskriver designet, ikke tallene. Låse og versionering af todos.json i multi‑dev scenarier er ubeskrevet. Indtil vi ser dokumentation, anbefaler vi fil‑ejerskab og obligatoriske pre‑merge checks.
Sikkerhedsmodellen for følsomme specs er heller ikke tydelig i kilden. Vores råd: sanitisér logs, ring‑fenc adgange, og læg aldrig secrets i spec‑artefakter. Simpelt, men konsekvent.
Kort konklusion
Claude Code med et spec‑drevet workflow ligner et reelt svar på tre‑timers kollapset. Hos Hightower er de fire lag beskrevet klart, og idéen kan — med de rette rammer — løfte Claude fra funktionsskriver til featurebygger. Vi tror, det er værd at prøve i kontrollerede rammer og med stram styring.
Beviserne for fuld produktionsskalering mangler stadig. Så begynd småt, mål, og byg governance før I skalerer. Man mærker forskellen, når man sidder med artefakterne i repoet — ikke i en chattråd.
Kilder og metode
Primær kilde: Rick Hightower på Towards AI, opdateret 26. maj 2026. Herfra stammer beskrivelserne af plan mode, interview‑to‑spec, live task list og todos.json, plus formuleringer som “hand Claude a spec and walk away” og udsagnet om, at Claude Code allerede leverer en komplet task‑liste og et spec‑drevet projektstyringslag. Trendkontekst: MarkTechPosts dækning af Microsoft Researchs Webwright om agenters rigere eksekveringskontekster. Praktiske anbefalinger er Snillds egne professionelle vurderinger fra vores interne brief og projekter. Vi har krydstjekket funktionsbeskrivelser mod Towards AI og markeret vores vurderinger som netop vurderinger.
- Towards AI: Claude Code, spec‑drevet workflow og citater
- MarkTechPost: Webwright og trenden mod terminal‑native agenter
- Snillds interne brief: CI/CD, governance, samt spec‑ og prompt‑versionering
