Po ostatnich ruchach Anthropica – wyższe ceny, mocno ścięte limity – wraca pytanie, które słyszę coraz częściej: „Codex czy Claude Code?”. I moim zdaniem jest źle postawione. Bo można mieć oba. Co więcej – one się świetnie uzupełniają, jak tylko przestaniesz myśleć o nich jak o konkurentach.
OpenAI zrobiło ciekawy ruch: zamiast walczyć z Claude Code na noże, wydało oficjalny plugin, który wpina Codexa do środka Claude Code (otwarte repo openai/codex-plugin-cc na GitHubie, w momencie pisania już ponad 25k gwiazdek). Brzmi dziwnie – OpenAI buduje narzędzie, które robi lepszym produkt konkurenta. Ale to ten sam ruch, który widać w całej branży: wojna AI przestała być o stawianie murów, a zaczęła być o bycie wszędzie. Jak nie możesz ich pokonać, dołącz do nich – OpenAI woli, żebyś używał Codexa nawet wtedy, gdy siedzisz w Claude Code, niż żebyś nie używał go wcale.
A dla Ciebie wychodzi z tego prosta rzecz: jedna konsola, dwa mózgi. Claude pisze – bo w pisaniu kodu jest świetny. A Codex robi to, w czym akurat dobrze mieć kogoś z zewnątrz: sprawdza, audytuje, wytyka dziury. Druga para oczu, tylko że to oczy innego modelu, bo generalnie to jest rozwiązanie nie tylko w zakresie kodowania, czesto np. jeżeli to samo zapytanie damy do różnych narzędzi to otrzymujemy trochę inne rezultaty i …
Dlaczego to w ogóle ma sens (i to jest sedno)
Najważniejsza rzecz w całej tej zabawie nie jest techniczna, tylko zdroworozsądkowa: review tym samym modelem, który pisał kod, jest słaby. Anthropic pisze o tym w swoim poradniku dobrych praktyk Claude Code: „świeży kontekst poprawia review, bo Claude nie jest wtedy stronniczy wobec kodu, który przed chwilą sam napisał”. Ja bym powiedział mniej grzecznie: Claude, sprawdzając własny kod, podchodzi do niego jak do swojego – „no przecież sam to napisałem, jest dobrze” – i cicho pomija rzeczy.
To nie jest wada Claude’a. To wada, którą model odziedziczył po nas w procesie trenowania. Każdy, kto kiedyś robił code review własnego kodu po dwóch dniach, wie, że łapie się wtedy więcej niż „na gorąco” – bo przestajesz być autorem, a stajesz się czytelnikiem. Inny model robi dokładnie to: patrzy bez emocjonalnego przywiązania do tego, jak „ładnie to wymyśliłem”.
Ja to widzę od strony Refio i benchmarku, który prowadzę. Różne modele mają różne mocne strony – puszczam je przez te same zadania i widzę, że tam, gdzie jeden konsekwentnie zalicza, drugi się sypie, i odwrotnie. Dwa modele patrzące na ten sam kod to nie redundancja. To dwa różne czytniki błędów. (O tym, jak bardzo „ten sam task, różne podejścia” potrafi się rozjechać, pisałem osobno – przy okazji benchmarku małych modeli.)
Co dostajesz w pluginie
Trzy komendy, które robią robotę (opisuję na wersji pluginu, którą odpaliłem u siebie – 1.0.4):
/codex review– spokojny, neutralny przegląd. Read-only, nie rusza kodu, patrzy na Twoje bieżące zmiany (możesz wskazać, z którego brancha) i mówi, co myśli. Czyta każdą linię poza Claude Code i zwraca wynik z podziałem na critical / warning / information plus krótkie podsumowanie. Najprostszy opis: jakbyś na trzydzieści sekund wynajął senior deva, który spojrzy na kod świeżym okiem./codex adversarial-review– i to jest ten ciekawy. Codex nie tyle sprawdza, co atakuje Twoje decyzje projektowe. Nie pyta „czy działa”, tylko czego nie przewidziałeś: autentykacja, utrata danych, rollback, race condition, rozjazdy wersji, brak observability. Klasyczny przykład: zakładasz, że webhook albo odpowiedź z API dotrze na czas i że po kliknięciu przycisku wszystko zadziała od razu – a co, jeśli nie dotrze? To jest dokładnie ten rodzaj rzeczy, które wybuchają o drugiej w nocy, przy największym kliencie na pokładzie. Wynik z podziałem na poziomy krytyczności. Możesz też wskazać konkret – „skup się na cache’owaniu” albo „na logowaniu userów”. On działa bardziej jak adwokat diabła to jest trik który często używam podczas pracy z agentami, każę im obalić podejści co jest zrobione i popastwić się nad nim./codex rescue– delegujesz całe zadanie do Codexa i pracujesz dalej, bo leci w tle. Przydaje się, gdy Claude utknął i kręci się w kółko, albo – całkiem prozaicznie – gdy chcesz oszczędzić limity Claude i przerzucić robotę na Codexa. Co ważne, rescue potrafi wziąć pod uwagę wynik wcześniejszego adversarial review jako kontekst, więc nie zaczyna od zera. Na wyjściu dostajesz nie „gdzieś tam jest problem”, tylko konkretny root cause: plik, linie i propozycję poprawki.
Do tego komendy do zarządzania tym, co leci w tle: codex status (gdzie to jest), codex result (zgarnij wynik), codex cancel. I praktyczny szczegół, który zmienia sposób pracy: możesz zatrzymać Claude’a, a proces Codexa dalej mieli w tle – czyli realnie masz dwa agenty pracujące równolegle na jednym kodzie, a Ty w tym czasie budujesz dalej.
Gdzie to widać w praktyce
Zwykły review zachował się jak spokojny recenzent. Wypunktował dwie rzeczy, obie o wczytywaniu istniejących projektów – z numerami plików i linii, nie ogólnikami:
- renumeracja enuma psuje zapisane sceny SDF, bo serializer czyta z JSON-a surową liczbę operacji. Stara wartość (u mnie SMIN miało numer 41) po przenumerowaniu wczytuje się jako zupełnie inna operacja. Czyli stare projekty cicho się rozjeżdżają.
- współdzielony shader (kilka efektów wskazujących na to samo źródło) jest owijany wielokrotnie – drugi efekt owija już owinięty shader i produkuje nieprawidłowe źródło.
Już to było wartościowe. Ale potem odpaliłem na tym samym kodzie adversarial-review – i tu zrobiło się ciekawie. Werdykt: needs-attention, no-ship. Złapał to samo co review (renumeracja SDF, tym razem z gotową rekomendacją: dopisz migrację starych opcode’ów i test wczytujący stare wartości), ale dorzucił rzecz, której zwykły review w ogóle nie dotknął:
Ścieżka eksportu gubi wejścia efektu. Shader, który sampluje kanał
uChan0, renderuje się w podglądzie edytora – bo edytor przekazujeinputs. Ale eksporter woła tę samą funkcję bezinputs, więc w wyeksportowanym buildzie nie ma deklaracji samplera. Efekt: w edytorze ładnie, w finalnym demie shader się nie kompiluje albo wychodzi czarny ekran.
I to jest cała pointa adversarial review: nie sprawdza, czy kod robi to, co miał. Sprawdza, co może pójść nie tak, kiedy nikt nie patrzy. Review patrzy „czy ten kod jest spójny”. Adversarial pyta „co się stanie, jak to wyślę” – i znalazł rozjazd podgląd kontra eksport, czyli błąd, który nie odpala się na mojej maszynie, tylko u kogoś, kto uruchomi gotowy build.
Uczciwie, żeby nie było laurki: w moim przypadku to były w większości rzeczy, o których i tak wiedziałem, bo wychodzi podczas testów „dlaczego to nie działa”. Ale to akurat o czymś świadczy. Po pierwsze: narzędzie nie zmyśla i nie sypie fałszywymi alarmami, tylko trafia w realne miejsca z numerami linii. Po drugie: skoro na cudzym dla siebie kodzie – bo modele tego kodu wcześniej nie widziały – złapało dokładnie to, co autor już wie, to na kodzie, którego autor nie pamięta na pamięć, ma szansę złapać to, czego autor nie widzi.
Setup w pigułce
Cała instalacja to dosłownie dwie minuty. Potrzebujesz: Node.js, zainstalowany Claude Code i konto ChatGPT. Potem: dodajesz marketplace OpenAI, instalujesz plugin (polecany scope globalny – dostępny we wszystkich projektach), przeładowujesz przez /reload-plugins, odpalasz codex setup, żeby sprawdzić, czy czegoś nie brakuje (najczęściej brakuje logowania). Logowanie robisz w osobnym, czystym terminalu, bez Claude’a – codex login otwiera autoryzację przez Twoją subskrypcję ChatGPT, klikasz dalej i tyle. Repo pluginu (openai/codex-plugin-cc) jest otwarte – można zajrzeć, jak te komendy działają od środka, jak wyglądają prompty i sam agent rescue.
Jedna uczciwa uwaga o koszcie: sam plugin jest darmowy, ale pali Twój limit ChatGPT. Do spokojnego review darmowe konto albo Plus za 20 zielonych spokojnie wystarczy. Ale jak chcesz docisnąć adversarial-review na większym kodzie, to 20 dolarów potrafi nie starczyć – to komenda, która zjada zauważalnie więcej.
Co autor miał na myśli …
Koncept kupuję w całości, bo to dokładnie to, co sam robię w benchmarku Refio: testuję zachowania róznych modeli, i czasami widać ze działają podobnie.
Dwa konkretne plusy, które widzę:
- Druga para oczu z innego modelu – łapie błędy, których Claude na własnym kodzie nie zobaczy, bo uznaje go za swój.
- Oszczędność limitów – delegując część roboty do Codexa, nie palisz tokenów Claude. Po ostatnich ograniczeniach limitów to nie jest błahy argument.
Po realnym podejściu mój wniosek jest taki: review to szybki, spokojny check, a adversarial-review to ten, po który sięgam przed wysłaniem czegoś dalej. Ten drugi tryb znalazł u mnie rozjazd, który nie wywaliłby się na mojej maszynie, tylko u kogoś z gotowym buildem – a to jest dokładnie ten gatunek błędu, który najdrożej kosztuje. Zostaje u mnie wpięty – używam go punktowo, przy konkretnych zmianach, a nie jako stałego sita na każdym commicie.
Zanim wepniesz to w projekt firmowy – gdzie lecą Twoje dane
I tu jedna rzecz, o której entuzjastyczne filmy z reguły nie mówią, a jest ważna. Normalnie, pracując w Claude Code, Twój kod leci do Anthropica. Jak wepniesz Codexa, ten sam kod leci dodatkowo do OpenAI – bo to ich model go czyta. Dla mojego silnika dema po godzinach to żaden problem. Ale w projekcie firmowym czy klienckim to już nie jest decyzja techniczna, tylko kwestia polityki danych – i zależy od konkretnej firmy. Zanim odpalisz review na cudzym kodzie, sprawdź, czy umowa i polityka w ogóle pozwalają wysyłać go do drugiego dostawcy. Wygoda wygodą, ale dane to dane – warto o tym pamiętać.
0 komentarzy