Tier workflow — od jednej sesji do autonomicznych overnight runs

Q14 · Paralelizm i automatyzacja Który tier workflow najlepiej Cię opisuje?

Odpowiedź max score: “Tier 3: dodatkowo uruchamiam autonomiczne overnight backlog drains (Codex Cloud, Cursor Cloud Agents).”

Dlaczego to ma znaczenie w 2026

Agenty równoległe mogą zwiększyć throughput na niezależnych, dobrze zakresowanych zadaniach, ale ograniczeniem stają się review bandwidth i ryzyko merge. Użyteczne pytanie nie dotyczy uniwersalnej liczby agentów ani mnożnika produktywności, lecz tego, ile równoczesnych zmian zespół potrafi zreviewować, przetestować i zintegrować bez wzrostu rework. Zacznij mało, mierz completion i rejection rate, a skaluj tylko dopóki utrzymuje się jakość review.

Jak naprawdę wygląda “max score”

Pełne punkty z Q14 dostajesz tylko wtedy, gdy potrafisz konkretnie opisać, jak działasz na wszystkich trzech tierach i wybierasz odpowiedni do zadania. Kształt top-tier dnia:

Rano, Tier 3 wake-up. Zanim w ogóle otworzysz laptopa, dwa nocne Codex Cloud runs i jeden Cursor Cloud Agent wyprodukowały po draft PR dla issue, które otagowałeś wczoraj. Triażujesz je jak normalne code review: mergeujesz tego czystego, odpychasz tego z machaniem rękami w commitach, zabijasz trzeciego bo podejście było złe. To godzina “darmowego” outputu przed standupem.
Późny ranek, Tier 2 fan-out. Pracujesz nad prawdziwym featurem. Spawnujesz 3 równoległych lokalnych agentów w git worktrees: jeden pisze migrację, drugi buduje API handler, trzeci podłącza komponent UI. Pingujesz między nimi przez tmux albo Conductor / Claude Squad, robiąc review tego, który najbardziej potrzebuje human inputu w tej chwili. Żaden nie blokuje pozostałych.
Po południu, Tier 1 deep focus. Najtrudniejsza część dnia — fragment wymagający prawdziwego architektonicznego osądu — to jedna sesja Claude Code w Plan mode z Opus 4.8, bez fan-outu, Ty w pętli na każdym kroku. Czasem jedna skupiona sesja bije pięć średnich, i wiesz która jest która.
Wieczorem, Tier 3 queue. Wychodzisz z biura otagowawszy 3–5 issue odpowiednim labelem (codex-cloud, cursor-agent, albo po prostu zrouteowane przez Twój auto-PR hook) tak, żeby autonomiczne agenty podjęły je w trakcie gdy śpisz. Jutrzejszy poranny triage powtarza się.

Wszystko mniej jest sub-tier na Q14. Konkretnie:

“Prowadzę jedną sesję Claude Code lub Cursor naraz” — to Tier 1, mid-tier w Q14.
“Prowadzę 2–3 równoległych agentów w worktree, ale nigdy nie próbowałem cloud agents” — to Tier 2, blisko topu, ale brakuje asynchronicznej overnight pętli, w której teraz mieszka większość leverage’u.
“Próbowałem Cloud Agents raz, nie zaufałem” — nie liczy się. Zaufanie pochodzi z setupu orkiestracji (layered review, zakresowane zadania, sensowne etykiety), nie z modelu.

Aktualny krajobraz (web-verified)

Tier 1: jedna sesja terminala/IDE

Pojedyncza sesja Claude Code, Cursora lub Codex CLI przed Tobą, jeden prompt naraz, Ty czytasz ekran kiedy działa. To tu wszyscy zaczynają i tu wciąż w 2026 mieszka większość programistów.

