Tier 2 w zespole — 5-6 parallel agents z rozwiązanymi merge patterns

Pytanie ze scorecardu: Czy zespół używa narzędzi do równoległej pracy agentów (Conductor, Claude Squad, Cursor + git worktrees)? Odpowiedź na maksymalny wynik (3 pkt): Część workflow zespołu — sufit 5‑6 równoległych agentów na developera, z rozwiązanymi merge‑conflict patterns.

Dlaczego to ma znaczenie w 2026 (task per dev → feature per dev per day)

W 2024 jednostką throughputu inżynierskiego był “task per developer”. Senior backend engineer brał jeden ticket w Linearze, otwierał jeden branch, uruchamiał jeden AI pair‑programmer w edytorze i wypychał jeden PR. Stosunek dev:AI wynosił efektywnie 1:1, historia merge’y sprowadzała się do “rebase przed push”, a bottleneck siedział w prędkości pisania człowieka.

W 2026 ta jednostka pękła. Ten sam backend engineer uruchamia teraz pięciu lub sześciu agentów równolegle — jeden pisze migrację, drugi route handler, trzeci poprawia flaky test, który właśnie pokazał linter, czwarty drafftuje changelog, piąty refaktoruje sąsiedni moduł, którego dotknęła migracja. Każdy agent żyje we własnym git worktree na własnym branchu, na własnym modelu (Sonnet 4.5 do routingu, Opus do trudnego refactoringu, GPT‑5‑Codex do migracji), a praca człowieka to już nie “pisać kod” — to “reviewować, mergować, orkiestrować”. Jednostką throughputu jest teraz znacznie bardziej feature per developer per day.

To brzmi jak historia 5‑6x wzrostu produktywności i na poziomie artefaktów nią jest. Ale bottleneck merge’a i review pojawia się szybko. W momencie gdy dwóch agentów dotknie tego samego pliku, dostajesz konflikt tekstowy, który git chętnie zaflaguje, ale żaden agent nie rozwiąże go czysto. W momencie gdy sześciu agentów skończy w tej samej chwili, dostajesz kolejkę review, która rośnie szybciej niż jakikolwiek człowiek ją drenuje. W momencie gdy CI w twoim repo działa szeregowo, twoja równoległość zapada się w kolejkę na etapie merge’a. Tier 2 to poziom, na którym zespół przeszedł już przez dolinę “spróbowałem dwóch agentów i się pobili” i wszedł w działający wzorzec: równoległość per‑dev z prawdziwym sufitem, prawdziwymi narzędziami do konfliktów i prawdziwą merge queue.

Jeśli na to pytanie zdobyłeś 0, twój zespół wciąż siedzi na Tier 0 (jeden developer, jedno okno Cursora, brak worktrees). Jeśli zdobyłeś 1, jeden lub dwóch entuzjastów uruchamia Claude Squad na własnym laptopie, a reszta przygląda się. Tier 2 — trzy punkty — to moment, w którym 5‑6 równoległych agentów na developera jest domyślnym workflow, a historia merge’a jest na tyle rozwiązana, że nikt nie boi się fan‑outu.

Jak wygląda “max score” w praktyce (Tier 2 jako default, merge playbook)

