O czym jest ten film
- Harness znaczy więcej niż model. Cała maszyneria wokół „mózgu” — narzędzia, uprawnienia, skrypty — decyduje o efektach; spory „Claude czy Codex” dotyczą wyłącznie mózgu.
- Model bez opakowania nie ma kończyn. Demonstracja w LM Studio: model lokalny napisze HTML, ale nie uruchomi serwera; Claude Code i Codex mają to od razu.
- Czat w przeglądarce kontra harness. Różnica między Claude w przeglądarce a Claude Code to dostępny zestaw narzędzi; rozmówcy przewidują, że zwykłe czaty „wyparują” na rzecz lżejszych wersji harnessów (Cowork).
- Lojalność wobec własnych zasobów, nie dostawcy. Umiejętności, reguły i pliki kontekstu trzymaj niezależnie od modelu — mózg wymienia się bez sentymentów, a przenosiny na inny model to kwestia doby.
- Chirurg kontra artysta. Codex sprawdza się w precyzyjnej realizacji i weryfikacji, Claude Code w ideacji i planowaniu; zderzanie ich planów w pętli domyka luki.
- Własny harness z odzysku. Rozmowy z Claude Code i Codexem zostawiają na dysku pliki JSONL z metadanymi wywołań — można z nich odtworzyć sprawdzone zachowania (projekt pi.dev).
- Umiejętności jak scyzoryk. Pliki umiejętności da się pisać tak, by działały w każdym narzędziu (YAML, słowa wyzwalające, /polyskill), a cały ekosystem audytować co miesiąc automatycznie.
- rot.md, czyli różne tempa rozkładu. Tożsamość starzeje się wolno, reguły tygodniami, umiejętności najszybciej — Boris Cherny radzi kasować wszystkie umiejętności co pół roku.
- Modele wyrastają z umiejętności. Przyszłość to mniej instrukcji krok po kroku, ostrzejsze reguły i wiedza milcząca; Anthropic samo zachęca do „dawania modelom ambitniejszych zadań”.
- Segmentacja i awans do globalu. Osobne systemy dla każdej dziedziny, wszystko domyślnie projektowe — mały promień rażenia pozwala szybko ustalić, czy winny jest model, harness czy organizacja plików.
Redakcyjne tłumaczenie
(Informacja dodatkowa: nazwisko gościa jest zniekształcone w automatycznej transkrypcji — w tekście występuje jako Mark. Rozmowa nagrana na żywo podczas wydarzenia AI w Czarnogórze.)
Zapowiedź rozmowy
Nate Herk: Marku, czego się dziś wszyscy od ciebie nauczą?
Mark: Chcę, żeby po tym nagraniu każdy rozumiał, że harness modelu znaczy o wiele więcej niż sam model. (Informacja dodatkowa: harness — w świecie agentów AI to całe opakowanie wokół modelu: narzędzia, uprawnienia, skrypty i reguły, dzięki którym „mózg” może działać na twoim komputerze i w chmurze.)
Nate Herk: Mam takie skojarzenie: Claude Code to mądra, stara sowa, z którą się rozmawia i planuje, a która czasem podważy twój pomysł. A Codex to rotwajler: chwyta zadanie, wykonuje polecenia i nie puszcza, dopóki nie skończy.
Mark: Bo ilekroć toczy się spór, czy lepszy jest Claude, czy Codex, spieramy się o mózg — a o to, czy całość realnie tyka, decyduje wszystko, co ten mózg otacza. To wcale nie jest magia. Za kulisami pracuje cała fabryka, dzięki której model wygląda na znacznie mądrzejszy, niż jest. Moja zasada numer jeden: nie jestem lojalny wobec dostawcy. Jestem lojalny wobec własnego harnessu i własnych zasobów, a mózg wymieniam, kiedy chcę.
Nate Herk: To ważne, żeby mieć świadomość, że budujemy własną własność intelektualną — i trzeba jej bronić. Zawsze przypominam sobie zdanie: myślenie możesz zlecić, zrozumienia — nigdy.
Mark: Umiejętności i agenci gniją przy tym niewiarygodnie szybko. Boris Cherny napisał kiedyś na X, że co sześć miesięcy należy skasować wszystkie swoje umiejętności. Wszystkie, do jednej. (Informacja dodatkowa: Boris Cherny — inżynier związany z rozwojem Claude Code, później z Codexem.)
Nate Herk: Serio? I wiesz dlaczego?
Mózg w słoju: od czego naprawdę zależy agent
Nate Herk: Mark, dzięki, że doszedłeś do nagrania na żywo — jesteśmy w pięknej Czarnogórze, gdzie świetnie się bawimy. Przyjechaliśmy na wydarzenie AI i pomyśleliśmy: czemu by nie usiąść razem i nie podzielić się konkretami. Jeśli nie znacie Marka, mam nadzieję, że po tym filmie jego materiały zaczną wam wpadać w rekomendacje, bo to czyste złoto — sam oglądałem go, nim zacząłem nagrywać. W społeczności padają tłumy pytań: przechodzić już na Hermes? Pokazuje się ta lokalna rzecz zwana pi? Narzędzi przybywa, a wszystkim zależy, żeby to, co budujemy, było aktualne także za rok i za dwa — bo nie wiadomo, co dalej z Claude Code czy Codexem. Zaczynajmy.
Mark: Zacznijmy od tego schematu — a konkretnie od mózgu w słoju. Bo ilekroć pada argument „Claude jest lepszy”, „Codex jest lepszy”, „może kiedyś Gemini będzie lepszy”, chodzi o mózg. Tymczasem o to, czy całość działa, decyduje wszystko, co go otacza. Spójrzmy na elementy: możliwość czytania plików; możliwość pisania i edytowania; dostęp do basha, który w praktyce przejmuje kontrolę nad twoim komputerem — zakłada foldery, przenosi je i tak dalej. Nic z tego nie jest wbudowane w sam model. Widzisz to, gdy poprosisz model lokalny: „zrób mi stronę i postaw ją na moim komputerze”. Pierwszą część zrobi, drugiej — nie.
Nate Herk: Bo to mózg, który umie wygenerować HTML, ale nie umie uruchomić lokalnego serwera. Nie ma kończyn.
Mark: Im częściej myślisz o modelu jak o mózgu, któremu otoczenie daje ręce i nogi, tym wyraźniej rozdzielasz, co jest zasługą mózgu, a co jego otoczki — i tym łatwiej wzbogacać otoczkę tak, żeby mniej zależeć od jednego, konkretnego mózgu. Jesteśmy zresztą w punkcie, w którym sporo modeli lokalnych — Kimi albo dowolny inny open source — ogarnia jakieś 80% codziennej roboty. Siły ognia jak w Claude Code czy Codexie nie dostaniesz, ale w coraz większej liczbie ról, zwłaszcza od przyszłego roku, widzę świat, w którym 70–80% pracy kręcisz lokalnie — o ile masz sprzęt — a „geniuszy” wzywasz do zadań klasy geniusza, na przykład do planowania.
Nate Herk: Bardzo lubię ten wątek, bo gdy porównujemy Claude w przeglądarce z Claude Code, między nimi jest przepaść. I szczerze: szkoda, że nazwali to „Claude Code”.
Mark: No właśnie.
Nate Herk: Bo „code” to właśnie wszystkie te narzędzia, o których mówiłeś. Przejdźmy przez praktyczny przykład: na czym polega różnica, gdy proszę Claude w czacie, żeby coś zbadał i przygotował PDF, a gdy dokładnie to samo zlecam Claude Code?
Mark: Claude w przeglądarce ma po prostu inny zestaw narzędzi. Research zrobi, PDF wygeneruje, ale pośrednie kroki — odwołanie do dodatkowych platform, przeniesienie plików na twoim komputerze — mogą wyjść poza jego możliwości, bo często nie ma dostępu do lokalnych plików. Musiałby w tle zakładać rzeczy, których nie widzi i których nie dotknie. Claude Code jako harness dogaduje się i z twoim komputerem, i z chmurą — masz wszystko w jednym. Pierwszy system opowie ci hipotetycznie, co dałoby się zrobić — i coraz większą część naprawdę zrobi. Widzę świat, w którym czat z Claude’em zupełnie wyparuje i zostanie tylko Cowork, czyli lżejsza wersja harnessu Claude Code. Każde narzędzie, z którym będziemy pracować, będzie miało jakieś opakowanie — pytanie tylko, na ile sprawne w zadaniu, którego akurat potrzebujesz.
Nate Herk: A co jest w tym piękne — pamiętam, jak w styczniu zacząłem się tego uczyć i jak bardzo mnie to onieśmielało. Wystarczyło zacząć zadawać pytania, a poczułem się, jakby zadziałała magia: rozmawiasz z tym samym modelem, który dobrze znasz, a cała reszta dzieje się sama. Opakowanie jest bowiem tak zbudowane, że zna listę swoich narzędzi — jak na tym schemacie, zresztą świetnie zrobionym. Trochę jak sięgnięcie po szklankę wody: ręka i bark współpracują, żeby ją podnieść, a ty się nad tym nie zastanawiasz. Więc choć z zewnątrz wygląda, że musisz znać basha czy szczegóły czytania plików — model załatwia to za ciebie.
Mark: Dokładnie. To wszystko dostajesz z pudełka — o to chodzi w harnessie Claude Code, to uczyniło go świetnym: read, edit i cała reszta działa od razu. Są narzędzia typu pi, bardzo surowa, otwarta wersja, w której budujesz własne opakowanie. To jest fajne, ale ty — i twój kanał — wnosicie wartość gdzie indziej: co jeszcze można dorzucić do tej fabryki? I wtedy pojawiają się modułowe klocki: umiejętności (skill — plik-instrukcja, który agent ładuje, gdy rozpozna odpowiednie zadanie), wtyczki, kolejne warstwy. Powstaje ekosystem — orkiestra, w której mózg pośrodku przekazuje reszcie cel. A w zależności od inteligencji model lepiej lub gorzej orientuje się, że „do tego potrzebuję basha z zapisem pliku i przejdę przez pętlę agentową”. Ta pętla jest w gruncie rzeczy prosta: składasz zadanie, ono zostaje wykonane, wraca wynik — błąd albo sukces — i model bierze ten bodziec i kręci dalej. Jego zdolność do pozostania w tej pętli zależy w pełni od wyrafinowania opakowania. Lepszy model użyje narzędzi lepiej. Trochę jak ze złotą rączką: jeden ledwie skończył roczną praktykę, drugi ma lata blizn, porządny sprzęt i wyczucie, kiedy po co sięgnąć. Obaj są sprytni — ale ten drugi odrobi to nieporównanie sprawniej. Tak samo tu: sam model jest świetny, ale to doświadczenie wokół niego robi różnicę.
Demonstracja w LM Studio: mózg bez kończyn
Nate Herk: Przejdźmy do LM Studio? Czym właściwie jest LM Studio dla kogoś, kto nigdy z niego nie korzystał?
Mark: Wyobraź sobie, że możesz odpalić ChatGPT, tylko z otwartym modelem. Domyślnie nie ma tu harnessu — rozmawiasz wprost z mózgiem. I właśnie dlatego pięknie zobaczysz, o co chodzi. Używam Qwena 27B — mam mocniejsze modele, ale nie chcę, żeby komputer padł mi w trakcie nagrania.
Prompt: „Zrób bardzo prostą stronę landing dla mojej firmy doradczej AI. Nazwij ją Prompt Advisors, postaw lokalnie na moim komputerze, żebym mógł ją hostować i pokazać całej widowni”. I nieistotne, ile to potrwa — usłyszę, że nie umie jej postawić. Dlaczego? Nie ma kończyny, która by sięgnęła do mojego komputera i utworzyła serwer.
Dokładnie to samo zlecenie dla Codexa albo Claude Code nie wywoła nawet zdziwienia — mają to z pudełka. Tutaj powstanie sam HTML, bo model umie tylko przyjąć tekst i oddać tekst. Wyobraź sobie mózg w słoju: dostaje bodźce i odsyła sygnał — swoje przypuszczenie, jaka jest odpowiedź. Ten sam schemat. Więc jeden teoretycznie potrafi zrobić rzecz…
Nate Herk: …ale nie przeprowadzi jej od startu do mety.
Mark: I cały sens harnessu sprowadza się do pytania: jak przejść od tego, co napisał bardzo inteligentny model, do namacalnego efektu w twoich rękach.
Nate Herk: Zupełnie. Przypominam sobie historie z czasów, gdy Claude dopiero się pojawiał, jeszcze przed harnessami: firmy budowały produkty tak, że Claude pisał kod, a ludzie ręcznie kopiowali go i wklejali tam, gdzie trzeba było coś zbudować i uruchomić. To kolejny przykład tej samej prawidłowości: samo w sobie bardzo potężne — ale nie tak potężne, jak gdy odda się modelowi całą pętlę agentową.
Przerwa sponsorska: Clay
Nate Herk: Krótka przerwa i podziękowania dla Clay, sponsora tej części nagrania. Jedno z najczęstszych pytań, jakie dostaję, brzmi: gdzie szukać osób do zimnego kontaktu i jak dowiedzieć się o nich dość, żeby wysłać coś, co odbiorca w ogóle otworzy. Goła lista nazwisk nie podpowie, czy ktoś w ogóle decyduje, jak się do niego dotrzeć ani co go naprawdę obchodzi. Clay to platforma do wzbogacania i orkiestracji danych: ponad 250 dostawców danych i narzędzi badawczych AI w jednym miejscu. Zamiast każeć agentowi wygrzebywać z sieci, co się da, analizujesz całą listę naraz i wyciągasz właściwą osobę do kontaktu, jej służbowy e-mail i wielkość firmy. Jeśli jeden dostawca nie zwróci wyniku, Clay przechodzi do następnego — aż coś znajdzie. Co najfajniejsze: zbudowana logika zostaje przy danych, więc te same kroki da się puścić na każdym kolejnym leadzie. Widzisz przy tym każdy etap: od którego dostawcy pochodzi każda wartość i ile kosztowała. Całość zbudujesz z poziomu Claude Code przez Clay CLI — tak robię tutaj. Wypróbujcie Clay z linku w opisie; dostaniecie 2 tysiące darmowych kredytów. Wracamy do rozmowy.
Lojalność należy się opakowaniu, nie dostawcy
Nate Herk: Mówiliśmy, jak ważne są te elementy, bo właśnie tu dokładasz własną wiedzę fachową — i dzięki temu system czuje się twój. A przy tym, budując umiejętności, pliki kontekstu i wtyczki, nie zamykasz się w jednym harnessie: przeniosą się do innych i do innych modeli. Moje pytanie: jak ty osobiście myślisz o przełączaniu się między nimi? Skoro twój Codex sięga do twojego systemu operacyjnego AI — „drugiego mózgu”, jak kto woli — a na horyzoncie są Hermes, OpenClaw i cokolwiek przyniesie przyszłość, jak wygląda u ciebie dobór narzędzia do zadania?
Mark: Jasne. Zasada numer jeden: nigdy nie być lojalnym wobec dostawcy. Lojalność należy się mojemu harnessowi i moim zasobom — mózg wymieniam wymiennie, zero sentymentów. Claude Code używam często, ale głównie z przyzwyczajenia: znam jego rytm, wiem, czego się spodziewać. Natomiast każdą umiejętność buduję tak, żeby działała z każdym modelem, otwartym czy zamkniętym, i priorytetem jest porządne przetestowanie jej na wszystkim, co się da. Sprawdzam na Claude Code, a potem puszczam umiejętność, którą nazywam /polyskill: przekształca każdą umiejętność z Claude Code i optymalizuje ją pod Codexa. W ten sposób mam pewność, że każda działa w obu, a wszystkie modele wiedzą dokładnie, gdzie szukać tych samych zasobów. Trzymam jeden link, pod którym siedzą wszystkie kluczowe zasoby — neutralne wobec modelu — i przenoszę się, kiedy chcę.
A odpowiadając wprost: w ostatnim czasie około 60% pracy kręcę na Codexie, choć przez zdecydowaną większość czasu byłem wierny Claude Code. Claude Code jest znakomity w wymyślaniu pomysłów i — do pewnego stopnia — w planowaniu. To wizjoner. Lubi pogadać, lubi ocenić twój pomysł. Ale jedna rzecz mu czasem nie wychodzi: wykonanie instrukcji dokładnie tak, jak ją dostał. Dlatego widzę Codexa jako chirurga, a Claude Code jako utalentowanego artystę. Bardzo często wzywam więc Codexa, żeby przejrzał plan Claude’a, po czym kazuję im ścierać się w pętli przez dziesięć rund — aż plan w końcu obejmie wszystkie braki, które dostrzegł Codex. Wszystko to, czego pierwszy nie przewidział.
Nate Herk: Trafiłem na tweeta, który bardzo mi się podobał, i sprawdzę, czy się ze mną zgodzisz — bo patrzymy na te dwa narzędzia bardzo podobnie. Chodziło o to, że Claude Code jest jak mądra, stara sowa: rozmawiasz z nim, planujesz, trochę ci podwazuje decyzje. A Codex jak rotwajler: chwyta zadanie, wykonuje polecenia i nie odpuszcza, dopóki nie skończy. Bo mnie w Codexie bardzo cenię ostrość pętli weryfikacyjnych. Ważne jednak, żeby pamiętać: nie ma pytania „które narzędzie jest najlepsze” — jest pytanie „które jest najlepsze do tego konkretnego zadania”. Masz proces pięcioetapowy? Do kroków jeden i dwa może bierzesz Codexa, dalej co innego. Albo odwrotnie. A gdzie ty widzisz różnicę między Hermes i OpenClaw? I gdzie w tym wszystkim Codex i Claude Code?
Mark: W Hermesie robisz jedną rzecz: przynosisisz harness Hermes i podpinasz pod niego dowolny model. I właśnie dlatego ludzie muszą tak mocno szyć swojego agenta na miarę — bo w zależności od tego, jak chcą używać modeli, muszą bez przerwy przerabiać to opakowanie. Nie chodzi o pliki umiejętności i te wszystkie dodatki md — one są świetne — ale o to, że Hermes zrobił się lepszy od OpenClaw właśnie dzięki swojemu harnessowi. W wielu zadaniach, jeden na jednego, surowy agent Hermes i Codex dadzą różne wyniki. Harness Hermes da się jednak z czasem tak urządzić, żeby wykonywał tę pętlę weryfikacyjną, którą cenisz w Codexie — zachowa się bardzo podobnie. Można to zrobić na zasadzie: zobacz i powtórz.
Coś, co zrobiłem — bez żadnych układów, to projekt otwarty: wejdź na pi.dev. Znajdziesz tam harness, który ściągniesz na komputer; skopiujesz go jedną komendą. A jeśli czujesz przed tym respekt, zrób jak ja: wrzuć ten link do Codexa albo Claude Code i powiedz: przeczytaj dokumentację, rozłącz się na paru agentów i naucz się, jak to opakowanie działa. A potem każ mu przejrzeć pliki JSONL — bo każda rozmowa, którą prowadzisz w Codexie i Claude Code, leży zapisana na twoim komputerze. Każę mu przejrzeć te zapisy: mają metadane — jakie narzędzia zostały wywołane, jakie weryfikacje wykonano i w jakiej kolejności. I wtedy mogę kazać mu działać metodą „zobacz i powtórz”: jak zacząć budować własną wersję opakowania, które przy podobnych zadaniach reaguje tak samo?
Da się tak odtworzyć wszystko, co ci się podoba w Claude Code i Codexie, przenieść do własnego harnessu — i w końcu mieć jedno opakowanie do wszystkiego, do którego podpinasz modele jak wynajmowany mózg, wymienny w razie potrzeby. I według mnie tam zmierzamy. Dziś wszystko jest plemienne: YouTube jest plemienny, X jest plemienny — „jestem z ekipy Codexa”, „jestem z ekipy Claude Code”, „jestem z ekipy open source”, „wy wszyscy to neandertalcy”. Ja jestem antyplemienny. Pytam: jak zbudować system, w którym każdy mózg, który obsłuży mnie najlepiej — z najlepszą prędkością, w najlepszej cenie, w najlepszym momencie — wchodzi do gry niemal bez adaptacji? Żeby nie bolało, gdyby jutro naprawdę „obudziło się” Gemini i okazało się świetne: spokojnie, przeniosę wszystko w ciągu doby. I kocham tę zwinność. Bo choć dziś króluje Codex, Claude Code może wrócić z atakiem — pewnie szybciej wyjdą na giełdę, zrobią mocny ruch. A jeśli wreszcie dostaniemy model, którego nie okaleczą ograniczeniami do cna — możesz zechcieć przenieść wszystko właśnie tam.
Nate Herk: I nie wiadomo, co jeszcze zmieni się w cenach dla nas, użytkowników. Dlatego tak ważne jest to myślenie: budujesz własną własność intelektualną — zadbaj, żeby była chroniona i zwrotna.
Umiejętność-scyzoryk i comiesięczny audyt
Nate Herk: Wspomniałeś, że dbasz o to, by umiejętności były niezależne od modelu, i masz do tego specjalną umiejętność, która pilnuje, żeby działały i były zoptymalizowane pod różne narzędzia. Jak wygląda ten proces? Bo zwykle plik umiejętności to markdown, czasem do tego kilka skryptów w Pythonie i jakieś zasoby — w sumie jeden główny plik. Jak zapewnić, żeby Codex go podchwycił tak samo jak inne agenty?
Mark: Kluczowa rzecz: te pliki są strukturalnie do siebie podobne. Na górze mają YAML — nazwę zapisaną kebab-case, czyli małymi literami łączonymi myślnikami — oraz opis z wyzwalaczami: „gdy użytkownik zrobi X, wywołaj tę umiejętność, żeby zrobić Y”. Więc zleciłem to maszynie: poprosiłem Codexa, żeby przejrzał całą dokumentację Claude Code, własną dokumentację i dokumentację jeszcze jednego dostawcy, a potem sprawdził, jak zbudować wielofunkcyjną umiejętność — scyzoryk — działającą u wszystkich, najlepiej jak się da. Bo Codex w umiejętnościach stawia na co innego niż Claude Code i odwrotnie — jak objąć jedno i drugie? Ze skryptami jest łatwiej: Python to Python, na szczęście jest sam w sobie uniwersalny. Natomiast sposób jego wywoływania — skąd agent wie, kiedy i jak go użyć — trzeba czasem podszlifować. Nawet /polyskill zawsze szuka drobnych rozbieżności: „Codex mógłby to przeoczyć przy takim wyzwalaczu jak w Claude Code — zróbmy opis konkretniejszym”. Żeby szansa, że każde narzędzie umiejętność wyłapie, była jak największa.
Po prostu każę AI wykonywać brudną robotę — przerabianie dokumentacji — i aktualizuję ten proces co miesiąc, automatycznie według harmonogramu. Co miesiąc robię audyt całego ekosystemu: doszlifowuję umiejętności i sprawdzam, których w ogóle nie używam. Bo mnóstwo ludzi — twoich widzów i moich — ma spuchnięte repozytoria umiejętności: pobrali „niesamowite” paczki, mają ich trzysta, wszystkie ładują się za każdym razem, a korzystają z pięciu. Audyt ustawicznie liczbę umiejętności, łączy te, które nadają się na jedną złożoną, i pilnuje, żeby wszystkie były neutralne wobec modelu.
Nate Herk: Ważne jest to, co powiedziałeś: brudną robotę wykonuje AI, ale ty trzymasz rękę na sterze i nadal rozumiesz. I zawsze przypominam sobie to zdanie: myślenie możesz zlecić, zrozumienia — nigdy. To dobra zmiana perspektywy: także my, twórcy, w sprawach, których nie znamy, korzystamy z pomocy AI, ale wciąż rozumiemy, jak podać dokumentację, żeby ją przejrzał, i wiemy, co zrobić z jego wiedzą. Powtarzam to w filmach, nawet jeśli przez to tracę zasięgi: traktujcie to jako partnera do myślenia — byle nie zlecać mu wszystkiego. Inaczej sami przestaniemy się rozwijać.
Mark: Dokładnie. I jeszcze jedno, znowu w świecie, w którym masz własny harness: możesz kazać wykonać to samo zadanie i pozwolić Claude’owi przyglądać się; puścić je w terminalu na twoim opakowaniu pi, puścić u innych dostawców, zobaczyć krok po kroku, co się wydarzyło i jaki był efekt — i stale próbować zrozumieć, odtwarzać, co u innych działa, a u ciebie nie.
Wyciek z marca 2026: fabryka za „magią”
Mark: W marcu 2026 doszło do wycieku harnessu Claude Code. Pamiętasz? To był plik markdown, który trafił do całego świata. Spędziłem nad nim cztery–pięć dni — i jestem niemal pewien, że ty też nagrałeś o tym parę filmów — przerabiając każdy jego fragment. Najciekawsze było to, że większość tego pliku wypełniały kule, którymi wsparli mózg, czyli model: miał nie obrzucać użytkownika wyzwiskami — a przekleństwa wykrywał po liście wyrażeń regularnych, na podstawie której „mózg” dostawał wskazówkę, jak reagować. Gdy zobaczyłem, ile takich kul ustawiono dla modelu rzekomo na poziomie AGI, obudziłem się: to nie jest żadna magia. Za kulisami stoi cała fabryka pracowników, dzięki którym model wygląda o wiele mądrzej, niż jest. A gdy raz to pojmiesz, wychodzisz z transu i zaczynasz zupełnie inaczej czytać benchmarki. Już nie robi na tobie wrażenia, który test model zgniótł. Robi wrażenie, jak dobrze dostawca rozwija opakowanie, żeby współgrało z mózgiem świeżo wypuszczonego modelu. Dlatego zależy mi na empirii: jak to się spisuje, gdy ja to dociskam — a nie jak mi się obiecuje, że powinno, bo model jest taki inteligentny.
rot.md — wszystko gnije, ale w innym tempie
Nate Herk: Mam pytanie, które dostaję bardzo często i które dotyczy właśnie harnessu: budowania własnego „drugiego mózgu”, systemu operacyjnego AI. Skoro co miesiąc dochodzą nowe elementy — umiejętności, wiki o modelach — jak ty pilnujesz, żeby to pozostawało „zoptymalizowane”? Cudzysłowy stawiam celowo, bo nie wierzę, że istnieje jedna optymalna droga. Raczej chodzi o wyczucie momentu, w którym system zbyt długo szuka czegoś, co powinien znaleźć od razu, albo zaczyna halucynować, bo w którymś folderze nazbierało się balastu. Wejdźmy do twojej głowy: jak utrzymujesz to w porządku i sprawnie?
Mark: Największa rzecz, jaką zrobiłem, to plik rot.md. Rot — czyli zgnilizna. System operacyjny AI ma warstwy — masz na ten temat całe kursy i obszedłeś to szeroko — zwykle pięć, sześć. Jedna to twoja tożsamość, potem podłoże, czyli rdzeń kontekstu, który nie powinien się specjalnie zmieniać. Dalej umiejętności, reguły, hooki, agenci i różne dodatki. I każda z tych warstw gnije, zużywa się w innym tempie. Kim jesteś, czym się zajmujesz, twoje cele i aspiracje — szybko się nie zmienią. Aktualizacja co jeden–trzy miesiące, w firmie może rzadziej, jeśli dane wciąż są aktualne. Umiejętności, jak mówiłem, przeglądam i doszlifowuję co miesiąc — właśnie skończyłem kolejny taki przegląd.
Nate Herk: Podoba mi się samo słowo.
Mark: A potem reguły. Reguły mogą zmieniać się codziennie. Mam takie, które zmieniają się codziennie — bo wykonując kolejne zadania na tym samym systemie, odkrywam nowe ograniczenia i przypadki brzegowe, i wtedy szukam sposobów, by szlifować i składać lepsze, bardziej złożone umiejętności. Moje reguły przegniwają w gruncie rzeczy co tydzień. Ale hooki — czyli procedury odpalane automatycznie przy określonych zdarzeniach — to co innego: gdy wypycham projekt klienta na GitHuba, chcę, żeby odpalił się hook usuwający dane osobowe i całą wrażliwą resztę, której nie chcem na swoim GitHubie. Taki hook może się nie zestarzeć przez pół roku. Trochę go poprawię, ale nie ma sensu, żeby się rozkładał szybko. Umiejętności i agenci gniją za to niewiarygodnie szybko — do tego stopnia, że Boris Cherny wrzucił wpis: co sześć miesięcy kasuj wszystkie umiejętności. Wszystkie.
Nate Herk: Serio? A dlaczego tak napisał?
Mark: Bo umiejętność to w gruncie rzeczy dodatkowa kula, którą dorzucamy systemowi, żeby mózg coś zrobił albo żeby lepiej rozumiał, jak użyć narzędzi do tego celu. A jeśli model naprawdę złapie rozpędu, może już nie potrzebować umiejętności jako skrótu mówiącego, po które narzędzia sięgnąć. Może osiągnąć cel tej umiejętności na samym ogólnym poleceniu, zamiast ogólne polecenie plus umiejętność wstrzykiwana przy każdym uruchomieniu. Dlatego musisz mieć pewność, że umiejętność realnie coś wnosi — a nie przytrzymuje smoka, który z czasem robi się tylko większy, mądrzejszy i mocniejszy. Umiejętności audytuj bardzo agresywnie, bo za trzy, za sześć miesięcy problem, pod który ją zbudowałeś, może już nie istnieć. A agenci? Agentów zatrudniasz jak pracowników. Agenta do księgowości możesz wcale nie potrzebować: gdy model będzie dość dobry, wystarczy ogólne polecenie, a on — opierając się na całej pamięci, zakładając że pamięć też się poprawi — sam wypisze te osiemnaście–dwadzieścia podzadań, które trzeba wykonać. Możemy więc dożyć świata, w którym trzymasz garść umiejętności i garść reguł, a te umiejętności to w istocie bardzo specyficzna wiedza milcząca, której model nigdy by nie miał — a nie instrukcje krok po kroku.
Nate Herk: Bardzo ciekawe. Ja zawsze dbam, żeby po premierze nowego modelu — mam teraz nowego Opusa podpiętego do Claude Code — przepuścić go przez wszystkie umiejętności i sprawdzić, czy używa ich tak samo. Ale nigdy nie wpadłem, żeby wrócić do całości i zapytać: czy my tego w ogóle potrzebujemy? I co się stanie, gdy spróbuję przeprowadzić proces bez tej umiejętności?
Mark: Właśnie. Nawiązując do twojego błyskawicznego wzrostu na YouTube: gdybym ci dwa lata temu powiedział „Nate, tak robi się film na YouTube”, taka umiejętność byłaby ci pomocna — mógłbyś się jej u mnie nauczyć, zanim wszedłem w to przed tobą. Ale dziś, gdybym wręczył ci ten sam podręcznik, spojrzałbyś na mnie, przekrzywił głowę i zapytał: „a oglądałeś nasze liczby subskrypcji?”. Tej umiejętności już nie potrzebujesz. Z niej wyrosłeś.
Nate Herk: Ciekawe — czyli im szersze dane treningowe ma model, tym większa szansa, że umiejętność stała się zbędna, przestarzała jak na jego poziom. Masz przykład umiejętności, którą udało ci się skasować, bo model ogarnia to dziś bez wysiłku?
Mark: Mam. Teraz mówię: „przeczytaj wszystkie nasze rozmowy i podaj piętnaście rzeczy, które możemy zoptymalizować”. Kiedyś potrzebowałem do tego umiejętności, która dokładnie wskazywała, gdzie leżą pliki powiązane z naszymi rozmowami i jak je rozbijać, żeby nie wysadzać okna kontekstu pięćdziesięcioma tysiącami tokenów naraz, razy sto. Musiałem to tłumaczyć kawałek po kawałku. Dziś z całej umiejętności zostało jedno podstawowe zdanie — a on dokładnie wie, jak zoptymalizować pod mój CLAUDE.md. Zawsze dbam o okno kontekstu i o to, jak je wykorzystuję — i on robi to sam, bez mojego polecenia. (Informacja dodatkowa: CLAUDE.md — plik z instrukcjami i pamięcią projektu, który Claude Code czyta na starcie każdej sesji.)
Nate Herk: To nasuwa mi coś ciekawego. Ta swoboda, ta — można powiedzieć — lepsza radzenie sobie z problemami, bo on wie, jak dojść do celu… Może być też odrobinę przerażająca. Bo bywa, że to właśnie umiejętność trzyma go w ciasnych ryzach. Gdy musi sam szukać drogi od punktu A do B, może po drodze stworzyć coś, co zaszkodzi systemowi.
Mark: I po to jest reszta systemu operacyjnego — bo to nie sama umiejętność. Masz reguły, masz warstwy, które pełnią rolę niani. Możemy dożyć świata, w którym potrzebujemy znacznie mniej umiejętności, a znacznie ostrzejszych reguł. CLAUDE.md mówi wtedy w gruncie rzeczy: „w takich sytuacjach stosuj te zasady” — i to może wystarczyć. Niektóre warstwy — nawet sama idea przydzielania agenta, tworzenia własnego agenta startującego za każdym razem tak samo — mogą się zdezaktualizować. Nie twierdzę, że tak będzie; mówię: bądźmy otwarci na to, że to ewoluuje. Dopóki twoje kluczowe zasoby pozostają zwrotne — będzie dobrze.
Nate Herk: Pasuje to do czegoś, co niedawno widziałem. Nie pamiętam, czy przy Opusie 5, czy przy Fable 5 — przy jednej z tych premier Anthropic — opublikowali notkę z benchmarkami i poradą, jak używać i jak promtować. Na samej górze stało: „dawajcie mu ambitniejsze zadania”. Można to przeoczyć wzrokiem, ale mnie zastanowiło: czemu w ogóle czują potrzebę, żeby to pisać? Może uważają, że ludzie nie dociskają modeli do granic i że stają modelom na drodze. Wtedy zacząłem robić takie eksperymenty: stawiałem cel i mówiłem w stylu „zaimponuj mi — zbuduj to, ale zaimponuj mi, pokaż, na co naprawdę cię stać”. Sam fakt, że oni to napisali, dużo mówi. I dobrze komponuje się z tematem umiejętności: coś, co wstawiliśmy kiedyś i czego teraz używamy po omacku, bo działa, może wręcz przycinać to, co model potrafi — bo prowadzimy go starymi szynami.
Osobne systemy i zasada awansu do globalu
Nate Herk: Zbliżamy się do końca, więc zapytam wprost: co robisz w swoim harnessie — w Claude Code i reszcie — czego twoim zdaniem większość ludzi nie robi, a robić powinna?
Mark: Główna rzecz: mam czasem dwadzieścia pięć różnych systemów operacyjnych. Niektórzy wolą jeden wielki. Ja buduję bardzo konkretne, żyjące w odizolowanych światach. Podatki i finanse żyją u mnie zupełnie inaczej niż system konsultingowy, a ten inaczej niż system do contentów — i tak dalej. Każdy kawałek mojego biznesu — edukacja, oferty, wszystko, co robimy dla klientów korporacyjnych — ma własny zestaw systemów. Utrzymania jest więcej, nie ukrywam. Ale im więcej budujesz, tym więcej dźwigni. Mam jeden system nadrzędny, który na podstawie audytu każdego z pozostałych wypisuje listę rzeczy do poprawienia w tym konkretnym — oraz listę uogólnień na wszystkie naraz.
Bo gdy tworzysz foldery, masz umiejętności, reguły i CLAUDE.md na poziomie projektu — oraz poziom globalny. Niektórzy ustawiają wszystko globalnie, co jest fatalne: dokładasz nowe elementy i nagle widzisz spadek wydajności, bo zapomniałeś, że na wszystko działa ten globalny zestaw reguł. U mnie obowiązuje odwrotna koncepcja: awans. Wszystko jest projektowe, dopóki nie zasłuży na awans do globalu. Dzięki temu w każdym momencie wiem, co dokładnie działa mi globalnie — a działa bardzo niewiele. Prawie wszystko siedzi przy projektach. Daje mi to jeszcze jedną rzecz: bardzo mały promień rażenia, gdy chcę eksperymentować. Mogę audytować i dociskać jeden folder pod jeden typ zadania, bez obawy, że coś się rozleje na inny projekt — i bez dylematu: „czemu to nie działa? model się pogorszył? harness? czy mój setup?”. Jestem skrupulatny w rozdzielaniu: to problem modelu, opakowania czy organizacji. Gdy umiem izolować, szybciej znajduję przyczynę. Fable jest cudowny przy moich podatkach, a nagle okropny w systemie konsultingowym? To może nie być wina modelu ani umiejętności — to może być kwestia organizacji pod tego modelu, do której muszę się dostosować w tym projekcie. A to pozwala mi panować nad balastem i znajdować punkt oporu, który muszę ruszyć, żeby dostać efekty, których szukam.
Nate Herk: To bardzo mądre — zwłaszcza że te systemy działają tak autonomicznie. Musisz umieć wskazać tę jedną zmienną, która zawaliła zadanie, inaczej nie ma ani nauki, ani postępu. AI w większości przypadków pomoże ustalić, co i gdzie poszło nie tak. Ale sedno tej izolacji to ty: znasz układ swoich folderów. Nie ufasz ślepo, że wszystko znajdzie. Mam przeczucie, że gdybyś szukał konkretnego efektu końcowego, znalazłbyś go sam, klikając po plikach — bo wiesz, gdzie co leży. I to znowu pokazuje: zrozumienia nie da się zlecić. Musisz wiedzieć, gdzie wszystko jest i jak działa.
Mark: Ostatnia myśl: to umiejętność, która przychodzi z praktyką. A mistrzostwo to po prostu zrozumienie, jak cała fabryka działa od deski do deski i gdzie leży każda część. Więc jeśli chcesz więcej dźwigni — a przy problemach łapiesz się na lenistwie umysłowym: „o, ten model jest beznadziejny” — to zanim wyrok ostateczny, upewnij się, że być może jest beznadziejny tylko przy konfiguracji, którą właśnie masz. W razie wątpliwości: audytuj swój setup, swoje umiejętności i cały balast. Bo różne modele…
[Tutaj nagranie się kończy.]
10 najważniejszych takeaways — z kontekstem zastosowania
1.Oceniaj agenta jako całość: mózg plus opakowanie
Na czym polega: O wynikach decyduje harness — narzędzia, uprawnienia, reguły i skrypty wokół modelu. Po wycieku z marca 2026 r. wiadomo, że znaczna część „inteligencji” narzędzi to dopracowana maszyneria, a nie sam mózg; dobre wyniki benchmarków nie gwarantują ukończenia twojego zadania.
Jak stosować: Wybierając agenta, testuj go na jednym własnym, reprezentatywnym zadaniu od początku do końca, zamiast porównywać modele na sucho. Obserwuj też, jak szybko dostawca rozwija opakowanie pod nowe wersje mózgu.
Na co uważać: Na marketingowe porównania „model kontra model” — zwykle mówią o mózgu, a nie o tym, czy narzędzie dowiezie efekt na twoim sprzęcie i w twoim środowisku.
2.Test „od HTML do działającego serwera”
Na czym polega: Model bez harnessu wygeneruje kod, ale nie uruchomi go na twoim komputerze — nie ma „kończyn”. To najszybszy sposób, by zobaczyć rzeczywistą granicę narzędzia.
Jak stosować: Zleć zadanie z realnym artefaktem na końcu (strona postawiona lokalnie, plik przeniesiony w konkretne miejsce) i sprawdź, na którym kroku narzędzie się zatrzyma. Ten sam test użyty osobno do Claude w przeglądarce i Claude Code od razu pokaże różnicę w dostępnych narzędziach.
Na co uważać: Czat potrafi barwnie opisać, co „zrobiłby” — łatwo pomylić opis z wykonaniem. Zawsze weryfikuj, czy istnieje realny dostęp do twoich plików i do chmury.
3.Buduj zasoby przenośne, lojalność zostaw sobie
Na czym polega: Przewaga nie znika wraz ze zmianą dostawcy, jeśli umiejętności, reguły, hooki i zasoby są niezależne od modelu. Gość rozmowy wymienia mózg wymiennie, a przenosiny na inny model to dla niego kwestia doby.
Jak stosować: Trzymaj kluczowe zasoby w jednym, neutralnym miejscu (jeden link, jedno repozytorium) i testuj każdą umiejętność w co najmniej dwóch narzędziach. Ćwicz migrację regularnie, żeby w razie potrzeby była rutyną, a nie awaryjnym projektem.
Na co uważać: Ceny, limity i polityki dostawców zmieniają się bez ostrzeżenia — sentyment do marki ma swoją cenę. Z drugiej strony „przenośność” bez bieżących testów szybko się dezaktualizuje.
4.Dopasuj narzędzie do etapu zadania
Na czym polega: Claude Code to wizjoner do planowania, Codex to chirurg do realizacji i weryfikacji. Optymalny proces często używa obu po kolei, a zderzenie ich planów domyka luki.
Jak stosować: W procesie wieloetapowym rozdziel planowanie od wykonania; po przygotowaniu planu przez jedno narzędzie każ drugiemu je skrytykować i iteruj, dopóki plan nie obejmie uwag obu stron.
Na co uważać: Podział ról zmienia się z każdą wersją modeli i harnessów — co miesiąc weryfikuj, które narzędzie jest teraz lepsze do którego etapu, zamiast trzymać się sztywnych etykiet.
5.Odtwarzaj sprawdzone zachowania z plików JSONL
Na czym polega: Historie rozmów z Claude Code i Codexem leżą lokalnie jako pliki JSONL z metadanymi: jakie narzędzia wywołano, jakie weryfikacje i w jakiej kolejności. To gotowy materiał do naśladowania.
Jak stosować: Zleć agentowi przeczytanie dokumentacji wybranego harnessu (np. pi.dev) i przejrzenie własnych logów, a potem budowanie zachowań, które ci się podobają, w twoim opakowaniu — metodą „zobacz i powtórz”.
Na co uważać: Kopiowanie bez zrozumienia szybko się zestarzeje wraz z aktualizacjami narzędzi; wyciągaj zasady i mechanizmy, a nie dosłowne przepisy. Zasada rozmówców: myślenie możesz zlecić maszynie, zrozumienia — nigdy.
6.Pisz umiejętności-scyzoryki i automatyzuj portowanie
Na czym polega: Pliki umiejętności są strukturalnie podobne (YAML z nazwą i opisem pełnym słów wyzwalających), a różnice między narzędziami da się zniwelować. Skrypty w Pythonie są z natury przenośne.
Jak stosować: Niech AI przejrzy dokumentacje dostawców i zbuduje opis umiejętności tak konkretny, by każde narzędzie ją wyłapywało; utrzymuj skrypt w rodzaju /polyskill, który portuje i doszlifowuje umiejętności między harnessami.
Na co uważać: Największe ryzyko to zbyt ogólny opis — jedno narzędzie przegapi wyzwalacz i umiejętność „zniknie”. Aktualizuj portowanie przy każdej większej zmianie narzędzi.
7.Prowadź rot.md i audytuj warstwy w ich tempie
Na czym polega: Warstwy systemu operacyjnego AI starzeją się różnie: tożsamość — kwartalnie, reguły — tygodniami, czasem codziennie, hooki — mniej więcej półrocznie, umiejętności — najszybciej.
Jak stosować: Załóż plik rot.md z okresem ważności każdej warstwy i harmonogramem przeglądów; comiesięczny, automatyczny audyt niech wylicza umiejętności nieużywane, łączy pokrewne i pilnuje neutralności wobec modeli.
Na co uważać: Zaniedbany audyt zdradzają drobne sygnały: system dłużej szuka, halucynuje na podstawie starych plików. Naucz się je wyczuwać, zanim balast urośnie.
8.Każdą umiejętność testuj także bez niej
Na czym polega: Modele wyrastają z umiejętności: instrukcja, która kiedyś była konieczna, dziś bywa kulą, która spowalnia sprawniejszy model — stąd rada kasowania umiejętności co pół roku.
Jak stosować: Po każdej premierze nowego modelu uruchom kluczowe procesy z umiejętnością i bez niej, porównaj wynik i długość drogi; pytaj wprost: „czy ona wciąż dodaje wartość?”. Gdy model ogarnia resztę sam, ścinaj umiejętność do jednego zdania.
Na co uważać: Nie kasuj umiejętności z wiedzą milczącą — danych i know-how, których model nie zdobędzie z treningu. Do kasacji są instrukcje krok po kroku, nie wiedza firmowa.
9.Mniej umiejętności, ostrzejsze reguły, hooki na krytycznych momentach
Na czym polega: Rosnące modele potrzebują mniej „przepisów”, a więcej rygoru: reguł sytuacyjnych i automatycznych kontroli, na przykład czyszczenia danych osobowych przed publikacją kodu.
Jak stosować: Przenieś powtarzalne procedury z umiejętności do reguł w CLAUDE.md, a niedopuszczalne zdarzenia obsłuż hookami. Ambitniejsze cele („zaimponuj mi”) testuj w izolowanym projekcie — zwiększają i kreatywność, i ryzyko.
Na co uważać: Odhamowany model szuka własnych dróg — bez warstw pilnujących łatwiej o kroki szkodliwe dla systemu. Ściślejsze reguły to nie opcja, tylko warunek brzegowy.
10.Segmentuj systemy i świadomie awansuj do globalu
Na czym polega: Osobne, odizolowane systemy dla poszczególnych dziedzin (podatki, konsulting, content) plus zasada „wszystko jest projektowe, dopóki nie zasłuży na awans do globalu” dają mały promień rażenia i czytelny obraz tego, co działa zawsze.
Jak stosować: Przy każdej awarii rozstrzygaj po kolei: model, harness czy organizacja? Izolacja folderów pozwala wykluczać zmienne i szybciej znaleźć winną. Globalnych reguł trzymaj minimum — i zawsze z ich aktualną listą pod ręką.
Na co uważać: „Wszystko globalnie” potrafi niewidocznie obniżać wydajność każdego projektu. Ceną segmentacji jest większe utrzymanie i konieczność ciągłej świadomości, gdzie co leży — tej świadomości nie da się nikomu zlecić.