Claude Code — terminal-first agent Anthropica. Default do głębokiej pracy, bo Plan mode + Opus 4.8 + execution na Sonnet 5 to mocna pętla rozumowania w pojedynczej sesji; do najtrudniejszych zadań architektonicznych Claude Fable 5 (/model fable) przewyższa teraz Opus 4.8 za 2× cenę — patrz porównanie modeli po wskazówki routingowe. Najlepsze gdy zadanie wymaga poważnego architektonicznego osądu albo dotyka >5 plików.
Cursor (tryb IDE) — doświadczenie “VS Code z panelem agenta”. Najlepsze gdy robisz ciasne pętle edit-test-edit i chcesz mieć diff widoczny obok pliku. Mocny przy refactorach, gdzie chcesz przeczesać zmiany hunk po hunku.
Codex CLI — terminal-first agent OpenAI, lokalny odpowiednik Codex Cloud. Mocny w długich agentowych tool-use loops i structured outputs. ChatGPT Codex oferuje GPT-5.6 Sol, Terra i Luna zależnie od planu i zadania; alias API gpt-5.6 wskazuje na Sol.

Co zyskujesz w Tier 1: pełne skupienie, pełna kontrola, pełne zrozumienie każdej zmiany. Co tracisz: throughput. Jeden człowiek + jeden agent dostarczają mniej więcej w tempie jednego developera.

Tier 2: 2–4 równoległych agentów

Wielu lokalnych agentów uruchomionych jednocześnie, każdy nad swoim zadaniem, każdy w swoim katalogu roboczym (prawie zawsze git worktrees — patrz Q15). Ty orkiestrujesz, nie kodujesz.

Conductor — Mac app, który uruchamia wielu agentów Claude Code równolegle, każdego w sandboxed git worktree, z kanban-stylowym UI do przełączania między nimi. Zrobiony specjalnie pod workflow “uruchamiam 4 agentów naraz”.
Claude Squad — open-source terminal multiplexer dla sesji Claude Code / Codex / Aider / Gemini, każda w swoim tmux pane i git worktree. Darmowy i działa dla wszystkich, łącznie z Linuksem.
Cursor + git worktrees — otwórz jedno okno Cursora per worktree, każde wskazuje na inną gałąź, w każdym uruchom agenta. Darmowe, bez dodatkowego tooling, działa dziś.
tmux + Claude Code — wersja barebones: jedno okno tmux per agent, ręcznie checkout do osobnych worktree. Tanie, trwałe, bez zależności.

W Tier 2 możesz zyskać concurrency na niezależnych zadaniach. Ryzykujesz płytszym review i merge conflicts przy słabej izolacji lub ownership; mierz wynik zamiast zakładać stały mnożnik.

Tier 3: autonomiczne overnight (Codex Cloud, Cursor Cloud Agents, Anthropic Computer Use)

Cloud-hosted agenty uruchamiane na izolowanych VM, których nie musisz pilnować. Budzą się, działają godzinę albo osiem, i wystawiają draft PR (albo failure do zbadania). To front 2026.

Codex Cloud (OpenAI) — async cloud agent w środowisku zdalnym do pracy batch, takiej jak fixy, codemody i dokumentacja. ChatGPT Pro 5x kosztuje $100/miesiąc, a Pro 20x $200/miesiąc; wliczone użycie Codex można rozszerzyć token credits, więc opłacalność zależy od zmierzonego workloadu, a nie stałej liczby wiadomości tygodniowo.
Cursor Cloud Agents — Każdy agent dostaje izolowane środowisko chmurowe ze skonfigurowanymi narzędziami. Agenty mogą budować, testować, nagrywać demo i przygotowywać PR; ich wartość weryfikuj własnymi metrykami akceptacji i rework.
Anthropic Computer Use — najbardziej ogólnego przeznaczenia z całej trójki. Steruje prawdziwym desktopem, w tym przeglądarką, i jest najmocniejszy, gdy zadanie wymaga pracy GUI poza IDE (klikanie po admin panelach, przechodzenie przez onboarding flows, screenshot-driven QA).

Co zyskujesz w Tier 3: throughput, którego żaden pojedynczy człowiek nie wyprodukuje. Rozsądny nocny output bez ludzkiej uwagi. Co tracisz: widoczność — zobowiązujesz się do “ufać layered-review pipeline” zamiast oglądać każdą zmianę.

Cost/benefit: limity review bandwidth