Każdy aktywny developer uruchamia ≥3 równoległych agentów w przeciętny dzień pracy. Nie “może uruchomić, jeśli zechce” — faktycznie uruchamia, codziennie, jako domyślny workflow. Tryb pair‑programmer (jeden agent, siedzimy i patrzymy) jest zarezerwowany do dyskusji projektowych i najtrudniejszych 10% tasków.
Udokumentowany sufit 5‑6 współbieżnych agentów na developera. Empirycznie to punkt, w którym wentylatory laptopa, limity API i pasmo review człowieka osiągają szczyt jednocześnie. Zespół uzgodnił sufit, a narzędzie orchestracji go egzekwuje.
Izolacja worktree jest obowiązkowa, nie opcjonalna. Każdy agent działa we własnym katalogu git worktree na własnym branchu. Nikt nie uruchamia dwóch agentów przeciwko tej samej kopii roboczej. Conductor i Claude Squad to wymuszają; zespoły piszące własny skrypt do worktree dokumentują go w repo.
Merge playbook, który przeżyje 5‑6 PR‑ów wpadających jednego popołudnia. Trzy komponenty: (1) merge queue (GitHub Merge Queue, Mergify lub Aviator) linearyzująca integrację; (2) conflict‑resolving agent wywoływany, gdy git wykryje overlap, z udokumentowanym promptem i wzorcem reviewera; (3) dekompozycja zadań na małe zakresy, żeby agenci rzadko lądowali na tym samym pliku.
Automatyzacja review nadąża za fan‑outem agentów. CodeRabbit / Greptile / Diamond review lądują na każdym PR w ciągu minut; ludzie reviewują review, a nie surowy diff. (Zobacz Q9 niżej.)
Zespół ma nazwy na tryby awarii. “Worktree drift”, “duplicate implementation problem”, “silent rebase loop” — zespoły Tier 2 mają wspólne słownictwo, bo wszyscy uderzyli w te problemy i nauczyli się playbooku.
Pair programming jest nadal narzędziem, nie podłogą. Zespół Tier 2 nie porzuca synchronicznej głębokiej pracy; świadomie wybiera tryb pair dla 10% tasków, w których koszt poznawczy orchestracji pokonałby zysk z równoległości.

Konkretnie: w środę po południu senior engineer odpala sześć worktrees z dokumentu planowania sprintu, idzie na lunch, wraca do czterech zielonych PR‑ów w merge queue, jednego PR z zaflagowanym konfliktem, do którego resolver agent już naszkicował trzy opcje, i jednego agenta, który trafił w rate limit i sam się zapauzował. Czas zegarowy: 90 minut. To, co się wysłało: feature, który w 2024 byłby 2‑dniowym ticketem.

Krajobraz na dziś (zweryfikowany przez web search)

Conductor (orchestracja worktree)

Conductor (od Melty Labs) to kanoniczny Mac‑first dashboard do uruchamiania równoległych agentów Claude Code i Codex, każdy w izolowanym git worktree. Siedzi obok twojego edytora — nie wewnątrz — i pokazuje widok board każdego agenta: który branch, który model, nad czym pracuje, aktualne zużycie kosztów i status PR. Pitch brzmi: “dowieziemy UX orchestracji, którego nie mają Cursor ani terminale”.

Trzy rzeczy robią z Conductora default Tier 2 dla wielu zespołów. Po pierwsze, tworzenie worktree to jedno kliknięcie — żadnych shell aliasów, żadnej pamięci mięśniowej do git worktree add. Po drugie, dashboard pokazuje wszystkich agentów naraz, co sprawia, że sufit 5‑6 da się egzekwować wizualnie (można zobaczyć kolejkę). Po trzecie, ma wbudowane tworzenie PR‑ów i integrację z merge queue, więc handoff od “agent skończył” do “PR wjechał” to jedno naciśnięcie klawisza, a nie ręczne przełączanie kontekstu.

Ograniczenie: tylko Mac i tylko laptop. Dla zespołów na Linuksie albo dla każdego, kto chce fan‑outować do agentów w chmurze, Conductor nie jest odpowiedzią — zobacz Cursor Background Agents lub Claude Code Cloud, omówione w Q15.

Claude Squad (tmux + worktree)

Claude Squad to napisana w Go aplikacja terminalowa do równoległości zero‑setup. Zarządza wieloma instancjami Claude Code (i Codex / Aider) jednocześnie, każda we własnym tmux pane, każda zakorzeniona we własnym git worktree na własnym branchu. Model mentalny: “mam jedną klawiaturę, ale sześć terminali, i wszystkie uruchamiają agentów”.

Trakcja Claude Squad bierze się z trzech właściwości: działa na każdym OS‑ie z tmux, nie wymaga wychodzenia z terminala i komponuje się z dowolnym edytorem i workflow PR, które już masz. Dla zespołów żyjących w tmux/Neovim wpasowuje się czysto. Dla zespołów chcących GUI dashboard, lepszy jest Conductor.

