O czym jest ten film
- Kontynuacja poprzedniego odcynku o modach — dodatkach do Claude Code, za pomocą których dodaje się narzędzia, zmienia zachowanie asystenta i tworzy własne skróty.
- Demonstracja: Claude Code steruje aplikacją Kalkulator na Macu nie swoją wbudowaną przeglądarką, lecz funkcją computer use zapożyczoną z aplikacji Codex — a wyniki zapisuje w sformatowanym dokumencie tekstowym.
- Sedno triku: wiele narzędzi zamkniętych w aplikacji Codex wystawia interfejs MCP, więc dowolny model językowy może z nich korzystać, jeśli zbuduje się odpowiedni pomost.
- Architektura pracy: Claude podejmuje decyzje, Codex wykonuje ruchy; każde kliknięcie wraca do Claude jako wizualne potwierdzenie i wyznacza kolejny krok.
- Budowa przebiegła etapami: podsłuchiwanie działania Codexa, powstanie launchera, a potem pomocnika, który utrzymuje połączenie i po cichu obsługuje warstwę uprawnień.
- Prompt budowy rozłożony na części: jasny cel nadrzędny, zawsze najnowsza wersja aplikacji, instrukcja dla pomostu, model uprawnień z trzema opcjami, przełącznik wbudowanej przeglądarki, izolacja sesji między czatami.
- Oszczędność: zamiast dopłacać za agents API wystarczy zwykła subskrypcja aplikacji Codex — bez kosztów pośrednich.
- Drugi mod, „threads”, przenosi do aplikacji desktop Claude funkcję znaną z Codexa: równoległe wątki z różnymi modelami i jednym wątkiem prowadzącym, który składa wynik w spójną całość.
- Panel boczny daje pełną przejrzystość: widać wątek prowadzący, postęp pozostałych, bieżący koszt — a całością, także zdalnie, można sterować z jednego miejsca.
- Główna lekcja procesu: gdy Claude twierdzi, że coś jest niemożliwe, trzeba kazać mu zbadać własne API i CLI, a testy wyegzekwować poleceniem „/goal”.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Funkcje konkurencyjnej aplikacji często da się pożyczyć przez MCP
Na czym polega: Sterowanie aplikacjami okienkowymi (computer use) w aplikacji Codex jest wystawione jako serwer MCP. Skoro tak, nie trzeba czekać, aż Anthropic zbuduje odpowiednik — dowolny model, także Claude, może korzystać z tych narzędzi przez odpowiedni łącznik.
Jak stosować: Zanim uznasz, że jakaś funkcja „istnieje tylko u konkurencji”, sprawdź, czy nie ma interfejsu MCP. Jeśli tak — poproś asystenta o obserwację działania aplikacji, audyt logów i zbudowanie pomostu.
Na co uważać: Takie połączenie nie jest oficjalnie wspierane: aktualizacja aplikacji może je unieruchomić, a automatyczne zatwierdzanie uprawnień osłabia bezpieczeństwo. Traktuj to jako eksperyment.
2.„To niemożliwe” to często pierwsza reakcja modelu, a nie fakt
Na czym polega: Claude od razu oświadcza, że prowizoryczne połączenia są niewykonalne — dopóki nie każesz mu realnie sprawdzić. Autor wprost wpisuje do promptu: zanim uznasz funkcję za niemożliwą, zbadaj zainstalowane API do tworzenia modów i pomoc CLI oraz odróżnij brakujące narzędzie od możliwości, którą można dorobić.
Jak stosować: Przy pierwszej odmowie nie przekonuj, tylko każ modelowi przeprowadzić konkretną inspekcję: uruchomić aplikację, przejrzeć logi, wypisać dostępne narzędzia. Po faktycznym sprawdzeniu model zwykle sam przyznaje, że się da.
Na co uważać: Odmowa bywa też uzasadniona — odróżnij realny brak możliwości od niechęci modelu, pytając o konkretne narzędzia, a nie o ogólną „wykonalność”.
3.Odwrócona inżynieria zaczyna się od podsłuchania, nie od pisania kodu
Na czym polega: Autor nie projektował pomostu od zera. Poprosił Claude o obserwację, jak Codex uruchamia computer use, i o nasłuchiwanie usług wołanych po drodze. Dopiero z tych obserwacji powstał skrypt-launcher, a potem pomocnik utrzymujący połączenie.
Jak stosować: Gdy chcesz odtworzyć czyjeś zachowanie, najpierw zbierz dane: uruchom funkcję i zapisz, co dzieje się pod maską. Dopiero na tym fundamencie pisz prompt z instrukcją budowy.
Na co uważać: Ten etap jest żmudny i iteracyjny — autorowi zajęło około godziny poprawek, zanim wszystko zagrało.
4.Pomost ma zdjąć z użytkownika całą biurokrację uprawnień
Na czym polega: Pożyczone narzędzie bez przerwy pyta o zgodę („czy mogę kliknąć?”). W budowie jest więc lokalny pomocnik, który utrzymuje żywe połączenie z sesją Codexa i w tle załatwia warstwę uprawnień — przy pierwszym użyciu danej aplikacji pyta użytkownika, z trzema opcjami do wyboru, potem już nie zawraca głowy.
Jak stosować: Przy każdym eksperymentalnym łączniku zaprojektuj model uprawnień: pytaj przy pierwszym kontakcie z aplikacją, zapamiętuj decyzję i nie powtarzaj pytania w kółko.
Na co uważać: Bezmyślne „dopuszczam zawsze” to prosta droga do sytuacji, w której agent zrobi coś, czego nie chcesz. Zaczynaj od zgody ograniczonej do danego czatu.
5.Łącz się zawsze z najnowszą wersją aplikacji
Na czym polega: W prompcie jest jawne polecenie, by mod przy każdym uruchomieniu sięgał po najświeższą wersję aplikacji Codex — to zabezpieczenie na wypadek aktualizacji, które mogłyby posypać połączenie.
Jak stosować: Jeśli twoje narzędzie zależy od obcej aplikacji, nie zaszywaj w nim konkretnej wersji — sprawdzaj aktualną przy starcie i testuj całość po każdej aktualizacji.
Na co uważać: Nawet z tym zabezpieczeniem aktualizacja może zmienić nazwy narzędzi lub logikę działania — miej przygotowaną ścieżkę diagnostyczną (patrz wniosek 7).
6.Nie płać drugi raz: subskrypcja zamiast API
Na czym polega: Zamiast przepuszczać tę konstrukcję przez płatne agents API, pomost korzysta ze zwykłej subskrypcji aplikacji Codex, którą autor już posiada — bez żadnych dodatkowych kosztów pośrednich.
Jak stosować: Zanim dołożysz nowe API do swojego zestawu narzędzi, sprawdź, czy funkcja nie jest dostępna w aplikacji, za którą już płacisz, i czy da się ją wystawić jako MCP.
Na co uważać: Limity subskrypcji i warunki świadczenia usługi mogą blokować intensywne lub zautomatyzowane korzystanie pośrednie.
7.„/goal”: test w boju i sposób na przełamanie oporu modelu
Na czym polega: Polecenie „/goal” każe Claude samodzielnie doprowadzić do wyznaczonego celu — tu: przetestować mod w boju (jeden wątek, wiadomość, plan krok po kroku, obserwacja wykonania; potem dwa wątki i tak dalej). Pali mnóstwo tokenów, ale bywa jedynym sposobem, by model przestał powtarzać „nie da się” i zaczął działać.
Jak stosować: Gdy model kręci nosem, sformułuj sprawdzanie jako cel do osiągnięcia, nie jako pytanie. Testuj skalując: od pojedynczego wątku do pełnego zespołu.
Na co uważać: Koszt bywa znaczny — używaj „/goal” punktowo, do zamkniętych i precyzyjnie zdefiniowanych zadań.
8.Rozdzielaj pracę między modele według ceny za inteligencję
Na czym polega: W prompcie wątków opisany jest przepływ pracy: plan tworzy Opus (tu warto wydać tokeny rozsądnie), notatki trafiają do pomocnika na Sonnet, a końcową kontrolę robi Haiku. Poszczególne etapy dostają tyle „mózgu”, ile naprawdę wymagają.
Jak stosować: Przy pracy wielowątkowej przydzielaj modele etapami: najdroższy do planowania, średni do wykonania, najtańszy do kontroli i rutyny. Dobieraj też poziom wysiłku (effort level) do każdego wątku z osobna.
Na co uważać: Zbyt tani model na kluczowym etapie zniweczy całość — oszczędności nie mogą obejmować decyzji o największej wadze.
9.Równoległość bez panelu kontroli to dopiero połowa sukcesu
Na czym polega: Mod „threads” otwiera panel z boku ekranu: widać wątek prowadzący, startujące podwątki, bieżący koszt i pełne transkrypcje, a własne przyciski pozwalają kierować całym zespołem z jednego miejsca. Dodatkowo każdy wątek nadaje się do zdalnego sterowania — można odejść od komputera i prowadzić pracę dalej.
Jak stosować: Projektując automat, od razu wbuduj widoczność postępu, wykrywanie utknięcia i logowanie kosztu; zadbaj o sterowanie zbiorcze i dostęp zdalny.
Na co uważać: Nawet tak oczywiste wymaganie jak zdalne sterowanie autor musiał dopisać po wielu iteracjach — nie zakładaj, że model zgadnie sam.
10.Nie zaczynaj od zera: cudze prompty i kod to najlepsze paliwo
Na czym polega: Żaden z modów nie powstał „za pierwszym podejściem”, ale gotowe prompty i repozytorium na GitHubie pozwalają je przejąć, przerobić i użyć po swojemu. Sam zbiór promptów i kodu wystarcza jako kontekst startowy dla Claude i Opusa 5.5 do podejmowania kolejnych dużych wyzwań.
Jak stosować: Przed ambitnym projektem zbierz istniejące prompty, kod i dokumentację — i wrzuć je modelowi jako inspirację oraz punkt wyjścia.
Na co uważać: Gotowiec trzeba zweryfikować pod własne środowisko i aktualną wersję aplikacji — kopiowanie bez testów kończy się cichymi awariami.
Redakcyjne tłumaczenie
Kalkulator sterowany z cudzej aplikacji
Popatrzcie na to. Pokażę ciekawy przykład wyciśnięcia z modów wszystkiego, co się da: sprawię, że Claude Code wykona zadanie funkcją computer use — tyle że nie swoją, tylko zapożyczoną z aplikacji Codex. Wystarczy, że wpiszę polecenie „/codex-cu” i włączę tryb. Teraz wysyłam prompt.
Ma on sprawić, że Claude Code zignoruje własną wbudowaną przeglądarkę i zamiast tego odnajdzie pomost do funkcji computer use z Codexa, żeby wykonać zadanie. Jak widać, moduł rusza — na dole ekranu widać, że jest aktywny — i za chwilę powinien otworzyć aplikację Kalkulator. I proszę: obsługuje ją, zapisuje dokładnie to, co policzył (tu: pewną hipotetyczną subskrypcję) i podaje wynik.
Przyspieszyłem nagranie, ale efekt widać wyraźnie: asystent obsłużył kalkulator, a wyniki zapisał w dokumencie tekstowym — pogrubione, sformatowane, tak żeby dało się je przeczytać. W tym filmie przeprowadzę was przez to, jak złożyłem tę całość — i jak sami możecie to odtworzyć. Mam też drugi mod, który moim zdaniem bardzo wam się spodoba, zwłaszcza jeśli przy pracy z Claude kiedykolwiek pomyśleliście: „czemu po prostu tego nie potrafi?”. Bo dziś sporo brakujących funkcji możecie dorobić sami. Jeśli więc chcecie podnieść swoją grę modową na wyższy poziom — zaczynajmy.
Czym są mody — szybkie przypomnienie
W poprzednim materiale pokazywałem, czym są mody i jak działają, ale w skrócie: mod to dodatek, którym dopasowujecie Claude Code do siebie. Można nim dodać narzędzie, zmienić sposób, w jaki asystent podchodzi do określonych zadań, albo zrobić sobie przycisk pod czynność wykonywaną w kółko, którą chce się skrócić.
Tym razem chciałem zejść ze swoich podstawowych modów poziom głębiej. Pytanie brzmiało: czy za ich pomocą mogę dorzucić funkcje, których zawsze brakowało mi w Claude — albo odtworzyć możliwości Codexa, które mi się podobają i na które cierpliwie czekam, aż zespół Anthropicu w końcu je zbuduje?
Claude jako mózg, Codex jako ręce
Zobaczmy, jak to działa od środka. Gdy wysłałem Claude ten prompt, musiał zdecydować, który przycisk nacisnąć. Na podstawie celu wyłonionego z polecenia uznał, że potrzebuje modu; gdy zrozumiał, o który chodzi, przekazał sterowanie do zestawu narzędzi Codexa. Te narzędzia oddałem do dyspozycji Claude — więc zamiast zmuszać modele Codexa do orkiestracji własnych funkcji, mógł to robić Claude. Przy zadaniu z kalkulatorem stał się w praktyce mózgiem, który dysponuje kończynami Codexa. Za każdym razem, gdy coś kliknął lub wykonał ruch, wizualne potwierdzenie wracało do niego — i na tej podstawie podejmował kolejną decyzję, gdzie kliknąć dalej.
Możecie się zastanawiać, jak w ogóle możliwy jest dostęp do narzędzi zaprojektowanych przecież wyłącznie dla aplikacji Codex. Najważniejsze jest to, że wiele z nich można wystawić jako MCP, a wtedy praktycznie dowolny duży model językowy — nie tylko Claude — z nich skorzysta, jeśli zbuduje się odpowiedni pomost. (Informacja dodatkowa: MCP, czyli Model Context Protocol, to otwarty standard łączenia modeli językowych z zewnętrznymi narzędziami i danymi.)
Etapy budowy: nasłuchiwanie, launcher, pomocnik
Rozbiję teraz na fazy to, o co prosiłem Claude. W największym skrócie: kazałem mu obserwować, jak otwieram Codex i korzystam z jego computer use, i podsłuchiwać wszystkie usługi, które przy tym pracują. Chodziło o odtworzenie od podszewki, jak dotrzeć do tych mechanizmów. Gdy to rozgryzł, napisał skrypt nazwany launcherem — otwiera on drogę do kolejnego etapu.
Następna przeszkoda: skoro pożyczamy narzędzie z obcej usługi, prędzej czy później pojawiają się uprawnienia. Codex pytałby bez końca: „mogę użyć tego narzędzia? mogę tu kliknąć?”. Potrzebowałem sposobu, by Claude nie musiał przechodzić przez to w kółko. Po nieco nacisków powstał mały program utrzymujący żywe połączenie z sesją Codexa. Ten pomost — nazywam go pomocnikiem — nie tylko trzyma połączenie otwarte, ale po cichu obsługuje wszystkie warstwy uprawnień: gdy sesja prosi o zgodę, automatycznie ją otrzymuje.
Prompt budowy, część po części
Mając to z głowy, przejdźmy do pełnego prompta budowy.
Pierwsza część to oczywiście rozpisanie celu nadrzędnego. U mnie zabrzmiał on bardzo konkretnie: chcę mod do Claude Code, dzięki któremu za każdym razem, gdy poproszę cię o coś na moim Macu — policzenie czegoś w kalkulatorze, napisanie notatki — użyjesz computer use z Codexa zamiast własnego. Codex ma klikać i pisać w moich aplikacjach w tle, bez przejmowania mojej myszki.
Jedna irytująca cecha Claude: często od razu oświadcza, że takie prowizoryczne połączenia są niewykonalne — dopóki nie zacznie się drążyć. Wtedy mówię: otworzę aplikację Codex, chcę, żebyś obserwował, jak uruchamiam computer use, i nasłuchiwał wszystkich narzędzi pracujących pod spodem; może znajdziemy sposób, żeby się do nich dobrać. Zwykle, gdy model faktycznie to sprawdzi, orientuje się, że się mylił — i że się da. To jest właśnie nić, za którą warto pociągnąć, żeby odtworzyć resztę połączenia.
Od wyjaśniania celu przechodzimy więc do bardzo szczegółowego opisu łączenia się z Codexem. Jako zabezpieczenie — żeby nic się nie posypało po aktualizacji aplikacji — wpisujemy wymóg sięgania zawsze po najnowszą wersję.
Dalej pojawia się launcher: to on łączy się z serwerem MCP, a obok podajemy nazwę tego konkretnego serwera, który otwiera dostęp do computer use. Jest też instrukcja dla pomostu między Codexem a Claude: zbuduj trwałego lokalnego pomocnika, który będzie klientem MCP tego serwera; ma nawiązywać połączenie, obsługiwać wywołania narzędzi i prośby o zatwierdzenie aplikacji itd.
Bo to rozwiązanie jest eksperymentalne — przy pierwszym użyciu narzędzia ma nas zapytać o zgodę; skoro powiemy „działaj”, nie chcemy być pytani ponownie. Stąd zapis: przed pierwszym użyciem danej aplikacji zapytaj mnie i daj trzy opcje — „dopuszczam w tym czacie”, „dopuszczam zawsze” albo „nie dopuszczaj”.
Zdarza się, że i tak wolę, żeby Claude używał własnej wbudowanej przeglądarki — to po prostu wygodniejszy sposób, żeby sprawdził swoją pracę, na przykład przejrzał aplikację, którą złożyłem, albo stronę, którą wystarczy przewinąć. Chciałem więc mieć łatwy włącznik i wyłącznik tego dodatku, domyślnie włączonego w każdym czacie.
Jeszcze jedna uwaga: zamiast korzystać z agents API i dopłacać, rozwiązanie pozwala pójść na skróty przez subskrypcję aplikacji Codex, którą już mam — bez żadnych dodatkowych kosztów pomiędzy.
Kolejna, bardziej techniczna część zabezpiecza jedną rzecz: jeśli użyję narzędzia w jednym czacie, a potem otworzę nowy, nie chcę, żeby narzędzie zostało przyklejone do obsługi tamtego poprzedniego. Całość jest do poczytania w oryginale — ten prompt, podobnie jak prompt drugiego modu, wrzucam pod drugim linkiem w opisie.
Potem rzecz oczywista: trzeba to przetestować, a kalkulator to chyba najprostszy sposób na sprawdzenie całej drogi od początku do końca. Część siódma każe Claude przygotować zestaw kroków diagnostycznych na wypadek, gdyby computer use z Codexa nawalił. W ósmej mocno pomógł mi sam AI: wskazałem dokładnie, gdzie pliki mają trafić, żeby moja biblioteka modów nie spuchła.
Ile to naprawdę trwało
Czy poszło za pierwszym razem? Oczywiście, że nie. Ale po kilku próbach dałem mu „/goal”, powiedziałem wprost, co diagnozować na podstawie zbieranych błędów — i po może godzinie w końcu zaskoczyło. Nie zamierzam jednak każdemu z was kazać przechodzić tej samej drogi, jeśli chcecie odtworzyć dokładnie ten mod: pod linkiem znajdziecie też moje repozytorium na GitHubie z całym kodem. Bierzcie, podpinajcie, przerabiajcie pod siebie — jak wam pasuje.
Mod „threads”: zespół wątków jak w Codexie
Drugi mod, który chcę wam pokazać, nazywa się „threads”. Wiem — na ekranie nie mam Claude, tylko Codex, i jest ku temu powód: zawsze mi tego brakowało i czekałem na moment, w którym Claude nabędzie dokładnie tę funkcję, którą zaraz pokażę — pokazywałem ją już w poprzednich materiałach. Posłuchajcie, co mówię do asystenta:
„Chcę, żebyś odpalił serię wątków z różnymi modelami, dobranymi do poziomu inteligencji potrzebnego w poszczególnych częściach zadania. Zrób przy tym pełny research: które modele najlepiej łączyć? Opus 5.5 i GPT-6 Astra? Na jakich poziomach wysiłku? Same modele GPT-6? Same Opusy? A może coś jak Sonnet 5.5 albo Opus 5.5? Odpal serię wątków, wyznacz jeden wątek prowadzący i niech on zorganizuje podwątki tak, żeby stale raportowały — a na końcu dostajemy jedną spójną odpowiedź.”
Sporo jak na jedno polecenie. Ale gdy to wyślę, ta funkcja potrafi: odpalić wszystkie wątki, nadać im nazwy, prowadzić je równolegle i trzymać nad nimi nadzorcę. Przy większej skali robi się z tego bardzo użyteczne narzędzie. I proszę — jednym ruchem pięć wątków działa równocześnie i współpracuje ze sobą. W aplikacji desktop Claude czegoś takiego nie zrobicie. Można kombinować w terminalu, żeby uzyskać zbliżone zachowanie, można sięgnąć po narzędzia pokroju Herdera, jeśli jest się bardziej technicznym — ale jeśli chce się zostać przy zwykłej aplikacji, musi istnieć lepsza droga.
Sprawdźmy to. Otwieram świeży czat w Claude desktop i pytam: „czy możesz, gdy poproszę, odpalać wątki z różnymi modelami w aplikacji desktop?” — i w tym wypadku wyraźnie każę mu nie korzystać z modu, który już zbudowałem. Odpowiedź: nie, nie potrafi; najwyżej uruchomi podagenty na wybranym modelu. Ale skoro mamy na to mod, możemy wysłać dokładnie ten sam prompt z dopiskiem: „koniecznie wykorzystaj mod threads”. I powinien zacząć budować to samo zachowanie — tylko inną drogą niż Codex.
I już: rusza część modu odpowiedzialna za tworzenie wątków; pojawiają się w lewym dolnym rogu. Po prawej otwiera się panel, w którym śledzimy wszystko: który model prowadzi, jakie wątki właśnie startują i ile w tym wszystkim wydajemy. A jest jeszcze jedna superciekawa rzecz: można sobie dodawać własne przyciski. Jeśli chcę skierować rozmowę albo zadanie dla wszystkich wątków naraz, robię to z jednego miejsca w panelu.
I gotowe. Odpaliliśmy wszystkie wątki i odtworzyliśmy doświadczenie znane z Codexa — a w wielu miejscach je ulepszyliśmy. Bo całością da się tu zarządzać, mamy pełną przejrzystość, mamy wszystkie transkrypcje i można dokładać tej funkcji kolejne poziomy złożoności. A gdy wątki skończą, wspólny efekt ląduje w głównym czacie.
Jak powstał mod „threads”
Patrząc z lotu ptaka: samo wytłumaczenie tej funkcji prostymi słowami — nawet z pomocą AI piszącego meta-prompt — nie było łatwe. Zrobiłem więc podobnie jak przy computer use. Powiedziałem Claude, że zaraz otworzę aplikację Codex i utworzę wiele wątków z jednej rozmowy, i chciałem, żeby prześwietlił wszystkie logi Codexa: co dokładnie robi, jak decyduje o tworzeniu wątków i — co dla mnie najważniejsze — jak robi to w samej aplikacji, a nie w jakimś terminalu. Bo w terminalu takie zachowanie uzyska się znacznie łatwiej; w normalnej aplikacji z interfejsem graficznym trzeba trochę pogimnastykować.
Oto prompt, który wysłałem — omówię najistotniejsze fragmenty. Mówiąc nietechnicznie: chcę zbudować mod Claude Code o nazwie threads. Zanim cokolwiek napiszesz, wczytaj wbudowany przewodnik (skill) do tworzenia pluginów i przypomnij sobie, jak działają mody; przejrzyj dokumentację i nabierz pełnego kontekstu, zanim ruszymy dalej.
Potem rozkładam koncepcję: ten czat ma być szefem małego zespołu. Gdy powiem „odpal pomocnika na Haiku, żeby zlistował mi pliki, i pomocnika na Opusie, żeby przejrzał mój readme”, mod uruchamia każdego pomocnika w jego własnej, prawdziwej sesji Claude Code, na modelu, o który poprosiłem. A jeśli powiem, żeby użył własnego osądu — tak jak pokazywałem w Codexie — powinien i to potrafić.
Tu byłem już raz przez Claude przejechany, więc dopisałem wprost: zanim uznasz, że funkcja jest niemożliwa, zbadaj zainstalowane API do tworzenia modów i pomoc bieżącego CLI, i rozróżnij brakujące w tym czacie narzędzie od możliwości, którą można po prostu dorobić.
Zacząłem drążyć: rozbij na części, jak działa aplikacja Codex i jak działa aplikacja Claude Code. I wtedy usłyszałem: no przecież są narzędzia zarządzające panelem bocznym, są narzędzia zarządzające wątkami w czatach. Gdy tylko pozwoliłem mu rozpoznać, do czego ma dostęp, i podałem cel — dosłownie przez „/goal” — naciskałem i naciskałem, aż sam zobaczył, że to wykonalne. Trzeba być po prostu znacznie bardziej kreatywnym.
Podobnie jak przy pierwszym modzie, i tu potrzebny był pomocnik. Zapis: każdy pomocnik to zwykła sesja Claude Code. A jeśli masz wątpliwości, jakich modeli można używać, po prostu uruchom „claude —help” — w terminalu dostaniesz całą podstawową funkcjonalność Claude do przejrzenia, czym on sam może się wspomóc.
Potem podsunięliśmy mu na tacy, czego szukać: ustawianie modelu, nadawanie sesji nazwy, pokazywanie jej w panelu bocznym Claude desktop. Każemy mu: przejrzyj narzędzia do operowania panelem bocznym; pomiń pytania o uprawnienia — bo w pierwotnej wersji tworzył nową sesję, a potem prosił, żebyśmy w nią weszli i kliknęli enter, wyrażając zgodę na wykonanie prompta. Gdy to zaczęło działać, zeszliśmy poziom głębiej: poziomy wysiłku (effort level) i dodatkowe instrukcje.
Ten element nie wziął się znikąd. Powiedzieliśmy mu wprost: chcemy widzieć postęp wszystkich wątków, więc potrzebujemy stałego sposobu sprawdzania, czy któryś nie utknął — a jeśli tak, niech się nim zajmie. Wtedy podsunęliśmy mu pomysł, jak tworzyć i logować odpowiednik kosztu API dla wszystkich dodatkowych sesji.
Kolejne sekcje wchodzą w szczegóły: jak prowadzić różne rodzaje pracy, w jakiej kolejności i jak to wygląda w praktyce. Na przykład: plan robi Opus — tam chcemy wydać tokeny rozsądnie; zostawia notatki, a te trafiają do pomocnika na Sonnet; gdy Sonnet skończy, oddaje robotę Haiku na końcowe przejrzenie i ostateczny wynik. (Informacja dodatkowa: Opus, Sonnet i Haiku to klasy modeli Anthropic — od najmocniejszej i najdroższej po najtańszą.)
Przy naprawdę skomplikowanych modach kluczowe jest podanie jawnej listy rzeczy do przetestowania. Dałem mu więc „/goal”. Tak, to spala tony tokenów — ale bywa, że gdy Claude odmawia i zaprzecza, rzucenie mu „/goal” przynosi coś konkretnego: „okej, masz tę funkcję; chcę, żebyś przetestował ją w boju — twórz jeden wątek, wysyłaj mu wiadomość, wysyłaj plan krok po kroku i patrz, jak wykonuje do końca; jeśli działa, przechodzimy do dwóch wątków i tak dalej”. Właśnie ten „/goal” daje mu dodatkowego kopa, żeby sprawdził, co jest możliwe, i to ocenił.
Jeszcze jeden niuans: chciałem, żeby każdy wątek nadawał się do zdalnego sterowania — żebym mógł odejść od komputera i nadal kierować podwątkami. Nawet to musiałem doprecyzować po sporej liczbie iteracji. Szczegółów jest zdecydowanie więcej, ale prompt przeczytacie sami i zobaczycie, które fragmenty was najbardziej zaciekawią.
Trudne? Tak. Możliwe? Praktycznie bez granic
Czy oba mody powstały łatwo? Nie. Czy da się — i czy paleta możliwości jest praktycznie nieograniczona, jeśli tylko potraficie dokładnie wyobrazić sobie cel, drogę jego osiągnięcia i, co najważniejsze, to, jak zmusić Claude do testowania własnej pracy? Tak. W gruncie rzeczy wystarczy wziąć moje prompty z poprzedniego filmu i tego, do tego kod — samo wrzucenie tego wszystkiego daje Claude’owi i Opusowi 5.5 dość inspiracji, żeby zabrał się za wasze następne duże, wymagające wyzwanie.
Na koniec
To w zasadzie tyle. Wszystkie zasoby do obu modów znajdziecie pod drugim linkiem w opisie. A jeśli chcecie zejść głębiej w tematy pokroju modów — naprawdę zrozumieć, jak ten system działa i jak zastosować go u siebie — pierwszy link prowadzi do mojej społeczności early adopters. Pozostali: jeśli uznaliście ten materiał za pomocny i świeży, byłbym wdzięczny za łapkę i komentarz. To realnie pomaga filmowi i kanałowi. Do zobaczenia w następnym.