Workflow deweloperski VM0: Zarządzanie agentami AI jak zespołem

W zespole deweloperskim VM0 każdy programista pracuje jednocześnie z wieloma instancjami Claude Code. Zazwyczaj z więcej niż ośmioma.

Traktujemy Claude Code tak samo, jak prawdziwego dewelopera. (Tak, nasza firma pół-żartem nazywa się AI Colleagues Co!)

Z tego powodu filozofia projektowania workflow deweloperskiego VM0 odzwierciedla klasyczne praktyki zarządzania zespołem w inżynierii oprogramowania.

Używamy GitHub Issues do śledzenia pracy, Pull Requests do przeglądu i scalania kodu oraz GitHub Actions do automatyzacji. W ciągu dwóch miesięcy to podejście pozwoliło nam wdrożyć 404 wersje i napisać ponad 230,000 linii kodu.

Ten wpis wyjaśnia, jak to uczyniliśmy wykonalnym i dlaczego kluczowym problemem nigdy nie były możliwości AI, lecz koordynacja ludzka.

Praktyka workflow deweloperskiego z AI

Gdy koordynujesz wielu agentów AI równolegle, wąskim gardłem nie jest to, czy model potrafi pisać kod. Prawdziwym ograniczeniem jest obciążenie poznawcze człowieka.

Ten workflow składa się z 14 komend slash, zorganizowanych w trzy warstwy: Deep Dive, Zarządzanie Issue i Zarządzanie PR.

Najpierw zobaczmy, jak wygląda mój workflow i jak zwykle powstaje nowa funkcja.

Uzgodnienie wymagań

Człowiek otwiera sesję Claude i zaczyna od /deep-research. Claude zbiera fakty z bazy kodu, dokumentacji i odpowiedniego kontekstu. Omawiamy ustalenia i uzgadniamy, jaki problem faktycznie rozwiązujemy.
Eksploracja rozwiązań

Za pomocą /deep-innovate Claude proponuje kilka możliwych kierunków wraz z kompromisami. Dyskutujemy, zawężamy i wybieramy kierunek.
Tworzenie issue

Tworzymy issue na GitHubie używając /issue-create. Człowiek przegląda issue, by upewnić się, że wymagania są jasno określone.
Planowanie i akceptacja

Użyj /issue-plan, by Claude kontynuował pracę. Claude automatycznie uruchomi pełny workflow deep-dive i zamieści wyniki w issue, w tym:
1. ustalenia z /deep-research
2. porównania z /deep-innovate
3. konkretny plan wdrożenia z /deep-plan
Implementacja

Po akceptacji /issue-action pozwala Claude wdrożyć plan, napisać testy, otworzyć PR i upewnić się, że CI przechodzi.
Przegląd i scalenie

Używamy /pr-review do uporządkowanego przeglądu, a następnie wykonujemy końcowy przegląd ludzki przed scaleniem.

Człowiek interweniuje w trzech punktach kontrolnych: wymagania, kierunek i akceptacja. Wszystko inne przebiega autonomicznie.

Zmiana podejścia: prowadzisz zespół deweloperów AI

Momentem przełomowym było uświadomienie sobie, że potrzebujemy uporządkowanego workflow, gdy dodanie kolejnych sesji Claude faktycznie pogarszało sytuację. Im więcej instancji uruchamiałem równolegle, tym trudniej było śledzić, co każda robi, na jakim etapie jest praca i jakie decyzje już zapadły.

Bez narzędzi zewnętrznych po prostu nie byłem w stanie zarządzać tyloma instancjami Claude naraz. Wtedy zrozumiałem: to nie był problem AI, tylko zarządzania.

GitHub już jest naturalnym narzędziem współpracy w rozwoju oprogramowania, więc zamiast wymyślać coś nowego, zacząłem traktować Claude jak członka zespołu. Gdy to zrobiłem, moja przepustowość zarządzania nagle wzrosła.

Dziesięć lat doświadczenia w zarządzaniu projektami i zespołami wreszcie nabrało sensu w tym nowym kontekście. Traktując Claude jako członka zespołu, a GitHub jako wspólną przestrzeń komunikacji i zarządzania, cały system znów stał się możliwy do opanowania.

