O czym jest ten film
- Boris Cherny, twórca Claude Code, poradził publicznie, żeby co pół roku kasować całą swoją warstwę AI: CLAUDE.md, skille, hooki.
- Autor pokazuje, że wyrwane z kontekstu zdanie jest źle rozumiane — chodzi o ablację, a nie o trwałe wyrzucenie wszystkiego.
- Ablacja to usunięcie całego promptu systemowego i dokładanie go z powrotem linia po linii, żeby zmierzyć realny wpływ każdego fragmentu.
- Druga rada Borisa: przestać pisać instrukcje krok po kroku, a zamiast tego opisywać zadanie, bariery i kryteria zakończenia.
- Główny zarzut autora: ablacja jest bardzo kosztowna tokenowo i nierealna dla kogoś, kto płaci za tokeny lub uderza w limity subskrypcji.
- Autor zarzuca Borisowi „bańkę nielimitowanego budżetu” — przykład agenta migrującego kod z Electrona do Swifta, działającego ponad dwa tygodnie.
- Propozycja autora: spektrum warstwy AI — reguły, skille/workflow, subagenci — i przycinanie przede wszystkim reguł globalnych.
- Dokumentacja Anthropic potwierdza: przesadnie rozbudowany CLAUDE.md szkodzi, celuj poniżej 200 linii.
- Test na własnym kodzie (Archon, CLAUDE.md na tysiąc linii): po ablacji jakość decyzji architektonicznych się utrzymała, ale zgodność z konwencjami projektu się posypała.
- Wniosek i narzędzie: reguły naprawiające rozumowanie się zdezaktualizowały, reguły kierujące uwagą i personalizujące — nie; autor udostępnia skill prowadzący przez proces ablacji.
Redakcyjne tłumaczenie
Znowu słyszymy, że nasza praca jest przestarzała
Oboje wiemy, że świat AI porusza się za szybko. Zawsze jest jakaś kolejna rzecz, której podobno trzeba się nauczyć — loop engineering, graph engineering. A jeszcze gorsze jest to, że regularnie słyszymy, iż to, co już mamy, jest przestarzałe i powinniśmy się tego pozbyć jak najszybciej.
Boris Cherny, twórca Claude Code, powiedział ostatnio rzeczy, które sprawiają wrażenie, że znowu w to wchodzimy. W niedawnym wywiadzie stwierdził: „Co sześć miesięcy powinniśmy kasować całą naszą warstwę AI — globalne reguły, skille, hooki, wszystko, nad czym ciężko pracowaliśmy — bo zdziwilibyście się, do czego LLM jest zdolny bez waszych wskazówek”.
Brane dosłownie brzmi to tak, jakby Boris patrzył na nas z góry: twoja warstwa AI, którą budowałeś z takim wysiłkiem, jest już bezużyteczna, bo Opus 5 jest po prostu aż tak dobry. Tylko że nie do końca o to mu chodzi. Jest tu znacznie więcej niuansów, a mnóstwo osób błędnie go interpretuje, bo czyta jednego tweeta i idzie dalej.
Chcę więc omówić z tobą, co Boris naprawdę ma na myśli — bo w jego słowach jest sporo prawdy i dobrych sugestii, ale mam też kilka punktów spornych. Rozłożę to na czynniki pierwsze, a przy okazji podam rzeczy, które radzę zrobić od razu.
Co dokładnie powiedział Boris
Zacznijmy od momentu, który zrobił największe wrażenie. Fragment z wydarzenia na żywo w Y Combinatorze:
— Sto procent. A dla osób, które nie budują produktów agentowych, tylko używają Claude Code: co sześć miesięcy skasujcie swój CLAUDE.md, skasujcie skille, skasujcie hooki i zobaczcie, co zrobi model. Może was zaskoczyć. A przy Opusie 5 to jest coś, co naprawdę rekomendujemy — po prostu spróbujcie to wszystko usunąć, bo model może zwyczajnie nie potrzebować instrukcji, których potrzebowały poprzednie modele.
Same te kilka zdań rzeczywiście brzmi jak: „Opus jest za dobry dla ciebie, skasuj wszystkie swoje instrukcje”. Ale minutę wcześniej pada coś znacznie łagodniejszego. Oni nie kasują wszystkiego bezpowrotnie — przeprowadzają proces zwany ablacją:
— Zgadza się. Żeby być uczciwym: nie kasujemy całej bazy kodu, ale kasujemy dużo. Za każdym razem, gdy pojawia się nowy model, robimy coś, co w badaniach nazywa się ablacją. Polega to na tym, że kasujesz cały prompt systemowy, a potem przywracasz go linia po linii, żeby ustalić, jaki wpływ ma każda pojedyncza linia. To rodzaj ewaluacji — tyle że kasujesz elementy, żeby zmierzyć ich wpływ.
(Informacja dodatkowa: ablacja to termin zapożyczony z badań nad sieciami neuronowymi — usuwa się pojedynczy komponent systemu i mierzy spadek jakości, żeby ustalić, za co ten komponent faktycznie odpowiadał).
I tu mamy prawdziwy sens tej rady. Nie wycieramy wszystkiego i nie oddajemy się na łaskę modelu — robimy to po to, żeby rzetelnie ocenić, czego naprawdę potrzebujemy w naszej warstwie AI. Przywracamy elementy w miarę jak stwierdzamy: „aha, ten skill albo ta reguła faktycznie poprawiły wyniki”, nawet przy najnowszym i najlepszym modelu.
Ogólna teza Borisa ma sens. Im lepsze są LLM-y, tym mniej trzeba doprecyzowywać w regułach i barierach ochronnych, żeby efekt spełniał nasze standardy. W twoim harnessie może więc siedzieć sporo rzeczy, które modelowi bardziej szkodzą niż pomagają, bo go ograniczają.
Przestań pisać instrukcje krok po kroku
Boris mówi o tym jeszcze wprost:
— Bardzo częsty błąd, który widzę: ludzie używają Claude Code, używają Claude’a i dają mu skrajnie szczegółowe instrukcje. „Chcę, żebyś zrobił to, chcę, żebyś zrobił to w ten sposób, w ten i w ten. Masz zrobić najpierw jeden, potem dwa, potem trzy, potem cztery”. Przy nowoczesnych modelach to naprawdę nie jest właściwa droga. Chcesz operować nieco wyżej. Chcesz opisać zadanie, opisać bariery ochronne, opisać kryteria zakończenia — a potem pozwolić modelowi działać.
Ablacja jest więc dla nich procesem ustalania, gdzie byli zbyt szczegółowi wobec współczesnego modelu. Tyle że robią to od tyłu: zaczynają od zera i dokładają elementy w miarę odkrywania, że agent kodujący naprawdę tej wskazówki potrzebuje — nawet jeśli to Fable, Opus czy GPT Soul, cokolwiek akurat jest topowym modelem.
Gdzie się z tym nie zgadzam: to kosztuje
W teorii jest dobrze, ale mam z tym dwa problemy. Po pierwsze, ten proces jest bardzo, bardzo drogi. Po drugie, są rzeczy, których po prostu nie ma sensu wyrzucać i przywracać.
Największy problem: nie zawsze da się realnie wyczyścić całą warstwę AI i odbudować ją od zera. To jest skrajnie tokenożerne. Kasowanie wszystkiego, a potem dokładanie kawałek po kawałku przy jednoczesnym testowaniu i pracy z agentem, kosztuje ogromnie dużo.
Właściwie wiele rzeczy, o których Boris mówi na tym wydarzeniu, boleśnie pokazuje, że jest ślepy na fakt, iż tokeny są drogie. Widać, że pracuje w Anthropic, gdzie dostaje nielimitowany budżet tokenów — bo mnóstwo jego strategii sprowadza się do puszczenia agenta na bardzo, bardzo długo. A to nie zawsze jest praktyczne: albo jesteś w firmie, która płaci za token, albo masz subskrypcję i regularnie uderzasz w limity przy Fable i Opusie. Kiedy opowiada o sesjach trwających dwa tygodnie, momentami wygląda to na własną bańkę nieskończonych tokenów — jego i Petera Steinbergera.
Wiem, że trochę już mielę ten temat, ale ten fragment jest po prostu zabawny. Boris właśnie opowiedział, jak zmigrował całą bazę kodu z Electrona do Swifta, i pada pytanie:
— A jak długo to się liczyło? — Wciąż się liczy. — Kiedy to uruchomiłeś? [śmiech] — Trochę ponad dwa tygodnie. — Trochę ponad dwa tygodnie. [śmiech] — Tak. To muszą być miliony tokenów.
Tego nie da się powtórzyć nawet z subskrypcją Claude Max — chyba że mieszasz Sonnet z Haiku, a on mówi o Opusie 5.
(Informacja dodatkowa: w tym miejscu w oryginale znajduje się blok sponsorski poświęcony narzędziu Code Rabbit i jego nowemu widokowi przeglądu kodu „Change Stack”, który grupuje pliki z pull requesta w spójne warstwy zamiast alfabetycznej listy. Pominięto go jako materiał reklamowy).
Spektrum warstwy AI
Sedno sprawy: tak, twoja warstwa AI jest prawdopodobnie zbyt rozdęta i prawdopodobnie w części rzeczy jesteś zbyt szczegółowy jak na dzisiejsze modele. Ale wycinanie wszystkiego nie jest realistyczne i moim zdaniem nie powinieneś tego robić. Zajmie ci to mnóstwo czasu, będzie bardzo drogie, a w warstwie AI jest sporo elementów, które nawet lekko rozdęte naprawdę nie szkodzą wydajności agenta.
Warstwa AI składa się z trzech komponentów, które karmią kontekst agenta:
- reguły — globalne reguły i inne konteksty, które agent czyta albo które mu wstrzykujemy,
- skille i workflow,
- subagenci — pracownicy, którym delegujemy zadania.
Z tego wszystkiego naprawdę tylko reguły trzeba ciąć ostro. To kontekst — zwłaszcza reguły globalne — ładowany na starcie każdej rozmowy. Tu jest największe ryzyko przespecyfikowania i skrępowania modelu, bo tych wytycznych musi trzymać się zawsze.
Anthropic dużo o tym pisze w dokumentacji Claude Code i jest to dobra rada niezależnie od tego, jakiego agenta używasz. W sekcji o typowych błędach do uniknięcia jednym z głównych punktów jest przespecyfikowany CLAUDE.md: jeśli twoje globalne reguły są za długie, Claude ignoruje ich połowę, bo ważne reguły giną w szumie — i to realnie pogarsza wyniki. W części o pamięci i pisaniu skutecznych instrukcji pada konkret: celuj poniżej 200 linii na plik CLAUDE.md.
Globalne reguły muszą być zwięzłe, bo nasze spektrum biegnie od tego, co jest wrzucane agentowi za każdym razem, po rzeczy kontekstowo oszczędne — takie, które nie zajmują nieustannie jego przepustowości uwagi.
To spektrum wyznacza też, w jakim stopniu zgadzam się z Borisem. Przy regułach presja na przycinanie jest duża, trzeba je trzymać szczupłe i zgadzam się, że dość często warto przetestować mocno skurczoną wersję. Ale im wyżej na spektrum — skille i inny kontekst wczytywany na żądanie, który agent czyta tylko czasem — tym mniej istotne staje się przepychanie ich przez proces skracania. A jeśli skupisz się głównie na globalnych regułach, ablacja przestaje być bolesna i kosztowna.
Idee Borisa są zdrowe. Po prostu nie sądzę, że stosują się do tak szerokiego zakresu, jak on sugeruje. Subagenci, skille, inny kontekst na żądanie w Markdownie czy na stronach Confluence — tego prawie nie ruszam. Doprowadzam do działania na starcie i zostaję z tym przez kolejne premiery modeli. Ale przy globalnych regułach — tu przyznaję mu rację, tu trzeba być wybrednym.
W idealnym świecie, z nieograniczonym czasem i budżetem, jaki najwyraźniej ma Boris, oczywiście warto ablować całą warstwę AI, bo każdy model interpretuje instrukcje choćby minimalnie inaczej i zawsze będzie miejsce na optymalizację, a nawet na budowę od zera. Tylko w realnym świecie musimy gdzieś postawić granicę: gdzie to się opłaca pod względem czasu i tokenów, co ablować.
Mój argument brzmi: trzymajmy się raczej tej strony spektrum. A jeśli naprawdę chcesz to rozciągnąć na skille i subagentów, rób to od święta — na przykład raz w roku. Nie polecałbym tego przy każdej premierze modelu, a co pół roku, jak mówi Boris, wydaje mi się nieco zbyt agresywne.
Test na własnym kodzie: Archon
Obiecałem też pokazać własne testy, bo one dobrze pokazują, jakich reguł potrzebujemy niezależnie od wszystkiego, a jakich możemy się pozbyć wraz z rosnącymi możliwościami modeli. Ogołocona, ablowana warstwa AI wybroniła się w części zastosowań — Boris ma do pewnego stopnia rację. Ale są typy reguł, po których usunięciu wyniki gwałtownie spadły.
Testowałem na Archonie, moim open source’owym buildarze harnessów. To dojrzała, mocno rozwinięta aplikacja — chciałem po prostu wybrać odpowiednio skomplikowaną bazę kodu. Trochę wstyd się do tego przyznawać przed kamerą, ale nasz globalny plik reguł do pracy nad Archonem ma tysiąc linii. Tak, zgodnie z tym, co pisze Anthropic — powinno być około 200 albo mniej — to zdecydowanie za długo.
Muszę jednak dodać, że próbowaliśmy to już przycinać w czasach Opusa 4.5 czy 4.7 i wyniki wychodziły gorsze. Wycinaliśmy różne nasze konwencje i było widać różnicę. Ale teraz, gdy mamy Fable 5, Opusa 5 i GPT 5.6 Soul, czyli następną generację modeli, wiem, że tak długie reguły nie są już potrzebne.
Zrobiłem więc test: wziąłem CLAUDE.md i sprowadziłem go do pełnej ablacji — kilka komend, odrobina kontekstu o tym, czym jest Archon, i tyle. Potem porównałem pracę nad zestawem różnych zgłoszeń z GitHuba: raz na naszych rozdętych obecnych regułach, raz na tej okrojonej wersji.
Mam też skill, który ogólnie uczy, jak używać Archona — jak uruchamiać komendy i tym podobne. Ten skill ma jakieś 350 linii i jego również ablowałem: usunąłem go w całości, żeby model musiał wywnioskować sposób użycia Archona wyłącznie z samej bazy kodu. Byłem przekonany, że Claude Code polegnie na tej wersji warstwy AI.
Tymczasem w połowie testów obie warstwy wypadły tak samo dobrze. Dla mnie było to szokujące. Testy dzieliły się na dwie kategorie: na ile agent potrafi podejmować trudne decyzje architektoniczne w naszej bazie kodu i na ile potrafi trzymać się konwencji specyficznych dla naszego projektu.
Pełna warstwa AI wybroniła się w obu kategoriach — to była nasza linia bazowa jakości. Wersja ogołocona, czyli mniej więcej dwudziestolinijkowy CLAUDE.md i żadnego skilla o Archonie, wypadła tak:
- Trudne decyzje architektoniczne — bez zmian. Agent projektował nowe funkcje w naszej bazie kodu równie dobrze jak przy pełnym CLAUDE.md.
- Zgodność z konwencjami projektu — porażka. Tu się posypało: jak rejestrujemy testy, jak chcemy pisać funkcje, jaki styl, jak importujemy rzeczy.
Wniosek jest taki: im lepszy staje się model, tym mniej trzeba go prowadzić za rękę, żeby dobrze pracował jako inżynier oprogramowania. Bardzo wiele reguł, które kiedyś pisaliśmy, łatało po prostu braki modeli, a nie uczyło ich czegoś o naszej bazie kodu. Ale reguły typu „u nas pracuje się tak” nadal mają znaczenie. Nie da się w pełni ablować warstwy AI, bo bardzo dużo w niej uczy agenta dopasowania do ciebie. Nie musisz go uczyć, jak wykonać dobrą robotę w ogóle — musisz go nauczyć, jak wykonać dobrą robotę według twoich konkretnych standardów.
Rekomendacja końcowa
Tak, warto przejść przez ablację. Tylko nie musisz przerabiać wszystkiego, jak sugeruje Boris. Zacznij od reguł — tam jest cały nisko wiszący owoc, więc nie przepalisz czasu ani tokenów, a szybko wyłapiesz elementy, które tylko wpajały modelowi ogólne dobre praktyki i łatały jego braki, w odróżnieniu od tych, które faktycznie uczą pracy nad twoim konkretnym projektem. Te pierwsze usuń — najpewniej nigdy nie będziesz musiał ich przywracać.
Oczywiście nawet rzeczy specyficzne dla ciebie agent czasem sam wychwytuje, pracując w bazie kodu, więc pole do testowania ablacją jest większe. Ja mówię raczej o tym, co jest nisko wiszącym owocem, co warto robić co jakiś czas, a co robić bardzo rzadko albo wcale.
Ujmijmy to tak: reguły naprawiające rozumowanie straciły ważność, bo modele nauczyły się rozumować wystarczająco dobrze. Ale reguły, które kierują uwagą i personalizują pracę, są równie ważne jak wcześniej.
Skill do przeprowadzenia ablacji
Na koniec zbudowałem skilla dla Claude’a, który przeprowadza cię przez ten sam proces ablacji, który sam wykonałem po obejrzeniu wystąpienia Borisa. Mógłbym poświęcić mu cały osobny odcinek i może to zrobię, więc nie będę tu omawiał każdego szczegółu.
W skrócie: po wywołaniu — i możesz to zrobić w zasadzie z dowolnym agentem kodującym — skill najpierw identyfikuje twoją warstwę AI, czyli wypisuje twoje skille, hooki, reguły i subagentów. Następnie układa zadania, które można uruchomić na twojej bazie kodu i przetestować zarówno z pełną warstwą AI, jak i bez niej. Odpala te same zadania równolegle w obu wariantach, a na końcu ocenia wyniki i daje ci raport: na ile twoja warstwa AI i każdy jej element faktycznie pomagają ci w codziennej pracy.
Nie testowałem tego przez setki godzin, więc nie wiem, jak dobrze uogólni się na każdą bazę kodu. Chciałem po prostu dać ci narzędzie pozwalające od razu zastosować to, co tu omawiam — bo jakaś forma ablacji zdecydowanie jest warta robienia co jakiś czas. Pytanie brzmi raczej: jak dużą część warstwy AI ablować i ile czasu naprawdę temu poświęcić.
Skill możesz zainstalować — wystawiłem właśnie nowe repozytorium ze skillami na GitHubie, z instrukcją instalacji całego pluginu; skill do ablacji jest jednym z nich. Link znajdziesz w opisie.
To wszystko: co mówi Boris, jak należy to interpretować i co naprawdę myślę o tych strategiach. Zdecydowanie warto zwrócić na to uwagę i stosować — do pewnego stopnia.
10 najważniejszych takeaways — z kontekstem zastosowania
1.„Kasuj wszystko co pół roku” to skrót myślowy — chodzi o ablację
Na czym polega: Boris Cherny nie namawia do trwałego wyrzucenia warstwy AI, tylko do procedury badawczej: usuwasz cały prompt systemowy, a potem dokładasz go z powrotem linia po linii i mierzysz wpływ każdego fragmentu.
Jak stosować: Traktuj usunięcie jako punkt startowy eksperymentu, nie jako decyzję końcową. Zrób kopię obecnej warstwy AI, pracuj na okrojonej wersji i przywracaj tylko te elementy, po których widzisz realną poprawę.
Na co uważać: Bez kopii zapasowej i bez z góry ustalonego zestawu zadań testowych ablacja zmienia się w kasowanie na wyczucie. Wtedy przywrócisz to, co pamiętasz, a nie to, co działa.
2.Tnij ostro globalne reguły, nie całą warstwę AI
Na czym polega: Warstwa AI ma trzy komponenty — reguły, skille/workflow, subagentów. Tylko reguły globalne ładują się na starcie każdej rozmowy, więc tylko one obciążają uwagę modelu nieustannie.
Jak stosować: Ograniczaj ablację do plików reguł globalnych. Skille i subagentów, raz doprowadzonych do działania, zostaw przez kolejne premiery modeli; ewentualnie przejrzyj je raz w roku.
Na co uważać: Rozdęty skill wczytywany raz na dziesięć sesji kosztuje niewiele — nie warto przepalać na niego dni pracy. Odwrotnie: rozdęty CLAUDE.md kosztuje przy każdym zapytaniu.
3.Reguły naprawiające rozumowanie się zdezaktualizowały, reguły konwencji nie
Na czym polega: To główny wniosek z testu na Archonie. Instrukcje, które kiedyś łatały braki modeli w inżynierii oprogramowania, są dziś zbędne. Instrukcje mówiące „u nas robi się to tak” nadal są niezastąpione.
Jak stosować: Przejdź plik reguł i podziel każdy punkt na dwie kategorie: „uczy modelu ogólnego rzemiosła” i „uczy modelu naszego projektu”. Pierwszą kategorię usuwaj bez wahania — najpewniej nigdy jej nie przywrócisz.
Na co uważać: Granica bywa zamazana. Reguła typu „pisz testy” jest ogólna, ale „testy rejestrujemy w pliku X w taki sposób” jest już konwencją — ta druga zostaje.
4.Wynik testu: architektura się broni, konwencje się sypią
Na czym polega: Przy CLAUDE.md skróconym z tysiąca do ~20 linii i całkowicie usuniętym skillu projektowym agent projektował nowe funkcje równie dobrze jak z pełną warstwą, ale przestał trzymać się stylu, importów i sposobu rejestracji testów.
Jak stosować: Zaprojektuj swoje testy ablacyjne wokół tego samego podziału: osobno oceniaj trudne decyzje projektowe, osobno zgodność z konwencjami. Bez tego rozdziału uśredniony wynik nic ci nie powie.
Na co uważać: To wynik z jednej dojrzałej bazy kodu i jednej generacji modeli. Nie zakładaj, że twoja proporcja będzie identyczna — sprawdź na swoim projekcie.
5.Opisuj zadanie i kryteria zakończenia zamiast kroków 1–2–3–4
Na czym polega: Boris wskazuje drobiazgowe instrukcje krok po kroku jako najczęstszy błąd użytkowników. Współczesne modele lepiej reagują na opis zadania, barier ochronnych i warunków zakończenia.
Jak stosować: Przy najbliższym większym zadaniu napisz trzy rzeczy: co ma powstać, czego nie wolno ruszać oraz po czym poznamy, że skończone. Resztę zostaw modelowi.
Na co uważać: Rezygnacja z kroków nie oznacza rezygnacji z barier. Bez jasno postawionych granic i kryteriów zakończenia „pozwól modelowi działać” zmienia się w kosztowne błądzenie.
6.Rada Anthropic ma twardą liczbę: poniżej 200 linii na CLAUDE.md
Na czym polega: Dokumentacja Claude Code wprost wskazuje przespecyfikowany CLAUDE.md jako typowy błąd — przy zbyt długim pliku ważne reguły giną w szumie i model ignoruje ich część.
Jak stosować: Zmierz swój plik. Jeśli przekracza 200 linii, potraktuj ten limit jako cel i pierwszy kandydat do cięcia szukaj wśród reguł ogólnych (patrz punkt 3).
Na co uważać: Limit to heurystyka, nie próg awarii. Autor sam prowadzi plik na tysiąc linii i przyznaje, że wcześniejsze próby przycinania — przy starszych modelach — pogarszały wyniki. Zmienną jest generacja modelu.
7.Ablacja jest droga — licz to jako koszt, nie jako higienę
Na czym polega: Wyczyszczenie warstwy i dokładanie elementów przy jednoczesnym testowaniu pochłania ogromną liczbę tokenów. Autor uznaje to za główny powód, dla którego rada Borisa nie skaluje się na zwykłych użytkowników.
Jak stosować: Zanim zaczniesz, oszacuj budżet: ile zadań testowych, ile przebiegów, na jakim modelu. Jeśli budżet nie starcza na całość, zrób tylko reguły globalne — tam leży nisko wiszący owoc.
Na co uważać: Przy subskrypcji łatwo trafić w limity w środku serii testów, co unieważni porównywalność wyników. Rozplanuj przebiegi tak, aby oba warianty leciały w tych samych warunkach.
8.Odróżniaj rady od kogoś z nielimitowanym budżetem
Na czym polega: Autor zauważa, że wiele strategii Borisa opiera się na bardzo długim działaniu agenta — jak migracja z Electrona do Swifta, licząca się ponad dwa tygodnie na Opusie 5. To praktyka niedostępna przy płaceniu za tokeny.
Jak stosować: Przy każdej radzie od osób z wnętrza laboratoriów AI pytaj o ukryty koszt i przelicz go na swój plan. Część technik da się odtworzyć na tańszych modelach, część nie.
Na co uważać: To nie jest powód, by odrzucać całość — mechanizm bywa słuszny, nawet gdy skala jest nierealna. Szukaj okrojonej wersji techniki, nie wymówki, by jej nie stosować.
9.Ustal własną częstotliwość zamiast trzymać się „co sześć miesięcy”
Na czym polega: Autor uznaje półroczny cykl dla całej warstwy AI za zbyt agresywny. Jego propozycja: reguły globalne przeglądaj częściej, skille i subagentów rzadko — na przykład raz w roku.
Jak stosować: Powiąż przegląd reguł z premierami modeli, których faktycznie używasz, i ogranicz go do plików reguł. Resztę warstwy tykaj tylko wtedy, gdy widzisz konkretne problemy.
Na co uważać: Skrajność w drugą stronę też kosztuje — warstwa AI nietykana latami gromadzi reguły napisane pod modele, których już nie używasz.
10.Skill do ablacji jako punkt startu, nie jako wyrocznia
Na czym polega: Autor udostępnił w nowym repozytorium skilli na GitHubie skilla, który identyfikuje twoją warstwę AI, generuje zadania testowe, uruchamia je równolegle z pełną warstwą i bez niej, a na końcu wystawia raport z oceną poszczególnych elementów.
Jak stosować: Użyj go, by zdjąć z siebie żmudną część procesu — inwentaryzację warstwy i wymyślenie porównywalnych zadań. Wnioski merytoryczne i tak weryfikuj sam.
Na co uważać: Autor sam zaznacza, że nie testował go długo i nie wie, jak uogólnia się na dowolną bazę kodu. Traktuj raport jako materiał do decyzji, a nie jako podstawę do automatycznego kasowania reguł.