Dwa gotcha warte wzmianki. Po pierwsze, nawigacja tmux gęstnieje przy 5‑6 pane’ach — zespoły Tier 2 inwestują w konfig tmux (prefix bindings, status bar pokazujący stan agenta), który dzielą przez dotfiles. Po drugie, Claude Squad nie wymusza sufitu per‑developera; musi to robić człowiek. Większość zespołów ustawia soft cap w team handbook i hard cap przez limity API.

Cursor + git worktrees (manual + skrypty)

Dla zespołów już na Cursorze (większość płacących orgów inżynierskich w 2026) najtańszą drogą do Tier 2 jest “Cursor + git worktrees + kilka skryptów shell”. Tryb multi‑window Cursora 3 pozwala otworzyć jedną instancję Cursora per worktree, każda uruchamiająca własnego agenta, każda na własnym branchu. Zarządzanie worktree jest ręczne — sam uruchamiasz git worktree add ../repo-feature-x feature-x albo opakowujesz to w skrypt bin/wt, którego używa cały zespół.

To ścieżka dla zespołów chcących inkrementalnej adopcji bez kupowania nowego narzędzia. Działa, ale wymaga więcej dyscypliny: zespół musi udokumentować skrypt worktree, konwencję nazewniczą (../repo-<slug> lub ~/wt/<slug> to typowe) i rytuał cleanup (git worktree remove po merge). Bez skryptu i konwencji dostajesz worktree drift — przeterminowane branche, niedokończone feature’y, trzy kopie node_modules.

Cursor Background Agents (po stronie chmury, nie laptopa) to osobna historia — należą do Tier 3, omówionego w Q15.

Sufit 5‑6 równoległych agentów (matematyka pasma review)

Pytanie “dlaczego 5‑6, a nie 10” pada na każdej pierwszej retrospektywie parallelism w zespole. Matematyka jest dobrze udokumentowana w 2026: praktyczny sufit na laptopie jednego developera to 5‑7 współbieżnych agentów, zanim trzy niezależne ograniczenia zbiegają się — limity API (Anthropic i OpenAI throttle’ują na poziomie orga około 5‑10 współbieżnych ciężkich requestów per seat), lokalne compute (sześciu agentów × toolchainy Node/Python + przeglądarka + edytor człowieka wysycają M‑klasowego MacBooka) i pasmo review (człowiek może sensownie zreviewować maksymalnie 4‑6 PR‑ów na godzinę, i to zanim w ogóle przeczyta kod, samo przyjęcie do wiadomości).

Dominującym ograniczeniem jest to trzecie. Sześciu agentów, którzy skończą w 20 minut, produkuje sześć PR‑ów wymagających review teraz. Jeśli twój setup CodeRabbit / Greptile nie jest dość szybki, żeby wylądował pierwszy pass zanim człowiek dotrze do PR‑a, człowiek spędza czas review na rozumieniu diffa zamiast na ocenie, a zysk z throughputu się zapada. Zespoły Tier 2 wybierają 5‑6 jako sufit, bo to najwyższa liczba, przy której automatyzacja review nadal wyprzedza człowieka.

Push powyżej 5‑6 i nie dostajesz większego throughputu — dostajesz dłuższą kolejkę review, wyższy współczynnik konfliktów merge i wolniejszy median PR age. Tier 3 (następne pytanie, Q15) jest odpowiedzią na “naprawdę chcę 20 agentów” — ale żyje na overnight runs i agentach w chmurze, nie na laptopie developera w trakcie dnia pracy.

Wzorce konfliktów merge (rebase queues, conflict‑resolving agents, mniejsze zakresy)

Dominującym wnioskiem Tier 2 na połowę 2026 jest to, że konflikty merge przy równoległości sześciu agentów nie są tym samym problemem co konflikty przy jednym agencie. Git wykrywa overlap tekstu; agenci AI generują nakładające się zmiany z częściowym kontekstem. Dostajesz więcej konfliktów i są subtelniejsze — dwóch agentów reimplementuje tego samego helpera pod różnymi nazwami, dwóch agentów naprawia ten sam bug dwoma różnymi patchami, refactor jednego agenta łamie graf importów, który drugi agent zakładał.

