O czym jest ten film
- Ktoś zestawił dziewięć najpopularniejszych pakietów umiejętności (skills) dla Claude’a z plikiem-atrapą o tej samej długości — siedem nie wypadło lepiej niż atrapa, bo model robi dziś większość tej pracy sam z siebie.
- Nowa definicja skilla: nie instrukcja krok po kroku, lecz lista poprawek do tego, czego model nie umie jeszcze z marszu. Anthropic zaleca wykonanie każdego zadania najpierw bez umiejętności.
- Oficjalny plugin skill eval uruchamia to samo zadanie z umiejętnością i bez niej — każdy skill, który nie daje lepszego wyniku, warto przytnąć albo usunąć i odzyskać kontekst.
- Przełączanie modeli w trakcie sesji psuje cache (każdy model trzyma własną pamięć podręczną rozmowy), więc rzekome oszczędności na tańszym modelu potrafią podnieść rachunek wielokrotnie; lepszą dźwignią jest poziom wysiłku.
- Tryb advisor pozwala prowadzić pracę na tańszym modelu i odpytywać mocniejszego w trzech momentach: przed wyborem podejścia, przy nawracającym błędzie i przed ogłoszeniem zakończenia.
- Twórcy Claude Code odchodzą od trybu planowania, ale samo planowanie — definicja „gotowe” i barierki dla modelu — zostaje kluczowe, zwłaszcza przy dużych zmianach w wielu plikach.
- Cel w /goal musi generować dowód w samej rozmowie, bo sprawdzający model nie otwiera plików — nieostry warunek kończy pracę za wcześnie.
- Pełne okno kontekstu szkodzi jakości: w teście Anthropic trafność odnajdowania szczegółów spadła z 93 do 76 procent przy milionie tokenów; wielokrotnego użytku treści lepiej trzymać w plikach ładowanych na żądanie.
- Domyślne ustawienia (model, wysiłek, uprawnienia, moment kompresji) są dziś zwykle lepsze niż ręczne strojenie; podobnie Claude sam wybiera między podagentami a rozgałęzieniami rozmowy.
- Do pracy bez nadzoru służą hooki jako gwarancje (kontrola na zdarzeniu stop), dynamiczne workflow (ultra code), rutyny wyzwalane zdarzeniami i sesje chmurowe — a wyczerpany limit nie przerywa już zadania, tylko wstrzymuje je do odnowienia.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Najpierw zadanie bez skilla, umiejętność pisz tylko z poprawek
Na czym polega: Dawniej skille budowano jak procedury operacyjne — setki linijek reguł. Dziś Claude sam stosuje większość takich zasad, a testy pokazują, że popularne pakiety nie biją nawet pliku-atrapy. Skill ma zawierać wyłącznie to, czego model nie wymyśli sam, plus twoje niuanse.
Jak stosować: Nowe zadanie wykonaj najpierw w całości bez umiejętności. Zapisz każdy punkt, w którym Claude się pomylił, i dopiero te punkty przenieś do skilla jako reguły. W starych umiejętnościach wycinaj fragmenty, które model realizuje już domyślnie.
Na co uważać: Nie kasuj wszystkiego hurtem — test z atrapą dotyczył konkretnych pakietów, a twoje indywidualne reguły (np. głos marki) nadal mogą wnosić wartość. Za pół roku i ten resztkowy zestaw może okazać się zbędny.
2.Testuj skille pluginem skill eval, nie na wyczucie
Na czym polega: Oficjalny plugin Anthropic uruchamia to samo zadanie równolegle w dwóch wersjach — z twoją umiejętnością i bez niej — co obiektywizuje decyzję, co zostaje.
Jak stosować: Zainstaluj plugin, odpal porównanie przed i po, a potem sam oceń jakość obu wyników. Skilla, który nie daje lepszej pracy niż model bez wsparcia, usuń w całości i odzyskaj miejsce w kontekście — albo przytnij do fragmentów, które realnie coś zmieniają.
Na co uważać: Porównania jakości nie zrobi za ciebie plugin. Pamiętaj też, że każdy zainstalowany skill zżera kontekst nawet wtedy, gdy nic nie wnosi.
3.Wybierz model na start zadania i nie przeskakuj między nimi
Na czym polega: Każdy model utrzymuje własną, buforowaną kopię rozmowy. Przejście w trakcie sesji na tańszy model wymusza ponowne przeczytanie całej historii po pełnej cenie — i to samo przy powrocie. Do tego mniejszy model bywa tańszy na token, a droższy na całe zadanie: potrzebuje więcej prób i czasu.
Jak stosować: Na początku zadania wybierz jeden model i trzymaj się go do końca. Przy łatwym pytaniu zejdź z poziomem wysiłku albo napisz wprost: „odpowiedz krótko, bez rozwlekłego rozumowania”.
Na co uważać: Pozorne oszczędności na Haiku potrafią skończyć się kilkukrotnie wyższym rachunkiem — w jednym z testów Haiku 5.5 wystawił więcej zapytań niż większe modele i był niemal dwukrotnie wolniejszy od Sonnetu na długich sesjach.
4.Advisor: mocniejszy model „na telefon”, bez psucia cache
Na czym polega: Tryb doradcy pozwala prowadzić główną robotę na tańszym modelu (np. Sonnet) i odpytywać mocniejszego (Opus, Fable) w trudnych momentach. Włączenie doradcy w trakcie sesji nie unieważnia buforowanej kopii rozmowy, w przeciwieństwie do ręcznej zmiany modelu.
Jak stosować: W sesji na Sonnecie wpisz /advisor Opus. Claude sam sięgnie po doradcę w trzech sytuacjach: zanim zobowiąże się do jakiegoś podejścia, gdy ten sam błąd wraca po raz kolejny oraz tuż przed ogłoszeniem, że skończył — wtedy drugi model weryfikuje wynik.
Na co uważać: Funkcja jest oznaczona jako eksperymentalna, więc spodziewaj się zmian. Na subskrypcji (bez płacenia za API) często prościej i przewidywalniej jest zostać przy jednym modelu przez całe zadanie.
5.Planuj, ale niekoniecznie w trybie planowania
Na czym polega: Twórcy Claude Code uważają tryb planowania za przeżytek i rozważają jego usunięcie (Shift+Tab służyłby wtedy do sterowania poziomem wysiłku). Sam plan — definicja „gotowe” i barierki dla modelu — pozostaje jednak najtańszym sposobem uniknięcia przerabiania setek linijek w wielu plikach. Tryb ma dziś jedną realną funkcję: blokuje edycje do twojej aprobaty.
Jak stosować: Przy dużym, niejasnym zadaniu dotykającym wielu plików: każ Claude’owi przeprowadzić z tobą wywiad, zapisać konkretny plan do pliku, a realizację zacząć w świeżej sesji (to oficjalna rada Anthropic). Gdy zmiana mieści się w jednym akapicie albo to nie jest kilkudniowa budowa — planowanie odpuść albo zostaw krótką listę celów, definicję „gotowe” i barierki.
Na co uważać: Nie planuj mechanicznie wszystkiego — przy drobnych zadaniach to strata czasu. Jeśli trzymasz się trybu dla poczucia bezpieczeństwa, miej świadomość, że jego przyszłość jest niepewna.
6./goal działa tylko wtedy, gdy cel generuje dowód w rozmowie
Na czym polega: Po każdej turze osobny, mały model sprawdza, czy cel został osiągnięty — ale widzi wyłącznie przebieg rozmowy. Nie otwiera plików i niczego nie uruchamia, więc nieostry warunek typu „raport jest skończony” przyjmie na słowo Claude’a.
Jak stosować: Zanim odpalisz /goal, poproś Claude’a o napisanie skryptu sprawdzającego z deterministycznymi warunkami. Cel formułuj tak, by jego spełnienie zostawiało ślad w czacie — np. „skrypt check-report przechodzi i pokazujesz mi jego wynik; szablon pozostał bez zmian; zatrzymaj się po piętnastu turach”.
Na co uważać: Sprawdzian nie zweryfikuje niczego poza rozmową — pliki i zewnętrzne systemy muszą „zaświadczyć o sobie” w czacie, inaczej pętla zakończy się za wcześnie albo wcale, gdy warunek jest nieweryfikowalny.
7.Trzymaj kontekst w plikach ze wskaźnikami, nie w oknie rozmowy
Na czym polega: W teście Anthropic na Opusie 4.6 trafność odnajdywania ośmiu ukrytych w kontekście szczegółów wyniosła 93 procent przy 250 tys. tokenów i 76 procent przy pełnym milionie. Większe oknie to po prostu więcej miejsc, w których detal się gubi.
Jak stosować: Materiały wielokrotnego użytku zapisuj w zagnieżdżonych folderach, a z Claude.md lub z skillsów odwołuj się do nich wskaźnikami — treść danego pliku ładuje się dopiero wtedy, gdy jest potrzebna. W tym samym kierunku zmierza funkcja projektów.
Na co uważać: Nie wrzucaj dokumentów do rozmowy tylko dlatego, że „zmieści się w oknie”. Jeśli wciąż pracujesz w zwykłym czacie, kontekst przekazuj między rozmowami linkami udostępniania.
8.Zostaw domyślne ustawienia, dopóki coś realnie nie zawiedzie
Na czym polega: Domyślne wartości — Opus 5.5 jako model (także na planach płatnych), średni poziom wysiłku, automatyczne uprawnienia z klasyfikatorem od sierpnia, moment kompresji rozmowy strojony pod konkretny model — są dziś zwykle lepsze niż typowe ręczne strojenie. Opus 5.5 na średnim wysiłku dorównuje lub przewyższa Opusa 5 na wysokim i maksymalnym.
Jak stosować: Zanim cokolwiek zmienisz, zajrzyj do dokumentacji, co dana opcja faktycznie robi (np. model ma skłonność do przesadnego kombinowania przy dołożonych tokenach). Gałki kręć dopiero wtedy, gdy wyniki zawodzą w praktyce.
Na co uważać: Podbijanie wysiłku „bo więcej znaczy lepiej” często pogarsza wynik i podnosi koszt. Uwaga także na wątki w projektach — domyślnie startują na Opusie z wysokim wysiłkiem i szybko zjadają limity (sprawdź ustawienia projektu).
9.Rozróżniaj podagenta od rozgałęzienia rozmowy
Na czym polega: Podagent startuje od zera — dostaje własne instrukcje plus to, co przekaże mu główny wątek, i wraca wyłącznie z wynikiem (wbudowane agenty explore i plan nawet nie czytają Claude.md). Rozgałęzienie (fork) to kopia rozmowy: zna całą dotychczasową historię i współdzieli buforowaną kopię, więc jego pierwsza tura jest tańsza.
Jak stosować: Od sierpnia tryb rozgałęzień jest domyślnie włączony i Claude sam wybiera między nim a podagentami — zwykle warto zostawić mu ten wybór. Gdy zadanie poboczne wymaga pełnej historii rozmowy, wymuś forka poleceniem subtask.
Na co uważać: Podagent nie zna twoich „domowych reguł” z Claude.md ani kontekstu głównego wątku — nie powierzaj mu pracy, która wymaga tej wiedzy, albo przekaż ją wprost w instrukcji.
10.Hook na zdarzeniu stop zamienia prośbę w gwarancję
Na czym polega: Linijka w Claude.md — „nigdy nie wysyłaj maila do klienta, zawsze zostaw szkic w mojej skrzynce” — to prośba, którą chcesz przenieść z poziomu „model zwykle się stosuje” na poziom gwarancji. Dokładnie to robi hook, który odpala się w ustalonym momencie za każdym razem. Co nowe: hook nie musi być już skryptem — może być promptem albo podagentem, więc kontrola potrafi przeczytać faktyczną pracę.
Jak stosować: Nie pisz hooka sam — powiedz Claude’owi wprost: „dodaj hook na stop, który czyta dokument głosu marki i najnowszy raport, a potem odsyła podsumowanie łamanych reguł”. Gdy kontrola nie przejdzie, powód wraca do modelu jako kolejna instrukcja i praca trwa do skutku.
Na co uważać: Hook-prompt czyta tylko rozmowę (tani i szybki), a hook-agent otwiera pliki, ale jest jeszcze eksperymentalny. Dopiero taka pewna kontrola uzasadnia puszczenie zadania bez nadzoru (rutyny, sesje chmurowe, dynamiczne workflow — te ostatnie ustaw w /config na „small”, czyli mniej niż pięciu agentów).
Redakcyjne tłumaczenie
Pakiety umiejętności, które można wysłać na emeryturę
Wśród umiejętności (ang. skills), które najczęściej oznaczacie gwiazdkami na GitHubie, wiele jest dziś w praktyce bezużytecznych. Ktoś porównał dziewięć najpopularniejszych pakietów dla Claude’a z plikiem-atrapą o tej samej długości — i siedem z dziewięciu nie wypadło lepiej niż atrapa. Powód jest prosty: Claude potrafi dziś zrobić z marszu większość tego, co te umiejętności mu dyktowały. A to tylko jedna z piętnastu zmian z ostatnich dziesięciu miesięcy, które umknęły większości użytkowników. Mówimy o Claude, ale wnioski w większej części dotyczą także innych interfejsów — Codexa, Cursora, aplikacji desktopowych czy własnych konfiguracji.
Od razu doprecyzujmy, żeby nie było nieporozumień: wcale nie namawiam do usuwania wszystkich skillsów i zaczynania od zera. Zmieniło się natomiast to, jak myśleć o budowaniu nowych umiejętności i o sprawdzaniu, czy w ogóle potrzebujesz zewnętrznych pakietów — bo modele same nadrobiły większość dystansu.
Skill stał się listą poprawek, nie instrukcją
W styczniu i lutym umiejętność była zwykle całym procesem rozpisanym krok po kroku — czymś w rodzaju instrukcji dla Claude’a. Tak radzili budować niemal wszyscy popularni doradcy, ja też. Przeszedłem nawet całą oficjalną dokumentację, żeby opanować inżynierię skillsów: stopniowe ujawnianie treści i pozostałe zasady. Sporo z tej logiki wciąż obowiązuje. Problem w tym, że pisaliśmy szczegółowe procedury operacyjne do zadań, które ich wcale nie wymagały.
Weźcie moją umiejętność copywriterską albo tę do „uhumanizowania” tekstów modelu. Każda z nich to setki linijek reguł i kroków dotyczących pisania. Tymczasem Claude stosuje dziś większość tych reguł z własnej logiki. Wie, że nikt nie chce papki rodem z AI, a nowe modele same piszą po ludzku. Wniosek: umiejętność powinna zawierać wyłącznie to, czego model nie wymyśli sam, plus niuanse, które chcesz wpleść w jego rozumowanie. To dużo, dużo mniej niż dziesięć miesięcy temu.
Anthropic w pierwszym kroku zaleca zresztą własnoręcznie: spróbuj wykonać każde zadanie bez umiejętności. Potem zapisz tylko to, w czym Claude się pomylił — i dopiero to dodaj do skilla. Umiejętność przestaje być procedurą, a staje się listą poprawek do procesu, którego model jeszcze nie opanował z marszu. Za pół roku może się okazać, że skillsy w ogóle przestaną być potrzebne.
Jak to przetestować: plugin skill eval
Najprostszy sposób, żeby sprawdzić, czy dana umiejętność jest ci jeszcze potrzebna, to plugin skill eval od Anthropic. Uruchamia to samo zadanie równolegle w dwóch wersjach — z twoim skillem i bez niego. Porównujesz wyniki przed i po i usuwasz każdą umiejętność, która nie daje lepszego rezultatu niż praca bez wsparcia. Wyjdzie z tego jedno z dwoje: albo przytniesz skilla, wycinając to, co model robi już sam, albo skasujesz go w całości i odzyskasz miejsce w kontekście. Oceny jakości obu wersji musisz dokonać sam — przyjrzeć się wynikom i porównać.
Pułapka tańszego modelu
Z modelami łatwo wpaść w tę samą pułapkę. Wybór tańszego modelu, żeby zaoszczędzić — na przykład zejście do Haiku — często kończy się większym rachunkiem, z dwóch powodów.
Pierwszy to cache, czyli buforowana kopia rozmowy, której kolejne odczyty kosztują mniej. (Informacja dodatkowa: dopóki pamięć podręczna jest ważna, powtórne czytanie tej samej historii jest wyraźnie tańsze; zerwanie jej przywraca pełną cenę.) Wyobraź sobie: godzina pracy na Opusie, pojawia się łatwe pytanie, więc żeby oszczędzić, przełączasz się na Haiku. Tyle że każdy model trzyma własną kopię rozmowy — nowy model czyta całą historię od zera, po pełnej cenie. Rachunek potrafi skoczyć o rząd wielkości. A gdy wracasz na Opusa do trudniejszego zadania, historia tam również nie jest już zabuforowana i czyta się od nowa. Przeskakując tam i z powrotem, płacisz za tę samą rozmowę kilka razy.
Drugi powód: model tańszy na token nie jest automatycznie tańszy na zadanie. Mniejszy model potrzebuje więcej prób i poprawek, żeby dojść do tego samego efektu, a każda próba to tokeny i twój czas. W jednym z tegomiesięcznych testów Haiku 5.5 wystawił więcej zapytań niż większe modele, a przy tej samej jakości był o połowę wolniejszy od Sonnetu na długich sesjach. Dlatego we własnym przewodniku Anthropic pisze wprost, że większość pracy powinna startować na Opusie 5.5, a lepszą dźwignią niż zmiana modelu jest sterowanie poziomem wysiłku. Praktycznie: wybierz model na początku zadania i trzymaj się go. Przy łatwym pytaniu zejdź z wysiłku albo po prostu napisz „odpowiedz krótko” — model umie pominąć dłuższe rozumowanie i oddać szybszą odpowiedź.
Doradca: mocniejszy model bez dopłaty
Da się jednak mieszać modele bez tej dopłaty — tryb doradcy (advisor), którego prawie nikt nie włączył. Główną robotę prowadzi tańszy model, powiedzmy Sonnet, a przy trudniejszym fragmencie odpytuje mocniejszego — Opusa albo Fable. To Claude sam decyduje, kiedy skorzystać z doradcy, zwykle w trzech sytuacjach: zanim zobowiąże się do jakiegoś podejścia; gdy ten sam błąd wraca po raz kolejny; oraz tuż przed tym, jak ogłosi zakończenie — wtedy drugi model jeszcze raz weryfikuje pracę. Co istotne, włączenie doradcy w trakcie sesji nie psuje bufora, w przeciwieństwie do ręcznej zmiany modelu. W sesji na Sonnecie wpisujesz /advisor Opus i — według Anthropic — zwykle wychodzi taniej niż siedzenie na mocniejszym modelu przez cały czas. Tryb jest eksperymentalny, więc spodziewaj się zmian. Osobiście wolę jednak prostotę: jeden model na jedno zadanie — zwłaszcza na subskrypcji, gdzie nie płacę za tokeny z API.
Koniec trybu planowania, ale nie planowania
W poprzednim filmie powiedziałem, że tryb planowania można odpuścić, a sporo z was w komentarzach się nie zgodziło — i słusznie, bo, jak sądzę, mówiliśmy o dwóch różnych rzeczach. Ludzie, którzy ten tryb zbudowali, sami od niego odchodzą. Boris Cherny, twórca Claude Code, powiedział wprost: był pożyteczny i przestał być. 23 września Tarik z zespołu Claude Code napisał, że rozważają jego usunięcie, a Shift+Tab służyłby do przełączania poziomów wysiłku. Dodał, że według niego modele nie potrzebują już trybu — sam planuje w artefaktach — i poprosił zagorzałych zwolenników o wyjaśnienie, po co im on jeszcze. Najlepsza odpowiedź brzmiała: „tryb planowania nie jest dla agenta, jest dla mnie”. Tarik przyznał, że dobrze to ujęte — i chyba o to samo chodziło wam w komentarzach. Zmiana planu jest dużo tańsza niż przerabianie setek linijek w wielu plikach, a dla osoby nietechnicznej plan to zresztą sposób, żeby dopracować barierki wpisywane potem w prompt.
Moja pozycja: sam tryb faktycznie traci sens, ale planowanie jako pojęcie — zdecydowanie, co znaczy „gotowe” i jakich reguł Claude ma się trzymać — zostaje. Tryb ma dziś jedną realną funkcję: blokuje edycje do czasu twojej aprobaty. Jeśli chcesz tej siatki bezpieczeństwa, na razie jest. Gdy zadanie jest duże, niejasne i dotyka wielu plików, możesz wyjść z samego trybu, a mimo to zaplanować: każ Claude’owi przeprowadzić z tobą wywiad, zapisać konkretny plan do pliku, a budować zacząć w świeżej sesji. To zresztą rada samego Anthropic. Ale jeśli zmianę daje się opisać jednym akapitem albo to nie jest kilkudniowa budowa, planowanie odpuść całkiem albo zostaw krótką listę celów, definicję „gotowe” i barierki.
Krótka wtrącenie o kursie
Ten materiał idzie w tej samej kolejności co mój nowy, piętnastogodzinny kurs w Agentic Academy. Przez 30 dni budujesz cztery warstwy — w Claude, Codexie albo Cursorze. Najpierw wyciskasz maksimum z samego okna czatu; potem stawiasz na tym porządny projekt, który już zna twój kontekst; dalej serię procesów zdolnych działać samodzielnie — od treści, przez SEO, po pracę z klientami; a na końcu własny „system operacyjny” dla agentów, który wszystko spina. Po trzydziestu dniach masz pierwszy proces pracujący bez nadzoru. Link w opisie.
/goal: dowód musi wylądować w rozmowie
Przejdźmy do tego, dlaczego /goal potrafi ogłosić „gotowe”, kiedy nic nie jest skończone — i jak to naprawić. Polecenie ma utrzymać Claude’a przy pracy, dopóki nie zostanie spełniony warunek, żeby nie wpisywać „dalej” przy każdej turze. Po każdej turze osobny, mały model sprawdza, czy cel osiągnięto, i na tej podstawie decyduje, czy wracać do roboty. Haczyk: ten sprawdzian nie otwiera plików ani niczego nie uruchamia — widzi wyłącznie dotychczasową rozmowę. Jeśli cel brzmi „raport jest skończony” albo cokolwiek nieostrego, sprawdzian przyjmie Claude’a na słowo i zakończy za wcześnie. Cel musi więc generować dowód w samym czacie, np. „skrypt check-report przechodzi i pokazujesz mi jego wynik; szablon pozostał bez zmian; zatrzymaj się po piętnastu turach”. A zanim w ogóle odpalisz /goal, użyj Claude’a do napisania samego skryptu sprawdzającego — z deterministycznymi warunkami, które da się zweryfikować.
Kontekst: milion tokenów to nie zaleta
Wszystko do tej pory dotyczyło samego okna rozmowy. Co jednak z kontekstem, który zapisujemy na stałe? Opus i Sonnet mają domyślnie milion tokenów okna, więc kusi dokładanie kolejnych porcji materiału w trakcie rozmowy. Tyle że we własnym teście Anthropic na Opusie 4.6 odnalezienie ośmiu ukrytych w kontekście szczegółów wypadło na 93 procent przy jednej czwartej okna (250 tysięcy tokenów) i na 76 procent przy pełnym milionie. Większe okno to po prostu więcej miejsca, w których szczegóły się gubią. Dlatego bardzo polecamy zapisywanie materiałów wielokrotnego użytku w zagnieżdżonych folderach i odwoływanie się do nich wskaźnikami z Claude.md albo z umiejętności — treść danego pliku ładuje się dopiero wtedy, gdy jest potrzebna, i detal się nie gubi. To także kierunek, który Anthropic deklaruje w nowej funkcji projektów.
Projekty: kierownik i jego wątki
Projekty w Claude Code zmieniły się we wrześniu. Kiedyś projekt był folderem z osobnymi czatami, słabo powiązanymi ze sobą. Dziś to jedna długa rozmowa, która sama nie wykonuje pracy: instruujesz ją jak kierownika zespołu, a ona uruchamia pod sobą wiele wątków. Każdy wątek to pełna sesja Claude Code w chmurze, startująca z instrukcji projektu i pamięcią rozmowy — i wszystko kręci się dalej po zamknięciu laptopa.
Dwie rzeczy trzeba wiedzieć, zanim taki projekt zaczniesz. Po pierwsze, rozmowa główna nie ma dostępu do twoich konektorów — mają go tylko wątki. Traktuj ją więc jak koordynatora, który narzędzia deleguje dalej. Po drugie, wątki domyślnie działają na Opusie z wysokim wysiłkiem i bardzo szybko zjadają limity — zajrzyj w ustawienia projektu i je skoryguj. Funkcja jest na razie w becie i tylko w Claude Code; czat działa po staremu, wieloma rozmowami, więc jeśli pracujesz w oknie czatu, kontekst przekazujesz między rozmowami linkami udostępniania. Projekt to miejsce na kontekst szeroki — np. głos marki. Do zadań powtarzających się, powiedzmy cotygodniowych, lepsze będą umiejętności.
Umiejętność nagrana, a nie napisana
Skoro skill jest dziś tylko listą poprawek, to da się go zdobyć bez pisania ani jednej linijki. W aplikacji desktopowej funkcja „nagraj umiejętność” (record a skill) patrzy, jak wykonujesz zadanie, i sama tworzy z tego reguły. Testowałem to na automatyzacji wiadomości prywatnych: funkcja wyłapała wszystko, co w moim demo przekłamałem względem tego, jak zadanie robi ręcznie osoba do niego przypisana, i zapisała te uwagi jako reguły. Skill wyszedł zaskakująco mały — co teraz w pełni się broni, bo zawierał wyłącznie poprawki i niszę wiedzy, których Claude nie wymyśliłby sam.
Ustawienia: ręce precz od gałek
Gdy zadanie jest już ustawione, kusi dłubanie w ustawieniach, żeby działało lepiej. W większości przypadków wychodzi na odwrót. Wiele opcji, które kiedyś wszyscy zmieniali, ma dziś domyślne wartości lepsze niż nasze pomysły. Model: Anthropic zaleca start od Opusa 5.5 — i to już jest domyślne na planach płatnych. Wysiłek: większość podkręca, bo „więcej” brzmi jak „lepiej”, a Opus 5.5 na średnim daje wyniki równe lub lepsze niż Opus 5 na wysokim i maksymalnym. Są też niuanse, których nie widać gołym okiem: dokumentacja przyznaje, że model ma skłonność do przesadnego kombinowania, więc dołożenie tokenów czy wysiłku niekoniecznie poprawia wynik. Uprawnienia: tryb automatyczny jest domyślny od sierpnia, a każdy ruch zamiast ciebie sprawdza klasyfikator. Nawet moment skracania historii rozmowy jest dziś strojony pod konkretny model — dlatego przy zmianie modelu kompresja przychodzi wcześniej albo później. Moja rada: zostaw ustawienia w spokoju, dopóki coś realnie nie pójdzie źle. Te domyślne są tam z powodu, a jego autorzy wiedzą o tych modelach więcej niż my.
Podagent albo rozgałęzienie
Jednym z domyślnych mechanizmów jest sposób, w jaki Claude dzieli robotę, gdy zadanie rośnie. Może to robić na dwa sposoby, zachowujące się zupełnie różnie — warto rozumieć oba.
Podagent startuje od zera: dostaje własne instrukcje plus to, co przekaże mu Claude, a wraca wyłącznie z podsumowaniem albo wynikami. Widać to we wbudowanych agentach explore i plan, które nawet nie czytają twojego Claude.md — podagent nie zna domowych reguł dotyczących innych plików. Robi się to po to, żeby utrzymać czystość głównej rozmowy. Przykład: chcę odpalić skrypt generujący obraz, wołający model OpenAI. Claude zleci to podagentowi i dostanie z powrotem sam obraz — bez wnętrza kodu i promptów do OpenAI. Głównemu kontekstowi niepotrzebne są te podzespoły; wystarczy mu wynik, który wykorzysta wobec celu albo definicji „gotowe”.
Fork to co innego: kopia twojej rozmowy. Wie wszystko, co dotąd padło, i współdzieli buforowaną kopię, więc jej pierwsza tura jest tańsza. Mało kto wie, że tryb rozgałęzień jest domyślnie włączony od sierpnia — Claude sam wybiera między forkiem a podagentem zależnie od zadania i polecam zostawić mu ten wybór. Jeśli jednak zadanie poboczne potrzebuje całej historii rozmowy, możesz wymusić rozgałęzienie ręcznie poleceniem subtask.
Ultra code: dziesiątki agentów w tle
Dwa pomocnicy naraz wystarczą przy drobnych robotach, ale niektóre zadania — choćby porządne poszukiwania informacji — wymagają dziesiątek pracowników, czyli uporządkowanego procesu. Claude potrafi dziś napisać na zamówienie cały workflow: to tzw. ultra code, inaczej dynamiczne workflow. To skrypt, który w tle uruchamia dziesiątki agentów i zestawia ich ustalenia między sobą, zanim cokolwiek trafi do ciebie.
Najłatwiej pokazać to na głębokich researchach, bo Anthropic ma dla nich osobny slash command. Wpisujesz deep research i pytanie: model szuka z kilku perspektyw, krzyżuje źródła, odrzuca twierdzenia, które się nie bronią, i oddaje ci jeden zbiorczy raport. Ciekawostka: przy każdym uruchomieniu metoda badania będzie inna, dopasowana do zadania, choć ogólnie trzyma się jednego z sześciu wzorców. Taki workflow nie startuje sam z siebie — trzeba go wywołać poleceniem typu deep research, więc używaj go tylko, gdy naprawdę masz potrzebę. A jeśli już używasz, wejdź w /config i ustaw rozmiar dynamicznego workflowa na „small” — mniej niż pięciu agentów — bo apetyt łatwo rośnie do dwudziestu, trzydziestu podagentów i to od razu zjada tokeny. Z ciekawości: napiszcie w komentarzach, do czego użyliście ultra code — ja na razie widziałem głównie research.
Hooki: od prośby do gwarancji
Do kontroli, która ma działać zawsze i bez wyjątku, służą hooki. Hook uruchamia się w ustalonym momencie za każdym razem, niezależnie od wszystkiego. Linijka w Claude.md — „nigdy nie wysyłaj maila do klienta, zawsze zostaw go jako szkic w mojej skrzynce” — to prośba, którą chcesz przenieść z poziomu „model zwykle się stosuje” na poziom gwarancji. I dokładnie to robi hook. Co się zmieniło: hook nie musi już być skryptem — może być promptem albo podagentem, więc kontrola potrafi przeczytać faktyczną pracę.
Jak to działa? Moment, w którym Claude ogłasza zakończenie, to zdarzenie stop — i do niego możesz przypiąć sprawdzenie. Gdy Claude próbuje się zatrzymać, drugi model (bo każe mu hook) ogląda pracę i odpowiada jednym z dwóch zdań: „tak, Claude może kończyć” albo „nie może, bo…”. Ten powód wraca prosto do Claude’a jako następna instrukcja i praca trwa, dopóki kontrola nie przejdzie. Są dwa rodzaje: hook-prompt, który czyta wyłącznie rozmowę — szybki i tani — oraz hook-agent, który potrafi otwierać pliki, np. dokument głosu marki i szkic raportu, ale jest jeszcze eksperymentalny. Nie musisz też niczego pisać sam: wystarczy poprosić Claude’a, żeby dodał hook na stop, czytający dokument głosu marki i najnowszy raport, a potem odsyłający ci podsumowanie, czy raport łamie reguły z dokumentu. Prośba staje się gwarancją.
Rutyny: agent budzi się na zdarzenie
Skoro kontrole działają za każdym razem i nie siedzą już w instrukcjach umiejętności, praca może biec zupełnie bez ciebie. Wchodzimy w rutyny. Rutyna uruchamia Claude’a w chmurze — laptop może być zamknięty — i istnieje od dawna, choć parę rzeczy o niej mało kto zna. Po pierwsze: może startować nie tylko wg harmonogramu, lecz od zapytania sieciowego albo zdarzenia z GitHuba, np. nowego pull requesta. Każde narzędzie, które umie wysłać żądanie HTTP, może zdecydować, że agent ma wystartować. To duży krok w stronę reaktywności: agent włącza się, gdy coś się wydarzy — czego nie potrafią zadania harmonogramowane w oknie czatu, oparte wyłącznie na czasie. Konfiguracja jest prosta: nazwa, prompt, repozytorium i wyzwalacz; jeśli jako wyzwalacz wybierzesz API, po zapisaniu dostajesz adres URL i token, a cokolwiek uderzy w ten adres, uruchamia w chmurze nowy przebieg.
Uwaga praktyczna: tworząc rutynę, dostaje ona domyślnie wszystkie konektory podpięte do twojej aplikacji. Odetnij je do niezbędnego minimum — inaczej ładujesz agentowi kontekst, którego nie potrzebuje. OpenAI szedł dokładnie tą samą drogą i robi to jeszcze wygodniej: na dev day pod koniec września zapowiedziano MCP events — podłączona aplikacja sama startuje zadanie. Mówisz ChatGPT, na co patrzeć (np. nowa wiadomość w slackowym kanale uwag) i co agent ma zrobić, gdy zdarzenie nadejdzie. Obaj giganci wyraźnie zmierzają do wyzwalaczy zdarzeniowych.
Sesje w chmurze
Nie każde zadanie da się wcisnąć w harmonogram albo wyzwalacz — i rutyny nie są już jedyną drogą pracy w chmurze. Anthropic opublikował w tym tygodniu przewodnik po sesjach chmurowych, dziś najprostszej metodzie uruchomienia dowolnego zadania Claude Code na maszynie, która nie jest twoja. Każde zadanie dostaje własną maszynę, więc możesz odpalić kilka naraz, zamknąć laptopa — i wszystko będzie dalej pracować. Startujesz z claude.ai/code, w aplikacji desktopowej wybierając chmurę zamiast pracy lokalnej albo w terminalu poleceniem claude --cloud. Najlepsze: wszystko działa w ramach zwykłego planu, bez dopłaty za maszynę. Gdy chcesz wrócić, claude --teleport ściąga całą sesję razem z historią rozmowy na twój komputer.
Limity, które potrafią poczekać
Przy zadaniach działających poza twoim komputerem jedną pułapką był limit wykorzystania: do niedawna, gdy w połowie zadania kończył się limit, Claude po prostu stawał, a po powrocie czekało cię dzieło zaczęte od połowy. Trzeba było je restartować, tracąc część kontekstu i wykonanej roboty. Dziś zadanie po prostu czeka: gdy limit się odnawia, Claude podnosi je dokładnie tam, gdzie stanął. W Claude Code działa to domyślnie. Znaczy to niestety też, że bez pytania zaczyna zużywać twój następny tokenowy budżet — ale tylko ten pięciogodzinny, nie tygodniowy, więc zadanie z tego tygodnia nie wypali ci tokenów na przyszły.
Na koniec
To piętnaście rzeczy, które radykalnie zmieniły się w ciągu ostatnich dziesięciu miesięcy — droga od pojedynczego czatu do Claude’a pracującego, gdy ciebie nie ma. Pełny kurs, który rozwija te wszystkie wątki na praktycznych przykładach, znajdziecie w Agentic Academy. Do zobaczenia w następnym materiale.