O czym jest ten film
- Autor odkrył, że przez lata intensywnego używania AI zbudował ogromny, nieuporządkowany „harness” — całą warstwę reguł, skilli, plików i pamięci owijającą model.
- Definiuje pojęcie harnessu: to wszystko wokół modelu, co kształtuje odpowiedź, zanim jeszcze wpiszemy cokolwiek w okno promptu.
- Inwentaryzacja jego konfiguracji ujawniła 66 skilli i 172 pliki instrukcji; jedno zadanie pisarskie potrafiło wciągnąć plik o wielkości 18 000 słów.
- Główny problem to nie liczba reguł, lecz brak wglądu w to, które chronią pracę, a które są duplikatami, nakładkami lub przeżytkami z czasów starszych modeli.
- Autor zbudował „cleaner” — skill, który mapuje harness i pokazuje go w całości w jednym miejscu.
- Przedstawia sześć zasad budowania stabilniejszego harnessu.
- Pokazuje różnicę między instrukcjami tekstowymi a twardymi „zamkami” (uprawnienia, schematy, testy), które faktycznie mogą coś zablokować.
- Porównuje zachowanie Fable 5 i rodziny ChatGPT 5.6 — te same reguły, ale różne tryby awarii i różne wrażliwości na przeciążenie kontekstem.
- Kluczowy wniosek: model i harness razem tworzą efekt; obwinianie samego modelu prowadzi do dokładania reguł, które psują pracę.
- Cleaner jest dostępny na Substacku; można go wskazać na własną konfigurację, dostać mapę, decyzje czyszczące i „receipt” z tego, co się wydarzyło.
Redakcyjne tłumaczenie
Jak niepostrzeżenie zbudowałem przerośnięty harness
Przebudowałem swoją konfigurację pod Fable 5 i ChatGPT 5.6 — i zrobiłem to jeszcze zanim te modele się ukazały. Byłem podekscytowany. Dużo korzystam z AI, ciągle dodaję nowe reguły, nowe instrukcje, nowe skille i robię to z entuzjazmem. A wiecie, co to oznacza? Że wszystko wokół modelu — wszystkie te skille, stare system prompty, cała ta warstwa — stało się balastem, który nie pozwalał moim modelom działać dobrze.
Za każdym razem, gdy AI coś pominęło, dokładałem kolejną regułę. Wielu z nas tak robi. Mówiłem mu: „korzystaj z tych źródeł poprawnie”, „pisz moim głosem”, „sprawdzaj długość w ten sposób”, „najpierw przeczytaj ten plik”, „nigdy więcej nie popełnij tego błędu”. Każda reguła w momencie powstania rozwiązywała realny problem, ale z czasem nie zauważyłem, jak bardzo mój harness spuchł.
Czym jest harness
Jeśli nie wiesz, czym jest harness, to samo w sobie jest częścią problemu — jako społeczność nie mówiliśmy o tym jasno. Harness to wszystko, co owija model. To twoje własne instrukcje. Twoje pliki projektu. Zapisane prompty. Pamięć. Skille, narzędzia. Uprawnienia i wszelkie kontrole, które uruchamiasz. To kształtuje odpowiedź, zanim cokolwiek wpiszesz w okno promptu — bo dołącza się do niego i pomaga modelowi zrozumieć, co ma odpowiedzieć.
Większość z nas nigdy nie zamierzała budować harnessu. Zbudowaliśmy go przypadkiem, jedna poprawka na raz. Nie miałem żadnego ekranu, który pokazałby mi pełen zakres harnessu, jaki zbudowałem w Codeksie i w Claude. Widziałem najnowszą regułę, jeśli jej szukałem, ale nie widziałem całego systemu w jednym miejscu.
Kiedy AI zaczynało zachowywać się dziwnie, często obwiniałem model — i wiem, że wielu ludzi tak robi — a potem dokładałem kolejną regułę, która czyniła całość jeszcze bardziej rozdętą. Dlatego zbudowałem skill, który czyni harness widocznym.
Sześć zasad — zapowiedź
Pokażę wam sześć zasad budowania stabilniejszego harnessu, w tym to, co działa inaczej dla Fable 5 i rodziny ChatGPT 5.6. Potem pokażę, jak uruchomić ten sam „cleaner” na własnej konfiguracji. Cel jest prosty: modele wciąż ewoluują i to się nie zmieni.
Gdy uruchomiłem pierwszą inwentaryzację, znalazła 66 wielokrotnie używanych skilli i 172 pliki związane z instrukcjami. Byłem bardzo zajęty. Jedno zwykłe zadanie pisarskie potrafiło wciągnąć plik o wielkości 18 000 słów, jeszcze zanim dostosowało prompt. Ale liczba nie była prawdziwym problemem. Część tych instrukcji naprawdę chroni ważną pracę. Mówią AI, które źródła są istotne, gdy prowadzę research. Powstrzymują je przed wymyślaniem opinii, których szczerze nie mam — nie znoszę, kiedy to robi. Definiują, co może zrobić bez pytania, a o co musi zapytać.
Problem w tym, że przy nowej inteligencji, przy nowych modelach, nie potrafiłem odróżnić, które reguły chronią pracę, a które są tylko kopiami, nakładają się na siebie, przychodzą zbyt wcześnie, są zbędne przy dzisiejszych modelach albo pokrywają się w sposób mylący dla modelu.
To jak wszystko wokół silnika w samochodzie, aż po to, co wprawia koła w ruch. Wał napędowy to przykład. Podwozie. Wszystkie części auta, które nie są silnikiem, a są potrzebne, by przenieść siłę z silnika na koła — tym właśnie jest harness dla modelu AI. On faktycznie umożliwia pracę i powinniśmy projektować go świadomie, a nie zgadywać i wrzucać śruby do samochodu na oślep.
Model się zmienia, harness — nie
Rzecz w tym, że gdy zmienia się model, harness nie przebudowuje się magicznie. Czasem sam wybierasz nowy model. Czasem ChatGPT albo Claude zmienia ci domyślny model, wycofuje starszy i kieruje trudne żądanie gdzie indziej. A czasem przełącza modele w środku rozmowy — możesz nawet nie wiedzieć, że to się stało. Stara konfiguracja, stary harness, stare podwozie tego auta zostaje na miejscu. Nowy model może przez to zachowywać się zupełnie inaczej, a ty zastanawiasz się dlaczego. Obwiniasz model. Doświadczenie się pogarsza. Więc dokładasz kolejną instrukcję.
Zasada 1: Najpierw zmapuj harness, potem go czyść
Wskazałem konfigurację, której już używam, i poprosiłem, by wyczyściła harness, który potrafi zobaczyć. Nie zbieram każdego promptu ręcznie. Nie decyduję z góry, co ma zostać usunięte. Skill zaczyna od stworzenia mapy mojego harnessu. Stąd pierwsza reguła: mapujesz harness, zanim go wyczyścisz. To zasada — skill ją realizuje, bo to po prostu dobry pomysł.
Mapa daje każdej istotnej kontroli w harnessie osobny wiersz i pyta: „Gdzie ta kontrola żyje? Kiedy się ładuje? Jaką pełni funkcję? Kto jest jej właścicielem? Czy są dowody, że wciąż pomaga? Jaki problem może stworzyć, jeśli zostanie źle użyta?”. To był pierwszy raz, gdy zobaczyłem cały swój harness w jednym miejscu. I było naprawdę odkrywcze, ile było tam śmieci.
Mapa ujawniła też różnicę, którą chatboty zwykle ukrywają. Niektóre kontrole to prawdziwe zamki. Mają zęby. Uprawnienie może zablokować akcję, schemat może odrzucić uszkodzony plik JSON, task może odmówić przepuszczenia złego wyniku. To nie jest ten sam rodzaj instrukcji co zwykły tekst. Dopóki nie zmapujesz harnessu, wszystko wygląda dla ciebie jak tekst, ale AI nie czyta tego tak samo.
Zasada 2: Obwiniaj właściwą warstwę
Drugą zasadą, której się nauczyłem, jest obwinianie właściwej warstwy. Przetestowałem to samo zadanie z Fable 5 w dwóch konfiguracjach. Kompaktowa dała Fable cel, fakty, granicę uprawnień i linię mety. Grubsza konfiguracja — grubszy skill — dała to wszystko plus pełną metodę, plus system punktacji, plan ewaluacji i schemat klasyfikacji.
Grubsza wersja rzeczywiście wykonała zadanie pełniej. Analiza była znacznie bogatsza — ale dwukrotnie nie spełniła realnych wymagań dostarczenia. Jeden wynik zepsuł JSON, drugi przekroczył limit słów. Kompaktowa konfiguracja ukończyła zadanie poprawnie trzy razy na trzy.
To nie znaczy, że krótkie prompty zawsze wygrywają — chcę to jasno powiedzieć. To znaczy, że model i harness wytwarzają pracę, na której nam zależy, razem. Jeśli obwiniasz o wszystko model, będziesz wciąż dokładać instrukcje, żeby rozwiązać problemy stworzone przez instrukcje, a nie przez model. Dlatego cleaner wymusza dużo bardziej użyteczne pytanie: czy zawiódł model, czy zawiodła otaczająca go konfiguracja? Czy zawiódł harness?
Zasada 3: Jedna reguła, jeden dom, jeden właściciel
Trzecia reguła jest łatwa do zapamiętania: jedna reguła, jeden dom, jeden właściciel. Moja konfiguracja miała wersje tej samej reguły o autorstwie i źródłach w 15 różnych skillach najwyższego poziomu. To znaczyło, że bardzo mi na tym zależało, ale nie robiłem postępów w żadnym pojedynczym skillu, więc ciągle nad tym pracowałem.
To, na czym mi krytycznie zależy, to żeby AI nie wkładało mi słów w usta. Nie chcę, żeby wracało z researchem i udawało, że to moja opinia. Miałem więc 15 różnych wersji skilla, który powstrzymuje AI przed przeczytaniem stosu researchu i wróceniem w moim głosie — bo naprawdę zależy mi na tym, żeby dokładnie rozumieć, co zostało zbadane, i mieć poprawne cytaty. Chcę tę jakość zachować, ale na pewno nie potrzebuję do tego 15 plików. I najwyraźniej żaden nie robił tego jak trzeba, skoro wciąż dokładałem.
Każda kopia to kolejne miejsce, w którym reguła może zacząć dryfować. Jedną wersję poprawiasz po awarii, 14 zostaje — teraz są rozjechane, model ma kilka wersji prawdy. Wiadomo, do czego to prowadzi. To po prostu złe. Cleaner nie pyta, czy instrukcja jest za długa. Jest sprytniejszy: pyta, jaką funkcję ta instrukcja pełni, gdzie ta funkcja powinna mieszkać i kto powinien ją aktualizować, gdy następnym razem coś się zmieni.
Zasada 4: Ładuj specjalistyczną wiedzę wtedy, gdy jest potrzebna
Przewijającym się motywem jest tu ładowanie właściwej informacji we właściwym czasie. Czwarta reguła kodyfikuje to wprost: specjalistyczną wiedzę ładuj wtedy, gdy praca faktycznie jej potrzebuje.
Miałem sześć różnych przewodników redakcyjnych, które ładowały się, gdy tylko uruchamiał się jeden skill do pisania. Przewodnik o źródłach ma ogromne znaczenie, gdy robię research. A jeśli szukam przykładów do YouTube, potrzebuję ich w momencie, gdy zmagam się ze scenariuszem. To wszystko jest świetne, ale jeśli ładujesz to wszystko na początku, po prostu wpychasz do AI kupę zbędnego materiału, który prawdopodobnie pogorszy wyniki. Twój research jest gorszy, bo model myśli o przykładach do YouTube, gdy powinien myśleć wyłącznie o researchu.
Cleaner zachowuje bibliotekę specjalistycznych skilli — ona jest przydatna. Zmienia tylko to, kiedy każda jej część się pojawia. I tu, moim zdaniem, wiele czyszczących promptów nie do końca rozumie, co robi. Celem nie jest wyrzucenie użytecznego kontekstu. Twoja biblioteka może być całkiem duża — to nie jest złe.
Zasada 5: Twarde wymagania potrzebują twardych kontroli
Piąta reguła mówi, że jeśli masz twarde wymagania, potrzebują one twardych kontroli. Jest różnica między powiedzeniem modelowi, że masz jakiś pogląd, a poproszeniem go, by się z tym poglądem wspólnie zmierzył.
Prosta zasada, którą cleaner sprawdza: jeśli masz reguły typu „50 słów” z odpowiedziami tak/nie, które model może przetestować, powinny trafić do schematu, względem którego model może się sprawdzić. Cleaner może w tym pomóc. Kluczowa zasada: pozwalamy systemowi egzekwować to, co maszyna potrafi zweryfikować — a to czyni harness jednocześnie lżejszym i bezpieczniejszym.
Zasada 6: Buduj pod model i produkt, który faktycznie wykonuje pracę
Szósta i ostatnia reguła: buduj pod model i produkt, który realnie wykonuje pracę. Chcemy być na tyle wyrafinowani, by odróżnić Fable 5 od ChatGPT 5.6. Kto dużo korzysta z AI, ten rozumie, że Fable 5 w Claude.ai nie ma tego samego harnessu co Fable 5 w Claude Code czy przez API. ChatGPT 5.6 w ChatGPT Work to nie to samo co w Codeksie i nie wystawia tych samych kontroli co przez API.
(Informacja dodatkowa: „Claude Code” to narzędzie CLI dla programistów, a „Codex” to środowisko kodowania OpenAI — autor pokazuje, że ten sam model zachowuje się różnie w zależności od otaczającego go produktu.)
Model ma znaczenie, ale to produkt wokół niego decyduje, jak ładują się skille, jakie narzędzia istnieją, co można sprawdzić i jaki dowód wraca. Jakich faktów potrzebuje model? Co wolno mu zrobić? Co musi być prawdą, zanim praca zostanie uznana za skończoną? Jaki jest nasz efekt ewaluacyjny? Te podstawowe reguły nie zmieniają się tylko dlatego, że przeszedłem z Claude na ChatGPT — bo wartość samej pracy jest ta sama. Testujemy tę samą pracę w obu harnessach.
Kompaktowa konfiguracja przeszła każde wymaganie dostarczenia trzy razy na trzy — dostarczyła to, czego trzeba, bo była dopasowana do Fable. Bogatsze skille, cięższy harness, dawały bogatszą analizę, ale Fable nie potrafiło zmieścić się w moich ograniczeniach na output.
Czego to uczy o tym, jak działa Fable? Dajesz mu realny wynik, dajesz kontekst, którego nie może wywnioskować, dajesz mu przestrzeń, by zbadał problem, i pozwalasz mu użytecznie zaplanować własne podejście. A potem wprowadzasz materiał specjalistyczny, gdy praca dojdzie do tej fazy — cleaner pomaga wywołać go we właściwym momencie, albo pozwalasz zrobić to samemu Fable. Zawiodło natomiast opowiadanie całej metody w wielkim, grubym pliku skilla, zanim Fable w ogóle zobaczyło zadanie, i oczekiwanie, że ta cała prozą pisana instrukcja wyegzekwuje wymagania dotyczące JSON i liczby słów. To po prostu nie zadziała dobrze, nawet jeśli Fable świetnie stosuje się do reguł.
To nie jest głodzenie Fable kontekstem. Pełna metoda pomogła mu zauważyć więcej rzeczy — ale głębia powinna przychodzić, gdy praca jej potrzebuje, a nie cała z góry, w sposób, który dezorientuje model.
Wyniki audytu
A oto wyniki audytu: 66 korzeni skilli i 172 zasoby instrukcyjne. 27 000 znaków opisów przy budżecie „Codex Discovery” na 8 000 znaków. To duży problem, bo oznacza, że Codex nie jest w stanie tego przeczytać. Była trasa/skill o zawartości 18 000 słów z minimalnym „fan-in” — czyli skill prowadzący do innych skilli, ważący 18 000 słów.
Zarządzanie proweniencją — czyli sposób obsługi źródeł — było rozproszone po 15 różnych skillach. I tylko sześć z 66 korzeni skilli miało wykrytą lokalną ewaluację. Miałem evale na sześciu, ale nie na pozostałych 60, i musiałem to poprawić. Chodzi o spójność z Codeksem: schematy, ograniczenia narzędzi, kontrole plików i „run receipt” muszą nieść dokładnie te same wymagania od skilla do skilla, by Codex mógł działać bardzo konsekwentnie.
(Informacja dodatkowa: „receipt” to zapis wykonania — rejestr modelu, ustawienia rozumowania, użytych narzędzi, skilli, fallbacków i kontroli, które się uruchomiły; działa jak diagnostyka silnika.)
Sprzątanie po stronie Codeksa/ChatGPT to nie jest po prostu „skróć prompt”. To: uczyń właściwą trasę do skilla łatwą do odnalezienia, a potem doładuj głębię we właściwym punkcie. Receipt zapisuje model, ustawienie rozumowania, narzędzia, skille, fallbacki i kontrole, które się uruchomiły — dzięki temu z czasem widzisz, gdzie są problemy.
Dwa modele, dwa tryby awarii
Gdy porównamy oba modele: tryb awarii Fable pojawił się, gdy metoda stała się zbyt ciężka dla zadania dostarczenia. Tryb awarii ChatGPT 5.6 w Codeksie pojawił się dużo wcześniej — gdy system wciąż próbował w ogóle znaleźć właściwą metodę, mając trudność z routingiem w obrębie naprawdę ogromnej warstwy harnessu.
Oba modele korzystają na selektywnym ładowaniu i oba korzystają na twardych kontrolach, ale z zupełnie różnych bezpośrednich powodów, i wynika to z tego, jak te modele działają. Fable 5 przekopujące się przez masę kontekstu, próbujące wymyślić najlepsze podejście i przeciążające się — to charakterystyczny dla Fable 5 sposób na porażkę.
Harnessy obrastają w pąkle jak statki
Ostatecznie chcę systemu, który pomaga nam dobrze pracować. Chcę, by harnessy ewoluowały i pozostawały czyste, a nie zbierały pąkli w postaci dodatkowych punktowych rozwiązań, dodatkowych plików, przypadkowych skilli znalezionych w internecie, bo trafiłem na jakiś tweet, dorzuciłem je i teraz nie wiem, co robię, bo ChatGPT jest przeciążony albo Fable 5 dostało za grubego skilla. Chcę czystego harnessu, który pozwala mi efektywnie wykonywać pracę. Dlatego zbudowałem cleaner.
I to ma znaczenie. Jeśli jesteś product managerem, oznacza to czystą, prostą notatkę, która ładuje właściwe skille od PRD we właściwym czasie. Jeśli jesteś programistą, oznacza to jedno źródło prawdy zamiast kilku plików instrukcji kłócących się o to, jak działa repozytorium. A jeśli po prostu używasz ChatGPT albo Claude w domu czy w pracy, oznacza to, że twoje stare wspomnienia, pliki projektu, przykłady i poprawki przestają po cichu kształtować odpowiedzi w sposób, którego nie zamierzałeś.
Mogłeś dać Claude czy ChatGPT poprawkę pół roku temu, o której model wciąż pamięta i nadmiernie ją teraz stosuje przy nowym modelu. Na przykład: kilka miesięcy temu powiedziałeś mu „musisz pokazywać mi krok po kroku, bo w listopadzie to było naprawdę ważne”. Ale teraz już tego nie potrzebujesz, bo modele są dobre. Właśnie takie rzeczy cleaner wychwytuje.
Podsumowanie
Cel jest prosty: twoje AI powinno stać się łatwiejsze w użyciu do sensownej pracy, bo system wokół niego powinien stać się łatwiejszy do zrozumienia. Gdy już zobaczysz ten system, możesz go faktycznie posiadać. Widzisz, które kontrole cię chronią, które potrzebują jednego domu, które powinny pojawiać się później w procesie, a które powinny stać się prawdziwymi zamkami, a nie tylko uprzejmymi przypomnieniami.
Pełnego cleanera wrzuciłem na Substacka. Instalujesz go raz, wskazujesz na wybraną konfigurację lub projekt AI i pozwalasz, by pokazał wszystko, co się nazbierało. Daje mapę harnessu i decyzje czyszczące, daje „przed i po” prostym językiem oraz receipt pokazujący, co się uruchomiło, gdy pozwolisz mu wykonać te poprawki. Zmiany możesz przejrzeć, zanim cokolwiek ważnego się ruszy — nie chcę, żeby cokolwiek cię zaskoczyło.
Mam przeczucie, że wielu z nas odkryje, że zbudowaliśmy dużo więcej, niż nam się wydawało. Ja na pewno tak. Będę dalej drążył te nowe modele i aktualizował cleanera. Dajcie znać w komentarzach, jak wam działa i pod jakie inne modele mam go zoptymalizować — bo poza Claude i ChatGPT jest mnóstwo innych. W piątek pokażę wam, co zbudowałem moim nowym, ulepszonym harnessem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zmapuj harness, zanim zaczniesz go czyścić
Na czym polega: Zanim cokolwiek usuniesz, wypisz wszystkie elementy owijające model — instrukcje, skille, pamięć, pliki projektu, uprawnienia, kontrole — w jednej tabeli, gdzie każdy element ma osobny wiersz.
Jak stosować: Dla każdej kontroli odpowiedz na pytania: gdzie żyje, kiedy się ładuje, jaką funkcję pełni, kto jest właścicielem, czy są dowody, że wciąż pomaga, i jaki problem może stworzyć. Dopiero taki widok całości pozwala podejmować decyzje.
Na co uważać: Nie usuwaj niczego „na oko” na podstawie długości. Bez mapy nie odróżnisz reguły chroniącej pracę od przypadkowego duplikatu.
2.Rozróżniaj tekst od prawdziwych „zamków”
Na czym polega: Część harnessu to tylko tekstowe prośby, a część to twarde mechanizmy — uprawnienia, schematy, testy — które faktycznie potrafią coś zablokować lub odrzucić.
Jak stosować: Wymagania, które da się sprowadzić do odpowiedzi tak/nie (limit słów, poprawny JSON, dozwolone narzędzie), przenieś ze zwykłej instrukcji do schematu lub kontroli, którą system może wyegzekwować automatycznie.
Na co uważać: Dla AI wszystko wygląda jak tekst, dopóki tego nie rozdzielisz. „Uprzejme przypomnienie” w prompcie nie ma mocy realnego zamka — nie polegaj na nim przy twardych wymaganiach.
3.Obwiniaj właściwą warstwę: model czy harness
Na czym polega: Gdy wynik jest zły, domyślnie obwiniamy model i dokładamy kolejną regułę — a często to właśnie nadmiar reguł jest przyczyną awarii.
Jak stosować: Przy każdym błędzie zadaj pytanie: czy zawiódł model, czy otaczająca go konfiguracja? Przetestuj to samo zadanie w wersji kompaktowej i rozbudowanej, żeby zobaczyć, która warstwa faktycznie zawodzi.
Na co uważać: Dokładanie instrukcji, by naprawić problem stworzony przez instrukcje, prowadzi do spirali balastu. Nie zakładaj z góry, że winny jest model.
4.Jedna reguła, jeden dom, jeden właściciel
Na czym polega: Ta sama reguła powielona w wielu plikach zaczyna dryfować — poprawiasz jedną kopię, reszta zostaje nieaktualna, a model dostaje kilka sprzecznych wersji prawdy.
Jak stosować: Dla każdej reguły ustal jedno miejsce, w którym mieszka, i jedną osobę/proces odpowiedzialny za jej aktualizację. Skonsoliduj duplikaty do jednego źródła prawdy.
Na co uważać: Wielokrotne kopiowanie reguły to sygnał, że nigdy nie zadziałała jak trzeba — zamiast dokładać kolejną wersję, napraw jedną i usuń resztę.
5.Ładuj specjalistyczną wiedzę dopiero wtedy, gdy praca jej potrzebuje
Na czym polega: Wczytywanie wszystkich przewodników i skilli na starcie zaśmieca kontekst i pogarsza wyniki — research cierpi, bo model myśli jednocześnie o rzeczach z innej fazy pracy.
Jak stosować: Zachowaj pełną bibliotekę, ale zmień moment, w którym każda jej część się aktywuje. Wprowadzaj materiał specjalistyczny dopiero, gdy praca wejdzie w odpowiednią fazę.
Na co uważać: To nie jest wyścig o najkrótszy prompt ani wyrzucanie użytecznego kontekstu — duża biblioteka jest w porządku, problemem jest tylko ładowanie wszystkiego naraz z góry.
6.Twarde wymagania potrzebują twardych kontroli
Na czym polega: Wymagania mierzalne (limit słów, format JSON) egzekwowane prozą w prompcie zawodzą nawet przy modelach dobrze stosujących się do reguł.
Jak stosować: Zamień takie wymagania na schemat lub test, względem którego wynik jest weryfikowany maszynowo. To jednocześnie odchudza harness i czyni go bezpieczniejszym.
Na co uważać: Nie myl poglądu, z którym model ma się zmierzyć, z twardym warunkiem odbioru — tylko ten drugi nadaje się na schemat.
7.Buduj pod konkretny model i produkt, nie pod „AI w ogóle”
Na czym polega: Ten sam model zachowuje się różnie w zależności od produktu (Claude.ai vs Claude Code vs API; ChatGPT Work vs Codex vs API), bo produkt decyduje, jak ładują się skille i co da się sprawdzić.
Jak stosować: Utrzymaj stałe „reguły rdzenia” (jakie fakty, co wolno, co musi być prawdą, jaki eval), ale dostosuj sposób ładowania i egzekwowania do konkretnego produktu i modelu, w którym pracujesz.
Na co uważać: Fable 5 lubi przeciążać się nadmiarem kontekstu; ChatGPT 5.6 w Codeksie potyka się o routing w wielkim harnessie. Oba korzystają na selektywnym ładowaniu, ale z różnych powodów — nie stosuj jednej recepty w ciemno.
8.Wychwytuj przestarzałe poprawki i pamięć
Na czym polega: Poprawki dane modelowi miesiące temu (np. „zawsze pokazuj krok po kroku”) mogą być nadmiernie stosowane przy nowszym, lepszym modelu i po cichu psuć odpowiedzi.
Jak stosować: Okresowo przeglądaj pamięć, pliki projektu i stare korekty pod kątem tego, czy nadal są potrzebne przy obecnym modelu. To, co miało sens „w listopadzie”, dziś może być zbędne.
Na co uważać: Te reguły działają niewidocznie — nie zobaczysz ich, dopóki świadomie nie przejrzysz pamięci. Zakładaj, że część twoich starych korekt już szkodzi.
9.Dawaj Fable wynik i przestrzeń, nie całą metodę z góry
Na czym polega: Fable radzi sobie najlepiej, gdy dostaje realny cel, kontekst nie do wywnioskowania, przestrzeń na zbadanie problemu i swobodę zaplanowania podejścia — a nie pełną narrację metody przed zobaczeniem zadania.
Jak stosować: Zacznij od kompaktowego promptu z celem, faktami, granicą uprawnień i linią mety; głębię (metoda, punktacja, klasyfikacja) doładowuj dopiero w fazie, gdy jest potrzebna.
Na co uważać: Grubszy skill daje bogatszą analizę, ale potrafi rozwalić twarde ograniczenia outputu. Bogatszy ≠ lepszy, jeśli nie dowozi wymagań dostarczenia.
10.Traktuj harness jak kadłub obrastający pąklami — sprzątaj cyklicznie
Na czym polega: Harness rośnie przypadkiem, jedna korekta na raz, i z czasem obrasta „pąklami”: przypadkowymi skillami z internetu, dodatkowymi plikami, punktowymi łatami.
Jak stosować: Uczyń czyszczenie regularnym procesem, a nie jednorazowym. Autor udostępnia gotowy „cleaner” na Substacku — można go wskazać na własną konfigurację, dostać mapę, decyzje „przed i po” oraz receipt, i przejrzeć zmiany przed ich zastosowaniem.
Na co uważać: Modele będą się zmieniać dalej, a harness nie przebuduje się sam. Zawsze przeglądaj proponowane zmiany przed zatwierdzeniem — czyszczenie ma odsłaniać, a nie zaskakiwać.