O czym jest ten film
- Film omawia trzy nowe umiejętności Matta Pococka — gotowe procedury dla agentów AI wspierających programowanie — i pokazuje, gdzie mieszczą się w całym cyklu wytwarzania oprogramowania.
- Na wstępie przypomnienie pięciu dotychczasowych: zbieranie kontekstu, specyfikacja, tickety, implementacja oparta na TDD oraz przegląd kodu.
- Pierwsza nowość, implement-spec, eliminuje ręczne przerabianie zadań: kilka agentów naraz działa na niezależnych ticketach, w osobnych drzewach roboczych, a wyniki są scalane, recenzowane i pakowane w pull request.
- Druga nowość, umiejętność pull requestów, odpowiada na nowe wąskie gardło: AI pisze kod szybciej, niż człowiek zdąża go sprawdzać.
- Taki pull request ma trzy sekcje: podsumowanie w formie diagramów, dowody działania (testy, zrzuty ekranu, wydajność) oraz ryzyko scalenia (możliwość wycofania zmiany, zasięg jej wpływu).
- Ta struktura porządkuje decyzje: drobne zmiany łatwe do wycofania można przepuszczać śmielej, duże i trudne do naprawienia zostawić dokładnej ludzkiej weryfikacji.
- Umiejętność pull requestów warto dostosować do zespołu — mniej żargonu, jeśli odbiorcy nie mają technicznego przygotowania.
- Trzecia nowość, retro, analizuje przebieg pracy agenta i ulepsza dwa obszary: kontekst (plik agent.md z mapą kluczowych plików, odchudzanie promptów) oraz zabezpieczenia (sztywne reguły, lint, standardy kodowania).
- Retro nie może pracować na autopilocie — uruchamiaj je okresowo i zatwierdzaj propozycje osobiście, bo w przeciwnym razie projekt zamieni się w nieustanne szlifowanie drobiazgów zamiast tworzenia funkcji.
- Wszystkie umiejętności razem zamykają pętlę: od kontekstu, przez plan i implementację, po naukę na błędach — a autor filmu udostępnia stronę z pełną mapą całego zestawu (link w opisie nagrania).
10 najważniejszych takeaways — z kontekstem zastosowania
1.Najpierw zbierz kontekst, dopiero potem koduj
Na czym polega: Pierwsza faza zestawu (grooming) to zebranie maksimum informacji, zanim agent cokolwiek zbuduje — jakość odpowiedzi AI rośnie razem z jakością kontekstu.
Jak stosować: Zanim zlecisz agentowi budowę funkcji czy przepływu pracy, przeprowadź z nim rozmowę o wymaganiach, ograniczeniach i ustaleniach, a efekt zapisz w postaci specyfikacji.
Na co uważać: Ustalenia muszą trafić do plików. Jeśli zostaną tylko w rozmowie, wyparują z pamięci agenta i przy następnym zadaniu zaczniesz od zera.
2.Dziel pracę według funkcji, nie według warstw
Na czym polega: Plan rozbija się na tickety ułożone wokół kompletnych funkcji, a nie wokół warstw technicznych — to kluczowa decyzja projektowa całego zestawu.
Jak stosować: Każdy ticket powinien dawać kawałek realnie działającej funkcjonalności, do zrealizowania od początku do końca przez jednego agenta.
Na co uważać: Dzielenie warstwowe (osobne zadanie na frontend i osobne na backend) rozprasza kontekst i oddala moment, w którym coś faktycznie działa.
3.Jedno zadanie — jeden agent
Na czym polega: Każdy ticket realizuje pojedynczy agent, właśnie po to, żeby nie przeładowywać okna kontekstowego.
Jak stosować: Przydzielaj zadania pojedynczo; równoległość organizuj na poziomie wielu zadań, a nie wielu wątków w ramach jednego.
Na co uważać: Agent z nadmiarem rzeczy w kontekście gubi się w szczegółach i częściej popełnia błędy — im mniejsze zadanie, tym pewniejszy wynik.
4.implement-spec: przestań przerabiać tickety ręcznie
Na czym polega: Nowa umiejętność sama porządkuje zadania, wybiera te niezależne i uruchamia kilka agentów równolegle, a następnie scala rezultaty, przeprowadza przegląd kodu i przygotowuje pull request.
Jak stosować: Gdy masz gotową specyfikację i listę zadań, sięgnij po implement-spec zamiast realizować je jedno po drugim samodzielnie.
Na co uważać: Równolegle można puścić wyłącznie zadania bez zależności — powiązane wymagają zachowania kolejności, a scalanie wielu równoległych gałęzi wymaga uwagi.
5.Gdy kod pisze AI, wąskim gardłem staje się przegląd
Na czym polega: Skoro AI generuje kod masowo, problem przesunął się z pisania na sprawdzanie — codziennie może powstawać mnóstwo pull requestów.
Jak stosować: Sprawdź, gdzie realnie znika czas w Twoim procesie. Jeśli to przeglądy, inwestuj w narzędzia, które skracają decyzję „scalać czy nie”.
Na co uważać: Plan testów napisany przez samo AI to jeszcze nie dowód — dopóki człowiek nie uruchomi aplikacji, nie wiadomo, czy funkcja działa.
6.Podsumowanie pull requesta rysuj, nie pisz
Na czym polega: Zamiast opisu słownego umiejętność PR generuje diagramy zależności — całość widać jednym rzutem oka, bez czytania ściany tekstu.
Jak stosować: W pull requestach tworzonych przez agentów wymagaj schematów zmian (co z czym się łączy), a nie tylko listy zmodyfikowanych plików.
Na co uważać: Diagram musi oddawać rzeczywistą strukturę kodu — błędny schemat wprowadza w błąd szybciej niż nieprecyzyjny opis.
7.Żądaj dowodów, nie deklaracji
Na czym polega: Sekcja „dowody” w pull requeście ma pokazywać fakty: przechodzące testy, zrzuty ekranu, wpływ na wydajność — zamiast założeń w stylu „powinno działać”.
Jak stosować: Przyjmij zasadę, że zmiana bez dowodu nie wchodzi — zanim scalisz, sprawdź, czy agent dostarczył mierzalne potwierdzenie działania.
Na co uważać: Testy napisane i uruchomione przez tego samego agenta bywają zbyt pobłażliwe; krytyczne ścieżki warto zweryfikować samodzielnie.
8.Przeglądaj zmiany według ryzyka scalenia
Na czym polega: Sekcja ryzyka odpowiada na pytania: co się stanie na produkcji, jeśli ta zmiana zawiedzie; czy da się ją szybko wycofać; jak szeroki będzie obszar, którego dotknie.
Jak stosować: Drobne zmiany łatwe do wycofania przepuszczaj śmielej; duże i trudne do naprawienia zatrzymuj do dokładnej ludzkiej weryfikacji.
Na co uważać: Ocena „łatwe do wycofania” musi wynikać z realiów Twojej produkcji, a nie z samego opisu zmiany przygotowanego przez agenta.
9.Dostosuj umiejętność do swojego zespołu
Na czym polega: Wersja PR Matta Pococka jest mocno techniczna, ale sam autor filmu podkreśla, że to tylko punkt wyjścia — należy ją przepracować pod własne potrzeby.
Jak stosować: Jeśli odbiorcy nie mają technicznego przygotowania, uprość opisy: mniej żargonu architektonicznego, więcej tego, co zespół faktycznie rozumie.
Na co uważać: Umiejętność napisana językiem obcym dla zespołu nie będzie używana — i prędzej czy później wróci się do chaotycznych przeglądów.
10.Retro: powtarzające się błędy agenta zamieniaj w trwałe reguły
Na czym polega: Po skończonej pracy retro analizuje całą rozmowę z agentem i proponuje ulepszenia w dwóch obszarach: kontekstu (np. plik agent.md z mapą kluczowych plików, skrócenie nadmiarowych fragmentów promptów) oraz zabezpieczeń (zakazy, style importów, reguły lintu, standardy kodowania).
Jak stosować: Uruchamiaj okresowo — na przykład po większych seriach zadań — i zatwierdzaj propozycje jak zwykłe pull requesty.
Na co uważać: Tryb autopilota prowadzi do czepiania się drobiazgów: projekt przesuwa się wtedy z tworzenia funkcji na nieskończone szlifowanie procesu.
Redakcyjne tłumaczenie
Wprowadzenie: trzy nowe elementy zestawu
Jeśli budujesz aplikacje z pomocą AI w oparciu o umiejętności Matta Pococka — czyli gotowe pakiety instrukcji dla agentów, wywoływane zwykle poleceniem z ukośnikiem, na przykład /implement — ten film jest dla Ciebie. Autor niedawno opublikował nowe wersje swojego zestawu, a wśród nich trzy, które prowadzący uważa za szczególnie przydatne. W materiale po kolei: czym są, jak działają i kiedy sięgać po każdą z nich w całym cyklu wytwarzania oprogramowania.
(Informacja dodatkowa: Matt Pocock to znany edukator programowania, autor popularnych materiałów o TypeScripcie, który w ostatnim czasie publikuje zestawy „umiejętności” — rozszerzeń dla agentów kodujących, m.in. w Claude Code.)
Przypomnienie: pięć dotychczasowych elementów zestawu
Zanim przejdziemy do nowości, krótkie przypomnienie tego, co już jest w zestawie.
Pierwsza umiejętność to tzw. grooming, czyli zbieranie kontekstu. Zanim agent cokolwiek zbuduje — aplikację czy przepływ pracy — najpierw zbiera się jak najwięcej informacji o zadaniu. Im pełniejszy obraz, tym trafniejsze odpowiedzi AI.
Druga to umiejętność specyfikacji. Spisuje to, co ustaliliśmy podczas zbierania kontekstu, w formie uporządkowanego planu.
Trzecia rozbija ten plan na serię ticketów. Najważniejszy szczegół: zadania są ułożone według funkcji, a nie według warstw technicznych. Każde z nich realizuje pojedynczy agent, od początku do końca — właśnie po to, żeby chronić okno kontekstowe.
Czwarta, /implement, odpowiada za samo kodowanie i opiera się na programowaniu sterowanym testami (TDD).
Piąta to przegląd kodu: agent startuje ze świeżym oknem kontekstowym, a przy poprawkach kieruje się dwunastoma technikami refaktoryzacji opisanymi w książce Martina Fowlera.
(Informacja dodatkowa: chodzi o „Refactoring” Martina Fowlera — klasykę dotyczącą poprawiania struktury kodu bez zmiany jego zachowania.)
Kto chce porównać ten zestaw z innymi podejściami do programowania sterowanego specyfikacją albo poznać go znacznie głębiej, odsyłam do wcześniejszego filmu na kanale.
Wtrącenie: społeczność prowadzącego
W połowie materiału pojawia się krótka autopromocja. Prowadzący, były starszy inżynier AI w Amazonie i Microsofcie, zachęca do swojej społeczności szkoleniowej. Oferuje w niej plan nauki obejmujący automatyzacje, agentów, systemy badawcze, budowanie produktów SaaS, a na końcu produktyzację i marketing własnych umiejętności — do tego szablony, cotygodniowe spotkania na żywo i pomoc grupy. Filozofia jest prosta: nie chodzi o oglądanie kolejnych filmów, tylko o budowanie, pokazywanie postępów i zbieranie na nie reakcji.
Pierwsza nowość: implement-spec — koniec z ręcznym przerabianiem zadań
W dotychczasowym zestawie był jeden irytujący mankament: po rozbiciu specyfikacji na tickety trzeba było każde zadanie realizować ręcznie, jedno po drugim. Właśnie to eliminuje nowa umiejętność.
Jej działanie wygląda tak: bierze specyfikację i wygenerowane wcześniej tickety, porządkuje je, wybiera te, które nie zależą od innych, i zabiera się do nich równolegle. W ten sam czas pracuje kilka agentów, każdy we własnym drzewie roboczym (tzw. worktree, czyli osobnym katalogu roboczym danej gałęzi w Gicie), przez co cała pula zadań znika szybciej niż dotąd. Na koniec wszystkie zmiany trafiają do jednej gałęzi, pod spodem odpala się przegląd kodu, nanosi poprawki i przygotowuje pull request.
W skrócie: implement-spec to połączenie trzech rzeczy — TDD, przeglądu kodu i równoległej pracy wielu drzew roboczych.
Druga nowość: umiejętność pull requestów — dowód, ryzyko i zaufanie w kilka sekund
To, że AI pisze kod, nikogo już nie dziwi. Pytanie brzmi inaczej: jak sprawdzić ten kod szybciej? Agent może generować dziesiątki pull requestów dziennie i to właśnie recenzowanie stało się wąskim gardłem procesu.
Dla mniej technicznych odbiorów warto wyjaśnić samą mechanikę. W aplikacji produkcyjnej działa wersja, z której w tej chwili korzystają klienci. Nowej funkcji nie dodaje się wprost do niej — tworzy się osobną gałąź, w której zmiana powstaje, jest testowana i dojrzewa, a dopiero potem scala się ją z gałęzią główną. Właśnie tę prośbę o scalenie nazywa się pull requestem (spotyka się też nazwę merge request). Zawiera listę zmian, uzasadnienie oraz wskazówki, co warto sprawdzić. To w praktyce ostatnia linia obrony: błąd wyłapany na etapie przeglądu nie trafia do klientów. Dawniej wąskim gardłem było samo pisanie kodu — było wolne. Dziś problem się odwrócił i o efektywności decyduje tempo przeglądów.
W standardowym pull requeście tworzonym przez AI znajdziemy co najwyżej krótkie podsumowanie i plan testów — przy czym nikt nie wie, czy ten plan testów jest w ogóle prawdziwy. Nadal trzeba, żeby człowiek uruchomił aplikację i sprawdził, że wszystko działa, zanim zmiana wejdzie do gałęzi głównej. Nie ma więc żadnego dowodu, że funkcja faktycznie działa.
Na to odpowiada umiejętność PR Matta Pococka, której zadaniem jest dostarczanie dowodów, oceny ryzyka i zaufania w kilka sekund. Składa się z trzech sekcji.
Pierwsza to podsumowanie — ale inne niż wszystkie, które znamy. Zamiast zmuszać czytelnika do przerabiania ściany tekstu, umiejętność generuje diagramy obrazujące relacje między elementami zmiany. Efekt: całość widać jednym rzutem oka.
Druga to dowody. Agent ma pokazać fakty: czy zmiana realnie poprawiła wydajność, czy testy przechodzą, czy są zrzuty ekranu. Coś, co potwierdza działanie, a nie deklarację w stylu „no, powinno być git”.
Trzecia to ryzyko scalenia. Co się stanie, jeśli ta zmiana zawiedzie na produkcji? Czy da się ją wycofać? Jak szeroki będzie obszar, którego dotknie ewentualna awaria? Pull request ma zatem rozkładać na stole dowody i najczarniejsze scenariusze, zanim w ogóle zasiądziemy do recenzji.
I to porządkuje decyzje. Drobiazgową zmianę, którą łatwo wycofać, można po prostu przepuścić. Dużą zmianę, której nie da się szybko naprawić — zatrzymać i dokładnie obejrzeć człowiekowi. Oczywiście to wersja Matta. Twoja może wyglądać zupełnie inaczej: jeśli nie pochodzisz ze świata technicznego i architektura nie jest Twoją bajką, możesz umiejętność przerobić tak, żeby nie sypała żargonem. Najważniejsze, żeby sens był dla Ciebie jasny — i żeby całość była skrojona pod Twój zespół.
Trzecia nowość: retro — jak agent ma uczyć się na błędach
Funkcja skończona to jednak nie koniec pracy, bo nie wiemy, jakie błędy AI popełniła po drodze — i jak sprawić, żeby ich nie powtarzała. Dokładnie do tego służy trzecia z nowych umiejętności: retro, czyli retrospektywa.
Problem jest realny zwłaszcza przy długich zadaniach. Gdy agent ma do zrobienia dziesięć, sto albo tysiąc zgłoszeń, potrafi w kółko wpadać w tę samą pułapkę i przy okazji spalać mnóstwo tokenów. Retro spogląda wstecz na to, co agent zrobił, i wyciąga wnioski z dwóch obszarów: kontekstu oraz zabezpieczeń.
Zacznijmy od kontekstu. Czasem agent długo szuka właściwych informacji, zanim dokończy poprawkę błędu albo funkcję. Rozwiązaniem może być plik agent.md, zawierający spis kluczowych plików projektu: co gdzie leży i jak to szybko znaleźć. Wtedy agent nie przekopuje całego repozytorium, tylko zagląda do jednej ściągi. Druga strona tego samego medalu to porządkowanie samego pliku agent.md i promptu systemowego: czy nie ma tam fragmentów zbyt długich albo powielanych, które należałoby wyciąć? Cała ta praca nad kontekstem ma jeden cel — jak najlepiej wykorzystać okno kontekstowe.
Drugi obszar to zabezpieczenia, czyli sztywne reguły, których agent ma przestrzegać: jakich interfejsów API nie wolno wywoływać, jaki styl importów obowiązuje, do których katalogów nie zaglądać. Część błędów da się po prostu zablokować regułami lintu, czyli statycznej analizy kodu. To z kolei wymaga spójnego stylu i kodowego smaku, ustalonego jako standard zespołu.
Ważne zastrzeżenie Matta: retro nie może działać na autopilocie. Ta umiejętność ma być uruchamiana okresowo — jeśli puścić ją bez nadzoru, zaczyna traktować wszystko jako materiał do czepiania się drobiazgów, a projekt przesuwa się z budowania funkcji na samo doskonalenie procesu. Poza tym w pętli musi siedzieć człowiek, który zatwierdzi pull requesty proponowane przez retro.
Całość: pętle domknięte
Jak to wszystko składa się w całość? Nowe umiejętności uzupełniają wcześniejszy zestaw dokładnie w brakujących miejscach. implement-spec wchodzi między generowanie ticketów a przegląd kodu. Po przeglądzie do akcji wkracza umiejętność pull requestów, dzięki której człowiek szybciej i pewniej decyduje o scaleniu. A na końcu retro zamyka obieg: gdy przy następnym zadaniu agent zabiera się do nowej funkcji czy poprawki błędu, pracuje sprawniej — bo wnioski z poprzednich rund wróciły do jego kontekstu i reguł. To jest właśnie owa domknięta pętla programowania z AI.
Zakończenie
Na tym kończy się przegląd nowych umiejętności Matta Pococka i ich miejsca w cyklu wytwarzania oprogramowania. Autor filmu przygotował osobną stronę-zbiorcze omówienie całego zestawu (link znajdziemy w opisie nagrania): każdą umiejętność można tam rozwinąć i sprawdzić, czym jest, kiedy jej używać i jak dokładnie działa. Jeśli macie pytania albo własne ulubione umiejętności, które chcielibyście zobaczyć w kolejnych materiałach — zapraszamy do komentarzy.