Programowanie z dwoma agentami: Claude Code i Codex w jednym projekcie

Przez większość 2025 roku rozmowa o kodowaniu z agentami była drabinką turniejową: Claude Code kontra Codex kontra Cursor, wybierz swojego zawodnika, broń go w sieci. W połowie 2026 roku najlepsze zespoły po cichu porzuciły tę drabinkę. Uruchamiają dwóch agentów naraz — Claude Code i Codex — na tym samym repozytorium, tej samej gałęzi, tego samego popołudnia, i kierują każdy fragment pracy do tego agenta, który jest do niego stworzony. Rama myślenia przesunęła się z którego na którego do tego.

To nie jest siedzenie okrakiem na płocie. To ta sama logika, która sprawiła, że orkiestra wieloagentowa działa, zastosowana o jeden poziom wyżej: zamiast dyrygować wieloma instancjami jednego agenta, dyrygujesz dwoma różnymi agentami, których mocne strony się nie pokrywają. Efektem jest przepływ pracy zdolniejszy niż którekolwiek z narzędzi z osobna — o ile rozumiesz, w czym każde z nich jest naprawdę dobre, i zbudujesz harness, który utrzyma je z dala od siebie nawzajem.

Dwóch agentów, dwa kształty pracy

Claude Code i Codex to nie ten sam produkt z innym logo. Mają różne domyślne zachowania, a te różnice czysto odwzorowują się na różne rodzaje pracy.

Claude Code jest zbudowany do głębi. Utrzymuje duży kontekst roboczy, rozumuje przez wiele plików zanim którykolwiek tknie, i jest w swoim żywiole przy zadaniach, gdzie trudną częścią jest zrozumienie, a nie pisanie: refaktor przekrojowy, decyzja architektoniczna, rozplątanie tego, dlaczego podsystem zachowuje się tak, jak się zachowuje. Jego funkcja Agent Teams — lider koordynujący członków zespołu wspólną listą zadań i blokowaniem plików — rozszerza tę głębię na skoordynowaną pracę równoległą, gdy jedno okno kontekstu nie wystarcza. Gdy problem brzmi „rozgryź właściwy kształt”, po Claude Code sięgasz.

Codex jest zbudowany do szybkości i rozpiętości. Błyszczy przy szybkich, celowanych edycjach i przy rozgałęzianiu się: potrafi uruchomić grupę równoległych subagentów (do ośmiu) przeżuwających naraz niezależne, dobrze wyspecyfikowane zadania. Generowanie kodu szablonowego, mechaniczne edycje stosowane w dziesiątkach plików, naszkicowanie specyfikacji z istniejącego interfejsu — praca, w której kształt jest już przesądzony, a to, co zostaje, to przepustowość. Gdy problem brzmi „zrób tę znaną rzecz, czterdzieści razy, teraz”, narzędziem jest Codex.

Mówiąc wprost: Claude Code decyduje, czym ma być zmiana; Codex wykonuje jej rozpiętość. To jedno zdanie to cały hybrydowy przepływ pracy w skondensowanej formie.

Wzorzec hybrydowy: projektuj jednym, implementuj drugim

Wzorzec, który się wyłonił, to dwufazowa pętla, i odzwierciedla on dyscyplinę spec-driven, za którą wielokrotnie się opowiadaliśmy: najpierw dopracuj projekt, a potem niech wykonanie będzie tanie.

Faza pierwsza — projektuj i dekomponuj z Claude Code. Oddajesz Claude Code zabałaganiony, niejednoznaczny front problemu. Czyta bazę kodu, proponuje architekturę, podejmuje przekrojową decyzję i — co kluczowe — produkuje dekompozycję: jasną listę niezależnych, mechanicznych zadań, które ta decyzja implikuje. To tutaj głębokie rozumowanie zarabia na swój koszt. Mglisty plan w tym miejscu zwielokrotnia się w dół strumienia, więc osąd inwestujesz z góry.

Faza druga — implementuj rozpiętość z Codeksem. Gdy kształt jest przesądzony, a praca zdekomponowana na dobrze wyspecyfikowane jednostki, kierujesz równoległe subagenty Codeksa na tę listę. Każde zadanie jest teraz zawężone, niezależne i mechaniczne — dokładnie warunki, w których flota szybkich subagentów błyszczy.

Konkretny przykład rozjaśnia rzecz. Powiedzmy, że zmieniasz rdzeniową schemę API usługi:

• Claude Code sam wykonuje refaktor schemy — tę część, gdzie musisz zrozumieć każdego konsumenta, każdy przypadek brzegowy, każdy niejawny kontrakt zakodowany w starym kształcie. Rozumuje przez migrację, podejmuje decyzję strukturalną i wypisuje nową schemę plus listę zadań: zaktualizuj te 40 plików testowych do nowego kształtu, wygeneruj na nowo specyfikację OpenAPI, zaktualizuj trzy SDK klienckie, napraw fikstury.
• Codex bierze tę listę i się rozgałęzia. Jeden subagent przepisuje pliki testowe, inny generuje na nowo specyfikację OpenAPI z nowej schemy, jeszcze inny zamiata fikstury. Czterdzieści plików zaktualizowanych i świeża specyfikacja wygenerowana w czasie, w którym ty otworzyłbyś pierwszych dziesięć.

