O czym jest ten film
- Matt Pocock (aihero.dev) opowiada o swoim sposobie pracy z agentami AI: model to tylko połowa sukcesu, druga połowa to harness — prompty, skille, środowisko i jakość bazy kodu.
- Z rozróżnienia znanego z „A Philosophy of Software Design” wynika, że AI pochłonęło programowanie taktyczne (pisanie kodu), a wartość programisty przeniosła się na myślenie strategiczne: architekturę, zakresy zadań, tempo zespołu.
- Twoje umiejętności są sufitem tego, co zdziała AI — seniorzy zyskują z agentów wielokrotnie więcej niż juniorzy.
- Na żywo pokazany skill „teach”: agent buduje spersonalizowany kurs — z misją nauki, rejestrem postępów, lekcjami w HTML i quizami.
- Dwa typy skilli: procedury uruchamiane przez człowieka i zdolności wywoływane przez model — te drugie „wyciekają” opisami do okna kontekstowego.
- Setup Matta: Claude Code z Opusem 4.8, własne narzędzie Sandcastle do uruchamiania agentów w sandboxach oraz GitHub Actions i praca AFK, czyli beze mnie przy klawiaturze.
- Krytyka internetowej mody na „pętle agentowe”: lepiej myśleć o kolejce zadań z punktami kontrolnymi z człowiekiem, przesuwanymi coraz bliżej produkcji.
- Dobra architektura kodu pozwala pracować na tańszych modelach i mniej wydawać na tokeny.
- W budowaniu biznesu nic się fundamentalnie nie zmieniło: rozmawiaj z klientami i buduj to, czego potrzebują.
- Rada na start: skasuj wszystkie skille, wtyczki i MCP, obserwuj „czystego” agenta i świadomie dokładaj kolejne procedury.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Harness jest równie ważny jak model — myśl o tym jak o podziale 50/50
Na czym polega: Matt porównuje model do silnika bolidu Formuły 1: ważny, ale to tylko jeden element systemu. Druga połowa wyniku to harness — prompty, skille, środowisko wykonawcze i jakość bazy kodu. Nad harnessem masz pełną kontrolę, nad modelem — nie.
Jak stosować: Zanim zmienisz model na nowszy, zrób audyt otoczki: co poprawić w skillach, dokumentacji, architekturze i automatyzacji, żeby obecny model wyciągał więcej. Nowe modele testuj dopiero po kilku tygodniach od premiery, gdy opadnie szum.
Na co uważać: Na pułapkę „gorzkiej lekcji” — przekonanie, że skoro modele i tak będą lepsze, to nie ma sensu nic optymalizować. Matt uważa, że czekanie z założonymi rękami niczego nie buduje.
2.AI przejęło programowanie taktyczne — twoją wartością jest strategia
Na czym polega: Według podziału z „A Philosophy of Software Design” programowanie taktyczne (pisanie kodu, walka ze składnią, błędy na bieżąco) zostało wchłonięte przez AI, bo robi to taniej. Zostaje programowanie strategiczne: architektura, interfejsy między modułami, kierunek i tempo.
Jak stosować: Traktuj agentów jak nieskończoną flotę juniorów i deleguj tak, jak dobry lead: zadania z jasnym zakresem, trudne fragmenty projektowane z góry, porządne testy i dokumentacja wskazująca miejsca zmian.
Na co uważać: Nie deleguj myślenia strategicznego. Wizja produktu, mapa drogowa i kluczowe decyzje projektowe mają zostawać u ciebie — oddaj tylko taktykę.
3.Twoje umiejętności są sufitem tego, co zdziała AI
Na czym polega: AI działa jak mnożnik kompetencji: seniorom daje ogromny wzrost, juniorom niewielki. Subskrypcje i narzędzia kupi każdy — przewagę daje wyłącznie biegłość we własnej dziedzinie.
Jak stosować: Inwestuj w głębokość w swojej domenie — lepszy nauczyciel użyje AI do uczenia lepiej niż przypadkowa osoba. Luki domykaj narzędziami w duchu skillu „teach”, który buduje kurs wokół twojej misji i rejestruje postępy.
Na co uważać: Zmiana narzędzi co tydzień daje złudzenie postępu, a w rzeczywistości nie buduje żadnych umiejętności.
4.Lepsza architektura kodu to tańszy model i niższy rachunek za tokeny
Na czym polega: Baza kodu, w której łatwo wprowadzać zmiany, pozwala celować w tańsze modele: lepsze „poręcze”, mniej wydawanych tokenów na walenie głową w ścianę.
Jak stosować: Zamiast dopasowywać prompty do kaprysów modelu, ułatw modelowi pracę: czytelna struktura, testy, dokumentacja wystarczająca, by agent trafił we właściwe miejsce.
Na co uważać: Jeśli od pierwszego dnia utrudnisz agentowi życie chaotyczną bazą kodu, skazujesz się na najdroższe modele — bo tylko one poradzą sobie z bałaganem.
5.Dwa typy skilli: procedury sterujesz ty, zdolności wywołuje model
Na czym polega: Procedury uruchamiasz sam („grill me”, pisanie PRD, rozbijanie na zadania); zdolności — jak standardy kodowania — model sam dociąga w trakcie pracy. Każda zdolność „wycieka” swoim opisem do okna kontekstowego.
Jak stosować: Stawiaj na procedury. Skille, których używasz wyłącznie sam, oznaczaj flagą wyłączającą automatyczne wywoływanie — ich opisy nie zanieczyszczają wtedy kontekstu.
Na co uważać: Sto zainstalowanych skillli to sto opisów w kontekście. Wiedzę o swoim arsenale trzymaj w sobie, a nie w oknie kontekstowym modelu.
6.Zanim zbudujesz — daj się przesłuchać
Na czym polega: Krótki skill „grill me” zamienia model w dociekliwego, przeciwnikowego rozmówcę, który zadaje pytania, dopóki nie osiągniecie wspólnego zrozumienia pomysłu — lepszy odpowiednik trybu planowania.
Jak stosować: Opisz wizję, poproś o listę dziesięciu najbardziej brzemiennych w skutki decyzji (projektowych, architektonicznych, produktowych) i każ dopytywać, dopóki model nie pojmie sprawy niemal w całości.
Na co uważać: Nie buduj aplikacji „jednym promptem” — pomijasz fazę wspólnego rozumienia i płacisz za to bugami oraz przepisanym kodem.
7.Proceduralizuj swoją pracę i podnoś poprzeczkę zespołu
Na czym polega: Tak jak powtarzalną funkcję wyciąga się do współdzielonej, tak dziś sprawdzone procedury — choćby sposób planowania — można zamienić w skill i rozdać zespołowi.
Jak stosować: Zauważ, co robisz setki razy, opisz raz, wersjonuj i pozwól zespołowi dokładać ulepszenia. Wszyscy pracują wtedy według jednego, sprawdzonego schematu.
Na co uważać: Wiedzę i umiejętności da się spakować w plik, ale mądrości — wiedzy, kiedy i w jakim kontekście coś robić — już nie. Tego nie zastąpisz paczką na GitHubie.
8.Praca AFK: usuń się z równania i pomnóż się
Na czym polega: Największy skok produktywności daje przejście z trybu „człowiek w pętli” do pracy AFK (away from keyboard, czyli z dala od klawiatury): wysyłasz agenta, a wracasz dopiero na przegląd gotowych rezultatów. Zamiast jednego siebie masz kilku.
Jak stosować: Uruchamiaj agentów w sandboxach (Docker lub Podman, np. przez narzędzie Sandcastle), równolegluj lokalnie albo na zdalnych sandboxach, łącz z GitHub Actions — choćby automatyczny agent reviewujący pull requesty — a commity ściągaj do lokalnego katalogu roboczego.
Na co uważać: Agent bez sandboxa potrafi skasować katalog domowy albo wyciec zmienne środowiskowe. Przygotowanie takiego setupu wymaga cierpliwości.
9.Kolejka zamiast pętli — z punktami kontrolnymi przesuwanymi na koniec
Na czym polega: Wirusowe „agentic loops” (w stylu pętli Ralpha) to w praktyce zwykli agenci AFK. Lepszy model to kolejka zadań: triage, etykieta „zbadaj”, implementacja, review, scalenie — a punkty kontrolne z człowiekiem przesuwasz coraz bliżej produkcji.
Jak stosować: Bug z telemetrii → natychmiastowe zgłoszenie → automatyczna eksploracja → ustrukturyzowana odpowiedź (naprawa od ręki czy potrzebny człowiek?) → implementacja → review → decyzja o scaleniu. Ty widzisz całą ścieżkę jednym rzutem oka, jeden klik od efektu zamiast całej sesji debugowania.
Na co uważać: Nie wywalaj wszystkich punktów kontrolnych — review daje też wgląd w system, który kod produkuje. Sprawdzaj próbki tego, co agent uznaje za bezpieczne do pominięcia, i reaguj na przyczyny: gdy model znajdzie lukę, wniosek brzmi „mój system powinien sam takich rzeczy pilnować”, a nie „model jest super”.
10.Zacznij od zera: usuń wszystko i obserwuj agenta
Na czym polega: Przeładowane okno kontekstowe — nadmiar skilli, serwerów MCP, plików CLAUDE.md i AGENTS.md — szkodzi bardziej niż pomaga.
Jak stosować: Skasuj wszystko, obejrzyj, jak agent radzi sobie w czystym trybie, a potem dokładaj wyłącznie procedury wybrane przez siebie i tylko te, których brak naprawdę odczuwasz. Instaluj w wersji, którą możesz modyfikować i testować.
Na co uważać: Nie przywracaj starych nawyków hurtowo — każda kolejna warstwa ma odpowiadać na konkretny, zaobserwowany problem. Samą implementację poprawek zlecaj agentom AFK.
Redakcyjne tłumaczenie
Zapowiedź: harness ponad model
(Fragment otwierający film — cytat z dalszej części rozmowy.)
Matt Pocock: Wszyscy są zakochani w modelu, a moim zdaniem powinni bardziej interesować się harnessem — całą otoczką wokół modelu: promptami, skillami i środowiskiem, w którym pracuje. Model jest użyteczny, ale harness wnosi równie wiele, a nad harnessem masz znacznie większą kontrolę niż nad modelem. Ludzie patrzą na niewłaściwą rzecz: wpatrują się w wielką, błyszczącą nowość, tymczasem wystarczy trzymać się tego, co działa od trzydziestu, czterdziestu lat — bo to naprawdę działa. Ludzie ciągle mnie pytają, jak zoptymalizować wydatki na tokeny. Odpowiedź: miej bazę kodu, w której łatwo się wprowadza zmiany.
Taktyczne kontra strategiczne programowanie
David Ondrej: Matt, co będzie główną różnicą między ludźmi, którzy dzięki AI ruszą z kopytem, a większością, która odnotuje tylko niewielki wzrost?
Matt Pocock: W książce „A Philosophy of Software Design” John Ousterhout rozróżnia programowanie taktyczne i strategiczne — i to rozróżnienie bardzo pomaga mi myśleć o AI. (Informacja dodatkowa: „A Philosophy of Software Design” to ceniona książka o projektowaniu oprogramowania, wydana w 2018 roku.) Taktyka to codzienna robota na froncie: samo pisanie kodu, męczenie się ze składnią, łapanie błędów na bieżąco, tworzenie commitów. Strategia to wygrywanie wojny, a nie bitwy — myślenie długoterminowe, generał siedzący na samej górze: jak ma wyglądać baza kodu, co podniesie tempo pracy zespołu? Dla mnie to zawsze była najciekawsza część — tak myślałem już jako junior: jak pracować szybciej, jak osiągać więcej mniejszym kosztem? A AI po prostu pochłonęło programowanie taktyczne. Koniec, nie ma go. Model robi to lepiej od ciebie, bo taniej. Żeby wyciągnąć maksimum z tej nieskończonej floty taktycznych programistów, którą właśnie dostałeś, musisz być świetny w tej strategicznej części.
David: Czyli umiejętność orkiestracji agentów plus fundamenty projektowania oprogramowania, architektury… Jak byś to rozbił na konkretne rzeczy, których można się nauczyć?
Matt: Świetne pytanie. Programowanie strategiczne przez AI właściwie się nie zmieniło. Zamiast delegować zadania juniorom i midom, delegujemy je AI — a do dobrej delegacji wciąż potrzebne jest to samo. Trudne fragmenty trzeba zaprojektować z góry. Zadania muszą być naprawdę dobrze określone. Trzeba myśleć o interfejsach między modułami, o sensownych testach. W praktyce: zaprojektuj kod, w którym łatwo się pracuje, i zostaw dokumentację wystarczającą, by wskazać AI właściwe miejsca zmian — tak, żeby umiało je wprowadzić skutecznie.
Twoje umiejętności są sufitem dla AI
David: Wszyscy się pewnie zgodzą, że rozwój AI jest szybki, a nawet przyspiesza. Przy okazji mnóstwo ludzi pomija podnoszenie własnych kompetencji. Subskrypcje może opłacić każdy, najnowsze narzędzia też — ale wciąż będą jedni, którzy użyją ich do ogromnego wzrostu biznesu i wydawania lepszego oprogramowania niż kiedykolwiek, i drudzy, którzy tylko trochę pobawią się darmową wersją albo tańszym modelem. Jak doradzałbyś, żeby zacząć samodzielnie się rozwijać?
Matt: Ludzie ciągle mnie o to pytają — a ja sprzedaję kursy dla programistów, więc możesz moją opinię brać z przymrużeniem oka. Osobiście uważam, że moje umiejętności są mnożnikiem dla AI. Jeśli potrafię nadzorować bazę kodu, wiem, jak coś powinno być zbudowane, i po prostu mówię AI, jak to zrobić, to model ma o nieporównanie bogatszy kontekst do pracy. Widzę to wszędzie — CTO-i i ludzie, z którymi rozmawiam na konferencjach, powtarzają: AI robi z seniorów dziesięciokrotnie lepszych. I właściwie przestaje mieć sens zatrudnianie tylu juniorów, bo junior dostaje z AI niewielki wzrost, a senior — absurdalnie duży i może zrobić o niebo więcej. Twoje umiejętności są sufitem tego, co AI potrafi. Jeśli są niskie, model tego sufitu nie przebije. Dobrze używać AI to tak naprawdę dobrze znać swoją dziedzinę — tę, którą AI ma dla ciebie wykonywać. Lepszy nauczyciel nauczy z AI lepiej niż przypadkowa osoba. Umiejętności są dziś ważniejsze niż kiedyś, bo masz pod ręką mnożnik i możesz więcej delegować.
Skill „teach” na żywo: nauka jak u prawdziwego nauczyciela
David: Właśnie wydałeś nowy skill „teach”. Możesz o nim opowiedzieć?
(Informacja dodatkowa: w tym miejscu film zawiera wstawkę sponsorowaną serwisu SerpApi, zwracającego przez API ustrukturyzowane wyniki wyszukiwania; treść reklamy pomijamy.)
Matt: Znam się na nauczaniu — robię to od dziesięciu lat. Zaraz po studiach uczyłem śpiewu i emisji głosu, potem zostałem programistą, a od czterech lat uczę programistów. Pomyślałem: co jeśli wezmę znane mi zasady dydaktyki — na przykład strefę najbliższego rozwoju albo różnicę między wiedzą, umiejętnościami i mądrością — zakoduję w skillu i użyję do tworzenia kursu na żywo o dowolnym temacie? I to zrobiłem, a to działa fenomenalnie. Nauczyłem się w ten sposób układania kostki Rubika — umiem ją dziś ułożyć z pamięci. Używam tego do wszystkiego. Wczoraj testowałem, co wyjdzie, gdy zapytać skill „teach”, jak zostać seniorem. Ruszył w dużą wyprawę po zaufanych źródłach, złożył całe curriculum i wyprodukował coś pięknego.
David: Zróbmy to na żywo!
Matt: Okej. David, czego chcesz się nauczyć?
David: Może projektowanie systemów?
Matt: Mam pomysł. Do mnie przychodzą w zasadzie inżynierowie — ludzie, którzy już umieją swoją robotę. Ciekawi mnie, czy ten skill potrafi nauczyć podstaw inżynierii: domknąć luki, jakie ma na przykład vibe coder. (Informacja dodatkowa: „vibe coding” to pisanie oprogramowania głównie przez rozmowę z AI, przy minimalnej własnej wiedzy inżynierskiej.) Więc udaję vibe codera. Jestem w pustym katalogu i po prostu puścimy to samo. Zaraz nadiktuję prompt: „Jestem vibe coderem i chcę domknąć luki w wiedzy, żeby wydawać lepsze oprogramowanie. Znam bardzo podstawowe komendy wiersza poleceń, umię mniej więcej czytać kod i korzystać z terminala — i to wszystko. Czego powinienem się nauczyć dalej?”
David: Prosty prompt, zwykłym językiem. Każdy mógłby o to zapytać.
Matt: Dokładnie. Bardzo proste żądanie. Nie mówię o przedmiocie nauki, tylko o swojej misji — o tym, co chcę wynieść, po co w ogóle przyszedłem dziś do nauczyciela. Można na to patrzeć jak na współpracę: agent jest moim nauczycielem i to on powinien wiedzieć, jak nauczyć mnie najlepiej.
David: Świetnie się składa, że wydałeś ten skill właśnie teraz, bo dosłownie wczoraj myślałem o tym samym — zwłaszcza gdy wyszedł Fable. Jak podnieść własne kompetencje, żeby z niego wyciągnąć maksimum? Wiem, że nie jestem tam, gdzie mógłbym być — są ludzie ode mnie lepsi.
Matt: No dobrze. Skill właśnie pisze: sprawdziłem przestrzeń roboczą — czysta kartka. Trzeba go uruchamiać w workspace, bo zapisuje tam mnóstwo informacji. I czyta: „Dla vibe codera, który czyta kod i obsługuje podstawowy terminal, najbardziej opłacalna luka to prawie nigdy kolejna porcja składni. To wszystko, co otacza kod i pozwala wydawać bez strachu.” Sto procent prawdy. Git, czytanie błędów, debugowanie, jak oprogramowanie faktycznie trafia na produkcję, testowanie — zaczynamy od gita. Ale najpierw misja. Nie chcę zgadywać — trzy krótkie pytania. Pierwsza rzecz, jaką robi skill, to dopasowanie się do tego, co chcesz osiągnąć. Myślę o nauce nie jako o wpompowywaniu informacji do głowy, tylko o stawianiu cię w nowym miejscu w świecie. Brzmi to abstrakcyjnie, wręcz duchowo, ale chodzi o prozą rzecz: uczysz się po to, żeby coś zrobić, i to jest twoja misja. Co budujesz? Co oznacza dla ciebie „lepsze oprogramowanie” właśnie teraz? Nad jakim konkretnym projektem pracujesz?
David: Wyobraźmy sobie moją odpowiedź. Jestem — bo taki kiedyś byłem — nauczycielem śpiewu i głosu. Chcę zbudować aplikację do umawiania lekcji z uczniami i prowadzenia notatek o nich, żeby lepiej uczyć, plus coś, przy czym mogliby ćwiczyć. Chodzi o pełnostackową aplikację z bazą danych i logowaniem — ale to dziś daleko ponad moje siły. Aha, dyktuję to przez Whisper Flow, jest świetny.
Matt: To zresztą też gra o tempo: jak szybko potrafisz przelać tokeny z głowy na zewnątrz i z powrotem do głowy.
David: No właśnie, mała dygresja o dyktowaniu: kto nie dyktuje, ten zostaje daleko w tyle. Mnie samo idzie szybko, bo mówię płynnie i dobrze przekładam myśli na słowa.
Matt: Ale to umiejętność — da się nauczyć werbalizować myśli lepiej i szybciej.
David: Dokładnie, i to umiejętność absurdalnie mocna u dewelopera. Zawsze miałem wrażenie, że komunikatywność to w świecie programistów kartowy as — i się to potwierdziło.
Matt: No i skill właśnie utworzył plik mission.md. Zapisuje: kim jest ta osoba, co chce zbudować, dlaczego to ważne, jak wygląda sukces — wydać aplikację, nie zepsuć jej, doprowadzić do żywych użytkowników i ufać, że działa dla prawdziwych uczniów. To będzie teraz porządkować wszystko, co skill robi dalej. Widzisz, że wykonuje wyszukiwania — szuka zaufanych źródeł o pełnostackowych aplikacjach webowych, frontendach i backendach. Zapowiada: przygotuję ci zasoby do nauki, rejestr postępów, ściągi referencyjne i pierwszą lekcję. I zacznie wypluwać materiał — lokalnie. Bo rozróżniam skille bezstanowe, które niczego nie muszą zapamiętywać, od stanowiskich — takich, które polegają na informacji trzymanej lokalnie. „Teach” jest stanowiskowy: pomyśl o pracy z świetnym nauczycielem — pamięta, co robiłeś wcześniej, wie, dokąd masz iść dalej, zna twoją misję. Skill zapisuje stan, żeby wszystko pamiętać. Najpierw stworzył ściągę referencyjną, teraz tworzy pierwszą lekcję — w HTML, żeby otworzyć ją w przeglądarce i mieć naprawdę bogaty materiał. Bo nauka w terminalu to po prostu mordęga.
David: Korzystasz z Claude Code z Fable, tak?
Matt: Używam Claude Code z Opusem 4.8 w trybie „medium effort” — średnim poziomie wysiłku obliczeniowego. Fable jeszcze nie, bo nie zdecydowałem, czy w ogóle w niego wchodzić.
David: Serio?
Matt: Nie wierzę w ten cały szum. Wczoraj to wyszło i hałas jest niewiarygodny — ludzie załatwiają jednym promptem to i tamto. Tak, wygląda na skok jakościowy, wydaje się trochę lepszy. Ale trzeba to odważyć przeciw kosztowi tokenów, dostępności i opóźnieniom. Wolę nie testować nowego modelu zaraz po premierze i poczekać z miesiąc, aż się wszystko ułoży. Tak zrobiłem z Opusem 4.5 — ostatnim modelem, który wywarł na mnie naprawdę duże wrażenie — i niczego nie straciłem.
Jak powstają lekcje: misja, rejestr nauki, quizy
David: To jest plik, który powstał?
Matt: To lekcja pierwsza: „Zdobądź przycisk cofania dla swojego projektu”. W HTML jest o niebo bogatsza i przyjemniejsza niż w terminalu. Zapisana lokalnie, więc zawsze możesz do niej wrócić. Daje konkretne ćwiczenia do wykonania w terminalu: załóż folder, wejdź do niego, zainicjuj gita, stwórz plik, sprawdź status, przenieś zmiany do poczekalni, zapisz migawkę. I oczywiście, skoro działa na moim systemie, zna mój setup — pewnie już sprawdził, czy mam gita. Idealnie spersonalizowana edukacja.
David: W pełni spersonalizowana.
Matt: Dokładnie. „Która komenda zapisuje migawkę twoich zmian?” — David, odbierzesz to dla mnie?
David: Komenda zapisująca migawkę zmian… git commit.
Matt: Git commit, brawo. Znów wchodzi na techniki dobrze znane w dydaktyce, wzmacniające trwałość śladu pamięciowego. Quizy są tak niezręczne — szczerze ich nie znoszę — a jednocześnie niebezpiecznie skuteczne. „Jaka komenda pokazuje, co się właśnie zmieniło?”
David: Git status… ojej, kliknąłem nie tak.
Matt: Git status. „Co robi git add ze zmianą?”
David: Przenosi ją do poczekalni.
Matt: „Commit najlepiej wyobrażać sobie jako…”?
David: Punkt zapisu.
Matt: „Zepsułeś plik, ale nie zrobiłeś commita. Czym go przywrócisz?”
David: Eee… git restore? Chyba?
Matt: Zgadza się. Bardzo dobrze. Potem odsyła cię — jeśli masz ochotę — do źródła pierwotnego, książki Pro Git, i zaprasza do zadawania nauczycielowi pytań oraz tworzenia następnej lekcji. Myślę o wiedzy jak o grafie: wielkim lesie, przez który wędrujesz. A to tworzy liniową ścieżkę przez ten graf: „tego się nauczyłeś, wiem o tym — jest w twoim rejestrze nauki”. Widać go w rogu ekranu: misja, punkt startowy, decyzja o rozpoczęciu od gita, strefa najbliższego rozwoju, bieżące szacunki… Uwielbiam to. I polecam każdemu, kto zaczyna — zwłaszcza w programowaniu. Jestem deweloperem, wiem, jak wygląda edukacja programistów, i to właśnie włożyłem w ten skill. Zawsze uważałem, że nauczenie się kodowania jest łatwe — sam nie miałem z tym problemów — i myślę, że to znakomita droga.
David: To jest gdzieś na GitHubie? Gdzie ludzie mogą to znaleźć?
Matt: GitHub, moje repozytorium skilli. Wystarczy jedna komenda w CLI, wybierasz skill „teach” i zapisuje się lokalnie. Działa z Claude Code, z Codex — a potem wywołujesz po prostu „teach” w świeżym workspace.
Co odróżnia dobry skill od złego
David: Masz chyba jedno z najbardziej znanych repozytoriów skilli. Więc: co odróżnia dobry skill od złego?
Matt: To pytanie na lata — bo zależy, czego chcesz. Można wyróżnić dwa typy skilli: procedury, które zamierzasz uruchamiać sam, i zdolności, które model ma wywoływać z własnej inicjatywy. Dobrą zdolnością mogą być na przykład twoje standardy kodowania. Agent sobie pracuje, ma napisać kod w Reakcie, więc sięga po zdolność „standardy kodowania React”, czyta ją i rozumie: „aha, nie używam tutaj useEffect, tylko czegoś innego”. Procedura natomiast to coś, co uruchamiasz sam, żeby model zachowywał się w określony sposób. Moją ulubioną jest „grill me” — jeden z moich najpopularniejszych skillów. Zamienia model w dociekliwego, przeciwnikowego rozmówcę. Jest niesamowicie krótki — dosłownie cztery, może pięć zdań — a działa znakomicie, bo zmusza agenta, żeby cię przesłuchiwał, zadawał pytania i wyciągał pomysły, o których byś nie pomyślał, dopóki nie osiągniecie wspólnego zrozumienia. Używam tego przy kodowaniu przede wszystkim zamiast trybu planowania: zanim coś zaimplementujesz, mówisz „oto mój pomysł — przesłuchaj mnie, osiądnijmy wspólne zrozumienie, wyłapmy dziwactwa, zanim wejdziemy głęboko”. I to jest niebezpiecznie skuteczne. A to procedura, nie zdolność.
Wolę moje skille jako procedury. Lubię rządzić: „robię grill me, potem piszemy dokument wymagań produktu, potem rozbijamy go na pojedyncze zadania i przechodzimy przez nie po kolei”. Tak lubię pracować ja. Ale inne skille — jak superpowers od Obry, chyba najpopularniejsze repozytorium skilli — robią odwrotnie i wolą, żeby rządził model. Ja zawsze wolałem mieć kontrolę, bo znam swoje skille i swoje możliwości. Nie chcę delegować myślenia modelowi.
David: To jeden z elementów listy, którą ostatnio kombinuję. Weź średniego dewelopera używającego AI na poziomie „sto razy więcej” i zwykłego — jaka byłaby lista różnic? Część to surowa inteligencja, ale większość da się pewnie nauczyć: jakieś umiejętności, jakaś wiedza. Jedna z nich to właśnie wyczucie, kiedy kazać AI pytać ciebie — ten styl „grill me”. Bo zamiast mówić „zbuduj mi tę aplikację jednym promptem” opisuję wizję i mówię: „wypisz dziesięć najbardziej brzemiennych w skutki decyzji — projektowych, architektonicznych, produktowych — które ukształtują ten projekt, i przesłuchuj mnie, dopóki nie zrozumiesz sprawy w dziewięćdziesięciu ośmiu procentach”. Co jeszcze byłoby na tej liście?
Matt: Mogę podważyć samą możliwość stworzenia takiej listy? Bo skille są bardzo trudne do pisania — zwłaszcza że każdy skill wycieka swoim opisem do okna kontekstowego. Da się to wyłączyć: mam w swoim skillu „engineering zoom out” flagę wyłączającą wywoływanie przez model — ten skill może uruchomić wyłącznie użytkownik, więc jego opis nie trafia do kontekstu. Każda zdolność wycieka. Jeśli masz listę stu skillów, do okna kontekstowego wycieka sto opisów.
David: Okej, przeformułuję. Nie chodziło mi o listę dla AI, tylko o listę cech człowieka. Gdyby opisać ludzi naprawdę niewiarygodnie produktywnych — czołówkę z OpenAI czy Anthropic, wartych setki zwykłych deweloperów — jaka byłaby lista ich zdolności i wiedzy na tle przeciętnego?
Matt: Rozumiem — i w sumie zmierzasz w moją stronę. Wolę ukrywać większość tych opisów przed samym AI i trzymać tę wiedzę w człowieku, w deweloperze. Wolę, żebyś to ty siedział za kierownicą. To niesamowity czas na bycie seniorem: można zamieniać własną pracę w wielokrotnego użytku procedury. Jak w kodzie funkcja powtarza się trzy razy — wyciągasz ją do wspólnej i ograniczasz duplikację. Teraz to samo możemy robić z własnymi procedurami: „robiłem ten plan sto razy, umiem robić dobre plany — zamienię to w skill, roześlę zespołowi i wszyscy będą planować tak samo, dokładając ulepszenia do tego samego pliku”. Podnosisz w ten sposób dolną granicę tego, co potrafi zespół inżynierów. Powiedziałbym jednak — i tu trochę pomieszam terminologię — że do czegoś dobrego potrzebujesz trzech rzeczy: wiedzy, czyli rozumienia rzeczy w głowie; umiejętności, czyli zrobienia tego wiele razy, do pamięci mięśniowej; i mądrości — wiedzy, kiedy to zrobić i jak to się ma do prawdziwego świata. A mądrości prawie nie da się zdobyć bez zrobienia tej rzeczy dokładnie w kontekście, w którym trzeba ją robić. Chcesz pracować na poziomie ludzi z Anthropic? Wiedzę i umiejętności zdobędziesz, ale skąd weźmiesz mądrość? Pewnie musiałbyś tam pójść. Ale samo to, że możesz spakować pierwsze dwa — wiedzę i umiejętności — w coś wielokrotnego użytku, to fascynujący owiot tego dziwnego czasu, w którym żyjemy.
Setup agentowy: Sandcastle, sandboxy, GitHub Actions
David: Dobrze, o skillach już wiemy. Jak wygląda twój setup agentowy? Jakie narzędzia, jakie modele, ilu agentów?
Matt: Używam Claude Code zasadniczo do planowania i części implementacji lokalnie — Opus 4.8, medium effort, na tym osiadłem i działa dobrze. Większość developmentu i sporo pracy robię teraz AFK — z dala od klawiatury — i służy do tego narzędzie, które sam zbudowałem: Sandcastle. To sposób na uruchamianie agentów w sandboxach. Bo jeśli nie puścisz agenta w sandboxie, będzie robił dziwne rzeczy: może na przykład skasować ci katalog domowy albo wyeksportować zmienne środowiskowe na podejrzane strony. Z Sandcastle podłączasz Dockera albo Podmana i uruchamiasz agentów — na przykład Claude Code w odizolowanym środowisku. Bardzo fajne i bardzo skuteczne, a do tego można równolegle odpalić wielu agentów: na własnej maszynie albo przez zdalne sandboxy, gdzie stawiasz agenta w chmurze i ściągasz commity z powrotem do lokalnego katalogu. Ja łączę to jeszcze z GitHub Actions. W zakładce actions repozytorium Sandcastle widać na przykład agenta review, który odpala się przy pull requeście: pobiera brancha, uruchamia agenta do przeglądu — czyli po prostu prompt, który mam lokalnie — widać wszystko, co sprawdził, kontrola typów czysta, i na koniec odpowiada: „spoko, wszystko wygląda dobrze”. Tak w większości teraz pracuję: agenty przez Sandcastle i GitHub Actions, a ja im po prostu mówię, co robić. I to jest niebezpiecznie skuteczne, bo równolegle możesz uruchomić, ile chcesz, nie martwisz się o zasoby lokalnej maszyny, a odpalenie agenta do zadania trwa chwilę.
David: A modele? To jest wersja 5.5 na najwyższym wysiłku? Co wolisz?
Matt: To znowu zwykły Claude Code, Opus 4.8, medium. Szczerze, niewiele zmieniam. Modelami w ogóle się nie przejmuję. I to jest moja prowokacyjna teza: wszyscy są zakochani w modelu — wszyscy są zakochani w silniku bolidu Formuły 1. Tymczasem silnik to tylko część systemu: masz całe nadwozie, masz to, jak auto przecina powietrze. Model jest użyteczny, ale harness wnosi równie dużo pracy — a nad nim masz znacznie większą kontrolę.
Spór o model: „gorzka lekcja” i fundamenty
David: To prawda, ale trochę się z tobą pokłócę, bo nie widzę, czemu nie robić obu naraz. Zgadzam się, że potrzebujesz właściwych skilli i setupu — ale jeśli wsadzisz lepszy silnik, wszystko to samo staje się od razu lepsze, nie?
Matt: Zdecydowanie. Ale traktuj to jako podział 50/50, a nie dziewięćdziesiąt procent model i dziesięć optymalizacji. Bo wszyscy tak skupili się na modelu… Wróćmy krok. Znasz „gorzką lekcję”, bitter lesson?
David: Tak.
Matt: To idea, że cokolwiek robisz w badaniach nad uczeniem maszynowym, surowa moc obliczeniowa prędzej czy później cię pokona, bo rośnie tak szybko, że możesz po prostu ufać, że fundament będzie lepszy i przebiję wszelkie optymalizacje nakładane z wierzchu. I jest taka obawa, że właśnie wpadam w tę gorzką lekcję: że zamiast optymalizować swój setup, powinienem czekać na lepsze modele — lepszy silnik — i wtedy mój bolid pojadę szybciej. Nie wiem. Nadal uważam, że bardzo dużo zyskasz, optymalizując harness i budując bazy kodu, w których agent radzi sobie dobrze — zamiast obcinać mu skrzydła, zanim wystartuje.
David: Zgadzam się, że nie powinno się czekać — siedzenie z założonymi rękami i czekanie na AGI to bardzo głupi pomysł. Jestem gdzieś pośrodku: codziennie aktywnie poprawiam swój setup, przyspieszam pracę z agentami — czy podłączyć tu narzędzie do orkiestracji, postawić coś na serwerze, użyć Tailscale — czyli poprawiam wszystko poza modelem, ale jednocześnie używam najlepszego możliwego modelu. Bo jeśli dla uproszczenia mówimy o 50/50 — co, gdy model naprawdę stanie się dużo lepszy? Następna generacja: Opus 6, Fable 6, GPT 6, 7, cokolwiek. Czyż te modele nie będą wymagały mniej prowadzenia za rękę, im będą kompetentniejsze?
Matt: Nie jestem komentatorem — to mówię przy każdym takim pytaniu. Staram się jak najlepiej wykorzystać to, co mam teraz. Nie mam wglądu w to, czy te rzeczy będą lepsze, i nie chcę robić prognoz. Myślę, że jeśli będę trzymał swój katalog roboczy i harness tak niezależnym od konkretnego modelu, jak się da, jeśli będę stosować dobre fundamenty inżynierii oprogramowania i robić rzeczy, które zawsze działały — to prawdopodobnie będą działać i dalej. A jeśli zacznę się nadmiernie optymalizować pod jeden model, stracę z oczu fundamenty. Taki jest mój punkt widzenia.
David: Czyli skupiasz się na tym, co było prawdą przez ostatnie dziesięć, dwadzieścia, trzydzieści lat — na najlepszych zasadach dobrego oprogramowania — i one raczej się ostoją przy następnym modelu. Zamiast podejścia „od modelu”: ten wymaga krótszych promptów, ten jest słaby w tej części, więc załatam tę część. Fundament najpierw, model potem. Może?
Matt: Dokładnie. Ludzie patrzą na niewłaściwą rzecz: wpatrują się w wielką, błyszczącą nowość, a wystarczy trzymać się tego, co działa od trzydziestu, czterdziestu lat — bo to naprawdę działa. Ludzie ciągle pytają: jak zoptymalizować wydatki na tokeny? Mieć bazę kodu, w której łatwiej wprowadzać zmiany. Bo wtedy możesz zatrudnić głupszy model. Przy lepszej architekturze tańszy model zrobi tę samą robotę — poręcze są lepsze, łatwiej eksplorować, mniej tokenów schodzi na walenie głową w ścianę. Jeśli od pierwszego dnia obcinasz agentowi skrzydła, będziesz potrzebować mądrego modelu, żeby w ogóle coś z tego wyciągnąć. Myślenie od modelu to zły kierunek.
David: Czyli kwintesencja odwrotności twojego podejścia to pierwotny vibe coder, który co tydzień zmienia narzędzie: aktualizacja Replit — idzie do agenta Replit, potem Lovable, potem coś jeszcze — ciągle się przełącza i nigdy nie nauczy się żadnych zasad programowania, niczego z inżynierii oprogramowania. A ty przecież wierzysz w AI po uszy i uczysz innych, jak z niego korzystać. Chodzi o różnicę podejścia: „nauczcie się fundamentów, jak działa kod, jak wygląda dobre oprogramowanie — to będzie cenne niezależnie od wszystkiego, czy przewodzi OpenAI, Anthropic czy Gemini”. Kontra skakanie na każdy trend i przepinanie wszystkiego, gdy tylko wyjdzie aktualizacja albo narzędzie.
Matt: Zupełnie. Możesz tak żyć i to ekscytujące, ale w ten sposób nie budujesz swoich umiejętności. A to twoje umiejętności — tego jestem pewien — są sufitem tego, co potrafi AI. Skup się na sobie: podnoś kompetencje na ten nowy świat zamiast szukać, jak oddelegować własne myślenie. Wciągaj więcej do swojej domeny i oddawaj tylko taktykę. Zachowaj strategiczny umysł: myśl o najbliższych tygodniach i miesiącach, o mapie drogowej kodu — zamiast delegować to dalej. Ludzie są zafiksowani na idei, że można oddelegować wszystko. A nie można. Naprawdę nie można.
David: Zgadzam się — ja jestem człowiekiem w realnym świecie, który tym steruje. To ja muszę podejmować decyzje produktowe, ja wiem, dokąd zmierzam. Jako deweloper powinienem mieć kontrolę, a do tego potrzebuję umiejętności. Dam ci jeszcze jedną historyjkę o Fable, bo wyszło wczoraj — coś trochę niepokojącego i zdecydowanie nie idącego po linii dobrych praktyk bezpieczeństwa. Konfigurowałem nowego agenta do Twittera i API było zbugowane: konsola deweloperska nie ładowała przycisków. Próbowałem w innej przeglądarce — nic. Wyłączyłem wszystkie rozszerzenia — nic. Dałem temu kilka porządnych minut debugowania i przegrałem. Nie było to główne zadanie dnia, więc nie szarpałem się na maksa — podałem to Cursorowi napędzanemu Fable. Użył wbudowanej przeglądarki, ja musiałem się tylko zalogować do konsoli, a potem zaczął klikać. Utworzył klucze API i skopiował je — zastrzegam, nie polecam tego przy aplikacjach produkcyjnych, to była drobnostka. Potem wykrył przy testach, że klucze trafiły do innej aplikacji w konsoli i nie korzystają z doładowanych przeze mnie kredytów, więc przeniósł aplikację — znowu sam, przez wbudowaną przeglądarkę. I siedzę tak i myślę: co ja tu w ogóle robię? Opisałem, co budujemy i po co, zrobiłem swoją wersję grill me na start — ale potem się zalogowałem, doładowałem kilka dolarów i wszystko inne robiło AI. Czułem, że moja wartość w tym projekcie była dużo niższa niż przy poprzednich modelach. Co o tym myślisz?
Matt: Pomyśl, co AI tam właściwie robiło — i skąd wie, że na końcu zrobiło dobrą robotę. Teoria, że możesz całkiem zniknąć z projektu? Nie, wciąż jesteś potrzebny. Zrobiliśmy jedno: daliśmy AI zestaw narzędzi, dobrze określone zadanie i cel — „zrób to i tamto”. Nie uważam, żeby to było szczególnie magiczne. Agenty po prostu potrafią to dziś wykonywać: dostają narzędzia i działają. Ale ocenić, czy to była właściwa rzecz, i przeprowadzić na końcu test bezpieczeństwa — do tego ty jesteś potrzebny, David. Możemy delegować więcej, ale to nie powód, żeby wpadać w „AI-psychozę”. To po prostu rozsądna rzecz, którą AI potrafi zrobić, sterując interfejsem komputera.
David: Widziałem też sporo osób, które — znowu mówię o Fable, bo wyszło wczoraj i mam to świeżo w głowie — zgłaszały, że znajduje głębsze bugi, których zupełnie nie zauważali, a inne modele je pomijały. I tu bym się znowu z tobą przekłócił, że to znak AI robiącego więcej. Nie mówię, że mamy zniknąć z procesu, ale jeśli AI przeprojektowuje frontend i przy okazji znajduje poważną lukę bezpieczeństwa w endpointach backendu — to już nie jest 50/50. To AI jest bardziej zaangażowane.
Matt: Czyli mówisz: im lepszy silnik, tym więcej wartości dla biznesu płynie z samego jego posiadania — a te efekty są nieprzewidywalne, nie wiesz, co dostaniesz, zwiększając jego moc.
David: On wciąż zna wizję. Wie, że to repo edukacyjne dla studentów mojej płatnej społeczności albo narzędzie dla pięciu osób w zespole, zna cel. Inicjatywa wciąż pochodzi ode mnie. Ale jeśli chodzi o same działania — moim argumentem byłoby, że im modele mocniejsze, tym więcej z tego zrobi AI. I nie tylko: AI samo zauważy, co trzeba zrobić, jak w przykładzie z głębokimi bugami, których nikt nawet nie szukał.
Matt: Zupełnie — ale myślimy, że model to jedyna droga do tego celu. A możesz w swoim repozytorium odpalić cykliczne zadanie, które codziennie robi przegląd bezpieczeństwa i codziennie sprawdza inną część kodu. Przy dość prostym modeliu pewnie dostałbyś przyzwoite wyniki. Ta narracja, że istnieją głębokie luki, które jeden model widzi, a inny nie — brzmi atrakcyjnie, ale prawdopodobnie odkryłbyś je tańszymi modelami, gdybyś patrzył we właściwe miejsca i dał im właściwy harness. Nie ma w tym nic szczególnie specjalnego. I znowu: 50/50. Gdybyś miał harness, który patrzy właśnie na te rzeczy, znalazłbyś je. Po prostu zaniedbujemy nasze praktyki i oczekujemy, że model nadgoni. Możesz spokojnie odpalić Opusa i kazać mu to robić. Tak samo ludzie mówili przy debiucie Opusa 4.5: „o, jakie znaleziska bezpieczeństwa!”. No i co — znalazł je, ale to samo dostaniesz z harnessem, tylko uruchamianym regularnie.
David: Rozumiem — płyniesz przeciw fali hype’u i próbujesz wpuścić w to rozsądek: modele robią się lepsze, tak, ale nie gubmy oczywistych optymalizacji i odwiecznych prawd. Może przy lepszym harnessie wystarczyłaby poprzednia generacja modelu. Może nie musiałbyś wydawać dwóch tysięcy dolarów na tokeny, tylko dwieście. Tu się z tobą w pełni zgadzam.
Matt: Jedna rzecz na zamknięcie tego wątku: czego naprawdę nauczyła cię sytuacja, w której Fable spojrzał na twój kod i znalazł lukę bezpieczeństwa? Nauczyła cię, że Fable jest dobry — na pewno. Ale też że w twoim kodzie są luki bezpieczeństwa — i że przydałoby się coś, co będzie ich szukać także w przyszłości. Musimy budować w naszych systemach mechanizmy samonaprawy. Musisz zrozumieć, dlaczego to się w ogóle zdarzyło. Jak ciągle kradną ci rower — może kup w końcu zamek.
David: Dokładnie. Może musimy projektować systemy, które same się doskonalą. Robimy to jako inżynierowie od dawna: suite’y testów, żeby testować własny kod; przeglądy przez ludzi, żeby pilnować jakości; refaktoryzacje, żeby łatwiej zmieniać kod w przyszłości. Model odkrył, że powinniśmy robić tego więcej — to zróbmy więcej. Ale nie potrzebujemy najnowszego modelu, żeby dojść do tych wniosków. I to wpisałbym na tę listę: to naprawdę odróżnia ludzi, którzy z AI polecą i zbudują więcej i lepiej, od reszty. Większość w takiej sytuacji mówi: „o, Fable jest super, napraw buga” — i bug jest naprawiony. A tamten człowiek — nie wiem, czy to jeszcze „10x developer”, to już raczej „10x budowniczy z AI”, bo wszyscy stają się budowniczymi, zarówno z designu, jak i z developmentu — patrzy na przyczyny: jak to się stało, że ten bug istniał tak długo i nikt go nie widział? I łata problem u źródła: nowym skillem, nowym systemem, lepszym procesem. To wpisałbym na listę ludzkich zdolności, które trzeba mieć, żeby wyciągnąć z AI maksimum.
Matt: W pełni się zgadzam.
Pętla czy kolejka?
David: Wspomniałeś o pętlach — to było superpopularne na Twitterze, może wciąż jest, z tydzień temu. Zaczęło się, o ile dobrze kojarzę, od Petera Steinbergera. Ludzie obsesyjnie debatują o pętlach agentowych. Połowa tego to moim zdaniem laboratoria sprzedające więcej tokenów: „przestańcie promptować swoich agentów, znajdźcie pętle, które mogą biegać w nieskończoność” — czyli płaćcie nam w nieskończoność. Połowa może być użyteczna. Co myślisz?
Matt: Mówimy naprawdę o różnicy między pracą z człowiekiem w pętli a pracą AFK. Ta pierwsza: jesteś z agentem, rozmawiacie, coś odkrywacie — świetna do planowania, do bardziej złożonych implementacji, do zadań bez określonego zakresu, które trzeba po prostu rozgryźć na miejscu. A potem mamy AFK: wysyłasz agenta, a on idzie i coś robi. Moment, w którym odkryłem AFK, to moment, w którym naprawdę wskoczyłem w kodowanie z AI — bo dopiero wtedy dramatycznie zwiększyłem wydajność. Zamiast siedzieć w pętli i obsługiwać prośby o uprawnienia oraz wszystkie pytania agenta — w chwili, gdy mogę się usunąć z równania, mnożę się. Nagle jest dwóch mnie, trzech, czterech, pięciu — i produkują o wiele więcej kodu, który ja potem przeglądam. Idea, że pętle to jedyna droga, to absurd. Historia tego sięga Geoffreya Hunta — pamiętasz Ralpha? Mówiłem o nim w styczniu. Oryginalny artykuł pochodzi z czternastego lipca zeszłego roku. To w istocie pętla: przekaż ten prompt do Claude Code i w końcu będziesz skończony — czyli uruchamianie Claude Code raz za razem. (Informacja dodatkowa: „Ralph” — publiczny eksperyment Geoffreya Hunta z nieustannie zapętlonym agentem kodującym.) I zdałem sobie sprawę, że nie muszę tego uruchamiać jako pętli. Potrzebuję od agenta AFK tylko jednego: żeby przyjął konkretne zadanie i je wykonał.
O tych rzeczach myślę jak o kolejkach, nie pętlach. Kolejka to po prostu zaległości zadań do zrobienia. Patrzę teraz na zgłoszenia w Sandcastle: raporty o błędach, prośby o funkcje. Muszę nadać zakres pozycji — powiedzmy tej. Zrobiłem tu trochę triage’u, trochę zbadania: czy to trywialne, czy wykonalne. To zostało zrobione AFK: pozycja zdjęta z kolejki, zbadana, odłożona. Potem mogę to zaimplementować — wygląda nieźle, więc dodaję etykietę „agent: implementacja” i realizuję to w moim setupie GitHub Actions plus Sandcastle. To nie jest pętla — to kolejka, która w końcu się wyczerpuje. Ta pozycja zejdzie z niej, gdy pull request zostanie scalony. A cały rozwój oprogramowania to właśnie to: masz kolejkę zadań, kierownicy dokładają do niej, ty je realizujesz. Zawsze tak było. Jest wiele węzłów zdejmujących zadania z kolejki — wielu deweloperów. Więc idea jednej pętli, która po prostu realizuje wszystkie zadania, nie pasuje do tego, jak pracują zespoły. Zwłaszcza że w GitHub Actions każdy deweloper może dodać etykietę, coś odpalić i ruszyć pracę. Idea pętli jest użyteczna, ale to nie cały obraz — lepiej myśleć o kolejce, z której zdejmuje się zadania. Gdy ludzie mówią, że musisz odpalić pętlę i przestać promptować, naprawdę mówimy po prostu o agentach AFK.
David: Jak to mówiłeś, nie wiem czemu, ale przyszedł mi do głowy obraz średniowiecznego króla zarządzającego królestwem przez ministrów. Króla, który wie najlepiej i ma najwięcej kontekstu — nie takiego, co odziedziczył imperium przez przypadek. Gdyby wysłał ministra w odległy region i nigdy od niego nic nie słyszał, minister działałby na pętli — i mogłoby się to skończyć dobrze albo źle, zależnie od złożoności spraw w regionie i rozumu ministra. Ale jako król chcesz podejścia kolejkowego: żeby ludzie przychodzili do ciebie — „nadchodzi inwazja”, „klęska głodu w tym regionie” — masz kolejkę problemów i wciąż to ty rządzisz. To byłby odpowiednik człowieka z garścią agentów: pięćdziesiąt raportów o błędach, tylko trzy krytyczne — naprawmy najpierw te; firma chce współpracować — sprawdźmy najpierw jej reputację. To dobry sposób myślenia?
Matt: Zdecydowanie. I do tego wciąż możesz wpleść mnóstwo automatyzacji. Załóżmy, że mam telemetrię dla Sandcastle albo narzędzie obserwowalności typu Sentry. Dostaję raport o błędzie z żywej aplikacji, natychmiast tworzę z niego zgłoszenie i taguję „zbadaj”. Agent może zwrócić ustrukturyzowane dane: da się to naprawić od ręki czy potrzeba człowieka? Idzie i implementuje, idzie i przegląda, a na końcu dostaje tag: scalić automatycznie czy powiadomić użytkownika? W takich systemach potrzebujesz punktów kontrolnych z człowiekiem — i chcesz przesuwać je coraz dalej, jak najbliżej końcowego efektu. Zamiast zobaczyć sam raport o błędzie, widzisz raport, eksplorację kodu, poprawkę i pytanie „możemy to przejrzeć?”. Od decyzji dzieli cię wtedy jedno kliknięcie, a nie cała sesja debugowania.
Jak daleko przesuwać człowieka
David: I wtedy pytanie — bo to nie jest pętla, prawda? Odpala się tylko wtedy, gdy przyjdzie błąd; nie ma sensu płacić OpenAI albo Anthropic w nieskończoność. Ale skoro przesuwasz siebie coraz bliżej produkcji: gdzie jest próg, po przekroczeniu którego takie rzeczy — mała zmiana interfejsu, nowy schemat kolorów — mogą być zatwierdzane automatycznie? I tego będzie coraz więcej. Jak to wygląda? Widzisz, dokąd zmierzam?
Matt: Ach — jak usuwać punkty kontrolne z człowiekiem.
David: Tak. Gdzie decydujesz, że coś jest na tyle trywialne, że nawet na to nie patrzysz? Może wszyscy agenci — które przecież wyposażasz w harness, skille i dobry model — mówią: „mały błąd, przekrzywiony element interfejsu, brak złych intencji użytkownika, nikt nie próbuje zhakować aplikacji — scalamy od razu na produkcję”. I zakres rzeczy scalanych od ręki będzie pewnie rósł. Jak o tym myślisz?
Matt: Zapytam inaczej: co daje ci przegląd?
David: Możliwość zatrzymać niebezpieczne rzeczy przed produkcją. Zapobiec złu — powiedzmy wyciekowi kodu źródłowego Claude Code na świat.
Matt: Właśnie. Ale dostajesz też wgląd we własny system, w całą instalację. Patrzysz, jak to działa, i oceniasz, czy zrobiło dobrą robotę — i tej drugiej rzeczy nie chcesz stracić, bo znowu mówimy o harnessie: chcesz go z czasem poprawiać i chcesz mieć obserwowalność. Możesz usunąć część punktów kontrolnych: „ten pull request to wewnętrzny refactor, tylko przenosi kod, nie zmienia zachowania” — i mieć AI, które mówi: „tego nie musisz przeglądać”. Ale kto wtedy przegląda to AI? Jak dawać mu z czasem informację zwrotną? Pewnie jednak musisz sprawdzać część zmian, które agent uznaje za bezpieczne do pominięcia — czy naprawdę są. I tak poprawiasz system. Nie przeglądamy tylko kodu — przeglądamy też system, który kod produkuje. A to jest ważne i użyteczne. Zgadzam się zatem, że celem jest usuwanie punktów kontrolnych, gdzie się da.
David: Więc może lepsza droga wygląda tak: w przeciętnym dniu AI autonomicznie naprawia dwadzieścia drobiazgów i pcha je na produkcję, bo są małe. Zamiast je wszystkie przeglądać — nudne i wolne — dostajesz wieczorem spersonalizowany plik HTML w duchu skillu „teach”: „oto powtarzające się wzorce w błędach naprawionych dzisiaj”. Bo GitHub powstał dawno temu i nie jest zaprojektowany pod tę erę agentów. A taki plik zna ciebie, twój styl nauki, twoje typowe pomyłki, historię błędów — i jest zoptymalizowany pod to, żeby pomagać tobie i systemowi się rozwijać.
Matt: Zupełnie. Jedna świetna rzecz, którą widziałem u ludzi — i to jest szalone: przy każdej zmianie frontendowej AI nagrywa wideo, w którym samo przechodzi po kodzie i po tym, co się zmieniło, a potem odpytuje API zamiany tekstu na mowę i nakłada lektora. Czyli AI rozmawia z tobą, prowadząc cię po kodzie — i masz przy pull requeście wideo działającej funkcji. Tę bogatość informacji powinniśmy wbudowywać we wszystko i optymalizować ludzki przegląd, przyspieszać go. Bo wszyscy narzekają: „o boże, tyle kodu do przeglądania” — a przecież możesz używać AI do pomocy w przeglądach, na tysiąc sposobów. Dopiero dotykamy powierzchni.
Biznes w epoce AI
David: Absolutnie. Dużo ludzi chce coś zbudować z AI — narzędzia osobiste, coś dla zespołu — ale wielu chce biznesu: startupu AI albo innej firmy. Jedni mówią: „SaaS i subskrypcje będą cenniejsze niż kiedykolwiek, bo dołożycie stanowiska dla agentów”. Inni: „SaaS umarł”. Jak myślisz o budowaniu biznesu i oprogramowania w epoce AI?
Matt: Szczerze? Nie zmieniło się aż tak wiele. Znów — nie jestem komentatorem, nie śledzę rynków, nie obchodzi mnie, czy SaaS umrze, czy rozkwitnie. Jeśli budujesz biznes, musisz robić rzeczy fundamentalne: rozmawiać z klientami, ustalić, czego potrzebują, budować prototypy, które wyglądają jak to, czego potrzebują, i rozwiązują ich prawdziwy problem. Nic się tu nie zmieniło. Możesz się tego nauczyć i robić to lepiej, ale AI nie daje ci w tym szczególnej przewagi, bo musisz wyjść do prawdziwego świata, prowadzić rozmowy i ustalać, czego ludzie naprawdę chcą. Klasyczne książki o projektowaniu produktów nadal mają sens — tyle że przy samej implementacji masz ogromną przewagę, a opisane w nich procedury też możesz zacząć delegować AI. Ale sedno: mieć właściwy pomysł i budować właściwą rzecz. W tym AI ci nie pomoże. Jeśli nie rozmawiasz z żywymi ludźmi i nie ustalasz, czego chcą — nie zdołasz tego zrobić. A gdy tylko to ustalisz, możesz startować.
David: To zresztą jest rzecz, w której AI jest notorycznie słabe: oryginalne pomysły, myślenie poza schematem. I to byłaby pewnie jedna z głównych rad, jakie bym dał: to ty musisz wybierać funkcje, które dokładacie. Jak widzisz kogoś, kto deleguje i to — „co dodamy następnego dużego?” — to nie. Ty rządzisz produktem. Oczywiście nie musisz znać dokładnej składni ani czytać każdego pliku, ale nie możesz prosić AI o zbudowanie twojej aplikacji. Musisz mieć wizję, wiedzieć, po co to budujesz i jaki problem rozwiązuje.
Matt: Zdecydowanie. Powinieneś raczej pytać AI, co z twojej aplikacji usunąć. Jak to uprościć, jak poprawić doświadczenie użytkownika, jak przykleić się do tego, czego ludzie naprawdę chcą — zamiast kończyć jako jedna z tych przerażających aplikacji finansowanych przez fundusze VC, z tysiącem funkcji, w których nie można znaleźć tej jedynej, potrzebnej. To znowu fundamenty projektowania produktu.
Juniorzy, seniorzy, DX i AX
David: Wspomnieliśmy, że seniorzy dostają dziesięciokrotny wzrost. Z mojego doświadczenia to prawda — ale tylko jeśli naprawdę używają tych narzędzi. Wciąż są programiści, którzy nie wierzą: próbowali rok czy dwa lata temu, zawiedli się, a przecież narzędzia, harnessy i modele są dziś o niebo lepsze. Ale inne pytanie: co z zatrudnianiem młodych ludzi, prawdziwych entuzjastów AI, którzy znają te narzędzia od podszewki — wiedzą, jaki model, jaki skill, jaki agent w danej sytuacji — i mają oczywiście trochę fundamentów technicznych? Jak pogodzić tę sprzeczność: seniorzy z dziesięcioma, piętnastoma, dwudziestoma latami doświadczenia kontra zwolennicy AI z mniejszym doświadczeniem, ale lepsi operatorzy?
Matt: Zatrudnianie świetnych juniorów zawsze było celem każdej firmy — bo jeśli znajdziesz świetnego juniora, entuzjasta zrobi lepszą robotę niż ktoś bardziej doświadczony. Entuzjazm wygrywa z doświadczeniem w czystym wyniku, bo tacy ludzie rozwijają się i uczą o wiele szybciej. Ludzie naprawdę podekscytowani tą nową erą i znający się na niej — jeśli połączysz to z odrobiną fundamentów… Bo rozróżniam DX, doświadczenie dewelopera, od AX — doświadczenia agenta, czyli tego, jak pracuje mu się w bazie kodu. I wszystko, co możesz zrobić — lepsze skille, mocniejszy model, lepszy harness, lepsza baza kodu — działa. Ludzie przy okazji zapominają o poprawianiu samej bazy kodu pod kątem AX, zapominają o wszystkich przewagach płynących z dobrych fundamentów inżynierii. I tu przyda się senior: senior wie, jak budować dobry DX — jak zbudować bazę kodu, w której człowiek pracuje dobrze. A między dobrym DX a dobrym AX jest ogromna strefa wspólna. Junior świetny w AI podchodzi do problemu po prostu z innej strony niż senior. Ale co było pierwotnym pytaniem — kogo zatrudnić?
David: Nie tyle kogo byś zatrudnił, co kto da więcej przewagi, kto będzie cenniejszy: senior z bagażem doświadczeń i właściwym myśleniem o oprogramowaniu, ale nie aż takim zwolennikiem AI — czy ktoś, kto w pełni używa AI i umie wycisnąć z niego maksimum?
Matt: Myślę, że jeśli masz eksperymentalne nastawienie i ekscytujesz się AI, wyciągniesz z tego mnóstwo — czy jesteś juniorem, czy seniorem. A jeśli interesuje cię harness i poprawianie doświadczenia agenta wszędzie, gdzie się da — będziesz kwitnąć. Oczywiście ludzie mają dobre powody, żeby nie wsiadać w ten pociąg: mogą mieć opory etyczne — choćby wobec tego, że Anthropic „pożycza” wszystkim powieści i pompuje je do Claude’a. Ale to już jest i taka jest dziś ta praca. Jeśli jesteś czysto taktycznym programistą, który tylko klepie kod — jesteś skończony. Nie da się już być „klepaczem kodu”. Musisz myśleć strategicznie. Seniorzy mogą z tego wycisnąć najwięcej — ale juniorzy też mogą się tego nauczyć.
Rada na dziś: zacznij od zera
David: Moje ostatnie pytanie będzie praktyczne. Gdybyś wziął przeciętnego entuzjastę AI i dał mu jeden–dwa kroki na dziś — poprawić setup, harness, czegoś się nauczyć — co by to było?
Matt: Pierwsza rzecz: skasowałbym każdy skill, każdą wtyczkę, każdy serwer MCP. Skasuj CLAUDE.md, skasuj AGENTS.md, wróć do absolutnie niczego — a potem obserwuj agenta. Patrz, co robi. Moim zdaniem każdy przeładowuje okno kontekstowe nadmiarem rzeczy i instrukcji. Wróć do czystej karty i patrz, co agent robi w tym podstawnym trybie. Dopiero potem dokładaj warstwy — i dbaj o to, żeby były procedurami, nie zdolnościami. Dokładaj rzeczy, które sam wybierasz. Moje repozytorium skilli to dobry punkt startu. Jeśli czegoś naprawdę zaczniesz brakować — na przykład burzy mózgów z superpowers — przywróć to. I zadbaj, żeby instalować skille tak, byś mógł je modyfikować, bawić się nimi i eksperymentować. Jeśli zauważasz problemy, szukaj rozwiązań — i staraj się jak najwięcej implementacji delegować agentowi AFK. AFK to niesamowity sposób pracy. Wymaga trochę przygotowania, ale gdy już stoi — po prostu rusza jak burza.
David: Świetnie. Dzięki za czas. Gdzie ludzie mogą cię znaleźć?
Matt: Na Twitterze i na aihero.dev. Prowadzę też newsletter, w którym piszę o tym wszystkim — a jeśli chcesz poznać moje skille i ich aktualizacje, wejdź na aihero.dev/skills.
David: Dobrze, linkuję wszystko poniżej. Jeszcze raz dziękuję za czas, Matt, i miłego dnia.