I VM0-utviklingsteamet jobber hver utvikler med flere Claude Code-installasjoner samtidig. Vanligvis mer enn åtte.
Vi behandler Claude Code på samme måte som vi behandler en ekte utvikler. (Ja, selskapet vårt heter halvveis spøkefullt AI Colleagues Co!)
Derfor speiler designfilosofien bak VM0-utviklingsflyten klassiske teamledelsespraksiser innen programvareutvikling.
Vi bruker GitHub Issues for å spore arbeid, Pull Requests for kodegjennomgang og sammenslåing, og GitHub Actions for å håndtere automatisering. Over to måneder hjalp dette oppsettet oss å levere 404 utgivelser og skrive mer enn 230,000 kodelinjer.
Dette innlegget forklarer hvordan vi fikk dette til å fungere, og hvorfor hovedproblemet aldri var AI-kapasitet, men menneskelig koordinering.
AI-drevet utviklingsflyt i praksis
Når du koordinerer mange AI-agenter parallelt, er flaskehalsen ikke om modellen kan skrive kode. Den virkelige flaskehalsen er menneskelig kognitiv belastning.
Denne arbeidsflyten består av 14 slash-kommandoer, organisert i tre lag: Deep Dive, Issue Management og PR Management.
La oss først se på hvordan min arbeidsflyt ser ut og hvordan en funksjon vanligvis blir bygget.
-
Kravavklaring
Et menneske åpner en Claude-økt og starter med
/deep-research. Claude samler fakta fra kodebasen, dokumentasjon og relevant kontekst. Vi diskuterer funnene og blir enige om hvilket problem vi faktisk løser. -
Løsningsutforskning
Ved å bruke
/deep-innovateforeslår Claude flere mulige retninger, med avveininger. Vi diskuterer, snevrer inn og velger en retning. -
Opprettelse av issue
Vi oppretter en GitHub-issue ved hjelp av
/issue-create. Mennesket gjennomgår saken for å sikre at kravene er tydelig beskrevet. -
Planlegging og godkjenning
Bruk
/issue-planfor å la Claude fortsette arbeidet. Claude vil automatisk kjøre hele deep-dive-arbeidsflyten og poste resultatene til saken, inkludert:- funn fra
/deep-research - sammenligninger fra
/deep-innovate - en konkret implementeringsplan fra
/deep-plan
- funn fra
-
Implementering
Etter godkjenning lar
/issue-actionClaude implementere planen, skrive tester, åpne en PR og sikre at CI består. -
Gjennomgang og sammenslåing
Vi bruker
/pr-reviewfor en strukturert gjennomgang, deretter gjør vi en siste menneskelig gjennomgang før sammenslåing.Mennesket griper inn på tre sjekkpunkter: krav, retning og akseptanse. Alt annet kjøres autonomt.
Tankeskifte: du leder et team av AI-utviklere
Øyeblikket jeg innså at vi trengte en strukturert arbeidsflyt, var da det å legge til flere Claude-økter faktisk gjorde ting verre. Jo flere instanser jeg kjørte parallelt, desto vanskeligere ble det å holde oversikt over hva hver enkelt gjorde, hvilken tilstand arbeidet var i, og hva som allerede var bestemt.
Uten eksterne verktøy kunne jeg rett og slett ikke håndtere så mange Claude-installasjoner samtidig. Da gikk det opp for meg: dette var ikke et AI-problem, det var et ledelsesproblem.
GitHub er allerede det naturlige verktøyet for samarbeid i programvareutvikling, så i stedet for å finne opp noe nytt, begynte jeg å behandle Claude på samme måte som en menneskelig kollega. Da jeg gjorde det, skalerte plutselig min ledelseskapasitet.
Ti års erfaring med prosjekt- og teamledelse fikk plutselig mening i denne nye konteksten. Ved å behandle Claude som et teammedlem og GitHub som vårt felles kommunikasjons- og ledelsesrom, ble hele systemet håndterbart igjen.
En god teamleder vet når man skal engasjere seg og når man skal trekke seg tilbake:
| Sjekkpunkt | Hva jeg gjør | Hva AI gjør |
|---|---|---|
| Krav | Avklarer problemet, tydeliggjør omfang | Undersøker kodebase, samler kontekst |
| Retning | Gjennomgår funn, godkjenner tilnærming | Foreslår 2-3 tilnærminger, vurderer avveininger |
| Akseptanse | Gjennomgår PR, verifiserer kvalitet | Implementerer, tester, fikser CI |
Dette speiler hvordan effektive programvareteam opererer. Jeg mikrostyrer ikke utviklere, men setter tydelige krav, gjennomgår viktige beslutninger og verifiserer sluttresultatet. Det samme prinsippet gjelder når man leder AI-agenter.
Deep dive-flyten sikrer strukturert, langsom tenkning
Deep dive-arbeidsflyten tvinger frem bevisst tenkning før implementering. Noen ganger kjører Claude seg fast. Når det skjer, tvinger vi Claude til å stoppe opp og tenke, og så snakker vi det gjennom sammen. Den har tre faser:
| Fase | Kommando | Formål | Utdata |
|---|---|---|---|
| Research | /deep-research | Samle fakta, forstå kontekst | research.md |
| Innovate | /deep-innovation | Utforske flere tilnærminger | innovate.md |
| Plan | /deep-plan | Definere konkrete steg | plan.md |
Hver fase har strenge grenser.
- Research: ingen forslag
- Innovate: ingen detaljer
- Plan: ingen implementering
Disse begrensningene tvinger Claude til langsom, bevisst resonnering i stedet for å hoppe rett til kode. Uten dem blir ofte hjørnetilfeller og arkitektoniske hensyn oversett!
Brukseksempel
/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
For enkle oppgaver kan du hoppe over deep dive og gå direkte til /issue-create.
For komplekse oppgaver med teknisk usikkerhet hjelper deep dive-fasene deg og Claude å være samkjørte før implementeringen starter.
Bruk GitHub som delt minne
De fleste AI-verktøy behandler kontekst som midlertidig. Når økten avsluttes, forsvinner minnet.
VM0 bruker GitHub som vedvarende minne:
| GitHub-funksjon | Hva den lagrer |
|---|---|
| Issue body | Krav og beslutninger |
| Issue-kommentarer | Research, alternativer, planer |
| PR-kommentarer | Gjennomganger og oppsummeringer |
| Labels | Arbeidsflytstatus |
Dette løser også et menneskelig problem: konteksthenting.
Når jeg administrerer 8+ Claude-installasjoner, får jeg varsler om at arbeidet er ferdig. Men jeg kan ikke rekonstruere ut fra samtalen med Claude hva den gjorde, hvilke beslutninger som ble tatt, eller hva status er.
GitHub-issues løser dette. Hver issue viser:
- De opprinnelige kravene
- Research-funn (hva som ble oppdaget)
- Innovasjonsfase (hvilke alternativer som ble vurdert)
- Den godkjente planen (hva som skal implementeres)
Dette strukturerte formatet gjør gjennomgang effektiv. Jeg kan raskt skanne fasene, forstå tilnærmingen og godkjenne eller be om endringer, uten å måtte huske den opprinnelige samtalen.
Når arbeidet er ferdig, trenger jeg ikke huske hva som skjedde i et chatvindu. Jeg kan åpne saken og se hele historien, strukturert og nedskrevet.
Overlevering mellom agenter
Fordi all kontekst ligger i GitHub, kan arbeidet flyttes sømløst mellom agenter:
- Én agent oppretter en issue eller PR
- En annen fortsetter senere med
/deep-research issue 123eller/issue-plan 123eller/deep-research PR 124
For lange diskusjoner konsoliderer /issue-compact alt til en ryddig issue-body. Dette gjør overleveringer enkle for både mennesker og AI.
La oss oppsummere arbeidsflytmønstrene
Etter alt dette, la meg oppsummere noen praktiske tips.
Enkle oppgaver
/issue-create → /issue-plan → /issue-action → /pr-check-and-merge
Bruk dette når kravene er klare og arbeidet er rett frem.
Komplekse oppgaver
/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check
Dette forhindrer bortkastet innsats på feil tilnærming.
Parallelt arbeid
Flere agenter kan jobbe samtidig mens mennesket gjennomgår fullførte sjekkpunkter. Her skalerer arbeidsflyten best.
Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements
Kommandoreferanse
Deep dive-kommandoer
| Kommando | Formål |
|---|---|
/deep-research | Samle informasjon, forstå kodebasen. Ingen forslag tillatt. |
/deep-innovate | Utforske 2-3 tilnærminger, vurdere avveininger. Ingen kode tillatt. |
/deep-plan | Lage konkrete implementeringssteg. Ingen implementering tillatt. |
Issue-kommandoer
| Kommando | Formål |
|---|---|
/issue-create | Opprett issue fra samtalekontekst |
/issue-bug | Opprett feilrapport med reproduksjonstrinn |
/issue-feature | Opprett funksjonsønske med fokus på krav |
/issue-plan | Kjør full deep-dive-arbeidsflyt, post resultater til issue |
/issue-action | Fortsett implementering etter menneskelig godkjenning |
/issue-compact | Konsolider issue-body + kommentarer for overlevering |
PR-kommandoer
| Kommando | Formål |
|---|---|
/pr-check | Overvåk CI-pipeline, auto-fiks, prøv på nytt opptil 3 ganger |
/pr-review | Gjennomgå PR-commit for commit mot prosjektstandarder |
/pr-comment | Oppsummer samtalediskusjon til PR-kommentar |
Kom i gang
- Start enkelt: Bruk
/issue-create→/issue-plan→/issue-actionfor din første oppgave - Legg til deep dive for komplekse oppgaver: Når kravene er uklare eller teknisk komplekse, start med
/deep-research - Skaler gradvis: Legg til flere Claude-installasjoner etter hvert som du blir komfortabel med gjennomgangsrytmen
- Stol på prosessen: La Claude jobbe autonomt mellom sjekkpunktene
Arbeidsflyten er laget for å kunne tas i bruk trinnvis. Du trenger ikke bruke alle 14 kommandoene fra dag én. Start med den grunnleggende issue-flyten, og legg til deep dive-faser og parallelt arbeid etter hvert som du får mer erfaring.
Skaleringshensyn: Hva gjør du når du har flere agenter
Arbeidsflyten er testet med 10+ samtidige Claude-installasjoner. Vår anbefaling:
- Opptil 10 agenter: Komfortabelt for tett samarbeid med hver enkelt
- Over 10: Ikke anbefalt
Den begrensende faktoren er ikke arbeidsflyten, men menneskelig oppmerksomhet og beslutningskvalitet. Når du administrerer mer enn 10 agenter, risikerer du å bli en flaskehals ved gjennomgangssjekkpunktene, og beslutningskvaliteten begynner å svekkes.
Det klassiske "to pizza-team"-prinsippet gjelder her. De samme begrensningene som setter grenser for menneskelige teamstørrelser, setter også grenser for hvor mange AI-agenter én person effektivt kan lede.
Jeg utforsker for tiden en 8×8 to-nivå teamstruktur for å skalere utover 10 agenter, men har ennå ikke utviklet effektive praksiser. Jeg deler mer når det finnes konkrete resultater…
VM0-utviklingsflyten endrer hvordan vi tenker om programvareutvikling når AI blir en del av teamet.
Når du behandler AI-agenter som teammedlemmer i stedet for verktøy, faller alt på plass. GitHub blir teamets felles minne. Issues blir arbeidsoppgaver. PR-er blir leveranser. Og du blir teamlederen, med fokus på arkitektur, retning og kvalitet mens AI-teamet ditt håndterer implementeringen.
Slik leverte vi 404 utgivelser på 2 måneder. Og slik kan du skalere din egen utvikling med AI.
