O czym jest ten film
- Autor odpowiada na pytanie widzów: jakich umiejętności (skills) używa przy budowaniu aplikacji z agentami kodującymi.
- Prezentuje trzy narzędzia: code structure (własne), grep loop (od Greptile) i code simplify (od zespołu Anthropic) — pliki w opisie filmu.
- Wyjaśnia budowę umiejętności: metadane (nazwa + opis) oraz instrukcje; zasoby mają znaczenie drugorzędne.
- Kluczowa mechanika: do kontekstu modelu trafiają tylko metadane umiejętności — 53 tokeny zamiast 944, które kosztowałoby wczytanie całego pliku.
- Pełne instrukcje agent czyta dopiero po wywołaniu umiejętności, na przykład komendą /code structure.
- Plik agents.md jest wczytywany do kontekstu przy każdej turze rozmowy — przeznaczony dla wiedzy, którą agent ma znać stale, np. workflow gałęzi i pull requestów.
- W agents.md autor trzyma też informację o narzędziu Open Source, które pobiera kod źródłowy używanych bibliotek — aktualna wiedza zamiast nieświeżych danych treningowych modelu.
- Ostrzeżenie: do agents.md nie należy wpisywać opisu technologii projektu (np. „to React”) — agent sam przeszuka kod.
- grep loop to pętla: agent czyta recenzję PR-a od Greptile, poprawia kod i powtarza, aż osiągnie ocenę 5/5; u autora potrafiła kręcić się 19 minut.
- Segment sponsorowany: Daytona — środowiska sandbox do szybkiego testowania aplikacji (fork, instalacja zależności, build w ok. 30 sekund).
10 najważniejszych takeaways — z kontekstem zastosowania
1.Umiejętność kosztuje w kontekście tylko swoją metryczkę
Na czym polega: Do okna kontekstowego modelu trafiają wyłącznie metadane umiejętności — nazwa i opis. W przykładzie autora to 53 tokeny zamiast 944. Pełne instrukcje agent sięga dopiero wtedy, gdy uzna umiejętność za potrzebną.
Jak stosować: Buduj umiejętności według schematu: metryczka na górze, instrukcje pod spodem. Zadbaj o zwięzły, jednoznaczny opis — to od niego zależy, czy model w ogóle umiejętność wywoła.
Na co uważać: Opis, który nie mówi jasno, do czego umiejętność służy, sprawi, że model jej nie użyje albo sięgnie po nią w złym momencie.
2.agents.md jest wczytywany w każdej turze — więc każde słowo kosztuje wielokrotnie
Na czym polega: W odróżnieniu od umiejętności plik agents.md (lub CLAUDE.md) ląduje w kontekście przy każdej wymianie zdań z modelem.
Jak stosować: Wpisuj wyłącznie zasady obowiązujące stale: workflow gałęzi i PR-ów, konwencje zespołu, informację o narzędziach, do których agent ma dostęp.
Na co uważać: Rozrastający się plik zjada okno kontekstowe i przytłacza rozmowę. Im krótszy, tym lepiej.
3.Rozdziel wiedzę „zawsze” od wiedzy „na żądanie”
Na czym polega: Umiejętności i agents.md nie konkurują ze sobą — uzupełniają się. Autor używa obu, bo pełnią różne role.
Jak stosować: Przy każdej informacji zadaj pytanie: czy agent ma to wiedzieć przez cały czas? Jeśli tak — agents.md. Jeśli tylko przy konkretnym zadaniu — umiejętność.
Na co uważać: Wklejenie umiejętności do agents.md (np. „zawsze restrukturyzuj kod”) każe agentowi działać bez potrzeby i obciąża kontekst w każdej turze.
4.Nie opisuj w agents.md tego, co agent znajdzie sam
Na czym polega: Informacje w rodzaju „to jest baza w Reactcie” są zbędne — model potrafi przeszukać repozytorium i sam rozpoznać stack.
Jak stosować: Do agents.md trafiaj wyłącznie z nietypowymi workflow, które nie przychodzą modelowi naturalnie. Standardową wiedzę o kodzie zostaw jego wyszukiwarce.
Na co uważać: Łatwo o granicę: opis technologii to śmieć, ale wymogi procesowe (gałęzie, PR-y, wydawanie) to złoto — rozróżniaj je konsekwentnie.
5.Pętla grep: pull request iterowany do oceny 5/5
Na czym polega: Umiejętność grep loop każe agentowi odczytać wszystko, co Greptile zostawił pod PR-em — podsumowanie, komentarze, gotowy prompt z poprawką — wypchnąć fix i poczekać na nową recenzję. Bez piątki pętla rusza od nowa; u autora potrafiła działać 19 minut bez nadzoru.
Jak stosować: Po zbudowaniu funkcji i lokalnych testach prześlij PR do maszynowej recenzji, uruchom pętlę i zając się czymś innym.
Na co uważać: Recenzent ocenia tylko to, co dostanie. Pętla nie zastępuje testów, a agent może poprawiać powierzchownie pod ocenę — warto przejrzeć finalny diff.
6.Maszynowa recenzja łapie błędy, które umykają człowiekowi
Na czym polega: Według autora prawie każda recenzja kodu przez agenta wykrywa jakąś lukę bezpieczeństwa albo buga — „zawsze coś się znajdzie”.
Jak stosować: Wprowadź maszynową recenzję jako stały etap przed merge’em, równolegle do lokalnych testów, a nie zamiast nich.
Na co uważać: Recenzja to filtr drugi, nie pierwszy — funkcja najpierw musi przejść twoje własne testy.
7.Architektura warstwy usług jako wzorzec dla kodu od agentów
Na czym polega: Umiejętność code structure przepisuje wygenerowany kod na service layer — czysty wzorzec, po którym agent łatwiej kontynuuje pracę, a człowiek łatwiej recenzuje. Większość kodu pluwana przez agenty to bowiem śmietnik.
Jak stosować: Po wygenerowaniu większej funkcji uruchom restrukturyzację, zanim kod pójdzie dalej w rozwój.
Na co uważać: Restrukturyzacja dotyka wielu plików naraz — wygodnie przeprowadzić ją jako osobny, oddzielony krok, nie wymieszany ze zmianami funkcjonalnymi.
8.Upraszczaj kod, gdy przestajesz go rozumieć
Na czym polega: Umiejętność code simplify od Anthropic upraszcza implementację z zachowaniem funkcjonalności. Autor nie ma harmonogramu — kieruje się czuciem: gdy kod robi się zbyt złożony, puszcza upraszczacz.
Jak stosować: Włączaj wtedy, gdy po lekturze kodu (swojego lub agentowego) nie łapiesz, co się w nim dzieje.
Na co uważać: Uproszczenie zmienia strukturę bez zmiany zachowania — mimo to dobrze po nim ponownie przetestować funkcję.
9.Ściągaj kod źródłowy bibliotek, z których korzystasz
Na czym polega: Narzędzie Open Source pobiera kod źródłowy używanych w projekcie bibliotek do wydzielonego katalogu, a agents.md informuje agenta o tym dostępie. Model wyszukuje w tym kodzie zamiast czytać całość, więc kontekst nie cierpi.
Jak stosować: Gdy biblioteka zmienia się szybciej niż dane treningowe modelu, każ agentowi patrzeć wprost w źródło — będzie wiedział dokładnie, czego szukać.
Na co uważać: Trzymaj te katalogi poza repozytorium produkcyjnym (u autora są wyszarzone i nie idą na GitHuba) — to tylko lokalna dokumentacja dla agenta.
10.Mierz koszt kontekstu w tokenach, zanim coś wstawisz
Na czym polega: Autor pokazuje na tokenizatorze OpenAI konkretną różnicę: 944 tokeny za cały plik kontra 53 tokeny za same metadane. To konkret zamiast domysłów.
Jak stosować: Sprawdzaj rozmiar w tokenizatorze wszystkiego, co ma trafić do agents.md lub do umiejętności. Optymalizuj w pierwszej kolejności to, co wczytywane stale.
Na co uważać: Nawet małe pliki, powtarzane w każdej rozmowie, kumulują się — mikrooszczędności robią różnicę dopiero w skali wielu tur i wielu sesji.
Redakcyjne tłumaczenie
Wstęp: trzy umiejętności i jeden plik
Po ostatnim filmie sporo osób pytało, jakich umiejętności używam przy budowie aplikacji, kiedy pracuję z agentami kodującymi. Podzielę się nimi. Pokażę też mój plik agents.md, ale przede wszystkim wyjaśnię, jak te narzędzia działają od środka — żebyście stosowali je świadomie, a nie na ślepo.
Nie ma tu nic nadzwyczajnego. Trzymam się trzech umiejętności:
- code structure — mojego autorstwa,
- grep loop — od Greptile, mojego agenta do recenzji kodu,
- code simplify — od zespołu Claude.
Linki do wszystkich trzech znajdziecie w opisie filmu. Do tego dochodzi plik agents.md. I od razu ważna uwaga: w sieci krąży mnóstwo materiałów, w których umiejętności i agents.md ścigają się jak rywale — bo jedno rzekomo jest lepsze od drugiego. Ja używam obu, bo każde robi co innego. Umiejętności model sięga dopiero wtedy, gdy ich potrzebuje; agents.md dostaje w każdej rozmowie.
Jak zbudowana jest umiejętność
Warto najpierw zrozumieć, jak umiejętność jest pisana. Składa się z metadanych, instrukcji i zasobów. Zasobami na razie się nie przejmujmy — patrzmy na metadane i instrukcje. Metadane wyglądają zwykle tak: nazwa i opis. Nazwa mówi sama za siebie, a opis wyjaśnia, co dana umiejętność robi. Poniżej zaczynają się instrukcje, czyli dokładne wskazówki, jak agent ma wykonać zadanie.
Przykład z mojego warsztatu: mam umiejętność do analityki YouTube. Zbiera kliknięcia z dub.sh, dane z Notion i statystyki z YouTube, robi na tym obliczenia i składa mi raport. Spisałem to jako umiejętność — i, co ciekawe, zbudowana jest dokładnie według tego samego schematu: nazwa, opis, a wszystko poniżej to instrukcja. To samo widać w mojej umiejętności code structure: metryczka na górze, instrukcje pod spodem.
Dlaczego umiejętności oszczędzają kontekst
I tu dochodzimy do sedna. Umiejętności są wydajne dlatego, że działają na żądanie: model nie dostaje całej umiejętności do kontekstu — dostaje wyłącznie metadane.
Najlepiej widać to na tokenizatorze OpenAI. Kiedy tworzysz plik markdown i każesz agentowi go przeczytać, cały plik ląduje w kontekście. Moja umiejętność code structure to około 944 tokenów. Samo w sobie niewiele — ale wyobraź sobie, że te 944 tokeny dokładasz do każdej rozmowy z agentem, sesja po sesji. A gdyby w kontekście była tylko nazwa i opis? Wtedy 53 tokeny. Różnica między 944 a 53 — dokładnie tyle oszczędzasz, bo przy umiejętnościach do modelu trafia sama metryczka.
Dlaczego to takie ważne? Bo zostaje ci więcej okna kontekstowego — po prostu go nie marnujesz. A mówię „na żądanie”, ponieważ instrukcje czytane są dopiero w chwili, gdy model uzna, że umiejętność jest mu potrzebna. Konkret: wpisuję /code structure i zatwierdzam. Agent sięga wtedy do pliku, czyta instrukcje — dotąd miał w kontekście tylko nazwę i opis — i po lekturze wie, co robić. W tym tkwi cała siła umiejętności.
Segment sponsorowany: Daytona
(Informacja dodatkowa: poniższy fragment to płatna promocja sponsora — Daytony, dostawcy środowisk sandbox dla deweloperów.)
Gdy słyszycie „Daytona”, myślicie pewnie o szybkich samochodach. Ja myślę o dostawcy sandboxów z najlepszą wydajnością — i potwierdza to benchmark Compute SDK: przejrzyjcie kolejne testy, a w każdym na szczycie znajdziecie Daytonę. Nie opieram się jednak wyłącznie na benchmarku. Używam jej w aplikacji feedback — wewnętrznym narzędziu mojego studia produktowego, czymś w rodzaju firmowego vibe codingu. To właśnie Daytona napędza to narzędzie.
Test: klikam „przetestuj w sandboxie”. Zobaczcie, jak szybko wstaje instancja — projekt jest forkowany, zależności instalowane, a build sprawdza, czy aplikacja działa. Zajęło to dosłownie pół minuty. Następnie klikam „utwórz aplikację” i otwieram jej instancję: nowy sandbox, środowisko podglądowe, instalacja wybranego agenta (domyślnie OpenCode). Po kilku sekundach mogę działać — aplikacja chodzi w sandboxie z agentem, widzę pliki, mam terminal (to terminal w sandboxie Daytony) i diagnostykę na żywo. Wszystko to dzięki Daytona. Link w opisie, a z moim kodem zyskacie 100 dolarów kredytu.
Co trafia do agents.md
agents.md to zupełnie inna bestia: plik trafia do okna kontekstowego przy każdej turze. Wyobraźcie sobie okno na 272 tysiące tokenów: najpierw systemowy prompt i inne wewnętrzne sprawy modelu, potem agents.md, a dopiero dalej cała wymiana zdań między mną a modelem. Umiejętności obciążają to okno zaledwie 53 tokenami; agents.md — całą swoją treścią. Za każdym razem.
Trzeba więc zadać sobie pytanie: co właściwie wpisać do agents.md? Moja odpowiedź: wyłącznie to, co agent musi wiedzieć zawsze.
Pierwszy przykład — mój workflow gałęzi i pull requestów:
Staging jako gałąź integracyjna dla pracy funkcjonalnej. Gałąź funkcjonalną twórz z najświeższego stagingu, najlepiej w wydzielonym work tree pod work trees. Wysyłaj małe, jednozadaniowe PR-y z każdej gałęzi funkcjonalnej do stagingu. Nie włączaj niezwiązanych zmian do cudzej gałęzi, chyba że pull requesty są celowo ułożone jeden na drugim i zależność jest realna. Utrzymuj PR-y możliwe do zrecenzowania: dziel pracę według funkcji, granic odpowiedzialności lub obszarów zachowań, zamiast zbierać wielką łatkę mieszającą wszystko. Po wcieleniu PR-a do stagingu zaktualizuj aktywne gałęzie funkcjonalne, zanim ruszysz dalej. Promuj staging do main dopiero wtedy, gdy zintegrowany zestaw zmian jest gotowy do wydania.
Tego typu zasady agent ma znać bez przerwy — w każdej turze.
Świeży kod źródłowy zamiast nieaktualnej wiedzy z treningu
Druga rzecz, o której informuję w agents.md: narzędzie o nazwie Open Source (nagrałem o nim osobny film — link w opisie). Pobiera ono kod źródłowy narzędzi, których używam w danym projekcie. W moim repozytorium widać cały katalog z podprojektami — jest wyszarzony, bo nie idzie na GitHuba do produkcji. Są tam m.in. browser-use, Composio, Daytona, Crossmint, Open Clock (mój ziomek Chris Haruki wydał agenta — też go ściągnąłem) oraz Super Memory AI. Krótko: każdy open source’owy kawałek, na którym się opieram, ma tu swoją kopię kodu.
Po co? Bo modele nie zawsze są wytrenowane na najświeższych wersjach narzędzi. Wolę powiedzieć agentowi wprost: patrz w kod źródłowy — wtedy wiesz dokładnie, czego szukać. I od razu uspokajam tych, którzy obawiają się, że cały ten kod wejdzie do kontekstu. Nie wejdzie. Modele potrafią przeszukiwać. Gdy pytam „jak działają remote functions w SvelteKit?”, agent wyszukuje w kodzie remote functions, zamiast czytać repozytorium od deski do deski. Dzięki temu agent dostaje zawsze aktualną wiedzę, a ja zaznaczam w agents.md jedynie, że ma dostęp do tego źródła. To klasyczna informacja typu „zawsze”.
Czego do agents.md nie wpisywać
Skoro znacie już różnicę, zróbmy szybki test: gdybym wstawił umiejętności do agents.md, nic by z tego nie wyszło. Agent nie musi nieustannie restrukturyzować kodu, nie musi ciągle puszczać pętli grep, nie musi bez przerwy niczego upraszczać. Chcę dostarczać funkcje — a te kroki uruchamiać samodzielnie, kiedy uznam za stosowne. agents.md służy wiedzy stałej.
I jeszcze jedno, dla dobra wszystkiego świętego: nie wpisujcie tam informacji o kodzie projektu. Nie piszcie „to jest baza w Reactcie”. Agent to wie — może sam przeszukać kod. Do agents.md należą wyłącznie specyficzne workflow, które nie przychodzą modelowi naturalnie. Na tym polega cała różnica.
Trzy umiejętności w praktyce
code structure przepisuje wskazany fragment kodu na architekturę warstwy usług. To bardzo czysty wzorzec: agent łatwiej kontynuuje pracę na takim kodzie, a ja łatwiej go recenzuję. Umiejętność porządkuje to, co wygenerował agent — bo w większości przypadków agent po prostu pluje śmietnikiem. Link w opisie; zajrzyjcie i przeczytajcie.
grep loop, w parze z Greptile, to jedna z moich ulubionych umiejętności. Greptile sponsoruje część moich filmów, ale ten nie jest sponsorowany — po prostu kocham to narzędzie i na co dzień go używam. Jak to działa? Spójrzcie na moje pull requesty… właściwie każdy ma piątkę, więc trudno o kontrprzykład. No dobrze — wyobraźcie sobie, że wysyłam funkcję, a poziom pewności recenzji wychodzi trzy na pięć. Wpisuję wtedy /grep loop 128 (to numer PR-a) i zatwierdzam. W przykładzie z mojej historii pętla pracowała dziewiętnaście minut. Czym się zajmuje? Agent czyta wszystko, co Greptile zostawił pod pull requestem — podsumowanie, komentarze przy konkretnych fragmentach kodu, a nawet gotowy prompt z poprawką. Analizuje te informacje, wypycha fix i czeka na nową recenzję. Jeśli znowu nie ma piątki? Pętla rusza od nowa. Stąd nazwa: grep loop.
Dla mnie to najlepsza pętla sprzężenia zwrotnego, jaka mi się trafiła. Wchodzę w dialog z agentem, buduję z nim, każę mu dorabiać, testuję funkcję lokalnie — a po testach każę mu kod zrecenzować. I prawie zawsze recenzja coś wyłapie: jakąś lukę bezpieczeństwa, jakiegoś buga. Zawsze coś się znajdzie. Greptile przekazuje agentowi informację zwrotną, a grep loop po prostu kręci pętlę — raz, drugi, trzeci — aż zobaczę piątkę. O całym tym workflow nagrałem osobny film.
code simplify pochodzi od samych Anthropic. Uruchamiam go od czasu do czasu, kiedy patrzę na kod, a ten wydaje mi się zbyt złożony i nie łapię, co się w nim dzieje. Umiejętność zachowuje funkcjonalność, a upraszcza implementację. Nie mam tu żadnej struktury ani harmonogramu — kieruję się czuciem: gdy coś robi się zbyt skomplikowane, puszczam upraszczacz, a ten ogarnia mi kod.
Podsumowanie
To by było na tyle. Macie moje umiejętności i mój agents.md — wiecie, których narzędzi używam, jak i po co. Wiecie też, czemu służy agents.md i co do niego wkładam. Umiejętności działają na żądanie; agents.md (albo CLAUDE.md) to wiedza, którą agent ma mieć zawsze. Oba elementy są potrzebne, oba są ważne — i tak właśnie ich używam. Napiszcie w komentarzach, co chcielibyście zobaczyć następnym razem. Dziękuję za obejrzenie — łapcie lajka i dzwonek. Do zobaczenia.