Trzy wzorce skonsolidowały się jako playbook Tier 2:

Merge queues linearyzujące integrację. GitHub Merge Queue, Mergify i Aviator robią tę samą zasadniczą rzecz: gdy sześć PR‑ów jest gotowych, rebase’ują je po kolei względem najświeższego main, uruchamiają CI i mergują — tak że drugi PR rebase’uje się względem zmergowanego pierwszego PR‑a, a nie tego samego main, który widział pierwszy PR. Łapie to przypadki duplicate‑implementation i refactor‑conflict zanim wylądują. Zespoły Tier 2 traktują merge queue jako table stakes, nie nice‑to‑have.
Conflict‑resolving agents z udokumentowanym promptem. Gdy konflikt wypływa, dedykowany agent‑resolver czyta markery konfliktu, opisy obu PR‑ów, odpowiedni wycinek historii gita i proponuje wersję zmergowaną. Wzorzec, na który większość zespołów się zgadza: resolver zapisuje zmergowany plik, otwiera komentarz z uzasadnieniem i tag’uje człowieka do potwierdzenia. Resolver nie ma prawa mergować — szkicuje. Człowiek mergeuje. Ten wzorzec zamienia “merge hell” w “30 sekund oceny per konflikt”.
Mniejsze zakresy by design. Najsilniejszym predyktorem niskiego współczynnika konfliktów jest dekompozycja zadań. Zespoły Tier 2 rozbijają pracę na mniejsze, bardziej ortogonalne zadania przed fan‑outem. Zamiast “zbuduj feature user profile”, jest “dodaj route profile”, “dodaj komponent profile”, “dodaj API profile”, “dodaj testy profile” — każdy agent posiada katalog, katalogi rzadko się nakładają, a współczynnik konfliktów spada o 60‑80%. Dyscyplina siedzi w planowaniu, nie w mergowaniu.

Kombinacja jest istotna: merge queue bez małych zakresów wciąż produkuje konflikty (po prostu w szeregowej kolejności); małe zakresy bez merge queue wciąż produkują race condition na main; conflict‑resolving agents bez żadnego z tych dwóch wciąż produkują backlog konfliktów do triagu. Wszystkie trzy razem to jak wygląda Tier 2 w praktyce.

Krok po kroku: jak wdrożyć Tier 2 w zespole

