Parallelt arbejde med Claude Code: worktree, agenter og workflows

Praktisk materiale om at arbejde parallelt med agenter: Ailoot-dokumentation.

Denne guide samler praktisk erfaring og et overblik over, hvor værktøjerne passer ind. De fire officielle Claude Code-primitiver, et overblik over deres anvendelsesområder og et anti-hype-rammeværk for, hvor mange parallelle agenter en vibe-koder faktisk har brug for. Alle tal og citater linker til primærkilder fra Anthropic.

Hvad er multi-agent-arbejde i Claude Code, og hvorfor er det ikke »1000 agenter«#

Et multi-agent-setup er et setup, hvor en opgave deles op i flere uafhængige arbejdsspor, som hver håndterer deres egen del og afleverer et resultat. Det enkleste eksempel: Du skriver frontend i ét Claude Code-vindue og backend i et andet vindue på samme maskine med et delt git-repository mellem dem. Det er allerede multi-agent-arbejde, selv om »orkestrering« ville være et unødvendigt ord for det.

Et mere omfattende setup: I én Claude Code-session starter du fem underagenter med forskellige roller (frontendudvikler, backendudvikler, sikkerhedsreviewer, tester, dokumentationsskribent), og hver af dem afleverer sin del af resultatet til den fælles samtale. Det er samme multi-agent-tilgang, bare med ét kontrolpunkt.

Endnu mere omfattende: Du siger til Claude: »kør en ugentlig sikkerhedsrevision af alle 500 filer i mit projekt«, og Claude skriver et JavaScript-orkestratorscript. Runtime-miljøet starter flere dusin agenter i baggrunden, som hver reviderer deres eget afsnit; derefter kontrollerer uafhængige agenter hinandens resultater, og du får én rapport tilbage. Det er Dynamic Workflows, som Anthropic udgav den 28. maj 2026. En detaljeret gennemgang af funktionen findes i den separate guide til Dynamic Workflows.

Forskellen mellem disse tre scenarier er ikke antallet af agenter. Forskellen er hvem der beslutter, hvad den næste agent skal gøre. I det første scenarie er det dig. I det andet beslutter Claude det, efterhånden som samtalen skrider frem. I det tredje er det et JavaScript-script skrevet af Claude.

»1000 agenter« er i øvrigt et reelt tal. Det er den øvre grænse for ét Dynamic Workflow i Claude Code. Den officielle Anthropic-dokumentation siger:

Med andre ord er dette en teknisk beskyttelse mod løbsk adfærd, ikke en anbefalet arbejdsbelastning. I praksis håndteres 95% af opgaverne af 2–8 parallelle arbejdsspor. Hvis du planlægger flere, så spørg først dig selv, hvad de skal lave.

4 Claude Code-primitiver: underagenter, skills, agentteams og workflows#

Claude Code har fire officielle primitiver til at dele én opgave mellem flere agenter. Anthropic samlede dem i en sammenligningstabel i dokumentationen til Dynamic Workflows. Her er sammenligningen forklaret i almindeligt sprog:

Hvert af disse primitiver løser et forskelligt problem. Underagenter egner sig til at delegere 2–3 kontroller inden for én opgave. Skills egner sig, når du har en færdig instruktion, Claude skal følge (som »udfør et PR-review med denne tjekliste«). Agentteams egner sig, når flere dele af et produkt ligger i forskellige vinduer, og du har brug for én koordinator. Workflows egner sig, når en opgave er for stor til ét kontekstvindue.

Underagenter gennemgås i detaljer i guiden Claude Code Subagents 2026. Beslutningstræet for »hvad du skal bruge til en bestemt opgave« findes i guiden Skills, Subagents, MCP, Plugins. Denne guide handler om at samle dem i et multi-agent-setup oven på git worktree.

Niveau 1: underagenter i én session – det nemmeste sted at begynde#

En underagent er den enkleste måde at dele en opgave op på. Hovedsamtalen er koordinatoren. Underagenter er midlertidige arbejdere, som hovedagenten starter, efterhånden som arbejdet skrider frem.

Et konkret eksempel fra det beskrevne projekt. Efter første udkast til en guide sættes reviewet op sådan: Claude får anmodningen »start seks underagenter parallelt – én leder efter AI-markører, den anden efter juridisk ordforråd, den tredje gennemgår stemme og tone, den fjerde faktatjekker med WebFetch, den femte gennemgår SEO-strukturen, og den sjette kontrollerer, om krydslinks er korrekte«. Hver agent afleverer en rapport, hvorefter ændringerne gennemføres.

