VM0-utvecklingsflöde: Hantera AI-agenter som ett team

I VM0-utvecklingsteamet arbetar varje utvecklare med flera Claude Code-instansar samtidigt. Vanligtvis fler än åtta.

Vi behandlar Claude Code på samma sätt som vi behandlar en riktig utvecklare. (Ja, vårt företag heter halvt på skämt AI Colleagues Co!)

Därför speglar designfilosofin bakom VM0-utvecklingsflödet klassiska teamledningsmetoder inom mjukvaruutveckling.

Vi använder GitHub Issues för att följa upp arbete, Pull Requests för kodgranskning och sammanslagning, samt GitHub Actions för automation. Under en period av två månader hjälpte denna uppsättning oss att leverera 404 releaser och skriva mer än 230,000 rader kod.

Detta inlägg förklarar hur vi fick det att fungera, och varför det största problemet aldrig var AI-förmåga, utan mänsklig samordning.

AI-drivet utvecklingsflöde i praktiken

När du koordinerar många AI-agenter parallellt är flaskhalsen inte om modellen kan skriva kod. Den verkliga flaskhalsen är mänsklig kognitiv belastning.

Detta arbetsflöde består av 14 slash-kommandon, organiserade i tre lager: Deep Dive, Issue Management och PR Management.

Låt oss först titta på hur mitt arbetsflöde ser ut och hur en funktion vanligtvis byggs.

Kravjustering

En människa öppnar en Claude-session och börjar med /deep-research. Claude samlar in fakta från kodbasen, dokumentation och relevant kontext. Vi diskuterar fynden och enas om vilket problem vi faktiskt löser.
Utforskning av lösningar

Med hjälp av /deep-innovate föreslår Claude flera möjliga riktningar, med avvägningar. Vi diskuterar, snävar in och väljer en riktning.
Skapa ärende

Vi skapar ett GitHub-ärende med /issue-create. Människan granskar ärendet för att säkerställa att kraven är tydligt fångade.
Planering och godkännande

Använd /issue-plan för att låta Claude fortsätta arbetet. Claude kör automatiskt hela deep-dive-flödet och postar resultaten i ärendet, inklusive:
1. fynd från /deep-research
2. jämförelser från /deep-innovate
3. en konkret implementationsplan från /deep-plan
Implementering

Efter godkännande låter /issue-action Claude implementera planen, skriva tester, öppna en PR och säkerställa att CI går igenom.
Granskning och sammanslagning

Vi använder /pr-review för en strukturerad granskning och gör sedan en sista mänsklig granskning innan sammanslagning.

Människan ingriper vid tre kontrollpunkter: krav, riktning och acceptans. Allt annat körs autonomt.

Tankeskifte: du leder ett team av AI-utvecklare

Jag insåg att vi behövde ett strukturerat arbetsflöde när fler Claude-sessioner faktiskt gjorde allt svårare. Ju fler instanser jag körde parallellt, desto svårare blev det att hålla reda på vad varje gjorde, vilket läge arbetet var i och vad som redan hade beslutats.

Utan externa verktyg kunde jag helt enkelt inte hantera så många Claude-instanser samtidigt. Då insåg jag: detta var inte ett AI-problem, utan ett ledningsproblem.

GitHub är redan det naturliga verktyget för samarbete inom mjukvaruutveckling, så istället för att uppfinna något nytt började jag behandla Claude som en mänsklig lagkamrat. När jag gjorde det, skalade min ledningskapacitet plötsligt.

Tio års erfarenhet av projekt- och teamledning fick plötsligt mening i detta nya sammanhang. Genom att behandla Claude som en teammedlem och GitHub som vår gemensamma kommunikations- och ledningsyta blev hela systemet hanterbart igen.

En bra teamledare vet när man ska engagera sig och när man ska kliva tillbaka:

Kontrollpunkt	Vad jag gör	Vad AI gör
Krav	Enas om problemet, klargör omfattning	Utforskar kodbas, samlar kontext
Riktning	Granskar fynd, godkänner tillvägagångssätt	Föreslår 2-3 tillvägagångssätt, utvärderar avvägningar
Acceptans	Granskar PR, verifierar kvalitet	Implementerar, testar, fixar CI

Detta speglar hur effektiva mjukvaruteam arbetar. Jag detaljstyr inte utvecklare utan sätter tydliga krav, granskar viktiga beslut och verifierar slutresultatet. Samma princip gäller när man leder AI-agenter.

Deep dive-flödet tvingar fram strukturerat, långsamt tänkande

Deep dive-arbetsflödet tvingar fram eftertänksamhet före implementation. Ibland kör Claude fast. Då tvingar vi Claude att stanna upp och tänka, och sedan pratar vi igenom det tillsammans. Det har tre faser:

Fas	Kommando	Syfte	Utdata
Research	/deep-research	Samla fakta, förstå kontext	research.md
Innovate	/deep-innovation	Utforska flera tillvägagångssätt	innovate.md
Plan	/deep-plan	Definiera konkreta steg	plan.md

Varje fas har tydliga gränser.

Research: inga förslag
Innovate: inga detaljer
Plan: ingen implementation

Dessa begränsningar tvingar Claude till långsamt, eftertänksamt resonemang istället för att hoppa direkt till kod. Utan dem missas ofta specialfall och arkitekturfrågor!

Användningsexempel

/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

För enkla uppgifter kan du hoppa över deep dive och gå direkt till /issue-create.

För komplexa uppgifter med teknisk osäkerhet hjälper deep dive-faserna dig och Claude att vara överens innan implementationen börjar.

