I VM0 dev-teamet arbejder hver udvikler med flere Claude Code-instancer på samme tid. Typisk mere end otte.
Vi behandler Claude Code på samme måde, som vi behandler en rigtig udvikler. (Ja, vores firma hedder halvt for sjov AI Colleagues Co!)
Derfor afspejler designfilosofien bag VM0 dev-arbejdsgangen klassiske teamledelsesmetoder fra softwareudvikling.
Vi bruger GitHub Issues til at spore arbejde, Pull Requests til kodegennemgang og sammensmeltning, og GitHub Actions til automatisering. Over to måneder hjalp denne opsætning os med at levere 404 releases og skrive mere end 230.000 linjer kode.
Dette indlæg forklarer, hvordan vi fik det til at fungere, og hvorfor det største problem aldrig var AI-evner, men menneskelig koordinering.
AI-drevet dev-arbejdsgang i praksis
Når du koordinerer mange AI-agenter parallelt, er flaskehalsen ikke, om modellen kan skrive kode. Den reelle flaskehals er menneskets kognitive belastning
Denne arbejdsgang består af 14 slash-kommandoer, organiseret i tre lag: Deep Dive, Issue Management og PR Management.
Lad os først se på, hvordan min arbejdsgang ser ud, og hvordan en funktion typisk bliver bygget.
-
Kravsafstemning
Et menneske åbner en Claude-session og starter med
/deep-research. Claude indsamler fakta fra kodebasen, dokumentation og relevant kontekst. Vi diskuterer resultaterne og afstemmer, hvilket problem vi faktisk løser. -
Løsningsudforskning
Ved hjælp af
/deep-innovateforeslår Claude flere mulige retninger med fordele og ulemper. Vi diskuterer, indsnævrer og vælger en retning. -
Oprettelse af issue
Vi opretter et GitHub-issue med
/issue-create. Mennesket gennemgår issuen for at sikre, at kravene er tydeligt beskrevet. -
Planlægning og godkendelse
Brug
/issue-planfor at lade Claude fortsætte arbejdet. Claude kører automatisk hele deep-dive-arbejdsgangen og poster resultaterne i issuen, inklusive:- fund fra
/deep-research - sammenligninger fra
/deep-innovate - en konkret implementeringsplan fra
/deep-plan
- fund fra
-
Implementering
Efter godkendelse lader
/issue-actionClaude implementere planen, skrive tests, åbne en PR og sikre, at CI består. -
Gennemgang og sammensmeltning
Vi bruger
/pr-reviewtil en struktureret gennemgang og laver derefter en endelig menneskelig gennemgang før sammensmeltning.Mennesket griber ind ved tre checkpoints: krav, retning og accept. Alt andet kører autonomt.
Tankeskifte: Du leder et team af AI-udviklere
Det øjeblik, jeg indså, at vi havde brug for en struktureret arbejdsgang, var da flere Claude-sessioner faktisk gjorde tingene værre. Jo flere instanser jeg kørte parallelt, desto sværere blev det at holde styr på, hvad hver enkelt lavede, hvilken status arbejdet havde, og hvad der allerede var besluttet.
Uden eksterne værktøjer kunne jeg simpelthen ikke styre så mange Claude-instanser på én gang. Det var dér, det gik op for mig: Dette var ikke et AI-problem, men et ledelsesproblem.
GitHub er allerede det naturlige værktøj til samarbejde i softwareudvikling, så i stedet for at opfinde noget nyt begyndte jeg at behandle Claude på samme måde som en menneskelig kollega. Da jeg gjorde det, kunne min ledelseskapacitet pludselig skalere.
Ti års erfaring med projekt- og teamledelse gav pludselig mening i denne nye kontekst. Ved at behandle Claude som et teammedlem og GitHub som vores fælles kommunikations- og ledelsesrum blev hele systemet håndterbart igen.
En god teamleder ved, hvornår man skal engagere sig, og hvornår man skal træde tilbage:
| Checkpoint | Hvad jeg gør | Hvad AI gør |
|---|---|---|
| Krav | Afstemmer problemet, afklarer omfang | Undersøger kodebase, indsamler kontekst |
| Retning | Gennemgår fund, godkender tilgang | Foreslår 2-3 tilgange, vurderer fordele/ulemper |
| Accept | Gennemgår PR, verificerer kvalitet | Implementerer, tester, retter CI |
Dette afspejler, hvordan effektive softwareteams arbejder. Jeg mikrostyrer ikke udviklere, men sætter klare krav, gennemgår nøglebeslutninger og verificerer det endelige output. Det samme princip gælder, når man leder AI-agenter.
Deep dive-flowet sikrer struktureret, langsom tænkning
Deep dive-arbejdsgangen tvinger til bevidst tænkning før implementering. Nogle gange kører Claude fast. Når det sker, tvinger vi Claude til at stoppe op og tænke, og så taler vi det igennem sammen. Det har tre faser:
| Fase | Kommando | Formål | Output |
|---|---|---|---|
| Research | /deep-research | Indsamler fakta, forstår kontekst | research.md |
| Innovate | /deep-innovation | Udforsker flere tilgange | innovate.md |
| Plan | /deep-plan | Definerer konkrete trin | plan.md |
Hver fase har strenge grænser.
- Research: ingen forslag
- Innovate: ingen detaljer
- Plan: ingen implementering
Disse begrænsninger tvinger Claude til langsom, bevidst ræsonnement i stedet for at springe direkte til kode. Uden dem overses ofte edge cases og arkitektoniske hensyn!
Eksempel på brug
/deep-research investigate the authentication flow, I'm seeing token expiration issues
[Claude researches, analyzes 12 related files, finds 3 similar patterns]
/deep-innovate what are our options for fixing this?
[Claude presents 3 approaches with trade-offs, you pick one]
/issue-create let's track this fix
Til simple opgaver kan du springe deep dive over og gå direkte til /issue-create.
Til komplekse opgaver med teknisk usikkerhed hjælper deep dive-faserne med at sikre, at du og Claude er afstemt, før implementeringen starter.
Brug GitHub som delt hukommelse
De fleste AI-værktøjer behandler kontekst som midlertidig. Når sessionen slutter, forsvinder hukommelsen.
VM0 bruger GitHub som vedvarende hukommelse:
| GitHub-funktion | Hvad den gemmer |
|---|---|
| Issue body | Krav og beslutninger |
| Issue-kommentarer | Research, muligheder, planer |
| PR-kommentarer | Gennemgange og opsummeringer |
| Labels | Workflow-status |
Dette løser også et menneskeligt problem: konteksthentning.
Når jeg styrer 8+ Claude-instanser, får jeg notifikationer om, at arbejdet er færdigt. Men jeg kan ikke rekonstruere ud fra Claudes samtale, hvad den lavede, hvilke beslutninger der blev taget, eller hvad status er.
GitHub-issues løser dette. Hver issue viser:
- De oprindelige krav
- Research-fund (hvad blev opdaget)
- Innovationsfase (hvilke muligheder blev overvejet)
- Den godkendte plan (hvad skal implementeres)
Dette strukturerede format gør gennemgang effektiv. Så jeg kan hurtigt skimme faserne, forstå tilgangen og godkende eller bede om ændringer – uden at skulle huske den oprindelige samtale.
Når arbejdet er færdigt, behøver jeg ikke huske, hvad der skete i et chatvindue. Jeg kan åbne issuen og se hele historien, struktureret og nedskrevet.
Overlevering mellem agenter
Fordi al kontekst ligger i GitHub, kan arbejdet flyttes mellem agenter uden problemer:
- Én agent opretter en issue eller PR
- En anden fortsætter senere med
/deep-research issue 123eller/issue-plan 123eller/deep-research PR 124
Ved lange diskussioner konsoliderer /issue-compact alt til en ren issue body. Det gør overlevering let for både mennesker og AI.
Lad os opsummere workflow-mønstrene
Efter alt dette vil jeg opsummere nogle praktiske tips.
Simple opgaver
/issue-create → /issue-plan → /issue-action → /pr-check-and-merge
Brug dette, når kravene er klare, og arbejdet er ligetil.
Komplekse opgaver
/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check
Dette forhindrer spildt arbejde på den forkerte tilgang.
Parallelt arbejde
Flere agenter kan arbejde samtidig, mens mennesket gennemgår færdige checkpoints. Her skalerer arbejdsgangen bedst.
Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements
Kommandoreference
Deep dive-kommandoer
| Kommando | Formål |
|---|---|
/deep-research | Indsamler information, forstår kodebase. Ingen forslag tilladt. |
/deep-innovate | Udforsker 2-3 tilgange, vurderer fordele/ulemper. Ingen kode tilladt. |
/deep-plan | Opretter konkrete implementeringstrin. Ingen implementering tilladt. |
Issue-kommandoer
| Kommando | Formål |
|---|---|
/issue-create | Opretter issue ud fra samtalekontekst |
/issue-bug | Opretter bug report med reproduktionstrin |
/issue-feature | Opretter feature request med fokus på krav |
/issue-plan | Kører fuld deep-dive-arbejdsgang, poster resultater til issue |
/issue-action | Fortsætter implementering efter menneskelig godkendelse |
/issue-compact | Konsoliderer issue body + kommentarer til overlevering |
PR-kommandoer
| Kommando | Formål |
|---|---|
/pr-check | Overvåger CI-pipeline, auto-rettelser, prøver op til 3 gange |
/pr-review | Gennemgår PR commit-for-commit mod projektstandarder |
/pr-comment | Opsummerer samtalediskussion til PR-kommentar |
Kom godt i gang
- Start simpelt: Brug
/issue-create→/issue-plan→/issue-actiontil din første opgave - Tilføj deep dive til komplekse opgaver: Når kravene er uklare eller teknisk komplekse, start med
/deep-research - Skaler gradvist: Tilføj flere Claude-instanser, efterhånden som du bliver tryg ved gennemgangsrytmen
- Stol på processen: Lad Claude arbejde autonomt mellem checkpoints
Arbejdsgangen er designet til at blive taget i brug trinvis. Du behøver ikke bruge alle 14 kommandoer fra dag ét. Start med det grundlæggende issue-flow, og tilføj så deep dive-faser og parallelt arbejde, når du får mere erfaring.
Skaleringshensyn: Hvad gør du, når du har flere agenter
Arbejdsgangen er testet med 10+ samtidige Claude-instanser. Vores anbefaling:
- Op til 10 agenter: Komfortabelt for tæt samarbejde med hver
- Over 10: Ikke anbefalet
Den begrænsende faktor er ikke arbejdsgangen, men menneskets opmærksomhed og beslutningskvalitet. Når du styrer mere end 10 agenter, risikerer du at blive en flaskehals ved gennemgangspunkter, og beslutningskvaliteten begynder at falde.
Det klassiske "to pizza team"-princip gælder her. De samme begrænsninger, der gælder for menneskelige teams, gælder også for, hvor mange AI-agenter én person effektivt kan styre.
Jeg undersøger i øjeblikket en 8×8 to-niveau teamstruktur for at skalere ud over 10 agenter, men har endnu ikke udviklet effektive praksisser. Jeg deler mere, når der er konkrete resultater…
VM0 dev-arbejdsgangen ændrer vores syn på softwareudvikling, når AI bliver en del af teamet.
Når du behandler AI-agenter som teammedlemmer frem for værktøjer, falder alt på plads. GitHub bliver dit teams fælles hukommelse. Issues bliver arbejdsopgaver. PRs bliver leverancer. Og du bliver teamlederen, der fokuserer på arkitektur, retning og kvalitet, mens dit AI-team håndterer implementeringen.
Sådan leverede vi 404 releases på 2 måneder. Og sådan kan du skalere din egen udvikling med AI.
