O czym jest ten film
- Autor przez około miesiąc pracował równolegle z Claude Code i Codexem i coraz częściej sięga po to drugie narzędzie — jego zdaniem modele GPT rozwiązują bardziej złożone problemy i lepiej wykorzystują abonament.
- Oba narzędzia dostają dokładnie to samo zadanie: wizualny kreator automatyzacji, czyli uproszczony i samodzielny odpowiednik n8n.
- Test prowadzony jest sprawdzonym sposobem pracy autora — metodą RAMP: instrukcje, rozbudowa agenta o skille, planowanie, a dopiero potem implementacja.
- W fazie planowania Codex zadał około pięć razy więcej pytań, technicznych i trafnych — punkt dla niego. Claude dodatkowo zignorował polecenie zapisania planu i od razu ruszył z implementacją.
- Obie aplikacje były w pełni funkcjonalne od razu i przeszły testy we wbudowanej przeglądarce — remis w kompletności funkcji i weryfikacji, a także w czasie pracy.
- Warstwę wizualną wygrywa Claude (spójny design na komponentach shadcn); strukturę plików i architekturę — Codex (folder na bazę danych, strona 404, porządek w bibliotekach).
- To samo zadanie zużyło około 8% planu Claude (250 dolarów) i około 16% planu Codex (100 dolarów) — realnie taniej wyszło Codexowi.
- W wyzwaniu utrzymywalności (dodanie wyboru modeli z OpenRouter w zupełnie nowej sesji) lepiej wypadł Codex: głębiej przejrzał dokumentację i dał pełniejszą listę modeli.
- Werdykt autora: Codex jest zdecydowanie tańszy w codziennej pracy, Claude pozostaje bezkonkurencyjny w wyglądzie tworzonych interfejsów.
- Całość to subiektywna ocena jednego praktyka — autor zaprasza widzów do oceny poszczególnych kategorii w komentarzach.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Porównuj agentów na jednym, identycznym zadaniu
Na czym polega: Siłą tego testu jest kontrola zmiennych: ten sam opis projektu, ten sam sposób pracy, porównywalne modele (Opus 4.8 i GPT 5.5) ustawione na maksymalny wysiłek obliczeniowy.
Jak stosować: Wybierz jeden konkretny projekt, uruchom go równolegle w dwóch narzędziach, każde w osobnym folderze, i oceniaj wyniki według ustalonych z góry kryteriów: planowanie, kompletność funkcji, testy, czas, koszt, łatwość rozwijania kodu.
Na co uważać: To ocena pojedynczego użytkownika na jednym projekcie — zanim zdecydujesz o migracji, przeprowadź analogiczny test na własnym stacku.
2.Zaczynaj od reguł zapisanych w projekcie
Na czym polega: Pierwszy krok metody RAMP to plik z instrukcjami dla agenta: konwencje, wymogi techniczne, np. „zawsze uruchamiaj aplikację na porcie 1234”. Dopiero świeża sesja gwarantuje, że reguły zostaną wczytane.
Jak stosować: Przed pierwszym zadaniem wpisz trwałe zasady do pliku konfiguracyjnego projektu, zamknij sesję i otwórz nową. W ten sposób unikniesz np. konfliktów portów między równolegle uruchamianymi aplikacjami.
Na co uważać: Każde narzędzie ma własny plik reguł — Claude Code czyta CLAUDE.md, Codex — AGENTS.md. Te same zasady trzeba zapisać w obu miejscach.
3.Rozszerzaj agenta skillami dobranymi do stacku
Na czym polega: Drugi krok RAMP to rozbudowa agenta: skille i narzędzia MCP instalowane pojedynczymi poleceniami, np. skill z dobrymi praktykami Reacta od Vercela.
Jak stosować: Przeglądaj planowany projekt i instaluj wyłącznie te rozszerzenia, które odpowiadają technologiom, których zamierzasz użyć — agent z odpowiednim skillim pisze kod bliżej produkcyjnych standardów.
Na co uważać: Agent potrafi samodzielnie doinstalować dodatkowe skille. Warto sprawdzić, co dokładnie trafiło do projektu, zamiast zakładać, że lista kończy się na tym, co podałeś.
4.Liczba i jakość pytań w fazie planowania mówi dużo o narzędziu
Na czym polega: Podczas planowania Codex zadał około pięć razy więcej pytań niż Claude — technicznych i wnikliwych. To przekłada się na trafniejszy dobór bibliotek i architektury.
Jak stosować: Jeśli chcesz samodzielnie sterować architekturą aplikacji, wybierz narzędzie, które dopytuje. Jeśli zależy Ci na tempie, odpowiadaj krótko: „idź ze swoją rekomendacją”.
Na co uważać: Rozmowny agent kosztuje Twój czas — przy drobnych zadaniach lawina pytań bywa nieopłacalna.
5.Plan trzymaj w repozytorium projektu
Na czym polega: Autor po zakończonym planowaniu każe zapisać go w folderze /plans w głównym katalogu, żeby w przyszłych sesjach móc do niego wracać. Oba narzędzia mają podgląd plików, więc plan łatwo obejrzeć.
Jak stosować: Po każdej sesji planistycznej zapisuj dokumentację w projekcie — nowa sesja z czystym kontekstem może wtedy realizować plan bez ponownego planowania.
Na co uważać: Agent może zignorować polecenie zapisu i ruszyć z implementacją, jak zrobił to Claude. Reaguj natychmiast — przerwij pracę i poproś o zapisanie planu jeszcze raz.
6.Do dużych zadań używaj trybu długiej pracy i monitoringu z telefonu
Na czym polega: Oba narzędzia obsługują polecenie goal, które pozwala agentowi pracować bardzo długo nad dużymi, złożonymi zadaniami. Przebieg można obserwować zdalnie z telefonu, a testy wykonuje wbudowana przeglądarka.
Jak stosować: Przy dużych projektach otwórz nową sesję, wskaż folder z planem i dodaj instrukcję: „Nie przerywaj, dopóki wszystko nie będzie zaimplementowane, zweryfikowane i przetestowane”.
Na co uważać: Długie autonomiczne przebiegi zużywają dużo limitów — tym bardziej warto śledzić postępy na telefonie, zamiast zostawiać agenta bez nadzoru na godziny.
7.Oceniaj efekt warstwami: wygląd, struktura plików, biblioteki
Na czym polega: Ładny interfejs to jedno, a jakość kodu — co innego. W teście Claude zapisał bazę danych w głównym katalogu projektu i wstawił favicon do niewłaściwego folderu; Codex założył porządny folder na dane, dodał stronę 404 i uporządkował biblioteki.
Jak stosować: Po zakończonej implementacji obejrzyj drzewo plików i listę zależności, zanim ocenisz projekt. Pytajnika w katalogu głównym, brak strony błędu i losowo porozrzucane moduły to sygnały, że kod będzie kosztowny w utrzymaniu.
Na co uważać: Dopracowany wizualnie interfejs łatwo maskuje bałagan w kodzie — nie daj się zmylić pierwszemu wrażeniu z podglądu.
8.Wymagaj, żeby aplikacja działała od razu, bez poprawek
Na czym polega: Oba narzędzia zwróciły w pełni działającą aplikację: rejestracja, przeciąganie węzłów na płótnie, uruchamianie przepływów, zapis automatyczny, realne wywołania modeli. Testy end-to-end agent wykonał sam, we wbudowanej przeglądarce.
Jak stosować: Do promptu włącz jawny wymóg: „Zweryfikuj i przetestuj wszystko przed zakończeniem”. Potem sam przejdź kluczowe ścieżki — w teście okazało się np., że workflow trzeba najpierw zapisać, żeby uruchomienie przeszło.
Na co uważać: Testy robione przez agenta potwierdzają, że aplikacja działa u agenta. Twoje środowisko, klucze API i dane mogą zachować się inaczej.
9.Procenty zużytych limitów mylą — przeliczaj na realny koszt
Na czym polega: To samo zadanie zużyło około 8% planu Claude (250 dolarów miesięcznie) i około 16% planu Codex (100 dolarów). Mniejszy procent na droższym abonamencie oznaczał realnie wyższy koszt zadania.
Jak stosować: Przy wyborze abonamentu patrz nie na pasek postępu limitów, lecz na koszt wykonania typowego zadania: procent zużycia razy cena planu.
Na co uważać: Porównanie ma sens tylko przy świeżo zresetowanych limitach — inaczej okna odnowienia zafałszują wynik.
10.Utrzymywalność testuj w zupełnie nowej sesji
Na czym polega: Najciekawszy sprawdzian: dodanie nowej funkcji (lista wyboru modeli pobrana z OpenRouter) w sesji, która nic nie wie o projekcie. Agent musi sam rozeznać się w kodzie, wyjść do dokumentacji w sieci i wpiąć wynik w istniejącą aplikację.
Jak stosować: Zamknij wszystkie sesje, otwórz nową i zleć zmianę, która wymaga researchu online. Oceniaj trzy rzeczy: jakość zebranej dokumentacji, obsługę błędów (np. wybór niedostępnego modelu) i to, czy komunikaty precyzyjnie wskazują miejsce awarii.
Na co uważać: Wyniki bywają mylące przez stany niezapisane — w teście Codex najpierw zwrócił błąd dotyczący innego modelu, a po zapisaniu workflow everything przeszło. Przed testem zadbaj o czysty, zapisany stan projektu.
Redakcyjne tłumaczenie
Dlaczego po trzydziestu dniach coraz częściej sięgam po Codexa
Claude Code święci ostatnio duże sukcesy i sam nakręciłem o nim mnóstwo materiałów. W ostatnim miesiącu, może dwóch, zauważyłem jednak, że coraz częściej pracuję z Codexem i modelami GPT. Mam wrażenie, że lepiej wykorzystuję swoje abonamenty, modele oddają lepsze rezultaty i radzą sobie ze znacznie bardziej złożonymi problemami.
Postanowiłem więc postawić Claude Code i Codex obok siebie: dostaną dokładnie to samo zadanie, w dokładnie tym samym porządku pracy, a ja porównam wyniki według konkretnych rubryk. Od razu zaznaczam: to moja subiektywna ocena, więc piszcie w komentarzach, które narzędzie — waszym zdaniem — wygrało poszczególne punkty.
Ta sama metoda, ten sam projekt
Obu uczestników przeprowadzę przez sprawdzony sposób pracy z agentami kodującymi, który nazywam metodą RAMP. Właśnie tak buduję prawdziwe oprogramowanie, i to z bardzo różnymi agentami — łącznie z tanimi, a nawet darmowymi modelami lokalnymi. Na temat RAMP mam całkowicie darmowy kurs, link znajdziecie w opisie filmu.
Zaczynam od nowych sesji, po jednej w Claude Code i w Codexie, każdej wyznaczam osobny folder. Projektem będzie centrum sterowania automatyzacjami AI: coś w rodzaju odchudzonej wersji n8n, Make.com czy Zapiera — miejsce, w którym zarządza się procesami biznesowymi za pomocą przepływów automatyzacji.
(Informacja dodatkowa: n8n, Make.com i Zapier to popularne narzędzia do budowania automatyzacji z gotowych, łączonych ze sobą bloków.)
Krok pierwszy: instrukcje dla agenta
Pierwszy etap RAMP polega na przekazaniu agentowi instrukcji — a przy okazji przekonamy się, jak dobrze oba narzędzia ich słuchają. Proszę Claude, żeby do pliku CLAUDE.md w folderze projektu dodał zasadę: „Zawsze uruchamiaj naszą aplikację na porcie 1234”. Robię to wyłącznie po to, żeby nie doszło do absurdalnej sytuacji, w której oba agenty próbują obsadzić ten sam port. Analogiczne polecenie trafia do Codexa — tam odpowiedni plik nazywa się AGENTS.md. Obie strony wykonały zadanie, więc otwieram świeże sesje; dopiero wtedy nowe reguły zostają wczytane i można brać się do pracy.
Stan limitów: 250 dolarów kontra 100
Zerkam jeszcze na aktualne wykorzystanie planów. Plan Claude Max 20x kosztuje około 250 dolarów miesięcznie, po stronie Codexa — około 100. Trafiam idealnie w moment: Claude właśnie zresetował mi limit, a na koncie Codexa zostało 99%. Ciekawie będzie zobaczyć, ile realnego użytku wyjdzie ze stumiedziułowego abonamentu w porównaniu z planem za 250.
Krok drugi: skille pod konkretny stack
W obu narzędziach przechodzę w tryb planowania. Jako model wybieram Opusa 4.8 — moim zdaniem Opus 4.8 i GPT 5.5 to zupełnie porównywalna para — i ustawiam obu maksymalny poziom wysiłku obliczeniowego.
Drugi element RAMP to rozbudowa agenta o dodatkowe możliwości: skille i narzędzia MCP. Podaję po prostu gotowe polecenia instalacji dla skilli, które uznam za przydatne. Przykład: skill z dobrymi praktykami Reacta od Vercela przyda się na pewno, bo w tym projekcie korzystamy z Reacta. Moja rekomendacja jest taka: instalujcie skille według stacku technologicznego, na którym pracujecie. Identyczną listę przekazuję po stronie Codexa.
Codex skończył instalację jako pierwszy i zaciągnął wszystko, o co prosiłem. A dla pewności dołożył od siebie jeszcze skill Groll.me.
(Informacja dodatkowa: nazwa tak pada w materiale — „skill” to rozszerzenie podłączane do agenta kodującego; zapis nazwy mógł zostać zniekształcony w nagraniu.)
Planowanie: dwa różne temperamenty
Agent siedzi w skillach, więc czas zaplanować aplikację. Obie strony dostają co do słowa ten sam prompt: „Zbuduj AgentOps — wizualny kreator automatyzacji, w zasadzie uproszczony, samowystarczalny n8n. Chcę płótno, po którym mogę przeciągać węzły, łączyć je i układać w przepływ”. Dochodzi kilka podstawowych typów węzłów, a węzeł AI ma odwoływać się do prawdziwego modelu przez OpenRouter. Dokładam jeszcze pożądany stack technologiczny i kończę poleceniem: „Użyj skilla Groll.me”.
(Informacja dodatkowa: OpenRouter to pośrednik API, który daje dostęp do modeli wielu dostawców przez jedno konto.)
Ustawiam tryb planowania. Oba narzędzia podchwytują skilla. Odpowiadam na pytania Codexa — w większości przyjmuję rekomendacje agentów, bo naprawdę chcę zobaczyć, jak dobrze planują aplikacje. Claude skończył swój plan implementacji pierwszy, choć różnica sięgała może minuty. Mogę jednak zdradzić jedno: Codex zadał mniej więcej pięć razy więcej pytań. Część była bardzo techniczna i dogłębna, więc za każdym razem powtarzałem: „Idź ze swoją rekomendacją”.
Plan ma trafić do projektu — i tu pierwszy sygnał ostrzegawczy
Nieзамierzam wybrzydzać nad samymi planami. Wychodzę z trybu planowania i proszę oba narzędzia: „Zapisz plan w folderze /plans w głównym katalogu projektu”. Osobiście lubię trzymać plany wewnątrz projektu, żeby zawsze można było do nich wrócić. Codex zapisał dokument we właściwym miejscu. A przy okazji: oba narzędzia pozwalają podejrzeć pliki w folderze — plan widać tu i tu.
I tu pojawia się rzecz niepokojąca. Poprosiłem po prostu o zapisanie planu, a Claude zignorował polecenie i po prostu ruszył z wdrażaniem projektu, zupełnie tak, jakby niczego nie słyszał. To nie jest to, czego chciałem, więc natychmiast zatrzymuję Claude. Już ten moment budzi mój niepokój.
Jeśli podsumować doświadczenia z trybem planowania i pytaniami agentów: punkt dla Codexa. Zadał wielokrotnie więcej pytań, a spora część była naprawdę na temat — dużo konkretów technicznych. Jeśli zależy Wam na tym, by samemu sterować architekturą aplikacji, Codex będzie znacznie lepszym partnerem.
Implementacja: polecenie goal i długa, samodzielna robota
Przechodzimy do wdrażania. Otwieram zupełnie nową sesję, żeby oczyścić okno kontekstu, i uruchamiam implementację poleceniem goal. Zarówno Claude Code, jak i Codex je obsługują — pozwala ono agentowi pracować bardzo długo nad dużymi i złożonymi zadaniami, takimi jak świeżo powstały plan. Obie strony dostają identyczną instrukcję: „Zaimplementuj plan z folderu plans. Nie przerywaj, dopóki wszystko nie zostanie zaimplementowane, zweryfikowane i przetestowane”.
Dobra wiadomość praktyczna: zarówno Claude Code, jak i Codex można monitorować zdalnie z telefonu. Tymczasem Claude sam testuje aplikację we wbudowanej przeglądarce — oba narzędzia mają taką funkcję i same nią wykonują testy. Nawet w malutkim oknie podglądu widać, że powstaje coś na kształt płótna znanego z n8n. Bardzo obiecująco.
Próba ognia: aplikacja od Claude
Claude właśnie zakończył wdrażanie przez goal; Codex wciąż pracuje. Czas na próbę. Dostajemy ekran logowania — rejestruję się, podaję dane i… jesteśmy w środku. Widzimy jeden przykładowy przepływ i muszę przyznać: wygląda to naprawdę jak n8n. Płótno przesuwa się myszką, kółko przybliża widok, na dole czeka mini-mapa ułatwiająca nawigację. Węzły da się łapać i przestawiać, a klik w węzeł pokazuje jego konfigurację i wynik uruchomienia.
Uruchamiam przepływ. System na żywo podświetla węzeł, który właśnie pracuje, a po zakończeniu dostajemy czytelną informację, którą ścieżką popłynęły dane. Zerkam w wyniki: węzeł wyzwalający otrzymał na wejściu tekst „I love this product. It works perfectly”, model ocenił ton wypowiedzi jako pozytywny, a węzeł warunkowy — skonfigurowany tak, by przy wartości „positive” kierować przepływ gałęzią prawdziwą — przekazał dane do szablonu, który zwrócił końcowy wynik. Po prostu działa.
Spróbujmy zbudować własny przepływ od zera: węzeł wyzwalający, węzeł AI, prompt systemowy „napisz przykładowy kod w Pythonie”, połączenie i uruchomienie. Węzeł AI faktycznie odwołuje się do modelu przez OpenRouter — wygenerowane przykłady kodu, od „hello world” począwszy, ewidentnie nie są niczym zaszytym na sztywno. Do tego przepływ zapisuje się automatycznie. Interfejs mnie po prostu cieszy — wszystko działa.
Aplikacja od Codex: mniej poleru, więcej informacji
Codex również skończył, może pięć minut później. Także korzysta z komponentów shadcn, więc niezbyt zaskakująco wygląda bardzo podobnie do wersji Claude. zakładam konto. Początek wygląda inaczej: dostajemy dwa gotowe przykłady — streszczacz tekstów oraz rozgałęźnik priorytetów AI — obok małego formularza do tworzenia nowego przepływu.
Otwieram streszczacz. Płótno ma ten typowy, n8n-owy charakter: przybliżanie, centrowanie węzłów, a nawet opcję ich zablokowania, żeby dało się je przesuwać — czego, o ile pamiętam, Claude nie dodał. Mamy komplet podstawowych węzłów i ustawienia przepływu; klik w dowolny węzeł pokazuje po prawej stronie szczegóły i historię uruchomień. Próbuję uruchomić — pasek statusu wygląda mniej efektownie niż u Claude, ale działa, a na dole pojawia się wynik wykonania.
Które lubię bardziej? Szczerze — nie wiem. W designie przesuwa mnie wersja Claude, ale interfejs Codexa wydaje się nieść więcej informacji. Tego jednego nie umiem rozstrzygnąć, więc ocena należy do Was: która wersja jest przyjemniejsza dla oka i daje cenniejsze wyniki?
Rubryka po rubryce: UI, struktura, funkcje, testy
Zacznijmy od wyglądu i wykończenia. Tu punkt dla Claude. Modele GPT nigdy nie słynęły z tworzenia pięknych interfejsów, więc Claude wygrywa tę kategorię bez dyskusji.
Przechodzimy do struktury plików i architektury — podglądam drzewo w obu projektach. Ponieważ obie aplikacje stoją na Next.js, spodziewamy się podobieństw: katalog node_modules, folder źródłowy z plikami aplikacji. Różnice są jednak wymowne. Claude wrzucił bazę danych do głównego katalogu projektu — nie jestem fanem takiego rozwiązania. Codex ładnie założył folder na dane i tam schował wszystkie pliki bazy. Claude dodatkowo pomylił się, umieszczając favicon w folderze źródłowym zamiast w właściwym miejscu. Codex dorzucił stronę 404 dla nieistniejących ścieżek — u Claude jej nie widzę. Katalog z bibliotekami jest też po stronie Codexa wyraźnie bardziej uporządkowany.
I jeszcze jedno: biblioteki, które dobrał sobie Codex — właśnie dzięki lawierze pytań z fazy planowania — closer odpowiadają aplikacji produkcyjnej. Punkt za architekturę i strukturę plików: Codex.
Kompletność funkcji? Muszę przyznać remis — oba narzędzia oddały dokładnie to, o co prosiłem. Testy i weryfikacja? Również remis: oba świetnie odrobiły lekcję z przeglądarką, testując aplikację od początku do końca, i oba wręczyły mi w pełni funkcjonalny produkt, gotowy do działania zaraz po wygenerowaniu. Czas i wykorzystanie zasobów? Praktycznie remis — różnica mogła wynieść jakieś pięć minut.
Koszty: mniejszy procent, ale ile to kosztuje
Najciekawsza rubryka. Po stronie Claude zużyłem około 8% bieżącego limitu; po stronie Codexa — około 16%. I tu ważna rzecz: za plan Claude Max 20x płacę 250 dolarów, a za Codexa — 100. Czyli realnie z planu Codexa wyciągam znacznie więcej użytku. W tej kategorii punkt zdecydowanie dla Codexa.
Wyzwanie utrzymywalności: nowa funkcja w nowej sesji
Ostatni sprawdzian: zdolność agenta do rojrzenia się po istniejącej bazie kodu, zrozumienia kluczowych funkcji i dobudowania czegoś na tym fundamencie. Polecenie brzmi tak: „Nie chcę już zaszytej na sztywno nazwy modelu w węźle AI. Gdy użytkownik kliknie węzeł AI, ma móc wybrać model z przygotowanej listy. Przejdź do dokumentacji OpenRouter, pobierz najnowsze modele od Anthropic i OpenAI i udostępnij je w węźle AI jako listę rozwijaną”.
Obie sesje startują z czystą kartą — model w tej chwili nie ma pojęcia, czym jest projekt. Musi więc sam odnaleźć węzeł AI, wyjść do sieci, zrobić research i wpiąć wybór modeli w aplikację. Oba agenty właśnie skończyły — Claude przy okazji zrobił zrzut ekranu końcowego efektu. W obu przypadkach poszły do sieci, przebadały dokumentację i złożyły listę modeli. Obejrzyjmy wyniki.
Wersja Claude: wchodzę w przepływ, klikam węzeł AI i — proszę — pojawił się selektor modeli. Mamy całą listę modeli Claude oraz modele GPT-5. Ciekawostką jest pozycja „Fable 5”, model formalnie niedostępny. Wybieram go celowo, żeby zobaczyć, co się stanie. Uruchamiam przepływ i aplikacja poprawnie pada: wskazuje dokładnie, który węzeł zawodzi, i tłumaczy przyczynę błędu. Tak ma wyglądać poprawna obsługa awarii.
Wersja Codexa: otwieram streszczacz, klikam węzeł AI — listy modeli Claude i OpenAI na miejscu, ale opcji jest więcej. Jest Opus 4.8 i dostęp do szybkich wariantów modeli, których wersja Claude nie oferowała. Bardzo ciekawe. Do testu wybieram Claude Opus 4.8 Fast — i cała zabawa kończy się wpadką: komunikat mówi, że to „Claude Fable 5” jest niedostępny, choć przecież wybrałem zupełnie inny model. Podejrzewam, że przepływ trzeba było najpierw zapisać. Zapisuję, uruchamiam drugi raz — i teraz przechodzi, odpowiedź wraca. Scenariusz negatywny mieliśmy już za sobą, więc punktu nie odbieram.
W tej rubryce punkt dla Codexa — nie dlatego, że bezbłędnie, ale dlatego, że głębiej przejrzał, które modele powinny być dostępne, i dał pełniejsze opcje, z wariantami szybkimi i standardowymi.
Werdykt po trzydziestu dniach
Chętnie poznam Wasze zdanie w komentarzach. Z mojej strony podsumowanie wygląda tak: Claude jednoznacznie pokonuje Codexa w projektowaniu wizualnym — modelom GPT nikt nigdy nie zarzucał tworzenia pięknych interfejsów, więc ta kategoria należy do Claude. Zarazem oba narzędzia świetnie trzymają się instrukcji i dowożą aplikacje kompletne pod względem funkcji. Obie strony dobrze radzą sobie też z narzędziami testowymi: unit tests nie stanowią problemu, a testowanie aplikacji w prawdziwej przeglądarce to u obu standard.
A rzecz, która utkwiła mi w pamięci po prawie miesiącu pracy z Codexem, jest najprostsza z możliwych: Codex jest po prostu znacznie tańszy. Ze stu dolarów miesięcznie wyciągam dużo więcej realnej pracy niż z planu Claude za 250.
Jeśli materiał Wam się przydał, zostawcie łapkę w górę i zasubskrybujcie kanał — więcej treści o kodowaniu z agentami w drodze. A teraz idźcie i zbudujcie coś dobrego.