Limit paralelizmu w 2026 to nie koszt compute. To liczba diffów wygenerowanych przez agenty, którą pojedynczy człowiek może w sensowny sposób przejrzeć w ciągu dnia. Field data zbiegają się z wielu zespołów:

Sustainable steady state: Tyle równoległych agentów, ile recenzent wciąż potrafi zrozumieć i zweryfikować. Ustal cap na podstawie wzrostu kolejki, rejection rate i escaped defects, a nie uniwersalnej liczby.
Burst capacity: 8–10 agentów podczas zaplanowanego sprintu sprzątającego (fixy literówek, update’y dokumentacji, dependency bumps), gdzie diffy są mechaniczne i da się je zrecenzować w 30 sekund każdy. Nie rób z tego trybu codziennego.
Czas na review jednego Tier 3 PR: średnio 5–15 minut gdy setup layered-review jest dobry (Q17). To unit cost uruchamiania autonomicznego agenta. Jeśli nie potrafisz poświęcić tego czasu, agent po prostu tworzy kolejkę niezrecenzowanych PR, która się rozkłada.

Dlatego Tier 3 zwraca się tylko wtedy, gdy Twój review pipeline (Q17), praktyka strukturyzowania zmian (Q25) i auto-PR workflow (Q16) są już solidne. Pomiń je i Tier 3 spowolni Cię, nie przyspieszy.

Krok po kroku: przechodzenie przez tiery

Najpierw ustal biegłość w Tier 1. Powinieneś codziennie prowadzić sesję Claude Code lub Cursor, czuć się komfortowo z Plan mode, czuć się komfortowo zabijając sesję i restartując ją, gdy zjechała z torów. Jeśli pojedyncza sesja wciąż wydaje się chaotyczna, fan-out z 4 z nich będzie 4× chaosem. Spędź tu 2–4 tygodnie.
Skonfiguruj git worktrees. To prerequisite dla Tier 2 i większości Tier 3. Skonfiguruj repo tak, żebyś mógł odpalić worktree per agent w jednym poleceniu — patrz Q15 po dokładny setup. Bez tego równoległe agenty będą nadpisywać sobie pliki, a Ty spędzisz więcej czasu rozwiązując merge conflicts, niż dostarczając.
Uruchom pierwszą równoległą sesję. Otwórz dwa tmux pane, każdy w osobnym worktree, każdy uruchamia Claude Code nad innym małym zadaniem. Nie próbuj jeszcze niczego ważnego dostarczać — cel to poczuć, jak naprawdę wygląda context-switching między dwoma agentami. Większość ludzi uznaje, że dwa są łatwe, trzy są ścianą, cztery wymagają tooling.
Dodaj Conductor lub Claude Squad. Gdy już poczułeś ból przełączania między 3+ surowymi tmux pane, zainstaluj Conductor (Mac) albo Claude Squad (cross-platform). Oszczędności UI się kumulują — możliwość rzucenia okiem na statusy wszystkich agentów na jednym ekranie to to, co czyni 4+ równoległych agentów wykonalnymi.
Podłącz swój auto-PR workflow. Tier 2 jest dramatycznie bardziej użyteczny, gdy każdy agent kończy automatycznym otwarciem PR (patrz Q16). Dzięki temu nie musisz ręcznie odpalać git push && gh pr create cztery razy z rzędu. Przepis Stop hook + gh pr create z Q16 pokrywa to.
Spróbuj jednego zadania na Codex Cloud lub Cursor Cloud Agent. Wybierz małe, dobrze zakresowane i niskiego ryzyka zadanie, a wynik zreviewuj jak każdy inny PR. Powtarzaj na reprezentatywnych zadaniach, aż zbierzesz dane o akceptacji i rework.
Zbuduj małą nocną kolejkę. Gdy jeden cloud agent działa niezawodnie, kolejkuj tylko tyle pracy nocnej, ile możesz szybko zreviewować następnego ranka.
Ustal cap concurrency na podstawie danych. Jeśli backlog PR albo rejection/rework rate rośnie szybciej niż merge, zmniejsz fan-out.

Częste pułapki

