O czym jest ten film
- Rozmowa z byłym starszym inżynierem (poziom L8 / principal) z Meta, Microsoftu i Atlassiana o jego codziennym setupie do programowania z agentami AI.
- Cały workflow działa w terminalu — frameless okno, terminal WezTerm i multiplekser Herder, który „rozumie” agentów i pozwala łączyć się z tą samą sesją z telefonu przez SSH.
- Sercem systemu jest First Mate — jeden agent-orkiestrator, do którego mówi się głosem, a on deleguje zadania do wielu „crewmate’ów”, eliminując ręczne żonglowanie 20–30 sesjami.
- Autor niemal nie pisze już kodu ręcznie; punktem przełomowym było wprowadzenie modelu Sonnet 3.5 v2, pierwszego agenta zdolnego samodzielnie wykonać zadanie.
- Do skomplikowanych decyzji projektowych używa narzędzia Lavish, które generuje interaktywne artefakty HTML (drzewa, tablice) zamiast ścian tekstu w terminalu.
- Dobór modeli i „reasoning effort” jest zapisany w regułach: na co dzień GPT 5.6 „Soul” na x-high, do najbardziej kreatywnych zadań projektowych — Fable.
- Narzędzie No Mistakes przepuszcza zmiany kodu przez pipeline: analiza intencji, rebase, adwersaryjna recenzja (najlepiej GPT), testy z dowodami, dokumentacja i pilnowanie CI.
- Głównym wąskim gardłem nie jest już pisanie kodu, lecz jego recenzja i limity tokenów z subskrypcji — autor apeluje o wyższy tier (500 $) i tańszy, wolniejszy tryb dla zadań w tle.
- Autor promuje axi — zasady budowania interfejsów CLI zoptymalizowanych pod agentów (np. wyjście token-efficient zamiast JSON), pokazując, że są tańsze i skuteczniejsze niż serwery MCP.
- Teza końcowa: większość oprogramowania SaaS zostanie przebudowana pod agentów (headless), a interfejsy dla ludzi w dużej mierze znikną.
Redakcyjne tłumaczenie
(Informacja dodatkowa: rozmówcą Davida Ondreja jest inżynier o pseudonimie Kun — w transkrypcie zapisywany fonetycznie jako „Coon”. Poniżej zachowano układ wywiadu z etykietami mówców. Wiele nazw narzędzi to autorskie projekty gościa: First Mate, No Mistakes, Lavish, axi, baby menu.)
Punkt wyjścia: jeden agent zamiast trzydziestu sesji
Kun: Pracuję w bezramkowym oknie terminala. Używam WezTerm, bo jest wyjątkowo konfigurowalny — mogę zmienić w nim praktycznie wszystko. W środku mam sesję Herdera. Herder to taka nowocześniejsza wersja tmuksa. Tmuksa używałem przez ponad dekadę, a Herdera odkryłem dopiero niedawno i bardzo mi się spodobał. To świeższe podejście do zarządzania wieloma sesjami w oknie terminala. Wszystko działa na moim Mac Mini, a do tej samej sesji mogę się podłączyć z telefonu — biorę telefon, łączę się przez SSH i mam dokładnie to samo okno terminala.
Dobrą stroną Herdera jest to, że rozumie, czym są agenci. Żeby wykonać więcej pracy, ludzie muszą zarządzać wieloma równoległymi sesjami agentów — bo pojedynczy agent potrzebuje czasu na wykonanie zadania. Ludzie zaczynają więc odpalać kolejne sesje i widuję osoby z 20, 30 sesjami naraz. Sam zaczynałem od tego wariować, bo te dwadzieścia sesji trzeba trzymać w głowie.
Ten ból skłonił mnie do zbudowania First Mate. Nie sądzę, żeby żonglowanie kartami było docelowym stanem. Nie chcę spędzać całego dnia na przeskakiwaniu między zakładkami i pamiętaniu, co było czym. Zbudowałem First Mate, bo uważam, że agenci — w miarę jak stają się coraz zdolniejsi — powinni żonglować tym wszystkim za mnie. Eksperymentuję z tym układem od kilku miesięcy i naprawdę działa. Teraz to jedyny agent, z którym rozmawiam przez większość czasu.
David: Byłeś elitarnym inżynierem w elitarnych firmach — Meta, Microsoft, Atlassian. Jak wygląda twój obecny setup do programowania z AI?
Kun: Używam AI praktycznie do napisania wszystkiego, co chcę zbudować. Bardzo rzadko piszę teraz kod ręcznie.
David: A kiedy to się zmieniło?
Kun: To był proces stopniowy. Jakieś trzy lata temu mieliśmy GitHub Copilot — uzupełnianie kodu. Zaczynaliśmy od brania podpowiedzi linijka po linijce, potem zaczął podpowiadać wiele linii, całą funkcję naraz. Punktem przełomowym, który zmienił ten stan rzeczy, było wprowadzenie modelu Sonnet 3.5 v2 — to był moment, który zmienił reguły gry. Po raz pierwszy agent potrafił wziąć zadanie i zacząć coś dla nas robić, a potem wrócić z kompletnym zestawem wyników. Wtedy zacząłem pracować z agentami. Pracowałem wówczas w Atlassianie, a moim zadaniem było rozwijanie agentów kodujących, więc dużo bawiłem się modelami. Testowałem różne — od GPT 3.5, które po prostu nie działało; poproszenie go o edycję pliku to już był spory kłopot. GPT-4 był trochę lepszy, ale wciąż niewystarczający. Dopiero Sonnet 3.5 v2 naprawdę zmienił zasady gry. Kilka takich punktów przełomowych mocno przebudowało mój sposób pracy przez ostatnie trzy lata.
Terminal jako podstawowe środowisko
David: Czy jesteś człowiekiem terminala, czy GUI?
David (o sobie): Ja jestem hybrydą — są tygodnie, gdy używam tylko terminala, i tygodnie, gdy siedzę w aplikacji Codex albo w oknie agentów Cursora.
Kun: Ja jestem bardziej po stronie terminala. Staram się używać go jako podstawowego środowiska. Zbudowałem sobie w nim ogromną pamięć mięśniową — pracuję w terminalu od ponad dwóch dekad. Ten nawyk sprawia, że mam dłonie na klawiaturze praktycznie cały czas.
David: Co powiedziałbyś ludziom, którzy boją się terminala — może nie są programistami, nie są zbyt techniczni?
Kun: Na początku jest krzywa uczenia się, żeby przywyknąć do innego sposobu pracy, w którym klawiaturą kontrolujesz wszystkie ruchy w terminalu. Początkowo poczujesz spadek produktywności, bo nie jesteś jeszcze wprawny. Ale kiedy przez to przejdziesz, terminal utrzymuje cię w przepływie — masz dłonie na klawiaturze, wszystko kontrolujesz skrótami, a jedyne, co płynie, to twoje myśli.
(Informacja dodatkowa: w tym miejscu w nagraniu pojawia się blok reklamowy narzędzia Code Rabbit — automatycznego recenzenta kodu podłączanego do repozytorium, uruchamiającego ponad 40 linterów i skanerów bezpieczeństwa. Treść pomijamy jako materiał sponsorowany.)
First Mate: agent, który zarządza innymi agentami
Kun: W sesji Herdera po lewej u góry widać „spaces” — to jak przestrzenie robocze, którymi organizuję różne projekty. Na dole po lewej są agenci. Poprzednie multipleksery, jak tmux czy Zellij, nie rozumiały agentów — znały twoje okna, zakładki i panele, ale nie wiedziały, czym jest sesja agenta. Herder wie, że mam tu pracującego agenta. Status „working” mówi mi, że nie muszę na niego patrzeć — wciąż pracuje, nie czeka na mnie. To bardzo przydatne.
Przez większość czasu pracuję jednak na jednej sesji — First Mate. To workflow, który rozwinąłem kilka miesięcy temu, gdy zdałem sobie sprawę, że cały czas zarządzam mnóstwem sesji. Podobnie dzieje się u ludzi używających innych narzędzi do orkiestracji — żeby wykonać więcej pracy, muszą prowadzić wiele równoległych sesji. Widuję osoby z 20–30 sesjami. Trzeba je wszystkie pamiętać: co to za sesja, co robi. Ten ból skłonił mnie do zbudowania First Mate. Teraz rozmawiam tylko z First Mate i pozwalam mu zarządzać wszystkimi innymi sesjami.
Pokażę przykład. Coś się już dzieje — pracuje, mówi mi, że nie są potrzebne żadne działania. Zastanawiam się nad pracą sprzed jakiegoś czasu, więc pytam: „Hej, czy Apple zatwierdziło recenzję naszej aplikacji?”. To aplikacja na iOS, którą zgłosiłem do App Store. First Mate nie zrobi tego sam — zdeleguje zadanie do innego crewmate’a. Bo gdyby zrobił to sam, byłby zajęty i nie mógłbym z nim znów rozmawiać. Widzisz: „Kapitanie, sprawdzam” — poprosił innego członka załogi. Dzięki temu mogę mówić do First Mate dalej, bez blokowania. Pytam więc od razu o coś innego: „Pamiętam, że w Treehouse czekają na mnie jakieś PR-y do recenzji. Sprawdzisz?”.
David: Czyli First Mate ma dostęp do wszystkich projektów, nad którymi pracujesz?
Kun: Tak, to koordynator wszystkiego. Zna wszystkie moje projekty. Mam jakieś 20–30 publicznych repozytoriów na GitHubie, które cieszą się pewną popularnością — ludzie zgłaszają issues i PR-y. Gdybym miał ręcznie żonglować tymi wszystkimi projektami, zwariowałbym. Pozwalam więc First Mate zarządzać nimi wszystkimi. Kiedy mówię „Treehouse”, First Mate wie, o który projekt chodzi.
David: Jak zbudowałeś na tyle duże zaufanie, żeby oddać First Mate tyle odpowiedzialności?
Kun: Zaufanie buduje się z czasem — nie ufałem mu od razu we wszystkim. Zaczynałem od prototypu i stopniowo pozwalałem mu robić coraz więcej, obserwując, jak sobie radzi. Na początku było wiele problemów: delegował niewłaściwe zadania do niewłaściwych crewmate’ów albo kilku z nich robiło to samo, wchodząc sobie w drogę. Optymalizowałem proces coraz bardziej i w końcu doszedłem do słodkiego punktu, w którym First Mate obsługuje to wszystko za mnie i nie widzę już błędów ani nieoptymalnego rozdzielania zadań.
Najlepsze uczucie, jakie mam teraz przy pracy, to bycie stale w trybie „zrzucania myśli”. Mam jakąś myśl i po prostu zrzucam ją do First Mate, a on zajmuje się resztą. Nie muszę martwić się o kroki, które trzeba wykonać.
David: Czy zaglądasz czasem do konkretnych sub-agentów, żeby zobaczyć, co robią?
Kun: Teraz bardzo rzadko. Na początku, gdy rozwijałem First Mate, robiłem to często — żeby obserwować, czy dobrze przekazuje kontekst crewmate’om. Teraz robię to rzadko. Czasem jednak czuję: „dlaczego to tak długo trwa?”. To jak praca w prawdziwej firmie — czasem menedżer idzie bezpośrednio do podwładnego, omijając tech leada, bo tak jest szybciej. W Herderze mogę wywołać widok, który pozwala przeskoczyć do dowolnej innej sesji agenta i zobaczyć, co się tam naprawdę dzieje.
Lavish: projektowanie na interaktywnych artefaktach
Kun: First Mate odpowiedział na moje ostatnie pytanie. Jesteśmy przy ważnym punkcie decyzyjnym w projekcie. Omawiałem kiedyś pewien pomysł, ale nie przeszliśmy do implementacji, bo nie byłem pewien podejścia — coś mi nie grało. Przy takim projekcie technicznym, który bywa złożony, ma wiele ruchomych elementów i kompromisów, zwykle używam narzędzia Lavish — interaktywnego artefaktu HTML, który pozwala mi łatwiej zrozumieć pomysł i jego kompromisy.
Pytam więc: „Czy możesz użyć Lavish, żeby przejrzeć ze mną projekt przestrzeni roboczych w Herderze?”. First Mate stworzy artefakt HTML z wizualizacjami decyzji projektowych, dzięki czemu łatwiej będzie nam współpracować. To potrwa chwilę.
David: Pisałeś teraz na klawiaturze, ale jesteś zwolennikiem mówienia. Kiedy używasz którego?
Kun: Prawie zawsze używam wejścia głosowego. Pisałem, bo zauważyłem, że wejście głosowe jakoś zakłóca mój mikrofon i jeszcze tego nie naprawiłem. Ale zwykle promptuję głosem. Jedyny wyjątek to sytuacje, gdy muszę wkleić URL, ścieżkę pliku i tak dalej — wypowiadanie tego na głos nie ma sensu.
Dobór modeli i problem limitów
David: Używasz modelu 5.6 jako głównego agenta. Dlaczego?
Kun: Tak, GPT 5.6 „Soul” na x-high jako First Mate. Nauczyłem się, że First Mate żongluje ogromnym kontekstem — musi racjonalizować wiele rzeczy, na przykład o czym w ogóle mówię. Kiedy mówię „widok przestrzeni roboczych w Herderze”, musi wiedzieć, że pracowaliśmy nad tym jakiś czas temu i o to mi chodzi. First Mate potrzebuje więc dużo rozumowania.
Mam różne reguły dla różnych crewmate’ów. Gdy First Mate rozdziela zadanie, korzysta z zestawu preferencji, które mu podałem — w tym pliku zapisuję reguły mówiące, w jakim przypadku którego agenta, którego modelu i na jakim poziomie rozumowania użyć. Wcześniej była tu reguła: dla każdego projektu technicznego czy produktowego o wysokiej złożoności używaj Fable w Claude Code. Fable ma głębię i kreatywność, które naprawdę lubię. Ale domyślnie teraz korzysta z 5.6.
David: Czyli czysto z powodów praktyki subskrypcyjnej?
Kun: Mam narzędzie śledzące moje limity. Wyczerpałem już limit Grока i czekam na reset. Kończy mi się też limit Fable w tym tygodniu, a reset jest jeszcze daleko, więc oszczędzam resztki na rzeczy, do których naprawdę potrzebuję Fable. Limity LLM z subskrypcji po prostu nie wystarczają. Zasugerowałbym firmom od LLM-ów, żeby wprowadziły wyższy tier — obecny tier 200 $ jest niewystarczający.
David: Zgadzam się. Ludzie tego nie polubią, ale potrzebujemy tieru za 500 $.
Kun: Dla osób indywidualnych rozliczanie się według cennika API nie ma sensu. Gdybym policzył ceny API za wszystko, co zrobiłem przez ostatni miesiąc, wyszłoby ponad 10 000 dolarów. To nie jest do utrzymania. Inna rzecz: wiele modeli — GPT 5.5, 5.6, modele od Anthropic — ma tryb szybki, który kosztuje więcej za niższą latencję. Ja chcę czegoś odwrotnego: wolniej, ale taniej. Bo mam mnóstwo zadań w tle, przy których nie zależy mi na szybkim ukończeniu. Zależy mi na tym, ile pracy wykonam łącznie, bo moim wąskim gardłem jest teraz całkowity limit.
David: Różne zadania wymagają różnych ustawień. Jeśli masz ważne spotkanie za 10 minut i transkrypt z zeszłego tygodnia — potrzebujesz trybu szybkiego. Ale jeśli odpalasz agenta na noc, potrzebujesz najwolniejszego z wolnych trybów. Nie obchodzi cię, czy to pięć tokenów na sekundę — po prostu chcesz, żeby było zrobione.
Wizualne przeglądanie decyzji projektowych
Kun: To jest ten projekt organizacji Herdera, o który pytałem wcześniej — chodzi o to, jak First Mate używa Herdera do porządkowania crewmate’ów. Teraz wszystko jest płaską listą i czasem trudno zrozumieć, który agent co robi. Lavish wygenerował artefakt z rekomendacją. Pokazuje mi hierarchię w postaci widoku drzewa — inaczej w terminalu dostałbym długą ścianę tekstu. Tutaj widzę wizualnie strukturę: jak różne drzewa robocze grupują się według repozytoriów, i jest rekomendowana architektura.
Lavish potrafi też kazać agentowi wyprodukować tablicę — to whiteboard w stylu Excalidraw, na którym oglądam diagramy. Mogę je dostosować, przesuwać pola, powiedzieć „to nie jest właściwe” i odesłać feedback do agenta. Na koniec zwykle wskazuje decyzje, które muszę podjąć, i otwarte pytania. Ma kilka podejść — muszę wybrać jedno. Chcę priorytetowo potraktować własność po stronie supervisora, bo wtedy grupowanie ma większy sens. Zakolejkuję tę decyzję i odeślę do agenta. I tyle — tak wygląda proces podejmowania takiej decyzji.
Głęboka praca i granica autonomii
David: Skoro jest tyle kontekstu i projektów, jak wciąż osiągasz głęboką pracę? Jak wchodzisz w przepływ, nie wariując od ciągłego „ciekawe, jak idzie tamten projekt”?
Kun: Czas, który spędzam z First Mate, idzie głównie na dwuznaczne decyzje. Nie przeskakuję między kartami ani nie zastanawiam się, czy tamta praca wciąż trwa. Jedyne, na co poświęcam czas, to naprawdę niejednoznaczne decyzje, które wymagają mojego osądu. Przez cały dzień robię więc dwie rzeczy. Pierwsza: zrzucam myśli do First Mate — cokolwiek chcę zrobić, po prostu mu mówię i mogę o tym zapomnieć. Albo zostanie to zrobione, albo wróci do mnie jako decyzja do podjęcia. Druga: zajmuję się decyzjami, których First Mate nie może rozstrzygnąć sam.
Mam mnóstwo instrukcji dla First Mate, kiedy powinien wrócić do mnie — to bardzo trudne do dobrego ustawienia. Czasem widzimy, jak agenci szaleją i robią autonomicznie mnóstwo rzeczy bez naszego nadzoru, a na koniec okazuje się, że zrobili coś nie tak. To jedna z rzeczy, które musimy dostroić w zachowaniu agentów — gdzie leży słodki punkt. Każdy może mieć nieco inną preferencję, więc trzeba to przegadać ze swoim agentem.
David: Ile tokenów zużywasz w typowy dzień?
Kun: Nie liczę tokenów — liczę raczej, ile procent limitu zużywam. Staram się utrzymać dobry balans. Wyczerpałem limit Claude szybciej, niż powinienem, bo Anthropic powiedział nam, że Fable zniknie.
(Informacja dodatkowa: w tym miejscu rozmówcy żartobliwie krytykują komunikację Anthropic — cotygodniowe „przedłużenia” dostępu do modelu Fable zamiast jasnej decyzji o zachowaniu lub usunięciu, oraz brak „bankowanych” resetów limitu w stylu OpenAI. Padają hiperboliczne, niepotwierdzone anegdoty o osobach rzekomo trafiających do szpitala po dwóch dobach bez snu — należy je traktować jako przesadzony żart, nie fakt.)
Kun: Przejrzystość to coś, z czym Anthropic naprawdę się zmaga. Sposób, w jaki komunikowali wiele dużych zmian, po prostu nie był wystarczająco przejrzysty, by dać ludziom jasność do podejmowania decyzji. Widżet limitów służy mi do trzymania oka na zużyciu, żeby być w dobrym tempie względem resetów. Przy OpenAI mogę być trochę bardziej agresywny, bo mam kilka resetów do wykorzystania.
Dlaczego GPT 5.6 „Soul” i jak modele marnują tokeny
David: Ale czy nie zauważyłeś, że GPT 5.6 „Soul”, zwłaszcza na extra-high albo ultra, potrafi palić tokeny jak szalony — przynajmniej w pierwszych 24–48 godzinach?
Kun: Było kilka rzeczy. W pierwszych dniach OpenAI popełniło błąd — ustawili próg kompaktowania kontekstu dla 5.6 na 372 tys. tokenów, a potem zorientowali się, że każde żądanie powyżej 272 tys. tokenów jest zawyżanie liczone. Ludzie palili więc tokeny szybciej, niż powinni, i firma zrobiła za to reset. Naprawiają to.
Druga sprawa: „ultra” to przypadek szczególny. Ultra i „ultra code” w Claude to niekoniecznie poziom rozumowania — to prompt, który każe agentowi agresywnie korzystać z sub-agentów, rozdzielać zadania. Przez pewien czas Codex od OpenAI przy trybie ultra odpalał tyle sub-agentów, że każdy z nich był agentem ultra — to pali tokeny stanowczo za szybko. X-high i high są bardzo różne. X-high nie pali tokenów tak szybko i jest moim słodkim punktem, bo mimo poziomu x-high jest całkiem szybki — prompty, przez które właśnie przeszliśmy, wracają dość szybko.
David: Wczoraj testowałem z kilkoma osobami — mieli włączony 5.6 „Luna” i było wolno. Przełączyli na 5.6 „Soul” medium i było szybciej. Luna jest teraz wolniejsza niż Soul.
Kun: Pokażę benchmark o nazwie DeepU — chyba go znasz. To obecnie benchmark, któremu ufam najbardziej, bo nie jest jeszcze skażony: jest na tyle nowy, że dane treningowe go nie zawierają. Widać kilka interesujących wyjątków. Jeśli spojrzysz na Sonnet 5 od low, przez medium, high, do x-high — to rozsądna krzywa. Lewa strona wykresu to droższe modele, góra to bardziej inteligentne, więc prawy górny róg jest dobry. Sonnet 5 jest rozsądny aż do x-high, ale przy „max” krzywa szaleje — to najdroższy model, jaki istnieje, droższy od Fable.
Myślę, że dzieje się tak, bo gdy model sam w sobie nie jest wystarczająco inteligentny, marnuje mnóstwo cykli na robienie niewłaściwych rzeczy. Zwłaszcza gdy każesz mu rozumować na maksa — myśli bardzo długo, ale wciąż nie jest dość inteligentny, żeby rozwiązać problem, więc marnuje czas i tokeny. Podobnie jest z Luną. Luna ma bardzo „wysoką” krzywę — rozciąga się od bardzo niskiej do bardzo wysokiej inteligencji. Jeśli poprosisz Lunę o trudny problem, którego nie potrafi rozwiązać, zmarnuje mnóstwo tokenów na próby.
David: Dokładnie to zaobserwowałem — wykonała za dużo wywołań narzędzi, żeby osiągnąć coś względnie prostego, a 5.6 „Soul” na medium zrobił to w minutę.
Kun: Właśnie. Dlatego na co dzień używam praktycznie tylko „Soul” — mogę regulować poziom rozumowania. Widzę mało powodów, by używać „Terra”: po co, skoro mogę obniżyć rozumowanie w „Soul” i dostać bardziej inteligentny model taniej? Luny używam w niektórych przypadkach — w moim asystencie domowym, który steruje światłem, muzyką itd. Tam potrzebuję, żeby był naprawdę szybki.
David: Dlaczego nie model open source, np. na OpenRouterze z 200–300 tokenami na sekundę?
Kun: Do scenariusza asystenta domowego mógłbym coś uruchomić lokalnie na Mac Mini i działałoby rozsądnie. Problem w tym, że mój Mac Mini to bardzo cenny zasób — robię na nim wszystko inne: buduję aplikacje na iOS, podłączam telefon, to moja osobista maszyna obliczeniowa. Model open source konkurowałby o zasoby z całą resztą. Mógłbym też uruchamiać modele open source u dostawców chmurowych, ale oszczędność nie jest dla mnie na tyle znacząca, żeby przesiadać się z czegoś takiego jak Luna. Jak dotąd nie wsiąkłem mocno w lokalne LLM-y i modele open source.
Harness: dlaczego Pi, Grok jak „Opus na trybie szybkim”
David: A co do harnessu — czy Pi jest teraz twoim ulubionym?
Kun: Używam kilku. Pi — bo głównie pracuję dziś z GPT 5.6 z powodu limitów. Zasada jest taka: gdy używam modeli Anthropic, korzystam z Claude Code, bo oni blokują wszystko inne; gdy używam GPT 5.6, korzystam z Pi. Codex CLI nie jest tak dobrym harnessem — ma pewne mocne strony, np. wbudowaną integrację z generowaniem obrazów, co jest wygodne, ale wiele innych rzeczy, jak zarządzanie procesami w tle, wypada gorzej. Pi jest za to wysoce konfigurowalny — do praktycznie każdej potrzeby mogę zbudować wtyczkę.
Używam też Grока, bo mam już subskrypcję X i jest tam trochę limitu. Grok 4.5 jest naprawdę dobry — myślę o nim jak o Opusie na trybie szybkim. Jest tak zdolny jak Opus i superszybki.
David: Ja jestem w UE, więc nie mogę go używać — jest tam zablokowany.
Kun: Ciekawe jest to, że harness Grok Build wydaje się dawać darmowy dostęp do API X — do czytania, postowania i wyszukiwania — co inaczej kosztuje. Mogę więc używać Grok Build do wyszukiwania tweetów i racjonalizowania newsów. To jeden z najszybciej poprawiających się harnessów — bardzo młody, a już ma lepsze możliwości niż Codex przy odpytywaniu procesów w tle. Używam też sporo Open Code — TUI jest tam przyjemne. Ale z czasem coraz bardziej skłaniam się ku Pi, bo jest głębiej konfigurowalny.
Oprogramowanie, które modyfikuje samo siebie
David: Jesteś fanem konfigurowalności. Czy w przyszłości coraz więcej ludzi będzie miało własne setupy zamiast gotowych, spakowanych aplikacji?
Kun: Prawdopodobnie powstanie spektrum preferencji. Będzie grupa osób mało zaangażowanych w to, jak coś ma działać — chcą sprawdzonych, gotowych rozwiązań, żeby nie musieć majstrować przez cały dzień. Ta grupa zawsze będzie istniała i ludzie będą dla niej budować gotowe narzędzia. Będzie też druga grupa z coraz silniejszymi osobistymi preferencjami — ci będą potrzebować rzeczy, które da się głęboko dostosować i które ewoluują.
Pokazywałem wcześniej widżet limitów na pasku menu — nazywam go „baby menu”. Zbudowałem go sam i potrafi się sam modyfikować. Widać tam rzeczy, które nigdy nie istniałyby razem w jednym produkcie: statystyki GitHuba, zużycie CPU i pamięci, moje limity Claude i Codex. Nikt nie zbuduje takiego produktu i nie sprzeda go innym — to należy do mnie. Doprowadziłem go do tego stanu, rozmawiając z nim: „baby menu” zaczęło jako pusta rzecz, mówiłem mu, czego chcę, a ono samo się modyfikowało. To jedna z wersji przyszłości oprogramowania: dostajesz rozsądne doświadczenie „z pudełka”, ale każdy ma teraz agenta, więc każdy może rozmawiać ze swoim agentem i dostosowywać używane oprogramowanie.
David: Plus pętle samonaprawcze — łatwe zgłoszenie błędu, które odpala Codex CLI, wdraża poprawkę, otwiera PR, coś w rodzaju Code Rabbit go recenzuje i błąd zostaje naprawiony w 20 minut bez udziału człowieka.
Kun: Dokładnie. First Mate to w istocie plik agents.md, który opisuje, jak First Mate ma się zachowywać i koordynować zadania między wieloma crewmate’ami. Ma też folder ze skryptami bashowymi obsługującymi kroki deterministyczne, które First Mate musiałby inaczej wykonywać ręcznie — pakuję je w skrypty, żeby nie marnował na nie tokenów. Zarówno agents.md, jak i skrypty są w bieżącym katalogu, więc First Mate może je modyfikować.
Nie spodziewałem się jednej rzeczy: gdy First Mate ma błąd uniemożliwiający mu poprawne wykonanie czegoś, po prostu sam go obchodzi. To oprogramowanie stało się w zasadzie nie do zatrzymania. Nie da się go powstrzymać przed wykonaniem tego, co ma zrobić. Nawet jeśli skrypty mają błędy, mogą go co najwyżej spowolnić, ale nie zatrzymają. To ogromna zmiana względem tradycyjnego oprogramowania, gdzie błąd potrafi zawiesić aplikację i nie da się przez niego przejść. Teraz mamy inteligentne oprogramowanie, które jest zawsze elastyczne — bardzo trudno napisać błąd, który je zatrzyma. Wyzwaniem staje się więc: gdzie my, ludzie, spowalniamy agentów i jak usunąć siebie z jak największej liczby tych miejsc, angażując się tylko w to, co naprawdę ważne.
No Mistakes: pipeline, który pilnuje jakości kodu
David: Co jeszcze warto wiedzieć o twoim setupie?
Kun: Może „No Mistakes”. Bardzo często AI generuje mi kod — Fable i 5.6 piszą szybko, dobrze, potrafią złożone zmiany. Ale jeśli AI zrobi złożoną zmianę, skąd mam wiedzieć, że można ją bezpiecznie zmergować?
Pokażę realny przykład — projekt „High Bit”, harness AI, który buduję dla dzieci uczących się korzystać z agentów. Wczoraj Fable wprowadził tu sporo zmian. Oto diff. Co teraz robię? Czy mam recenzować każdą linijkę? To zajmie mnóstwo czasu, a nasz czas jest ograniczony. Jeśli recenzuję kod generowany przez AI, istnieje górna granica tego, ile pracy jestem w stanie wykonać — zależy od tego, ile kodu zrecenzuję dziennie bez utraty zmysłów.
Zamiast tego wysyłam wszystkie te zmiany do No Mistakes, które wykonuje pipeline z recenzją adwersaryjną i walidacją i przedstawia mi coś, na podstawie czego łatwiej ocenię, czy jest w porządku. Robię to komendą nm -y — skrót od „no mistakes” — która bierze wszystkie zmiany z bieżącego katalogu roboczego, wrzuca je do brancha i przekazuje do No Mistakes. Narzędzie tworzy branch i commit, wrzuca wszystkie potrzebne informacje, po czym wypycha branch do lokalnego proxy Git, gdzie przeprowadza walidację w izolowanym drzewie roboczym.
Pipeline działa tak. Najpierw analizuje intencję — a rozumie ją, analizując sesję agenta, która wyprodukowała zmianę. W tej sesji pracowałem z Fable, wyraziłem tam swoją pierwotną intencję. To krok kluczowy, bo intencja jest prawdziwym wymaganiem, które trzeba uszanować. Potem robi rebase na najnowszym main z origin, żebyśmy nie wpadli później w konflikty scalania. Następnie robi recenzję adwersaryjną — tu używa GPT 5.6 „Soul” na medium. Jeśli coś znajdzie, albo autonaprawi (jeśli to oczywisty błąd), albo eskaluje do mnie po akceptację (jeśli nie jest oczywiste lub ma implikacje produktowe). Bo czasem naprawa błędu wymaga zmiany produktu — w takich przypadkach chcę mieć głos, więc ustawiam reguły, by eskalować je do mnie.
Krok recenzji trwa chwilę i wyłapuje praktycznie wszystkie przypadki brzegowe, błędy i braki. Na koniec robi testy, które dają widoczny dowód, że wszystko naprawdę działa zgodnie z intencją, potem dokumentację, linting, wypycha PR i pilnuje pipeline’u CI, aż PR będzie zielony — a wtedy mówi mi, że mogę spojrzeć. Zwykle po uruchomieniu No Mistakes nie patrzę na ten widok — odchodzę i robię coś innego. Dziś nawet nie uruchamiam go sam — proszę First Mate. Gdybym nie używał czegoś takiego, moje bazy kodu absolutnie zamieniłyby się w bałagan.
Koszt jakości i kompromisy
David: Ale czy na dużym projekcie to nie pali za dużo limitów? Przypomina mi się DeepSack od Vercela z ostrzeżeniami, że na dużej bazie kodu spali dziesiątki tysięcy dolarów kredytów API, bo idzie tak głęboko. Jak balansujesz liczbę recenzji ze zużyciem?
Kun: Jest nieunikniony koszt jakości. Pomyśl o zespole: jeśli usuniemy proces recenzji kodu między ludźmi, wszyscy będą mergować szybciej, ale pojawią się problemy z jakością i incydenty na produkcji, za które i tak zapłacisz — tyle że inaczej. To część nieunikniona. Musimy zdecydować, jak bardzo zależy nam na jakości danego projektu. Jeśli to demo na weekendowy pokaz — nie ma to wielkiego znaczenia, można pominąć ciężką walidację. Ale jeśli budujesz oprogramowanie produkcyjne, na które wpływa wielu użytkowników i klienci, którzy przestaną płacić, gdy zepsujemy im doświadczenie — wtedy trzeba być ostrożnym. Jest więc kompromis: na których projektach stosować takie podejście.
Druga rzecz: nie wysyłam każdej zmiany do pipeline’u. Przy bardzo prostej poprawce, co do której jestem pewien, że niczego nie zepsuje, podejmuję decyzję: mergujemy. Ale zdecydowana większość moich zmian przechodzi przez pipeline.
Mam statystyki No Mistakes — z ostatnich mniej więcej trzech miesięcy: tysiąc zmian w 59 repozytoriach, 63% zmian dostało „mistake cut” (Informacja dodatkowa: w narzędziu autora oznacza to zmianę, w której pipeline wykrył i naprawił problem przed scaleniem).
David: Który etap procesu jest najskuteczniejszy — recenzja adwersaryjna innym modelem?
Kun: Etap recenzji wyłapał i naprawił najwięcej problemów. Zauważyłem, że mniej więcej od GPT 5.5 modele GPT stały się naprawdę dobre w wyłapywaniu przypadków brzegowych. Porównywałem kilka modeli — GPT lubię najbardziej jako recenzenta, jest bardzo dokładny i dobrze identyfikuje przypadki, które zdarzają się rzadko, ale jednak się zdarzają. Drugim mocnym graczem jest dokumentacja. Bardzo często agent wprowadza zmianę, ale nie aktualizuje np. pliku README, który dalej mówi coś nieaktualnego, sprzecznego ze zmianą — to wszystko wyłapuje ten etap.
Jak nie utknąć w budowaniu setupu zamiast produktów
David: Znam mnóstwo osób, które spędzają cały czas na swoim setupie — mają szalone agentowe systemy, ale nigdy niczego nie wypuszczają. Jak utrzymujesz rozsądny podział, żeby powiedzmy 10–20% czasu iść na ulepszanie setupu, a reszta na budowanie produktów?
Kun: Bardzo dobry temat — sam parę miesięcy temu się z tym zmagałem. Wszystko zajmuje czas: buduję coś, napotykam tarcie, chcę zbudować narzędzie, które je usunie, ale budowa narzędzia zabiera czas, a potem narzędzie ma problemy, które trzeba naprawić. Przez tydzień czy dwa zauważyłem, że pracuję głównie nad narzędziami, a nie buduję prawdziwych rzeczy.
To zmieniło się po tym, jak zacząłem używać First Mate. Rzeczy przyziemne — naprawa błędu, drobne usprawnienie — nie zajmują mi już czasu. Mówię First Mate: „jest problem”, a on go naprawia. To, co pochłania mój czas, naturalnie ciąży ku bardziej interesującym i niejednoznacznym decyzjom, którymi zwykle jest rozwój nowego produktu. Dzięki temu, że First Mate zarządza przyziemnymi rzeczami, mam więcej czasu na produkty, które chcę budować — jak High Bit czy moja aplikacja na iOS. Tego nie planowałem — to wyłoniło się samo po wdrożeniu First Mate.
David: Odświeżające jest to, że wiele z tych rzeczy wyłania się z realnych problemów. Duży odsetek ludzi w przestrzeni AI robi rzeczy dla samego robienia — „połączyłem to, zbudowałem tamto, zobacz, ile agentów odpala” — ale to nie płynie z pierwszych zasad, nie z realnej potrzeby.
Kun: To zdecydowanie moje podejście. Początkowo w ogóle nie chciałem budować tych narzędzi. Trzy miesiące temu rzuciłem pracę w big techu, żeby działać solo — chciałem zbudować kilka aplikacji B2C z potencjałem, jak tutor AI dla dzieci. To był plan. Ciekawe w pracy solo — w przeciwieństwie do dużej firmy — jest to, że w korporacji jest mnóstwo innych wąskich gardeł: spędzasz czas na spotkaniach, koordynacji z ludźmi. Doszedłem do dość wysokiego szczebla i cały mój czas szedł na mówienie innym, co mają robić, zamiast na robienie samemu.
Solo nie mam tych wąskich gardeł — jedynym wąskim gardłem jestem ja sam. Zacząłem więc napotykać problemy: jak walidować kod generowany przez AI, jak planować z AI bardziej interaktywnie zamiast czytać ściany tekstu w terminalu, jak żonglować 20–30 sesjami bez wariowania. Zostałem zmuszony do zbudowania tych narzędzi, bo nic innego nie rozwiązywało tego dobrze. Tak przypadkiem stałem się maintainerem open source — teraz muszę balansować czas między utrzymaniem open source a pierwotnym planem budowania własnych aplikacji.
Przyszłość: oprogramowanie przebudowane pod agentów
David: Szerokie pytanie: jakie typy oprogramowania spodziewasz się, że się zmienią, a co zostanie?
Kun: Dzieje się kilka dużych trendów. Większość oprogramowania — zwłaszcza SaaS budowany przez ostatnie dwie dekady — powstała dla ludzi. To w istocie interfejs dla człowieka podłączony do bazy danych z jakimś skalowalnym systemem z tyłu. Część z interfejsem dla człowieka w dużej mierze zniknie. Nie chcemy przeklikiwać się samodzielnie przez Salesforce i inne strony SaaS — przez większość czasu chcemy, żeby robiły to nasze agenty, a agenty potrzebują innego interfejsu. Nastąpi więc wielka przebudowa wielu tych usług, żeby stały się bardziej headless — pozbyły się warstwy interfejsu dla człowieka albo zmieniły ją tak, by człowiek mógł współpracować z AI. Oprogramowanie, które daje agentom naprawdę dobre interfejsy, pozostanie. Kto wygra wyścig o miano nowego GitHuba, musi to opanować: musi to być usługa headless, którą agenty potrafią obsługiwać, a nie strona, przez którą ludzie muszą się przeklikiwać.
David: Jak to wygląda w praktyce? Lepsza dokumentacja, stabilne schematy API? Co naprawdę ma znaczenie dla agentów?
Kun: Pokażę stronę axi.md. Zacząłem wchodzić w to, gdy budowałem narzędzia dla agentów. Zauważyłem, że wiele narzędzi — w tym serwery MCP i CLI — nie było zoptymalizowanych pod agentów. Weźmy serwery MCP. Wiele firm wciąż uczy się budować dobre interfejsy dla agentów, więc część serwerów MCP jest naprawdę mało wydajna. GitHub — wprost ich wskażę — ma chyba najbardziej niewydajny i zbędny serwer MCP, bo GitHub ma naprawdę dobre CLI, którym agenty załatwią większość pracy. Po co nam serwer MCP?
Zrobiłem benchmarki. Dla tych samych zadań — jeśli zmienimy tylko interfejs, jak bardzo to ma znaczenie? Widać: przy GitHub CLI to średni koszt operacji; przy serwerze MCP jest kilka wariantów (bez „two search”, z „two search”, z „code mode”), ale zawsze wychodzi drożej niż CLI dla tej samej pracy. Podejścia oparte na MCP są wolniejsze, wymagają więcej tur, zużywają więcej tokenów — gorsze pod każdym względem. GitHub CLI jest lepiej zoptymalizowane, także dlatego, że istnieje długo i dane treningowe LLM-ów mają mnóstwo przykładów jego wydajnego użycia. Dla operacji GitHuba nie ma więc powodu, by używać MCP, poza pewnymi integracjami serwerowymi.
Rzecz z CLI jest taka, że większość z nich zaprojektowano pod pracę człowieka. Uznałem, że jest pole do poprawy, więc zbudowałem zestaw CLI dla agentów i wydestylowałem kilka zasad, które czynią CLI bardzo ergonomicznym dla agentów. Dowodem jest moje axi zbudowane według tych zasad — jest nawet tańsze niż GitHub CLI i ma wyższą skuteczność. Zrobiłem też axi dla Chrome DevTools, bo automatyzacja przeglądarki to bardzo częsty przypadek użycia. Zbenchmarkowałem popularne podejścia — serwer MCP Chrome DevTools, agent browser, dev browser — i zbudowałem axi Chrome DevTools jako wrapper na serwerze MCP Chrome DevTools. Nie ma różnicy funkcjonalnej: pod spodem to ten sam serwer MCP, zmieniłem tylko interfejs — a mimo to jest znacząco wydajniejszy: średni koszt spadł o ponad 20%, bez utraty czegokolwiek, i latencja też mocno się poprawiła.
Zasady wydestylowałem do dziesięciu — udokumentowanych na stronie axi.md jako publiczny zestaw standardów. Pierwsza: używaj wyjścia oszczędnego tokenowo. Wiele serwerów MCP i narzędzi CLI wypuszcza dane w JSON. JSON jest przydatny, gdy coś innego musi je sparsować w ustrukturyzowany sposób, ale agenty LLM tak nie parsują — potrzebują tylko zrozumieć treść i semantykę danych. Format oszczędny tokenowo od razu oszczędza mnóstwo tokenów. Kolejna: minimalny domyślny schemat — niektóre narzędzia CLI zwracają dosłownie każdą kolumnę i pole, gdy prosisz o dane.
Mam już kilka opublikowanych axi — GitHub axi, Chrome DevTools axi, samo Lavish jest axi, a niedawno opublikowałem też quota axi, które udostępnia agentom dane o limitach — po to, by First Mate był mądry i nie używał crewmate’ów opartych na subskrypcji, której limit jest prawie wyczerpany. Jest też sporo axi kontrybuowanych przez społeczność — npm, sqlite, wiele popularnych narzędzi ma już wersję axi. Osobom, które napotykają wąskie gardło wydajności tokenowej, zdecydowanie polecam sięganie po wydajniejsze narzędzia.
Dlaczego wielu ludzi tego nie widzi
David: Zgadzamy się chyba, że wkrótce 99,9% oprogramowania i narzędzi będą używać agenty, a my będziemy rozmawiać z naszym głównym agentem. Dlaczego tylu ludzi wciąż to omija — skupiają się na budowaniu UI dla człowieka i w ogóle nie myślą o backendzie ani CLI? Kiedy zrozumiałeś, że agenty będą obsługiwać całe oprogramowanie?
Kun: To krzywa uczenia się, którą widzieliśmy przy każdej transformacji technologicznej — rewolucje przemysłowe, silnik parowy, elektryczność, internet. Zawsze zaczyna się od małej grupy wczesnych adopterów, którzy po prostu lubią majstrować, bawić się technologią, nawet jeśli jeszcze się nie zwraca. Jesteśmy właśnie na tym etapie, gdzie część majsterkowania faktycznie się nie opłaci. Jest wiele projektów legacy, w których AI pomoże tylko do pewnego stopnia — pomoże, ale nie da tak dużego kopa jak w projektach green-field. Ludzie z tych domen, gdy spróbują AI, zobaczą, że „nie jest aż tak pomocne”, i to rozsądny argument. Ale to właśnie wcześni adopterzy — majsterkowicze bawiący się dla samej zabawy — wypracują to, co naprawdę zadziała: narzędzia, luki, sposoby pracy, które skorzystają z nowej technologii. I to zajmuje czas: wczesnym adopterom potrzeba czasu, by udowodnić, że coś jest dobre, przekuć doświadczenia w naprawdę dobre narzędzia, a innym — by przekonać się do nich i zacząć z nimi pracować. Rozsądnie jest oczekiwać, że nie stanie się to z dnia na dzień. Każdy jest w innej sytuacji, ma inne ograniczenia i projekty — to ukształtuje właściwy moment przejścia przez ten punkt przełomowy.
David: To świetny punkt na zakończenie. Co ludzie powinni sprawdzić?
Kun: Może mój GitHub, gdzie wypisałem mnóstwo zbudowanych i udostępnionych narzędzi — praktycznie wszystko udostępniam jako open source. Mam też kanał na YouTube z filmami pokazującymi dokładnie, jak koduję i jak używam moich narzędzi, żeby efektywnie budować nowe rzeczy. Jest też serwer Discord z pomocną społecznością, gdzie często rozmawiam z ludźmi.
David: Podlinkuję to wszystko poniżej. Dzięki, że wpadłeś.
Kun: Dzięki, że mnie zaprosiłeś.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Jeden agent-orkiestrator zamiast żonglowania sesjami
Na czym polega: Zamiast ręcznie zarządzać 20–30 równoległymi sesjami agentów, rozmawiasz tylko z jednym agentem-koordynatorem (u autora: First Mate), który sam deleguje zadania do „podwładnych” agentów i wraca do ciebie tylko z decyzjami wymagającymi osądu.
Jak stosować: Zbuduj lub skonfiguruj agenta nadrzędnego opisanego plikiem instrukcji (np. agents.md), który zna wszystkie twoje projekty. Kluczowa zasada: orkiestrator nie wykonuje sam długich zadań, tylko je deleguje — dzięki temu pozostaje wolny do rozmowy. Wchodź w tryb „brain dump”: zrzucaj każdą myśl do agenta i zapominaj o niej.
Na co uważać: Zaufanie buduje się miesiącami. Na początku agent będzie źle rozdzielał zadania albo dublował pracę — musisz to obserwować i dostrajać reguły. Nie oddawaj krytycznych decyzji zanim empirycznie nie potwierdzisz, że routing działa poprawnie.
2.Precyzyjne reguły „kiedy wrócić do człowieka”
Na czym polega: Największym ryzykiem autonomicznych agentów jest to, że „szaleją” i robią mnóstwo rzeczy bez nadzoru, a na końcu okazuje się, że zrobiły coś nie tak. Autor pisze obszerne instrukcje określające, kiedy agent ma eskalować decyzję do niego.
Jak stosować: Zdefiniuj wprost warunki eskalacji — np. „jeśli naprawa błędu wymaga zmiany działania produktu, pytaj mnie”. Traktuj to jako iteracyjne dostrajanie „słodkiego punktu” autonomii, przegadane z agentem, a nie ustawienie raz na zawsze.
Na co uważać: Słodki punkt jest indywidualny i zależny od projektu. Za mało eskalacji = ciche błędy w produkcji; za dużo = agent staje się bezużyteczny, bo pyta o wszystko.
3.Pipeline adwersaryjnej recenzji kodu generowanego przez AI
Na czym polega: Skoro wąskim gardłem nie jest już pisanie, lecz recenzja tysięcy linii kodu od AI, autor przepuszcza zmiany przez zautomatyzowany pipeline (No Mistakes): analiza pierwotnej intencji z sesji agenta, rebase na main, adwersaryjna recenzja innym modelem, autonaprawa lub eskalacja, testy z widocznym dowodem, dokumentacja, linting i pilnowanie CI.
Jak stosować: Zbuduj proces w izolowanym drzewie roboczym/branchu, który recenzuje diff osobnym modelem (autor poleca GPT jako recenzenta) i weryfikuje zgodność z twoją pierwotną intencją, nie tylko poprawność techniczną. Odpalaj go i odchodź — nie siedź nad widokiem.
Na co uważać: To kosztuje tokeny i czas — to „nieunikniony koszt jakości”. Nie stosuj tego do wszystkiego: demo weekendowe pomiń, oprogramowanie produkcyjne z płacącymi klientami — nie. Proste, pewne poprawki mergеuj ręcznie.
4.Dobór modelu i „reasoning effort” to najtańsza dźwignia oszczędności
Na czym polega: Modele niewystarczająco inteligentne do zadania marnują tokeny, kręcąc się w kółko — zwłaszcza na najwyższych poziomach rozumowania („max”, „ultra”). Autor zauważył, że słabszy model na wysokim rozumowaniu potrafi wykonać wiele zbędnych wywołań narzędzi tam, gdzie lepszy model na „medium” robi to w minutę.
Jak stosować: Trzymaj się jednego dobrego modelu i reguluj poziom rozumowania w dół, zamiast przeskakiwać na tańszy, słabszy model. Autor używa GPT 5.6 „Soul” i dostosowuje rozumowanie; jego słodki punkt to x-high (szybki, nie pali tokenów tak jak „max”/„ultra”).
Na co uważać: „Ultra”/„ultra code” to nie poziom rozumowania, lecz prompt każący agressywnie odpalać sub-agenty — każdy jako agent ultra — co potrafi drastycznie spalić limity. Weryfikuj, co dana etykieta faktycznie robi, zanim ją włączysz na stałe.
5.Wizualne artefakty zamiast ścian tekstu przy decyzjach projektowych
Na czym polega: Do złożonych decyzji technicznych z wieloma kompromisami autor używa narzędzia (Lavish), które każe agentowi wygenerować interaktywny artefakt HTML — drzewo, diagram, tablicę w stylu Excalidraw — zamiast długiego wywodu w terminalu.
Jak stosować: Gdy decyzja ma wiele ruchomych części i trade-offów, poproś agenta o wygenerowanie wizualnej reprezentacji opcji i otwartych pytań. Nanoś poprawki na diagram (przesuwaj pola, komentuj) i odsyłaj feedback zamiast opisywać wszystko słowami.
Na co uważać: To narzędzie do decyzji ambiguous, nie do codziennych zadań. Autor świadomie nie spędza nad artefaktem zbyt wiele czasu — kolejkuje decyzję i idzie dalej, by nie utknąć w analizie.
6.Interfejsy dla agentów (axi) bywają tańsze i skuteczniejsze niż MCP
Na czym polega: Wiele serwerów MCP jest niewydajnych — wolniejszych, bardziej tokenożernych i mniej skutecznych niż dobrze zaprojektowane CLI. Autor zbudował „axi” (interfejsy CLI dla agentów) według 10 zasad; wrapper na Chrome DevTools MCP obniżył średni koszt o ponad 20% bez utraty funkcji, samą zmianą interfejsu.
Jak stosować: Jeśli uderzasz w wąskie gardło tokenów, sprawdź, czy używane narzędzie ma wersję axi lub dobre CLI zamiast serwera MCP (dla GitHuba autor rekomenduje CLI, nie MCP). Kluczowe zasady: wyjście oszczędne tokenowo zamiast JSON, minimalny domyślny schemat (nie zwracaj wszystkich pól).
Na co uważać: LLM-y najlepiej znają narzędzia obecne w danych treningowych (jak GitHub CLI) — nowy, „idealny” interfejs może być gorszy tylko dlatego, że model go nie zna. Benchmarkuj na własnych zadaniach, nie zakładaj poprawy w ciemno.
7.Terminal + multiplekser rozumiejący agentów daje mobilność i świadomość stanu
Na czym polega: Cały workflow działa w terminalu na Mac Mini, z multiplekserem (Herder), który rozumie, czym jest agent — pokazuje status „pracuje/czeka na mnie” — i pozwala podłączyć się do tej samej sesji z telefonu przez SSH.
Jak stosować: Jeśli pracujesz z wieloma agentami, wybierz multiplekser świadomy statusu agentów, byś nie musiał ręcznie sprawdzać, czy sesja jeszcze działa. Sesje terminalowe (w przeciwieństwie do GUI) łatwo udostępnić zdalnie przez SSH z dowolnego urządzenia.
Na co uważać: Terminal ma realną krzywą uczenia — na początku spadek produktywności jest normalny. Zwrot pojawia się dopiero po zbudowaniu pamięci mięśniowej skrótów klawiszowych.
8.Oprogramowanie, które modyfikuje samo siebie, jest odporne na błędy
Na czym polega: Gdy instrukcje i skrypty agenta leżą w edytowalnym katalogu, agent może obchodzić własne błędy i modyfikować swoje narzędzia. Błąd co najwyżej spowalnia agenta, zamiast go zatrzymywać — inaczej niż w tradycyjnym oprogramowaniu, gdzie bug potrafi wywalić aplikację.
Jak stosować: Trzymaj plik instrukcji i skrypty pomocnicze w bieżącym katalogu, do którego agent ma dostęp zapisu, i pozwól mu je usprawniać. Pakuj kroki deterministyczne w skrypty bashowe, by agent nie palił tokenów na ich odtwarzanie. Rozważ pętle samonaprawcze: zgłoszenie błędu → CLI wdraża poprawkę → PR → automatyczna recenzja.
Na co uważać: „Nie do zatrzymania” bywa dwuznaczne — agent obchodzący błędy może maskować problem, zamiast go zgłosić. Utrzymaj bramki jakości (jak pipeline recenzji z punktu 3), żeby elastyczność nie stała się źródłem cichego długu technicznego.
9.Limity subskrypcji, nie umiejętności, są dziś wąskim gardłem
Na czym polega: Dla osoby pracującej solo intensywnie z agentami cennik API jest nie do utrzymania (autor szacuje ponad 10 000 $ miesięcznie), więc realnym ograniczeniem staje się limit subskrypcji. Autor śledzi procent zużytego limitu, a nie liczbę tokenów, i rozkłada zużycie względem resetów.
Jak stosować: Zbuduj lub użyj widżetu limitów (autor eksponuje dane o limitach agentom przez „quota axi”, by orkiestrator nie kierował zadań do prawie wyczerpanej subskrypcji). Dla zadań w tle preferuj tańsze, wolniejsze tryby — liczy się łączna wykonana praca, nie latencja.
Na co uważać: Dostawcy zmieniają zasady (progi kompaktowania, dostępność modeli, brak „bankowanych” resetów) często bez jasnej komunikacji. Nie planuj krytycznej pracy wokół pojedynczego modelu czy limitu, którego reset jest daleko — miej zapas i alternatywy.
10.Buduj narzędzia z realnych tarć, nie dla samej zabawy setupem
Na czym polega: Wielu entuzjastów AI spędza cały czas na spektakularnych setupach, ale niczego nie wypuszcza. Autor zaczął budować narzędzia dopiero, gdy praca solo obnażyła konkretne wąskie gardła (walidacja kodu AI, planowanie, żonglowanie sesjami) — a delegowanie przyziemnych rzeczy orkiestratorowi przesunęło jego czas ku realnemu tworzeniu produktów.
Jak stosować: Buduj narzędzie tylko wtedy, gdy usuwa realne, powtarzające się tarcie w twojej pracy. Deleguj naprawy i drobne usprawnienia agentowi, żeby twój czas naturalnie ciążył ku ambiguous decyzjom i rozwojowi produktu. Ograniczaj udział człowieka tylko do rzeczy naprawdę istotnych.
Na co uważać: Łatwo wpaść w pułapkę, gdzie przez tydzień czy dwa budujesz wyłącznie tooling, a nie prawdziwe rzeczy. Pilnuj proporcji — jeśli setup przestaje służyć wypuszczaniu produktów, to znak, że stał się celem samym w sobie.