O czym jest ten film
- Autor pokazuje kompletny warsztat „inżynierii agentowej” – efekt ponad 2000 godzin kodowania z AI i rozmów z czołówką tej dziedziny.
- Interfejsy pracy z agentami: open source’owe BB (wszystkie agenty i subskrypcje w jednym oknie), cmux, terminal Ghostty z Herderem oraz autorskie Coral z kolejkowaniem agentów według priorytetów.
- Strategia wydatków na modele: cztery subskrypcje (OpenCode, ChatGPT/Codex, Claude Code, Cursor) składa się według budżetu; płacenie za API to najgorszy z możliwych wariantów.
- Teza: agenty chmurowe są nieuchronne (w Cursorze odpowiadają już za blisko 60% zmieszanych PR-ów), ale gotowe platformy zamykają użytkownika w swoim ekosystemie.
- Alternatywa: własny, tani VPS z Herderem i SSH – trwałe sesje, dziesiątki agentów, pełna kontrola; całą konfigurację wykonuje agent na polecenia w zwykłym języku.
- Przegląd „harnessów”: minimalistyczne Pi, niedoceniany Cursor CLI, samouczące się Hermes i Prime Agent oraz klasyki (Claude Code, Codex) skrócone do aliasów terminalowych.
- Autorska biblioteka skilli: recenzje zmian (total review), decydowanie przed budowaniem (ask and build), research i scraping (Deep API), zabezpieczenia (guardrails, push lock).
- Zasada worktree: w małych projektach zbędne, przy kilkunastu i więcej agentach równolegle – niezbędne.
- Szybka seria praktyk: dobór modelu do zadania, dokładnie jedna recenzja zmian, presendy, kontrola podagentów, ADR-y, limitowanie testów, dostęp tylko do odczytu do produkcyjnej bazy.
- Zapowiedź: rzadsze filmy na YouTube, za to codzienne artykuły i projekty open source w Vectoral Labs, w tym repozytorium do mierzenia produktywności agentowej.
Redakcyjne tłumaczenie
Kim jestem i co pokażę
Nazywam się David Ondrej. W ciągu ostatnich trzech lat spędziłem ponad 2000 godzin na kodowaniu z AI i rozmawiałem z wieloma najbardziej wiarygodnymi, najproduktywniejszymi ludźmi w dziedzinie inżynierii agentowej. Poniżej pokazuję mój pełny, aktualny warsztat – bez owijania w bawełnę. Zaczynam od interfejsu, czyli od tego, jak w ogóle rozmawia się z agentami.
Interfejsy: BB, cmux, Ghostty z Herderem i Coral
Moim podstawowym narzędziem jest BB – projekt open source, całkowicie darmowy, który pozwala w jednym oknie korzystać z dowolnej subskrypcji, dowolnego agenta i dowolnego modelu. U mnie obok siebie pracują Codex, Claude Code, Pi, Cursor CLI, OpenCode, Grok i Hermes. Aplikacje w rodzaju Codexa czy Cursora mają tę wadę, że zamykają na własnych modelach i własnej subskrypcji – nie wyciśnie się z nich maksimum, a w 2026 roku to już konieczność.
W BB po boku mam listę projektów, które mogę swobodnie otwierać, zamykać i przestawiać. Są też agenci i podagenty: gdy kazałem agentowi wykonać skilla „total review”, sam uruchomił dwóch podagentów – nie pisałem promptu, nie zarządzałem nimi, wystarczyło kliknąć i zobaczyć, co robią. Wszystko, co podoba ci się w aplikacjach Cursora czy Codexa (a są to dobre aplikacje), znajdziesz w BB, z tą różnicą, że kod jest otwarty – można go sforkować i zajrzeć do środka – i nic nie kosztuje.
Drugie narzędzie to cmux. Świetnie nadaje się do prowadzenia wielu spraw naraz: mogę na przykład rozpiąć pięć paneli z Codexem i obserwować, jak zachowują się po utracie łącza. Nową przestrzeń roboczą dzieli się jak ekran w tmuxie – stąd podobna nazwa – a każdy panel to zwykły terminal, w którym odpalisz dowolny harness; jest nawet wbudowana przeglądarka. Wada wychodzi przy skali: gdy agentów i przestrzeni robi się dużo, lewy pasek boczny przestaje wystarczać i większy projekt zaczyna się gubić. Do dwóch–trzech spraw jednocześnie – jak najbardziej.
(Informacja dodatkowa: „harness” to otoczka, w której działa agent – łączy model z terminalem, plikami i narzędziami. Claude Code i Codex to właśnie harnessy, tak samo jak Pi czy Cursor CLI.)
Trzeci element: terminal Ghostty, szybki i natywny, a w nim Herder – coś w rodzaju tmuxa dla agentów, lekki backend, w którym żyją ich sesje. Aplikacja Cursora wywalała mi się, gdy puszczałem pięć i więcej agentów w worktree, czyli osobnych kopiahcach drzewa roboczego repozytorium (wrócę do tego). Herder jest minimalny, siedzi w terminalu i pozwala błyskawicznie startować nowe sesje oraz przechodzić między katalogami. Najważniejsze: po lewej widzę stan każdego agenta – skończył, czeka, utknął, pracuje. Uruchomię Codexa, powiem „cześć”, widzę, że pracuje, potem że czeka – i nie muszę go pilnować. Śledzenie stanów to informacja krytyczna i przewiduję, że w ciągu trzech–sześciu miesięcy zrobi się jeszcze ważniejsze: nie będziesz rozmawiał z jednym agentem, tylko z agentem-menedżerem, który kieruje wieloma pracownikami. Uwaga człowieka jest z natury ograniczona – dlatego dobry interfejs to podstawa.
Jest wreszcie Coral, narzędzie mojego autorstwa (obecna wersja to fork projektu Zeron). Zamiast przeskakiwać między agentami losowo, gdy któryś skończy – tak działa Herder – przyjąłem, że każdy agent ma inny priorytet. Gdy kończy agent P1, wraca na szczyt kolejki; nie ma mowy, żebyś odpisywał agentowi P4, kiedy czeka na ciebie P1. Jeszcze muszę to dopracować i upublicznić – zobaczymy, czy wzbudzi zainteresowanie.
Modele i subskrypcje: jak nie przepłacać
Drugi temat: modele i subskrypcje, czyli jak wycisnąć z pieniędzy maksimum. Dziś cztery główne subskrypcje prezentują się tak (za dwa miesiące może być zupełnie inaczej).
Najlepszy stosunek ceny do wartości ma OpenCode Go: dziesięć dolarów miesięcznie za Kimi K3, Groka 4.6, GLM 5.3 i DeepSeeka V4 Pro. Zestaw robi wrażenie jak na tę cenę, ale zabraknie ci najlepszych modeli – Fable i GPT 5.6 – a limity są dość ciasne, więc przy większym budżecie trzeba dokupić kolejną pozycję.
Za dwadzieścia dolarów zaczyna się od ChatGPT/Codexa albo Claude, jeśli masz wyrobioną preferencję; ewentualnie Cursora, jeśli zależy ci na wielu modelach – tyle że Cursor słabiej subsydiuje. ChatGPT i Claude dają w tym przedziale najwięcej wykorzystania, ale tylko własne modele. Konkretnie: za trzydzieści dolarów – OpenCode plus ChatGPT/Codex; za pięćdziesiąt – dokładasz Claude Code; za siedemdziesiąt – jeszcze Cursor i masz najniższe piętro wszystkich czterech. Od około stu dziesięciu dolarów wchodzisz w duże plany, bo one dają zdecydowanie najlepszą propozycję – i tu ChatGPT/Codex wypada lepiej niż Claude, po prostu OpenAI ma więcej mocy obliczeniowej i chętniej dopłaca. W dającej się przewidzieć przyszłości subskrypcja ChatGPT – czy za sto, czy za dwieście dolarów – da ci więcej niż Claude Code. A przy budżecie około dwustu dziesięciu dolarów bierz od razu duże plany: te za dwieście dają wielokrotnie więcej.
Cursor jest przy tym niedoceniany. Po przejęciu przez SpaceXA firma Elona Muska dysponuje ogromną mocą obliczeniową i stertą GPU, a to znaczy, że może grać w tę samą grę co OpenAI – dopłacać do subskrypcji. Na razie subsydiów jak w Codexie czy Claude Code nie ma, ale to łatwa prognoza, w której jestem pewny: za dwa–cztery miesiące subskrypcja Cursora stanie się świetnym interesem. Z Grokiem 4.6 jest już dobrze, a Grok 4.7 już za rogiem.
I zasada nadrzędna: nigdy nie płać za API. To najgorszy wariant – zero subsydiów, zero rabatów, żadnego „więcej tokenów za mniej pieniędzy”. Chcesz wymieniać jak najmniej gotówki na jak najwięcej tokenów, a to potrafią tylko subskrypcje. Składaj te cztery według budżetu, jak ci pasuje.
Agenty chmurowe: przyszłość z jednym dużym „ale”
Przyszłością są agenty chmurowe – widać to po ruchach Cursora, Amp, Devina czy Codexa; wszyscy stawiają na chmurę na maksa. Dowód? Wewnętrzny wykres Cursora pokazujący siedmiodniową, kroczącą wartość zmieszanych pull requestów wykonanych przez agentów chmurowych. Na początku roku było to około 10–15%, a w drugiej połowie 2026 zbliża się do 60%. Nie mówimy o automatach, których zmiany wiszą nierozmieszane – liczone są te, które realnie trafiają do kodu, i większość z nich robią agenty chmurowe.
Czym zatem jest agent chmurowy? Wszystko, co pokazywałem w BB, działa lokalnie, na moim komputerze. Tyle że to się nie skaluje: setek agentów nie uruchomisz, bo wystarczy, że kilku naraz zechce odpalić testy bazodanowe albo cały ich zestaw, i maszyna klęka. Do tego dochodzą izolacja środowisk, trwałość sesji oraz nieprzerwany dostęp do internetu i prądu: zamykasz laptopa – tracisz sesje; internet pada na kilka minut – harnessy nie potrafią się pozbierać. Potrzeba agentów lokalnych nie znika, ale coraz większa część pracy przenosi się do chmury. Spójrzcie na Grokboty – produkt wybucha, a to tylko inna odsłona tego samego pomysłu.
Mój problem z gotowymi rozwiązaniami: uzależnienie od ekosystemu. Konfiguracja środowisk, sekretów i zmiennych to godziny roboty, a potem siedzisz w nich na amen: sesje u nich, ich cennik, cały twój kontekst u nich. Mogą trenować na tym modele, a nawet jeśli nie trenują – dane można przeglądać, analizować, porównywać. Migrowanie całej firmy później to drogi koszmar.
Dlatego recepta jest jedna: własny serwer. Brzmi groźnie, jest proste. Na serwerze uruchamiasz Herdera, który daje trwałe sesje i wielu agentów naraz, a łączysz się przez SSH – z telefonu, laptopa, z czegokolwiek, co obsługuję SSH. Efekt 80/20 za kilka dolarów. Pokażę, jak to postawić, żeby skorzystać z rewolucji agentów chmurowych za ułamek ceny i bez uzależnienia od nikogo.
(Informacja dodatkowa: Hostinger jest sponsorem tego odcinka; autor poleca link partnerski i kod rabatowy „David”.)
Własna chmura krok po kroku: tani VPS
Pierwsza rzecz: serwer, najprościej VPS. Od lat używam Hostingera – tak samo wszyscy w moim zespole – bo to jeden z najtańszych wyborów, a konfiguracja zajmuje chwilę. Wybieramy plan; KVM2 w zupełności wystarczy, chyba że planujesz setki agentów – wtedy mocniejsza maszyna. Okres: dwanaście albo dwadzieścia cztery miesiące; polecam dwadzieścia cztery, bo oszczędność jest największa – a skoro co miesiąc uruchamiamy coraz więcej agentów, lepiej wejść w to teraz, zanim reszta rynku łapie to za pół roku. Dodatkowe dziesięć procent zyskasz kodem „David”. Zbędne dodatki w koszyku odznaczamy, lokalizację serwera bierzemy najbliższą sobie – siedzę w Warszawie, więc Niemcy, tym bardziej że panel pokazuje opóźnienia. Dalej logowanie lub rejestracja (dwadzieścia sekund), dane karty – i kupione.
Po zakupie panel pokazuje twój VPS: adres IPv4, dostęp roota i hasło. Jeśli nie zapisałeś hasła przy konfiguracji, resetujesz je, tworzysz nowe i chowasz w menedżerze haseł.
Konfiguracja po ludzku: agent robi robotę
Zamiast klikać sam, deleguję postawienie środowiska agentowi. W jednym panelu cmux uruchamiam agenta kodującego – może być Claude Code albo Codex, ja biorę Cursor CLI, bo działa z każdym modelem, i do tego zadania Groka 4.6 na wysokim poziomie (zaskakująco dobrze się sprawdza). Prompt brzmi: „Pomóż mi zalogować się przez SSH na VPS i ustawić zależności. Odpowiadaj prostym językiem, bardzo zwięźle”. To, co nazywam presendem: warto agentowi z góry zasygnalizować, czego dotyczy sesja – a przy okazji kolejkować u niego kolejne kroki, zanim skończy bieżący.
Agent od razu sięgnął po mój skill od SSH i VPS-ów (moje repozytorium skillów jest darmowe, link w opisie filmu – skill to po prostu instrukcja lub procedura, którą agent ładuje, gdy jest potrzebna), więc hamuję go: „Stop, to świeży VPS. Jeszcze nie używaj skillów, nie pędź – powiem ci, co robić”.
Wszystko dyktuję przez Superwhisper, bo mowa jest szybsza niż pisanie. Nawet jeśli wystukujesz 150 słów na minutę (sprawdzisz się choćby na monkeytype.com), powiesz ich około 300; naprawdę szybko mówiący – 250 i więcej. Większość pisze 40–50 słów na minutę, więc od razu mówi trzy–cztery razy szybciej. Wybór narzędzia nie ma znaczenia: Glo, Superwhisper, WhisperFlow – byle było. W tłumie nie użyjesz, ale gdzie indziej – zawsze.
W drugim panelu cmux odpaliłem komendę pwd. Mówię agentowi: „Znajdź ten pusty panel – tam będziesz wykonywał wszystkie terminalowe komendy, gdy podam ci VPS”. Znajduje go i wysyła testowe echo – dokładnie po to mam skill od cmux. Dlatego lubię takie konfiguracje w terminalu: wszystko widać na żywo. Aplikacje desktopowe chowają szczegóły – początkującym to wygodne, ale kto chce poważnie pracować z agentami, nie może bać się terminala. Terminal to po prostu sposób na dostęp do komputera, nic więcej.
Teraz przekazuję agentowi dostęp do serwera. Komendę logowania roota kopiuję z panelu i wklejam w prawym panelu, hasło wpisuję sam. Dobra praktyka: jeśli robota jest powtarzalna, trzymaj poświadczenia w pliku env.local, a w skillach podawaj wyłącznie ścieżkę do niego. Nigdy nie wklejaj loginów, haseł ani zmiennych środowiskowych do skillów i promptów – to bardzo zła praktyka.
Po zalogowaniu dyktuję: „Sprawdź panel jeszcze raz – właśnie wszedłem na VPS. Jeśli widzisz, odpal kilka komend i poznaj ten serwer”. I tu widać, po co agent: nawet zawodowiec czyta tylko tak szybko; agent czyta błyskawicznie i równie szybko pisze kod oraz komendy. W kilka sekund mam raport: Ubuntu, dwa rdzenie vCPU, około ośmiu gigabajtów RAM-u.
Kolejny krok: „Ustaw środowisko deweloperskie na tym VPS: zainstaluj Herdera; upewnij się co do Node.js, Pythona 3 i Gita. Zacznij od instalacji, najnowsze stabilne wersje”. Nie chodzę po stronach projektów i nie kopiuję komend instalatorów – agent sam pilnuje aktualności. Taki jeden VPS udźwignie wielu agentów: Hermes do spraw prywatnych, OpenClaw i cała stajnia agentów kodujących – Claude Code, Codex, Cursor, Droid, Prime Agent, cokolwiek używasz. Potrzebujesz mocniejszej maszyny? Kilka kliknięć w panelu – taniej i wygodniej niż migracja domowego serwera albo nowy laptop.
Po co w ogóle chmura? Bo długiego zadania nie zwiążesz z lokalnym komputerem: wychodzisz do kawiarni, zamykasz laptopa, łapiesz kapryśne Wi-Fi. Na własnym VPS odpalasz to bez stresu i konfigurujesz dokładnie po swojemu.
Najważniejsze: nie musisz znać się na VPS-ach, DevOpsie ani Linuksie. Patrz, jak rozmawiam z Grokiem 4.6 po ludzku, a on robi wszystko. Konnektory, harnessy, interfejsy, cron – cokolwiek chcesz ustawić, opisz słowami, każ wypisać darmowe opcje i przejdź z agentem przez kluczowe decyzje. Edukuj się w wyborach, a składnię i komendy zostaw mu. Minimalny przepis: cmux, po lewej agent kodujący, po prawej terminal zalogowany na VPS – i stawiasz dowolny setup chmurowy, z pominięciem lock-inu, na którym firmom najbardziej zależy, bo klient raz skonfigurowany praktycznie nie odchodzi.
Po chwili wszystko stoi: mówię „uruchom Herdera” i agent, odczytawszy stan interfejsu, odpala go na serwerze. Chcę też Pi – a Pi nie ma jeszcze na tej maszynie, więc: „Zainstaluj Pi agent; użyj skilla Deep API, żeby znaleźć oficjalny instalator”. I to jest kolejna reguła: wystarczy ci jeden agent, a potem tym agentem ustawiasz kolejne. Pi samo znajdzie instalator, zainstaluje, skonfiguruje, wyłapie na moim Macu klucz OpenRouter i wykona pełen setup na świeżym VPS po jednym moim zdaniu.
Jeśli masz komputer, walcz o postawienie pierwszego agenta. Odwołaj spotkanie, jeśli trzeba; usiądź i zrób to. Potem wszystko idzie już z górki.
Harnessy: Pi, Cursor CLI, samouczące się i klasyki z aliasami
Pi Agent – dla mnie najlepszy z możliwych: najprostszy i najbardziej minimalistyczny harness. Dostępny na pi.dev, open source i darmowy; na Pi zbudowany jest między innymi OpenClaw. Cztery narzędzia, zawsze w trybie YOLO (czyli bez pytania o potwierdzenia), dowolny model, dowolny dostawca. Elegancki, łatwy, bardzo konfigurowalny – stąd rosnąca popularność i mnogość projektów powstających na jego bazie. Dla mnie bezdyskusyjne: Pi musi być zainstalowane, dlatego to pierwszy harness, jaki stawiam na VPS. (O Pi rozmawiałem na podcaście z Mariem; za tydzień lub dwa epizod z Armenem – subskrybujcie, żeby nie przegapić.)
Gdy instalacja się skończyła, dyktuję: „Przejdź całą konfigurację sam. Jeśli potrzebujesz klucza OpenRouter, przejrzyj mojego MacBooka, znajdź go i użyj tego samego na VPS. Doprowadź model do działania – niech to będzie GPT 5.6 – w Pi przez OpenRouter. Idź dalej, masz moje pozwolenie”. I Grok robi wszystko. Zresztą nie ma znaczenia, czy prowadzisz przez Cursor CLI, Claude Code czy Codex.
Kolejny: Cursor CLI, bardzo niedoceniany. Przy jednej subskrypcji masz w nim wszystkie modele – Groka, modele GPT (choć OpenAI chce je stamtąd usunąć, to osobna historia), modele Anthropic, Kimi K3. Można tagować skille i ustawiać presendy – czego na przykład Claude Code nie oferuje.
Trzecia kategoria: harnessy samouczące się – na zadania, których nie rozumiesz, gdy zaczynasz coś z myślą „nie wiem, jak to ma wyglądać”. Dwa główne: Hermes, klasyk samodoskonalenia, i nowszy Prime Agent o zupełnie innym podejściu. Oba obiecujące – przetestuj oba i wybierz jedno. Przy dużej niepewności taki harness tworzy skille i rozwija się razem z tobą. A gdy robisz coś konkretnego – rozwijasz software i nie chcesz losowych skillów – zostań przy Codexie, Pi, Claude Code albo Cursorze.
Na końcu klasyki: Claude Code i Codex. Mam globalne aliasy: cc odpala Claude Code z pominięciem potwierdzeń uprawnień, cx – Codexa w trybie YOLO. Ludzie codziennie wystukują pełne, długie flagi – to powolne i nieefektywne. Połowa inżynierii agentowej to pytanie, jak zdążyć więcej w tym samym czasie, a aliasy na częste, długie komendy to absolutna podstawa.
Skille: recenzje, decyzje, research i bezpieczeństwo
Moje repozytorium skillów stało się w zeszłym miesiącu hitem – znani ludzie z branży AI uznali je (ich słowami) za jedno z cenniejszych repozytoriów. Nagrałem o nim osobny, półgodzinny materiał rozbierający na części osiem skillów, których używam bez przerwy; tutaj zostaję przy najważniejszych dla tego tematu. Repo jest darmowe i otwarte – forkujcie śmiało. I od razu: nie instalujcie wszystkiego. Bierzcie tylko to, czego faktycznie używacie – nie obciążajcie agentów balastem.
Pierwszy: total review (katalog agent orchestration). Uruchamia dwa inne skille – GPT review i Fable review – które przeglądają twoje zmiany. Przykład: przygotowywałem repo do publikacji; zamiast samemu odpalać Fable, podawać kontekst i prosić o spojrzenie seniora, kazałem po prostu: „przejrzyj zmiany przez total review”. Zasada ogólna: cokolwiek robisz dość często, zamień w prompt albo skill. Pojedyncze kroki trzymam jako rozwinięcia tekstu – skróty rozwijające się do promptów: „odpowiadaj krótko, prostym językiem”, „wykonaj ten plan w całości, jak senior”, „uprość i skróć poprzednią odpowiedź, ładnie sformatowaną”, „dodaj pliki do gita, napisz czytelny komentarz i wypchnij na GitHub”. Każdy z tych promptów mówiłbym z dwie minuty, z błędami i za każdym razem trochę inaczej – a tak wpisuję go natychmiast. Ja trzymam je w snippetach Raycasta, ale na start wystarczy wbudowane zastępowanie tekstu w macOS. Pojedynczy krok – rozwinięcie tekstu; wieloetapowy przepływ – skill.
Total review idzie jednak o krok dalej: puszcza recenzje GPT i Fable razem, a potem scala wyniki w jedną listę – bez marnowania tokenów. Uruchamiaj go przy średnich i dużych zmianach, zwłaszcza gdy pracował inny model: to, co zrobił Grok 4.6, oglądaj oczami GPT 5.6 Soul albo Fable 5 – inna sieć, inne wyczucie. Obrazowo: składasz ważne podanie o pracę. Jedna opinia rozsądnego znajomego to GPT review albo Fable review. Total review to wszyscy najbystrzejsi znajomi, którym każesz wrzucić na wspólny czat wyłącznie najcięższe zarzuty – dostajesz tylko to, co naprawdę ważne.
Drugi: ask and build (katalog thinking and docs) – nowszy skill, którego używam codziennie. Zasada: przed budowaniem przechodzimy decyzje. Zamiast „zrób to pod Windows” mówię: „chcę, żeby to działało na Linuksie i Windowsie – przeprowadź ask and build dla pięciu głównych decyzji”. Bo jeśli po prostu każesz, agent podejmie decyzje architektoniczne i projektowe, których możesz żałować. Odrobina pracy z przodu – a kod łatwiej skalować, mniej długu technicznego, lepszy software. Dostajesz wypisane opcje: ten sam produkt na Windows? najpierw pełna wersja na Linuksie, na Windows tylko binarka? – wybór należy do ciebie. Modele świetnie kodują i wdrażają plany, ale brak im smaku i dobrego osądu. Decyzje zostają przy człowieku – dokładnie to ten skill zapewnia.
A tymczasem na VPS: Grok skończył, Pi działa w pełni – OpenRouter, GPT 5.6, poziom rozumowania przełączany skrótem Shift+Tab. I sedno: mogę zamknąć laptopa, MacBook może wybuchnąć – agenci na serwerze pracują dalej. Odpalam drugiego Pi, tym razem z Fable: dwóch agentów, dwa modele, oba w chmurze, na moim VPS, z pełnym dostępem roota do Ubuntu. Własne środowisko chmurowe – i naprawdę aż tak proste.
Trzeci: Deep API – mój skill do głębokich researchów i scrapingu. Przykład: przed zbudowaniem instalatorów pod Linuksa i Windowsa dyktuję: „użyj skilla Deep API, zrób osiem szybkich przeszukiwań sieci i ustal najlepsze sposoby na oba systemy – opcje techniczne i dobre praktyki; przedstaw trzy najlepsze, krótko i po ludzku”. Ten sam skill potrafi zgarniać treści z Twittera czy GitHuba, robić głęboki research, a nawet ustalić trzy drogi kontaktu z człowiekiem: mail, numer, LinkedIn. Codex i Claude Code mają co najwyżej podstawową wyszukiwarkę – bez scrapingu, bez głębokiego researchu, i łatwo je zablokować. Deep API łata tę dziurę; używam go w kółko, cały zespół tak samo.
Czwarty i piąty są nudniejsze, ale niezbędne – i ustawiane tylko raz. Global agent guardrails (katalog ops and setup) to skill z hookiem: skrypt uruchamiany przed każdym wywołaniem narzędzia przez agenta. Pilnuje, by agent nigdy nie wyczyścił ci dysku, nie nadpisał historii ani nie posłużył się niebezpiecznymi wzorcami: rekurencyjne usuwanie, ryzykowne komendy gita i GitHub CLI, pobieranie z sieci bez sprawdzenia, grzebanie w menedżerze haseł. Wyobraź sobie atak typu prompt injection, w którym złośliwa treść każe agentowi odczytać twoje hasła – hook blokuje to, zanim komenda w ogóle ruszy. Nie wiem, jak ludzie żyją bez tego. Te twitterowe historie o wyczyszczonych dyskach i zhakowanych bazach? Każda kończyłaby się inaczej przy zwykłym hooku przed wywołaniem narzędzia. Zasada twarda: nie używaj trybu YOLO ani pomijania uprawnień bez tego skilla. Ryzykujesz za dużo i bez potrzeby.
Ostatni, pro push – dla zaawansowanych prowadzących wiele worktree. Problem: gdy kilkanaście i więcej agentów scala gałęzie i wypycha na produkcję, prędzej czy później dwóch czy trzech zechce pushnąć w tej samej chwili – staje CI/CD, lecą konflikty. Potrzebna kolejka i blokada. Pro push to blokada na poziomie całego systemu, prawdziwy kernelowy flock: pełny cykl wydania (merge, weryfikacja, push, CI, deploy, kontrola stanu) wykonuje naraz tylko jeden agent, reszta czeka. Nie wyobrażam sobie bez tego pracy – ale bez wielu worktree przeżyjesz. Nawet gdy prosiłem agenta o wyjaśnienie, po pierwszej odpowiedzi dorzuciłem z rękawa: „uprość i skróć poprzednią odpowiedź”. Nie czytaj długich, zakręconych wywodów – twoja uwaga jest równie cenna jak tokeny agenta.
Worktree: skala decyduje
Czym jest worktree, jeśli nie znasz? Kopią katalogu roboczego repozytorium: osobny folder z osobną, nową gałęzią gita, w której agent pracuje w pełnej izolacji – dzięki temu wielu agentów nie skacze sobie do oczu.
W małych projektach – niepotrzebne. Mam drobne narzędzie, które właśnie otworzyłem na licencji MIT; siedzę na głównej gałęzi, bo worktree byłyby armatą na wróbla. BB ma je zresztą wbudowane i pamięta (w przeciwieństwie do aplikacji Cursora, gdzie za każdym razem trzeba wpisywać komendę – irytujące). W większym repo, jak Deep API, kliknięcie plusa pamięta moje ustawienie: lokalnie pracuję na głównej, a przy API zawsze zakładam świeży worktree od origin/main. Właśnie dlatego BB to mój główny interfejs. Reguła: mały projekt albo poniżej kilkunastu agentów równolegle – jedna gałąź i spokój. Średnie i duże projekty z dwudziestoma–trzydziestoma agentami non stop – worktree obowiązkowe; inaczej agenty będą sobie nadpisywać i cofać zmiany, budować jedne na drugich – chaos gwarantowany.
Szybka serie: modele, recenzje, presendy, podagenty, ADR-y, testy, produkcja
Zostało mnóstwo tematów – zrobię z nimi szybką serię, z szacunku dla waszego czasu.
Musisz dogłębnie wiedzieć, kiedy sięgnąć po który model. Projektujesz architekturę – Fable. Nowy projekt – Fable, ma najwięcej iskry. Poważny, głęboki bug wymagający skrupulatności – GPT 5.6 Soul na maksymalnym wysiłku rozumowania. Codzienna rozmowa – Grok 4.6 na poziomie high albo extra high: konsekwentny, przewidywalny, prawie tak sprawny jak Fable i 5.6 Soul, a dwa razy tańszy i szybszy. Front-end – dziś najlepszy jest Kimi K3. Ta wiedza przychodzi wyłącznie z praktyką. Nie bądź kimś, kto przez samą aplikację Codexa zna tylko modele GPT i nigdy nie próbuje Anthropic, DeepSeek, GLM czy Kimi. I praktyka konkretna: gdy wychodzi ważny nowy model, odetnij się od wszystkiego i spędź minimum dobę, pracując tylko na nim. Nie słuchaj, co mówią na Twitterze – sprawdź w swoich workflowach.
Musisz też czuć, kiedy wypychasz na produkcję od ręki, a kiedy przeglądasz zmiany. Mała korekta front-endu? Wypycham od razu, bez total review. To przychodzi z doświadczeniem, z liczby budowanych projektów. Nie można marnować tokenów na review wszystkiego – ale nie wolno też wpaść w recenzje rekurencyjne. To ogromny błąd: modele wymyślają urojone błędy. Jeden przebieg: budujesz Fablem, przeglądasz GPT-em, poprawiasz najgorsze rzeczy, wypychasz. Nie rób Fable, potem GPT, znowu Fable, znowu GPT – nigdy nic nie wydasz. Bo na „znajdź pięć największych problemów w tej bazie” model nie odpowie: „kod jest wystarczająco dobry, zajmij się czymś innym” – tak powiedziałby świetny developer; model wypisze pięć problemów, choćby kod był wzorowy. Ani zero recenzji, ani w kółko – trzymaj się środka.
Presendy – jeszcze raz, bo są kluczowe. Ktoś z zespołu nagrał ze mnie zabawny filmik: wysyłam z wyprzedzeniem sześć kolejnych wiadomości, bo wiem, co się wydarzy. „Wykonaj plan”. „Przepuść to przez Fable review”. „Skróć odpowiedź”. „Przestań kombinować, powiedz, co naprawdę ważne”. „Teraz to popraw”. Zwykle to jeden–trzy kroki, bywa sześć. Jeśli sekwencja się powtarza, zamień ją w skill. I zasada: nie używaj harnessu ani interfejsu, który nie pozwala kolejkować wiadomości z wyprzedzeniem – BB pozwala.
Podagenty. Nadużywa się ich; ludzie marnują na nich limity. Ja używam ich tylko pod kontrolą – nie podobają mi się agenty, które losowo odpalają kolejne. Wiem, że to przyszłość, ale musisz nad tym panować; nazewnictwo „menedżer i pracownicy” mówi zresztą znacznie więcej niż „podagent”. Problem z aplikacjami: delegują na marne modele. Haiku 4.5? Nigdy. GPT 5.6 Luna? Lepiej, ale wcale niekoniecznie. Ja sam wybieram model dla podagenta: znam swoje subskrypcje i limity i nie chcę, by tani model implementował zmiany w kodzie, na którym mi zależy. Mam własne skille – total review, osobny do uruchamiania podagentów w BB – i odpalam je wtedy, kiedy decyduję ja. Przyszłość to menedżer kierujący pracownikami, ale ten system projektujesz ty: zasady, uprawnienia, warunki startu. Nie chcę, żeby decydował za mnie ktoś w Anthropic. Claude Code jest pełen zbędnych rzeczy – Pi powstało właśnie dlatego, że Claude Code jest spuchnięty: nadmiar zjada tokeny i grzebie w systemie za plecami. Jeśli ci to nie przeszkadza, nie traktujesz tej pracy poważnie. Trzymaj podagentów krótko: buduj skille i reguły określające, kiedy wolno im wystartować.
ADR-y, czyli Architecture Decision Records: sposób dokumentowania decyzji w repozytorium tak, by przyszli agenci i ludzie wiedzieli, dlaczego kod wygląda właśnie tak. Katalog /doc/adr zakładam wśród pierwszych. W jednym z mniejszych projektów mam cztery decyzje: autonomiczna praca ciągła; plik straży sekretów – sama nazwa; wyłącznie gałąź domyślna; dystrybucja przez Homebrew Cask. Wskazuję agentom ten katalog i natychmiast rozumieją wszystkie wybory. A gdy decyzja się zmieni, mam zapisane uzasadnienie i stan projektu z tamtej pory. Jeśli tego nie robisz – zacznij. Nie wszystko da się wyczytać z kodu; to, czego się nie da, zapisuj jako przejrzysty markdown. To kontekst zaoszczędzony przyszłym czytelnikom – ludzkim i maszynowym.
(Informacja dodatkowa: ADR – „Architecture Decision Record”, notatka dokumentująca pojedynczą decyzję architektoniczną wraz z jej uzasadnieniem i kontekstem.)
Testy. To ważne, zwłaszcza z GPT 5.6 Soul: model upycha testy wszędzie, nawet w najmniejszych repo – jednostkowe, integracyjne, bazodanowe, komponentowe. W OpenAI tak go dostrojono, że dodaje testy zawsze, nawet gdy nie ma to sensu. Efekt: żeby wyjść na właściwą ilość, musisz mu niemal zakazać testów. Zastanów się nad tym – to wyższa szkoła inżynierii agentowej: bez instrukcji agent narobi testów od groma; gdy powiesz „nie dodawaj testów”, i tak trochę doda – i to jest akurat ta właściwa miara. Może kolejna generacja to zmieni; na razie trzymaj agentów krótko, bo inaczej zrobią z repo testowy balon. Testy – tak, ale tam, gdzie mają sens.
Produkcja. Każdy produkt z realnymi użytkownikami powinien mieć agenta podpiętego do produkcyjnej bazy – ale wyłącznie do odczytu. U siebie utworzyłem w Postgresie rolę tylko do czytania (skill: read prod database). Nigdy nie dawaj agentowi pełnego dostępu: w 99,9% przypadków przejdzie gładko, ale wystarczy jedna nieodwracalna operacja – skasowany użytkownik, wyczyszczona tabela – i będziesz żałować. Brak dostępu to jednak też błąd. Z agentem przeanalizujesz dane w kilka minut: najpopularniejsze funkcje; to, co robią zaawansowani użytkownicy, a czego nie powtarzają odchodzący; najczęstsze błędy z produkcji. Budujesz funkcję? Zderz ją z rzeczywistością: czy ludzie w ogóle jej używają; czy szlifować jej interfejs, czy to najbardziej martwy zakątek produktu. Bezcenne; żałuję, że nie wpadłem na to wcześniej.
Mierzenie produktywności i pożegnanie
Na koniec mierzenie produktywności agentowej. W Vectoral Labs – moim laboratorium badawczo-innowacyjnym – wydaliśmy właśnie otwarte repozytorium agentic productivity: liczy commity, sesje agentów i rozwiązane problemy użytkowników. Każda z tych metryk osobno jest słaba, ale połączone, w długim trendzie i między harnessami pokazują, czy naprawdę dowozisz więcej. A przy okazji: będę rzadziej wrzucał filmy na YouTube, za to codziennie piszę artykuły – własnoręcznie – na vectoralabs.com. Wczoraj na przykład rozkminka „dlaczego nie ma więcej agentów?” – modele wystarczająco dobre, harnessy wystarczająco dobre, więc co blokuje? Jeśli siedzisz w AI, kodowaniu czy inżynierii agentowej i chcesz być na froncie – vectoralabs.com.
To tyle w tym surowym, gęstym formacie. Jeśli chcecie część drugą – dajcie znać w komentarzach; setup i tak zmienia się co miesiąc. A jeśli nie macie jeszcze VPS-a i własnych agentów chmurowych – zróbcie to teraz, dziś. Pierwszy link w opisie, kod David. Pokazałem krok po kroku, że to proste – i będziecie gotowi na przyszłość, w której wszyscy będziemy trzymać setki i tysiące agentów w chmurze, bez uzależnienia od niczyjego ekosystemu. Dzięki za obejrzenie i produktywnego tygodnia.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Subskrypcje składaj w pakiet, za API nie płać nigdy
Na czym polega: Subskrypcje są subsydiowane przez dostawców, więc dają wielokrotnie więcej tokenów za dolar niż rozliczenie API. Autor układa cztery pozycje (OpenCode, ChatGPT/Codex, Claude Code, Cursor) według budżetu – od dziesięciu do ponad dwustu dolarów miesięcznie.
Jak stosować: Zacznij od OpenCode Go (10 USD) – najlepszy wstęp za grosze. Przy 30 USD dokup ChatGPT/Codex, przy 50 USD Claude Code, przy 70 USD Cursora. Od około 110 USD przechodź na duże plany (najlepszy stosunek wartości), a przy ok. 210 USD bierz warianty za 200 USD – według autora dają wielokrotnie więcej.
Na co uważać: Oferty zmieniają się w skali miesięcy – co jakiś czas weryfikuj układ. Tanie plany mają ciasne limity i brak najsilniejszych modeli. Cursor na razie subsydiuje słabiej niż konkurencja (autor prognozuje poprawę dzięki mocy obliczeniowej SpaceX). API to najgorszy możliwy wybór – brak subsydiów.
2.Własny VPS: trwałe sesje i dziesiątki agentów bez lock-inu
Na czym polega: Gotowe platformy chmurowe zamykają cię w ekosystemie: sesje, sekrety i cały kontekst lądują u dostawcy, a wyjście jest później drogie i bolesne. Tani własny serwer z Herderem i SSH daje trwałe sesje, wiele równoległych agentów i pełną kontrolę za kilka dolarów.
Jak stosować: Weź podstawowy VPS (w zupełności wystarczy 2 vCPU i 8 GB RAM-u), a całą konfigurację (Herder, Node.js, Python, Git) zleć agentowi w zwykłym języku, zdanie po zdaniu. Łącz się przez SSH z laptopa lub telefonu. Pierwszego agenta postaw za wszelką cenę – kolejne pójdą już z górki, bo jeden agent potrafi konfigurować następne.
Na co uważać: Hasło roota od razu do menedżera haseł. Poświadczeń nigdy nie wklejaj do skillów i promptów – trzymaj je w env.local i podawaj tylko ścieżkę. Agenty lokalne nie znikają: do drobnych zadań nadal wystarczy własna maszyna.
3.Zanim włączysz YOLO – hook z guardrails
Na czym polega: Skrypt wyzwalany przed każdym wywołaniem narzędzia przez agenta (pre-tool-call hook) blokuje niebezpieczne wzorce: rekurencyjne usuwanie plików, ryzykowne komendy gita i GitHub CLI, niekontrolowane pobieranie z sieci, dostęp do menedżera haseł. Konfiguruje się go raz.
Jak stosować: Zainstaluj skill global agent guardrails z repo autora przed pierwszym użyciem trybu YOLO albo pomijania potwierdzeń uprawnień. Utrzymuj aktualną listę wzorców, które agent ma prawo wykonać wyłącznie z twojej wiedzą.
Na co uważać: Atak prompt injection może kazać agentowi odczytać twoje sekrety – bez hooka tryb YOLO to lot bez spadochronu. Historie o „wyczyszczonych dyskach” krążące po sieci to niemal zawsze brak właśnie takiego zabezpieczenia.
4.Każde powtórzenie zamieniaj w automat
Na czym polega: Pojedynczy często powtarzany prompt to rozwinięcie tekstu (snippet); wieloetapowy przepływ – skill; przewidywalna sekwencja kroków – presendy, czyli zakolejkowane wiadomości; długie komendy – globalne aliasy (cc, cx). Do tego dyktowanie zamiast pisania, bo mówisz kilka razy szybciej, niż piszesz.
Jak stosować: Przejrzyj swoje promptowanie: co wpisujesz codziennie, to kandydat na snippet (Raycast albo wbudowane zastępowanie tekstu w macOS). Powtarzająca się sekwencja dwóch–sześciu promptów to gotowy skill. Długie flagi harnessów skróć do aliasów. Promptuj głosem (Superwhisper, WhisperFlow, Glo).
Na co uważać: Nie instaluj skillów „na zapas” – balast zjada tokeny i rozprasza. Snippety muszą być jednoznaczne i stabilne: ich siła polega na powtarzalności. Dyktowanie nie wszędzie wypada.
5.Recenzja krzyżowa – dokładnie jedna
Na czym polega: Zmiany zrobione jednym modelem warto przeglądnąć drugim – inna sieć widzi inne problemy. Skill total review puszcza dwie recenzje równolegle i scala wyniki w jedną listę najpoważniejszych zarzutów, bez marnowania tokenów.
Jak stosować: Przy średnich i dużych zmianach uruchamiaj total review, zwłaszcza gdy wcześniej pracował inny model (np. Grok oglądany przez GPT 5.6 Soul lub Fable 5). Schemat: zbuduj Fablem, przegladaj GPT-em, popraw najgorsze punkty, wypchnij.
Na co uważać: Recenzje rekurencyjne (Fable–GPT–Fale–GPT…) są pułapką: model zawsze wypisze „pięć problemów”, nawet we wzorowym kodzie, bo nie powie ci, że kod jest już wystarczająco dobry. Ale i zero recenzji to błąd. Drobne korekty front-endu możesz wypychać od ręki.
6.Decyzje podejmuj przed budowaniem
Na czym polega: Skill ask and build wymusza przejrzenie kluczowych decyzji przed implementacją: agent wypisuje opcje (np. pełny produkt na Windows czy tylko binarka), a wybór należy do ciebie. Modele świetnie kodują i wdrażają plany, ale brak im smaku i dobrego osądu.
Jak stosować: Zamiast „zrób to pod X” formułuj: „chcę X – przeprowadź ask and build dla pięciu głównych decyzji”. Przejdź po opcjach, wybierz świadomie, dopiero potem każ budować. Kilka minut z przodu to mniej długu technicznego i łatwiejsze skalowanie.
Na co uważać: Polecenie „zrób to pod X” bez przeglądu decyzji oznacza architekturę wybraną przez model – którą możesz żałować. To ty zostajesz odpowiedzialny za wybory, nie agent.
7.Model pod zadanie – i pełna doba testów z każdym nowym
Na czym polega: Mapa modeli autora: Fable na planowanie i nowe projekty; GPT 5.6 Soul na maksymalnym wysiłku rozumowania do ciężkich bugów; Grok 4.6 (high/extra high) do codziennej rozmowy – prawie tak sprawny jak czołówka, a dwa razy tańszy i szybszy; Kimi K3 na front-end.
Jak stosować: Trzymaj własną mapę zadań i modeli. Gdy wychodzi ważna nowość, zarezerwuj pełną dobę i pracuj wyłącznie na niej – w swoich workflowach, nie na podstawie opinii z sieci. Przypadki użycia poznajesz tylko praktyką.
Na co uważać: Aplikacje producentów naturalnie spychają do własnych modeli – nie pozwól, by jedno środowisko zawęziło ci horyzonty. Pilnuj też, jaki model wykonuje delegowaną pracę: aplikacje chętnie zlecają podagentom słabsze modele – wybieraj sam.
8.Worktree dopiero od pewnej skali
Na czym polega: Worktree to kopia drzewa roboczego repozytorium w osobnym katalogu, z osobną gałęzią – agent pracuje w izolacji i nie kolizjonuje z innymi. W małych projektach to narzut; przy dużej równoległości – konieczność.
Jak stosować: Mały projekt albo mniej niż kilkanaście agentów naraz – zostań na jednej gałęzi. Średnie i duże repozytoria z dwudziestoma–trzydziestoma agentami non stop – zakładaj świeży worktree od origin/main per zadanie. Warto korzystać z interfejsu, który pamięta ustawienia worktree per repo (np. BB).
Na co uważać: Bez worktree przy dużej równoległości agenty będą sobie nadpisywać i cofać zmiany – gwarantowany chaos. W małym projekcie worktree to sztuka dla sztuki: dodatkowy bałagan bez korzyści.
9.Agent z dostępem tylko do odczytu do produkcyjnej bazy
Na czym polega: Rozwój sterowany użyciem: agent z rolą read-only na produkcyjnej bazie odpowiada w minuty na pytania, na które ręczna analiza danych potrzebowałaby godzin – co ludzie faktycznie używają, co robią zaawansowani użytkownicy, jakie błędy się powtarzają.
Jak stosować: Utwórz w bazie (np. Postgres) dedykowaną rolę wyłącznie do odczytu i podłącz do niej agenta. Przed budową nowej funkcji rób zderzenie z rzeczywistością: czy jest w ogóle używana, czy warto szlifować jej interfejs. Śledź różnice między użytkownikami, którzy zostają, a tymi, którzy odchodzą.
Na co uważać: Nigdy pełny dostęp do zapisu – 99,9% czasu przejdzie gładko, ale jedna nieodwracalna operacja (skasowany użytkownik, wyczyszczona tabela) przekreśli wszystkie oszczędności. Zerowy dostęp to jednak też błąd: tracisz najszybsze źródło wiedzy o produkcie.
10.ADR-y: zostaw kontekst w repozytorium
Na czym polega: Architecture Decision Records to krótkie notatki w katalogu /doc/adr dokumentujące kluczowe decyzje wraz z uzasadnieniem i stanem projektu z chwili wyboru. Dzięki temu nowy agent lub człowiek rozumie kod od razu, a nie po tygodniu archeologii.
Jak stosować: Zakładaj katalog na starcie projektu. Po każdej ważnej decyzji zapisz prostym markdownem: co wybrano, dlaczego, w jakim kontekście. Agentom wskazuj ten katalog jako punkt wejścia – natychmiast pojmą wszystkie ustalenia.
Na co uważać: Nie wszystko da się wyczytać z kodu – brak ADR-ów to trwale utracony kontekst. Trzymaj się prostego formatu; korporacyjna ceremonia zabija tę praktykę szybciej niż cokolwiek innego.