O czym jest ten film
- Matt Pocock opublikował nową umiejętność „handoff”, która sprasowuje kontekst bieżącej sesji agenta do pliku markdown — gotowego do przekazania zupełnie nowej sesji.
- Nawet milionowe okno kontekstu ma swoją „mądrą” i „głupią” strefę: realnie do wymagających zadań zostaje około 120 tysięcy tokenów.
- Wbudowany mechanizm „compact” streszcza rozmowę w obrębie jednej sesji — świetny do debugowania, ale nie rozdziela wątków.
- Główne zadanie, którego compact nie załatwia: w trakcie sesji pojawia się wątek poboczny (np. okazja do refaktoryzacji), którego nie chcesz ani doklejać, ani kasować.
- Handoff pozwala odciąć taki wątek, przekazać go niezależnej sesji i zachować czysty kontekst w tej bieżącej.
- Pierwszy przykład: sesja planistyczna dla Sandcastle, w której przekazanie zadania od razu porządkuje pytania planisty i tworzy dokument dla agenta zakładającego issue na GitHubie.
- Drugi wzorzec: „grilling → prototyp → powrót do planowania”. Sesja prototypowa pochłonęła 169 tysięcy tokenów i wróciła do planisty jako dokument z wnioskami — na wzór sub-agenta zrobionego własnymi rękami.
- Ponieważ nośnikiem jest zwykły markdown, dokumenty można przenosić między różnymi narzędziami: Claude Code, Codex, Copilot CLI — np. po to, by urządzić przegląd kontradyktoryjny.
- Plik skilla zawiera pięć zasad: sekcja sugerowanych umiejętności, zakaz powielania treści z innych artefaktów, zapis w katalogu tymczasowym, redagowanie sekretów i danych osobowych, dopasowanie dokumentu do celu następnej sesji.
- Na końcu promocja kursu „AI coding for real engineers” (start 1 czerwca) oraz zapowiedź ewentualnego materiału o książkach z półki autora.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Realny budżet „sprytu” to około 120 tysięcy tokenów
Na czym polega: Nawet jeśli narzędzie deklaruje okno kontekstu rzędu miliona tokenów, jakość odpowiedzi spada znacznie wcześniej — mechanizm uwagi modelu rozprasza się, gdy materiału jest zbyt dużo. Matt czuje wyraźny spadek już koło 120 tysięcy tokenów.
Jak stosować: Traktuj kontekst jak ograniczony zasób. Nowy wątek — nowa sesja. Kończ sesję zanim przekroczysz „bezpieczny” próg, zamiast dowozić kolejne zadania do tej samej rozmowy.
Na co uważać: Przekroczenie budżetu nie wywoła błędu — dostaniesz po prostu gorsze, mniej uważne odpowiedzi, a to łatwo przeoczyć.
2.Compact służy do przedłużania jednej sesji, nie do zarządzania wieloma wątkami
Na czym polega: Compact streszcza rozmowę i przenosi cię z powrotem do „mądrej strefy”, ale w obrębie tego samego wątku pracy. Sprawdza się, gdy godzinami wałkujesz jeden problem — klasycznie przy debugowaniu.
Jak stosować: Przy szukaniu usterki: wypróbuj warianty, skompaktuj to, co już próbowane, testuj dalej, znów skompaktuj. Tak zapisujesz stan poszukiwań.
Na co uważać: Każde kompaktowanie odkłada kolejną warstwę streszczenia — osad z dawnych rozmów, który sam zjada kontekst i potrafi zaciemniać obraz.
3.Wątek poboczny odetnij, zamiast go dolewać
Na czym polega: Gdy w trakcie pracy zauważysz coś wartego zrobienia (np. drobny refaktoring), masz dwie złe drogi: rozbudować sesję o kolejny temat albo skompaktować i utracić dorobek. Trzecia droga to przekazanie: dokument handoff opisujący wyłącznie ten wycinek.
Jak stosować: Powiedz agentowi, by napisał dokument przekazania dla tego jednego zadania, i podaj go świeżej sesji. Bieżąca rozmowa zostaje nietknięta.
Na co uważać: Rozbudowa sesji rozcieńcza kontekst — możesz nie skończyć nawet pierwotnego celu.
4.Cel następnej sesji to obowiązkowy element dokumentu
Na czym polega: Bez informacji, po co powstaje kolejna sesja i na czym ma się skupić, agent napisze ogólnikowe streszczenie bez wartości.
Jak stosować: Przy każdym przekazaniu podawaj powód i zakres nowej sesji. Jeśli używasz dyktowania głosowego, takie zdanie nagadasz w kilka sekund.
Na co uważać: Argumenty podane przy wywołaniu skilla powinny trafić do dokumentu i ukształtować jego treść — inaczej tracą sens.
5.Z dwóch sesji zrób sobie sub-agenta
Na czym polega: Układ „rodzic → dziecko → rodzic”: sesja planistyczna przekazuje temat do sesji prototypowej, ta zużywa pełne okno kontekstu na jedno zadanie, a potem odsyła sprasowane wnioski z powrotem do planisty.
Jak stosować: Prototyp rób na osobnej gałęzi. Po zakończeniu poproć o dokument przekazania zawierający wyłącznie wnioski — zwłaszcza te, których nie widać bezpośrednio w kodzie lub które nie są oczywiste.
Na co uważać: Nie kopiuj do dokumentu całego prototypu. Ma on być wnioskiem, nie raportem.
6.Markdown to wspólny język różnych narzędzi
Na czym polega: Dokument przekazania nie jest powiązany z żadnym natywnym mechanizmem jednego agenta. Sesję możesz zacząć w Claude Code, a pracę oddać Codexowi albo Copilot CLI.
Jak stosować: Chcesz kontradyktoryjnego przeglądu swojego planu lub kodu — przekaż dokument innemu agentowi i porównaj spostrzeżenia.
Na co uważać: Różne narzędzia mają różne umiejętności i przyzwyczajenia — dokument musi być na tyle samowystarczalny, by działał bez kontekstu „swojego” ekosystemu.
7.W dokumencie wskazuj sugerowane umiejętności
Na czym polega: Skille nadają sesji charakter — determinują, jak agent podejdzie do zadania. Sekcja sugerowanych umiejętności sprawia, że nowa sesja sama przywoła właściwe narzędzia.
Jak stosować: W dokumencie przekazania zamieść listę skillów, które ma użyć odbiorca (np. „grill with docs”, „diagnose”, „prototype”). Wklejasz plik i zaczynasz pracę.
Na co uważać: Nazwy muszą istnieć po stronie odbiorcy — przenosząc dokument do innego narzędzia, sprawdź, czy tamtejsze skille nie nazywają się inaczej.
8.Wskazuj, nie powielaj
Na czym polega: Dokumenty przekazania łatwo puchną, przepisując treść, która już leży w issue, plikach projektu czy innych dokumentach markdown.
Jak stosować: Zamiast kopiować — wstaw ścieżkę, link, numer issue. Dokument ma zawierać wyłącznie to, czego nigdzie indziej nie ma.
Na co uważać: Rozdęty dokument sam zużywa cenny kontekst kolejnej sesji i zaciemnia, co naprawdę istotne.
9.Pliki handoff są jednorazowe
Na czym polega: Dokument przekazania to narzędzie robocze, nie dokumentacja. Nie ma czego szukać w repozytorium po skończonej pracy.
Jak stosować: Zapisuj je w katalogu tymczasowym systemu operacyjnego — tam znikną same, nie zaśmiecając projektu.
Na co uważać: Pliki porzucone w repo zaczynają żyć własnym życiem: ktoś je kiedyś uzna za aktualną dokumentację.
10.Redaguj sekrety przed zapisem
Na czym polega: Dokument streścijący rozmowę z agentem może przechwycić klucze API, hasła czy dane osobowe, które przewinęły się w sesji.
Jak stosować: Wpisz do skilla (i sprawdź w praktyce), że dokument przed zapisem ma zostać oczyszczony z danych wrażliwych.
Na co uważać: Pliki markdown łatwo trafiają do commitów, zrzutów ekranu czy udostępnień — wyciek z nich rozprzestrzenia się bez oporu.
Redakcyjne tłumaczenie
Skąd wziął się pomysł
Kilka tygodni temu zauważyłem u siebie nawyk, który uznałem za sprytny, ale zbyt prosty, żeby robić z niego osobną umiejętność. Trochę kontekstu: nieustannie myślę o skillach — o tym, jak pakować moje instynkty i praktyki programistyczne w elementy wielokrotnego użytku. Efekt jest taki, że repozytorium moich skillów ma w chwili nagrywania prawie sto tysięcy gwiazdek.
(Informacja dodatkowa: „skill” w środowisku agentów kodujących to spakowany zestaw instrukcji i dobrych praktyk, które agent przywołuje na żądanie — coś jak rozdział podręcznika czytanego przez model w razie potrzeby.)
Umiejętność, o której wtedy pomyślałem, to handoff — po polsku po prostu „przekazanie”. Założenie: skill bierze okno kontekstu bieżącej sesji i sprasowuje je do pliku markdown, który można przekazać innej sesji. Dwa tygodnie temu go opublikowałem; leży w repozytorium skillów, w kategorii productivity. To bardzo prosta rzecz: „Napisz dokument przekazania streszczający bieżącą rozmowę tak, aby świeży agent mógł kontynuować pracę. Zapisz go w katalogu tymczasowym systemu operacyjnego użytkownika, a nie w bieżącym projekcie”. Wrzuciłem to do folderu ze skillami na próbę, żeby zobaczyć, jak często będę po to sięgał. Okazało się, że bardzo często.
W tym materiale pokażę skilla od podszewki: dlaczego zaprojektowałem go w ten sposób, po co istnieje, czym różni się od wbudowanych mechanizmów takich narzędzi, jakim jest compact, a także jak wycisnąć z niego najwięcej podczas sesji przesłuchania (grilling). A jeśli podoba ci się to, co pokazuję, powinien ci przypaść do gustu także mój kurs „AI coding for real engineers” — dwutygodniowa kohorta dla ludzi, którzy chcą używać narzędzi AI do wypuszczania porządnego kodu, a nie papki. Start 1 czerwca, obowiązuje zniżka — link znajdziesz w opisie.
Mądra i głupia strefa okna kontekstu
Zacznijmy od tego, dlaczego skill powstał i czym różni się od compact — być może to pojęcie już ci się obiło o uszy. Podczas sesji kodowania rozmawiamy z agentem, on odpytuje narzędzia, edytuje pliki — i każda taka czynność dorzuca kolejne tokeny do okna kontekstu.
Ja pracuję w Claude Code, gdzie okno ma milion tokenów. Ale w tych oknach istnieje mądra strefa i głupia strefa (oryg. smart zone i dumb zone). Na początku, gdy tokenów jest niewiele, agent działa wyraźnie lepiej: mechanizmowi uwagi nie trzeba przeliczać mnóstwa powiązań, więc jego „spojrzenie” nie rozprasza się na cały materiał. Mówiąc krótko — im mniej treści, tym łatwiej modelowi się skupić. W miarę jak rozmowa się rozkręca, odpowiedzi robią się coraz mniej rozgarnięte, w teorii aż do około 800 tysięcy tokenów. Ja nigdy tam nie trafiłem, bo już koło 120 tysięcy mam wrażenie, że siedzę po uszy w głupiej strefie.
Wniosek praktyczny: choć Anthropic chwali się ogromnym oknem kontekstu, do naprawdę wymagających zadań mamy do dyspozycji jakieś 120 tysięcy tokenów. Trzeba więc gospodarować nimi oszczędnie i cały czas wiedzieć, ile kontekstu jeszcze zostało.
Compact — streszczenie w obrębie jednej sesji
Co zatem robić, gdy zaczynamy wchodzić w głupią strefę? Jak uratować rozmowę i ciągnąć ją dalej, nie tracąc sprytu? Na to właśnie jest compact. Bierze długą sesję i streszcza ją, więc przenosisz się niemal znad granicy głupoty z powrotem do mądrej strefy. Zależnie od narzędzia i ustawień działa też automatyczny compact: gdy zbliżasz się do końca okna, głęboko w głupiej strefie, system sam streszcza rozmowę i przechodzi do nowej sesji.
Takie streszczenie zwykle zawiera listę plików, do których się odwoływano, rzeczy, które powiedziałeś, oraz ogólny ton rozmowy. Ląduje jako mały pakunecik na początku nowej sesji, a późniejszy kontekst nieustannie się do niego odnosi. Kolejne kompaktowanie odkłada warstwę na warstwie — swoisty osad z poprzednich rozmów. Bywa to nieefektywne, ale sprawdza się, gdy chcesz godzinami wałkować jeden problem. Ja szczególnie cenię ten mechanizm przy debugowaniu: kompaktujesz wszystkie warianty, które już próbowałeś, testujesz kolejne, uderzasz w barierę, kompaktujesz znowu — i właśnie w ten sposób zapisujesz stan gry. To sposób na długą pracę, ale wciąż jedną sesję.
Kiedy compact przestaje wystarczać
Compact nadal uważam za znakomite narzędzie do prowadzenia jednej, długiej sesji. Zauważyłem jednak, że chcę czegoś więcej — chciałbym kompaktować do innej sesji. Przykład: pracuję nad jednym zadaniem i po drodze dostrzegam okazję do drobnego refaktoringu. Coś całkiem poza zakresem tego, co robię, ale wiem, że prędzej czy później trzeba się tym zająć. Jakie mam wyjścia? Mogę rozbudować bieżącą sesję, ale dostanę rozcieńczony kontekst: pół etapu nad jednym, pół nad drugim — i na pewno wyląduję w głupiej strefie, więc pewnie nie skończę nawet pierwotnego celu. Mogę też skompaktować, ale wtedy roztrwonę cały dorobek bieżącej sesji.
A ja chciałem po prostu powiedzieć: „To drugie zadanie dokończę osobno, a bieżącą rozmowę zostawiam czystą”. Chciałem wyciąć z kontekstu wyłącznie ten wycinek, który dotyczył dodatkowej poprawki, przekazać go dalej i pozwolić obu sesjom działać niezależnie. Przez pewien czas robiłem to ręcznie: „Weź to, co mamy w bieżącej sesji. Chcę naprawić ten konkretny błąd. Napisz mi dokument handoff.md, który przekażę innemu agentowi”. Robiłem to tak cholernie często, że w końcu uznałem: to musi być skill.
Handoff podczas sesji przesłuchania
Najczęściej sięgam po handoffa w trakcie grillingu — sesji, w których agent „przesłuchuje” mnie pytaniami planistycznymi.
(Informacja dodatkowa: „grill me” i „grill with docs” to autorskie skille Pococka — agent zadaje użytkownikowi serię pytań doprecyzowujących, zanim w ogóle ruszy z pisaniem kodu.)
Na ekranie widzicie taką sesję dla Sandcastle, mojego rodzaju fabryki oprogramowania — planowałem tam przyszłe funkcje. Jestem dopiero przy drugim pytaniu, więc to krótka rozmowa, i mówię: „Myślę, że w przyszłości iteracje i sygnał ukończenia powinny trafić na osobne API. Właściwie… oddelegujmy to zadanie do osobnego agenta”. Zwróć uwagę, że definiując przekazanie, podaję powód, dla którego oddaję temat, i dokładnie to, co ma się znaleźć w dokumencie.
Zysk jest dwojaki. Po pierwsze, porządkuje to samą bieżącą sesję planistyczną: skoro mówię, że coś jest poza zakresem i obejrzymy to gdzie indziej, drugie pytanie po prostu znika z listy. Po drugie, powstaje plik markdown z zakresem następnej sesji: załóż issue na GitHubie, a docelowo zaprojektuj wydzielenie iteracji i sygnału ukończenia na osobne API. Później podaję ten plik innemu agentowi, który tworzy zgłoszenie. Proste.
Wzorzec: grilling → prototyp → powrót do planowania
Drugi układ, który gorąco polecam, to przekazanie pracy do prototypu w trakcie przesłuchania. Gdy agent zasypuje cię pytaniami, szybko zauważysz, że są dwóch rodzajów. Są niewiadome, o które może cię po prostu zapytać — i są rzeczy, które musisz zobaczyć w kodzie, w działającym prototypie. Dotyczy to zwłaszcza interfejsów użytkownika i złożonej logiki, której jeszcze dobrze nie ogarniasz.
W jednej z moich sesji, przy pytaniu trzynastym, agent dał wstępne rozstrzygnięcie, a ja poprosiłem: „Przekaż do prototypu trudne fragmenty — komunikację między oknami i integrację z tldraw”. Powstał dokument przekazania, a ja zaimplementowałem prototyp na osobnej gałęzi.
(Informacja dodatkowa: tldraw to biblioteka open source do budowania interaktywnych płócien rysunkowych w przeglądarce.)
Ta sesja prototypowa rozrosła się do 169 tysięcy tokenów — znacznie ponad to, co zmieściłoby się w sesji planistycznej. Zbudowałem w niej makietę interfejsu i interakcji, które chciałem zobaczyć, a potem powiedziałem: „Przekaż to z powrotem do sesji, z której to wyszło. Zbierz wszystkie wnioski z prototypu — zwłaszcza te, których nie widać bezpośrednio w kodzie albo które nie są oczywiste — i daj mi dokument handoff do oddania planiście”.
To bardzo częsty u mnie układ: sesja początkowa wykonuje kawał pracy, oddaje go innej sesji, tamta odhacza swoje, tworzy własny dokument przekazania i odsyła go do pierwotnej rozmowy. To niemal sub-agent sklejony własnymi rękami: wykorzystujesz całe okno kontekstu na jedno konkretne zadanie, sprasowujesz wnioski i oddajesz je rodzicowi. Potem mogłem dokończyć przesłuchanie i przygotować porządne dokumenty wymagań (PRD) oraz issue z wplecionym prototypem. Bardzo bogaty wzorzec — zwłaszcza gdy chcesz wycisnąć maksimum z agentów pracujących samodzielnie, bez twojego nadzoru.
Markdown jako wspólny język narzędzi
Warto podkreślić: dzięki temu, że nośnikiem jest zwykły dokument markdown, nie jesteśmy skuci do natywnych mechanizmów jednego agenta. Pierwsza sesja może biec w Claude Code, a dokument podajesz czym innym — Codexowi, Copilot CLI, czemukolwiek używasz. Jeśli więc chcesz urządzić przegląd kontradyktoryjny albo jakąkolwiek współpracę między różnymi agentami kodującymi, to najprostsza możliwa droga.
Zasady zapisane w pliku skilla
Przejrzyjmy też końcowe zapisy samego skilla, żeby zrozumieć decyzje projektowe.
Sekcja sugerowanych umiejętności. Dokument ma zawierać podpowiedź, jakie skille agent powinien przywołać. Dodałem to, bo skille nadają u mnie sesji charakter: wklejasz dokument do nowej rozmowy, ona sama przywołuje potrzebne narzędzia — grill with docs, diagnose, prototype — i możesz zaczynać. Nie musisz głowić się, czego użyć dalej.
Zakaz powielania treści. Zauważyłem, że dokumenty przekazania robiły się ogromne i przepisywały to, co już leżało w innych plikach markdown albo w zasobach typu issue. Lepiej podać wskaźnik — link, ścieżkę — niż kopiować wszystko.
Katalog tymczasowy systemu. Pliki handoff są jednorazowe. Nie powinny leżakować i gnić w dokumentacji repozytorium.
Redagowanie danych wrażliwych. Klucze API, hasła, dane osobowe — to trzeba usunąć. Sekrety nie mogą krążyć w plikach markdown porozrzucanych po losowych miejscach.
Argumenty jako opis celu. Jeśli użytkownik podał argumenty — czyli do czego ma służyć następna sesja — traktuj je jako opis jej zakresu i dopasuj do tego dokument. To moim zdaniem warunek dobrego przekazania: nie wyobrażam sobie, jak napisać sensowny dokument bez wiedzy, na czym skupi się kolejna sesja. Ja za każdym razem opisuję cel, a że sporo dyktuję na głos, idzie to błyskawicznie.
Na koniec
To by był handoff — umiejętność niezbędna w moim zestawie, która, jak zresztą wiele innych, jeszcze kilka tygodni temu w ogóle nie istniała. Jeśli podobają ci się moje skille, zajrzyj na kurs kohortowy — poprzednio przeszło przez niego około 2500 osób i tym razem też spodziewam się tłumu. Poza tym dziękuję za obejrzenie. Za mną regał wypełnia się nowymi książkami o programowaniu, które zamierzam przerobić w najbliższych tygodniach — może nagram coś w stylu „co stoi na mojej półce”. Jeśli chcesz takiego materiału, daj znać lajkiem albo komentarzem. Dzięki i do zobaczenia wkrótce.