Använd GitHub som gemensamt minne

De flesta AI-verktyg behandlar kontext som tillfällig. När sessionen avslutas försvinner minnet.

VM0 använder GitHub som beständigt minne:

GitHub-funktion	Vad den lagrar
Issue body	Krav och beslut
Issue comments	Research, alternativ, planer
PR comments	Granskningar och sammanfattningar
Labels	Arbetsflödets status

Detta löser också ett mänskligt problem: återhämtning av kontext.

När jag hanterar 8+ Claude-instanser får jag notiser om att arbete är klart. Men jag kan inte återskapa från Claudes konversation vad den gjorde, vilka beslut som togs eller vad status är.

GitHub-ärenden löser detta. Varje ärende visar:

De ursprungliga kraven
Research-fynd (vad som upptäcktes)
Innovationsfasen (vilka alternativ som övervägdes)
Den godkända planen (vad som ska implementeras)

Detta strukturerade format gör granskning effektiv. Jag kan snabbt ögna igenom faserna, förstå tillvägagångssättet och godkänna eller begära ändringar, utan att behöva minnas den ursprungliga konversationen.

När arbetet är klart behöver jag inte minnas vad som hände i ett chattfönster. Jag kan öppna ärendet och se hela historien, strukturerad och nedskriven.

Överlämning mellan agenter

Eftersom all kontext finns i GitHub kan arbete flyttas mellan agenter sömlöst:

En agent skapar ett ärende eller PR
En annan fortsätter senare med /deep-research issue 123 eller /issue-plan 123 eller /deep-research PR 124

Vid långa diskussioner konsoliderar /issue-compact allt till en ren ärendebeskrivning. Detta gör överlämningar enkla för både människor och AI.

Låt oss sammanfatta arbetsflödets mönster

Efter allt detta vill jag sammanfatta några praktiska tips.

Enkla uppgifter

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

Använd detta när kraven är tydliga och arbetet är rakt på sak.

Komplexa uppgifter

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

Detta förhindrar bortkastat arbete på fel tillvägagångssätt.

Parallellt arbete

Flera agenter kan arbeta samtidigt medan människan granskar färdiga kontrollpunkter. Här skalar arbetsflödet som bäst.

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

Kommandoreferens

Deep dive-kommandon

Kommando	Syfte
`/deep-research`	Samla information, förstå kodbasen. Inga förslag tillåtna.
`/deep-innovate`	Utforska 2-3 tillvägagångssätt, utvärdera avvägningar. Ingen kod tillåten.
`/deep-plan`	Skapa konkreta implementationssteg. Ingen implementation tillåten.

Issue-kommandon

Kommando	Syfte
`/issue-create`	Skapa ärende från konversationskontext
`/issue-bug`	Skapa buggrapport med reproduktionssteg
`/issue-feature`	Skapa funktionsförfrågan fokuserad på krav
`/issue-plan`	Kör hela deep-dive-flödet, posta resultat i ärendet
`/issue-action`	Fortsätt implementation efter mänskligt godkännande
`/issue-compact`	Konsolidera ärendebeskrivning + kommentarer för överlämning

PR-kommandon

Kommando	Syfte
`/pr-check`	Övervaka CI-pipeline, auto-fixa, försök upp till 3 gånger
`/pr-review`	Granska PR commit-för-commit mot projektstandard
`/pr-comment`	Sammanfatta konversationsdiskussion till PR-kommentar

Kom igång

Börja enkelt: Använd /issue-create → /issue-plan → /issue-action för din första uppgift
Lägg till deep dive för komplexa uppgifter: När kraven är oklara eller tekniskt komplexa, börja med /deep-research
Skala gradvis: Lägg till fler Claude-instanser när du blir bekväm med granskningsrytmen
Lita på processen: Låt Claude arbeta autonomt mellan kontrollpunkterna

Arbetsflödet är utformat för att kunna tas i bruk stegvis. Du behöver inte använda alla 14 kommandon från dag ett. Börja med det grundläggande ärendeflödet och lägg sedan till deep dive-faser och parallellt arbete när du blir trygg.

Skalningsaspekter: Vad du gör när du har fler agenter

Arbetsflödet har testats med 10+ samtidiga Claude-instanser. Vår rekommendation:

Upp till 10 agenter: Bekvämt för djupgående samarbete med var och en
Över 10: Rekommenderas inte

Den begränsande faktorn är inte arbetsflödet, utan mänsklig uppmärksamhet och beslutskvalitet. När du hanterar fler än 10 agenter riskerar du att bli en flaskhals vid granskningspunkter, och beslutskvaliteten börjar försämras.

Den klassiska "två pizza-team"-principen gäller här. Samma begränsningar som sätter tak för mänskliga team gäller även för hur många AI-agenter en person effektivt kan leda.

Jag utforskar just nu en 8×8 tvåstegsteamstruktur för att skala bortom 10 agenter, men har ännu inte utvecklat effektiva metoder. Jag delar mer när det finns konkreta resultat…

VM0-utvecklingsflödet förändrar hur vi ser på mjukvaruutveckling när AI blir en del av teamet.

När du behandlar AI-agenter som teammedlemmar istället för verktyg faller allt på plats. GitHub blir teamets gemensamma minne. Issues blir arbetsuppgifter. PRs blir leveranser. Och du blir teamledaren, med fokus på arkitektur, riktning och kvalitet medan ditt AI-team hanterar implementationen.

Det är så vi levererade 404 releaser på 2 månader. Och det är så du kan skala din egen utveckling med AI.