Skok od razu do Tier 3 bez layered review pipeline. Cloud Agents produkują PR szybciej, niż jesteś w stanie je przeczytać. Jeśli jedyną linią obrony jest “zrecenzuję je uważnie”, albo przepuścisz zły kod, albo przestaniesz dostarczać. Zbuduj najpierw setup layered-review z Q17 (CodeRabbit / Copilot review / Sentry review), żeby output agenta był pre-filtrowany zanim trafi do Twojej kolejki.
Fan-out bez git worktrees. Dwóch agentów w tym samym checkout nadpisze sobie edycje. Każdy weteran parallel-agent ma tę historię; nie musisz być następny. Używaj worktrees od pierwszego dnia Tier 2.
Traktowanie Tier 3 jak “fire and forget”. Autonomiczne overnight runs wciąż wymagają human review. Pętla trust-but-verify jest tym, co czyni je bezpiecznymi; “po prostu zmergowałem 3 cloud-agent PR bez czytania” to sposób na to, jak spędzisz jutro debuggując.
Uruchamianie kolejnych agentów tylko dlatego, że można. Compute jest tani, uwaga nie. Śledź zaakceptowany throughput i jakość review, nie liczbę spawnów.
Używanie Tier 3 do zadań wymagających prawdziwego osądu. Decyzje architektoniczne, paskudny debugging między serwisami, wszystko gdzie poprawna odpowiedź to “w ogóle nie powinniśmy tego budować” — to należy do skupionej sesji Tier 1 z Opus 4.8 (lub Fable 5 gdy potrzebujesz szczytowej inteligencji) w Plan mode. Nie outsource’uj judgement calls do async cloud agents.
Brak konwencji etykietowania dla cloud agents. Bez schematu tagów (codex-cloud, cursor-agent, claude-overnight) Twój backlog zamienia się w bałagan “to dla mnie czy dla agenta?”. Zdefiniuj tagi raz i się ich trzymaj.
Ignorowanie per-agent budgets. Źle skonfigurowany Cloud Agent potrafi spalić $30 w runaway loop. Ustaw per-agent timeouts i per-day spend caps w dashboardzie Codex Cloud / Cursor, zanim skalujesz kolejkę.

Jak zweryfikować, że tam jesteś

Potrafisz — bez zastanowienia — opisać, które zadanie z aktualnego backlogu powinno trafić do Tier 1, Tier 2 lub Tier 3, i dlaczego.
Uruchomiłeś co najmniej jedno autonomiczne zadanie na Codex Cloud lub Cursor Cloud Agent w ciągu ostatnich 7 dni, aż do zmergowanego PR.
Masz konwencję etykietowania dla “to issue ma być podjęte przez cloud agent” i użyłeś jej w tym tygodniu.
Twoje repo ma działający setup git worktrees (Q15) i spawnowałeś w nim co najmniej 2 równoległych lokalnych agentów w tym miesiącu.
Masz auto-PR workflow (Q16), żeby zakończenie pracy agenta kończyło się otwartym PR, a nie “idź ręcznie odpal gh pr create”.
Masz layered PR review (Q17) — CodeRabbit, Copilot review lub odpowiednik — żeby cloud-agent PR były pre-filtrowane zanim je triażujesz.
Masz cap concurrency oparty na danych o review bandwidth, wzroście kolejki i rework.
Twoja poranna rutyna zawiera slot 30–60 minut na triage nocnego outputu cloud-agentów i jest zablokowana w kalendarzu.
Masz per-agent spend caps skonfigurowane w Codex Cloud, Cursor lub dowolnym providerze cloud-agent, którego używasz.

Dalsza lektura

Q15 · git worktrees Jeden checkout per agent — prerequisite dla Tier 2 paralelizmu bez kolizji plików.

Q17 · Layered PR review CodeRabbit + Copilot review + Sentry — pipeline, który czyni cloud-agent PR bezpiecznymi do mergowania.

Q25 · Strukturyzacja zmian Mniejsze, zakresowane PR, które agent może faktycznie skończyć w jednym cloud run.

Wypełnij Developer Scorecard Oceń się w 25 pytaniach w ~10 minut.