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

Największa luka produktywności między średnim a top-tier programistą AI w 2026 to nie wybór modelu ani umiejętność pisania promptów — to liczba agentów, których możesz uruchomić równolegle bez stopienia review pipeline. Programista prowadzący jedną sesję Claude Code dostarcza mniej więcej w tempie szybkiego solo developera. Programista prowadzący 5–6 równoległych agentów — część lokalnie, część na cloud VM, które obudziły się o 2 w nocy żeby odpalić backlog — dostarcza w tempie małego zespołu. Front w 2026 stoi na poziomie około 5–6 równoczesnych agentów na jednego recenzenta; powyżej tej granicy review bandwidth staje się wąskim gardłem i zyski z paralelizmu wyparowują w merge conflicts i powierzchowne approvals. Wewnętrzne dane Cursora to najczystszy sygnał kierunku: ponad 35% PR zmergowanych przez zespół inżynierski Cursora jest teraz napisanych przez autonomiczne Cloud Agents — z zera osiemnaście miesięcy temu. Zespoły, które wygrywają w tym roku, to nie te, które piszą lepsze prompty; to te, które ustawiły warstwę orkiestracji tak, że mogą zrobić review trzech PR w trakcie gdy dwóch innych agentów wciąż pisze kod na cloud VM, a trzeci po cichu przerabia otagowany backlog przez całą noc.

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.7, 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.7 + execution na Sonnet 4.6 to wciąż najsilniejsza pętla rozumowania w pojedynczej sesji jaka jest dostępna. 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. Sparuj go z GPT-5.4 lub GPT-5.5 gdy chcesz nie-anthropicowej drugiej opinii.

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.

Co zyskujesz w Tier 2: 2–3× throughput na niezależnych zadaniach. Co tracisz: wierność kontekstu per agent (skanujesz szybko, pomijasz rzeczy) i realne ryzyko merge conflicts, jeśli nie używasz worktrees jak należy.

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 na sandboxed VM. Mocny w nocnej batched work — fixy bugów, codemody, pisanie dokumentacji przez wiele plików. Plan Codex Pro za $200/miesiąc odblokowuje cięższe weekly limits, które robią to faktycznie wykonalnym do codziennego użytku. Codex może teraz harmonogramować przyszłą pracę i sam się budzić, żeby kontynuować zadania ciągnące się przez dni lub tygodnie.
Cursor Cloud Agents — uruchomione w lutym 2026. Każdy agent dostaje własną VM z terminalem, przeglądarką i pełnym desktopem, plus Twoje skonfigurowane środowisko dev. Agenty potrafią budować oprogramowanie, testować je samodzielnie, nagrywać video demos swojej pracy i wystawiać merge-ready PR. Własny zespół inżynierski Cursora mergeuje >35% PR od tych agentów.
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: 5–6 równoległych agentów na jednego recenzenta, mieszane po wszystkich trzech tierach. Powyżej tego review quality się sypie — zaczynasz green-lightować kod, którego naprawdę nie rozumiesz, a wynikające z tego bugi zjadają Twój widoczny zysk produktywności.
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, niskie ryzyko zadanie — fix znanego buga, napisanie testów dla pojedynczego pliku, port małej utili do innego języka. Otaguj je codex-cloud lub użyj guzika “Send to Cloud Agent” w Cursorze. Odejdź od komputera. Wróć za godzinę i zrecenzuj wynik jak każdy inny PR. Powtórz 5–10 razy aż zaczniesz ufać outputowi tak samo, jak juniorowi na kontrakcie.
Zbuduj swoją nocną kolejkę. Gdy jeden cloud agent działa, przeskaluj do małej kolejki. Kończ każdy roboczy dzień otagowaniem 3–5 issue do nocnej autonomicznej pracy. Poranny triage staje się pierwsze 30–60 minut Twojego dnia. To tu pojawia się prawdziwy Tier 3 leverage — Twój throughput kumuluje się w czasie kalendarzowym, nie tylko w godzinach roboczych.
Trzymaj cap na 5–6 równoczesnych agentów. Gdy się oswoisz, naturalna pokusa to spawnować 10. Nie rób tego. Śledź swój efektywny review throughput — jeśli backlog PR rośnie szybciej niż mergeujesz, jesteś powyżej capa. Wycofaj się do sustainable steady state.

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 8+ agentów, bo można. Compute jest tani; Twoja uwaga nie. Powyżej 5–6 równoczesnych review bandwidth staje się ograniczeniem wiążącym i dostarczasz mniej, nie więcej. Śledź swój merge throughput, 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 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.
Trzymasz cap na liczbę równoczesnych agentów na 5–6 w głowie i potrafisz nazwać powód (review bandwidth, nie koszt compute).
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.