Teknisk set gøres det med filer i .claude/agents/[subagent-name].md, der beskriver rollen og værktøjerne. Kaldet foretages via værktøjet Agent i hovedsamtalen. Claude beslutter, hvornår en anmodning skal sendes til en underagent.

Hvor det fungerer. Opgaver med 3–7 parallelle kontroller af ét element (kode, tekst, design). Hver kontrol er uafhængig. Resultaterne passer i hovedkontekstvinduet.

Hvor det bryder sammen. Hvis du har 50+ filer, eller hver kontrol kræver sin egen kontekst på 50K tokens, bliver hovedvinduet fyldt. Så har du brug for workflows eller agentteams.

Den største risiko. Hver underagent bruger tokens separat. Hvis du starter seks i et projekt med 200 filer, og hver genlæser alle 200, betaler du 6×. Derfor SKAL du angive præcis, hvilke filer underagenten skal undersøge. Se guiden Hvor bliver tokens af i Claude Code for detaljer.

Niveau 2: git worktree – isolering af filer mellem parallelle sessioner#

Når underagenter ikke er nok, og du har brug for to fuldt udstyrede Claude Code-instanser i forskellige terminaler, der arbejder på samme repository, opstår et klassisk problem. De begynder at redigere den samme fil; den ene gemmer først, og den anden overskriver ændringen. En kunde spurgte supportteamet i sidste uge: »5 overskriver hinanden på samme tid.«

Løsningen er git worktree. Det er en indbygget git-funktion, der lader dig have flere arbejdskopier af det samme repository, hver på sin egen branch, mens de deler et .git-repository. Ét udgangspunkt, forskellige mapper på disken og ingen overlap mellem deres filer. Mekanismen beskrives i detaljer i guiden Git worktree i Claude Code.

Kommandoer til en opsætning på fem minutter:

# From the main project directory
cd ~/projects/my-app

# Create a worktree for feature/auth
git worktree add ../my-app-auth feature/auth

# Create a worktree for feature/billing
git worktree add ../my-app-billing feature/billing

# Open two terminal windows
cd ~/projects/my-app-auth && claude   # first Claude Code
cd ~/projects/my-app-billing && claude # second Claude Code

Hver kopi ligger på sin egen branch. Hver Claude Code-instans skriver til sin egen mappe. Når opgaven er færdig, kører du git push fra dens branch og derefter git worktree remove ../my-app-auth.

Det skal du vide. En worktree kopierer ikke node_modules, .venv eller andre filer i .gitignore. Hvis du har brug for uafhængige afhængigheder (en anden biblioteksversion på hver branch), skal du køre npm install separat i den nye mappe efter worktree add.

Hvor mange worktrees pr. person. Ifølge teamundersøgelser fra 2026 er den praktiske grænse 4–8 parallelle worktrees pr. udvikler. Den begrænsende faktor er ikke Claude, men en persons evne til at gennemgå og godkende resultaterne. Hvis du har 10 worktrees, venter de på review.

I den beskrevne praksis bruger folk som regel 2–3 parallelle worktrees. Én primær worktree til aktivt arbejde, én reserve til hastende hotfixes og én til et eksperiment (en ny funktion, du er usikker på). Flere er ikke nødvendige.

Niveau 3: agentteams – flere vinduer, én ledende agent#

Agentteams er et relativt nyt primitiv. Idéen er, at én ledende agent har den fælles plan som en opgaveliste, mens flere peer-sessioner i separate vinduer tager sig af opgaver, som lederen tildeler. De arbejder alle i det samme filsystem og kan se hinandens mellemresultater.

Det er nyttigt, når en opgave kan opdeles i 3–5 store arbejdsspor, som hver varer flere timer (migrering af et stort modul, omskrivning af et subsystem, en fuld sikkerhedsrevision). I så fald holder den ledende agent planen i én fælles opgavefil på en absolut sti uden for worktrees. Hjælpere læser stien og rapporterer resultater; kun lederen opdaterer status, så konkurrerende skrivninger til koordineringsfilen undgås.

Teknisk set er agentteams flere vinduer, der kører oven på git worktree med ét fælles planlægningspunkt. I praksis administrerer 80% af folk agentteams manuelt (som beskrevet ovenfor med worktree) og bruger ikke noget særligt »teamframework«. Det er helt fint.