Dobry lider zespołu wie, kiedy się zaangażować, a kiedy się wycofać:

Punkt kontrolny	Co robię ja	Co robi AI
Wymagania	Uzgadniam problem, doprecyzowuję zakres	Bada bazę kodu, zbiera kontekst
Kierunek	Przeglądam ustalenia, akceptuję podejście	Proponuje 2-3 podejścia, ocenia kompromisy
Akceptacja	Przeglądam PR, weryfikuję jakość	Implementuje, testuje, naprawia CI

To odzwierciedla sposób działania skutecznych zespołów programistycznych. Nie mikrozarządzam deweloperem, lecz stawiam jasne wymagania, przeglądam kluczowe decyzje i weryfikuję końcowy rezultat. Ta sama zasada dotyczy zarządzania agentami AI.

Deep dive wymusza uporządkowane, powolne myślenie

Workflow deep dive wymusza przemyślenie przed implementacją. Czasem Claude trafia na ślepy zaułek. Wtedy zmuszamy Claude do zatrzymania się i wspólnego przemyślenia sprawy. Ma to trzy fazy:

Faza	Komenda	Cel	Wynik
Research	/deep-research	Zbieranie faktów, zrozumienie kontekstu	research.md
Innovate	/deep-innovation	Eksploracja wielu podejść	innovate.md
Plan	/deep-plan	Określenie konkretnych kroków	plan.md

Każda faza ma ścisłe granice.

Research: bez sugestii
Innovate: bez szczegółów
Plan: bez implementacji

Te ograniczenia zmuszają Claude do powolnego, przemyślanego rozumowania zamiast natychmiastowego przechodzenia do kodu. Bez nich często pomija się przypadki brzegowe i kwestie architektoniczne!

Przykład użycia

/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

Przy prostych zadaniach możesz pominąć deep dive i przejść bezpośrednio do /issue-create.

Przy złożonych zadaniach z niepewnością techniczną fazy deep dive pomagają upewnić się, że Ty i Claude jesteście zgodni przed rozpoczęciem implementacji.

Używaj GitHub jako wspólnej pamięci

Większość narzędzi AI traktuje kontekst jako tymczasowy. Po zakończeniu sesji pamięć znika.

VM0 używa GitHub jako trwałej pamięci:

Funkcja GitHub	Co przechowuje
Treść issue	Wymagania i decyzje
Komentarze do issue	Badania, opcje, plany
Komentarze do PR	Przeglądy i podsumowania
Etykiety	Stan workflow

To rozwiązuje też ludzki problem: odzyskiwanie kontekstu.

Gdy zarządzam 8+ instancjami Claude, otrzymuję powiadomienia o zakończeniu pracy. Ale nie mogę odtworzyć z rozmowy z Claude, co robił, jakie decyzje podjął ani jaki jest obecny stan.

GitHub Issues to rozwiązują. Każde issue pokazuje:

Oryginalne wymagania
Wyniki badań (co odkryto)
Faza innowacji (jakie opcje rozważano)
Zatwierdzony plan (co będzie wdrożone)

Ta uporządkowana forma usprawnia przegląd. Mogę szybko przejrzeć fazy, zrozumieć podejście i zaakceptować lub zgłosić poprawki, bez konieczności pamiętania oryginalnej rozmowy.

Po zakończeniu pracy nie muszę pamiętać, co działo się w oknie czatu. Wystarczy otworzyć issue i zobaczyć całą historię, uporządkowaną i zapisaną.

Przekazywanie pracy między agentami

Ponieważ cały kontekst znajduje się na GitHub, praca może płynnie przechodzić między agentami:

Jeden agent tworzy issue lub PR
Inny kontynuuje później używając /deep-research issue 123 lub /issue-plan 123 lub /deep-research PR 124

Przy długich dyskusjach /issue-compact konsoliduje wszystko w przejrzystą treść issue. To ułatwia przekazanie zarówno ludziom, jak i AI.

Podsumujmy wzorce workflow

