O czym jest ten film
- Gościem Matta Pococka jest Poteto — twórca frameworka pstack, wcześniej inżynier w Meta (zespół React), później Cursor, obecnie w SpaceX AI.
- Punktem wyjścia jest jego talk „Jak wysłałem 2500 pull requestów do produkcji w zeszłym miesiącu”, który zdobył około 3 milionów wyświetleń na X.
- Centralna metafora: zamiast „fabryki oprogramowania” Poteto woli mówić o „kuchni Michelin” — skalowanie pracy bez utraty jakości i rzemiosła.
- Fundamentem skalowania jest „drabina zaufania” do agentów: im więcej zaufania, tym więcej odpowiedzialności można delegować.
- Najważniejszą umiejętnością jest weryfikacja — dawanie agentowi „rąk i oczu”, żeby sam uruchamiał, testował i poprawiał swój kod.
- Deterministyczną część pracy (kodowania mechaniki, refaktoryzacje) warto wynosić do skryptów i CLI wewnątrz skilli, oszczędzając kontekst i czas.
- Środowisko kodu — restrykcyjne reguły lint, konwencje katalogów, framework Dune — sprawia, że zły kod jest po prostu trudny do napisania.
- Dwie pętle: wewnętrzna (agenty budują kod) i zewnętrzna (agenty zbierają kontekst ze Slacka, Linear, maili) — ich połączenie usuwa człowieka jako wąskie gardło.
- W „ciemnej fabryce” agenty samodzielnie scalają swoje PR-y, a człowiek przegląda efekt rano i koryguje środowisko, nie pojedynczego agenta.
- Skille to procesy zapisane słowami — można je swobodnie łączyć, czerpać z cudzych i budować własny zestaw „noży”.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Weryfikacja to najważniejszy skill w całym zestawie narzędzi
Na czym polega: Agent musi mieć możliwość uruchomić swój kod, kliknąć w aplikację jak zwykły użytkownik, zrobić zrzut stosu czy trace — dopiero wtedy może iterować. Bez tego zawsze wracasz do roli pośrednika, który ręcznie sprawdza wyniki.
Jak stosować: Zbuduj skill weryfikacji oparty o Playwright i Chrome DevTools Protocol. Pozwól agentowi samemu uruchamiać i testować aplikację przed oddaniem pracy.
Na co uważać: Weryfikacja bywa kosztowna w tokeny — Poteto wysyła dziesiątki agentów-weryfikatorów na jeden PR, ale sam przyznaje, że można ograniczyć się do jednego. Reguluj intensywność do skali zadania.
2.Odłączaj część deterministyczną od wymagającej osądu
Na czym polega: Część pracy jest mechaniczna (przeniesienie kodu na inny wzorzec, migracje), a część wymaga myślenia. Agent powinien zajmować się tylko tą drugą — deterministykę zamknij w skryptach i CLI.
Jak stosować: Przejrzyj swoje skille i wydziel to, co zawsze przebiega tak samo, do skryptu w środku skilla. Agent wywołuje gotowe narzędzie zamiast za każdym razem wymyślać rozwiązanie od nowa.
Na co uważać: Bez CLI każdy agent „odbudowuje świat” po swojemu — poprzedni agent może napisać działający skrypt i go wyrzucić, a kolejny zacznie od zera. To marnowanie czasu i kontekstu.
3.Odpowiedź na błąd agenta to nie korekta, lecz zmiana środowiska
Na czym polega: Gdy agent powtarza błąd, problem nie leży w tym jednym agentzie, tylko w kodzie i konfiguracji, która mu na to pozwala. Obserwuj porażki i zamieniaj je w reguły lint, constrainty typów, konwencje.
Jak stosować: Zastanów się, jak sprawić, żeby ten błąd był niemożliwy do popełnienia — czy to reguła lintowa, bardziej restrykcyjny typ, czy katalog, w którym dany kod po prostu musi się znaleźć.
Na co uważać: To wymaga czasu i samodyscypliny — Poteto wprost mówi, że nie da się tego „kupić” gotowego w paczce. Trzeba świadomie obserwować, gdzie agenty zawodzą, i iterować.
4.Dobry kodbaz to taka, w której łatwo wprowadzać zmiany
Na czym polega: Kod powinien prowadzić agenta (i człowieka) wąskimi ścieżkami — tam, gdzie jest tylko jeden sposób zrobienia danej rzeczy. Framework Dune, konwencja katalogów features/, restrykcyjne lint — to wszystko służy temu celowi.
Jak stosować: Zaprojektuj strukturę projektu tak, żeby nowy feature miał jedno oczywiste miejsce, a dodanie do istniejącego „pliku boga” było wręcz niemożliwe.
Na co uważać: Restrykcyjność musi być konsekwentna — jeśli reguły istnieją tylko na papierze, agent je zignoruje. Warto zautomatyzować egzekwowanie konwencji (np. przez automatyczne odnajdywanie katalogów z feature’ami).
5.Połącz pętlę wewnętrzną z zewnętrzną, żeby przestać być wąskim gardłem
Na czym polega: Pętla wewnętrzna to agenty piszące kod; zewnętrzna to systemy, w których żyją realne informacje — Slack, Linear, maile, X. Jeśli nie są połączone, człowiek musi ręcznie przenosić kontekst między nimi.
Jak stosować: Skonfiguruj agenta (np. Grokbot) do subskrybowania kanału Slack z bug reportami i automatycznego kierowania zgłoszeń do projektu w Cursorze, gdzie coordinator rozdzieli zadania.
Na co uważać: Podłączając zewnętrzne systemy, upewnij się, że agent najpierw weryfikuje, czy bug w ogóle da się odtworzyć na aktualnym mainie — zgłoszenie może wynikać z konfiguracji użytkownika, nie z realnego problemu.
6.Nie rozbijaj każdego zgłoszenia na osobnego agenta — użyj bufora
Na czym polega: Przy napływie wielu podobnych bugów automatyczne spawnowanie jednego agenta na każdy problem prowadzi do duplikacji pracy i utraty widoczności szerszego obrazu.
Jak stosować: Poleć agentowi najpierw dopisywać znalezione problemy do dokumentu, a co kilka dni przeglądać tę listę — często okazuje się, że to ten sam błąd ujawniający się na różne sposoby.
Na co uważać: W trybie czystej egzekucji łatwo przeoczyć powiązania między zgłoszeniami — bufor wymusza zastanowienie się nad całością, zanim zaczniesz cokolwiek naprawiać.
7.Zamiast blokować na review, losuj próbkę i koryguj proces
Na czym polega: Przy 2500 PR-ach miesięcznie nie da się recenzować każdego. Rozwiązanie: przeglądać wyrywkowo, bardzo dokładnie, i jeśli problem się powtarza u kilku agentów — poprawiać środowisko, nie pojedynczy PR.
Jak stosować: Codziennie przejrzyj próbkę kodu od agentów, wypunktuj powtarzające się wzorce błędów i zamień je w nowe reguły, lint czy constrainity.
Na co uważać: To nie zwalnia z odpowiedzialności za wynik — Poteto przegląda commit history po fakcie i cofa lub poprawia, gdy coś poszło nie tak. Samplowanie nie oznacza ślepoty.
8.„Ciemna fabryka” jest osiągalna, ale tylko przy spełnionych warunkach
Na czym polega: Agenty działają 24/7, samodzielnie scalają własne PR-y, a człowiek przychodzi rano i przegląda efekty. Warunek: bardzo rygorystyczna weryfikacja i mocno ograniczone środowisko.
Jak stosować: Zacznij od trybu pełnego autopilota na niskostykowych zadaniach, z jednym agentem-weryfikatorem. Dopiero gdy zaufanie urośnie, zwiększaj skalę i liczbę weryfikatorów.
Na co uważać: Pierwsza noc z włączonym trybem bywa stresująca — Poteto sam bał się, że „zawoła CEO” o trzeciej nad ranem. W środowiskach o wysokiej stawce (medycyna, prawo, finanse) nie każda praca jest weryfikowalna i tam model nie zadziała bez modyfikacji.
9.Historia rozmów z agentami to kopalnia procesów
Na czym polega: Poprzednie chaty pokazują, jak naprawdę wygląda twoja praca — gdzie interweniowałeś, co poprawiałeś, jakie wzorce się powtarzały. To „proces zmaterializowany”, a nie abstrakcja w głowie.
Jak stosować: Przeglądaj własne transkrypcje interwencji i poproś agenta o zaproponowanie, które z nich warto zamienić w nowy skill, regułę lint lub tryb pracy.
Na co uważać: Nie ograniczaj się do gotowych skilli z internetu — Poteto podkreśla, że każdy powinien mieć własny zestaw noży, dopasowany do swojego stylu i kodu.
10.Skille ewoluują: od szczegółów implementacyjnych do samych workflow
Na czym polega: Zeszłoroczne skille zawierały dokładne komendy i skrypty. Nowe modele nie potrzebują tego poziomu szczegółowości — skille stają się coraz mniejsze i bardziej abstrakcyjne, opisując raczej kolejne kroki procesu niż jego wykonanie.
Jak stosować: Pisz skille bardziej jak checklisty myślowe niż instrukcje krok po kroku — co najmniej na etapie workflow, pozostawiając szczegóły agentowi.
Na co uważać: Mniejsze skille wymagają lepszych modeli i środowiska — im mniej szczegółów zapisujesz, tym więcej musisz mieć zaufania do agenta i tym mocniejsze muszą być guardrailse w kodzie.
Redakcyjne tłumaczenie
Wstęp: spotkanie dwóch autorów bibliotek skilli
Matt Pocock: Cześć wszystkim. Mam dziś dla was coś specjalnego. Ostatnio, w tym naszym rodzaju podcastu, gościem był Uncle Bob i rozmawialiśmy o jakości oprogramowania oraz agentach. Dziś mam kogoś, kto niedawno eksplodował na Twitterze tematami fabryk oprogramowania, podnoszenia jakości pracy i wchodzenia wyżej po drabinie zaufania do agentów — Pozdrawiam Potato, twórcę pstack. Witaj!
Poteto: Dzięki za zaproszenie, cieszę się, że mogę być. Jestem wielkim fanem waszej pracy.
Matt: Wzajemnie. Ludzie mówią o tej rozmowie jak o spotkaniu mistrzów Olimpu skilli, bo oboje mamy bardzo popularne biblioteki. Wspominałem przed startem, że nie korzystałem dużo z twoich — i chcę wycisnąć z twojej głowy wszystko, co się da, żeby potem używać tego dobrze. Chciałbym zacząć od twojego talku sprzed dziesięciu dni, tego o „2500 pull requestów zeszłego miesiąca”, który na X zdobył około trzech milionów wyświetleń. Oglądałem go, polecałem dalej — i mam do ciebie mnóstwo pytań. Zaczniemy od drabiny zaufania: czym wyżej ufasz agentom, tym więcej im delegujesz. Jak wyglądała twoja droga po tej drabinie, zwłaszcza po przejściu do SpaceX?
Geneza: od wypalenia w Meta do pierwszych skilli
Poteto: Ta droga zaczęła się jeszcze przed dołączeniem do Cursor (dziś SpaceX AI). Po odejściu z Meta — pracowałem tam w zespole Reacta — wziąłem miesiąc wolnego, bo czułem się wypalony. No i co robi człowiek wypalony? Zaczyna nowy projekt poboczny. Oczywiście pisałem kod z pomocą AI, ale szybko zauważyłem, że spędzam mnóstwo godzin na mikrozarządzaniu jednym agentem. To był koniec stycznia lub początek lutego — ludzie byli wtedy zafiksowani na idei „orkiestracji”, jeszcze zanim okno agentów w Cursorze stało się popularne. Wszyscy siedzieli w terminalu i opowiadali o własnych orkiestratorach. Dałem się w to wciągnąć — i budując swój projekt, zacząłem się zastanawiać, jak uczynić moje środowisko pracy z AI wydajniejszym.
Zrobiłem krok wstecz i zobaczyłem, że całe to mikrozarządzanie pochłania mój czas. Tworzyłem skille, ale nie umiałem zmierzyć ich efektu — działałem na ślepo, choć iterowałem szybko. Ten projekt stał się później podstawą pstack, choć wtedy jeszcze o tym nie wiedziałem. Całość jest nadal open source — na moim GitHubie, pod nazwą potatonoodle. Znajdziecie tam wczesne skille i katalog „brain”.
Fascynowała mnie wtedy jedna rzecz: jak wyciągnąć moją własną wiedzę i umiejętności, i przekazać je agentowi? Zdałem sobie sprawę, że cały czas próbuję nauczyć agenta, żeby pisał kod bardziej jak ja i pracował bardziej jak ja. Skille były do tego wejściem.
Cursor: agent window i rola „mięsnego proxy”
Poteto: Potem wszedłem do Cursor i zacząłem pracować nad oknem agentów. Miał ono poważne problemy z wydajnością — było mocno zmulone. Ponieważ miałem doświadczenie w Reakcie, zaproponowano mi pomoc. Początek był bardzo ręczny: siedziałem po uszy w flame graphach i zrzutach sterty, próbując zrozumieć, czemu aplikacja jest taka wolna. I znów to samo odkrycie — to ja byłem wąskim gardłem. Robiłem wszystko ręcznie. Byłem w pewnym sensie „mięsnym proxy” między moim agentem a Chrome DevTools. I to mnie irytowało.
Matt: Gdzie jesteśmy w timeline?
Poteto: Wszedłem do Cursora w marcu, więc to był wczesny kwiecień. Nie miałem wtedy żadnych skilli — porzuciłem swoje prywatne, bo myślałem, że już nie będą potrzebne. Ale pracując nad oknem agentów, a potem nad Grokbotem, zobaczyłem, że lekcje z tamtego okresu — zwłaszcza o weryfikacji i rygorze w pracy — są bardzo aktualne. Z mojego doświadczenia wynika, że nawet modele frontierowe lubią iść na skróty, robią to, co łatwiejsze. Dlatego wiele moich skilli odpowiada na pytanie: jak sprawić, żeby łatwa droga była zarazem właściwą?
Matt: To destylowanie własnej ekspertyzy i zamiana codziennej pracy w procesy jest mi bardzo bliskie — dokładnie to robię ze skillami. Wielu ludzi uważa jednak, że wiedza dziedzinowa traci na wartości, bo AI przejmuje więcej pracy. Co o tym myślisz — na wyczucie, zanim wejdziemy w szczegóły?
Poteto: Moim zdaniem ekspertyza dziedzinowa jest ważniejsza niż kiedykolwiek. Pisałem o tym na X: im modele są lepsze — a uwielbiam Opus 5.5, frontier robi się niesamowity — tym mniej wąskim gardłem jest sam agent. Wąskim gardłem staje się twoja zdolność do wyrażenia intencji i celów tak, żeby agent je zrozumiał i wykonał. Ludzie z głęboką ekspertyzą mają ogromną przewagę, zwłaszcza jeśli są trochę tech-ciekawscy. Lekarz, prawnik, specjalista z jakiejś nieinżynierskiej dziedziny, który ogarnia agentów — może zbudować świetny produkt, jeśli ma jasną wizję i umie ją przekazać. Dziś sednem jest transfer twojej intencji i wizji do agenta.
Język jako interfejs: słowa, na które agent się zaczepia
Matt: Od momentu, gdy pojawiły się agenty, jestem wręcz obsesjonaty językiem. Nieustannie myślę o doborze słów, o tym, jak zaostrzyć sformułowania, co może być ukryte w moich frazach. Uwielbiam moment, gdy znajdę słowo, na którym agent się zaczepi i potem je wzmacnia, wraca do niego w swoich śladach myślowych. Wczesny przykład: TDD. Ostatnio dużo się o tym mówi — czy używać TDD z agentami? To bez znaczenia. Istotne jest, że agent zaczyna myśleć w kategoriach TDD, pisze testy, priorytetyzuje inaczej niż wcześniej. Dlatego „grillowanie” działa.
Poteto: Dokładnie — wyciąga z ciebie te właściwe słowa. A przynajmniej pomaga agentowi zrozumieć twe myślenie, żeby mógł ci proponować słowa, a ty mówił: „tak, dokładnie o to chodziło”. Skopiowałem zresztą kilka twoich tipów — jednym z ulubionych jest ten o eliminowaniu testów tautologicznych. Moją zmorą są bezużyteczne testy, które piszą agenty. Słowo „tautologia” nie jest powszechnie znane, zwłaszcza dla osób bez angielskiego jako pierwszego języka, ale niesie mnóstwo znaczenia. To forma kompresji — upakowujesz w słowo mnóstwo intencji i sensu. Zawsze interesowały mnie języki — programowania i naturalne, i to, jak powstały. Fascynujące, że z agentami naturalny język spotyka się z językiem programowania. Bo w gruncie rzeczy to wszystko komunikacja.
Matt: Zrobiłem zresztą dyplom z dramatu — myślałem o języku i Szekspirze długo przed agentami. To wszystko wydaje mi się bardzo znajome.
Metafora centralna: kuchnia Michelin zamiast fabryki
Matt: Zanim wejdziemy w szczegóły — „fabryka oprogramowania” to duże buzzword i sam nad nim pracuję, także w kierunku kursu. Chcę dojść od punktu „człowiek z jednym–pięcioma agentami” do setek działających równolegle. I tu chcę usłyszeć twoją metaforę kuchni Michelin, bo dużo mówi o twoim sposobie myślenia.
Poteto: Nigdy specjalnie nie lubiłem terminu „fabryka oprogramowania”. Nie dlatego, że jest nieadekwatny — ale gdy ludzie myślą „fabryka”, kojarzą to z czymś, co nie ma nic wspólnego z jakością czy rzemiosłem. A jakość i rzemiosło są dla mnie — i dla większości ludzi budujących produkty — fundamentalne. Dbamy o user experience, o to, co tworzymy. Więc choć termin jest trafny, budzi czasem złe skojarzenia. Wpadłem więc na „kuchnię Michelin” — metaforę dużo bardziej inspirującą. I lubię jedzenie, nazywam się w końcu Potato, gotuję — widzę mnóstwo paral…
Weryfikacja: daj agentowi ręce i oczy
Matt: To, co kocham w twoim podejściu, to ilość uwagi poświęconej środowisku, w którym działa agent. Wielu ludzi myśli: agent jest dobry, nie poprawię go, zaufam temu, co dali twórcy modelu. Nie mogę grzebać w bebechach Claude Code czy czego tam używam. A ty pokazujesz, że środowisko można zmieniać — kod, narzędzia weryfikacyjne, możliwość samodzielnego sprawdzania pracy. W twoim talku to właśnie weryfikacja jest dźwignią, na której buduje się zaufanie. Opowiedz o tym konkretnie.
Poteto: Mówiłem to już wielokrotnie: nawet jeśli nie używasz pstack ani moich skilli, weryfikacja powinna być w twoim zestawie najważniejsza. Bez niej — dla tych, którzy nie znają pojęcia — chodzi o to, żeby dać agentowi w pewnym sensie „ręce i oczy”: może uruchomić kod, może wejść w interakcję z aplikacją jak zwykły użytkownik, może debugować, zbierać trace’y i snapshoty.
Ciekawostka: to był właśnie pierwszy skill, jaki zbudowałem po wejściu do Cursora. I to on faktycznie pozwolił mi zacząć wspinać się po drabinie zaufania — czego inne skille (how, why, unsop) nie dawały. Bo choćby nie wiem jak były dobre, nadal to ja byłem proxy między agentem a wynikiem. Jeśli agent nie widzi efektu swojej pracy, nie może iterować. Tu ludzie zaczynają mówić o „pętli” — pojęciu dość abstrakcyjnym, bo co to właściwie jest pętla agentowa? Ale dla mnie najważniejszą częścią pętli, tym, co czyni ją pętlą, jest właśnie weryfikacja: agent może sam sprawdzić własną pracę. To wyjmuje ciebie z równania.
Jednym z pierwszych zastosowań była praca wydajnościowa nad oknem agentów w Cursorze. Chciałem dojść do tzw. hill climbingu — terminu, którego dużo używają laboratoria AI. Chodzi o to, że masz jakiś rubric, sposób oceniania wyniku, a dzięki pętli agent może nieustannie próbować poprawiać ten wynik. Karpathy wydał zresztą słynny „auto-research”, w którym jest dużo tych idei. Weryfikacja to prawdopodobnie najważniejszy skill w pstack i wielu innych zestawach narzędzi. Spędziłem bardzo dużo czasu, strojąc skill weryfikacji — i dziś wewnętrznie mamy ich całą rodzinę: każda aplikacja Cursora/SpaceX AI ma swój skill weryfikacji, automatycznie utrzymywany. To stała się infrastruktura krytyczna dla zespołu, bo korzystają z niej wszyscy.
CLI w środku skilla: determinizm zamknięty w skrypcie
Matt: Poszedłeś z tym bardzo daleko — w talku pokazałeś, że zbudowałeś do tego własne CLI. Co ono robi i po co powstało? To dowód, jak głęboko pchasz ten temat.
Poteto: To tip, którego nauczyłem się wcześnie. W styczniu czy pod koniec zeszłego roku ludzie martwili się głównie oknem kontekstowym. Kompresja i podsumowywanie nie były jeszcze dobre — w społeczności krążył wręcz mem, że po pierwszym kompaktowaniu agent „głupieje” do końca sesji. Dużo więc myślano o oszczędnym korzystaniu z kontekstu. I to była inspiracja dla CLI w skillach weryfikacji. Dziś już mniej chodzi o kontekst — agenty i harnessy dużo lepiej podsumowują — ale czyste okno kontekstowe nadal ma wartość.
CLI to dla mnie sposób, by wziąć deterministyczną część tego, co robi skill, i zakodować ją w skrypcie — odebrać agentowi osąd tam, gdzie jest zbędny. Widzę agenty i skille jak gradient: z jednej strony praca oparta w całości na osądzie, wymagająca myślenia i łączenia kontekstów; z drugiej strony część czysto deterministyczna — np. refaktoryzacja z jednego wzorca na drugi jest mechaniczna, agent nie musi wymyślać jej za każdym razem na nowo. To była inspiracja dla CLI i widać to w wielu moich skillach: wydzielam części deterministyczne do kodu, a agentowi zostawiam tylko to, co faktycznie wymaga osądu. CLI to w gruncie rzeczy wrapper — nakładka z lekkimi instrukcjami, jak używać customowych narzędzi ze skilla. Sam w sobie nie jest specjalnie interesujący, to nie jest nowatorski kawał software’u. Po prostu klei ze sobą Playwright, Chrome DevTools Protocol i jakieś API. Zwykły glue.
Matt: A ja jestem zachwycony, bo to sposób na ukrywanie informacji przed skillem — trzymanie go małego — i delegowanie skomplikowanych, deterministycznych rzeczy do skryptu. Kompresujesz informacje i sprawiasz, że agent robi rzeczy bardziej spójnie.
Poteto: I rzeczywiście, jeśli dbasz o okno kontekstowe, to pomaga — agent nie musi niczego wymyślać od nowa. Zauważyłem wcześnie, że bez CLI agent próbował weryfikować pracę, ale za każdym razem „odbudowywał świat” — i każdy robił to inaczej. To było nieefektywne nie tylko pod względem kontekstu, ale i czasu: agent musiał napisać skrypt, przetestować, nie działał… a poprzedni agent napisał działający i go wyrzucił. Wtedy stało się oczywiste: zamień to w CLI i włóż do skilla, żeby każdy agent z tego korzystał.
Dobra zachęta dla ludzi: zastanówcie się, ile waszych skilli i reguł mogłoby być w ogóle deterministyczne. To jeden z moich core principles — jak wydajnie rozdysponować determinizm i niedeterminizm. Pozwólmy agentom błyszczeć w części niedeterministycznej, bo do tego są trenowane; a części mechaniczne niech wykona czysty determinizm. Widać to też przy migracjach — kolejny wielki temat, o którym mówiłem: przechodzenie z jednej technologii na inną, zwłaszcza na lepszą dla agentów. Dużą część takiej migracji da się zrobić skryptami i CLI — code modami, przechodzeniem po drzewie składni i mechaniczną transformacją kodu, zamiast kazania agentowi myśleć.
(Informacja dodatkowa: „code mod” to skrypt automatycznie przekształcający kod źródłowy zgodnie z regułami — bez udziału modelu językowego.)
Środowisko jako nowa praca inżyniera: framework Dune i reguły lint
Matt: Jest tu jeszcze jeden wątek: zabierasz agentowi pewne rzeczy i wkładasz je w środowisko. Na przykład gdy zauważysz, że agent zawsze popełnia ten sam błąd — spraw, żeby był w środowisku niemożliwy. To sprowadza się do jakości kodu. Lubię definicję: dobra kodbaza to taka, w której łatwo robić zmiany bez psucia rzeczy. Oznacza to mnóstwo barier ochronnych — agent i człowiek są prowadzeni bardzo wąskimi ścieżkami. Mówisz o tym nie tylko w kategoriach automatycznych checków (lint, typy), ale też projektowania abstrakcji. Zbudowaliście nawet własny framework dla agentów. Jak ważne to jest w porównaniu z budowaniem feature’ów?
Poteto: Prawie napisałem o tym wczoraj tweeta, ale nie napisałem. Uważam, że nowym zadaniem inżyniera jest po prostu zajmowanie się środowiskiem. Jeśli nie poświęciłeś czasu na budowanie zaufania do agentów, na skille i narzędzia, utkniesz nisko na drabinie zaufania — nie ufasz ich pracy, więc jedyną strategią jest mikrozarządzanie. A to pochłania mnóstwo czasu. I gdy w tym utkniesz, nie masz luksusu myślenia o rzeczach wyższego rzędu, jak zwiększanie własnej produktywności.
Analogia: wyobraź sobie developera, który nigdy nie słyszał o VS Code ani Vimie, zna tylko Notatnik, a nawet nie zna Gita. Nie zatopił noży — a z tępym nożem wszystko trwa wieki. Zwłaszcza gdy deadline’y wiszą nad głową: utknąłeś w koleinach, noże tępe, narzędzia słabe, a presja, by dostarczać, ogromna. Ale jeśli znajdziesz czas, żeby pomyśleć o setupie… wracając do gotowania: jeśli siekanie czosnku trwa wieczność, jest praska do czosnku. Maszyny i narzędzia wynaleziono z powodu. Jeśli prowadzisz kuchnię Michelin, a kucharze nie mają narzędzi, wszystko będzie ekstremalnie nieefektywne i każdy kucharz wymyśli swoje.
I tu dochodzimy do constraintów — a przy okazji musimy porozmawiać o TypeScripcie, bo dzielimy tę wspól-
ną przeszłość. Ty zrobiłeś Total TypeScript i jesteś liderem w tej przestrzeni, ja adoptowałem TS wcześnie i mówiłem na TypeScript Conf parę lat temu. Jedna z moich ulubionych rzeczy w TS to type narrowing — idea, że od bardzo szerokiego typu, który może być czymkolwiek, przez type guardy, zawężanie i sprawdzenia runtime’owe dochodzisz do: to nie jest zwykły string, to bardzo szczególny string, stała. I to ma mnóstwo wspól- nego z constraintami w kodzie: zawężasz przestrzeń możliwych typów, mówisz, że istnieje tylko jeden.
U nas ten framework nazywa się Dune. Nie jest open source. Opisuję go ludziom jako wewnętrzny Next.js dla naszych aplikacji Electron. Ma bardzo restrykcyjne reguły lint, a kodbaza jest zaprojektowana tak, że jest naprawdę tylko jeden sposób zrobienia danej rzeczy. Dużo korzystamy z konwencji — np. każdy feature ma swój katalog; jest mechanizm, który odkrywa feature’y przez rejestr i przeszukiwanie kodu. Ta konwencja plus reguły lint tworzą środowisko, w którym pisanie złego kodu jest po prostu trudne. To uwalnia twoją pojemność mentalną, a agent przestaje o tym myśleć: chcę dodać feature — idzie do katalogu feature’ów, cały kod ląduje tam, i nie będę dopisywał do „pliku boga”.
Bo inspiracją dla tych katalogów feature’ów były pierwsze wersje Grokbota, składające się z ośmiu plików-bogów, każdy po co najmniej dziesięć tysięcy linii. Musiałem to poszatkować na mniejsze kawałki. I to jest druga ważna rzecz: obserwowanie, jak agenty zawodzą. Za każdym razem, gdy widzisz błąd albo coś, co można zrobić lepiej, cofnij się i pomyśl: jak zamienić to w regułę lint? Jak sprawić, by kodbaza czyniła to niemożliwym? Dla mnie, z moim tłem w TS i systemach typów, to zawsze wraca do: jak zawęzić przestrzeń, żeby dokładnie wiedzieć, na czym pracuję.
Matt: Zrozumiałe. I zabawne, że wspomniałeś o TypeScripcie i plikach-bogach w jednym zdaniu, bo TypeScript słynie z pliku typów o 25 tysiącach linii. Chociaż pewnie już przepisali go w Go, prawda? Dobrze — środowisko jest ważne, obserwujesz agenta jak sokół, każdy błąd zamieniasz w element środowiska. A korzyść jest taka, że nie przeciążasz agenta regułami do zapamiętania — one są w środowisku, agent się na nie natyka i odbija we właściwym momencie.
Skąd się biorą 2500 PR-ów: dwie pętle i koordynatorzy
Matt: Wciąż nie rozmawialiśmy o tych 2500 PR-ach. Skąd się biorą? Nie przecież uruchamiasz 2500 czatów miesięcznie. Muszą być automatyczne triggery w repo. Jak ta fabryka sama uruchamia pracę?
Poteto: Zacznę od tego, że warunkiem koniecznym takiej liczby pull requestów jest środowisko — wszystko, o czym właśnie mówiliśmy. Bez tego czasu spędzonego na kuchni, nożach i narzędziach dla agentów nie byłbym w stanie tego zrobić. Myślę o tym tak: zbudowałem jedną kuchnię i jedną restaurację. A dziś jestem w punkcie, w którym nie muszę już tam stać.
Matt: Otwierasz sieć restauracji.
Poteto: Dokładnie. Jesteś Gordonem Ramsayem, nauczyłeś swojego szefa kuchni wszystkich trików tworzenia świetnego menu, kuchnia jest perfekcyjnie urządzona — i możesz otwierać drugą, trzecią restaurację. Każdy duży projekt, każdy duży czat, to dla mnie restauracja. Mam ich kilka działających równolegle i lataję między nimi helikopterem — do niektórych częściej, zależnie od tego, jak bardzo jestem w pętli.
Zdecydowanie istnieją zewnętrzne triggery i kontekst, których te projekty same nie mają — i przez długi czas to ja byłem ich pośrednikiem. Najlepszy przykład: pracujesz nad feature’em albo naprawiasz buga, a zgłoszenia błędów przychodzą do Slacka, Linear, X — systemów zewnętrznych, niepodłączonych do twojej wewnętrznej pętli. Mówię o pętli zewnętrznej i wewnętrznej. Moja pętla wewnętrzna to moi inżynierowie-agenci pracujący nad kodem, budujący w kierunku migawki mojej intencji. Problem w tym, że migawka się dezaktualizuje: pojawiają się nowe informacje, których muszę być pośrednikiem i przekazywać agentowi. Jeśli nie masz triggerów ściągających informacje do pętli wewnętrznej, musisz grać tę rolę sam: siedzisz w Slacku, na X, zbierasz kontekst o bugach, prośbach o feature’y, o tym, że ktoś wspominał, że backend ma jakieś ograniczenie — i wszystko to ręcznie przekazujesz dalej.
I tu narzędzia typu Grokbot są świetne, bo automatyzują pętlę zewnętrzną. Połączenie obu pętli jest bardzo potężne: nagle twoi agenci mogą sami zdobywać kontekst. Prosty przykład — masz Slack MCP albo własny harness z subskrypcją kanału Slack. Mówisz agentom: subskrybujcie ten kanał; za każdym razem, gdy pojawi się zgłoszenie buga, idźcie to zdiagnozować. Odtwórzcie problem, używając skilli weryfikacyjnych, w które już zainwestowaliśmy, i pozostałych skilli, dzięki którym mam spore zaufanie. Ufam, że agenci faktycznie zrozumieją buga i sprawdzą, że nadal istnieje na mainie — a nie wynika z setupu użytkownika, jego danych czy tego, że nie zainstalował zależności.
Stworzenie i połączenie tych dwóch pętli to dziś bardzo ważna część pracy, zwłaszcza jeśli myślisz o skalowaniu siebie. Wielki motyw: zawsze pytaj, gdzie w tym procesie jestem wąskim gardłem? Dlaczego moi agenci potrzebują mnie do odpowiedzi na to pytanie? I myśl o tym, jak agent ma odpowiedzieć sobie sam — nie przez halucynację, nie przez zgadywanie, ale na podstawie realnych danych. Ludzie mówią o „mózgu firmy” czy „grafie kontekstu” — te terminy są moim zdaniem niepotrzebnie złożone, wręcz abstrakcyjne. Dla mnie chodzi o to: jak wziąć informację, którą agent potrzebuje, a którą inaczej musiałbym mu przekazać sam, i po prostu nauczyć go, jak ją zdobyć? To usuwa mnie z równania.
I tak dochodzę do 2000-cu czy ileś tam PR-ów: mam te pętle ustawione, więc mogę otwierać kolejne restauracje, naprawdę się mnożyć. Nie siedzę i nie zakładam 2500 czatów. Te projekty to nowa funkcja Cursora — „projects”, czyli agenci-koordynatorzy. Koordynator świetnie deleguje: sam nie wykonuje pracy, tylko zarządza listą zadań i spawnuje subagentów do ich wykonania. Ja cały czas podaję kontekst albo uczę agentów, jak zdobyć własny — a oni idą i robią robotę za mnie. I ostatnia rzecz, wielki unlock dojścia do 2000 PR-ów: zacząć od pytania i pracować wstecz — jak dojść do punktu, w którym mój agent sam scali swój kod? Bo oczywista reakcja ludzi, gdy mówię „wysłałem 2500 PR-ów zeszłego miesiąca”, brzmi: „Jak to zrecenzowałeś? To mnóstwo review. Twój zespół musi cię nienawidzić.”
Matt: Możemy tam wejść za chwilę, bo mam pytanie. Najpierw pogłębmy analogię: gdy ręcznie uruchamiasz wszystkie czaty, to jakbyś sam zanosił zamówienia kucharzom. Gdy masz agenta na ekspedycji, samo się kręci. Jak to konkretnie wygląda? Masz Grokboty subskrybujące kanały, ściągające wiadomości, parę agentów-koordynatorów czy szefów sztabu, którzy to nadzorują. Kiedy patrzysz na swój komputer, co widzisz?
Konkrety setupu: Grokbot jako pętla zewnętrzna, projekty Cursora jako wewnętrzna
Poteto: Trochę to zagmatwane — pracujemy nad uproszczeniem i ujednoliceniem. Mamy więc Grokbota, choć można używać innych narzędzi. Traktuję je przede wszystkim jako pętlę zewnętrzną. To narzędzia z konektorami — wielu ludzi nazywa je „osobistymi agentami” — do maila, kalendarza, Slacka, Plaidu i innych usług. Świetnie nadają się do ściągania kontekstu do pracy. Kiedyś, gdy byłem menedżerem zespołu inżynierów — pracowałem w Netflixie — menedżerowie dużo mówili o idei „context, not control”. Co zabawne, niesamowicie przenosi się na świat agentów. Oczywiście możesz dojść do wyniku przez kontrolę, przez mikrozarządzanie — ale chodzi o dostarczanie kontekstu: naucz agenta, naucz inżyniera samodzielności, i przestaniesz ich pilnować.
Konkretnie: mam kilka Grokbotów, które patrzą na moje kanały Slack, X, maile, Linear. Mają rutyny-subskrypcje, stale obserwują. Mówię im np.: „ obserwuj problemy z bugami w aplikacji desktopowej Grokbota, a gdy coś znajdziesz, wyślij do mojego projektu w Cursorze”. Bo Grokbot łączy się z Cursor — a projekt to właśnie agent-koordynator działający w chmurze, z własnym komputerem. To menedżer agentów, twój szef kuchni, szef sztabu. Sam nie robi pracy — deleguje, orkiestruje i zarządza pracą subagentów, przekazuje im kontekst, pcha sprawy do przodu.
Matt: Więc gdy dostaniesz naraz trzydzieści zgłoszeń, koordynator to ogarnia i rozdziela.
Poteto: Dokładnie. Dostaje te trzydzieści payloadów i spawnuje subagentów albo pojedynczego koordynatora. Potrafi budować różne topologie agentów i sam dobiera sposób, jak najefektywniej rozdzielić zadania drużynie. Używam więc dużo projektów Cursora jako pętli wewnętrznej i Grokbota jako zewnętrznej. Grokbot bierze cały kontekst zewnętrzny i przekazuje do projektów — może im po prostu wysyłać wiadomości. Nie musisz nawet otwierać Cursora: mówisz Grokbotowi „stwórz projekt dla tego zestawu zadań, one się ze sobą łączą”. Przykład: masz falę zgłoszeń dotyczących wydajności, aplikacja muli, wszystko jest powiązane, niektóre mają pewnie podobną poprawkę. Możesz oczywiście spawnować jednego agenta na zadanie — ale tracisz nić między nimi. Możesz zdublować pracę albo nie dostrzec problemu wyższego rzędu. Czasem przy naprawianiu bugów having wielu, lekko różnych zgłoszeń pomaga wyjść z bliska: gdy patrzyłem na jedno, myślałem, że bug jest tu, ale gdy widzę całą mnogość — jest tam, wyżej.
Matt: Rozumiem — dlatego masz w tej pętli tylu agentów. Bo gdy przychodzi zgłoszenie i spawnujesz pojedynczego agenta, on będzie dublował pracę innych, skoro kilka zgłoszeń dotyczy tej samej usterki. Fascynujące. I tak: nieustanna seria triggerów od realnych użytkowników z realnymi zgłoszeniami rozpędza fabrykę, dokładając więcej zamówień. Poza bugami — jakie jeszcze źródła pchają te PR-y?
Ogrodnictwo kodu: agenty czytające kod i bufor zamiast spontanicznej naprawy
Poteto: Co zabawne, część pochodzi też ze… czytania kodu. Dla jasności: te 2500 PR-ów to oczywiście nie 2500 feature’ów. Duża część pracy to „ogrodnictwo” — kolejny termin, który bardzo lubię. Ma to szczególne znaczenie, gdy pracujesz z dużym zespołem ludzkich inżynierów, i wraca do środowiska: dobrze urządzone środowisko pomaga nie tylko tobie i twoim agentom, ale wszystkim w drużynie. Pomyśl o nowej osobie, która nie zna waszych praktyk inżynierskich — w dobrym środowisku jest produktywna od pierwszego dnia, nie musi otwierać serii słabych PR-ów, od razu wydaje dobry kod.
Matt: Mam follow-up: jakie są mechaniky triggerowania? Kiedy odpalasz agenta, żeby poszedł popatrzeć na kod? Ktoś powiedziałby: „zróbmy to co godzinę, na cronie”…
Poteto: Widziałem twoje ostatnie tweety o setupowaniu rutyn — świetne. Też mam takie rutyny. Jeden prosty przykład: React ma mnóstwo pułapek, jak zresztą wiesz. Mam więc agenta, który stale szuka zakazanych wzorców. Co ciekawe, nie każę mu od razu niczego naprawiać — każę mu dopisywać znaleziska do dokumentu. A co kilka dni przeglądam tę listę i widzę: to wszystko to samo. Chcesz mieć bufor, kolejkę. Czasem to skuteczniejsze niż spawnowanie armii subagentów do naprawiania każdej rzeczy osobno. Bo w czystym trybie egzekucji, gdy tylko realizujesz nadlatujące zamówienia, łatwo przeoczyć duży obraz. Bufor zmusza cię do myślenia o całości: masz artefakty, na które patrzysz jako człowiek i używasz własnego osądu — albo agenta. Dajesz sobie i agentowi szansę wychwycenia wzorców, które umknęłyby, gdybyś naprawiał każdy bug osobno. I to jest też benefit agenta-szefa sztabu: widzi las, nie tylko wykonuje.
Matt: Fascynujące. Mózg mi się od tego gotuje przy tym „szefie sztabu w fabryce oprogramowania” — pewnie będę musiał zmienić trochę kursu, który kręcę w przyszłym tygodniu.
Review przez próbkowanie: nie każde danie, ale proces
Matt: Porozmawiajmy o review, bo taką właśnie dostajesz odpowiedź: „Czy skosztowałeś wszystkich 2500 dań, gdy przelatywały obok?”. Zakładam, że odpowiedź brzmi: wersja „nie”.
Poteto: Nie chcesz znaleźć się w sytuacji, w której już nigdy nie próbujesz swojego jedzenia. Ale przy tej skali nie da się próbować każdego dania z kuchni, zwłaszcza kilku restauracji. Chodzi więc o próbkowanie i myślenie o procesach. Tu może fabryka jest lepszą analogią: jako inspektor jakości nie obejrzysz każdego egzemplarza — losujesz próbkę. Codziennie patrzysz na pull requesty, na kod, który piszą agenty, i bardzo rygorystycznie go rozkładasz na części. Wypatrujesz nieefektywności, złych wzorców — i myślisz, jak skorygować środowisko. Nie tego jednego agenta. Bo jeśli to jednorazowy incydent — trudno, może nie ma czego naprawiać. Ale jeśli kilku agentów ma ten sam problem, bierze ten sam skrót, propaguje to samo obejście wszędzie — to znak, że trzeba poprawić kuchnię albo fabrykę: przemyśleć skille, constrainty, linty, systemy typów — ustawić tak, by ten problem się nie powtórzył. Gdy zrobisz to wystarczająco wiele razy, dochodzisz do miejsca, w którym kodbaza, środowisko, jest tak ograniczone i tak dobrze prowadzi, że możesz po prostu odejść. To jest ten sen. I od razu mówię: bardzo trudno tu dojść. Nie chcę tego sprzedawać jako czegoś, co zrobisz łatwo, używając pstack. Wymaga mnóstwa czasu i wysiłku — patrzenia na kod, widzenia, gdzie agenci zawodzą, i bardzo przemyślanego ustawiania barier, żeby domyślnie robili dobrze.
Matt: I to nie jest — wracając do analogii fabryki — „ciemna fabryka”, prawda? Światło jest zapalone?
Poteto: W pewnym sensie właśnie jest ciemna.
Matt: Naprawdę?
Poteto: Ciemna w tym sensie, że jeśli moi agenci scalają własne pull requesty, stało się ciemno: idę spać, a agenty pracują 24/7. Mam odpowiednik ponad dziesięciu szefów sztabu, każdy w innym obszarze. Jeden pracuje nad wydajnością aplikacji desktopowej Grokbota. Jeden naprawia bugi zgłaszane przez użytkowników. Jeden eksploruje — czysto dla zabawy — przepisanie jej w innym języku: co by było, gdyby to była aplikacja native? To zabawka. Ale idea jest taka: gdy spędzisz czas na środowisku, dochodzisz do punktu, w którym recenzujesz pull request po jego wylądowaniu. Mówię agentom „pełny autopilot” — to opcja w pstack — a to uruchamia bardzo intensywną, rygorystyczną pętlę weryfikacyjną: dla każdego PR-a spawnuje całą grupę agentów-weryfikatorów i robi fuzzing, czyli faktycznie uruchamia aplikację, klika w nią jak człowiek, szuka regresji i bugów w implementacji, próbuje znaleźć problemy, a potem sam je naprawia. I tak w kółko, aż PR dojdzie do stanu, w którym może wylądować.
Jest to dość intensywne tokenowo — można to stroić: zamiast dziesięciu weryfikatorów może jeden, albo po prostu każesz agentowi zweryfikować swoją pracę. Ale kluczowa jest weryfikacja — to ona daje mi pewność. Weryfikacja plus środowisko: ta kombinacja pozwala mi odejść i powiedzieć: „agenty, scalcie swoje PR-y, ja przejrzę rano historię commitów”. I jeśli zobaczę problemy — koryguję: revertuję, modyfikuję, dodaję reguły lint. Dojście tu wymaga czasu, ale gdy już dojdziesz… czuje się magicznie. Mówię ludziom, że o wiele lepiej śpię. Pierwszego dnia po włączeniu „ciemnej fabryki” było bardzo strasznie — ojej, co jeśli o trzeciej w nocy przyjdzie wołać CEO? Co jeśli coś zepsuję nocą? Wymagało to sporej odwagi, ale jakoś się zdecydowałem. I dziś agenty scalają swój kod, gdy śpię.
Matt: Myślę, że to ciemne w tym sensie… Bo „ciemna fabryka” w oryginalnym rozumieniu, jak u Karpathego z vibe codingiem, to kod właściwie nie istnieje, zapominasz, że kod w ogóle jest czymś. Twoje podejście jest zupełnie inne: kod i środowisko są absolutnie kluczowe, a jeśli są złe — dostaniesz złe wyniki. Śmieci na wejściu, śmieci na wyjściu. To co innego — może jakiś ściemniacz:一部分 ciemne, częściowo jasne. Dlatego kuchnia…
Poteto: Dlatego restauracja może być lepszą analogią — bo nawet jako właściciel sieci ресторанów wpadasz co jakiś czas, zajrzeć do kuchni i spróbować jedzenia.
Matt: Pomysł próbkowania zamiast blokowania na review jest naprawdę ważny.
Drzwi dwukierunkowe i jednokierunkowe: co z domenami trudnymi do weryfikacji
Matt: Co powiedziałbyś ludziom w środowiskach bardzo wrażliwych na bezpieczeństwo — medycyna, prawo, finanse? Niektóre PR-y to „drzwi dwukierunkowe”: scalisz i zrevertujesz, zawrócenie jest tanie. Ale są drzwi jednokierunkowe — powodują utratę danych albo coś, czego nie da się łatwo cofnąć. Co robić, gdy większość twoich PR-ów to drzwi jednokierunkowe? W ogóle tego nie polecasz?
Poteto: Bardzo dobre pytanie. Wszystko sprowadza się dla mnie do jakości weryfikacji, jaką jesteś w stanie uzyskać od agenta. W domenach, gdzie pracę da się zweryfikować, jest łatwiej — drzwi jednokierunkowe stają się w pewnym sensie dwukierunkowe. Ale jeśli pracujesz na czymś bardzo trudnym do zweryfikowania programistycznie, to jesteś w pozycji, w której bardzo trudno do tego dojść. Weryfikowalność domeny to ważny warunek. Inżynieria oprogramowania to zresztą jedna z tych rzeczy, które w wielu przypadkach są weryfikowalne — może nie całkowicie. Podobnie matematyka: nie cała, ale niektóre aspekty — np. gdy piszesz dowód.
To świetne pytanie, na które nie mam pełnej odpowiedzi, i coś, co branża i my, inżynierowie, będziemy musieli rozwiązać. Moja nadzieja i przewidywanie: zobaczymy coraz więcej interesujących, nowych języków programowania projektowanych pod agenty. Jeden z najbardziej fascynujących, jakie widziałem, to Bend. Ten język niejako żeni programowanie z dowodami. Były czasy, gdy dowody trzeba było pisać w osobnym języku. Dla nieznających: dowód (proof) to idea, że możesz formalnie, matematycznie zweryfikować poprawność kodu — zwłaszcza napisanego bardzo funkcyjnie. Przez długi czas robiło się to w osobnym języku, jak Lean czy TLA+ — konstruowałeś dowód matematyczny, a potem solver sprawdzał, że pokryłeś wszystkie przypadki i nie masz np. race condition. Podsumowując: jeśli jesteś w stanie sprawić, by twoje agenty naprawdę weryfikowały pracę w sposób dający ci pewność, możesz pozwolić PR-om się scalać. Bo jeśli się kompiluje, jeśli dowody pokazują poprawność — czemu nie scalić? Ale oczywiście: nie wszystko da się zweryfikować. To trudne.
Skille jako proces zapisany słowami: łączenie bibliotek i własne noże
Matt: Zbliża się godzina, więc ostatnie pytanie. Jak widzisz pstack i skille w ogóle — bo rozmawialiśmy o tym przed emisją — ludzie myślą „twoje skille kontra moje”, jak łączyć frameworki? Jak używać pstack razem z moimi rzeczami, co brać z każdego? Ja widzę skille po prostu jako proces zamieniony w słowa — i chciałbym wiedzieć, jak zalecasz ludziom brać pstack i moje rzeczy i zamieniać we własne procesy.
Poteto: Udostępniłeś zresztą dziś tip bardzo trafiony: przeglądanie własnych, poprzednich transkrypcji. Kopanie w informacje z własnych promptów do agentów — tam, gdzie ich poprawiałeś, gdzie musiałeś stale interweniować — i wyciąganie z tego wiedzy wyższego rzędu, zamiana jej w reużywalny skill, żeby agent przestał powtarzać ten błąd. pstack i twoje skille są bardzo komplementarne. Zgadzam się w pełni: skill to naprawdę proces. To ostatecznie po prostu angielski — język. Markdown. Można je plątać i łączyć, jak ci pasuje.
Ale każdy powinien mieć własny zestaw noży. Wracam do gotowania, bo jest tak trafne: każdy kucharz, idąc do innej pracy, do innej restauracji, zabiera swoje noże. Narzędzia idą z nim. Zaufanie to dla mnie zaufanie do własnych narzędzi. Gdy spędzisz czas na ich ostrzeniu i naprawdę je zrozumiesz, możesz zdziałać świetne rzeczy. A zestaw skilli każdego będzie wyglądał inaczej. Ktoś odniesie sukces, łącząc twojego „grill me” z dokumentacją czy wayfindera z umiejętnościami wykonaniowymi z pstack. Ktoś użyje więcej twoich, ktoś więcej moich. Ostatecznie wraca do pytania: komu ufasz — mnie i Mattowi? Jeśli nam obu — używajcie naszych skilli. Ale zachęcam też: patrzcie we własne transkrypcje. Każcie agenta przejrzeć wzorce, które używaliście, momenty interwencji, i zaproponować zamianę ich w reguły lint albo nowe skille. Przeszłe czaty to często skarbnica kontekstu — proces zmaterializowany. Nie abstrakcja w głowie, ale realna rzecz: widzisz, jak to się stało w praktyce, i możesz wyciągnąć masę informacji.
Mam w pstack skill o nazwie recall — dokładnie o tym. Powstał z wzorca: pracowałem nad wirtualizacją w aplikacji Cursora, było dużo bugów, i za każdym razem przy nowym czacie myślałem: ileż dobrego kontekstu jest w poprzednim — jak go przenieść? Stąd patrzenie w przeszłe transkrypcje, a recall to po prostu zagęszczenie tego workflow w skill, żebym nie musiał za każdym razem pisać długiego eseju: „idź do tamtych czatów i zrób to i tamto”.
Myślę więc o skillach — zwłaszcza gdy agenty stają się zdolniejsze — jako o zapisie workflow. Skille z zeszłego roku były bardziej o detalach implementacyjnych: dokładne komendy skryptowe, których użyć. Przy najnowszych modelach te fragmenty można po prostu wywalić i skupić się na workflow — skill staje się ciągiem kroków, twojego procesu. Z czasem skille będą coraz mniejsze, bardziej kompaktowe. I są bardzo kompatybilne — a jak chcesz, po prostu przeczytaj nasze skille i połącz po swojemu: wayfinder z potato mode i zrób własny customowy tryb. To, co kocham w skillach, to ich plastyczność. Możesz zrobić, co chcesz. To tylko język.
Matt: Absolutnie. Nie ma w nich żadnej magii — to słowa.
Poteto: No i jeśli jest w nich jakaś magia, to właśnie w doborze słów i fraz oraz w myśleniu włożonym w zamianę abstrakcyjnego procesu w język. A gdy to myślenie już jest zrobione — jest. Jest dostępne, na powierzchni. I po prostu je podkradasz. Lauren, dziękuję ci ogromnie. To było wspaniałe.
Matt: Też świetnie się bawiłem, trzeba to powtórzyć.
Poteto: Koniecznie, może w poniedziałek? Część druga.
Matt: Wielkie dzięki. Zamykam stream — zostańcie, pogadamy jeszcze chwilę. Dziękuję wam wszystkim za oglądanie.