O czym jest ten film
- Theo prezentuje trzy własne skille dla agentów kodujących — Sol Loop, Full Send i Full Stop. Nie zaprojektował ich z góry: to czynności, które powtarzał w kółko, aż zamienił je w pliki Markdown.
- Sol Loop to pętla recenzji: inny model (GPT‑6.1 Sol) przegląda kod przed wystawieniem PR-a — z limitem trzech rund (do pięciu przy ryzyku bezpieczeństwa), jednym recenzentem naraz i zakazem odpalania własnych subagentów.
- Full Send daje pełną autonomię: agent doprowadza pracę od bieżącego stanu do scalonego PR-a, z wymogiem dowodów działania, bramkami scalenia i zasadą, że o człowieka pyta wyłącznie narzędziem blokującym.
- Full Stop robi wszystko co Full Send, oprócz samego scalenia: poprawia, weryfikuje, wystawia i pilnuje PR-a, a człowieka woła dopiero, gdy temat jest gotowy do decyzji.
- Kluczowa lekcja warsztatowa: pole „description” w skillu to wyzwalacz, nie opis — dlatego Theo nie używa komend /slash, tylko zwykłych fraz typu „full stop takeover sol loop”.
- Repo „fleet” trzyma skille, klucze i serwery MCP w ryzach na całej flocie maszyn sterowanych z T3 Code; Orchestrator V2 pozwala agentowi wywoływać inne modele (Muse, Gemini, GPT) w ich natywnych środowiskach.
- Proxy CLI zbiera autoryzację do wszystkich modeli w jednym miejscu i loguje ruch do ClickHouse; przy okazji przestroga — Anthropic pilnuje, by modele Claude pracowały tylko z natywnym promptem Claude Code, OpenAI takich ograniczeń nie stawia.
- Liczby: w badanym oknie 32 wywołania Full Send, z czego 27 PR-ów scaliło się bez ponownego spojrzenia Theo — i ani jeden nie narobił problemów.
- Domykają całość pomocnicze skille: Takeover (przejmowanie cudzych PR-ów z zachowaniem autorstwa) i Modernize (rebase i zamykanie nieaktualnych zgłoszeń).
- Na koniec zapowiedzi: publiczne repo skilli T-Stack oraz kurs MegaDev o wydawaniu z AI w realnych firmach; morał — kodujcie własne zaufanie do agentów w pliki, zamiast kopiować cudze.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Opis skilla to wyzwalacz, nie dokumentacja
Na czym polega: Pole „description” nie opisuje zawartości pliku — mówi modelowi, kiedy go odpalić. Theo pisze mechaniczne warunki w stylu „użyj, gdy użytkownik powie Sol Loop”, więc wystarczy fraza w zdaniu (albo dyktowanie głosowe), by uruchomić właściwy plik.
Jak stosować: W każdym skillu opisujcie scenę użycia, nie zawartość. W jednej wypowiedzi można łączyć wyzwalacze: „full stop takeover sol loop” odpali trzy pliki naraz.
Na co uważać: Zbyt ogólny opis sprawi, że model będzie wciągał skill sam z siebie. Do plików dających autonomię dodajcie klauzulę: „jeśli użytkownik wyraźnie nie poprosił — nie zakładaj pełnej samodzielności”.
2.Zewnętrzny recenzent w pętli, ale z budżetem
Na czem polega: — popraw: Na czym polega: Sol Loop każe drugiemu modelowi recenzować własny kod przed wystawieniem PR-a. Rundy są limitowane (domyślnie trzy), a w późniejszych sprawdzany jest tylko zmieniony kod i otwarte uwagi.
Jak stosować: Kod piszecie w modelu, z którym najlepiej się współpracuje (u Theo: Opus 5.5), a do recenzji puszczacie model-drażniłę (GPT‑6.1 Sol — „rottweiler, który nie puszcza”). Rozszerzajcie pętlę do pięciu rund tylko przy ryzyku bezpieczeństwa, uprawnień lub utraty danych; kończcie wcześniej, gdy zostają same drobiazgi.
Na co uważać: Wielu recenzentów z różnymi opiniami to prosta droga do przerostu zakresu i PR-a dwa razy większego, niż trzeba. Jeden recenzent naraz, zakaz odpalania subagentów i obowiązek zapisywania zgłaszanych uwag.
3.Różne modele widzą różne błędy — rozmnożcie recenzentów
Na czym polega: Modele mają odmienny trening, więc działają jak trzej recenzenci o różnych doświadczeniach — każdy łapie co innego. W obserwacjach Theo: modele OpenAI są najdokładniejsze, Claude wyławia dziwne, potencjalnie niebezpieczne rzeczy, a Gemini częściej halucynuje, niż faktycznie znajduje.
Jak stosować: Zacznijcie od minimalnej pętli: delegujcie przegląd do kilku subagentów, porównajcie odpowiedzi, dopracujcie polecenia i powtórzcie. W T3 Code robi to Orchestrator V2, który podnosi inne modele w ich natywnych środowiskach.
Na co uważać: Koszty i czas rosną z każdym dodatkowym głosem, a każdy głos trzeba jakoś pogodzić — znowu pilnujcie zakresu zmian.
4.Autonomia wymaga jawnego, wąskiego pozwolenia
Na czym polega: Niektóre modele — zwłaszcza u OpenAI — ociągają się ze scaleniem, dopóki w kontekście nie znajdą wyraźnej zgody użytkownika. Theo wpisuje więc w skill dosłowne zdanie: „Theo udzielił ci pozwolenia na scalenie PR-a, gdy przejdą bramki, oraz na force push (—force-with-lease) własnej gałęzi po rebasie”.
Jak stosować: Wypisujcie zgody konkretnie: na co, kiedy i na jakich warunkach — nigdy ogólnikowe „działaj samodzielnie”.
Na co uważać: Pozwolenie-karta blankietowa. Scalanie tylko po spełnieniu bramek, siłowe pushowanie wyłącznie własnej gałęzi.
5.„Udowodnij, że działa” — dowody z sesji, nie deklaracje
Na czym polega: Sekcja dowodowa wymaga rzeczy zaobserwowanych na miejscu: wyników poleceń, reprodukcji usterki, zrzutów ekranu. Najmocniejszy schemat: odtwórz usterkę, nałóż poprawkę, obejrzyj, jak ta sama reprodukcja przechodzi.
Jak stosować: Wpiszcie do skilla listę dowodów: testy odpalane przez CI, jeden celowany test padający bez poprawki, uruchomiona aplikacja przy zmianach w UI, screenshot lub wideo z sesji.
Na co uważać: Zielone testy na mockach nie dowodzą, co poczuje użytkownik. Bez wymogu model chętnie ograniczy się do deklaracji „działa”.
6.Bramki scalenia jako twarda checklista
Na czym polega: Zanim agent sam scali PR, muszą zajść: dowody pokrywające każdą zmianę, zielone wymagane checki, zamknięte boty recenzenckie (uwagi naprawione albo odpisane na piśmie), brak ludzkich zastrzeżeń, aktualna gałąź i status „mergeable” z GitHuba.
Jak stosować: Zapiszcie bramki w skillu jako warunki konieczne — model sprawdzi je sam, zanim sięgnie po przycisk.
Na co uważać: Pominięta bramka to prosta droga do samodzielnego scalenia niedopracowanej zmiany. Co jakiś czas przejrzyjcie, czy model nie nauczył się bramek omijać.
7.Pytania do człowieka tylko przez narzędzie blokujące
Na czym polega: Pytanie w zwykłej wiadomości ginie — wątek wygląda na zakończony. Dopiero narzędzie typu Ask User Question (Claude Code) czy Request User Input (Codex) wynosi wątek do skrzynki i pokazuje, że czeka na odpowiedź.
Jak stosować: W skilu wypiszcie narzędzia dla każdego środowiska i wymagajcie pełnego kontekstu w pytaniu: link do PR-a, co blokuje, jakie opcje rekomenduje — z najlepszą na początku.
Na co uważać: Bez bramki „pytaj tylko, gdy sam nie możesz iść dalej” model zasypie was pytaniami i cała autonomia traci sens.
8.Dwa tryby autonomii: do merga i do decyzji
Na czym polega: Full Send prowadzi wątek aż do scalonego PR-a (32 użycia, 27 samodzielnych scalęń); Full Stop robi wszystko oprócz scalenia i woła człowieka dopiero, gdy rzecz jest gotowa do decyzji.
Jak stosować: Drobnym, zrozumiałym zmianom dajcie pełny bieg; zmianom kosmatym i dotykającym ryzyka — wersję bez ostatniego kroku, a o scaleniu decydujecie wy.
Na co uważać: Autonomia nie zastępuje siatek bezpieczeństwa — błędy i tak się zdarzą. Potrzebujecie szybkiego wykrycia (np. wydanie nocne co sześć godzin) i łatwego cofania zmian.
9.Przejmujcie cudze PR-y z poszanowaniem autorstwa
Na czym polega: Takeover każe agentowi ocenić obcy PR (kontynuować czy potraktować jako punkt odniesienia), doprowadzić temat do końca — nowym albo istniejącym PR-em — i zachować zasługi pierwotnego autora. Modernize dopina rebase na main i zamykanie zgłoszeń, które stały się zbędne.
Jak stosować: Gdy zgłoszenie jest cenne, ale niedopracowane, wystarczy wkleić link i napisać „przejmij, full stop” — resztą zajmie się agent.
Na co uważać: Nic tak nie zniechęca kontrybutorów jak zamknięty PR z przejętym pomysłem. Przypisywanie autorstwa wymuszajcie jawnie, w treści skilla.
10.Skille rosną z powtórzeń, nie z projektów
Na czym polega: Cały „graf” Theo (Modernize → Takeover → Sol Loop → Full Send → Full Stop) narósł z czynności, które powtarzał, aż zamienił je w pliki. Skille są plastyczne: widzisz złe zachowanie, pytasz model dlaczego, poprawiasz plik.
Jak stosować: Przez tydzień notujcie, co mówicie agentom w kółko — to kandydaci na skille. Aktualizujcie je zwykłym poleceniem („zmień opis na…”) i raz na jakiś czas czyśćcie nalot.
Na co uważać: Kopiowanie cudzych skilli jeden do jeden przenosi czyjś sposób pracy, nie wasz. Pliki pisane przez modele puchną — ręczna korekta to nie fanaberia.
Redakcyjne tłumaczenie
Trzy pliki Markdown zamiast frameworków
No, czasy się zmieniły. Pamiętam jeszcze, kiedy siadałem przed kamerą i opowiadałem wam o nowych technologiach, frameworkach i sposobach pisania oprogramowania. A dziś nagram cały materiał o trzech plikach Markdown. Na pewnym poziomie brzmi to absurdalnie, ale te pliki realnie odmieniły sposób, w jaki buduję.
Ostatnio korzystam z tych trzech umiejętności bez ustanku i dostaję o nie tyle pytań, że w końcu czas usiąść i spokojnie wyjaśnić, co robią i jak ich używam. Nazywają się Sol Loop, Full Send i Full Stop.
Nie wymyśliłem ich przy biurku jako genialnej koncepcji, którą postanowiłem wcisnąć do swojej pracy. Zdarzyło się odwrotnie: to zachowania, które zauważałem u siebie w kółko, dopóki nie zamieniłem ich w pliki. Przy pracy nad T3 Code niemal połowa moich wątków korzysta z jednej z tych trzech — i przyjąłbym zakład, że te, które docierają do maina, prawie zawsze używają co najmniej jednej. Pomogły mi ugruntować warsztat i mam nadzieję, że po tym materiale wy będziecie budować skuteczniej.
(Informacja dodatkowa: „skille” w narzędziach takich jak Claude Code to pliki Markdown z instrukcjami, które model doładowuje do kontekstu, gdy uzna — albo dostanie sygnał — że są potrzebne.)
Zanim przejdę do sedna, jeszcze jedna rzecz, która też pomaga mi budować: dzisiejszy sponsor.
Reklama: WorkOS
Współczesne modele AI zrobiły przepisywanie rzeczy od zera podejrzanie łatwym — dotyczy to niemal wszystkiego, na czym wasza firma pewnie polega. U mnie robimy tego mnóstwo, żeby ciąć koszty i lepiej dopasować narzędzia do własnych potrzeb. Ale zauważyłem, że pewne obszary stawiają opór niezależnie od jakości własnych rozwiązań. Co, jeśli powiem wam, że jeden z nich jest tak upierdliwy, że nawet OpenAI i Anthropic zdecydowały się na zewnętrznego dostawcę zamiast pisać samodzielnie? Gdybym dodał, że chodzi o uwierzytelnianie, uznalibyście mnie chyba za wariata. Niestety, auth doprowadził do białej gorączki nawet mnie — i dlatego tak cenię WorkOS.
Nie bez powodu liczą się na nim wszyscy — od OpenAI i Anthropic po Cursor — jeśli chodzi o warstwę logowania. I nie chodzi tylko o to, że podstawy są trudne. Szczerze: dopięcie prostego przycisku „Zaloguj się przez Google” jest w miarę bezbolesne, o ile przebrniecie przez Google’owskie konsole. Kłopoty zaczynają się przy innych typach klientów — na przykład przedsiębiorstwach z bardzo konkretnymi wymaganiami swoich nietypowych konfiguracji SSO. Panel administracyjny WorkOS bierze to na siebie: wysyłacie firmie link, a ona rejestruje się, jak chce. Potem któryś z tych klientów zgłosi się z prośbą o MCP do połączenia ze swoimi agentami — i skonfigurowanie dla tego uwierzytelniania graniczy z cudem. No, chyba że używacie WorkOS: obsługa MCP jest tam wbudowana. A co, jeśli chcecie pójść dalej — żeby wasi agenci sami rejestrowali się w usłudze? Wtedy wchodzi AuthMD. To nie tylko produkt WorkOS; to standard zbudowany razem m.in. z Cloudflare i Firecrawl, dający agentom porządny sposób zapisywania się do usługi w imieniu użytkownika. I jak się domyślacie: przy AuthKicie w WorkOS konfiguracja sprowadza się do jednego kliknięcia. Ogarnijcie uwierzytelnianie dla firm i agentów na swiyft.link/workos.
Repo „fleet”, czyli gdzie mieszkają moje skille
Najłatwiej przejść po tych trzech skillach po kolei, ale dużo więcej zrozumiecie, gdy pokażę, jak w ogóle zarządzam swoimi umiejętnościami.
Mam na komputerze repozytorium o nazwie fleet. To praktycznie jedyne repo, jakie w ogóle otwieram w VS Code. Przechowuję tam dane o całej mojej flocie maszyn — komputerów, na których pracuję. Jeżeli nie znacie: T3 Code potrafi łączyć się z wieloma maszynami i sterować nimi z jednej aplikacji albo z telefonu, co jest bardzo wygodne. Ale trzymanie wszystkiego zsynchronizowanego między komputerami — logowania, skilli, serwerów MCP — potrafi boleć. Dlatego mam ten jeden magazynek, w którym ogarniam całość. W środku foldery pogrupowane według typów: jedne skille lubię tylko w Claude, inne tylko na konkretnej maszynie, którą nazywam command center, a jeszcze inne chcę mieć wszędzie. Prawdopodobnie zrobię niedługo porządki i sporo usunę, bo korzystam z mniejszej części, niż planowałem.
(Informacja dodatkowa: T3 Code — rozwijany przez Theo, darmowy i otwarty edytor do pracy z agentami kodującymi.)
Do grilla z Mattem Pocockiem wracam z przyjemnością co jakiś czas, ale w praktyce krążę głównie wokół Sol Loop, Full Send i Full Stop, a do tego wszystkiego, co dotyczy PR-ów — File PR, Babysit PR — których używam bardzo dużo. Przydaje się też skill do zostawiania komentarzy: prosty plik, który każe moim agentom zaznaczać, jakim są modelem i że piszą w moim imieniu, gdy komentują z mojego konta.
(Informacja dodatkowa: Matt Pocock — znany edukator TypeScripta; jego „grilling skill” zmusza model do szczegółowego wypytania użytkownika o plan, zanim cokolwiek napisze.)
Ale nie o tym dziś. Jesteśmy tu dla Sol Loop.
Sol Loop — pętla recenzji z budżetem
Powtarzałem wielokrotnie — i nadal w to wierzę, choć sam nie zawsze się stosuję — że takie pliki najlepiej pisać samemu. Ten akurat częściowo oddałem w ręce agentów. Początkowo napisałem go ręcznie, potem zauważyłem parę rzeczy, które Claude robi źle, więc poprosiłem go o poprawienie pliku. Wczoraj wieczorem otworzyłem go po dłuższej przerwie i zobaczyłem, że spuchł — w najbliższym czasie trzeba to posprzątać. Na razie liczy się rdzeń.
I od razu jedna ważna rzecz: pole „description”. Nie jest tym, czym sugeruje nazwa. Nie ma opisywać, czym jest skill — to wskaźnik dla modelu, kiedy go użyć. Moje opisy są więc banalne. To po prostu wyzwalacze: opisuję moment, w którym model ma dane zadanie odpalić. Skill nazywa się Sol Loop, a opis brzmi: „użyj, gdy użytkownik powie Sol Loop”. Tyle. Ten plik nie powinien być wciągany do kontekstu, dopóki nie padnie wprost — ode mnie albo z innego skilla.
A co ten skill robi? W skrócie: ty odpowiadasz za kod, a Sol go recenzuje. Napraw to, co słuszne, sprzeciwiaj się temu, co błędne, i zakończ, gdy dojdziesz do zgody albo skończy się budżet. Cel: najmniejsza zmiana, która spełnia intencję. Recenzje mają czynić kod poprawnym, nie większym. Ten ostatni akapit to slop, który model dorzucił od siebie — gołym okiem widać, że pisał to Opus. Przepiszę to teraz po swojemu.
I przepisałem. Nowa wersja mówi, do czego plik służy: to workflow, który ma uczynić zmiany w kodzie bardziej poprawnymi — przed wystawieniem pull requesta, a czasem już po jego otwarciu. W wielkim skrócie: używaj GPT‑6.1 Sol do przeglądu kodu w pętli; wprowadzaj najmniejsze możliwe zmiany, żeby zadowolić recenzenta; uważaj na przerost zakresu i nie bój się odmawiać.
Te dwa ostatnie zdania są kluczowe. Pułapka tego typu pliku: zbyt wiele agentów z odmiennymi opiniami, które się przekrzykują, i po chwili zakres eksploduje, a PR wychodzi znacznie większy, niż musiał być. Ta prosta linijka zapobiega większości takich scenariuszy.
Jest też budżet — ile tego ma być, bo inaczej pętla nie ma końca. U mnie: łącznie trzy rundy. Pierwsza pełna; kolejne sprawdzają tylko zmieniony kod i otwarte uwagi. Pięć rund tylko przy ryzyku bezpieczeństwa, uprawnień, utraty danych albo czymś w tym stylu. Kończ wcześniej, jeśli runda zwraca wyłącznie drobiazgi — drobiazgi oraz uwagi o komentarzach, dokumentacji i tym podobnych pomijaj. Zawsze tylko jeden recenzent naraz. Sol nie może odpalać własnych subagentów ani recenzentów, bo zagnieżdżanie urośnie w okamgnieniu. I niech prowadzi rejestr rzeczy, które zgłasza. Jest jeszcze fragment o zakresie i sekcja o tym, jak w ogóle wywołać Sola — da się to zrobić na kilka sposobów.
Jak się domyślacie, najczęściej używam tego skilla z Opusem 5.5. To po prostu lepszy współpracownik: sprytniejszy, pisze znacznie lepszy kod, przyjemniej się z nim pracuje. Ale GPT‑6.1 Sol jest dokładniejszy. Czuję w nim rottweilera — jak już coś chwyci w zęby, to nie puszcza — i właśnie dlatego uwielbiam go w roli recenzenta.
(Informacja dodatkowa: transkrypcja filmu jest automatyczna — nazwy modeli i narzędzi, m.in. GPT‑6.1 Sol, Gemini 4 Argon i Muse, mogą nieznacznie odbiegać od oficjalnych.)
Zdumiewa mnie, ile ten workflow zdążył uchronić PR-ów przed nieskończoną pętlą recenzji po wejściu na GitHuba. Odpalenie tego u siebie, na własnej maszynie, świetnie robi za pierwsze przepuszczenie — zanim zmiana trafi do PR-a i do narzędzi typu Macroscope, Graphite czy CodeRabbit, bywa już przyzwoicie dopracowana. Bonus: tak wykorzystujecie to, co opłaca wam abonament Codex. U mnie Codex ostatnio leży odłogiem, a na co dzień siedzę w Opusie — dzięki temu workflow subskrypcja wciąż pracuje.
Jeszcze jeden drobiazg, który bardzo lubię: na końcu pliku jest zapis, że po wystawieniu lub aktualizacji PR-a ma się pojawić sekcja „Przejrzano z Sol Loop, N rund, model X”, a pod nią osobno „Werdykt Sola: zatwierdzony”. Dlaczego? Kilka razy złapałem Opusa na tym, że niemal maskował, iż Sol nie był zachwycony zmianami. Ten dopisek zmusza go do jawności. I właśnie dlatego te pliki trzeba samemu edytować.
No to lecę: aktualizuję skilla Sol Loop, komentarz commitu „poprawa formatowania” i push na całą flotę.
Proxy CLI: jeden adres na wszystkie modele
Jedno wcześniej umknęło: jak w praktyce dać Claude Code’owi dostęp do Sola. Da się na kilka sposobów, a najprostszy w narzędziu takim jak Claude Code to postawić proxy dla interfejsów CLI — cała autoryzacja w jednym miejscu. Robię to już od dawna i dostosowałem panel po swojemu: jak szybko wypalam limity, dokąd płynie ruch. Poszedłem krok dalej i zrzucam wszystkie zapytania i odpowiedzi do bazy ClickHouse, żeby móc je odpytywać i wyciągać sensowne wnioski. To jeden z moich ulubionych elementów setupu; szczerze polecam sforkować coś takiego i ogarnąć u siebie. A gdy już to macie, wszystkie dostępne w proxy modele używacie w dowolnych narzędziach.
Uwaga jednak na modele Claude poza domem. Jeśli pracujecie na abonamencie Claude Code, Anthropic bardzo pilnuje, żeby systemowy prompt był dokładnie ten od Claude Code. Subskrypcjami Claude płacicie więc tylko w Claude. Subskrypcje Codex — w Codexie, ale też na przykład w Claude, bo OpenAI w praktyce nie patrzy, gdzie konsumujecie tokeny. Anthropicowi zależy, OpenAI nie. Jeżeli to zbudujecie, trzymajcie rękę na pulsie. Wspominam o tym, bo proxy bardzo ułatwia podpięcie modeli OpenAI do Claude Code. A jeśli boicie się bana — spokojnie: Tibo wrzucił cytata z tym rozwiązaniem i napisał, że jest „błogosławionym”, a jeśli mimo to dostaniecie blokadę, to należy wam się reset. Oficjalnie: dozwolone.
(Informacja dodatkowa: Tibo — inżynier Anthropic związany z Claude Code.)
Orchestrator V2: niech inne modele przejrzą twoje zmiany
Tak właśnie robiłem to przez jakiś czas — do momentu, aż na nocnym kanale T3 Code wylądował Orchestrator V2. W dwóch słowach: wasi agenci i wątki mogą teraz wywoływać innych agentów, inne środowiska, inne wątki — wszystko w ramach T3 Code.
Pokażę na wątku, w którym wystawiłem PR zmieniający sposób logowania danych o połączeniach do bazy SQLite. Mówię do niego: „Niech Muse, przecudowny GPT‑6.1 Sol i Gemini 4 Argon przejrzą twoje zmiany w delegatach. Reaguj na przydatne uwagi”. I mimo że sam siedzę teraz na Opusie w Claude Code — który, nawiasem mówiąc, w T3 Code korzysta z waszego prawdziwego Claude Code i prawdziwej subskrypcji — orkiestrator wbudowany w T3 podniesie teraz wszystkich pozostałych agentów w ich natywnych środowiskach. Nie upycham tu Sola w Claude Code: nauczyłem Claude Code wołać modele Muse, Codex i Gemini z poziomu samego T3 Code. Widzicie, jak odpalają się subagenci — każdy dostaje własny wątek, w którym przegląda zmiany i komunikuje się z głównym. Konfiguracja robi się dużo prostsza. Na nightly to już jest; wersja stabilna tuż-tuż.
Możliwość wysyłania subagentów po opinie jest świetna nie dlatego, że „wykorzystujemy wszystkie subskrypcje”, ale dlatego, że modele mają inny trening i inaczej się zachowują. To trochę jak z trzema recenzentami o różnych doświadczeniach: rośnie szansa, że każdy wypatrzy coś wyjątkowego. W moich obserwacjach modele OpenAI są najdokładniejsze i znajdują najwięcej; modele Claude wyławiają dziwne, potencjalnie niebezpieczne rzeczy, które innym umykają; Muse i Gemini coś tam znajdą, choć Gemini częściej halucynuje, niż faktycznie znajduje. A jeśli nie chcecie od razu budować tego na skalę albo tylko testujecie przepływ, świetna jest rada Morga: deleguj do N subagentów, porównaj odpowiedzi, dopracuj polecenia i powtórz tyle razy, ile trzeba.
I proszę — werdykt Sola: „brak istotnych uwag do kodu produktowego, wszystkie siedem testów przeszło”, do tego lista mniej ważnych spraw. Rozumiecie mechanizm. Kiedy odpalam ten skill, PR wjeżdżający na górę ma mniej problemów, częściej jest poprawny, szybciej przechodzi recenzję i szybciej się scala. Tak, od wysłania polecenia do otwarcia PR mija więcej czasu — ale zamykanie trwa nieporównywalnie krócej. A przede wszystkim, i to cenię najbardziej: nie chcę wysypywać na zespół sterty slopu, a ten plik realnie ogranicza ryzyko, że automatyczne chałactwo z wątku — w T3 Code czy czymkolwiek innym — wyleci pull requestem w świat. Jeśli kiedykolwiek obejrzeliście PR-y wystawione przez waszych agentów i poczuliście wyrzuty sumienia, to powinno wam pomóc.
Full Send — najpierw skrzynka, potem przepływ
Czas na pozostałe dwie umiejętności: Full Stop i Full Send. Sensowniej zacząć od Full Send, ale najpierw słowo o tym, jak w ogóle pracuję w T3 Code — i tak, powoli robi się z tego reklama T3 Code. Przepraszam; jest darmowy i otwarty, więc mam nadzieję, że nie będziecie źli, że wbudowuję w produkt to, co lubię.
Jeśli nie znacie T3 Code, kluczowa zmiana myślenia brzmi: pasek boczny to skrzynka odbiorcza. Gdy praca jest skończona, ma zniknąć. „Settled” działa jak archiwum: gdy zmiana się scala, gdy ją wyrzucacie albo gdy problem jest rozwiązany — śmiało zamykajcie wątek, bez sentymentów. Ideałem jest mała liczba wątków w danym momencie. Pokażę na przykładzie: wątek z otwartym PR-em, który właśnie przejrzałem i wygląda dobrze. Ten PR scalił się na GitHubie w maksymalnie minutę po zerknięciu — pewnie szybciej. Wątek dostaje status „zmergowany”; nie zamknął się automatycznie, bo wyłączyłem tę opcję (długi temat), ale gdybym tego nie zrobił, po prostu by zniknął. I o to chodzi: w T3 Code każdy wątek powinien albo pracować, albo nie istnieć.
Dlatego tak mocno optymalizuję pod szybkie scalanie PR-ów — bo chcę, żeby wątki znikały. Nie mówię „scalajcie byle co”. Mówię: minimalizujcie objętość rzeczy czekających na waszą reakcję i tak ułatwiajcie świadome scalanie, żeby wątki mogły znikać. Pod koniec dnia chcę mieć sporo w sekcji roboczej, a jak najmniej tematów, na które jestem coś winien odpowiedzią.
Do tego dochodzi sekcja „optional working” w T3 Code — funkcja beta, bardzo mi się podoba; być może wkrótce zrobię z niej domyślną (co zabawne, właśnie uczynili ją domyślną w Claude Code). Chodzi o to, że wątek, który akurat pracuje, nie wymaga uwagi — ma się schować, dopóki nie będzie na nas gotowy. Oznacza to też, że nie widzę, co robi w trakcie: ten akurat kręci dziesięcioma subagentami. Gdyby chciał mi coś pokazać, nie zobaczę tego, dopóki siedzi pod sekcją roboczą — i uważam, że tak jest dobrze. A jeśli zada pytanie narzędziem blokującym, zostanie wyrwany do góry, prosto do skrzynki. Wokół tego zbudowałem więcej mojego sposobu pracy.
Chciałem umieć: zgodzić się z modelem, wiedzieć z grubsza, co zrobi, i wiedzieć, że zweryfikuje, przetestuje, sprawdzi. I żeby przy małej poprawce — kiedy wiem, co i jak zostanie zrobione, albo fix już jest i została jedna drobnostka do scalenia — nie wracać do tego wątku. Nie chcę, żeby od nowa mi przerywał i zmuszał do przypominania sobie wszystkiego tylko po to, bym kliknął jeden przycisk. Ideał: gdy już passesamy się z modelem tam i z powrotem i mam pewność, że wie, czego chcę i z grubsza jak to zrobić — niech odezwie się tylko, jeśli utknie.
Wnętrze Full Send: pozwolenia, dowody, bramki, pytania
Stąd właśnie wziął się Full Send. Opis — jak zawsze — to wyzwalacz: „użyj, gdy użytkownik prosi o full send”. A treść zaczyna się tak: skoro użytkownik to wywołał, to znaczy, że nie śledzi wątku i chce, żebyś dokończył pracę samodzielnie od początku do końca. Twoje statusy i wiadomość końcowa zostaną przeczytane długo po tym, jak przestaniesz działać. Prowadzisz tę pracę od obecnego stanu aż do scalonego PR-a. Jeśli użytkownik w wyraźny sposób o to nie poprosił — nie zakładaj pełnej autonomii. To zabezpieczenie na wypadek, gdyby model wciągnął plik losowo.
Wprost wypisuję, na co daję pozwolenie, bo zauważyłem, że niektóre modele — zwłaszcza u OpenAI — stają się niepewne przed scaleniem, dopóki nie znajdą w kontekście jasnego „użytkownik pozwolił”. U mnie figuruje więc zdanie: „Theo udzielił ci pozwolenia na scalenie PR-a, gdy przejdą bramki, oraz na force push (—force-with-lease) własnej gałęzi PR-a po rebasie”. Wszystkie te punkty wzięły się tak samo: moje skille są plastyczne. Widzę, że coś działa nie tak, pytam model „czemu to zrobiłeś?”, słyszę „uznałem, że…, bo…”, poprawiam plik — i niechciane zachowanie znika. Cała ta lista to reakcje na zgryzotliwości modeli OpenAI.
Potem opisuję przepływ: dokończ zmianę, udowodnij, wystaw PR, dopilnuj go, scal, zamelduj. Sekcja „udowodnij” jest kluczowa — chcę, żeby model znalazł sposób sprawdzenia, że jego zmiany działają. Odsyłam też do innych skilli, żeby porządnie pilnował PR-ów, bo mój Babysit PR prowadził kiedyś do tego, że modele OpenAI ignorowały wbudowane obserwatory T3 Code i zamiast tego wyprawiały głupoty — stąd dopisek: „w T3 Code używaj funkcji watch pull request; jeśli przerywasz przed scaleniem, najpierw wywołaj unwatch pull request”. Znów: łatanie skillów.
Jest sekcja o dowodach. Dowód to coś, co sam zaobserwowałeś w tej sesji: wyniki poleceń, reprodukcję, zrzuty ekranu. Wybieraj najbardziej bezpośredni dowód, jaki pozwala zmiana:
- odtwórz pierwotną usterkę, nałóż poprawkę i obejrzyj, jak ta sama reprodukcja przechodzi;
- uruchom testy, które odpala CI repozytorium;
- jeśli zachowanie nie ma jeszcze testu, a repo ma infrastrukturę testową — dodaj jeden celowany test, który bez poprawki pada;
- sprawdź interfejs i działanie na żywo: uruchom aplikację i spójrz na zmianę.
Zielone testy na mockach nie dowodzą, co poczuje użytkownik. Dorzucam też odnośnik do skilla uploadu plików, żeby przy dowodzeniu mógł wrzucić screenshot czy wideo.
Następnie jawnie zapisane bramki scalenia — co musi zachodzić, zanim wolno scalić: dowody obejmują każdą zmianę; wymagane checki wszystkie na zielono; wszystkie boty recenzenckie skończyły, a ich uwagi naprawione albo odpisane na piśmie; żaden ludzki recenzent nie zgłasza już zastrzeżeń; gałąź zaktualizowana względem domyślnej i GitHub melduje, że scalenie jest możliwe.
I najważniejsza sekcja: „Zapytaj Theo”. Cały sens tego przepływu polega na tym, że kończąc z wątkiem, nie muszę do niego wracać i ufam, że zmiana wejdzie bez ostatniego spojrzenia. Model musi więc wiedzieć, jak mnie dopaść, kiedy wątek ignoruję. Wyjaśniam wprost: pytanie w zwykłej wiadomości ginie — wątek wygląda na zakończony. Chcesz o coś zapytać, użyj narzędzia blokującego, żeby wątek pokazał, że czeka: Ask User Question w Claude Code, Request User Input (async albo zwykły) w Codexie, dostępne odpowiedniki w Antigravity. Do pytania włóż cały kontekst: link do PR-a, co blokuje, i opcje, które rekomendujesz — z najlepszą na początku. Pytaj tylko wtedy, gdy sam nie możesz iść dalej; dodałem to po fakcie, bo model zarzucał mnie pytaniami. I ostatnie: jeśli nie masz dostępu do czegoś, czego potrzebujesz — wybierz bezpieczniejszą ścieżkę.
A wiecie, jak miło mieć ten cały ruch w jednej bazie w sieci, po której moi agenci mogą sobie odpytywać? To po prostu fajne. W oknie, które właśnie przeglądam: 32 razy padło „full send” i 27 z nich scaliło się bez mojego ponownego spojrzenia. Rozumiecie, jakie to jest dobre uczucie?
Siatki bezpieczeństwa zamiast nerwów
Wiem, że nieuważanie wydaje się szaleństwem, ale — jak mówiłem w innych filmach — budujcie dobre systemy weryfikacji, żeby agent sam sprawdził, czy działa, oraz dobre siatki bezpieczeństwa, żeby gdy jednak padnie, złapać to, zanim dotknie większej części użytkowników. W T3 Code wydajemy build nocny co sześć godzin i natychmiast dostajemy sygnał, gdy coś popsuliśmy — zdążę naprawić przed kolejnym wydaniem stabilnym.
Wiem, że taki styl pracy może wydawać się obłąkany, ale oto jedna z głównych osób odpowiedzialnych za aplikację Claude Code Desktop publicznie rozważa, by domyślnie grupować wątki po statusie właśnie pod takie przepływy. Coraz więcej programistów pracujących z AI przestaje zadawać pytanie „jak wygenerować kod, który ja potem obejrzę”, a zaczyna: „jak zbudować przepływ, w którym agent sam się zweryfikuje i śmiało wyda — a gdy coś się zepsuje, da się to szybko cofnąć”. Bo na końcu dnia, choćbyście byli wy, wasi agenci, wasze systemy weryfikacji i wasi deweloperzy najlepsi pod słońcem — błędy się zdarzą. Musicie umieć je odwracać z możliwie małą szkodą.
Mówiąc konkretnie: z tych 32 przypadków z ostatnich dni 27 scaliło się samo — wiem, w których wątkach użyłem skilla — i ani jeden nie narobił problemów. Po wystarczająco wielu godzinach agentowego kodowania znacie już możliwości modeli: co potrafią, co umieją zweryfikować, co wymaga dodatkowego oka, a co nie. Mając tę intuicję, nietrudno ocenić: „to się pewnie samo scali, a to jeszcze obejrzę”.
Ale ten przepływ kocham zbyt mocno, żeby z niego rezygnować przy zmianach, które robią się kosmate. I tu wkracza mój ostatni skill — Full Stop.
Full Stop — cała automatyzacja oprócz ostatniego przycisku
Jeśli uważaliście, pewnie już wiecie, czym różni się od Full Send. Powiem szczerze: ten plik to praktycznie w całości wytwór modelu — powinien nazywać się „full slop”. Powstał, bo Full Send tak mi podszedł, że przy bardziej przerażających zmianach zaczęło mi go brakować. Nie chciałem, żeby scalały się same — chciałem, żeby zrobiły wszystko pozostałe, tak żeby gdy w końcu mnie zaczepią, było gotowe do decyzji. Full Stop to więc przebudowany przez Claude Full Send z jedną wielką różnicą: prowadź pracę, dopóki PR nie będzie gotowy do scalenia przeze mnie. Poprawiaj, weryfikuj, przeglądaj. Nigdy nie scalaj.
Czyli: model działa, ja nie patrzę, ale nie ma mi przeszkadzać, dopóki nie nabierze bardzo wysokiego przekonania, że rzecz jest gotowa. Zrób wszystko, żeby zweryfikować zmiany; pogadaj z innymi agentami i modelami o weryfikację; wystaw PR, dopilnuj go, ogarnij porażki CI, ogarnij komentarze botów recenzenckich, ogarnij uwagi ludzi z mojego zespołu — i nie zaczepiaj mnie, dopóki nie natrafisz na twardą blokadę albo nie uznasz, że to gotowe do scalenia.
Kocham ten skill. Błyskawicznie stał się moim najczęściej używanym — do tego stopnia, że dziś, gdy startowałem streama, ludzie podrzucali mi PR-y do obejrzenia i praktycznie każdy otwierałem słowami: „Rozkminij. Full stop”. Miałem i taki przypadek: ktoś zgłosił buga w prywatnych wiadomościach na X i dosłał dwa PR-y, które go naprawiają. Nie miałem głowy do rozgrzebywania tego wszystkiego, więc skopiowałem jego wiadomość i napisałem: „Przesłał to znajomy. Przeanalizuj i przejmij. Full stop”.
Takeover i Modernize — dyplomacja wobec cudzych PR-ów
Mam też skill Takeover. Prosty — nie ma co kombinować. To bardzo umiejętność z serii „opiekun repo musi ogarnąć”. Treść: przejmij istniejącą pracę; użyj, gdy użytkownik prosi o przejęcie PR-a, gałęzi, wątku agenta albo zgłoszenia. Weź odpowiedzialność za dokończenie pierwotnego celu, zachowując zasługi pierwotnego kontrybutora.
Zrobiłem go, bo widywałem PR-y naprawiające rzeczy, na których mi zależało, którym nie do końca ufałem — i nie chciałem po prostu dociskać commitów na czyjąś gałąź. Dzięki temu skillowi wklejam link do PR-a w T3 Code i mówię: „przejmij. Full stop”. A on: ogląda PR, recenzuje go, czyta opis, rozumie motywację; ocenia, czy kod nadaje się do kontynuacji, czy lepiej uznać go za punkt odniesienia i zacząć od zera; robi nowy PR ze wszystkimi zmianami, jeśli to ma sens, albo rozwija istniejący, jeśli tak jest lepiej — i za każdym razem zostawia zasługi pierwotnym autorom. To dla mnie ważne: nie chcę, żeby ludzie czuli, że zamykam ich PR-y i kradnę pomysły. Chcę, żeby autorzy dostawali swój kredyt. Doprowadzenie cudzego PR-a do ideału to po prostu za dużo pracy — wolę, żeby ktoś z mojego zespołu, o którym wiem, że doprowadzi temat do końca i w końcu naciśnie przycisk, przejął go na własność. Ten skill pozwala mi to mieć bez ukradzenia zasług kontrybutorom.
Jest jeszcze skill, który nazywam Modernize — bardzo prosty: zajmij się nieaktualnym PR-em. Zrebasuj na main, sprawdź, czy w międzyczasie nie weszło już coś rozwiązującego te same sprawy — żebyśmy wiedzieli, czy to jeszcze potrzebne — i zamknij, jeśli nie.
Graf skillów, czyli jak to wszystko narosło
Może zauważyliście, że z tego wyłania się dziwny graf powiązanych umiejętności. Zaczynałem od Modernize: przepływ, który robiłem w kółko, mówiąc do modeli zawsze to samo — „upewnij się, że PR jest aktualny, zamknij, jeśli nie ma już sensu, bo weszło coś podobnego”. Zamieniłem to w plik. Wciąż kazałem wątkom przejmować cudze PR-y i gałęzie i zobaczyłem, że samo w sobie powinno to być skillem — bo te same problemy wracały. Potem chciałem częściej korzystać z Sola jako subagenta do recenzji, co robiłem ręcznie, więc powstał Sol Loop. Zobaczyłem, że jakość kodu wychodzi lepsza, niż oczekiwałem — więc dodałem Full Send, żeby doprowadzał sprawę do końca. A potem ten przepływ zaczął mi brakować przy ryzykownych zmianach, więc powstał Full Stop: największa porcja tej samej wygody bez angażowania mnie.
Zanim zapomnę — poprawię opis: „użyj, gdy Theo wprost prosi o full stop”. I właśnie tak aktualizuję skille na całej flocie. Chyba gdzieś w repo siedzi skrypt, który to ogarnia. Nie wiem. Nie interesuje mnie to. Wolę po prostu powiedzieć, czego chcę — modele są dość sprytne, żeby to wykonać.
Dlaczego nie wywołuję skilli ręcznie
Jeszcze jedno, bo widziałem takie komentarze: „czy nie lepiej wywoływać to bezpośrednio?” albo „dlaczego nie wyłączysz automatycznego dobierania skilli?”. Dla nieznających: w standardzie skilli jest opcja „disable model invocation” — model nie może wtedy wciągnąć pliku sam, musicie wywołać go ręcznie, na przykład komendą /sol-loop albo /full-send. Świetne, gdy sami klepiecie i chcecie mieć pewność, że plik wejdzie tylko wtedy, gdy świadomie go wywołacie. Ja nie chcę pamiętać o slash-komendach. Warto też wiedzieć, że część narzędzi — głównie Claude Code — nie pozwala ręcznie odpalić kilku skilli naraz. Wyłączycie modelowi możliwość samodzielnego wywoływania i w niektórych przypadkach nie uruchomicie dwóch naraz. To niesamowicie wkurzające. Szczerze: nie pamiętam, kiedy ostatnio wywołałem skilla slashem — poza grillingiem Matta Pococka, który dostarczany jest właśnie w wersji ręcznej.
Ja nie klikam skillów ręcznie. Piszę opisy-wyzwalacze i mogę powiedić „sol loop takeover, full stop” albo wcisnąć przycisk dyktowania i powiedzieć: „Full stop. Takeover. Sol loop.” — i model to rozpozna. Nie potrzebuję specjalnej składni.
Kiedy w ogóle wywołuje się kilka naraz? No właśnie — te pięć razy, które przed chwilą pokazałem. Oto szósty, zrobiony dziś tuż przed streamem: ktoś podlinkował zgłoszenie naprawione przez PR otwierającym eksplorator Windows. Wziąłem ten PR, wkleiłem link i powiedziałem: „przejmij i doprowadź do lądowania. Full send”. Dwa skille naraz: poprawka się scaliła, a stary PR został zamknięty, bo nie był już potrzebny. I dam głowę, że jeśli otworzymy ten zmergowany — którego, nawiasem mówiąc, nigdy nie widziałem — okaże się, że zasługi poszły do pierwotnego autora. Ta kombinacja pozwoliła mi wziąć PR, którego nie oglądałem, zrobić na jego bazie nowy, przypisać autorstwo pierwotnemu użytkownikowi, zweryfikować, że poprawka działa (sądząc po wszystkim, testował na maszynie z PowerShellem), i scalić. Wszystko bez zaglądania. A skoro mój skill każe upewnić się, że działa i jest bezpiecznie, a w razie wątpliwości dzwonić do Theo — jestem spokojny, że gdybym nigdy więcej nie otworzył tego wątku, nic złego by się nie stało.
Jeszcze jedna rzecz warta zapamiętania — dzięki, Alex. Gdy w Claude Code wywołujecie skilla ręcznie, wasz prompt trafia do niego jako argument (skille w Claude Code bywają programistyczne — można im przekazywać dane). Efekt: cała treść promptu ląduje w kontekście dwa razy. Nieidealnie. Ręczne wywoływanie po prostu się nie opłaca.
T-Stack, kurs MegaDev i puenta
Wiem, ilu z was chciałoby, żebym wrzucił to wszystko do jednego repo. Chyłam się ku temu. Dobra — koniec zwlekania, czas na to: nowy projekt, i wygrywa nazwa T-Stack. Nie skończę go szybko, ale wypatrujcie w przyszłości materiału o T-Stacku.
No i wreszcie ulegam: robię mój pierwszy kurs. Jeśli nie pracujecie na pełen etat jako programiści i nie zarabiacie prawdziwych pieniędzy, raczej nie kupujcie. Ale jeśli macie budżet szkoleniowy albo przekonacie szefa, żeby pokrył koszt — MegaDev będzie naprawdę, naprawdę dobry. Ostatnie miesiące spędziłem nad pierwszym rozdziałem. Otwieram ja, zamyka John Lindquist (twórca Egghead), a środek wypełniają Kenzie i Angie. To nie będzie kolejny kurs z serii „zbuduj aplikację od zera”. To o tym, jak naprawdę używamy AI, żeby wydawać w realnych firmach przy realnej pracy — i staraliśmy się nie przywiązywać tego do stanu na dziś, tylko do ogólnego sposobu myślenia o AI i nawigowania w tym nowym świecie. Bardzo jestem tym podekscytowany. Powiedzcie szefowi, żeby pokrył. Tylko proszę: nie kupujcie tego, żeby dostać pracę. Kupujcie, bo praca to opłaca, a chcecie podnieść kwalifikacje. Może zapiszcie cały zespół.
I to w sumie wszystko. Mam nadzieję, że przeszedł przekaz — a nie brzmi on „skopiujcie moje pliki Markdown, bo jestem mega mądry”. Chodzi o to, żebyście zobaczyli, jak dochodzę do rozwiązań własnych problemów i buduję coraz bardziej odstawiony ode mnie przepływ pracy, w którym uczestniczę na innym poziomie niż kiedyś. Tak w pewnym sensie zostaję menedżerem samego siebie. Żeby wycisnąć z agentów maksimum, przeanalizujcie swój przepływ: czemu ufacie, a czemu nie — i zacznijcie to kodować w skillach. Wtedy będziecie wydawać skuteczniej. Skoro tak — T-Stack nadchodzi. Subskrybujcie, jeśli jeszcze nie. I do następnego razu: trzymajcie się, nerdy!