O czym jest ten film
- Najcenniejszą umiejętnością 2026 roku staje się zarządzanie zespołami agentów AI — niezależnie od zawodu wszyscy stają się „menedżerami agentów”.
- Praca w chmurze (agenci na maszynach wirtualnych) pozwala uruchamiać wiele agentów naraz bez konfliktów kodu — inaczej niż praca lokalna.
- Gość, Ryan Carson, prowadzi jednoosobowy startup Untangle (AI dla kancelarii rozwodowych) i skaluje się dzięki agentom, robiąc ok. 50% pracy z telefonu.
- Nowa rola człowieka to podejmowanie kilkunastu–kilkudziesięciu decyzji wysokiej stawki dziennie; trzeba nauczyć się rytmu i priorytetyzacji, by nie zwariować.
- Bezpieczeństwo: klucze produkcyjne trzyma się z dala od agentów (np. w 1Password) i podaje ręcznie tylko wtedy, gdy trzeba pisać do produkcji.
- Automatyzacje zastępują cykliczne spotkania — np. testy end-to-end w przeglądarce trzy razy w tygodniu z automatycznym triage’em błędów.
- „Production watchdog” — codzienny raport, co robili kluczowi klienci, z linkami do realnego UI, działa jak chief of staff.
- Pętla samodoskonalenia: agent codziennie ocenia rozmowy produktu według rubryki i sam zgłasza poprawki (PR-y) do najsłabszych miejsc.
- Koszty: routing modeli i tanie, dostrojone modele (np. SWE 1.7 od Cognition) obniżają rachunki; zależność od jednego frontier labu grozi „walled garden”.
- Budowanie reputacji przez publiczne dzielenie się wiedzą (X, artykuły) realnie otwiera drzwi i procentuje w dłuższej perspektywie.
Redakcyjne tłumaczenie
(Informacja dodatkowa: To rozmowa Grega Isenberga z Ryanem Carsonem. Carson jest wieloletnim founderem — wcześniej prowadził Treehouse, platformę do nauki programowania — a obecnie sam buduje startup Untangle, „agenta rozwodowego AI” dla kancelarii prawa rodzinnego. Devon to agent kodujący firmy Cognition; Fable, Opus, GPT to modele językowe różnych dostawców.)
Wprowadzenie: wszyscy stajemy się menedżerami agentów
Greg: Nie przesadzę, jeśli powiem, że ludzie, którzy potrafią prowadzić zespoły agentów AI, będą w tej epoce sztucznej inteligencji wyprzedzać wszystkich innych. Jak więc naprawdę prowadzić takie zespoły? Co to w praktyce znaczy? Jakich narzędzi trzeba do tego znać — na przykład Devona? W dzisiejszym odcinku wróci do mnie Ryan Carson, który wyjaśni to wszystko krok po kroku, a nawet oprowadzi nas po swoim niesamowitym stanowisku pracy. Pod koniec zrozumiesz, czym są agenci chmurowi, jak stawiać automatyzacje i jak zbudować „fabrykę oprogramowania”, która tworzy je 24 godziny na dobę.
Ryanie, co ludzie z tego wyniosą?
Ryan: Nauczysz się robić dobrze trzy rzeczy: uruchamiać agentów w chmurze, budować automatyzacje i wysyłać zmiany szybciej. Niezależnie od tego, czy jesteś founderem, solopreneurem, czy rodzicem siedzącym w domu — zanim skończymy, staniesz się profesjonalistą w pracy z agentami.
Bo w praktyce jesteś teraz menedżerem agentów. Cokolwiek robiłeś wcześniej — czy zarządzałeś ludźmi, czy byłeś indywidualnym wykonawcą — teraz zarządzasz agentami i musisz być w tym najlepszy na świecie. Nieważne, czy jesteś inwestorem VC, founderem, wykonawcą, mamą, tatą czy studentem — powinieneś zarządzać agentami i robić to znakomicie.
Kontekst: jak skaluje się jednoosobowa firma
Ryan: Pozwól, że dam trochę kontekstu. Jestem founderem i CEO od jakichś 25 lat, pracuję nad czwartą firmą. W poprzedniej — Treehouse, która została przejęta — mieliśmy do 110 pracowników na pełen etat i nauczyliśmy programowania milion osób. Przeszedłem więc całą drogę budowania i zarządzania organizacją, nauczyłem się mnóstwa o kierowaniu ludźmi.
A teraz w tym startupie jestem jedynym pracownikiem. Zebraliśmy rundę zalążkową, skalujemy się bardzo szybko — przychód w tym miesiącu prawdopodobnie wzrośnie czterokrotnie — i pewnie niedługo zatrudnię pierwsze osoby. Jesteśmy w istocie „agentem rozwodowym AI” dla kancelarii rozwodowych. Zajmujemy się tematem, którego nikt nie chce ruszać, czyli prawem rodzinnym.
Nauczyłem się więc dużo o tym, jak skalować samego siebie: jak zarządzać wieloma agentami, jak sprawdzać ich pracę, jak automatyzować, jak pracować z telefonu. Prawdopodobnie ponad 50% mojej pracy robię z telefonu. To trochę szalone. I od razu powiem: to wszystko będzie się zmieniać co 3–6 miesięcy. Najlepiej uczyć się przez działanie — pobrudź sobie ręce i próbuj.
Stanowisko pracy: osiem okien i multitasking
Ryan: Zacznę od pokazania, jak wygląda mój świat przy biurku. Pracuję z Connecticut, z domowego biura, na wielkim 52-calowym monitorze Della. Kiedyś miałem kilka mniejszych, ale stwierdziłem: chcę jeden ogromny. Ustawiam na nim osiem okien naraz, bo muszę równolegle obsługiwać wielu agentów. Do listy zadań używam też papierowego systemu UG Monk — trochę dziwne, ale działa. Mam pionową mysz Razera, bo dokuczał mi nadgarstek, i przycisk podłączony do Whisper Flow, którego używam do niemal całego dyktowania.
W lewym górnym rogu mam Slacka — tam dostaję powiadomienia o tym, co robią moi agenci. Mam też stale otwarty 1Password, bo bardzo ważne jest, żeby trzymać klucze w bezpieczeństwie i osobno od agenta. Wszystkie klucze do zapisu na produkcji mam w 1Password i nie daję ich agentom. Pisanie do produkcji jest niebezpieczne — agent w końcu zrobi coś złego. Dlatego trzeba mieć system, w którym agent prosi o klucz, gdy musi zapisać coś na produkcji, a ty wtedy wchodzisz do 1Password, kopiujesz i wklejasz go do sesji — i oboje macie jasność, co się dzieje.
Do tego używam Devona od Cognition. To jedna z najlepszych „fabryk oprogramowania” w branży. Nie jest tani, ale jest dobry. Rzeczy, o których dziś mówię, nie są jednak specyficzne dla Devona. Mam też dwa okna do testowania aplikacji — bo testowania jest naprawdę dużo — X w rogach oraz Codex po prawej. Większość pracy robię w chmurze, w Devonie, a lokalne rzeczy w Codeksie.
Ale prawda jest taka, że mnóstwo pracy robię z iPhone’a. Zdarza mi się pod prysznicem pomyśleć: muszę sprawdzić ten PR albo go domknąć — łapię telefon, rozmawiam z Devonem w przeglądarce i sporo załatwiam.
(Informacja dodatkowa: PR, czyli pull request, to zgłoszona propozycja zmiany w kodzie, którą trzeba przejrzeć i zatwierdzić, zanim trafi do głównej wersji.)
Dlaczego Devon i dlaczego chmura
Greg: Ciągle słyszę, że Devon to najpotężniejszy agent kodujący. Dla tych, którzy nie mieli z nim styczności — o co chodzi?
Ryan: Jakieś dwa–dwa i pół roku temu Devon pojawił się i był reklamowany jako „inżynier oprogramowania”. Szczerze, wtedy nie działał dobrze — modele po prostu nie były wystarczająco mocne. Przewińmy do 2026 roku: modele są już zdecydowanie na poziomie, a gdy dodasz do nich dobry, chmurowy „harness”, całość jest naprawdę świetna.
(Informacja dodatkowa: „Harness” to warstwa oprogramowania spinająca model językowy z narzędziami — środowiskiem, testami, przeglądarką — dzięki której agent może realnie wykonywać zadania, a nie tylko generować tekst.)
Masz do wyboru różne opcje. Jeśli budujesz przy pomocy agentów, prawdopodobnie używasz Codeksa od OpenAI, Claude Code od Anthropic albo jednego z niezależnych „harnessów”: AMP, Cursor (już niezależny nie jest, bo w zasadzie należy do Elona), Cognition z Devonem albo Factory.
Ja chciałem skalować się horyzontalnie — uruchamiać tylu agentów, ilu się da, i nie siedzieć na laptopie zastanawiając się, który fragment kodu koliduje z którym i na którym „drzewie roboczym” jestem. Cała ta techniczna otoczka odbiera czas na wysyłanie zmian.
Ciekawe jest to: wszyscy myśleliśmy, że inżynieria i bycie technicznym odchodzą do lamusa. A dzieje się odwrotnie — im lepszym menedżerem agentów się stajesz, tym bardziej techniczny musisz być. Jesteś w istocie menedżerem inżynierii. Musisz rozumieć, czym jest Postgres, czym różni się środowisko produkcyjne od deweloperskiego, czym są migracje. Ale nauczysz się tego wszystkiego, po prostu używając agentów. Jestem dziś bardziej techniczny niż kiedykolwiek w życiu.
Pierwsza lekcja: pracuj w chmurze
Ryan: Pierwsza rzecz to chmura. Jak uruchamiać więcej agentów i robić więcej? Pracując w chmurze, nie na lokalnej maszynie.
Dla mniej technicznych: pisząc kod, musisz go gdzieś edytować i hostować. Kiedyś robiliśmy to wszystko na własnych Macach — to zwane jest „development lokalny”. Musisz postawić całe lokalne środowisko: bazę danych, uwierzytelnianie, serwer deweloperski. A co, jeśli chcesz robić dwie rzeczy naraz? Musisz użyć „git work trees”, co jest dość techniczne, albo dosłownie zrobić drugą kopię kodu w innym katalogu. Przy dwóch rzeczach masz dwie kopie, a przy pięciu czy dziesięciu — to po prostu przestaje działać.
Devon — i coraz częściej dobre niezależne harnessy jak Cursor czy Codex — tworzy w chmurze VM, czyli maszynę wirtualną. To mały serwer, który jest twoim środowiskiem deweloperskim. Klikasz przycisk, maszyna się uruchamia i możesz w niej kodować. Piękne jest to, że możesz stworzyć ich nieskończenie wiele. Często mam co najmniej pięciu agentów chmurowych pracujących naraz, nierzadko dziesięciu, i nie ma ryzyka kolizji kodu.
To zdejmuje z głowy cały narzut mentalny związany z koordynacją. Kiedy pracuję w chmurze, po prostu otwieram przeglądarkę, klikam „nowa sesja”, startuje nowy VM i nigdy nie muszę o tym myśleć. Jeśli pracujesz lokalnie, to szczerze — jesteś jaskiniowcem. Hamujesz się i wysyłasz dziesięć razy mniej, niż mógłbyś. Nawet jeśli ci się wydaje, że „fajni ludzie” pracują lokalnie — to już nieprawda.
Greg: Na X jest sporo „lokalnych maksymalistów”, którzy patrzą na ludzi stawiających maszyny wirtualne jak na amatorów. Co im powiesz?
Ryan: Że nie wykonują prawdziwej pracy. Kiedy w Untangle osiągnęliśmy dopasowanie produktu do rynku i zaczęliśmy pozyskiwać realnych klientów oraz wysyłać realne poprawki i funkcje, musiałem zwiększyć swój output jakieś 50-krotnie. Lokalnie się tego nie da. Praca lokalna bywa miła i czasem konieczna — na przykład przy ciężkim front-endzie, gdy tworzysz zupełnie nowy interfejs, to prawdopodobnie postawisz lokalnego agenta do lekkiego szkicowania. Ale jak najszybciej przenieś to do chmury i pozwól przejąć agentowi chmurowemu. Duża część tradycyjnej wiedzy o tym, jak się pracuje, jest już nieaktualna.
Życie w rytmie decyzji wysokiej stawki
Greg: Jeśli zaczniesz używać agentów chmurowych i zwiększysz output 50-krotnie, to w pewnym sensie jest stresujące — masz nagle mnóstwo spraw naraz. Jak zbudować system, żeby nie oszaleć?
Ryan: Najpierw musisz zmienić rozumienie tego, czym jest twoja praca. A twoja praca to teraz podejmowanie decyzji wysokiej stawki niemal przez cały dzień. Dawniej mieliśmy luksus podejmowania najwyżej dwóch–trzech takich decyzji dziennie — ważne spotkanie, kilka istotnych ustaleń, które potem realizowano przez dwa tygodnie. Teraz musisz nastawić się na to, że do lunchu podejmiesz 10–20 decyzji wysokiej stawki.
Jak to robić? Kilka prostych rzeczy. Organizuję wątki z agentami i przypinam te, które dotyczą najważniejszej pracy na dany dzień. Jest mnóstwo drobnych poprawek błędów — uczysz się dzielić rzeczy na dwa kubełki: co jest dziś naprawdę ważne (to przypinasz), a resztę „puszczasz luzem” i wracasz, gdy możesz.
Ustaw sobie też coś w rodzaju timera. Jeśli będziesz cały dzień bez przerwy przeklikiwać wątki, kompletnie się wypalisz. To kwestia dyscypliny. Jest takie powiedzenie: „powoli znaczy płynnie, a płynnie znaczy szybko”. Zorientowałem się, że mogę sprawdzać agentów i podejmować decyzje wysokiej stawki mniej więcej co 25 minut — i przy tym rytmie mentalnie odpoczywam. Druga strona medalu jest taka, że to po prostu jest wyczerpujące. Żeby przetrwać w tym nowym świecie, będziesz pracować więcej, a nie mniej.
Pokażę ekran. To moje PR-y w kolejnych dniach — średnio jakieś 22–25 dziennie, czasem 40. Większość jest scalana, część zamykana. Zabawne: tego dnia, 18-tego, poszedłem z synem na wspinaczkę na Mount Washington i nie miałem dostępu do telefonu. Ale zauważ — rano, zanim się obudził, wysłałem osiem PR-ów. Taki mamy teraz świat.
Lekcje są takie: musisz przejść do chmury; połowę czasu będziesz pracować z telefonu; to męczące, ale jak siłownia — masz nowy mięsień, którego nigdy nie ćwiczyłeś, a okazuje się najważniejszy. Ustaw sobie rytm, przypinaj najważniejsze wątki, zapisuj je. Codziennie używam tego zabawnego analogowego systemu, żeby przypomnieć sobie, co dziś naprawdę trzeba wysłać — bo zawsze będzie z dziesięć PR-ów gaszących pożary, które potrafią cię rozproszyć i wykończyć.
Greg: Chodzi o to, że przy tej prędkości pracy umysłowej po prostu musisz być dostępny, by w czasie rzeczywistym powiedzieć „tak” albo dać informację zwrotną. Po co czekać, aż siądziesz przed Makiem?
Ryan: Dokładnie. Łatwo myśleć o agentach jak o ludziach — tyle że masz teraz zespół, który skaluje się w nieskończoność, pracuje bardzo szybko i będzie blokowany tylko przez twoje decyzje. Decyzji na razie nie da się delegować. Jest jedna sztuczka: nawet używając Fable, potraktuj jeden wątek jako menedżera i poproś go, żeby uruchamiał „dzieci”. Robię tak często — odpalam wątek-rodzic i mówię: „chcemy osiągnąć te pięć rzeczy, uruchom pięć podrzędnych sesji Devona”. Nie da się cały czas gonić na super-premium modelu, więc miej inteligentnego rodzica, który zarządza tańszymi dziećmi. Ale i tak na końcu musisz zwracać uwagę. To jak z prowadzeniem dużego zespołu — nie możesz cały czas być na lunchu na jachcie, musisz być w biurze. A biuro to twój telefon. Więc moje zadanie domowe dla ciebie, Greg: następnym razem chcę, żebyś ponad połowę pracy robił z telefonu.
Greg: Jednym z moich wniosków jest to, że twój system radzenia sobie z zadaniami nie różni się bardzo od tego, co robiła dobrze zorganizowana osoba jeszcze przed erą AI. Przypinanie najważniejszych rzeczy to z jednej strony oczywistość, ale z drugiej — jeśli nikt ci tego nie powie, tonie w chaosie.
Ryan: To zabawne — powrót do podstaw, tyle że w epoce agentów. Okazuje się, że bycie naprawdę dobrym menedżerem inżynierii to jedna z najcenniejszych umiejętności, jakich możesz się nauczyć. Mam zaszczyt mentorować mojego siostrzeńca, który niedługo kończy studia i pyta: jak wygrać w tym nowym świecie? Uczę go dokładnie tego, o czym mówimy: twoim zadaniem będzie zarządzanie tyloma agentami, iloma zdołasz. Pracuj w chmurze, priorytetyzuj, naucz się szybko podejmować decyzje wysokiej stawki, stań się techniczny. To brednia, że inżynieria zanika — jeśli ktoś ci mówi, że inżynierowie znikają, po prostu nie wykonuje tej pracy.
To jak z cieślą: gdybyś miał wokół siebie roboty-cieśli, będąc prawdziwym cieślą byłbyś ich znacznie lepszym menedżerem — bo wiesz, jak wykonać cięcie i gdzie wbić gwóźdź. Więc rzecz numer jeden: agenci chmurowi. Zdobądź wprawę, spróbuj kilka razy, rób to z telefonu i oswój się z małym ekranem. Rzecz druga to automatyzacje.
Druga lekcja: automatyzacje zamiast spotkań
Ryan: Skoro pracujesz już w chmurze — świetnie, zaczynasz się wyróżniać. Druga rzecz to automatyzacje. Pomyśl o sprawach, na które kiedyś miałbyś cotygodniowe albo codzienne spotkanie z zespołem, żeby coś sprawdzić — i zbuduj z tego automatyzację.
Wracasz do agenta, otwierasz sesję i mówisz: „chcę, żebyś zautomatyzował to zadanie co X dni”. Jedną z moich prostych automatyzacji jest test rejestracji w Untangle: założenie sprawy, onboardowanie klienta, przejście przez etap „discovery” — czyli nasze podstawowe doświadczenie użytkownika — ale zautomatyzowane w przeglądarce. To nie fizyka kwantowa, to zwykłe testy użytkownika, tyle że dobry agent potrafi je wykonać.
(Informacja dodatkowa: „Discovery” w sprawie rozwodowej to prawny etap wymiany dokumentów i informacji między stronami.)
Wielki przełom polega na tym, żeby ustawić agentów tak, aby sami się ulepszali, zamiast żebyś to ty budował te systemy. W Devonie nazywa się to „playbook” — coś w rodzaju listy: jak wykonać daną rzecz i jak zrobić to poprawnie. To coś innego niż „skill”. Mam taki test rejestracji end-to-end, który uruchamia się trzy razy w tygodniu, bo jest drogi — jakieś 60 dolarów w tokenach, bo robi mnóstwo testów w przeglądarce.
To ważny punkt: dziś kluczowe jest, by twój agent potrafił porządnie testować w przeglądarce, i to od razu, „z pudełka”. To jeden z powodów, dla których używam Devona — oni robią agentów chmurowych testujących w przeglądarce od dwóch lat. Agent nagrywa wideo, anotuje je, ogląda własne nagranie i naprawia dostrzeżone błędy. Masz więc agentową pętlę wokół testowania w przeglądarce, uruchamianą trzy razy w tygodniu.
I co dalej? Trzeba na tej podstawie wywołać triage. Jeśli trzeci test w automatyzacji zawiódł, uruchamiam sesję Devona, która to naprawia. Ale musisz też wiedzieć, że coś padło — czy agent po cichu zawiódł i sam się naprawił? Co z utworzonym PR-em? Jako menedżer agentów musisz mieć sposób, by widzieć te zdarzenia. Znów: rozmawiasz z agentem — „mamy ten test end-to-end, uruchamia się w poniedziałki, środy i piątki, wyzwala podrzędną sesję triage’u, gdy coś pójdzie nie tak; jak mam się o tym dowiedzieć?”. Agent może zaproponować: „może zapostuję na Slacku?”. A ty: „dobrze, jak to zrobisz?”. Trzeba podłączyć MCP, ustalić, w którym kanale patrzeć — jest cała maszyneria, którą trzeba poukładać, żeby to działało i żebyś ty robił mniej pracy.
(Informacja dodatkowa: MCP — Model Context Protocol — to standard łączenia agentów AL z zewnętrznymi narzędziami i usługami, na przykład ze Slackiem czy bazą danych.)
Greg: Ta konkretna automatyzacja to raczej QA i wyłapywanie błędów, czy raczej perspektywa UX?
Ryan: Ta akurat dotyczy wyłapywania błędów, które trafiły na produkcję, a które jakoś umknęły naszym automatycznym testom. Chodzi o to, żeby rejestracje nie przestały działać, a my byśmy o tym nie wiedzieli. Automatyczny zestaw testów nie wychwytuje wszystkiego, ale dobre staroświeckie przeklikanie strony w przeglądarce to łapie. To nie jest o UX. Powiem tak: nie ma i długo nie będzie substytutu dla używania własnej aplikacji przez ciebie. Co jakiś czas sam przechodzę przez całą naszą aplikację, a potem szybko odpalam sesje naprawiające znalezione błędy. Nawet najmądrzejsze modele świata wciąż nie mają tego oczywistego zmysłu, przez który człowiek pyta: „dlaczego uznałeś, że to jest w porządku?”.
Greg: Większe pytanie brzmi: jeśli jest podział pracy między ludźmi a agentami, to które zadania zostają dla człowieka, a które oddajesz agentom, zachowując siebie w pętli? Poza QA, jakie inne automatyzacje mógłby wdrożyć founder?
Production watchdog: codzienny raport jak od szefa sztabu
Ryan: Pozwól, że wyciągnę listę. Jeden rodzaj to oczywiście QA i naprawa błędów. Drugi to coś, co nazywam „production watchdog”. Untangle używa wielu prawdziwych kancelarii, mamy mnóstwo realnych klientów przechodzących przez discovery i ogromną aktywność, której nie ogarnę mentalnie samym przeglądaniem logów. Więc codziennie o 9:00 rano uruchamia się automatyzacja, która przechodzi przez wszystkie zdarzenia w bazie dotyczące płacących klientów, podsumowuje je do pliku JSON, a ten plik ląduje w naszym panelu administracyjnym. Każdego ranka klikam „production watchdog” i czytam podsumowanie tego, co robili klienci. To ogromnie wartościowe — jak chief of staff, który mówi: „Greg, oto ważne rzeczy, które zdarzyły się wczoraj u naszych klientów, co poszło dobrze i kilka błędów, które zauważyliśmy”.
Greg: To duża sprawa. Brzmi drobno, a jest wielka — bo wydaje ci się, że wiesz, co się dzieje, ale tak naprawdę nie wiesz.
Ryan: Właśnie. I kolejna sztuczka: w raporcie wybierz najważniejszych klientów i zadbaj, by przy każdym było „klient zrobił X, oto link, żeby to zobaczyć”. Mam instancję produkcyjną, w której klikam i widzę, co dokładnie robił klient. Czasem myślę „dziwne”, klikam, i okazuje się, że doświadczenie użytkownika, które zbudował agent, nie było takie, jak zakładałem. Przez miliony lat ewolucji nauczyliśmy się bardzo szybko wychwytywać rzeczy, które są „nie tak”. Więc production watchdog, który linkuje do prawdziwego UI, to zmiana reguł gry.
Trzecia automatyzacja: pętla samodoskonalenia
Ryan: To bardzo ważne — pętla samodoskonalenia. W Untangle mamy agentkę o imieniu Grace, w istocie paralegal. Prowadzi mnóstwo rozmów: z naszymi klientami-adwokatami, z paralegalami, i z klientami naszych klientów, czyli osobami przechodzącymi rozwód. Jak oceniać te rozmowy i je poprawiać bez ręcznego pilnowania szczegółów?
Codziennie mam automatyzację, która analizuje te rozmowy i ocenia je według rubryki. Znów — po prostu rozmawiasz o tym z agentem. Wybierasz najważniejszą część aplikacji, którą chcesz doskonalić, i mówisz: „oto jak, agencie, masz oceniać, czy to, co się dzieje, jest dobre czy złe. Codziennie uruchom tę automatyzację, spójrz na rozmowy Grace, oceń je, a jeśli coś jest złe albo poniżej progu, odpal podrzędną sesję i to napraw”. Szokująca jest liczba drobnych szczegółów UX, które ta pętla wychwyciła i naprawiła. To rzeczy, których sam bym nie ruszył — albo o nich nie wiedziałem, albo pomyślałbym „to drobiazg, czy naprawdę mamy wysyłać na to poprawkę?”. Ale skoro agent już to zidentyfikował, przygotował PR i jest gotowy do wysyłki — po prostu go wysyłam. Wysyłamy pewnie trzy takie dziennie.
Koszty i routing modeli
Greg: Sporo krytyki takich pętli sprowadza się do tego, że są drogie. Czy w Devonie było to absurdalnie kosztowne? O jakich kwotach mówimy?
Ryan: W zeszłym miesiącu wydałem na tokeny jakieś 20 tysięcy dolarów — to za dużo, to nie do utrzymania. Myślę, że dochodzimy do momentu, w którym realna praca inżynieryjna to jakieś 5 tysięcy dolarów miesięcznie na pracownika. Powyżej tego naprawdę trzeba ogarnąć routing modeli. Na szczęście Cognition to rozumie i wszyscy — Cursor, Cognition, Factory, AMP, wszystkie niezależne laby — wiedzą, że klienci mają limity i nie zapłacą nieskończonych budżetów na tokeny.
I tu mała tyrada: masz Claude Code i Codeksa, którzy mocno dopłacają do tokenów, żeby wyglądały na tanie — ale to na dłuższą metę się nie utrzyma. Dlatego nauczyłem się używać właściwego modelu do właściwego zadania. Te pętle wzmacniające używają modelu SWE 1.7 — dostrojonego modelu, którego Cognition zbudował specjalnie do kodowania. Jest bardzo tani w porównaniu z Opus 4.8 czy GPT. Sporo pętli działa na tym tańszym, dostrojonym modelu — i będziemy widzieć tego coraz więcej. Na takiej sesji mówimy pewnie o jakichś pięciu dolarach.
Greg: To nie jest źle.
Ryan: Jeśli nie jesteś gotów zapłacić 15 dolarów dziennie, żeby ulepszać jeden z kluczowych zestawów funkcji swojego produktu — to co ty właściwie robisz? Albo to nie jest prawdziwa firma, albo ci nie zależy. Wydaj te pieniądze, a potem ogarnij system obniżający koszt tokenów.
Dlatego nie rozumiem, czemu ktokolwiek miałby budować swoją inżynierię na stacku pojedynczego frontier labu. Jeśli cała twoja praca dzieje się wewnątrz Claude Code albo Codeksa — to co robisz? Oni nie mają motywacji, by na dłuższą metę było ci rozsądnie cenowo; zamkną cię w swoich modelach i procesie. Natomiast niezależny lab agentowy — AMP, Devon, Factory, po części Cursor — będzie optymalizował pod tanią inżynierię w długim terminie. Nie chcesz być uzależniony wyłącznie od Anthropic czy OpenAI.
Greg: Dla jasności — w tych produktach wciąż możesz używać ich modeli, prawda? Nie odcinasz się od nich.
Ryan: Dokładnie, to „tak, i”. Piękne jest to, że gdy płacisz niezależnemu labowi — Factory, Cursorowi, Cognition, AMP — mają motywację, żeby dać ci najlepszy wynik za najniższą cenę. Powiedzą: „do tego typu zadania użyjemy GPT na wysokim ustawieniu, potem przekierujemy do SWE 1.7, a następnie każemy to sprawdzić Fable”. Oni rozwiążą te trudne rzeczy za ciebie.
I jeszcze jedno: jeśli próbujesz sam budować „fabrykę oprogramowania” — przestań. Powód, dla którego widzisz, jak Ramp uruchamia własnego wewnętrznego agenta „Inspect”, jest taki, że dorośli do rozmiaru, przy którym musieli zbudować własną fabrykę. Przy pewnej skali też to zrobisz. Ale jeśli jesteś jednoosobowym warsztatem i budujesz coś tylko dla siebie, prawdopodobnie wystarczy ci abonament za 200 dolarów miesięcznie u wybranego frontier labu. Gdy jednak awansujesz do „budujemy prawdziwy produkt, mamy dopasowanie do rynku, zaczynamy zatrudniać” — musisz zbudować fabrykę oprogramowania, i wtedy chcesz być na niezależnym labie. Inaczej albo zbudujesz ją sam (głupie), albo zapłacisz i zamkniesz się w ogrodzonym ogródku. Analogia: praca z niezależnym labem jest jak z brokerem kredytowym albo agentem turystycznym — wykonają mnóstwo telefonów, żeby wynegocjować ci najlepszą cenę.
Greg: Ja używam obu — jestem w Claude Code, ale osobiście korzystam też z Cursora. Devonem jestem zainteresowany; jeśli ludzie będą chcieli, może zrobię całe omówienie Devona.
Ryan: Devon jest teraz tak dobry, że aż niesamowity. Ale przyznaję, że używam też Codeksa — aplikacja na Maca jest przepiękna, a oni tak mocno dopłacają do tokenów, że jeśli chcesz mieć na maszynie agenta do naprawdę fajnych, pomocnych rzeczy — otwierania kart, tworzenia dokumentów Google, sprawdzania maila, całej tej pracy informacyjnej — masz to niemal za darmo. Płacisz 200 dolarów i dostajesz niemal nieskończone tokeny. Świetne, ale nie buduj na tym firmowej fabryki oprogramowania — to szaleństwo.
Podsumowanie i budowanie reputacji
Greg: Sporo dziś omówiliśmy. Chcesz coś jeszcze dodać?
Ryan: Mam wrażenie, że po prostu wyrzucam z siebie wszystko, co mam w głowie.
Greg: O to mi chodziło — żebyś wyrzucił to wszystko, tak jak radziłbyś swojemu siostrzeńcowi albo dwudziestodwulatkowi świeżo po studiach. Co jeszcze ludzie muszą wiedzieć poza agentami chmurowymi i automatyzacjami?
Ryan: Chmura i automatyzacje — z tymi dwoma chcę, żeby ludzie wyszli. Trzecia rzecz: naprawdę będziesz używać fabryki oprogramowania. Mam na myśli to, że agenci będą pisać 100% twojego kodu, przeglądać 100% i wysyłać 100% — tam zmierzamy. Im szybciej się tam znajdziesz, tym lepiej.
I rzecz czwarta: ważne jest budowanie sobie wiarygodnej reputacji. Praca, którą włożyłem przez ostatnie 20 lat na X, naprawdę procentuje. Jeśli publicznie dzielisz się tym, czego się uczysz, i piszesz pomocne artykuły, to buduje wiarygodność. Algorytm wciąż nagradza artykuły, więc powinieneś je pisać. Powinieneś być na X, niezależnie od tego, co myślisz o Elonie. Nie chodzi tylko o zarabianie na postach, ale o sieć kontaktów i relacje. Jestem na tym podcaście właśnie dlatego, że zbudowaliśmy relację przez X. Zachęcam: poświęć czas, by dzielić się tym, czego się uczysz. Nie musi to być super dopracowane. Bądź użyteczny dla ludzi, a to otworzy drzwi — bardziej, niż myślisz. Nie od razu, ale z czasem.
Greg: Nawet jeśli czegoś nie wiesz, możesz po prostu powiedzieć „nie wiem” — i to też jest strategia.
Ryan: Amen. A jeśli nie wiesz, poproś agenta, żeby ci pomógł.
Greg: Moim pierwotnym współprowadzącym był Sahil Bloom. Pracował w private equity, a podczas pandemii zaczął pisać o tematach, które go interesowały — finansach, ciekawych postaciach — trochę jak artykuły z Wikipedii, ale zoptymalizowane pod Twittera. Nie mówił „wiem wszystko”, tylko „uczę się tej rzeczy, oto co odkrywam”. Urósł do ponad miliona obserwujących, napisał bestseller „New York Timesa”, założył firmy i zebrał fundusz. Na X naprawdę wszystko jest możliwe.
Ryan: Po prostu wyjdź do ludzi, działaj i ucz się. Jak mówi Yoda: nie ma „próbować”, jest tylko „robić”.
Greg: Ryanie Carsonie, czuję się mądrzejszy — a to był mój cel. Jesteś wspaniałą osobą do obserwowania, wrzucę linki, w tym do X. Dziękuję, że przyszedłeś i podzieliłeś się hojnie swoimi przemyśleniami i niesamowitym stanowiskiem pracy.
Ryan: Dzięki, Greg, że mnie zaprosiłeś. Doceniam, że nieustannie dzielisz się wiedzą — dzięki temu internet jest lepszym miejscem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Twoja nowa rola to menedżer floty agentów
Na czym polega: Niezależnie od dotychczasowego zawodu, twoim zadaniem staje się prowadzenie zespołu agentów AI — jak menedżer inżynierii kierujący wieloma wykonawcami naraz.
Jak stosować: Przestań myśleć o sobie jako o wykonawcy zadań. Zbuduj codzienny rytm zarządzania: rano ustal priorytety, w ciągu dnia rozdzielaj pracę między agentów i zatwierdzaj wyniki. Zacznij od 3–5 równoległych agentów i stopniowo zwiększaj liczbę.
Na co uważać: To wymaga większej, nie mniejszej technicznej wiedzy. Musisz rozumieć podstawy (bazy danych, środowiska, migracje), inaczej nie ocenisz pracy agentów. Nie licz, że „AI zrobi wszystko za ciebie” bez nadzoru.
2.Pracuj w chmurze, nie lokalnie
Na czym polega: Agenci chmurowi działają na maszynach wirtualnych, które startują jednym kliknięciem, więc możesz uruchomić ich dowolnie wielu bez konfliktów kodu i mozolnej konfiguracji lokalnego środowiska.
Jak stosować: Przenieś główny nurt pracy do narzędzia z agentami chmurowymi (Devon, Cursor, coraz częściej Codex). Lokalnie zostaw tylko to, co tego wymaga — np. wczesne szkicowanie ciężkiego front-endu — i jak najszybciej przenoś zadanie do chmury.
Na co uważać: Chmura nie eliminuje potrzeby testowania i przeglądania kodu — zwiększa jedynie przepustowość. Więcej agentów to więcej decyzji do podjęcia, co bywa wyczerpujące.
3.Nastaw się na dziesiątki decyzji wysokiej stawki dziennie
Na czym polega: Przy dużej przepustowości agentów wąskim gardłem stajesz się ty. Zamiast 2–3 ważnych decyzji dziennie podejmujesz ich 10–20 przed lunchem.
Jak stosować: Wyznacz sobie stały rytm sprawdzania — np. co 25 minut — zamiast ciągłego przeklikiwania wątków. „Powoli znaczy płynnie, płynnie znaczy szybko”. Zaplanuj przerwy na regenerację umysłową.
Na co uważać: Ciągłe przeklikiwanie bez rytmu prowadzi do wypalenia. To realnie męczące; przygotuj się, że będziesz pracować więcej, nie mniej.
4.Priorytetyzuj przez przypinanie wątków i listę na papierze
Na czym polega: Prosty system dwóch kubełków: kilka najważniejszych rzeczy na dziś (przypięte) i cała reszta drobnych poprawek, które „puszczasz luzem”.
Jak stosować: Każdego ranka wypisz (choćby na papierze) 2–5 najważniejszych zadań do wysłania dziś. Przypnij odpowiadające im wątki agentów. Do reszty wracaj, gdy masz wolną chwilę.
Na co uważać: Codziennie pojawi się ok. 10 PR-ów „gaszących pożary”, które łatwo rozproszą cię od tego, co naprawdę ważne. Pilnuj, żeby priorytety nie zniknęły pod natłokiem drobnicy.
5.Trzymaj klucze produkcyjne z dala od agentów
Na czym polega: Agenci prędzej czy później zrobią coś destrukcyjnego na produkcji, dlatego kluczy z prawem zapisu nie powinni mieć na stałe.
Jak stosować: Przechowuj klucze produkcyjne w menedżerze haseł (np. 1Password). Ustaw proces, w którym agent prosi o klucz, gdy musi zapisać coś na produkcji, a ty świadomie wklejasz go do sesji, wiedząc dokładnie, co się dzieje.
Na co uważać: „Świadome wklejenie” to moment kontroli — nie automatyzuj go bezmyślnie. Oddziel środowisko deweloperskie od produkcyjnego, żeby eksperymenty agentów nie dotykały realnych danych klientów.
6.Zamieniaj cykliczne przeglądy w automatyzacje
Na czym polega: Wszystko, co robiłbyś na cotygodniowym lub codziennym spotkaniu kontrolnym, można oddać automatyzacji uruchamianej przez agenta co X dni.
Jak stosować: Wybierz powtarzalną kontrolę (test rejestracji, przegląd zdarzeń), opisz agentowi krok po kroku, jak ją wykonać (w Devonie to „playbook”), i ustaw harmonogram. Dołóż mechanizm powiadamiania (np. post na Slacku przez MCP), żebyś wiedział o wynikach.
Na co uważać: Automatyzacje kosztują — test w przeglądarce potrafi zjeść ~60 dolarów w tokenach, więc dobierz częstotliwość rozsądnie. Zadbaj o widoczność wyników: agent może „po cichu” zawieść i sam się naprawić, a ty tego nie zauważysz.
7.Zbuduj „production watchdog” z linkami do realnego UI
Na czym polega: Codzienny automatyczny raport podsumowujący, co robili twoi kluczowi klienci — jak briefing od szefa sztabu.
Jak stosować: Ustaw automatyzację, która co rano przechodzi przez zdarzenia płacących klientów, streszcza je i pokazuje w panelu admina. Przy najważniejszych klientach dodaj bezpośrednie linki „zobacz, co robił klient”, by móc jednym kliknięciem wejść w szczegóły.
Na co uważać: Bez linków do prawdziwego interfejsu raport traci wartość — to wychwycenie wzrokiem „czegoś dziwnego” daje najwięcej. Nie zakładaj, że wiesz, co się dzieje w produkcie; zwykle nie wiesz.
8.Uruchom pętlę samodoskonalenia opartą na rubryce
Na czym polega: Agent codziennie ocenia najważniejszą część produktu według zdefiniowanej rubryki i automatycznie odpala poprawki (PR-y) tam, gdzie wynik jest poniżej progu.
Jak stosować: Wskaż agentowi jeden kluczowy obszar (np. rozmowy z klientami), opisz kryteria oceny „dobre/złe”, i ustaw codzienny przebieg: oceń, a poniżej progu uruchom podrzędną sesję naprawczą. Przeglądaj gotowe PR-y i wysyłaj te wartościowe.
Na co uważać: Pętla wychwytuje drobne „paper cuts”, których sam byś nie ruszył — to zaleta, ale i źródło szumu. Zachowaj człowieka w pętli przy zatwierdzaniu, bo modele wciąż nie mają „zdrowego rozsądku” co do tego, co jest oczywiście złe.
9.Panuj nad kosztami przez routing modeli
Na czym polega: Realistyczny budżet to ok. 5 tys. dolarów miesięcznie na pracownika inżynieryjnego; powyżej trzeba kierować zadania do właściwych modeli — drogich do trudnych, tanich (jak dostrojony SWE 1.7) do pętli i rutyny.
Jak stosować: Nie odpalaj premium modelu do wszystkiego. Używaj inteligentnego modelu-„rodzica” do koordynacji, a tańszych „dzieci” do masowej pracy. Powierz routing niezależnemu labowi, który dobierze model pod zadanie.
Na co uważać: Tanie tokeny w Claude Code i Codeksie są dziś dotowane — to nie utrzyma się długo, więc nie buduj na tym założeniu kosztowego modelu firmy. Bez routingu rachunki potrafią sięgnąć 20 tys. dolarów miesięcznie.
10.Nie uzależniaj firmowej inżynierii od jednego frontier labu
Na czym polega: Opieranie całej „fabryki oprogramowania” wyłącznie o Claude Code lub Codeksa grozi zamknięciem w „ogrodzonym ogródku” — cudzych modelach, cenach i procesie.
Jak stosować: Dla jednoosobowego projektu abonament za ~200 dolarów u jednego dostawcy wystarczy. Ale gdy masz dopasowanie do rynku i zaczynasz zatrudniać, przenieś fabrykę do niezależnego labu (Devon, Factory, AMP, po części Cursor), który optymalizuje koszt i wynik, a modele różnych dostawców i tak możesz w nim wykorzystywać.
Na co uważać: Budowanie własnej fabryki ma sens dopiero przy dużej skali (jak Ramp z wewnętrznym „Inspect”) — dla mniejszych to marnotrawstwo. Codeksa czy Claude Code spokojnie używaj do lokalnej pracy informacyjnej, ale nie jako fundamentu produkcyjnej inżynierii.