O czym jest ten film
- Mark Kashef pokazuje, jak połączyć Claude z Codexem za pomocą wtyczki, ich narzędzi uruchamianych z terminala albo przeglądu zmian w projekcie.
- Proponuje, by jeden model przygotowywał plan, a drugi szukał w nim słabych punktów.
- Pokazuje, jak zlecić Codexowi przygotowanie grafiki i wykorzystać gotowy plik podczas pracy w Claude.
- Dzieli pracę nad funkcją między modele: jeden ją tworzy, drugi sprawdza i pomaga poprawić.
- Omawia zadania wymagające obsługi przeglądarki, logowania lub użycia danych dostępowych.
- Porównuje podejście obu narzędzi do długich zadań i radzi wyznaczyć im jasny warunek zakończenia.
- Przedstawia sposób przekazywania projektu między sesjami przez krótkie pliki opisujące ustalenia, stan prac i następny krok.
- Na koniec podaje własny podział zadań: Claude do planowania i budowania, Codex do krytycznej oceny, kontroli i obsługi komputera.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Najpierw wybierz sposób połączenia narzędzi
Na czym polega: Autor przedstawia trzy możliwości: wtyczkę Codex dla Claude, wywoływanie jednego narzędzia z poziomu drugiego przez terminal oraz zmianę przygotowaną przez jeden model i sprawdzoną przez drugi.
Jak stosować: Zacznij od sposobu pasującego do projektu. Do jednorazowej konsultacji wystarczy wywołanie przez terminal; przy pracy nad kodem wygodny może być przegląd zmian przed ich włączeniem do projektu.
Na co uważać: Samo połączenie narzędzi nie zapewnia dobrej kontroli. W poleceniu określ, o co drugi model ma zostać zapytany i co ma się stać z jego odpowiedzią.
2.Daj plan do oceny innemu modelowi
Na czym polega: Model, który ułożył plan, może zbyt łatwo uznać własne założenia za trafne. Niezależna ocena pomaga znaleźć przeoczenia.
Jak stosować: Poproś Claude o pierwszą wersję planu, a Codexowi zleć wskazanie ryzyk, braków i słabych założeń. Potem wróć z uwagami do Claude i popraw plan.
Na co uważać: Nie każ modelom dyskutować bez końca. Ustal, że mają zakończyć pracę, gdy najważniejsze zastrzeżenia zostaną rozstrzygnięte.
3.Wydziel tworzenie grafik jako osobne zadanie
Na czym polega: Kashef proponuje, by przygotowanie diagramu lub infografiki zlecić Codexowi, a gotowy plik wykorzystać w pracy prowadzonej w Claude.
Jak stosować: Opisz, co grafika ma wyjaśniać i gdzie będzie użyta. Po jej przygotowaniu przekaż plik oraz jego przeznaczenie do głównej sesji projektu.
Na co uważać: Grafika też wymaga kontroli: sprawdź podpisy, układ i zgodność z treścią. Oszczędność zależy od posiadanych planów i sposobu korzystania z narzędzi.
4.Podziel wykonanie pracy, a nie tylko planowanie
Na czym polega: Jeden model może stworzyć funkcję, a drugi przejrzeć wynik, zaproponować poprawki i pomóc je wdrożyć.
Jak stosować: Już w pierwszym poleceniu zapisz kolejność: zbudowanie funkcji, sprawdzenie jej przez drugi model, poprawki i ponowna kontrola.
Na co uważać: Określ, kto odpowiada za ostatnią decyzję. Sam fakt, że dwa modele zgadzają się ze sobą, nie zastępuje sprawdzenia działania funkcji.
5.Przy większych zmianach pracuj na osobnej gałęzi
Na czym polega: Autor radzi tworzyć nową funkcję w odizolowanej części projektu, a następnie poddać ją przeglądowi przed włączeniem do głównej wersji.
Jak stosować: Poproś o przygotowanie zmiany na nowej gałęzi i o jej przegląd przez drugi model. Włącz ją do projektu dopiero po sprawdzeniu wyniku.
Na co uważać: Recenzja kodu powinna dotyczyć konkretnej zmiany i jej skutków. Ogólne polecenie „sprawdź wszystko” może dać rozwlekłą, mało użyteczną odpowiedź.
6.Zadania wymagające obsługi komputera planuj oddzielnie
Na czym polega: Według doświadczeń autora Codex lepiej radzi sobie z czynnościami w interfejsie, zwłaszcza gdy trzeba użyć przeglądarki lub zalogować się na konto.
Jak stosować: Przy układaniu pracy zaznacz kroki, które wymagają kliknięć, logowania albo ręcznego przeniesienia danych. Zdecyduj, czy zlecić je Codexowi, czy wykonać samodzielnie.
Na co uważać: Przed przekazaniem zadania sprawdź, do jakiego konta i jakich danych narzędzie uzyska dostęp. Przy czynnościach wrażliwych zachowaj własną kontrolę.
7.Długiemu zadaniu podaj warunek zakończenia
Na czym polega: Autor zauważa, że Codex potrafi pracować nad złożonym celem bardzo długo, również wtedy, gdy dalsze próby nie przynoszą postępu.
Jak stosować: Zdefiniuj wynik, na przykład przejście testów procesu zakupu, oraz limit czasu. Dodaj instrukcję: jeśli po dwóch godzinach zadanie nadal jest zablokowane, przerwij pracę i opisz przyczynę.
Na co uważać: Więcej czasu i zużytych tokenów nie musi oznaczać lepszego wyniku. Szczególnie przy obsłudze stron internetowych sprawdzaj, czy kolejne działania rzeczywiście przybliżają narzędzie do celu.
8.Po sesji zapisuj stan projektu
Na czym polega: Zamiast utrzymywać wiele rozrastających się planów Kashef zapisuje po sesji krótką informację o wykonanej pracy, decyzjach i następnym kroku.
Jak stosować: Przy zakończeniu pracy przygotuj plik przekazania. W kolejnej sesji każ narzędziu wczytać najnowszy zapis, zanim podejmie następne zadanie.
Na co uważać: Oznacz jednoznacznie, który plik jest aktualny. Nieaktualne ustalenia mogą skierować kolejny model na złą drogę.
9.Zachowuj historię decyzji w zwięzłej postaci
Na czym polega: Kolejne pliki przekazania pozwalają odtworzyć, co zmieniało się w projekcie, bez wczytywania całych dawnych rozmów.
Jak stosować: W każdym zapisie uwzględniaj decyzje, ich powód, wykonane zmiany i sprawy otwarte. Sięgaj do starszych zapisów, gdy trzeba ustalić, skąd wzięło się obecne rozwiązanie.
Na co uważać: Zwięzły zapis może pominąć istotny szczegół. Jeśli decyzja ma duże znaczenie, zachowaj też odnośnik do kodu, dokumentu lub wyniku, na którym ją oparto.
10.Dobieraj model do etapu pracy
Na czym polega: Kashef zwykle wybiera Claude do planowania i tworzenia, a Codex do krytycznej oceny, kontroli przed publikacją, grafik, obsługi komputera i szczególnie długich zadań.
Jak stosować: Rozpisz projekt na etapy i przy każdym wskaż główne narzędzie oraz moment przekazania pracy drugiemu modelowi.
Na co uważać: To podział oparty na doświadczeniach autora. Oceniaj wyniki na własnych zadaniach, zwłaszcza gdy liczą się czas, koszt i zakres dostępu do narzędzi.
Redakcyjne tłumaczenie
Po co korzystać z dwóch modeli
Opus 5.5 i GPT-6 Astra uważam dziś za dwa najlepsze modele do mojej pracy. Jeśli korzystasz tylko z jednego, tracisz możliwość wykorzystania ich różnych mocnych stron. Opus dobrze radzi sobie z planowaniem, a Astra potrafi znaleźć słabe punkty takiego planu. Na wspólnym planowaniu możliwości się jednak nie kończą.
Pokażę sześć sposobów ich łączenia: od prostych zadań po rozwiązania wymagające staranniejszej organizacji pracy. Nie trzeba przy tym stale przełączać całego projektu z jednego środowiska do drugiego. Nie każda metoda wymaga też najdroższego planu w obu usługach — zależy to od zadania.
Zaczniemy od wspólnego planowania i wzajemnej oceny bez specjalnych rozszerzeń. Potem przejdziemy do tworzenia grafik, podziału wykonania pracy, obsługi komputera, długich zadań oraz przekazywania projektu między modelami. Na końcu powiem, do czego sam najchętniej wybieram każde z tych narzędzi.
Jak połączyć Claude z Codexem
Zanim zaczniesz, oba narzędzia muszą mieć sposób na przekazywanie sobie zadań. Pierwsza możliwość to wtyczka Codex, dostępna na oficjalnej stronie projektu w GitHubie. W moim przypadku działa ona od kwietnia. Można przekazać Claude link do repozytorium i poprosić o pobranie oraz instalację. W następnej rozmowie dostępne będą funkcje wtyczki, między innymi przegląd kodu napisanego przez Claude oraz ocena projektu konkretnych funkcji lub zmian.
To szybkie rozwiązanie, lecz nie zawsze daje najwygodniejszy sposób pracy. Druga możliwość to zainstalowanie obu narzędzi w wersji uruchamianej z terminala, czyli CLI. Aplikacja Claude może wtedy wywołać Codex, a Codex — Claude.
Przykładowo w aplikacji Claude proszę, by bez używania wtyczek wysłała przez Codex CLI zadanie do Astry, z ustawionym średnim poziomem rozumowania. Zadanie dotyczy analizy możliwości zastosowania AI w cyberbezpieczeństwie. Claude uruchamia odpowiednie polecenie, przekazuje prośbę Codexowi i po kilku minutach otrzymuję odpowiedź Astry. W przebiegu pracy widać wywołanie „Codex exec”.
W Codexie mogę zrobić to samo w drugą stronę: zamiast wywoływać Codex CLI, proszę o użycie Claude CLI i skierowanie pytania do Opus 5.5. Narzędzie uruchamia polecenie w terminalu, a następnie otrzymuję odpowiedź Opus. Nie potrzebuję do tego dodatkowego pośrednika.
Trzecia metoda przydaje się przy pracy nad projektem. Jeden model przygotowuje zmianę, a drugi ją sprawdza w ramach pull requestu, czyli propozycji włączenia zmian do głównej wersji projektu. Można to sobie wyobrazić tak: prosisz Opus albo Astrę o zmianę w aplikacji, otrzymujesz jej roboczą wersję, drugi model przeprowadza przegląd, a po zaakceptowaniu wynik trafia do projektu.
1.Niech jeden model zakwestionuje plan drugiego
Pierwszy sposób polega na tym, by wybrać model, w którym zwykle prowadzisz pracę, i poprosić go o pierwszą wersję planu. Następnie niech wyśle ją drugiemu modelowi do oceny. Po uwagach może poprawić plan i ponowić konsultację, aż obie strony uznają najważniejsze kwestie za rozstrzygnięte.
Przykładowe polecenie brzmi w przybliżeniu tak: „Przygotuj plan dla tego projektu. Następnie poproś GPT-6 Astra, pracującą ze średnim poziomem rozumowania, o jego ocenę. Wprowadzaj poprawki i konsultuj je ponownie, aż powstanie spójny plan”.
Kiedyś korzystałem do podobnej pracy z dodatkowych rozszerzeń i mechanizmów uruchamiających kolejne rundy rozmowy. Teraz wystarcza mi bezpośrednie polecenie. Jeśli Claude przygotuje pierwszą wersję, Codex zwykle bez ogródek wskaże miejsca, w których założenia są zbyt optymistyczne. W moim doświadczeniu Claude częściej zakłada, że realizacja pójdzie gładko, a Codex częściej szuka powodów, dla których może się nie udać.
To pomaga rozwiązać prosty problem: model oceniający własny plan, szczególnie w tej samej rozmowie, potrafi z dużą pewnością stwierdzić, że wszystko jest w porządku. Gdy pokażesz ten sam plan innemu modelowi, zwłaszcza bez wcześniejszego kontekstu, możesz otrzymać zupełnie inną ocenę.
2.Przygotuj grafikę w Codexie i wróć z nią do Claude
Drugi sposób dotyczy obrazów. Przez długi czas podłączałem do pracy narzędzia do generowania grafik i ponosiłem dodatkowe koszty korzystania z ich API. Później zdałem sobie sprawę, że skoro już płacę za Codex — nawet w planie za 20 dolarów — mogę zlecić mu przygotowanie diagramu lub infografiki, a gotowy plik przenieść do projektu prowadzonego w Claude.
Pomysł jest prosty: nie każde zadanie trzeba wykonywać w tym samym narzędziu, w którym powstaje reszta materiału. Można wydzielić przygotowanie grafiki i po otrzymaniu wyniku wrócić do głównej pracy.
3.Podziel także wykonanie projektu
Trzeci sposób idzie dalej niż wspólne planowanie. Można przygotować plan przy udziale obu modeli, a potem rozdzielić między nie również wykonanie. Przykładowo Claude może zrobić około 70 proc. pracy, a Codex zająć się pozostałą częścią.
Wyobraź sobie, że Opus buduje nową funkcję. Już w pierwszym poleceniu prosisz go, by po zakończeniu przekazał wynik drugiemu modelowi przez wtyczkę albo CLI. Codex ma sprawdzić, co zostało zrobione, przejrzeć zmianę, wprowadzić potrzebne poprawki i ponowić kontrolę. Gdy wynik będzie gotowy, zmianę można włączyć do projektu.
Przy pracy z kodem można poprosić o przygotowanie funkcji na nowej gałęzi. To oddzielna linia prac, która pozwala rozwijać zmianę bez bezpośredniego naruszania głównej wersji. Jeśli nie korzystasz z GitHuba i nie chcesz wchodzić w szczegóły, wystarczy prostsze polecenie: „Zbuduj nową funkcję, a potem poproś Codex o jej przegląd”. Jeśli używasz konkretnej wtyczki, bardziej szczegółowy opis gałęzi i kolejnych kroków pomoże jej wykonać zadanie.
4.Osobno potraktuj logowanie i obsługę komputera
Czwarty sposób dotyczy zadań, w których trzeba obsługiwać komputer, przeglądarkę lub konto. Bardzo dobrze pracuje mi się z Opus 5.5, ale w moim doświadczeniu jego możliwości wykonywania takich czynności pozostają wyraźnie słabsze od możliwości Codexa.
Claude potrafi zająć się większością listy zadań, lecz zdarza się, że odmawia prostych czynności związanych z danymi dostępowymi lub kluczem API, nawet gdy udzielę mu zgody. Codex częściej podejmuje takie działania. Jeśli wiesz, do czego narzędzie otrzyma dostęp, możesz przeznaczyć mu zadania wymagające zalogowania się, kliknięcia w interfejsie czy wykonania czynności w przeglądarce.
W praktyce pierwsze etapy projektu mogą polegać wyłącznie na pracy z kodem, a dopiero ostatni wymagać wejścia na stronę lub do aplikacji. Warto to zauważyć już podczas planowania. Jeżeli wszystkie potrzebne usługi są połączone i nie trzeba się nigdzie logować, Claude może przeprowadzić pracę od początku do końca. Jeżeli potrzebna jest obsługa konta lub interfejsu, można powierzyć ten etap Codexowi. Gdy siedzisz przy komputerze, równie dobrze możesz wykonać krótką czynność samodzielnie, a potem oddać Claude resztę zadania.
Nie zakładam przy tym, że każdą czynność dotyczącą konta należy automatyzować. Najpierw trzeba ocenić, czy dostęp do niego i do związanych z nim danych można bezpiecznie przekazać narzędziu.
5.Przy długiej pracy wyznacz granicę
Piąty sposób nazywam po prostu doprowadzaniem zadania do końca. Chodzi o przekazanie jednemu z modeli szczegółowo opisanego celu, nad którym będzie pracował przez dłuższy czas.
Codex potrafi poświęcić na taki cel 18, 20, a nawet 30 godzin, próbując sprawdzić sprawę możliwie dokładnie. Bywa to zaletą, ale czasem prowadzi do powtarzania podobnych prób. Przy obsłudze komputera może długo przeglądać kolejne części interfejsu i zużywać dostępny budżet tokenów, nie osiągając proporcjonalnego postępu.
Claude zwykle podchodzi do takiego celu mniej intensywnie. Jeśli to samo zadanie oddasz Codexowi, według moich doświadczeń możesz czekać na wynik trzy do pięciu razy dłużej i zużyć znacznie więcej tokenów. Są jednak zadania, przy których właśnie tak dokładna kontrola różnych możliwości jest potrzebna. Wtedy Codex może być właściwym wyborem.
Żeby nie pozwolić mu utknąć, podaj zarówno cel, jak i warunek przerwania pracy. Możesz na przykład zlecić: „Doprowadź do tego, by testy procesu zakupu przechodziły. Jeśli po dwóch godzinach nadal będziesz mieć problem, zatrzymaj się i wyjaśnij dlaczego”. Możesz też poprosić, by przekazał opis przeszkody Claude i sprawdził, czy ten znajdzie inne rozwiązanie.
6.Przekazuj między modelami stan projektu
Szósty sposób to praca na zmianę. Claude kończy etap, zapisuje, co zrobił i co trzeba zrobić dalej, a Codex podejmuje zadanie z tego miejsca. Potem role mogą się odwrócić.
Jeszcze kilka miesięcy temu tworzyłem w tym celu plik plan.md: zwykły dokument tekstowy z instrukcjami i etapami projektu. Z czasem takich plików robiły się dziesiątki, a czasem setki. Miały różne daty i zakresy, szybko się starzały, a znalezienie aktualnego planu stawało się coraz trudniejsze.
Obecnie pod koniec sesji uruchamiam polecenie /handoff. Tworzy ono plik Markdown z krótką informacją o obecnym stanie prac, podjętych decyzjach i następnym kroku. Zapis zawiera też wskazanie, że jest najnowszą wersją przekazania.
W Codexie mogę następnie uruchomić /prime, by odczytał aktualny plik i podjął pracę. Takie zapisy pomagają również prześledzić historię projektu. Zamiast prosić model o przeczytanie wszystkich dawnych rozmów, daję mu zwięzły zapis decyzji i zmian. Dzięki temu potrzebuje mniej miejsca na kontekst bieżącego zadania.
Ten sposób nie ogranicza się do Claude i Codexa. Można go wykorzystać także przy przekazywaniu pracy modelom uruchamianym lokalnie lub otwartym modelom dostępnym w chmurze.
Które narzędzie wybieram do czego
Mój obecny podział wygląda tak: planowanie najczęściej powierzam Claude, a Codexowi zlecam krytyczną ocenę planu. Grafiki przygotowuję w Codexie, między innymi ze względu na koszty. Budowanie i doprowadzanie projektu do publikacji zwykle prowadzę w Opus.
Przed oddaniem gotowego wyniku — czy jest to dokument .docx, czy aplikacja — często proszę Astrę lub Sol o kilka rund przeglądu. Do obsługi komputera wybieram dziś Codex. Sięgam po niego również wtedy, gdy zadanie jest długie i skomplikowane, a mnie zależy na szczegółowym sprawdzeniu możliwości mimo większego zużycia czasu i tokenów.
To mój sposób korzystania z mocnych stron obu narzędzi. Przygotowałem też szczegółową instrukcję oraz funkcje /prime i /handoff do zastosowania we własnym środowisku pracy. Udostępniam je bezpłatnie przez drugi link pod filmem. Pod pierwszym znajduje się informacja o mojej społeczności dla osób, które chcą szerzej pracować z Claude, Codexem i zastosowaniami AI w firmach.