O czym jest ten film
- Większość użytkowników traktuje aplikację Codex jak zwykłe okienko na prompt i przez to marnuje jej możliwości.
- System wtyczek: obowiązkowa jest wtyczka computer use, reszta wyłącznie taka, która realnie należy do twojego workflow.
- Wbudowana przeglądarka jako narzędzie do adnotacji na żywo w interfejsie budowanej aplikacji.
- Ta sama przeglądarka jako zautomatyzowany QA — agent sam klika po aplikacji i raportuje, co działa, a co można poprawić.
- Computer use w Codeksie jako najlepsze na rynku — z demonstracją na absurdalnym zadaniu i realnym zastosowaniem w pracy umysłowej (scraping, formularze, arkusze).
- „Thread maxing”, czyli równoległe wątki — ale tylko w dwóch konkretnych scenariuszach, nie dla samego efektu.
- Dobór modelu i poziomu wysiłku: GPT-5.6 Soul, głównie medium i extra high.
/goaldziała wyłącznie wtedy, gdy istnieje zdefiniowany cel i mierzalna pętla sprzężenia zwrotnego.- Umiejętność „greploop” jako wzorcowy przykład pętli sprzężenia zwrotnego dla pull requestów.
- T3 Code jako alternatywny klient wykorzystujący tę samą subskrypcję Codeksa.
Redakcyjne tłumaczenie
Wstęp: przestań używać Codeksa jak okienka na prompt
Aplikacja Codex od OpenAI to znakomity interfejs graficzny i znakomity harness (Informacja dodatkowa: harness to warstwa spinająca model językowy z narzędziami, plikami i środowiskiem użytkownika — to ona decyduje, co agent naprawdę potrafi zrobić). Można w niej zrobić mnóstwo ciekawych rzeczy, ale większość ludzi nie wykorzystuje jej potencjału. Jeżeli ty, osoba oglądająca ten materiał, używasz jej wyłącznie jako pola do wpisania promptu, to sporo tracisz.
Pokażę siedem rzeczy, które zrobią z ciebie zaawansowanego użytkownika Codeksa. Nieważne, czy jesteś programistą, czy używasz go w biznesie — szczególnie jednak przyda się to osobom, które faktycznie budują projekty.
Na marginesie: przeprowadziłem się do nowej przestrzeni. Tęskniłem. I jestem już blisko stu tysięcy subskrypcji, więc subskrypcja wiele by dla mnie znaczyła.
Jeszcze jedna uwaga wstępna: używam wszystkiego w jasnym motywie. Jeśli używasz czegokolwiek w ciemnym, oceniam cię — jesteś naśladowcą, nie liderem. Prawdziwi liderzy pracują w light mode.
1.Wtyczki: instaluj tylko to, czego naprawdę używasz
System wtyczek w Codeksie jest fantastyczny. Zacznijmy od tej absolutnie obowiązkowej: jeśli nie masz zainstalowanej wtyczki computer use, to co ty w ogóle robisz? Zainstaluj ją natychmiast.
Poza tym reguła jest prosta: instalujesz te wtyczki, które są częścią twojego workflow. Kiedy buduję aplikację, w grę wchodzą GitHub, Vercel, Convex i Linear. To są narzędzia, których naprawdę używam. Więc kiedy siadam do Codeksa, pierwsze pytanie brzmi: czy rzeczy z mojego workflow mają swoje wtyczki? Vercel — tak. Convex — tak. Linear — tak. GitHub — tak. To znaczy, że agent zyskuje dostęp do mojego uwierzytelnionego konta w każdym z tych narzędzi.
Błąd, w który łatwo wpaść, to instalowanie mnóstwa rzeczy, których nie potrzebujesz. Nie instaluj Salesforce’a, jeśli go nie używasz. Nie instaluj Dropboksa — pewnie z niego nie korzystasz. Ani ClickUpa. Sam mam zainstalowane wtyczki do prezentacji, z których korzystam sporadycznie. Nie bądź osobą, która kupuje nowego iPhone’a, instaluje wszystkie aplikacje świata i nigdy z nich nie korzysta. Pobieraj i używaj tylko tych wtyczek, które faktycznie należą do twojego procesu pracy.
2.Wbudowana przeglądarka: adnotacje i testy
Wbudowana przeglądarka jest naprawdę świetna. Nie wiem, czy pamiętacie, ale OpenAI miało kiedyś przeglądarkę o nazwie ChatGPT Atlas. Miała być konkurentem przeglądarki Perplexity i Dii, miała być tą jedyną przeglądarką AI. Wojny przeglądarkowe były wtedy na szczycie, OpenAI wkroczyło do gry — po czym się wycofało i zamknęło aplikację. Ale przeglądarkę znajdujemy teraz w Codeksie. (Informacja dodatkowa: Atlas to przeglądarka z wbudowanym asystentem, którą OpenAI wypuściło, a następnie wycofało; jej funkcje trafiły do Codeksa.)
To pełnoprawna, samodzielna przeglądarka. Mogę wejść na youtube.com/rasmic i upewnić się, że wciskam przycisk subskrypcji. Widzę nawet, że jestem zalogowany — sesja jest zachowywana, więc mogę zalogować się na konto Google i tam zostanie.
Ale to znacznie więcej niż to. Mam uruchomioną aplikację — prostą listę zadań zbudowaną w SvelteKit i Convex. I jest tam świetne narzędzie do adnotacji. Czasem chcesz zmienić jakiś tekst, powiększyć czcionkę albo poprawić konkretny fragment interfejsu. Opisanie tego w promptcie bywa nieproporcjonalnie trudne — samo doprecyzowanie, o który element chodzi, to praca. Owszem, możesz użyć czegoś w rodzaju Wispr Flow i podyktować to głosem. Ale w Codeksie wystarczy kliknąć „annotate”. Klikam w konkretne miejsce i dyktuję: „Zmień tytuł na »koniecznie zasubskrybuj Rasa Mica, bo jest przystojny«”. Wciskam enter.
I tu jest rzecz, którą lubię najbardziej: adnotacja nie jest wysyłana od razu. Mogę je układać w stos. Uznaję, że ten przycisk jest odrobinę za duży — „Możemy go trochę odchudzić?”. Enter. Można nazbierać ich dowolnie wiele, a dopiero potem wysłać wszystkie naraz.
Na innym wątku — o wątkach będzie za chwilę — mam uruchomioną aplikację o nazwie Pluto. Załóżmy, że chcę, by agent ją przetestował. Piszę: „Użyj przeglądarki, którą masz. Mam uruchomioną aplikację w przeglądarce. Przetestuj tworzenie agenta i powiedz mi, czy działa albo co dałoby się poprawić na podstawie twojego doświadczenia z używania”. Prompt marny, na chwilę zapomniałem angielskiego, ale wciskam enter.
Chcę, żebyśmy zobaczyli, jak agent korzysta z przeglądarki. I proszę: kursor pojawia się we własnej przeglądarce agenta. Agent testuje aplikację i wraca z informacją, czy działa. To już element mojego workflow: każę Codeksowi uruchomić moją aplikację lokalnie i ją przeklikać. Nie chcę wyłącznie code review — chcę recenzji z perspektywy użytkownika. To w praktyce zautomatyzowany proces QA.
Widać, że agent utworzył agenta w aplikacji. Podoba mi się nazwa: „Codex creation test, 12 sierpnia”. Wracam na drugi wątek — zmiany z adnotacji są już wprowadzone. Wracam do pierwszego — agent nadal testuje. Ostatecznie skończył: aplikacja działa, a przy okazji dostałem listę wartościowych usprawnień. Mógłbym dosłownie kazać mu je od razu wdrożyć, ale nie po to tu dziś jesteśmy.
Podsumowując te dwa punkty: wtyczki — zainstaluj computer use, reszta zależy od twojego workflow. Przeglądarka — świetna do adnotacji (adnotuj aplikację do skutku, aż wygląd i działanie będą dokładnie takie, jak chcesz, zwłaszcza po stronie UI/UX) oraz do zlecania agentowi testów aplikacji.
3.Computer use: najlepszy na rynku
Agent Codeksa jest zdecydowanie jednym z najlepszych w obsłudze komputera.
Najlepiej pokażę to na najgłupszym możliwym zadaniu — właśnie po to, żeby stało się jasne, jak dobre jest to narzędzie. Piszę: „Utwórz folder na moim pulpicie, nazwij go »knock knock jokes«. W środku utwórz trzy foldery: folder jeden, folder dwa i folder trzy. W jednym z nich, wybranym losowo przez ciebie, umieść plik markdown z dowcipem typu »puk, puk«. Tylko proszę, nie wybieraj słabego — niech będzie przezabawny”. (Informacja dodatkowa: „knock-knock joke” to amerykański schemat dowcipu opartego na dialogu przy drzwiach; polskim odpowiednikiem byłby żart z ustalonym schematem pytań i odpowiedzi.)
Widać widok agenta obok mojego. W tej chwili korzysta z Findera. Świetne w agencie computer use w Codeksie jest to, że nie blokuje mnie — mogę dalej normalnie pracować na własnym komputerze, podczas gdy on używa tego samego laptopa. Nie dzielimy kursora; on ma swój własny, więc nie wchodzimy sobie w drogę.
Widzę, że otworzył edytor tekstu, wpisał dowcip i go zapisuje. Jest przy tym naprawdę szybki — to jeden z najszybszych agentów tego typu.
Gotowe: utworzył folder „knock-knock jokes” na pulpicie, z folderami jeden, dwa i trzy. Otwieram — folder pierwszy pusty, drugi… o, tutaj jest. Dowcip: „Puk, puk. Kto tam? Maniak kontroli. Maniak kontroli kto? No dobra, teraz ty powiedz »maniak kontroli kto?«”. No cóż. Są rzeczy, w których nie można ufać AI, i pisanie dowcipów wyraźnie do nich należy.
Sama funkcja jest jednak potężna, i to niekoniecznie w zastosowaniach programistycznych. Szczerze mówiąc, computer use w Codeksie wykorzystuję głównie do zadań w rodzaju wypełniania formularzy. Mam kolegę, Zavery’ego — pozdrowienia, jeśli to oglądasz, brat z kościoła. Pracuje w sprzedaży i chciał wyciągnąć dane kontaktowe z ogromnej bazy stron: wejść na każdą i zebrać konkretne informacje. Powiedziałem mu wprost, żeby użył Codeksa. Agent przeszedł przez wszystkie strony, utworzył arkusz kalkulacyjny, zapisywał w nim informacje, aktualizował go na bieżąco, a kiedy skończył, wysłał mu maila — bo miał zainstalowaną wtyczkę do Gmaila.
To zatem raczej domena pracy umysłowej. Jeśli budujesz aplikację webową i chcesz ją przetestować, użyłbym po prostu przeglądarki. Ale jeśli budujesz aplikację desktopową — computer use pozwala ją przetestować. W tej kategorii nie ma harnessu, który choćby się zbliżał.
4.Thread maxing: kiedy równoległe wątki naprawdę mają sens
Wielu z was prosiło, żebym powiedział o „thread maxingu”. Chcę jednak coś postawić jasno: w naszej branży jest teraz mnóstwo rzeczy, które brzmią efektownie, ale nie są produktywne. Nie chcę, żebyś dawał się na nie nabrać — chcę, żebyś robił rzeczy, które faktycznie działają. Przy równoległych wątkach obowiązuje określony sposób myślenia, który sprawia, że to się opłaca.
Przykład. Chcę zbudować agenta, ale nie wiem, który framework wybrać. Jest framework agentowy od Vercela, jest Cloudflare Agent SDK, są SDK od Anthropiku i OpenAI, chyba Effect też ma swoje. Nie wiem, który jest najlepszy. Więc piszę: „Przejrzyj dokumentację. Zbuduj prostego agenta w każdym z tych frameworków, ale zrób to w osobnych wątkach — każdy framework dostaje własny wątek. Do tego przedstaw badania i fakty uzasadniające, dlaczego dany framework jest najlepszy. Na koniec powiedz, który powinniśmy wybrać. Dodatkowy kontekst: agent jest dla firmy budowlanej, która chce go wykorzystać w swoich operacjach”. (Informacja dodatkowa: firmy budowlane pojawiają się w przykładzie, bo — jak mówi autor — ostatnio wiele z nich zgłasza się do jego firmy doradczej po wdrożenia agentów.)
Ruszyło. Widać, jak system rozkręca wątki: jeden dla Effect, jeden dla agenta OpenAI, jeden dla Anthropiku, jeden dla Cloudflare i jeden dla Vercela. Jeśli mam do zrobienia tego rodzaju research, uruchamiam wątki.
Kiedy konkretnie stosuję thread maxing? Po pierwsze — przy researchu nad konkurencyjnymi rozwiązaniami: frameworkami, infrastrukturą, czymkolwiek. Po drugie — kiedy są dwa sposoby zbudowania czegoś, czyli dwie decyzje architektoniczne albo projektowe do podjęcia. Wtedy dosłownie mówię agentowi: „Uruchom dwa osobne wątki, każdy niech zbuduje swoją wersję we własnym worktree, a potem przygotuj mi działającą wersję w przeglądarce do obejrzenia”. (Informacja dodatkowa: worktree to mechanizm Gita pozwalający mieć kilka niezależnych katalogów roboczych tego samego repozytorium — dzięki temu równoległe wątki nie nadpisują sobie plików.) Kiedy stoję na rozwidleniu i nie wiem, którą drogę wybrać, każę wątkowi, na którym jestem, rozkręcić dwa wątki, zbudować obie wersje, a potem sam je oceniam i zostajemy przy jednej.
Na marginesie, nieco poza główną narracją: Codex jest naprawdę świetny w konfigurowaniu samego komputera. Czegoś nie masz zainstalowanego? Chcesz sprawdzić, ile pamięci się marnuje? Stawiasz home lab i musisz coś skonfigurować? Codex jest w tym fantastyczny. U mnie działa tu Ghostty, a to jest mój linuksowy komputer, na którym używam Codex CLI do skonfigurowania całej warstwy sieciowej i zbudowania dashboardów do monitoringu. Mówimy dziś o interfejsie graficznym, ale CLI też jest naprawdę bardzo dobre. A szczególnie w kwestii pracy na maszynie, na której jest zainstalowany, nie mogę tego GUI polecić wystarczająco mocno.
5.Dobór modelu i poziomu wysiłku
Zanim wątki się dogotują — porozmawiajmy o wyborze modelu.
Szczerze: używam Soula do wszystkiego, bo dopłaty do subskrypcji są korzystne. Jestem na planie za 200 dolarów miesięcznie. Jeśli ty nie jesteś i nie możesz sobie pozwolić na ciągłe używanie Soula — Terra jest dobra, Luna jest dobra. Trzeba po prostu myśleć o typie zadania. Ja zwykle buduję aplikację, diagnozuję coś w sieci albo robię coś, co wymaga więcej myślenia, więc siedzę w Soulu.
A teraz wysiłek. Używam medium i extra high. Zdarzało mi się użyć ultra. Kilka tygodni temu był z ultra pewien problem — spalał tokeny i ludzie narzekali. Użyłem go parę razy i było w porządku, całkiem nieźle. To nie są przepływy pracy rodem z Claude’a, ale jest naprawdę dobrze. Uczciwie mówiąc, można wieść całkiem szczęśliwe życie, żyjąc pomiędzy medium a extra high. Ja nieustannie przełączam się między tymi dwoma i to jest dla mnie złoty środek. Zadanie prostsze — medium. Wymaga trochę główkowania — extra high. GPT-5.6, Soul, medium i extra high.
Prędkość mam ustawioną na „fast”, bo muszę was zabawiać. Ale żeby oszczędzić tokeny, można spokojnie zostać przy „standard”.
Wątek wreszcie skończył. Po tym jednym promptcie i pracy wszystkich rozkręconych wątków dostałem finalną odpowiedź: rekomendacją jest Cloudflare Agents SDK dla agenta operacyjnego firmy budowlanej — durable objects plus reszta stosu. Dalej jest cały ranking i plik do przejrzenia. To po prostu świetne rozwiązanie na sytuację, w której stoisz na rozwidleniu i musisz podjąć decyzję wymagającą przebadania wielu opcji. Mówisz wątkowi, żeby rozkręcił kilka wątków, i wracasz po wynik. Prosta sprawa.
6./goal — działa tylko z pętlą sprzężenia zwrotnego
Na początku nie lubiłem /goal, bo ludzie próbowali za jego pomocą budować całe projekty. A nie po to się go używa.
/goal stosuje się wtedy, gdy masz zdefiniowany cel, do którego prowadzi wiele kroków. Ostatni przykład z mojej praktyki: miałem stronę klienta, która była wolna, a chcieliśmy, żeby była błyskawiczna — klikasz i już jest. Zrobiłem więc /goal, pamiętając, że Codex ma przeglądarkę. Napisałem: użyj przeglądarki — mogę ją oznaczyć w promptcie — i uruchom test Lighthouse. (Informacja dodatkowa: Lighthouse to narzędzie Google’a mierzące m.in. wydajność, dostępność i dobre praktyki strony w skali 0–100.) Wynik Lighthouse pokazuje, jak dostępna i jak szybka jest strona, a agent bez trudu potrafi go zmierzyć. Powiedziałem: „Spraw, żeby ta strona była błyskawicznie szybka, i wyciągnij same setki”. Wcisnąłem enter i /goal pracowało jakieś trzy godziny. Rezultat: strona z kompletem stu punktów w Lighthouse i naprawdę błyskawiczna.
Ale /goal zadziałało wyłącznie dlatego, że dałem mu finalny cel — czyli jasno wskazałem, jak wygląda meta — oraz pętlę sprzężenia zwrotnego. Tą pętlą był wynik Lighthouse: musiało być 100, 100, 100. Istniał sposób, by agent sam sprawdzał swoją pracę. Był mechanizm zwrotny i był zdefiniowany cel — dlatego mój przebieg nie był śmieciowy.
Większość ludzi — i pewnie ty też tego doświadczyłeś — dostaje z /goal bezwartościowy wynik. A powodem jest właśnie brak pętli sprzężenia zwrotnego. Żeby przebieg /goal był skuteczny, potrzebujesz pętli zwrotnej i zdefiniowanego celu. Połącz jedno z drugim, a pokochasz to narzędzie.
Nie użyłbym /goal do budowania aplikacji — chyba że chodzi o jakieś wewnętrzne narzędzie. Użyłem go natomiast do przeniesienia zmiennych środowiskowych do 1Password, bo mam je skonfigurowane na wszystkich maszynach i dzięki temu nie muszę kopiować zmiennych ręcznie. Zacząłem od /goal, a potem trochę dopieściłem wynik. Do rzeczy wewnętrznych — jak najbardziej. Do budowania aplikacji — nie. Ale do ulepszania tych fragmentów aplikacji, do których da się podpiąć pętlę zwrotną — tak. Wtedy to nie jest generowanie sieczki.
/goal to jedno z moich ulubionych narzędzi. Używam go wyłącznie wtedy, gdy mam pętlę sprzężenia zwrotnego.
Greploop: wzorcowa pętla zwrotna dla pull requestów
Wciąż wspominam o pewnej umiejętności — greploop, autorstwa Graphite. (Informacja dodatkowa: Graphite to narzędzie do automatycznego code review pull requestów.) Graphite bywa sponsorem moich filmów, ale ten materiał nie jest przez nich sponsorowany. Wspominam o tej umiejętności, bo działa w tej samej logice co /goal.
Greploop poprawia pull request tak długo, aż model wystawi ocenę pewności pięć na pięć przy zerze nierozwiązanych komentarzy. Uruchamia review w Graphite, naprawia wszystkie faktyczne uwagi, wypycha zmiany i ponownie odkłada je na stos, ponownie wywołuje review i tak w kółko. Używa się tego, kiedy chce się mieć pull request w pełni zoptymalizowany pod standardy code review Graphite.
To dokładnie ta sama konstrukcja co /goal: celem jest piątka na piątkę, zadaniem jest poprawianie wszystkiego, co zgłosi narzędzie, a warunkiem zatrzymania — osiągnięcie tej piątki. Działa, bo istnieje pętla sprzężenia zwrotnego. Dlatego lubię to rozwiązanie: greploop ułatwia mi optymalizowanie review i pilnowanie, żeby moje pull requesty zawierały jak najmniej sieczki. To taki blokada sieczki. I dokładnie tak chcę, żebyś myślał o /goal — pętla zwrotna jest kluczowa. Napiszcie w komentarzach: „pętla zwrotna”.
Ostatnia fajna rzecz przy /goal: kiedy pracuje, możesz robić inne rzeczy — na przykład czytać Biblię, bo pewnie nie czytałeś. Wyciągnijmy losowy werset. Idealnie: Księga Przysłów 27,1: „Nie chwal się dniem jutrzejszym, bo nie wiesz, co dzień ci przyniesie. Niech kto inny cię chwali, a nie twoje usta, ktoś obcy, a nie twoje wargi”. Czasem mamy skłonność do przechwałek — a Biblia mówi, że pokorni będą wywyższeni.
7.T3 Code
Omówiliśmy wtyczki, przeglądarkę, computer use, thread maxing, wybór modelu i /goal. Siódma rzecz to T3 Code.
Wspominam o nim, bo pozwala korzystać z twojej subskrypcji Codeksa we własnym kliencie. Ma kilka ciekawych właściwości. Zwłaszcza jeśli pracujesz na różnych maszynach, możliwość swobodnego przechodzenia między nimi jest znakomita. Ale najważniejsza i najbardziej imponująca część to jego skrzynka odbiorcza — po prostu lepsze rozwiązanie niż to natywne, szczególnie gdy pracujesz nad wieloma projektami i wieloma wątkami naraz.
Jeśli chcecie osobny film o T3 Code, dajcie znać w komentarzach.
Zakończenie
To wszystko. Mam nadzieję, że film się podobał i że wiecie już, jak korzystam z Codeksa. Wyciśnijcie z niego, ile się da — zwłaszcza dopóki trwają dopłaty do subskrypcji. Zostawcie łapkę, komentarz i subskrypcję, bo jesteśmy blisko stu tysięcy, a z tej okazji przygotuję coś specjalnego. Do zobaczenia w następnym.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Wtyczki dobieraj według realnego workflow, nie z ciekawości
Na czym polega: Wtyczki dają agentowi dostęp do twoich uwierzytelnionych kont w zewnętrznych usługach. Autor instaluje wyłącznie te, których faktycznie używa w pracy: GitHub, Vercel, Convex, Linear. Jedyny obowiązkowy wyjątek to computer use.
Jak stosować: Wypisz narzędzia, w których codziennie coś robisz przy projekcie, i sprawdź, które z nich mają wtyczkę. Instaluj tylko te — reszta to szum.
Na co uważać: Każda zainstalowana wtyczka to realny dostęp do uwierzytelnionego konta. Instalowanie „na zapas” nie tylko zaśmieca listę narzędzi agenta, ale też poszerza powierzchnię tego, co agent może dotknąć bez twojej wiedzy.
2.Adnotacje w przeglądarce zamiast opisywania interfejsu słowami
Na czym polega: Wbudowana przeglądarka pozwala kliknąć konkretny element działającej aplikacji i podyktować przy nim polecenie zmiany. Adnotacje się nie wysyłają natychmiast — można ich uzbierać wiele i wysłać jednym pakietem.
Jak stosować: Do wszystkich poprawek UI/UX, w których wskazanie elementu palcem jest łatwiejsze niż jego opisanie. Zbierz całą serię uwag z jednego przejścia po ekranie i wyślij razem.
Na co uważać: To narzędzie do dopieszczania warstwy wizualnej i drobnych zmian, a nie do zmian architektonicznych. Duży stos adnotacji trafia do agenta naraz — jeśli uwagi są ze sobą sprzeczne, dostaniesz przypadkowy kompromis.
3.Agent jako testujący użytkownik, nie tylko recenzent kodu
Na czym polega: Autor każe agentowi uruchomić aplikację lokalnie, przeklikać ją we wbudowanej przeglądarce i zaraportować, co działa i co dałoby się poprawić. To zautomatyzowany etap QA obok zwykłego code review.
Jak stosować: Po każdej większej zmianie zleć agentowi przejście konkretnej ścieżki użytkownika (np. „przetestuj tworzenie agenta”) i poproś o listę usprawnień z perspektywy użytkownika.
Na co uważać: Wskaż konkretny przepływ do przetestowania — sam autor przyznaje, że jego prompt był marny. Ogólne „przetestuj aplikację” da ogólne odpowiedzi. I traktuj wynik jako uzupełnienie testów automatycznych, nie ich zastępstwo.
4.Computer use najlepiej sprawdza się w pracy umysłowej, nie w kodowaniu
Na czym polega: Agent Codeksa obsługuje komputer własnym kursorem, nie blokując użytkownika. Autor używa go głównie do wypełniania formularzy i zadań operacyjnych — przykład znajomego z działu sprzedaży: obejście setek stron, zebranie informacji, prowadzenie arkusza i mail na koniec.
Jak stosować: Zrzucaj mu powtarzalne zadania przeglądarkowo-biurowe, które musisz zrobić na własnej maszynie i na własnych zalogowanych kontach. Do aplikacji webowych używaj zwykłej przeglądarki, do desktopowych — computer use.
Na co uważać: Agent działa na twoim komputerze i twoich sesjach — ma dostęp do wszystkiego, do czego ty. Zadania obejmujące masowe zbieranie danych ze stron sprawdź pod kątem regulaminów tych serwisów i przepisów o danych osobowych.
5.Równoległe wątki tylko przy researchu i rozwidleniach decyzyjnych
Na czym polega: Autor stosuje thread maxing w dwóch sytuacjach: porównanie konkurencyjnych rozwiązań (frameworki, infrastruktura) oraz wybór między dwiema decyzjami architektonicznymi. W obu przypadkach każdy wątek buduje działającą wersję i wraca z uzasadnieniem.
Jak stosować: Poleć głównemu wątkowi rozkręcenie osobnych wątków — po jednym na opcję — z wymogiem zbudowania prototypu, przedstawienia argumentów i wskazania rekomendacji. Przy zmianach w kodzie dodaj wymóg pracy w osobnych worktree.
Na co uważać: Autor sam ostrzega, że wiele modnych technik brzmi dobrze, ale nie jest produktywnych. Wątki bez ostrego pytania rozstrzygającego to spalanie tokenów. Bez osobnych worktree równoległe wątki będą sobie nadpisywać pliki.
6.Podaj agentowi kontekst biznesowy, nie tylko techniczny
Na czym polega: W promptcie porównującym frameworki autor dopisał, że agent powstaje dla firmy budowlanej i jej operacji. Rekomendacja końcowa była wypracowana pod ten kontekst.
Jak stosować: Przy każdym pytaniu „które rozwiązanie wybrać” dopisz, dla kogo i do czego to jest. To zmienia kryteria oceny z abstrakcyjnych na dopasowane.
Na co uważać: Rekomendacja jest tak dobra jak kontekst — jeśli opiszesz projekt nieprecyzyjnie, dostaniesz pewnie brzmiącą odpowiedź na niewłaściwe pytanie. Wynik zawsze warto zweryfikować samodzielnie.
7.Medium i extra high jako codzienny zakres wysiłku
Na czym polega: Autor pracuje na GPT-5.6 Soul i przełącza się wyłącznie między medium (zadania prostsze) a extra high (wymagające myślenia). Ultra wypróbował, ale odnotowuje wcześniejsze problemy ze spalaniem tokenów. Ustawienie prędkości „fast” ma u niego uzasadnienie nagraniowe — do oszczędzania tokenów poleca „standard”.
Jak stosować: Ustal sobie ten sam dwustopniowy przełącznik i podnoś wysiłek dopiero wtedy, gdy zadanie faktycznie tego wymaga. Domyślnie zostaw prędkość na standardowej.
Na co uważać: Autor korzysta z planu za 200 dolarów miesięcznie i sam mówi, że jego dobór modelu wynika z dopłat do subskrypcji. Przy tańszym planie ta konfiguracja nie przeniesie się jeden do jednego — trzeba realnie ważyć koszt na zadanie.
8./goal bez pętli sprzężenia zwrotnego zawsze da sieczkę
Na czym polega: Kluczowa teza filmu. /goal działa tylko wtedy, gdy istnieją dwie rzeczy: jasno zdefiniowana meta oraz mechanizm, którym agent sam sprawdza, czy już do niej dotarł. U autora tą pętlą był wynik Lighthouse, który musiał osiągnąć 100/100/100 — trzygodzinny przebieg zakończył się sukcesem.
Jak stosować: Przed uruchomieniem /goal odpowiedz sobie na pytanie: jaką liczbą albo jakim testem agent zmierzy, że skończył? Jeśli nie umiesz odpowiedzieć, nie uruchamiaj — najpierw zbuduj miernik.
Na co uważać: Metryka staje się jedynym celem, więc agent będzie ją optymalizował dosłownie. Wynik Lighthouse na sto punktów nie gwarantuje, że strona nadal robi to, co ma robić — efekt trzeba przejrzeć samodzielnie.
9./goal do ulepszania, nie do budowania
Na czym polega: Autor nie używa /goal do budowania aplikacji — z wyjątkiem drobnych narzędzi wewnętrznych, jak przeniesienie zmiennych środowiskowych do 1Password. Stosuje je do poprawiania tych fragmentów istniejących systemów, do których da się podpiąć miernik.
Jak stosować: Kieruj /goal na wydajność, dostępność, pokrycie testami, czas budowania — wszystko, co ma liczbę. Nowe funkcje buduj normalnym, kontrolowanym trybem pracy.
Na co uważać: Nawet przy narzędziach wewnętrznych autor dopracowywał wynik ręcznie po zakończeniu przebiegu. Traktuj wyjście /goal jako punkt startowy do przeglądu, nie jako gotowy produkt.
10.Greploop jako wzorzec do skopiowania we własnym procesie
Na czym polega: Umiejętność od Graphite, która iteracyjnie poprawia pull request, aż automatyczne review wystawi ocenę pięć na pięć przy zerze nierozstrzygniętych komentarzy: uruchamia review, naprawia uwagi, wypycha zmiany, uruchamia review ponownie.
Jak stosować: Nawet jeśli nie używasz Graphite, przenieś schemat: zewnętrzny weryfikator z twardym progiem plus pętla „popraw i sprawdź ponownie” aż do jego osiągnięcia. Może nim być linter, zestaw testów albo własne kryterium review.
Na co uważać: Automat optymalizuje pod standardy konkretnego narzędzia — piątka na piątkę u weryfikatora nie oznacza, że kod jest poprawny merytorycznie. Autor wprost mówi, że informuje o współpracy reklamowej z Graphite przy innych materiałach, więc rekomendację warto traktować z tym zastrzeżeniem.