O czym jest ten film
- Zespół Anthropica wyciął ponad 80% promptu systemowego Claude Code dla modeli generacji Claude 5 (m.in. Opus 5, Sonnet 5 i 5.1) — i nie zanotował żadnego mierzalnego spadku na ewaluacjach.
- Artykuł o nowych zasadach inżynierii kontekstu wyjaśnia: reguły pisane dla starszych modeli zaczęły krępować nowe. Przykład: twardy limit komentarzy w kodzie zastąpiono zasadą „trzymaj się stylu otaczającego kodu”.
- Boris Cherny, twórca Claude Code, zaleca kasowanie wszystkich skillów co pół roku — modele rosną w siłę szybciej, niż starzeją się nasze instrukcje.
- Typowy mechanizm balastu: Claude popełni błąd → dodajesz regułę → reguła zawisa w CLAUDE.md albo w skillu na dobre, choć model dawno ją przerosł.
- Badanie z 2025 roku (pięć modeli, matematyka, pytania, kodowanie): im dłuższe wejście, tym gorsze wyniki — spadki od 13,9% do 85%, nawet gdy model potrafił odszukać potrzebne informacje.
- Pomiar Anthropica: definicje narzędzi MCP ładowane dopiero na żądanie dały 85% mniejsze zużycie tokenów i lepsze wyniki (Opus 4: 49% → 74%; Opus 4.5: 79,5% → 88,1%).
- Zasada nadrzędna: pracuj na najmniejszym kontekście, który daje pożądany efekt — ale „minimalny” nie znaczy „krótki”; szczegóły niezbędne do zadania zostają.
- Eksperyment autora: pełny, rozbudowany setup wygenerował ładniejszy dokument z brandingu, ale „goły” model zbudował lepszą strukturę przewodnika — nadmiar zabezpieczeń po prostu krępował model.
- Komenda /doctor audytuje lokalne środowisko: nieużywane skille, duplikaty (u autora ok. 2 250 znaków do wycięcia), zepsute nagłówki plików i pamięć z nieoczywistych źródeł — m.in. CLAUDE.md leżący na pulpicie, wart ok. 2 tys. tokenów.
- Audyt warsztatu YouTube wykrył brak pomostu między researchem a scenariuszem (plik sources.md tylko w 3 z 25 folderów) — autor zaleca regularne audyty, a docelowo ich automatyzację.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Najlepszy kontekst to najmniejszy, który daje zadany efekt
Na czym polega: Zespół Applied AI w Anthropiku zaleca pracę na minimalnym kontekście, jaki wystarcza do uzyskania pożądanego wyniku. Nadmiar informacji nie pomaga — spowalnia model, spowalnia jego myślenie i podraża rachunek za tokeny.
Jak stosować: Przejrzyj własne CLAUDE.md i skille z jednym pytaniem: „czy bez tej linijki wynik realnie się pogorszy?”. Reguły testuj pojedynczo — wytnij, porównaj rezultaty na kilku zadaniach, dopiero wtedy decyduj.
Na co uważać: „Minimalny” nie znaczy „krótki”. Jeśli model potrzebuje konkretnego szczegółu do wykonania pracy (np. wiedzy o grupie odbiorców), ten szczegół zostaje.
2.Reguły mają termin przydatności — sprzątaj po każdej zmianie modelu
Na czym polega: Anthropic usunął ponad 80% promptu systemowego bez spadku jakości, bo reguły pisane dla starszych modeli ograniczały nowsze. Boris Cherny, twórca Claude Code, radzi w ogóle kasować wszystkie skille co pół roku.
Jak stosować: Po każdej migracji na nowy model zrób przegląd instrukcji. Każdą regułę odtwórz do błędu, z którego się wzięła — jeśli taki błąd już się nie zdarza, reguła jest martwa.
Na co uważać: Nie wszystko jest przestarzałe. Zanim coś wytniesz, sprawdź, czy reguła nadal chroni przed realnym problemem (np. przed zmyślaniem faktów).
3.Definiuj „gotowe” i zostaw modelowi pole
Na czym polega: Zamiast krok po kroku dyktować procedurę, podaj wynik, powód i ograniczenia. Model dostaje cel, a ty przestajesz mikromenedżerować.
Jak stosować: W każdym zadaniu zapisz trzy rzeczy: co ma powstać, po co to komu, czego wolno robić, a czego nie. Resztę zostaw modelowi.
Na co uważać: „Pole do działania” nie oznacza braku granic — model musi jasno wiedzieć, co wypada poza zakres.
4.Zostaw to, czego model nie znajdzie sam; wytnij to, co może sprawdzić
Na czym polega: W kontekście mają zostać rzeczy nieodzyskiwalne: twój styl, cele, odbiorcy, specyfica biznesu. Rozbudowane listy folderów i ścieżek model odczyta z dysku, kiedy będzie potrzebował.
Jak stosować: Podziel instrukcje na dwie kupki: „wiedza o mnie i mojej firmie” oraz „rzeczy odpytywalne na miejscu”. Drugą skróć do minimum albo usuń.
Na co uważać: Nie zakładaj, że model domyśli się kontekstu biznesowego — tego nie wywnioskuje z internetu i to właśnie musi dostać od ciebie.
5.Ładuj instrukcje dopiero wtedy, gdy są potrzebne
Na czym polega: Test Anthropica: definicje narzędzi MCP ładowane na żądanie dały 85% mniejsze zużycie tokenów i lepsze wyniki ewaluacji. Zasada działa też dla procedur — instrukcje montażu wideo nie są potrzebne przy pisaniu scenariusza.
Jak stosować: Rozbij monolityczne skille i rozsuń kontekst na etapy: krótki opis zawsze, pełna procedura dopiero po wywołaniu.
Na co uważać: Model musi wiedzieć, że głębszy plik istnieje i kiedy po niego sięgnąć — zostaw krótkie wskazanie drogi do szczegółowych wytycznych.
6.Jedna reguła, jedno miejsce
Na czym polega: Ten sam zakaz powtórzony w kilku plikach to ukryty koszt i ryzyko. U autora audyt wykrył ok. 2 250 znaków duplikatów (ok. 563 tokenów), m.in. mapę projektu powtarzającą treść mapy routingu.
Jak stosować: Przeszukaj CLAUDE.md, skille i pamięć pod kątem powtarzających się sekcji i przenieś każdą zasadę do jednego miejsca, z którego model ma ją czerpać.
Na co uważać: Kopie z czasem się rozjeżdżają — model dostaje sprzeczne wersje i nie wiadomo, którą ma traktować poważnie.
7./doctor jako regularny przegląd zdrowia środowiska
Na czym polega: Komenda /doctor w Claude Code audytuje skille (liczba użyć, szacunkowy ciężar nagłówka), pamięć, pluginy, ustawienia i instalację — i wyłapuje rzeczy, o których się nie myśli. U autora: 18 nieużywanych skillów, dwa zepsute pliki i przypadkowy CLAUDE.md z pulpitu na ok. 2 tys. tokenów.
Jak stosować: Uruchom w nowej sesji, przejrzyj raport, pozwól narzędziu poprawić zepsute nagłówki plików, a listę nieużywanych pozycji potraktuj jako wskazówkę, nie wyrok.
Na co uważać: „Zero zarejestrowanych użyć” nie zawsze znaczy „nieużywany” — skill może być wołany z innego narzędzia. Sprawdź, zanim skasujesz.
8.Audytuj przepływ pracy, nie tylko pliki
Na czym polega: Warto patrzeć na to, jak praca przechodzi między etapami. Audyt autora wykrył, że research nie zostawiał śladu w pliku sources.md (miał go tylko 1 na 8 folderów z filmami), więc kolejny etap weryfikował fakty od zera.
Jak stosować: Poproś model o zmapowanie kroków i miejsc, w których praca jest przekazywana dalej, a potem o najmniejszą poprawkę właśnie w tych miejscach styku.
Na co uważać: Reguły weryfikacji faktów istnieją z powodu halucynacji — nie wywalaj ich bezmyślnie; zastępuj mechanizmem, w którym następny etap dostaje już sprawdzone źródła.
9.Pytaj o najmniejszą zmianę i zabroń edycji w pierwszym kroku
Na czym polega: Prompt w stylu „pokaż najmniejszą zmianę, wskaż konkretne pliki, jeszcze niczego nie edytuj” daje konkretną, sprawdzalną rekomendację i pełną kontrolę zamiast planu generalnej przebudowy.
Jak stosować: Trzymaj się tego schematu przy audytach własnych repozytoriów: najpierw propozycja z cytowanymi plikami, potem twoja decyzja.
Na co uważać: Mała zmiana może nosić ukryte założenia — otwórz wskazane pliki i sam zweryfikuj diagnozę, zanim zatwierdzisz.
10.Zrób z porządków rutynę, a potem je zautomatyzuj
Na czym polega: Rytm audytów: co miesiąc przy dynamicznie zmienianym setupie, co kwartał przy stabilnym, zawsze po zmianie modelu — każdy model czyta twoje instrukcje trochę inaczej. Docelowo audyty da się zaplanować jako zadanie w aplikacji desktop Claude i rano po prostu zatwierdzać rekomendacje.
Jak stosować: Ustaw zaplanowane zadanie z dostępem do tych samych plików i ustawień; rekomendacje odbieraj jako listy do zatwierdzenia lub odrzucenia.
Na co uważać: Automat nie zna twoich intencji — zostaw sobie decyzyjne „tak/nie”. Pomyśl też o zespole: lepszy jeden wspólny, dopięty system niż kilku ludzi budujących każdy swój osobny.
Redakcyjne tłumaczenie
Wycięli ponad 80% reguł — i nic nie stracili
Inżynierowie Anthropica przyspieszyli wszystkim Claude Code, usuwając ponad 80% jego promptu systemowego. Przy okazji wywrócili do góry nogami to, co wiedzieliśmy o promptowaniu. Wielu z nas słyszało bowiem, że najlepszym sposobem na posłusznego Claude’a jest wrzucenie do kontekstu jak najwięcej informacji. Po tej zmianie okazuje się, że większość z tych informacji działa jak hamulec — spowalnia model i spowalnia jego myślenie. W tym materiale pokażę, jak posprzątać własne projekty metodą inżynierską prosto z Anthropica.
Jeden z inżynierów Anthropica opublikował niedawno artykuł „The New Rules of Context Engineering” o nowych zasadach inżynierii kontekstu dla modeli generacji Claude 5. Jego zespół usunął ponad 80% promptu systemowego Claude Code — dla modeli takich jak Opus 5, Sonnet 5 i 5.1 oraz wersji przyszłych — i nie zanotował żadnego mierzalnego spadku na ewaluacjach. Prompt systemowy to w praktyce książka reguł, z którą Claude Code startuje w każdym uruchomieniu; własne instrukcje użytkownika i kontekst zadania lądują tuż obok niej. Czyli w skrócie: można wyciąć większość tej książki i zachować zmierzoną wcześniej jakość.
(Informacja dodatkowa: CLAUDE.md to plik z instrukcjami ładowany automatycznie przez Claude Code — w wersji projektowej i globalnej; „skille” to pakiety gotowych instrukcji i procedur, które model uruchamia w razie potrzeby.)
Reguły, które przeżyły swoje modele
Według wskazówek z tego artykułu sam przeprowadziłem taki porządek: przejrzałem instrukcje, które nazbierały się z czasem, i uporządkowałem współpracę między moimi skillami. Dobrze pasuje do tego rada Borisa Cherny’ego, twórcy Claude Code: co pół roku po prostu kasuj wszystkie skille. Tymczasem przez cały czas słyszeliśmy, że to właśnie skille czynią Claude Code mądrzejszym i bardziej przewidywalnym.
Autorzy artykułu opisują, że reguły niezbędne starszym modelom zaczęły krępować Claude’a, gdy ten się rozwinął. Przykład: komentarze w kodzie. Kiedyś obowiązywał twardy limit długości — choć niektóre projekty wymagały więcej wyjaśnień. Dziś model dostaje jedną zasadę: trzymać się stylu otaczającego kodu.
Łatwo wpaść w tę samą pułapkę we własnym środowisku. Claude popełnia błąd, dodajesz regułę. Po paru miesiącach reguła wisi w CLAUDE.md albo w którymś ze skillów — często w lekko zmienionej wersji także gdzie indziej — a właściwie już jej nie potrzebujesz, bo model zdążył podrosnąć. Instrukcje zostają, kontekst rośnie.
Powiedz, co znaczy „gotowe” — i zejdź modelowi z drogi
W niedawnym filmie o promptowaniu Sonnetu 5.1 mówiłem o definiowaniu „gotowego”: podajesz modelowi oczekiwany efekt, powód, dla którego coś robisz, i ograniczenia, których ma przestrzegać. Potem schodzisz mu z drogi i zostawiasz przestrzeń do wykonania roboty.
Dlatego w tym materiale poprosiłem Claude’a, żeby przeanalizował moją drogę od pomysłu na film do scenariusza gotowego do nagrania — i wskazał jedną drobną poprawkę wraz z plikiem, który mogę sprawdzić na własne oczy. To demo pokażę dalej.
Zespół Applied AI w Anthropiku zaleca używać najmniejszej ilości kontekstu, jaka daje pożądany wynik. Ująłem to we własną maksymę: najlepszy kontekst to najmniejszy kontekst, który daje najwyższą jakość przy najniższym koszcie. I od razu zastrzeżenie: „minimalny” nie znaczy „krótki”. Jeśli model potrzebuje jakiegoś szczegółu do wykonania zadania, ten szczegół zostaje.
Dowody: im dłuższe wejście, tym gorszy wynik
Jest badanie, które sprawdza, co się dzieje, gdy wejście rośnie. Praca opublikowana w 2025 roku przetestowała pięć modeli na matematyce, odpowiadaniu na pytania i programowaniu. Wyniki spadały wraz z długością wejścia — nawet gdy modele potrafiły odnaleźć potrzebne informacje. Spadki wahały się od 13,9% do 85% w zależności od modelu i zadania. Zastrzeżenie: to inne modele, półtora roku temu, w warunkach kontrolowanych — te procenty nie powiedzą nam, co dokładnie stanie się z naszym CLAUDE.md.
Ale Anthropic przeprowadził też pomiar dokładnie tej idei: definicje narzędzi MCP ładowane dopiero wtedy, gdy są potrzebne. Efekt: o 85% mniejsze zużycie tokenów w ich przykładzie oraz wzrost wyników ewaluacji MCP — z 49% do 74% dla Opusa 4 i z 79,5% do 88,1% dla Opusa 4.5. Model nadal miał pełny dostęp do narzędzi; po prostu nie musiał ładować wszystkich instrukcji na starcie.
(Informacja dodatkowa: MCP, czyli Model Context Protocol, to otwarty standard podłączania zewnętrznych narzędzi i źródeł danych do modeli.)
We własnym środowisku odpowiednikiem takiego porządku jest komenda /doctor. Gdy ostatnio ją uruchomiłem, dostałem raport z audytem warsztatu pracy: konkretne instrukcje i miejsca przekazania zadań do posprzątania. Za chwilę pokażę to na ekranie.
(Informacja dodatkowa: w tym miejscu materiał zawiera wstawkę sponsorską — narzędzie Hyper Agent, skierowane do agencji wdrażających agentów u klientów; każdy klient dostaje osobną przestrzeń roboczą dla agentów, skillów, pamięci i dokumentów, a jego pracownicy rolę, która pozwala uruchamiać agentów bez ruszania promptów systemowych. Autor prowadzi też darmową społeczność poświęconą budowaniu systemów i agentów AI.)
Eksperyment: ładniejszy dokument kontra lepsza struktura
Na moim osobistym „systemie operacyjnym AI” testowałem już dość radykalne wersje tego podejścia: kopiowałem go, usuwałem CLAUDE.md, wywalałem skille i sprawdzałem różne prompty na tym samym zadaniu. Ostatni przykład: wziąłem wywiad z Borisem Chernym i chciałem z niego zrobić przewodnik dla studentów. Mój pełny, codzienny setup wyprodukował ładniejszy dokument — z moim brandingu, porządnym nagłówkiem, linkami, których zwykle używam, no i z kontekstem o mnie. Wersja „goła” wyszła skromniej wizualnie, ale jej struktura była wyraźnie lepsza: lepsze detale, wywiad porządkujący w idee, dodane znaczniki czasu. Bardziej profesjonalna i po prostu użyteczniejsza dla studenta. Jedna wersja dała mi szlif, druga — treść, którą wolałem.
Branding oczywiście chcę zachować. Zbudowałbym więc z tego nowy skill w duchu: „używaj takiego nagłówka, takiej czcionki, takiej stopki, dodaj te loga — a treść ustrukturyzuj tak, jak uznasz za słuszne, bo intencję znasz: przewodnik dla studentów”. W dopracowanej wersji miałem bowiem tyle zabezpieczeń i instrukcji, że po prostu zamykałem model w klatce i nie pozwalałem mu być twórczym. Te wytyczne ratowały sytuację za czasów Opusa 4; dziś Sonnet 5.1 zrobi to lepiej sam.
Doświadczony grafik nie potrzebuje instruktażu dla pierwszoklasisty
To trochę tak, jakby dać doświadczonemu grafikowi listę kontrolną pisaną dla dziecka składającego pierwszą prezentację. Grafik musi wiedzieć, dla kogo to jest i co chcemy osiągnąć. Ale jeśli dyktujemy położenie każdego pudełka i każdego zdania, zanim zobaczy materiał, możemy mu odebrać pomysł — być może ten, który spodobałby nam się bardziej.
I tak podchodzę do przeglądu instrukcji: zostawiam detale, które pomagają Claude’owi zrozumieć zadanie i to, co jest w nim specyficznie „moje”, a potem sprawdzam, czy nadal potrzebuje procedury, którą wokół tego napisałem.
Gdy mówię o kontekście w moich „czterech C” osobistego systemu AI, mam na myśli dokładnie te rzeczy: mój styl, moje cele, moją publiczność i to, jak działa mój biznes. Tego model sobie nie wywnioskuje i nie znajdzie w internecie — to muszę mu dostarczyć sam.
Ważne jest też wyjaśnianie, po co o coś prosimy. „Przewodnik dla studentów” podpowiada Claude’owi, żeby sięgał po analogie, proste wyjaśnienia i przykłady — taki kontekst zostawiam przy sprzątaniu. Ale rozbudowaną listę folderów model raczej sprawdzi sam. Jeśli ta sama instrukcja powtarza się w kilku miejscach, patrzę, czy wszystkie kopie są potrzebne. A jeśli szczegółowa procedura dotyczy wyłącznie montażu wideo, wolałbym, żeby ładowała się właśnie przy montażu.
Cała ta filozofia sprowadza się do zejścia modelowi z drogi — co nadal wymaga jasności co do tego, co wolno. CLAUDE.md zostawiam użyteczny jako punkt startowy: po co jest projekt, na jakie pułapki uważać, gdzie szukać głębszych wytycznych. Cały mój proces montażu nie musi się ładować, gdy proszę o pomoc ze scenariuszem.
/doctor: audyt rzeczy, o których nie myślisz
W Claude Code można uruchomić /doctor, żeby przejrzeć mnóstwo lokalnych spraw, którym zwykle nie poświęcamy uwagi: ustawienia, pliki konfiguracyjne i podobną nudę. Uruchomiłem /doctor w nowej sesji; sprawdził moje skille, pamięć, pluginy, ustawienia i instalację. W tabeli widnieje każdy skill: gdzie jest zainstalowany, ile razy zarejestrowano jego użycie od instalacji oraz ile tokenów — szacunkowo — zajmuje jego „lista”. Chodzi o nagłówek YAML, czyli krótki blok opisu z początku pliku: to właśnie po nim Claude odnajduje skilla, a pełne instrukcje czyta dopiero, gdy zdecyduje się go uruchomić. Agent builder wyceniono na 111 tokenów, „prove it” na 103, oba z zerem użyć.
Raport oflagował 18 starszych skillów bez żadnego użycia, ale zostawił te utworzone kilka dni wcześniej — wiek też wchodzi do rachuby. Poza tym narzędzie przejrzało 50 ostatnich sesji z projektu, liczniki z całego okresu użytkowania (252 uruchomienia) oraz wywołania skillów i pluginów w 223 transkryptach. Taką listę i tak przeglądam ręcznie, zanim cokolwiek wyłączę czy skasuję — zwłaszcza że danego skilla mogę używać przez inne narzędzie — ale to są dokładnie te dane użycia, do których Claude Code ma dostęp.
Potem /doctor bierze się za duplikaty. U mnie mapa projektu powtarzała treść już pokrytą przez mapę routingu; powtórki pojawiły się też w sekcjach o szablonach, materiałach źródłowych i archiwizacji plików. Łącznie wskazał ok. 2 250 znaków do wycięcia, czyli szacowane 563 tokeny oszczędności. Raport rozpisuje też, skąd właściwie bierze się pamięć: projektowy CLAUDE.md, instrukcje globalne dla całego konta, indeks pamięci automatycznej oraz CLAUDE.local.md z wytycznymi specyficznymi dla tego katalogu na mojej maszynie. Ten lokalny plik okazał się pustym szablonem na jakieś 35 tokenów — drobiazg, ale o to chodzi: narzędzie przejrzy rzeczy, o których nigdy nie myślisz.
Co ciekawsze, /doctor znalazł też CLAUDE.md osobnego projektu wideo leżącego na moim pulpicie, który ładuje się do Herka 2 — szacunkowo kolejne ok. 2 tysiące tokenów. Wniosek praktyczny: nawet jeśli posprzątałeś pliki wewnątrz projektu, instrukcje mogą dochodzić skądinąd — i płacisz za nie, choć o tym nie wiesz.
Kontrola konfiguracji wyłapała ponadto dwa zepsute skille: jeden miał złą nazwę pliku, drugu błąd formatowania w nagłówku YAML, przez co Claude w ogóle nie widział jego opisu. Na koniec audyt sam proponuje: „naprawić wszystko?” — pliki poprawione. Do tego /doctor zagląda w instalację, automatyczne aktualizacje oraz ustawienia trybu auto, uprawnień i hooków.
Audyt warsztatu: najmniejsza zmiana zamiast przebudowy
Po /doctor poprosiłem Claude Code o spojrzenie na mój warsztat YouTube’owy. Prompt, którego użyłem, brzmiał mniej więcej: „Przeaudytuj to repozytorium i pokaż najmniejszą zmianę, która przyspieszy drogę od surowego pomysłu na film do scenariusza gotowego do nagrania. Wykorzystaj systemy już istniejące. Wskaż konkretne pliki, które wykorzystałbyś ponownie, i jeszcze niczego nie edytuj”.
Claude najpierw zmapował kroki: od znalezienia pomysłu, przez research i konspekt, po scenariusz oraz plik do telepromptera, który podpinam przy nagraniu. Następnie prześledził, jak praca przechodzi z etapu na etap. Główna rekomendacja dotyczyła researchu: mój skill konspektu zbierał fakty, ale nie zapisywał dowodów w pliku, który skill scenariusza umiałby odczytać; a skill scenariusza miał z kolei twardą regułę weryfikacji faktów od zera. Regułę dodałem z rozsądku — chciałem mieć pewność, że nic nie jest zmyślone. Ale skoro źródło pierwotne zostało już znalezione i sprawdzone, kolejny etap powinien dostać tę gotową robotę na tacy.
Audyt policzył 25 folderów wideo ze scenariuszem i tylko trzy z plikiem sources.md. Nie znaczy to, że reszta filmów powstawała bez researchu — pokazuje jedynie, że taki sposób przekazywania dowodów nie był konsekwentny. Proponowana poprawka: trzy edycje w dwóch istniejących skillach. Zgodziłem się i pozwoliłem je wprowadzić.
Rytm porządków i system, który sam się czyści
Skoro wiesz już, jak użyć Claude’a do audytu własnego środowiska, zrób z tego rutynę. Raz w miesiącu, jeśli często dodajesz skille i przebudowujesz workflow; raz na kwartał, jeśli setup leży stabilnie. A przy każdej przesiadce na nowy model — zdecydowanie, bo każdy model interpretuje twoje ustawienia, skille i instrukcje trochę inaczej.
Gdy zrobisz to kilka razy i zaufasz /doctor albo własnym promptom audytowym, możesz te kontrole wpuścić na harmonogram. Dla lokalnych spraw wystarczy zaplanowane zadanie z dostępem do tych samych plików i ustawień w aplikacji Claude desktop, którą zostawiasz otwartą: raz w miesiącu sam odpala audyty, a ty budzisz się rano z listą rekomendacji do zatwierdzenia lub odrzucenia.
Dużo mówi się o systemach operacyjnych AI i „drugich mózgach”, a ich piętą achillesową jest człowiek: zapominamy aktualizować, wstawiamy duplikaty, nie kasujemy starek. Jeśli taki system współpracuje z tobą w tym rytmie — sam się porządkuje i sam doskonali — dostajesz w rękę mechanizm samoczyszczący się. A kiedy twój osobisty system działa, naturalny kolejny krok to zgranie zespołu: żeby ludzie współpracowali na wspólnych fundamentach, zamiast każdy od nowa budować własny.