Hvis du er i tvivl om, hvorvidt du overhovedet har brug for et framework, er svaret næsten helt sikkert nej. Brug manuel worktree og én ledende agent i hovedmappen.

Niveau 4: Dynamic Workflows – Claude skriver et JS-orkestreringsscript#

Alle tre niveauer ovenfor holder planen i en samtale: i hovedagentens hoved eller i den ledende agents opgaveliste. Dynamic Workflows flytter planen ind i koden. Claude udtrykker opgaven som et JavaScript-script, runtime-miljøet afvikler det i et isoleret miljø, mellemresultaterne ligger i scriptvariabler i stedet for i din kontekst, og sessionen forbliver responsiv, mens agenter arbejder i baggrunden.

Et konkret eksempel fra den officielle dokumentation. Du siger:

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Claude skriver et JavaScript-script med omtrent denne logik: »hent alle filer fra src/routes/, del dem op i grupper på 30 endpoints, kør en agent på hver gruppe med samme kontrol, kør derefter to uafhængige grader-agenter på deres resultater, og saml en endelig rapport.« Det kører. Du får en tabel med resultater og en liste over endpoints, der helt sikkert bør gennemgås.

Hvor det fungerer.

• Revision af et helt projekt for ét problem (sikkerhed, typning, forældede API'er).
• Store migreringer (500+ filer, der følger samme regel).
• Forskningsspørgsmål, der skal undersøges fra flere uafhængige vinkler (Anthropic gør dette i sin indbyggede kommando /deep-research).

En detaljeret gennemgang af Dynamic Workflows, deres begrænsninger, og hvordan ultracode fungerer, findes i den separate guide til Dynamic Workflows i Claude Code.

Hvornår du IKKE skal bruge det. Når opgaven er lineær og tydelig. Et workflow er unødvendigt til en opgave som »gør denne komponent færdig«. Et workflow giver mening, når en opgave kan opdeles i 10+ uafhængige delopgaver, og du har brug for krydstjek mellem dem.

Den største begrænsning. Et workflow bruger betydeligt flere tokens end en almindelig session. Anthropic anbefaler i sin dokumentation:

Med andre ord bør du køre dit første workflow i én mappe, ikke i hele projektet. Se, hvad det kostede, og beslut derefter, om det kan betale sig at skalere op.

Outcomes: et sæt kriterier og en uafhængig reviewer#

Det farligste ved multi-agent-arbejde er at stole på agenternes output. Hver agent returnerer tekst, der ligner færdigt arbejde. Et citat virker sandt, en rapport virker komplet, en migrering virker færdig. Med én agent kan du selv kontrollere det. Med 10 kan du ikke – du har ikke tid.

Anthropic tackler dette problem med Outcomes, en Managed Agents-funktion udgivet den 6. maj 2026. Idéen er enkel: Sessionen får en ANDEN agent (en grader), hvis eneste opgave er at kontrollere den første agents arbejde op mod et strengt sæt kriterier.

Sådan fungerer det teknisk. Du skriver et sæt kriterier – et markdown-dokument med en detaljeret liste over, hvad »færdig« betyder, hvilke kilder der skal kontrolleres, og hvilke labels der skal bruges. Platformen opretter automatisk en grader-agent i et nyt kontekstvindue. Den modtager kun kriterierne og resultatet, ikke andet. Efter hvert forsøg fra hovedagenten (skribenten) læser grader-agenten resultatet igen og godkender det eller returnerer en punktvis liste over det, der mangler.

Et citat fra Anthropic Cookbook:

Tal for den reelle effekt: Efter integrationen af Outcomes i Claude Managed Agents steg AI-virksomheden Harveys andel af gennemførte opgaver med cirka 6×. Hos Wisedocs (medicinsk dokumentation) blev tiden brugt på at gennemgå et dokument reduceret med 50%. Tallene stammer fra den officielle annoncering af funktionen.

Det vigtige for en vibe-koder snarere end en virksomhed er, at Outcomes er et mønster, ikke kun en bestemt funktion. Du kan oprette din egen grader-agent ved at beskrive de samme kriterier i .claude/agents/grader.md og bede hovedagenten om at køre den efter hvert forsøg. Det fungerer med ethvert multi-agent-setup, ikke kun Managed Agents.

Den vigtigste regel for at skrive kriterier fra kogebogen er at angive noget verificerbart, ikke noget generelt. Ikke »kontrollér, at briefen dækker fakturering«, men »åbn briefen, find afsnittet om fakturering, og bekræft, at det angiver et beløb i $ eller en procentdel af omsætningen«. Den første instruktion lader grader-agenten skimme og sætte et flueben. Den anden får den til at åbne dokumentet og finde et bestemt tal.

Antimønster: »50 agenter, der laver nonsens«#

Dette er det centrale antimønster ved multi-agent-arbejde. Nogen lærer, at Claude Code kan køre 16 agenter ad gangen, og at Dynamic Workflows kan køre 1000 pr. kørsel, så sætter vedkommende sig ned og starter dem. Effekt: nul. Tokenforbrug: 10× en almindelig session.

En enkel test. Tag et stykke papir, og tegn en boks for hver af dine agenter. Skriv i hver boks:

1. Hvad den helt præcist gør (én sætning).
2. Hvilke filer den berører.
3. Hvad den returnerer.
4. Hvem der kontrollerer det.

Hvis du ikke kan svare på bare ét af disse spørgsmål på 30 sekunder, bør du ikke have den agent. Reglen gælder på alle niveauer: underagenter, agentteams, Dynamic Workflows.

Det andet antimønster er at køre arbejde parallelt, som burde være sekventielt. Hvis frontend først har brug for backend, fordi den læser API-skemaet, skal du ikke køre dem parallelt. Lav backend først og derefter frontend. Opgaver bør kun køres parallelt, hvis de er uafhængige.

Det tredje antimønster er at bruge multi-agent-arbejde for at øge hastigheden. Det virker kun til et vist punkt. Hvis du deler en opgave op i fire uafhængige arbejdsspor, bliver de færdige omtrent på den tid, ét spor ville tage (plus minimal koordineringstid). Men hvis der er 50 spor på én maskine, kører hvert enkelt langsommere, fordi de deler CPU'en. Den praktiske grænse på en bærbar computer er 4–6 samtidige Claude Code-instanser; derefter begynder begrænsningen.

Hvad koster det, og hvordan undgår du at opbruge dine grænser?#

I maj–juni 2026 måtte branchen se i øjnene, at AI-kodning kostede mere end forventet.

Én almindelig Claude Code-chatsession koster forholdsvis lidt. Slår du Dynamic Workflows til for et helt repository, får du en regning, der er 20× så høj. Fra den officielle Anthropic-dokumentation:

Hvad du bør gøre i praksis. Sparereglerne fra den beskrevne praksis.

1. Angiv præcist, hvilke filer hver agent skal undersøge. Ikke »gennemgå projektet og find problemer«, men »se på src/auth/*.ts, og kontrollér, at hver funktion validerer userId«. Den anden prompt giver dig præcis det arbejde, du betaler for.

2. Prøv altid et workflow i én mappe først. Ikke hele src/. Begynd med src/auth/. Hvis du kan lide resultaterne og forstår omkostningen, kan du derefter rulle det bredere ud.

3. Brug /effort high som standard og kun ultracode, når det er tilsigtet. /effort ultracode betyder xhigh plus automatisk orkestrering. Det er meget dyrt. Brug det, når en opgave virkelig kræver flere parallelle arbejdsspor.

4. Skift underagenter til en mindre model, når du kan. Hvis du har seks underagenter til at gennemgå én guide, behøver hverken QA-agenten, der leder efter AI, eller krydslink-kontrolløren Opus. Sonnet er nok. Det reducerer forbruget med 3–5×.

En detaljeret gennemgang af, hvordan du sparer tokens, findes i guiden Hvor bliver tokens af i Claude Code og Sådan undgår du at opbruge Claude Code-grænser.

Hvor du kan begynde i dag: en tjekliste på 30 minutter#

1. Opdater Claude Code til v2.1.154+

   Dette er den mindste version, der understøtter Dynamic Workflows. Kør claude update i terminalen.

2. Aktivér Dynamic Workflows i /config

   De er deaktiveret som standard på Pro-abonnementet. Åbn /config, find linjen »Dynamic workflows«, og slå den til. De er allerede aktiveret på Max, Team og Enterprise.

3. Opret din første worktree

   Kør git worktree add ../<project>-experiment <branch> i projektets hovedmappe. Åbn et andet terminalvindue i den mappe. Kør claude.

4. Tilføj en delt opgaveliste

   Brug én absolut sti uden for alle worktrees. En tasks.md i hvert worktree er en separat fil og synkroniseres ikke automatisk. Lad kun den ledende session skrive; hjælpere læser den fælles liste og rapporterer resultater til lederen.

   Opret koordineringsmappe og opgaveliste én gang:

mkdir -p "$HOME/projects/my-app-coordination"
printf '%s\n' '# Tasks' '- Auth: assigned to the auth worktree' '- Billing: assigned to the billing worktree' > "$HOME/projects/my-app-coordination/tasks.md"

I første terminal:

cd "$HOME/projects/my-app-auth"
printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
claude

I anden terminal:

cd "$HOME/projects/my-app-billing"
printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
claude

Giv agenten **samme udvidede absolutte sti udskrevet ovenfor** i begge sessioner: “Læs denne fælles opgaveliste. Arbejd kun på din tildelte opgave og filer. Redigér ikke listen; rapportér fuldførelse og blokeringer til lederen, som ejer opdateringerne.” Bekræft, at begge agenter kan læse præcis denne fil før start; en tilladelsesprompt skal afklares for den sti. Opgavelisten koordinerer status, mens kodeændringer stadig bliver i separate worktrees.

5. Arbejd sådan i en uge

   Installér ikke en GUI-wrapper med det samme. Arbejd manuelt med to worktrees i en uge. Du vil opdage, hvad der mangler; vælg derefter et værktøj til et konkret problem.

6. Aktivér først derefter \/effort ultracode\\

   Vælg én opgave, for eksempel »find alle API-endpoints uden auth-kontroller i src/routes/«. Aktivér /effort ultracode. Se, hvilket workflow Claude skriver, hvad det koster, og hvilket resultat det giver. Det bliver dit første Dynamic Workflow.

Hvad du kan undersøge næste gang: hukommelse mellem sessioner, Code Review, Multi-Agent v2#

Det, der er dukket op i maj–juni 2026, og hvad der er på vej for multi-agent-arbejde i Claude Code.

Managed Agents med Dreaming. Udgivet den 6. maj 2026 på Code with Claude. En planlagt proces, der læser en agents tidligere transskripter mellem sessioner, finder tilbagevendende mønstre og opdaterer dens hukommelse. AI-juridikvirksomheden Harveys antal gennemførte opgaver blev seksdoblet specifikt efter Dreaming. Stadig i research preview.

Outcomes som en Managed Agents-funktion. Beskrevet ovenfor. Tilgængelig gennem Claude Agent SDK, ikke direkte i Claude Code CLI. Du kan anvende samme mønster manuelt med en grader-underagent allerede nu.

Multi-Agent Orchestration v2 i Claude Agent SDK. En ledende agent delegerer selv underagenter ved hjælp af et delt filsystem. Det er et skridt fra »start N underagenter manuelt« til »beskriv en opgave, så beslutter den ledende agent selv, hvem den skal delegere til, og hvordan«. Hvis du lige er ved at lære underagenter, behøver du ikke bekymre dig om v2 endnu. Lær det klassiske mønster – »én hovedagent + 3–5 underagenter med roller« – og gå naturligt videre til v2 om 3–6 måneder.

Code Review udført af et team af agenter. Anthropic annoncerede en funktion på Code with Claude til automatisk code review, når en PR åbnes. Et team af AI-agenter gennemgår diff'en parallelt, leder efter bugs, kontrollerer resultaterne indbyrdes og rangerer dem efter alvorlighed. Tilgængelig på Team og Enterprise, endnu ikke på Pro.

Plugin Marketplace. Lanceret den 23. maj 2026 på v2.1.128-136. Nogle plugins i marketplace er færdige multi-agent-setups (parallel-review, security-audit, migration-helper). Du kan installere dem med /plugin install <name>@claude-plugins-official og se, hvordan de er sat sammen – en god måde at lære at skrive dine egne på.

Multi-agent-arbejde i Claude Code ligner stadig et sæt primitiver på forskellige modenhedstrin. Underagenter og git worktree er stabile, gennemprøvede og fungerer overalt. Agentteams er halvt automatiserede og halvt manuelle. Dynamic Workflows er i research preview og ændrer sig hurtigt. Managed Agents v2 er kun for virksomheder. Det betyder, at det optimale setup for en vibe-koder det næste år ikke er den nyeste udgivelse, men det mindste setup, der kræves til den konkrete opgave. To worktrees og én grader-underagent er nok til en måneds aktivt arbejde. Tilføj kun kompleksitet, når du begynder at føle dig begrænset.

Et fungerende setup til vibe-kodning#

Praktisk materiale: Ailoot-dokumentation.

Flere materialer og værktøjer: Ailoot.