Wybierz narzędzie orchestracji pasujące do edytora zespołu. Jeśli większość inżynierów jest na Cursorze, zacznij od Cursor + git worktrees + wspólny skrypt bin/wt. Jeśli większość jest na Macu z mieszanymi edytorami, zewaluuj Conductora. Jeśli większość żyje w tmux/Neovim, zewaluuj Claude Squad. Nie próbuj standaryzować wszystkich trzech naraz — wybierz jedno jako domyślne dla zespołu i pozwól jednemu‑dwóm kontrarianom zachować swój setup, udokumentowany.
Udokumentuj konwencję worktree przed jakimkolwiek fan‑outem. Wybierz katalog główny worktree (~/wt/<slug> to typowe), wzorzec nazewniczy i rytuał cleanup. Zacommituj skrypt pomocniczy (bin/wt new <slug>, bin/wt cleanup) do repo. Dodaj jednostronicowy README dla nowego wzorca. Bez tego dostajesz worktree drift wewnątrz pierwszych dwóch tygodni.
Ustaw sufit per‑dev jawnie. 5 albo 6, wybierz jedno. Udokumentuj w team handbook. Zakomunikuj, że sufit dotyczy pasma review, nie CPU laptopa — wyjście powyżej nie czyni cię bardziej produktywnym, czyni twoją kolejkę PR wolniejszą. Soft‑enforce przez kulturę; hard‑enforce przez budżety limitów API per seat.
Postaw merge queue zanim włączysz równoległość. Skonfiguruj GitHub Merge Queue (lub Mergify / Aviator) na branchu domyślnym z wymaganymi CI checks. Przetestuj dwoma ręcznymi PR‑ami, które się gryzą, obserwuj linearyzację i dostrój czasy oczekiwania. Kolejka to siatka bezpieczeństwa — włączenie sześciu agentów bez niej to jak zespoły płoną w tygodniu pierwszym.
Podłącz automatyzację review do template’u PR. Dodaj CodeRabbit, Greptile lub Diamond (cokolwiek wystandaryzował twój zespół — zobacz Q9) do każdego PR otwieranego przez agenta. Pierwszy pass review musi wylądować zanim człowiek spojrzy na PR; inaczej człowiek czyta diff na zimno i zysk z równoległości się zapada.
Napisz i zacommituj prompt conflict‑resolvera. Napisz prompts/resolver.md (lub .claude/agents/resolver.md) zawierający: opisy obu PR‑ów, markery konfliktu, wycinek git log i instrukcję “naszkicuj zmergowany plik i wyjaśnij rozumowanie; nie mergeuj”. Wpisz wywołanie resolvera jako jeden liner w skrypcie bin/wt. Przetestuj na syntetycznym konflikcie.
Uruchom tygodniowy pilot przy 3 agentach na developera. Nie wskakuj na 6 pierwszego dnia. Trzy agenty pozwalają zespołowi nauczyć się workflow worktree, merge queue i pipeline’u review bez przytłaczania żadnego człowieka. Po tygodniu zrób post‑mortem na retro: gdzie faktycznie poszedł czas? Co się złamało?
Podnieś do 5‑6, gdy historia merge’a się utrzyma. Gdy pilot pokaże zero failów merge queue i CodeRabbit ląduje przed człowiekiem na >90% PR‑ów, podnieś sufit do 5 lub 6. Powtórz pilot przez jeszcze tydzień. Obserwuj median PR age — jeśli rośnie, jesteś za swoim realnym sufitem i musisz się cofnąć albo inwestować w Q9 review automation.
Zdefiniuj wyjątki “użyj trybu pair”. Udokumentuj 10‑20% zadań, w których parallel jest złym narzędziem: spikes architektoniczne, ścieżki wrażliwe security, cokolwiek wymagającego rozumowania na poziomie tablicy. Uczyń pair‑programming jawnym trybem zespołu, nie defaultem. To zapobiega równie złemu odwrotnemu driftowi: agenci wszędzie, nigdy żadnej głębokiej refleksji.
Rób kwartalne retro Tier 2. Możliwości narzędzi zmieniają się szybko. Przeglądaj, czego zespół faktycznie używa vs udokumentowany stack, gdzie merge playbook się utrzymał vs poległ i czy sufit powinien się ruszyć. Re‑ewaluuj Conductor / Claude Squad / Cursor co kwartał — i zaplanuj budżet na przynajmniej jeden swap narzędzia rocznie.

Typowe pułapki