Po tym wszystkim podsumuję kilka praktycznych wskazówek.

Proste zadania

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

Używaj tego, gdy wymagania są jasne, a praca prosta.

Złożone zadania

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

To zapobiega marnowaniu wysiłku na niewłaściwe podejście.

Praca równoległa

Wielu agentów może pracować jednocześnie, podczas gdy człowiek przegląda ukończone punkty kontrolne. Tu workflow skaluje się najlepiej.

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

Referencja komend

Komendy deep dive

Komenda	Cel
`/deep-research`	Zbieranie informacji, zrozumienie bazy kodu. Bez sugestii.
`/deep-innovate`	Eksploracja 2-3 podejść, ocena kompromisów. Bez kodu.
`/deep-plan`	Tworzenie konkretnych kroków wdrożenia. Bez implementacji.

Komendy issue

Komenda	Cel
`/issue-create`	Utwórz issue z kontekstu rozmowy
`/issue-bug`	Utwórz zgłoszenie błędu z krokami odtworzenia
`/issue-feature`	Utwórz zgłoszenie funkcji skupione na wymaganiach
`/issue-plan`	Wykonaj pełny workflow deep-dive, zamieść wyniki w issue
`/issue-action`	Kontynuuj implementację po akceptacji człowieka
`/issue-compact`	Konsoliduj treść issue + komentarze do przekazania

Komendy PR

Komenda	Cel
`/pr-check`	Monitoruj pipeline CI, automatycznie naprawiaj, ponawiaj do 3 razy
`/pr-review`	Przeglądaj PR commit po commicie względem standardów projektu
`/pr-comment`	Podsumuj dyskusję do komentarza PR

Jak zacząć

Zacznij prosto: Użyj /issue-create → /issue-plan → /issue-action przy pierwszym zadaniu
Dodaj deep dive do złożonych zadań: Gdy wymagania są niejasne lub technicznie złożone, zacznij od /deep-research
Skaluj stopniowo: Dodawaj kolejne instancje Claude, gdy przyzwyczaisz się do rytmu przeglądów
Zaufaj procesowi: Pozwól Claude pracować autonomicznie między punktami kontrolnymi

Workflow został zaprojektowany do wdrażania stopniowego. Nie musisz używać wszystkich 14 komend od pierwszego dnia. Zacznij od podstawowego przepływu issue, potem dodawaj fazy deep dive i pracę równoległą wraz ze wzrostem pewności.

Skalowanie: co zrobić, gdy masz więcej agentów

Workflow został przetestowany z 10+ równoczesnymi instancjami Claude. Nasza rekomendacja:

Do 10 agentów: Wygodna, głęboka współpraca z każdym
Powyżej 10: Nie zalecane

Ograniczeniem nie jest workflow, lecz uwaga człowieka i jakość decyzji. Przy zarządzaniu więcej niż 10 agentami ryzykujesz, że staniesz się wąskim gardłem na punktach przeglądu, a jakość decyzji zacznie spadać.

Klasyczna zasada "zespół na dwie pizze" ma tu zastosowanie. Te same ograniczenia, które dotyczą wielkości zespołu ludzkiego, ograniczają też liczbę agentów AI, którymi jedna osoba może skutecznie zarządzać.

Obecnie testuję strukturę dwupoziomowego zespołu 8×8 do skalowania powyżej 10 agentów, ale nie wypracowałem jeszcze skutecznych praktyk. Podzielę się więcej, gdy będą konkretne rezultaty…

Workflow deweloperski VM0 zmienia sposób myślenia o rozwoju oprogramowania, gdy AI staje się częścią zespołu.

Gdy traktujesz agentów AI jak członków zespołu, a nie narzędzia, wszystko zaczyna działać. GitHub staje się wspólną pamięcią zespołu. Issues to zadania. PR to rezultaty. A Ty jesteś liderem zespołu, skupiając się na architekturze, kierunku i jakości, podczas gdy Twój zespół AI realizuje wdrożenie.

Tak wdrożyliśmy 404 wersje w ciągu 2 miesięcy. I tak możesz skalować własny rozwój z AI.