Podział nie jest arbitralny. Zmiana schemy to jeden trudny osąd; czterdzieści plików testowych to czterdzieści łatwych powtórzeń przesądzonego wzorca. Głębokiego agenta użyłeś do osądu, a szybkiego i szerokiego do powtórzeń — i żaden nie robił części, w której jest gorszy.

Jak nie dopuścić do kolizji dwóch agentów

Uruchomienie dwóch autonomicznych agentów na jednym repozytorium wprowadza realne ryzyko, którego przepływ z jednym agentem nigdy nie miał: depczą sobie nawzajem po piętach. Dwóch agentów edytujących te same pliki albo zatwierdzających jeden na drugim zamienia zysk produktywności w koszmar scaleń. Zarządzanie przepływem z dwoma agentami to problem narzędziowy i wykrystalizowało się kilka wzorców.

• Organizacja terminala. Dedykowany organizer terminala, taki jak Beam — albo ręcznie zbudowany układ tmux — pozwala obserwować obu agentów w osobnych panelach, podawać każdemu własne polecenia i nie pozwolić, by ich strumienie wyjścia się zlewały. Gdy dyrygujesz, zamiast pisać, widzenie obu agentów jednym rzutem oka to połowa roboty.
• Izolacja przez worktree lub gałąź. Najczystszy sposób na powstrzymanie kolizji to odebranie okazji: daj każdemu agentowi własne git worktree lub gałąź, by ich edycje fizycznie nie mogły się nałożyć, a potem scalaj rozważnie. To ta sama sztuczka z izolacją, która czyni orkiestrację wieloagentową bezpieczną, zastosowana między dwoma produktami.
• Jasna granica własności. Zdecyduj, per zadanie, kto jest właścicielem których plików. Claude Code jest właścicielem schemy i architektury; Codex jest właścicielem plików generowanych i mechanicznych. Niejednoznaczność co do własności to miejsce, gdzie dwóch agentów psuje sobie nawzajem pracę.

Innymi słowy, harness wciąż jest produktem — punkt, który stawialiśmy wcześniej i który tylko się wyostrza, gdy do skoordynowania jest dwóch agentów. Model wykonuje pracę; harness decyduje, czy ta praca jest spójna, czy to chaos.

Rachunek kosztów i limitów

Dwie subskrypcje to oczywisty zarzut i zasługuje na prostą odpowiedź. Zarówno Claude Code, jak i Codex sprzedają dostęp warstwowy — plany rozliczane od zużycia, z limitami przepustowości, które kąsają przy intensywnym użyciu z górnej półki. Uruchomienie obu istotnie oznacza dwa rachunki i dwa zestawy limitów do śledzenia.

Ale rachunek zwykle sprzyja parze, z powodu strukturalnego: nie płacisz dwa razy za tę samą pracę — płacisz każdemu narzędziu za pracę, w której jest najtańsze. Spalanie drogiej mocy głębokiego rozumowania na czterdzieści mechanicznych edycji plików to faktyczne marnotrawstwo. Skierowanie tych edycji do szybkiego, równoległego agenta i zarezerwowanie głębokiego agenta na jedną trudną decyzję jest tańsze w przeliczeniu na dostarczoną funkcję, a nie droższe — i omija ścianę limitów, w którą uderzyłbyś, zmuszając jedno narzędzie do robienia wszystkiego. Dyscyplina, która czyni ten przepływ dobrym, czyni go też ekonomicznym.

Dlaczego to gra dla Azji Południowo-Wschodniej

Oto część, która najbardziej liczy się dla tego regionu, i jest to ta sama asymetria, do której wciąż wracamy. Programowanie z dwoma agentami to sposób na skalowanie wyniku bez skalowania zatrudnienia — a to dokładnie ta dźwignia, która sprzyja małym, ubogim w kapitał zespołom, jakich pełno w Azji Południowo-Wschodniej.

Trzyosobowe studio w Phnom Penh albo Da Nang, które nauczyło się prowadzić Claude Code i Codex w tandemie, nie konkuruje liczbą inżynierów, których może zatrudnić. Konkuruje tym, jak dobrze kilka osób potrafi zdecydować o właściwej architekturze, a potem wykonać jej pełną rozpiętość równolegle — projektuj jednym agentem, implementuj ośmioma subagentami z drugiego, weryfikuj, dostarczaj. Taki zespół może wziąć na siebie zakres dostaw, który kiedyś wymagał tuzina inżynierów, bo ograniczenie zeszło z listy płac na osąd.

A osąd to trwała zdolność bez GPU, którą — jak wciąż twierdzimy — region powinien budować. Frontierowe laboratoria chętnie wynajmą ci obu agentów. Czego nie wynajmą, to gustu, by wiedzieć, który agent powinien tknąć który plik, specyfikacji, która czyni pracę równoległą poprawną zamiast szybkiej-i-błędnej, oraz weryfikacji, która to wyłapie, gdy nie jest. Dwóch agentów wzmacnia to, co przynosisz — w tym mglistość. Przynieś ostre specyfikacje i czysty harness, a garstka ludzi w regionie zdoła dostarczyć więcej niż zespół wielokrotnie od niej większy.

Drabinka turniejowa się skończyła. Zespoły wygrywające w 2026 roku to nie te, które wybrały właściwego agenta. To te, które przestały wybierać — i nauczyły się dyrygować obydwoma.