Brak merge queue, sześciu agentów. Najszybsza droga, żeby spalić zaufanie zespołu do równoległych agentów, to wepchnąć sześć PR‑ów w main tego samego popołudnia bez linearyzacji. Trzeci PR pęka, bo zrebase’ował się względem przeterminowanego main; zespół obwinia “AI flakiness” i wraca do trybu jednego agenta. Fix: najpierw merge queue, agenci drudzy. Zawsze.
Brak automatyzacji review, sześć PR‑ów. Nawet z merge queue, sześć PR‑ów lądujących na człowieku o 16:00 produkuje albo rubber‑stamp review (które po cichu degraduje codebase), albo backlog do przyszłego tygodnia (który zabija zysk throughputu). CodeRabbit / Greptile / Diamond nie jest opcjonalny w Tier 2 — zobacz Q9.
Agent overload bez sufitu. Instynkt “jak 5 jest dobrze, to 15 lepiej” jest błędny. Powyżej sufitu spędzasz więcej czasu na orchestracji, niż równoległość oszczędza. Hard‑cap współbieżność na poziomie narzędzia (Conductor i Claude Squad oba to wspierają) i na poziomie budżetu API.
Worktree drift. Trzy tygodnie później zespół ma 47 przeterminowanych worktrees na laptopach, 200GB zduplikowanych node_modules i trzy niedokończone branche na inżyniera. Fix: bin/wt cleanup chodzi w CI, zespół uruchamia tygodniowo, a każdy worktree bez odpowiadającego mu otwartego PR po siedmiu dniach trafia do archiwum.
Duplikujące się implementacje. Dwóch agentów niezależnie pisze tę samą funkcję pomocniczą pod różnymi nazwami, bo ich okna kontekstu się nie pokryły. Merge queue łapie to dopiero przy integracji. Fix na etapie planowania: wspólny scratch buffer / dokument planowania / przypisanie sub‑tasków w Linearze listujące helpery, których dotknie każdy agent.
Pominięcie promptu conflict‑resolvera. Gdy konflikt wypływa, inżynierowie wklejają markery do Claude’a ad hoc, dostają odpowiedź i nie commitują promptu nigdzie. Sześć miesięcy później sześciu inżynierów ma własne prywatne workflow resolvera. Fix: zacommituj prompt resolvera do repo od dnia pierwszego i traktuj go jako aktyw zespołu.
Pozwalanie pojedynczym kontrybutorom ustawiać własne sufity. “Lepiej mi się pracuje z 9 agentami” jest prawie zawsze błędne, ale kulturowo trudno odmówić bez danych. Łap median PR age i conflict rate per inżynier; podnoś to na 1:1. Dane rozstrzygną spór.
Traktowanie Tier 2 jako celu. Tier 2 to stan równoległości zespołu. Tier 3 (overnight runs, agenci w chmurze, autonomous loops) to następne pytanie, Q15. Nie myl ich. Najpierw Tier 2, Tier 3 dopiero gdy Tier 2 jest solidny przez przynajmniej kwartał.

Jak zweryfikować, że tam jesteś

Slack w losowy roboczy dzień o 16:00 pokazuje wielu inżynierów raportujących “shippedem dziś 3‑5 PR‑ów” bez tego, żeby było to godne uwagi wydarzenie.
Twój dashboard GitHub merge queue pokazuje 5‑20 PR‑ów serializowanych przez niego dziennie, z jednocyfrowym failure rate.
Repo zawiera skrypt bin/wt (lub odpowiednik) i jednostronicowy README konwencji worktree, oba zaktualizowane w ostatnim kwartale.
Repo zawiera prompts/resolver.md (lub odpowiednik) zacommitowany w codebase i podlinkowany z contributing guide.
Team handbook deklaruje sufit współbieżnych agentów per developera i powód (pasmo review, nie CPU laptopa).
Nowo zatrudniony może postawić równoległy workflow w pierwszym tygodniu z samej dokumentacji — żadnego DM‑a na Slacku.
Median PR age jest niższy niż 6 miesięcy temu, nie wyższy. (Jeśli jest wyższy, jesteś za sufitem.)
Każdy PR otwarty przez agenta dostaje pierwszy automatyczny review zanim spojrzy na niego człowiek, w mniej niż 5 minut.
Zespół ma nazwę na przynajmniej trzy tryby awarii (“worktree drift”, “duplicate implementation”, “silent rebase loop”) i udokumentowany fix dla każdego.
Tryb pair‑programming jest nadal używany — do 10‑20% zadań, w których jest odpowiednim narzędziem — a zespół potrafi nazwać, które to zadania.

Dalsza lektura

Q15 · Tier 3 overnight runs Gdy Tier 2 trzyma się przez kwartał, popchnij równoległość do agentów w chmurze i overnight loops.

Q9 · Team PR review automation CodeRabbit / Greptile / Diamond — pipeline review, który czyni Tier 2 przeżywalnym.

Q20 · Knowledge sharing Jak konwencje worktree, prompty resolvera i decyzje o sufitach krążą po zespole.

CTO Scorecard Zobacz, gdzie stoisz w 25 pytaniach.