O czym jest ten film
- Anthropic przy okazji premiery Opusa 5 usunął ponad 80% systemowego promptu z Claude Code.
- Każdy nowy model traktowany jest jak inna osobowość — instrukcje pisane pod poprzednika mogą przestać działać.
- Boris Cherny, twórca Claude Code, wprost zaleca: co pół roku skasuj swoje CLAUDE.md, skille i hooki i zobacz, co model zrobi sam.
- Duża część dawnych instrukcji korygowała błędy modelu, których Opus 5 już nie popełnia.
- Nate testuje tę radę na własnym repozytorium i porównuje dwa wygenerowane materiały: ze skillami i bez.
- Wniosek z testu: wersja bez skilli miała lepszą treść, ale gorszą formę i brak elementów marki.
- Rozróżnienie kluczowe dla materiału: kontekst (gdzie co leży, jak wygląda marka) zostaje, mikrozarządzanie sposobem wykonania zadania odchodzi.
- Pojęcie „unhobbling” i „product overhang” — modele potrafią dziś więcej, niż zdążyliśmy odkryć.
- Weryfikacja pracy przez samego agenta to według Cherny’ego najczęściej pomijany i najważniejszy element promptowania.
- Ostrzeżenie przed bezrefleksyjnym kopiowaniem porad ekspertów, którzy pracują w zupełnie innym trybie niż my.
Redakcyjne tłumaczenie
Punkt wyjścia: dlaczego więcej instrukcji może szkodzić
Posłuchałem, jak twórca Claude Code tłumaczy, dlaczego Claude „stał się gorszy” i jak to naprawdę naprawić. Dowiedziałem się czegoś, co brzmi bardzo dziwnie: więcej skilli i więcej systemowych promptów prawdopodobnie psuje wasz system. Zacząłem drążyć temat, przeprowadziłem własne testy i wyszły z tego trzy rzeczy, które każdy powinien teraz robić. Są bardzo proste we wdrożeniu i nie wymagają żadnego doświadczenia technicznego. Zacznijmy od kontekstu — od tego, co dzieje się za kulisami w Anthropic.
(Informacja dodatkowa: Boris Cherny, cytowany w filmie, jest twórcą Claude Code. Wywiad, z którego pochodzą fragmenty, ukazał się na kanale Y Combinator.)
Prowadzący: Porozmawiajmy chwilę o nowym wydaniu. Usunęliście ponad 80% systemowego promptu z Claude Code.
Boris Cherny: Tak.
Prowadzący: Opowiedz o tym więcej.
Boris Cherny: Wiele osób może nie zdawać sobie sprawy, że Claude Code — i jako produkt, i jako harness — cały czas się zmienia. Ciągle coś dodajemy i ciągle coś usuwamy. Za każdym razem, gdy wychodzi nowy model, kasujemy sporą część systemowego promptu i sporą część przepisujemy. Bez przerwy zmieniamy też zestaw narzędzi i opisy tych narzędzi. Powód jest taki, że każdy model jest zupełnie inny. To, co zrobiłeś pod jeden model trzy miesiące temu, może w ogóle nie przekładać się na kolejny. A Opus 5 jest po prostu bardzo inteligentny. Mnóstwo rzeczy w systemowym prompcie korygowało zachowania, które model powinien był znać sam, a ich nie znał. Teraz Opus 5 po prostu to robi.
(Informacja dodatkowa: „harness” to warstwa oprogramowania wokół modelu — narzędzia, pętla działania, obsługa uprawnień. Model to silnik, harness to reszta samochodu.)
Każdy model to inna osobowość
To ciekawe i daje do myślenia. Chciałem tylko położyć fundament pod resztę: w Anthropic traktują każdy model jak zupełnie inną osobowość — inne wady, inne mocne strony, inny sposób, w jaki należy go promptować. Dlatego zawsze wam powtarzam: kiedy wychodzi nowy model, przepuśćcie go przez swoje skille. Sprawdźcie, czy wszystkie nadal działają i czy nadal dobrze się z nimi pracuje.
Z jakiegoś powodu przy Opusie 5 miałem wrażenie regresu — do tego stopnia, że czasem wracałem do 4.8, gdy musiałem coś zrobić, i dostawałem lepsze wyniki. Ale nigdy nie przyszło mi do głowy, że może wystarczy pozbyć się części własnych instrukcji i zejść modelowi z drogi, bo on jest po prostu inteligentniejszy i sam sobie z tym poradzi.
Boris Cherny: Dla osób, które nie budują produktów agentowych, tylko po prostu używają Claude Code: raz na pół roku skasujcie swój CLAUDE.md, skasujcie skille, skasujcie hooki i zobaczcie, co model zrobi. Może was zaskoczyć. A przy Opusie 5 naprawdę to zalecamy — po prostu spróbujcie usunąć te wszystkie rzeczy, bo model może naprawdę nie potrzebować instrukcji, które były niezbędne przy poprzednich modelach.
Analogia: dziesięciolatek, student i weteran
Kiedy się nad tym zastanowić, brzmi to kontrintuicyjnie. Wmawiano nam przecież — i sam to często powtarzam — że skoro wszyscy mają dostęp do tego samego modelu, to wszyscy powinni dostawać takie same wyniki. Do pewnego stopnia to prawda. Ale skoro Boris mówi „usuńcie skille, usuńcie własne systemowe prompty i zobaczcie, co jest możliwe”, to jest zupełnie inny sposób myślenia.
Pierwsze, co przychodzi mi do głowy: wyobraźmy sobie, że uczę przygotowywania prezentacji trzy osoby — dziesięciolatka, studenta i kogoś, kto pracuje w zawodzie od dziesięciu lat. Dziesięciolatkowi dałbym najbardziej szczegółowe instrukcje: masz zrobić dokładnie te dziesięć slajdów, tytuł ma wyglądać tak, kolory takie, tekst sformatowany w ten sposób. Byłbym maksymalnie precyzyjny i praktycznie nie zostawiłbym mu miejsca na eksperymenty — bo skoro stawka jest wysoka, chcemy to prowadzić za rękę.
Ale im wyżej wchodzimy po drabinie inteligencji i doświadczenia, tym gorzej to działa. Gdybyśmy dali ten sam zestaw instrukcji komuś, kto pracuje dziesięć lat i zrobił setki prezentacji, po prostu weszlibyśmy mu w drogę. Nie mógłby wykorzystać swojej wiedzy merytorycznej ani inteligencji, żeby dodać coś od siebie. Nie twierdzę, że tak jest zawsze, ale jest w tym element zdejmowania z modelu części instrukcji i ograniczeń. Nazywają to „unhobbling” — zdejmowaniem pęt — i zaraz puszczę o tym fragment.
Test na własnym repozytorium
Zobaczcie, co u siebie sprawdziłem. Po obejrzeniu tego wywiadu zduplikowałem swoje repozytorium, usunąłem plik CLAUDE.md, usunąłem wszystkie skille i zacząłem trochę w tym pracować, żeby zobaczyć, jak to działa. Było w porządku. Ale intuicja podpowiada mi coś takiego: kiedy budujemy coś w rodzaju systemu operacyjnego dla AI, to CLAUDE.md jest tym, co rozdziela ruch — mówi, gdzie jest kontekst mojego biznesu, gdzie leżą pliki, gdzie są bazy wiedzy. To jest ważne. Nadal potrzebujemy przekazać Claude’owi: „tutaj znajdziesz swoje rzeczy”. Natomiast jeśli chodzi o samo wykonanie zadania — może warto trochę zejść z drogi. I to jest miejsce, w którym skille albo tracą znaczenie, albo powinny wyglądać inaczej.
Konkretny przykład. Wziąłem ten film — ten wywiad, który oglądamy — podałem Claude’owi URL i powiedziałem: „zrób mi przewodnik po zasobach z tego filmu, taki jak te, które robię dla widzów”. Powstał dziewięciostronicowy przewodnik. Ładnie sformatowany, z kolorami, z blokami, z moim nagłówkiem i grafiką w nagłówku, z linkiem do mojego kanału YouTube na dole i linkiem do AIS Plus. To są rzeczy bardzo specyficzne — moje preferencje i mój styl.
A teraz wersja druga. Świeża sesja, praktycznie ten sam prompt, ale zero skilli i zero kontekstu. Efekt oczywiście nie wygląda tak dobrze — jest bardziej chaotyczny, brakuje ładnego formatowania, nie ma nagłówka. Ale uważam, że jako materiał jest lepszy, właśnie dlatego, że nie powiedziałem mu wprost: „przewodnik po zasobach robi się tak, tak i tak, oto jak masz to rozbić na części”. Model rozbił materiał na idee. Każda idea ma znacznik czasu: „prompty są jednorazowe”, „odbuduj na podstawie obserwacji” i tak dalej — wszystkie główne wątki z osi czasu. Treściowo wolę tę wersję bez skilli i bez CLAUDE.md.
Co bym więc zrobił? Zaszyłbym to w skillu w takiej formie: „przewodnik zrób tak, jak uważasz za stosowne, ale weź tę grafikę do nagłówka, wstaw link do mojego kanału na górze i link do AIS Plus na dole”. To jest ten obszar, w którym — moim zdaniem — rzecz nie polega na kasowaniu wszystkich skilli, tylko na przemyśleniu ich i zrobieniu wersji, które nie są aż tak drobiazgowe.
Nie kopiuj porad bezrefleksyjnie
Jeszcze jedna rzecz, którą dorzucam już na etapie montażu, bo uważam ją za bardzo ważną: nie można brać rady od Borisa Cherny’ego, od jakiegoś youtubera, ode mnie czy od kogoś ze społeczności i stosować jej u siebie jako uniwersalnej zasady. To tak nie działa. Intuicja podpowiada mi, że wiele porad Borisa — albo tych, które przeczytacie na Twitterze u Andreja Karpathy’ego — pochodzi z perspektywy kogoś, kto siedzi po łokcie w projektowaniu harnessów, pracuje codziennie na ogromnych bazach kodu i trenuje modele. Ja nie robię tego, co on. Nie wiem, czy wy robicie. Rady warto brać raczej od ludzi, którzy używają systemów AI tak, jak wy chcecie ich używać. U mnie to głównie research, praca z wiedzą, tworzenie dokumentów i materiałów — a nie budowanie oprogramowania.
Boris ma tu naprawdę dobre rady, ale powodem, dla którego nie skasowałem wszystkiego jednym ruchem, jest to, że według moich testów przeróbka jest dla mnie wartościowsza niż czystka. Osoby, które budują produkty i software, mają całe zestawy skilli do budowania i orkiestracji — być może właśnie te powinny zniknąć zupełnie, bo model i harness robią to dziś lepiej. Ale jak widzieliście na moim przykładzie, ja nadal potrzebuję skilla, który powie: „bierzesz tę grafikę, wstawiasz ją tutaj, używasz tych kolorów, bo to nasze wytyczne marki”. Tego typu rzeczy pozostają ważnym kontekstem w pracy z wiedzą. Warto o tym pamiętać. I wygląda na to, że Boris całkowicie się z tym zgadza.
Unhobbling i product overhang
Boris Cherny: „Hobbling” to takie badawcze pojęcie: model coś robi, a ty po prostu wchodzisz mu w drogę. Jest też inne ujęcie, które bardzo lubię, przydatne zwłaszcza przy budowaniu produktu — „product overhang”. Chodzi o to, że model potrafi robić mnóstwo rzeczy już dziś, nie w jakiejś przyszłej wersji, tylko w tej, którą mamy — a my jeszcze tego nie odkryliśmy. Jest ogrom możliwości, z których ludzie nie zdają sobie sprawy.
Myślę o tym na dwa sposoby. Po pierwsze: dawaj modelowi zadania nieco trudniejsze, niż według ciebie jest w stanie wykonać. Bardzo częsty błąd, który widzę, to ludzie używający Claude Code i Claude’a, którzy dają skrajnie szczegółowe instrukcje: „chcę, żebyś zrobił to, ale w ten sposób, i w ten, i w ten; masz zrobić najpierw jeden, potem dwa, potem trzy, potem cztery”. Przy współczesnych modelach to naprawdę nie jest właściwa droga. Trzeba wejść trochę wyżej: opisz zadanie, opisz bariery ochronne, opisz kryteria zakończenia — a potem pozwól modelowi pracować i wróć po chwili. Myślę, że cię zaskoczy. I znów: pół roku temu to by nie zadziałało, a dziś działa.
(Informacja dodatkowa: „product overhang” to sytuacja, w której możliwości technologii wyprzedzają sposób, w jaki ludzie faktycznie z niej korzystają — potencjał już istnieje, ale nikt go jeszcze nie „rozpakował”.)
Wysokopoziomowy cel plus standard jakości
Jeśli wcześniej was nie przekonałem, to mam nadzieję, że przekonuje was to, co powiedział Boris Cherny. Składa się na to wiele rzeczy. Jest oczywiście balans w używaniu CLAUDE.md w sposób, który nie spętuje modelu — i to samo dotyczy skilli. Ale jest też balans polegający na tym, żeby faktycznie dostać wynik, który nam się podoba. Wielu z nas frustruje się, gdy prosimy Claude’a o coś, a wraca przeciętny efekt. Tylko że może to była nasza wina. Może to było nasze zadanie, żeby powiedzieć: oto jak wygląda dobra robota. Bo jeśli model nie wie, jak wygląda dobre, to jak ma stworzyć coś dobrego?
Tak jak mówi Boris: dajesz wysokopoziomowy cel. Ustawiasz standard i mówisz w istocie: nie przerywaj, dopóki nie skończysz, dopóki nie osiągniesz tego poziomu. Ustawiając taki cel dla agenta, nie mówisz tylko „oto jak wygląda dobre” — mówisz też: oto X, Y i Z, które masz wykonać, żeby udowodnić, że to zostało osiągnięte. I iterujesz, aż faktycznie to udowodnisz. Weryfikujesz sam siebie, żebym ja nie musiał weryfikować.
Na przykład: na końcu moich wysokopoziomowych celów, po podaniu wszystkich standardów i metod weryfikacji, dopisuję mniej więcej coś takiego: „nie szukam prototypu ani proof of concept; chcę czegoś przetestowanego, przeiterowanego dziesięć razy, w pełni przetestowanego jakościowo i gotowego, żeby jutro trafić na rynek”. To nadaje sprawie odrobinę emocji — a kiedy promptuję z emocjami, wyniki bywają lepsze. Zobaczmy jednak, co Boris mówił o weryfikacji.
Weryfikacja — najczęściej pomijany element
Boris Cherny: Uważam, że dzisiejsza umiejętność to w mniejszym stopniu prompt engineering, a w większym — wymyślenie, jak dać Claude’owi trudne zadanie. Takie, które wydaje się odrobinę za trudne. I jak umożliwić Claude’owi weryfikowanie własnej pracy po drodze. Weryfikacja to prawdopodobnie ta jedna rzecz, której ludzie najczęściej nie robią jak trzeba.
Zarządzanie agentami to zarządzanie ludźmi
Naprawdę ciekawie się patrzy, jak myśli o tym twórca Claude Code. Im głębiej wchodzę w tę branżę i im więcej rozmawiam z ludźmi, którzy dopiero zaczynają, tym wyraźniej widzę, że umiejętności, które tu przenosimy, są niezależne od narzędzia. Czy używasz Claude Code, Hermesa, czy czegokolwiek innego — kluczowa umiejętność to zarządzanie agentami AI. A przez „zarządzanie” rozumiem to samo, co przy zarządzaniu ludźmi.
Nie zarządzam ludźmi od bardzo dawna, ale wiem tyle: dobrzy menedżerowie nie mikrozarządzają. Nie mówią „masz zrobić to, w ten sposób, ruszaj”. Schodzą swoim ludziom z drogi. Sprawdzają, jak idzie. Recenzują. Mają osąd i gust. Ale pozwalają ludziom używać własnej głowy — w końcu po coś ich zatrudnili.
Tak samo warto myśleć o wszystkich agentach i sesjach, które uruchamiacie. Używacie ich po coś. Oddajcie im myślenie. Pozwólcie im myśleć i wychodzić z pomysłami, ale dajcie im też możliwość uruchamiania innych agentów w roli adwokata diabła. Dajcie im możliwość sprawdzenia i zweryfikowania własnej pracy. Oddajcie część myślenia — ale nigdy nie oddawajcie rozumienia. Na koniec dnia to wy jesteście założycielami tych agentów i to wy prowadzicie wizję, ale one mogą wam ogromnie pomóc.
Mógłbym o tym mówić cały dzień. Jeśli chcecie obejrzeć ten wywiad — trwa około 35 minut, jest na kanale Y Combinator, link zostawiam w opisie. To były tylko wybrane fragmenty, które chciałem wyciągnąć i omówić. Dajcie znać, czy podoba wam się taki format. Mam nadzieję, że było wartościowo, że nauczyliście się czegoś nowego i że jest coś, co chcecie u siebie wypróbować.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Traktuj każdy nowy model jak nowego pracownika, nie jak update
Na czym polega: Anthropic przy każdej premierze przepisuje i kasuje spore fragmenty systemowego promptu Claude Code, bo instrukcje pisane pod poprzedni model nie przenoszą się automatycznie. Każdy model ma inne wady, inne mocne strony i inny optymalny sposób promptowania.
Jak stosować: Po premierze nowego modelu przepuść przez niego swoje skille i pliki instrukcji, jeden po drugim, i sprawdź, czy nadal dają dobry efekt. Zrób to zanim uznasz, że „model się popsuł”.
Na co uważać: Poczucie regresu bywa złudne — Nate sam wracał do starszej wersji, zanim zorientował się, że problemem mogą być jego własne instrukcje, a nie model.
2.Rób okresowy audyt przez skasowanie, a nie przez czytanie
Na czym polega: Rada twórcy Claude Code brzmi wprost: raz na pół roku skasuj CLAUDE.md, skille i hooki i zobacz, jak model radzi sobie bez nich.
Jak stosować: Nie kasuj na produkcyjnym repozytorium — zrób duplikat, tak jak w filmie, i popracuj w nim kilka dni na typowych zadaniach. Dopiero potem decyduj, co wraca.
Na co uważać: To eksperyment diagnostyczny, a nie docelowy stan. Autor po teście nie skasował niczego na stałe — przerobił instrukcje.
3.Odróżnij kontekst od mikrozarządzania
Na czym polega: Najważniejsze rozróżnienie w całym materiale. Kontekst — gdzie leżą pliki, gdzie są bazy wiedzy, jaki jest kontekst biznesu, jak wygląda marka — zostaje. Instrukcje krok po kroku, jak wykonać zadanie, można w dużej części usunąć.
Jak stosować: Przejdź swój CLAUDE.md linijka po linijce i zaznacz przy każdej: „to informacja, której model nie może znać” czy „to moja próba sterowania jego sposobem pracy”. Drugą kategorię tnij.
Na co uważać: Elementy marki, linki, grafiki i schematy kolorystyczne to kontekst, nie mikrozarządzanie — one muszą zostać, bo model nie zgadnie twoich wytycznych wizualnych.
4.Skille przepisuj na „co”, nie na „jak”
Na czym polega: W teście Nate’a wersja bez skilli miała lepszą strukturę merytoryczną (podział na idee ze znacznikami czasu), a wersja ze skillami — lepszą formę i elementy marki. Wniosek: skill powinien narzucać nienegocjowalne detale, a resztę zostawić modelowi.
Jak stosować: Przepisz skill w formie: „zrób to, jak uważasz za stosowne, ale obowiązkowo: ta grafika w nagłówku, ten link na górze, ten na dole”. Reszta struktury zostaje otwarta.
Na co uważać: Jeśli zostawisz w skillu narzucony podział na sekcje, dostaniesz zawsze ten sam szablon — nawet gdy materiał źródłowy prosi się o inny układ.
5.Dawaj zadania odrobinę za trudne
Na czym polega: „Product overhang” — model potrafi już dziś więcej, niż zdążyliśmy odkryć, a najczęstszy błąd to zbyt szczegółowe, rozpisane na kroki polecenia.
Jak stosować: Zamiast listy „zrób 1, potem 2, potem 3” podaj: opis zadania, bariery ochronne i kryteria zakończenia — a potem pozwól modelowi popracować i wróć po jakimś czasie.
Na co uważać: Bariery ochronne nie są opcjonalne. „Wyżej poziomem” nie znaczy „mniej precyzyjnie” — znaczy „precyzyjnie co do celu i granic, luźno co do metody”.
6.Powiedz modelowi, jak wygląda dobra robota
Na czym polega: Frustracja przeciętnymi wynikami często wynika z tego, że nie zdefiniowaliśmy standardu. Jeśli model nie wie, co jest dobre, nie wyprodukuje czegoś dobrego.
Jak stosować: Do każdego niebanalnego zadania dołącz krótki opis standardu jakości — czym się będzie mierzyć sukces, jak wygląda wynik, który przyjmiesz bez poprawek.
Na co uważać: Standard jakości to nie to samo co instrukcja wykonania. Opis „co ma być prawdą o efekcie” nie spętuje modelu, opis „w jakiej kolejności ma klikać” — spętuje.
7.Weryfikacja jest ważniejsza niż prompt engineering
Na czym polega: Według twórcy Claude Code umożliwienie modelowi weryfikowania własnej pracy w trakcie to pojedyncza rzecz, którą ludzie najczęściej robią źle.
Jak stosować: Do celu dopisz konkretne metody dowodzenia: jakie X, Y, Z model ma wykonać, żeby udowodnić, że standard został osiągnięty, i każ mu iterować aż do skutku. „Weryfikuj się sam, żebym ja nie musiał”.
Na co uważać: Weryfikacja bez zdefiniowanego kryterium jest pozorna — model potwierdzi sobie, że skończył. Metody dowodzenia muszą być sprawdzalne, a nie deklaratywne.
8.Nie kopiuj porad ekspertów o innym profilu pracy
Na czym polega: Rady Borisa Cherny’ego czy Andreja Karpathy’ego pochodzą od ludzi projektujących harnessy, pracujących na ogromnych bazach kodu i trenujących modele. To nie jest kontekst większości widzów.
Jak stosować: Zanim wdrożysz cudzą radę, sprawdź, czy jej autor używa AI tak, jak ty chcesz jej używać. Do pracy z wiedzą i dokumentami szukaj źródeł z tego obszaru, nie z inżynierii modeli.
Na co uważać: To działa w obie strony — także rady z tego filmu są z perspektywy pracy z wiedzą, a nie budowania oprogramowania. U programisty proporcje mogą wyjść zupełnie inaczej.
9.Skille do budowania i orkiestracji kasuj śmielej niż skille do formy
Na czym polega: Autor sugeruje, że osoby budujące produkty i oprogramowanie mają całe zestawy skilli do budowania i orkiestracji, które model i harness robią dziś lepiej same — i tam czystka może być całkowita.
Jak stosować: Podziel swoje skille na dwie grupy: proceduralne (jak coś wykonać, jak zorganizować pracę) i tożsamościowe (jak ma wyglądać efekt, marka, format). Pierwszą grupę testuj pod kątem usunięcia w całości.
Na co uważać: To hipoteza autora oparta na własnych obserwacjach, nie na przetestowanym porównaniu w kontekście programistycznym — traktuj ją jako punkt wyjścia do własnego testu.
10.Oddaj myślenie, nigdy nie oddawaj rozumienia
Na czym polega: Zarządzanie agentami przypomina zarządzanie ludźmi. Dobry menedżer nie mikrozarządza — schodzi z drogi, sprawdza postępy, recenzuje, ma osąd i gust, ale pozwala ludziom myśleć.
Jak stosować: Pozwól agentom generować pomysły i uruchamiać innych agentów w roli adwokata diabła oraz do sprawdzania własnej pracy. Ty utrzymujesz wizję i podejmujesz decyzje.
Na co uważać: Granica jest wyraźna: oddajesz wykonanie myślenia, ale nadal musisz rozumieć wynik. Jeśli nie umiesz ocenić efektu, żadna liczba weryfikujących agentów cię nie uratuje.