Inżynieria agentowa w 2027 roku będzie wyglądać zupełnie inaczej

O czym jest ten film

Po premierze modeli Astra i Opus 5.5 agenci przejmują coraz większą część pracy programistów, matematyków, montażystów czy grafików — a i tak wszyscy dopiero rozkręcamy ich możliwości.
Ludzie wciąż wygrywają w trzech obszarach: nowatorskim myśleniu, praktycznym wyczuciu (co pominąć przy ograniczonym czasie) i smaku, czyli wiedzy, co jest naprawdę dobre.
Autor porównuje obecny przełom do mechanizacji rolnictwa: w 1800 roku ponad 75% Amerykanów pracowało na farmsach, dziś poniżej 2%, a jedzenia jest więcej niż kiedykolwiek.
Praca z AI to drabina: wykonywanie zadania → sterowanie agentem → projektowanie pętli agentowych → prowadzenie fabryki software’u. Większość ludzi utknęła na pierwszym lub drugim szczepblu.
Człowiek stał się wąskim gardłem: setki agentów czekają na naszą reakcję, więc przyszłością są triggery (harmonogramy, webhooki, awarie), a nie ręcznie wpisywane prompty.
Laptop zabija skalowalność — agenci lokalne umierają wraz z zamknięciem pokrywy, a według wewnętrznych danych Cursora udział agentów chmurowych w zmianach trafiających na produkcję wzrósł w tym roku z ok. 10% do ponad 60%.
Praca wyższego rzędu to zarządzanie zespołami agentów, przydzielanie budżetu (tokeny vs. pensje vs. reklama), dobór modelu do zadania oraz ewaluacje i benchmarki.
Autor pokazuje na żywo swoje automatyzacje (przegląd billingów, kontrola bazy, testy bezpieczeństwa, polowanie na brakujące testy) i buduje nową głosem w mniej niż minutę.
Ekonomia tokenów wg SemiAnalysis: subskrypcja Claude Code za 200 dolarów daje obecnie kilkukrotnie więcej wartości niż porównywalny plan Codex; pracę jednej firmy warto recenzować modelem drugiej.
Główna teza: przepaść między osobami na cutting edge AI a resztą rośnie, a najbardziej wartościową umiejętnością staje się… myślenie z pierwszych zasad.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Człowiek, nie model, jest wąskim gardłem

Na czym polega: Modele są już na tyle szybkie i tanie, że problemem nie jest ich jakość ani koszt tokenów, tylko to, że czekają na Twoją reakcję. Tysiące wątków zatrzymuje się na ludzkim zatwierdzeniu.

Jak stosować: Przejrzyj własną pracę z agentami i policz, ile razy dziennie to Ty coś uruchamiasz lub odblokowujesz. Każde takie miejsce potraktuj jako kandydata do zastąpienia triggerem: harmonogramem, webhookiem, reakcją na awarię lub zachowanie klienta.

Na co uważać: Nie projektuj automatyzacji, która i tak kończy się na Tobie — to tylko przeniesienie wąskiego gardła o krok dalej. Zastanów się też, czy nowa automatyzacja rzeczywiście oszczędza czas, czy tylko generuje śmieciowe wyniki.

2.Zacznij od 5% pracy, nie od wielkiego projektu

Na czym polega: Większość z nas wykonuje codziennie ten sam typ zadań (maile, Slack, zgłoszenia klientów). To naturalny materiał na pierwsze pętle agentowe — zaczynając od małego, przewidywalnego wycinka.

Jak stosować: Najpierw zmierz, gdzie faktycznie idzie Twój czas — choćby przeglądem kalendarza przez dwa tygodnie. Potem zautomatyzuj najbezpieczniejsze 5% pracy, sprawdź wyniki i weź się za kolejne 5%.

Na co uważać: Ludzie fatalnie szacują swój czas (ktoś myśli, że poświęca coś 20% dnia, a okazuje się 60%). Bez pomiaru zoptymalizujesz niewłaściwe rzeczy.

3.Fabryka software’u to wiele pętli agentowych

Na czym polega: Pojedyncza pętla to: trigger → praca agenta → sprawdzenie efektu → powtórka. Fabryka to zestaw różnych pętli działających równolegle — i najlepiej bez człowieka w środku.

Jak stosować: Wyobraź sobie, że Twoja firma jest dziesięciokrotnie większa, i spytaj: jakie działy by miała? Zespół od bazy danych, od płatności, od bezpieczeństwa, od wsparcia klienta. Następnie zbuduj po jednej pętli dla każdego takiego „działu”.

Na co uważać: Na nadmierne ambicje na starcie. Nowa automatyzacja zwykle wymaga kilku poprawek, zanim przestaje marnować tokeny i zaczyna dawać realną wartość.

4.Wynieś agentów z laptopa do chmury

Na czym polega: Agent lokalny umiera wraz z utratą Wi‑Fi, baterii lub zamknięciem pokrywy. Agent chmurowy działa w odizolowanej piaskownicy, płacisz tylko za czas pracy i możesz uruchomić ich setki bez konfliktów o CPU, RAM i ekran.

Jak stosować: Wszystko, co ma działać „zawsze” — monitoring bazy, przeglądy bezpieczeństwa, reakcje na zgłoszenia — przenieś na serwer o wysokiej dostępności, skalowalny w obie strony.

Na co uważać: Silna stacja robocza rozwiązuje problem tylko do pewnego pułapu. Gdy potrzeba nagle 20% więcej mocy na tydzień, lokalny sprzęt zmusza Cię do zakupu kolejnej maszyny.

5.Uruchamiaj dziesiątki agentów jedną instrukcją

Na czym polega: Zamiast startować agentów pojedynczo, zaprojektuj jeden „kierowniczy” agent, który rozkazuje wielu. W demku autora jeden agent odpala 110 innych: kierownik na Opusie, koordynatorzy na Sonnecie, wykonawcy na Haiku.

Jak stosować: Znajdź zadanie, w którym 20–100 agentów zrobi sensowną robotę (analiza kodu, research, testy), zdefiniuj im umiejętności, zasady i proces rewizji — i przetestuj na małej flocie.

Na co uważać: Sama liczba agentów nic nie znaczy. Jeśli prowizorycznie „natrzaskasz” setki wątków bez reguł kontroli jakości, dostaniesz masę niskiej jakości wyników.

6.Model dopasuj do zadania jak narzędzie do pracy

Na czym polega: Nie każdy zadanie zasługuje na najdroższy model. Proste rzeczy mogą biec na tanim DeepSeeku czy Haiku, decyzje strukturalne na modelu decyzyjnym, a najtrudniejsze na Opusie 5.5.

Jak stosować: Sklasyfikuj swoje typy zadań według trudności i stawki. Przy 50 000 dolarów miesięcznego przychodu traktuj wydatki na tokeny jak każdy inny budżet operacyjny — obok pensji, reklam i sprzętu.

Na co uważać: Dana równowaga cenowa zmienia się co kilka tygodni. Sprawdzaj aktualne analizy (np. SemiAnalysis, Artificial Analysis), zanim zawiążesz się z jedną subskrypcją na dłużej.

7.Recenzuj pracę agenta modelem konkurencji

Na czym polega: Autor buduje niemal wyłącznie modelem jednej firmy (Opus), a każdą poważniejszą zmianę każe przeglądać modelowi drugiej (GPT 6.1 Soul) — w trybie adwersaryjnym, czyli „znajdź argumenty, czemu to jest złe”.

Jak stosować: Wprowadź zasadę krzyżowej rewizji: kod napisany przez model firmy A sprawdza model firmy B. Jeśli oba modele się zgodzą, efekt trafia do Ciebie po finalną akceptację.

Na co uważać: Rewizja tym samym modelem, który napisał kod, łatwo potwierdza własne błędy. Krzyżowa kontrola kosztuje trochę tokenów, ale wychwytuje „zamydlone” wnioski.

8.Ciągłe testy bezpieczeństwa to nie opcja, tylko konieczność

Na czym polega: Autor uruchamia automatyczny „przeciąg bezpieczeństwa” co 90 minut — agentowe testy penetracyjne własnego kodu. Argument: w przyszłości wygra ten, kto wydaje więcej tokenów na atakowanie i obronę swojego software’u.

Jak stosować: Nawet jako jednoosobowy zespół zaprojektuj pętlę, która regularnie próbuje znaleźć luki w Twoim kodzie i danych. Druga korzyść: agent chmurowy w piaskownicy, gdy zostanie przejęty, oznacza stratę jednej piaskownicy — a nie całego laptopa.

Na co uważać: Wdrożenie tego za pół roku, gdy zrobi to każdy, nie daje żadnej przewagi. Dziś atakują też inni — prompt injection potrafi nakłonić agenta do pobrania złośliwego pakietu.

9.Zamień subskrypcyjny limit tokenów na przychód

Na czym polega: Zostawianie ponad połowy tygodniowego limitu niewykorzystanym to marnowanie zasobu, który według analiz jest dotowany nawet ~90% względem cen API. Obniżanie planu to przyznanie się, że nie umiesz zamieniać tokenów na pieniądze.

Jak stosować: Zamiast oszczędzać na subskrypcji, skieruj nadwyżkę mocy na realne cele: poprawę marketingu, jakości produktu, bezpieczeństwa, automatyzację powtarzalnych zadań.

Na co uważać: Kluczowa umiejętność przyszłości brzmi banalnie, ale jest trudna: czy tokeny generują więcej wartości, niż kosztuje abonament? Jeśli nie — problem leży w pomysłach, nie w modelu.

10.Myślenie to teraz najtwardsza część pracy

Na czym polega: Klikanie po interfejsach i wykonywanie procedur przestało być trudne — to zrobi agent. Trudne jest rozumowanie z pierwszych zasad: o ludzkich zachowaniach, dynamice rynków i skutkach drugiego oraz trzeciego rzędu.

Jak stosować: Wprowadź codzienną sesję 60–90 minut bez telefonu i komputera: jedna hipoteza, rozmowa na głos, nagranie. Pierwsze 10 minut będzie jałowe — nie wstawaj od stołu, dopóki nie popłyną pomysły.

Na co uważać: Ludzie zrobią niemal wszystko, żeby uniknąć wysiłku myślenia — w tym oddadzą dekadę nużącej pracy. Jeśli sam przed tym nie uciekasz, agenci wyrównają resztę.

Redakcyjne tłumaczenie

Wstęp: 2000 godzin z agentami i jedno niewygodne pytanie

Nazywam się David Ondrej. W ciągu ostatnich czterech lat spędziłem ponad 2000 godzin na programowaniu z AI i osobiście rozmawiałem z najciekawszymi ludźmi tej branży. W tym materiale pokazuję, jak agenci przejmują ludzką pracę, po co całkowicie nowy sposób ich uruchamiania, dlaczego pętle agentowe i fabryki software’u są nieuniknione oraz dlaczego agenci chmurowi wypierają lokalnych. Wyjaśnię też, jak moja i Twoja praca będzie wyglądać za dwanaście miesięcy — a na końcu na żywo zbuduję od zera mini-fabrykę software’u i pokażę, jak robię to na co dzień.

Agenci wchodzą na nasze stanowiska

Praca agentowa ewoluuje. To już nie tylko siedzenie z Claude Code czy Codexem i dzielenie się podpowiedziami. Wszystko zmieniły premiery Astry i Opusa 5.5. Sporo wiarygodnych ludzi uznało, że Astra to AGI — a nawet jeśli nie, dowody są przed oczami. OpenAI opublikowało przed kilkoma dniami repozytorium, które wywróciło świat matematyków do góry nogami: jakieś 370 dowodów problemów, przez dekady i stulecia uważanych za nierozwiązane.

Nie będę Was okłamywał: wszyscy jesteśmy zastępowani. Programiści, montyżyści wideo, matematycy, graficy, twórcy treści — AI potrafi coraz więcej. Nasuwa się więc pytanie: co właściwie będzie robił człowiek? Wrócę do niego pod koniec, bo to pytanie egzystencjalne, przez które wiele osób traci sen. Tymczasem istnieje na nie bardzo konkretna odpowiedź i jasna droga naprzód — tylko niewielu osób ją przemyślało.

W czym ludzie wciąż wygrywają

Ludzie pozostają lepsi od agentów w wielu rzeczach. Brzmi banalnie, ale spójrzmy na sedno: duże modele językowe są z natury bardziej „mechaniczne”. Dostają dane wejściowe i coś z nimi robią. Same nie generują celów, nie przychodzą im do głowy losowe myśli po drodze, a ich łańcuch rozumowania widać na wylot — bo pochodzi z danych treningowych.

Po pierwsze: kreatywne, nowatorskie myślenie, intuicja i instynkt. Przez całe życie „przerabiamy” ogromną liczbę bodźców — dźwięków, dotyku, doświadczeń fizycznych — których w ogóle nie ma w tekście z internetu, czyli w danych treningowych modeli. A jeśli czegoś nie ma w danych treningowych, agent jest w tym słaby.

Po drugie: praktyczność. Masz wielki projekt i tylko godzinę na jego skończenie — agent nie rozumie, co to znaczy. Sam z siebie nie powie: „pomiń te detale” albo „nie zalewaj repozytorium bezliku testów”. Nie ma wyczucia, jak rozdzielać ograniczone zasoby.

Po trzecie: smak. Każdy może dziś wygenerować AI dziesięć tysięcy aplikacji albo setki obrazków, ale wiralowa będzie jedna, pieniądze zarobi garstka. Wiedza, co czyni świetny produkt, świetną miniaturkę na YouTube czy świetną piosenkę — to właśnie smak, i to rzadka cecha. Ludzie, którzy go mają, będą przed agentami wygrywać.

Dlatego przestań się kurczowo trzymać tego, w czym modele są lepsze. Jeśli wciąż piszesz kod linijka po linijce, zamiast używać Codexa czy Claude Code, nie wiem, co Ci powiedzieć. Jesteś jak chłopiec od windy w epoce wind z przyciskami albo jak człowiek liczący arkusze ręcznie po wynalezieniu kalkulatorów. Rób to, w czym człowiek wygrywa, resztę oddaj agentom. Inaczej będzie bardzo źle.

Lekcja z rolnictwa: nie panikuj

Żeby zrozumieć, dokąd zmierza przyszłość, warto zajrzeć w przeszłość — a rolnictwo to znakomita analogia. W Ameryce w 1800 roku ponad 75% wszystkich pracujących było zatrudnionych w gospodarstwach. To była zdecydowana większość społeczeństwa. Dziês to poniżej 2% — a jedzenia jest więcej niż kiedykolwiek. Dlaczego? Dzięki technologii.

Patrząc na zdjęcia robotników z pola, dosłownie widzę nas samych: klikających po formularzach, składających wnioski, ogarniających podatki i księgowość. Druga strona tej analogii — zmechanizowane farmy — jest bliższa temu, co nas czeka, choć oczywiście nie oddaje dokładnie, jak będziemy zarządzać agentami.

Krótko mówiąc: przestań się bać. Przeszliśmy już kilka rewolucji przemysłowych. Były kiedyś „ludzkie komputery” — piętnastopiętrowe budynki, w których na każdej piętrze ludzie liczli na ręce. Jeden wzorzec powtarza się przez dziesiątki i setki tysięcy lat naszej historii: zawsze się adaptujemy.

Praca wyższego rzędu — i słowo od sponsora

Najczęstszy błąd, jaki widzę u początkujących założycieli, to za mało kontaktu z prawdziwymi użytkownikami. Z AI buduje się software szybciej — ale im szybciej budujesz, tym ważniejsze stają się dane od klientów. W końcu trzeba wiedzieć, czy buduje się właściwą rzecz.

Fragment sponsorowany (PostHog). Autor polega tutaj na swoich dotychczasowych narzędziach analitycznych: PostHog pokazuje, jak ludzie realnie korzystają z produktu — gdzie utykają, których funkcji używają i czy wracają — a dzięki odtwarzaniu sesji widać dokładnie, co robili. Z rozwiązania korzystają m.in. Supabase, Fireworks AI, ElevenLabs, Railway i startupy z Y Combinator; Supabase dzięki tym danym zauważyło falę użytkowników z budowniczych aplikacji AI i na tym oprzeło partnerstwa („PostHog pomógł nam zdobyć dziesięciokrotnie więcej nowych użytkowników tygodniowo niż rok temu” — cytuje autor). Link: go.posthog.com/david.

Drabina pracy: od klikania do prowadzenia fabryki

Dziś po prostu wykonujesz zadanie — siadasz przed komputerem i robisz konkretną rzecz. Jeśli oglądasz mój kanał, to miejmy nadzieję, że uruchamiasz już agentów: Codexa, Claude Code, Cursora, Pie, Hermesa. To już poziom wyżej niż robienie wszystkiego samemu.

Ale większość ludzi utknęła właśnie na pierwszym lub drugim szczeblu — a czas przejść wyżej. Kolejny stopień to projektowanie pętli agentowych, a następnie prowadzenie fabryki agentów. Im wyżej w tej drabinie, tym praca jest mniej ręczna i mniej powtarzalna, a bardziej unikalna, kreatywna i abstrakcyjna.

Koniec z uruchamianiem agentów pojedynczo

Bądźmy konkretni: w przyszłości nikt nie będzie startował agentów jeden po drugim. To relikt — tak żyło się w 2024, 2025, a nawet przez pierwsze trzy kwartały 2026 roku. Dziś to przestało wystarczać.

I uwaga: przepaść między osobami na prawdziwym cutting edge a tymi „takimi sobie” użytkownikami AI będzie się rozszerzać. Pomyśl o przeciętnym użytkowniku: darmowy ChatGPT, darmowe Gemini, wyszukiwanie AI od Google. To żałośnie słabe modele w porównaniu z Opusem 5.5 w trybie extra high czy max.

W przyszłości będziemy projektować rzeczy, które działają według harmonogramu — i to nie my będziemy te agenty uruchamiać. Wszystko, co wymaga człowieka, ma ograniczoną przepustowość. To jak w biznesie: prezes pięciotysięcznej firmy nie może decydować o myciu podłóg, zamknięciu ksiąg, zwolnieniu juniora czy zakończeniu kampanii marketingowej. I właśnie tak trzeba o tym myśleć: niedługo każdy z nas będzie prowadzić „firmę” na pięć tysięcy podmiotów — część to ludzie, większość to agenci.

Warto pamiętać, że AI to dziedzina osiemdziesięcioletnia i wiele przełomów powstało przez naśladowanie biologii — sieć neuronowa wzorowana jest na mózgu. Obecny limit skalowania agentów jest prozaiczny: nie jesteś w stanie ich wszystkich odblokowywać. Zwłaszcza po Opusie, który działa tak szybko, że utrzymanie więcej niż pięciu agentów naraz to już wyzwanie. Gdy to przemyślisz, wniosek nasuwa się sam: człowiek musi wyjść z pętli. Kiedyś rządziła zasada „człowiek w pętli”. Teraz musimy się z tej pętli usunąć.

Potrzebujemy więc różnych mechanizmów startu zamiast ludzkiego promptu: harmonogramów, webhooków, reakcji na awarie, na zachowania klientów. Prompt głosowy jest lepszy niż pisanie, ale wciąż angażuje Twoją uwagę i czas. To wystarczało może sześć–dwanaście miesięcy temu. Już nie.

Czym właściwie będziemy się zajmować

Zadam teraz pytanie, które na moim podcaście zadaję każdemu gościowi — i ludzie, nawet ci z samej granicy rozwoju AI, mają z nim problem, bo odpowiedź nie jest oczywista. Niektóre elementy widać „we mgle”, ale nie wiemy, co kryje się za mgłą. Na podstawie tego, co wiamy dziś:

będziemy tworzyć nowych agentów — wyspecjalizowanych lub ogólnego przeznaczenia;
będziemy zarządzać ich zastępami: zespół agentów od marketingu, zespół od produktu, zespół od wsparcia klienta;
będziemy przydzielać zasoby: firma zarabia 50 000 dolarów miesięcznie — ile na tokeny, ile na pensje, ile na reklamy, ile w sprzęt;
będziemy dobierać modele do zadań: to proste zadanie, więc może tani i wydajny DeepSeek v4.1 Flash; ta decyzja jest ważna, więc model decyzyjny ze zwracaniem uporządkowanej odpowiedzi; to zadanie krytyczne, więc najlepiej z najlepszych — Opus 5.5, a w przyszłości może Fable 5.5 albo Astra 6.1;
ustawimy ewaluacje: jaki odsetek zadań wykonują agenci, a ile ludzie, ile tokenów spalamy — benchmarki i pomiary;
i będziemy po prostu więcej myśleć: jak podnieść ten biznes na wyższy poziom, gdzie dodać kolejnych agentów, czego jeszcze nie robimy.

To jest prawdziwa praca — taka, którą dziś wykonują prezesi i kadra zarządzająca. Tylko że wykonywać ją będą wszyscy, bo całą resztę przejmą agenci.

Pętla agentowa i fabryka: definicje i pierwsze 5%

Wokół pętli agentowych narosło sporo zamieszania — była moda na dyskusje w stylu „pętle kontra grafy”. Zignoruj to całkowicie. Praktycznie: fabryka software’u to po prostu wiele pętli agentowych. Pojedyncza pętla może jeszcze trzymać człowieka przy zatwierdzaniu, ale porządna fabryka nie powinna — ma działać sama.

Pętla agentowa to próba usunięcia samego siebie z procesu. I tu wraca rada, którą dawałem już dwa, trzy lata temu: nie próbuj automatyzować wszystkiego naraz. Zacznij od małego zadania. Prawda jest taka, że ty i ja wykonujemy codziennie te same typy zadań. Zmiana następuje dopiero, gdy ruszasz radykalnie nowy projekt — zakładasz firmę, piszesz książkę. Reszta to odpowiadanie na podobne maile, ten sam Slack, kolejne zlecenia dla klienta. Może nie dokładnie to samo każdego dnia, ale ten sam typ pracy — a to gotowy materiał na automatyzację. Kiedyś nie dało się tego zrobić zwykłym kodem. Dziś da się agentem.

Różnica robi się teraz w modelach i w nakładkach, w których działają („harness” — narzędzie spinające model z Twoim komputerem i umiejętnościami, jak Claude Code czy Codex). Postęp w tym roku był gigantyczny: najpierw Claude Code, w styczniu OpenClaw, w lutym agent Hermes, potem ogromną popularność zdobył Pi, doszedł Prime — agent samodoskonalący się. A że większość z nich jest open source, gdy jedna nakładka coś ulepszy, wszystkie przejmują pomysł. Taki urok otwartego kodu (szkoda tylko, że same modele przestały być otwarte). Efekt: w ciągu ostatnich 6–12 miesięcy możliwe stało się to, co wcześniej nie wchodziło w grę — pełne projekty graficzne, animacje, szalone rzeczy, zwłaszcza po Opusie 5.5.

Nie masz więc wymówki, żeby robić wszystko ręcznie. Zacznij od zautomatyzowania 5% pracy — tego, co najbardziej przewidywalne i bezpieczne. Potem weź następne 5%.

Zmierz, gdzie idzie Twój czas

Skąd wiedzieć, co automatyzować? Ja od lat zapisuję w kalendarzu, co robię, w odstępach piętnastu minut. Mam więc kupę danych — i mogę na żywo poprosić agenta (przez Composio CLI, wewnątrz CloudRoom): „Zobacz, na co wydałem ostatnie czternaście dni. Pomijaj sprawy prywatne — nagrywam materiał, który zobaczy dziesiątki tysięcy osób. Podaj szerokie kategorie”. Agent odpala się, po trzydziestu sekundach mam wynik.

Tak wygląda analiza. Musisz wiedzieć, dokąd płynie Twój czas — tak samo jak śledzisz wydatki w księgowości, żeby wiedzieć, co optymalizować. Większość ludzi nie ma pojęcia: ktoś sądzi, że coś zajmuje mu 20% czasu, a okazuje się 60%; ktoś uważa się za osobę „często trenującą”, a na siłownię chodzi trzy razy w miesiącu.

I jeszcze jedno: w każdej firmie najbardziej wartościowym zasobem jest czas szefa. Nie obchodzi mnie, czy mówimy o SpaceX i Elonie Musku, czy o trzyosobowym zespole. Mój zespół jest mały, a i tak ja blokuję niemal wszystko — niezależnie od tego, jak bardzo ludzie obok mnie są w temacie. Jeśli prowadzisz firmę, Twój czas to najcenniejszy zasób. Znajdź sposób, żeby go mierzyć, a potem zamieniaj te 5% na pętlę agentową albo mini-fabrykę.

Błąd: zakładanie, że nic się nie zmieni

Wielu ludzi wierzy, że praca z agentami będzie wyglądać tak jak dotąd z ChatGPT, Claude, Perplexity czy Cursor — bo tak działa interakcja. A nie będzie. Z Astrą i Opusem 5.5 doszliśmy do punktu, w którym to my jesteśmy wąskim gardłem — i to jest poważny problem. Wszyscy wiemy, że powinniśmy uruchamiać więcej agentów. A nie robimy tego.

Co blokuje? Już nie modele ani tokeny. Tokeny są tanie — a inteligentne tokeny też są tanie. To, co dostajesz za 200 dolarów abonamentu, graniczy z absurdem; a jak nie masz budżetu, OpenCode daje niewiarygodną wartość za darmo. Kto inwestuje we własny sprzęt i self-hosting, ten po zakupie ma tokeny praktycznie za darmo. To też nie nakładki. Czego więc brakuje? Wszystkiego innego. To bardzo abstrakcyjny problem i spędzam nad nim większość czasu.

Mam świetną wizualizację sytuacji: dziesiątki agentów po prostu na nas czekają. Gdy odpalam 30, 40, 50 agentów naraz, czekają właśnie na mnie. Mogę otworzyć pasek boczny i pokazać: setki otwartych wątków, a wszystkie czekają. Oprócz automatyzacji i fabryk, które działają bardziej samodzielnie. To ja blokuję agentów. To ja blokuję postęp.

I z tego rodzi się prawdziwe wyzwanie: jak zaprojektować pętlę, automatyzację, fabrykę, która działa bez Ciebie? Jak usunąć siebie z procesu? Przestań zakładać, że to Ty będziesz wysyłać prompty — głosowo czy pisemnie. Kto Ci to mówi, ten żyje w przeszłości. Mogło to być prawdą pół roku temu. Już nie jest. Dziedzina zmienia się błyskawicznie — trzeba to zaakceptować, odseparować emocje i zobaczyć tę grę taką, jaka jest, a potem w nią zagrać.

Cała konstrukcja ma dwie połówki: trigger (co uruchamia jednostkę pracy) i wykonanie (mocny model plus umiejętności, kontekst, MCP‑y i API, które mu dasz). Rozpoznanie dobrego triggera — harmonogram, webhook — i dobrej jednostki pracy to jedna sztuka. Skompletowanie agentowi narzędzi to druga.

Liczba agentów w naszym życiu rośnie lawinowo. Dziś w danym dniu współpracuję z setkami różnych agentów — rok temu tak nie było. I za rok będzie ich jeszcze więcej. Wyzwanie polega na tym, żeby dojść tam szybciej niż inni — i zyskać przewagę, której nikt nie nadrobi.

Trilionowe pytanie i problem laptopa

Spróbujmy odpowiedzieć na pytanie warte biliony dolarów: dlaczego nie uruchamiamy więcej agentów?

Zacznijmy od problemu laptopa. Wyobraź sobie, że przychodzisz do nowej pracy, a firma mówi: „laptop dzielisz z dwudziestoma osobami”. Dokładnie to oznacza uruchamianie wielu agentów na jednym laptopie. Git worktree (Informacja dodatkowa: worktree — odizolowana kopia drzewa plików repozytorium, pozwalająca pracować nad kilkoma zadaniami naraz) trochę pomaga, ale prędzej czy później agenty zaczną się gryźć. A przy computer use w ogóle robisz sobie koło na szyję: agenci otwierają losowe okienka i karty przeglądarki, podczas gdy Ty próbujesz pracować.

Jest gorzej: zamykasz laptopa — agenci umierają. Padło Wi‑Fi — umierają. Siadła bateria — przestają działać. To zbrodnia. Zwłaszcza w perspektywie, w której agenci obsługują 20, 40, 60% zadań Twojej firmy: dostarczają klientom, badają konkurencję, przyprowadzają leady, tworzą kreacje, prowadzą reklamy, pomagają z treścią i produktem, łatają bugi. Jeśli to wszystko zamiera, bo laptop trafił w złe warunki albo padł — Twoja firma padła razem z nim. Wystarczy, że jeden agent uruchomi Docker Desktop i duży zestaw testów, a już słychać wentylatory.

Jeśli budujesz przyszłość, w której agentów wybudza trigger, a nie Twój prompt, potrzebujesz serwera zawsze dostępnego — maszyny w chmurze, dostępnej w 99,99%, z doskonałym łączem, skalowalnej w obie strony. Kupując mocną stację czy Maca Studio, rozwiązujesz problem tylko do pewnej liczby agentów. A jeśli potrzebujesz nagle o 20% więcej? Nie dokupisz „20% do obudowy” — musisz kupić drugą skrzynkę. A jeśli ta nadwyżka jest Ci potrzebna tylko przez tydzień? Sprzęt lokalny nie daje takiej elastyczności.

I sedno: większość z Was fizycznie nie jest w stanie uruchomić setek agentów, bo sprzęt nie wyrabia. A co, gdy pojawi się okazja wymagająca setek agentów naraz — duży klient, okno na rynku? Nie wykorzystasz jej, bo ogranicza Cię komputer. Pokażę, jak my to rozwiązaliśmy. Jeden z inżynierów w CloudRoom po prostu to ogarnął: w CloudRoom możesz powiedzieć jednemu agentowi, żeby uruchomił 110 agentów. To był układ na darmowym planie: najpotężniejszy kierownik na Opusie, koordynatorzy na Sonnecie, wykonawcy na Haiku. Jeden prosty prompt. W tym jest cała dźwignia: zaprojektuj jednego agenta, który potrafi odpalić dziesięciu, zamiast startować robotników pojedynczo. Znajdź zadanie, w którym 20, 50, 100 agentów wykona sensowną pracę — i pomyśl, co zrobić, żeby robili ją dobrze, a nie sypali śmieciami. Umiejętności, zasady, warunki, interfejsy, procesy rewizji — to jest wyzwanie przyszłości.

Sam próbowałem budować wokół tego od dołu: otworzyłem kilka repozytoriów, m.in. „immortal agents” (pod szyldem Vector Labs) — agent, który umiera lub usypia, jest automatycznie restartowany. Zamkniesz laptopa, otworzysz — i wszystko wstaje samo. To tylko narzędzie, ale nakierowało mnie we właściwą stronę. A wielkim problemem okazało się… uruchamianie agentów lokalnie.

Chmura kontra lokal: nieuchronna migracja

Mało kto zna różnicę między agentem lokalnym a chmurowym — a ma fundamentalne znaczenie. Cursor przeprowadził wewnętrzne badanie: na początku roku ledwie 10% pull requestów trafiających na produkcję pochodziło od agentów chmurowych. W sierpniu — ponad 60%. Nie trzeba być geniuszem, żeby zobaczyć w tym krzywą wykładniczą. Wkrótce będzie 90%; pewnie nigdy 100%, bo czasem lokalny agent ma sens — prywatność, sprzątanie folderów. Ale zdecydowaną większość zadań — na pewno ponad 95, a pewnie ponad 98% — da się zrobić lepiej w chmurze.

Na czym polega różnica? Agent lokalny działa na Twoim laptopie: ograniczona ilość CPU, RAM i dysku, kupiona raz i na zawsze. Agent chmurowy działa na serwerze, w odizolowanej piaskownicy — a płacisz tylko za czas, gdy faktycznie pracuje. I nie ma limitu: dziesięć agentów to dziesięć piaskownic, pięciuset agentów — pięćset piaskownic. Pierwszym warunkiem niezawodnych agentów jest po prostu właściwe środowisko, a laptop ogranicza je na wielu poziomach.

Do tego computer use (Informacja dodatkowa: computer use — tryb, w którym agent steruje interfejsem graficznym jak człowiek: klika, wypełnia formularze, obsługuje aplikacje), który w ostatnich trzech–czterech miesiącach zrobił gigantyczny skok. Jeśli nie próbowałeś computer use w Codexie albo agentów typu „driver” przejmujących ekran — dużo tracisz. Agent potrafi wejść w najbardziej pokrętne interfejsy świata — konsole AWS, Google Cloud — i wszystko po nich poprzestawiać. Nigdy więcej nie musisz ich dotykać: dajesz mocnemu modelowi kontrolę nad ekranem i tyle. Problem w tym, że ten ekran Ci zabiera. Okienka, pytania o uprawnienia, nowe karty — a Ty próbujesz pracować. Mniej więcej dwudziestu agentówcomputer use jednocześnie na tej samej maszynie to koszmar.

I wreszcie bezpieczeństwo, ważniejsze z każdym dniem. Rozmawiałem ostatnio z CEO Vercela, Guillermo, który powiedział wprost: „chmura jest dla bezpieczeństwa bezdyskusyjnie lepsza”. Narysujmy to: laptop, a obok zbiór piaskownic w chmurze. Jeśli ktoś przejmie jedną piaskownicę — tracisz tego jednego agenta. Jeśli ktoś przejmie Twoją główną maszynę, bo złożył Ci prompt injection i kazał agentowi pobrać złośliwy pakiet — tracisz wszystko: dane, loginy, cały komputer. Im większa waga cyberbezpieczeństwa, tym większa wartość odizolowanych piaskownic w chmurze.

Moje automatyzacje — kradnij śmiało

W CloudRoom mam cały zestaw automatyzacji, które startują same (widzieliście to na początku filmu). Kilka przykładów:

Przegląd billingów — co cztery godziny agent sprawdza cały kod rozliczeniowy: bugi, nowe problemy, to, co umknęło poprzednio.
Kontrola zdrowia bazy — nagle kilku klientów wstaje naraz i np. jednoczesne połączenia nie wyrabiają, CPU siada, kończy się pamięć. Agent pilnuje, żeby to wychwycić.
Przeciąg bezpieczeństwa — co 90 minut dogłębne testy penetracyjne i audyty cyberbezpieczeństwa kodu. Jeśli tego nie robisz, ktoś zrobi to na Tobie. Przyszłość będzie należeć do tych, którzy wydadzą więcej tokenów na próby złamania software’u, dostania się do danych, zdobycia uprawnień. To nie jest opcjonalne — wszyscy to wdrożycie. Pytanie brzmi: zrobicie to dziś, czy zaczekacie sześć–dwanaście miesięcy, aż stanie się oczywiste — czyli do momentu, w którym przestaje dawać przewagę.

Każdy z tych obszarów to przecież dział dużej firmy software’owej. W pięciotysięcznej firmie byłby zespół od bazy danych, zespół od billingów i płatności, zespół od bezpieczeństwa i autoryzacji. Cokolwiek robisz, zadaj sobie pytanie: gdyby moja firma była dziesięciokrotnie większa, na jakie zespoły by się podzieliła? I buduj pętle agentowe właśnie dla tych części.

Jedna z najlepszych: każdy, kto znajdzie buga w CloudRoom, może powiedzieć „zgłoś to Davidowi”. Automatyzacja co dziesięć minut sprawdza tabelę w Supabase i jeśli pojawia się nowy wpis, uruchamia agenta na Opusie 5.5, żeby zbadał sprawę. Piękno polega na tym, że nie kosztuje to ani minuty mojego czasu: jeśli to drobny przypadek brzegowy albo pomysł nietrafiony — wątek archiwizuje się sam. Jeśli sprawa jest poważna albo pomysł świetny — agent wyjaśnia mi ją kilkoma zdaniami po ludzku i czeka. Najinteligentniejszy model świata, na trybie extra high albo max, bada zgłoszenia i sam zamyka te błędne. To jest ogromna wartość. Mały, zwinny zespół robi dzięki temu więcej niż firmy z pięćdziesięcioma, stu, dwustoma programistami.

Jeszcze jeden, bardziej zaawansowany: test gap. Agenci uwielbiają testy — zalałby Ci cały kod testami jednostkowymi, komponentowymi, integracyjnymi. Ten mechanizm jest subtelniejszy: agent przeszukuje fragmenty kodu pod kątem ewidentnie brakującego testu. Gdy Opus taki znajdzie, uruchamia GPT 6.1 Soul na extra high do rewizji adwersaryjnej — z założeniem, że ten test „nie jest potrzebny”. Dopiero gdy oba modele — autor i recenzent — zgodzą się, że test jest dobry, sprawa trafia do mnie do zatwierdzenia. Tak automatyzacje z czasem stają się coraz sprytniejsze.

Budujcie własne — niezależnie, czy piszecie software, prowadzicie agencję marketingową czy sprzedajecie nieruchomości. Zbadajcie firmy sto razy większe od Waszej: jakie mają działy, jakie zespoły? I od tego zacznijcie. Część automatyzacji będzie biec co dziesięć minut, część co cztery godziny, część na triggery. To sztuka, którą doszlifujesz z czasem. Pytanie jest zawsze to samo: gdzie jeszcze mogę wycelować Opusa, Astrę, GPT‑6? Jaką pętlę, jaką mini-fabrykę odpalić, żeby kierunek był słuszny? Niektóre pomysły skasujesz. Ale jeśli nie będziesz próbować, nie znajdziesz tych świetnych.

Ekonomia tokenów: wojna subskrypcji

Inferencja to jedna z głównych zmiennych prowadzenia fabryk i pętli — ile wydajesz, ile tokenów przepalasz. Opublikowałem niedawno na Twitterze mniej naukową wersję tych liczb i post zrobił się wiralowy; wielu uznało, że przesadzam albo żartuję. A to prawda.

Przed premierą Opusa 5.5 miałem sześć planów Codex po 200 dolarów miesięcznie. Dlaczego? Bo przez dobre trzy tygodnie Astra była najlepszym modelem świata — wyraźnie lepszym od Fable 5.1. Wtedy wyszedł Opus 5.5 — i jedna subskrypcja Claude Code za 200 dolarów daje ten sam wolumen tokenów, a nawet większy, bo Opus jest mnóstwo szybszy od Astry. Stąd moja ostrożna estymacja: 16–20 razy więcej użytkowania niż plan Codex za 200 dolarów. OpenAI zresztą tuż przed dev day połowi limity planu Codex za 200 i wypuściło plan za 500 — cóż, jest, jak jest. Badania SemiAnalysis (Informacja dodatkowa: SemiAnalysis — firma analityczna śledząca rynek AI i koszty inferencji), choć mniej radykalne, potwierdziły około dziesięciokrotnie (10,6×) więcej wartości. Jeśli mieścisz w budżecie tylko jeden plan za 200 dolarów — nie ma nawet dyskusji. Z czystym sumieniem nie mogę dziś polecić planu Codex za 200.

Opus 5.5 jest najlepszy. Możesz się nie zgadzać — to Twój problem, nie mój. Oczywiście za dwa, trzy tygodnie może wyjść kolejny wielki model i wszystko się odwróci; Anthropic jest teraz w doskonałej formie i jeśli wydadzą Fable 5.5, pewnie też będzie najlepszy. Dziś większość moich tokenów pochodzi z jednej subskrypcji Claude Code za 200 dolarów. Dolałem drugą, żeby odpalać więcej pętli — dla jasności: obie płacę z własnej kieszeni, żadna firma mi ich nie opłaca. Wtedy dwanaście setek na sześć planów Codex miało sens, bo Astra miała najlepsze tokeny. Dziś Opus jest bezkonkurencyjny.

A po co mi modele GPT? Do recenzji. Przykład z automatu: szesnaste już wykonanie automatyzacji upraszczającej kod — prompt, cztery minuty dwanaście sekund pracy, Sonnet na maksa, znaleziono miejsce do posprzątania. I teraz odwracam rolę: proszę agenta, żeby uruchomił rewizję i sprawdził, czy to zasadne, zanim zapisze skasowanie. Zawsze recenzuj pracę modelem drugiej firmy. Na froncie są dziś dwie: OpenAI i Anthropic — pozostałe próbują, ale to nie jest nawet blisko. Zbudowałeś coś GPT 6.1 Soul czy Astrą — recenzuj Opusem. Zbudowałeś Opusem 5.5 — recenzuj GPT 6.1. Inna „szkoła” patrzy inaczej i wyłapuje rozbieżności. U mnie 98% wątków biegnie na Opusie, a GPT 6.1 Soul albo Astra (czasem oba, przy poważnych zmianach) robią przegląd — po czym proszę Opusa: „to zasadne, czy przekombinowane?”. I jeszcze jedno: unikaj cen API. Subskrypcje są lepszym interesem; a jeśli już musisz przez API — chińskie modele są znacznie korzystniejsze cenowo. Haiku z Anthropic to obecnie też uczciwa cena. Konkretne liczby znajdziesz w Artificial Analysis.

Triggery: co uruchamia agenta, jeśli nie Ty

To połowa sukcesu. Dziś większość z nas startuje agentów ręcznie — na okres przejściowy ujdzie, ale powinieneś wycofywać się z jak największej liczby takich miejsc. Typy triggerów:

harmonogram — co 15 minut, co 5 godzin, raz dziennie;
webhook — najbardziej elastyczny; baza dobija do 90% limitu połączeń, płatności przestają przechodzić — i leci zgłoszenie;
incydent — awaria bazy, skok błędów;
feedback klientów — im więcej klientów, tym więcej sygnałów;
proaktywne polowanie na bugi — na harmonogramie albo z polecenia innego agenta. I to jest najbliższa granica.

Jedno z moich repozytoriów open source to „Director”: główny agent zarządzający innymi, który z czasem uczy się Twojego stylu pisania promptów i Twojego sposobu podejmowania decyzji. Wyobraź sobie kierownika z piętnastoma, dwudziestoma pięcioma podwładnymi: jeśli masz dobre umiejętności, wiedzę i zasady, i potrafisz ich nauczyć tego mocny model — Director zajdzie zaskakująco daleko i odblokowuje innych agentów sprawniej, niż myślisz. Trigger to połowa układanki. Druga połowa to wykonanie.

Od promptów, przez umiejętności, po przyszłe „sekwencje”

Ludzie patrzą na umiejętności agentów i mówią: „to tylko plik markdown”. Tymczasem to pierwszy krok w stronę automatyzacji i optymalizacji. Najprostsza forma to szablon promptu — coś, co robisz cały czas. Mam w Raycaście całą baterię skrótów, które odpalam szybciej, niż zdążysz zrozumieć, co się stało: „zrób rebase z maina i sprawdź, czy leżący u podstaw kod został już naprawiony — odpowiedz krótko po ludzku”; „nie gadaj w koło, krócej, tylko to, co istotne”; „zrób research cztery razy głębiej i trzy razy zgarnij stronę”; „jest tu coś jeszcze do zrobienia, czy nie?”; „przypomnij mi, po co ten wątek powstał”. Tak pracuję szybciej niż ktokolwiek.

Poziom wyżej: umiejętności — odpowiedniki procedur operacyjnych (SOP) z firm, rzeczy, które łapiesz się na powtarzaniu. Moje repozytorium umiejętności jest open source (ponad 4000 gwiazdek — kradnij śmiało): umiejętności decyzyjne, rewizor GPT do sprawdzania modelem konkurencji, różne typy wydań, computer use i tak dalej.

Ale jeśli uważnie słuchasz — w tej pętli wciąż siedzi człowiek. I to nie jest idealne. Prompty i umiejętności to krok we właściwym kierunku, jednak dalej powinieneś z niej wychodzić; a skoro już musisz być zaangażowany, to przy jednym Twoim gest powinno się dziać więcej.

Mój typ: po umiejętnościach przyjdą sekwencje — łańcuchy kilku umiejętności spinane automatycznie na podstawie prawdopodobieństw wyczytanych z Twojego własnego zachowania. Każdy, kto używa agentów od paru miesięcy, ma na dysku tysiące sesji. Można z nich wyczytać: „w takiej sytuacji David odpala te trzy umiejętności po kolei, w 98% przypadków”. To byłaby sekwencja. Przez najbliższe pół roku optymalizować trzeba będzie równolegle pracę asynchroniczną i synchroniczną człowieka — obie maksymalnie.

Od pętli do fabryki — i dlaczego „mini”

Pętla to trigger, potem agent pracuje, potem jest kontrola — i tak w kółko. Fabryka to wiele różnych pętli, robiących różne rzeczy, działających równolegle dla konkretnego celu — w życiu albo w biznesie. Ja mówię o „mini-fabryce”, bo to wciąż wczesne dni. Nie chcę krzyczeć jak ludzie wywołujący AGI od trzech lat. Uważam, że AGI już nastąpiło — ale nie twierdzę, że to, co mam, to najlepsza możliwa fabryka software’u. Nazwę „fabryka” przypiszę sobie wtedy, gdy naprawdę na nią zasłuży. Moja spinają różne dyscypliny software’owe, bo buduję firmę software’ową; Twoja będzie wyglądać inaczej.

Na żywo: automatyzacja zbudowana głosem w minutę

Pokażę, jak łatwo to idzie. Nowy wątek, tym razem lokalny — żeby było widać, że w CloudRoom da się pracować i lokalnie, i w chmurze. Opus 5.5 na „high” wystarczy. Promptuję głosem:

„Stwórz nową automatyzację: co dwie godziny niech startuje wątek z Opusem 5.5 na extra high. Ma szukać luk produktowych względem wszystkich ADR-ów w katalogu /docs/ADR (Informacja dodatkowa: ADR — Architecture Decision Record, zapis decyzji architektonicznych podjętych w projekcie) i znaleźć jedną oczywistą ulepszenie produktu — funkcję, czytelniejszy interfejs, cokolwiek zgodnego z decyzjami z katalogu /docs. Gdy znajdzie dobry pomysł, niech odpala pod sobą agenta recenzenta na GPT 6.1 extra high z rewizją adwersaryjną: niech szuka argumentów, czemu to NIE powinno trafić do produktu. Po zakończeniu recenzji wynik wraca do agenta głównego, który rozpatruje go z pierwszych zasad. Jeśli się zgadza z recenzentem — archiwizuje oba wątki. Jeśli nie — zostawia wątek otwarty i czeka na mnie, Davida. Zrób to teraz. Prosto, bez przekombinowywania”.

Mniej niż minuta mówienia — i mam automatyzację, która może bez końca ulepszać mój produkt. Uwaga praktyczna: świeża automatyzacja zwykle potrzebuje kilku poprawek w pierwszych uruchomieniach, zanim zacznie dawać dobre wyniki zamiast marnować tokeny. I nie chwal się liczbą plików markdown — słyszałem ostatnio gościa, który chwalił się pół miliona takich plików. Nikogo to nie obchodzi; tani model wygeneruje Ci ich milion. Nie chwal się liniami kodu — to znak nowicjusza.

Ważne rozgraniczenie: duże decyzje produktowe powinny należeć do ludzi, a przy UI/UX wciąż potrzeba smaku. Ale backendowe bugi, optymalizacje bazy, przyspieszanie kodu — w tym wszystkim Opus jest ode mnie lepszy i nie mam wokół tego żadnego ego. Puść to, w czym agenci wygrywają, obejmij to, w czym wygrywasz Ty — i buduj pętle. Agenci są tagowalni, mogą tworzyć złożone relacje i hierarchie — granicą jest tylko Twoja kreatywność. Po tej sesji licznik automatyzacji wskazywał 32 zamiast 31: „luka produktowa co dwie godziny” po prostu działa.

CloudRoom i plan Ultra

Dlaczego agenci chmurni są trudni i dlaczego większość ludzi ich nie używa? Najlepsze produkty są zamknięte i należą do wielkich firm: Codex, Cursor, Claude, Devin od Cognition. Nigdy nie było dobrego rozwiązania, które daje pełną kontrolę nad danymi, eksport rozmów i swobodę wyboru dowolnego modelu, nakładki i subskrypcji. Bo chmura jest wymagająca: wątek musi startować tak szybko jak lokalnie — jeśli nie, ludzie nie zostaną; repozytoria, kontekst i umiejętności muszą tam być; chcesz korzystać z planów, za które już płacisz (inne narzędzia zmuszają do swoich abonamentów i swoich nakładek — a wszyscy płacimy za tokeny więcej niż kiedykolwiek); a agent czasem jednak potrzebuje Twojego laptopa. Każda z tych tarcic osobno wystarczy, żeby ludzie odpuścili.

Właśnie to chcę zmienić w CloudRoom: platforma open source do produktywnego uruchamiania tysięcy agentów — z dowolnym modelem, nakładką i subskrypcją. Obsługuje codzienną pracę (Claude Code, Cursor, Codex, Devin, Pi, OpenCode, Hermes), ale też te futurystyczne kroki: pętle, automatyzacje, fabryki — wszystko z jednego interfejsu, z wyborem: wątek lokalnie czy w chmurze, a każdy wątek chmurowy dostaje własną piaskownicę. Jesteśmy pierwszym narzędziem do kodowania z AI, które daje agenta chmurowego w osobnym środowisku w każdym wątku.

Jasność co do odbiorcy: nie jest to produkt dla każdego. Celuję w przedsiębiorców i superużytkowników — zaawansowanych deweloperów robiących dużo pracy agentowej. Idealna osoba ma już plan za 200 dolarów w Claude Code i plan za 200 w Codexie i czuje potrzebę chmury. Nie moim zadaniem jest przekonywanie — jeśli po tym materiale wciąż nie widzisz sensu, nie przekonam Cię. Zbliżamy się do ogólnodostępnego startu; wcześniej chcę pracować z garstką osób, które mają biznes i potrzebę uruchamiania dziesiątek agentów równolegle. Stąd plan CloudRoom Ultra (cloudroom.dev): osobiste wdrożenie ode mnie i zespołu oraz 10 000 uruchomień agentów chmurowych na 30 dni, każdy we własnym środowisku.

W demie: „odpalcie 15 podagentów, każdy na Sonnecie 5.5 extra high, do analizy różnych fragmentów kodu pod kątem drobnych bugów” — agent główny wystartował w mniej niż sekundę. Większość platform potrzebuje 20–30 sekund na uruchomienie piaskownicy; mój zespół wyrabiał się do granic, żeby chmura działała równie szybko jak lokalnie — bo tyle wynosi poprzeczka. Piętnastu podagentów grzebie w kodzie; mogę je wstrzymać jednym ruchem, zarchiwizować i odpalić od nowa — jako 25 agentów w Codexie na GPT 6.1 Soul. Można mieszać: Opus jako dyrygent i Soul jako robotnicy, albo Astra jako kierownik i Opus albo Sonnet jako wykonawcy. Pytanie „na jakiej jesteśmy maszynie?” lokalnie odpowiada „MacBook Pro, 128 GB RAM”, a w chmurze — równie szybko — że jesteśmy w piaskownicy. Szybkość identyczna jak lokalnie.

Ty jesteś wąskim gardłem — i to musi się zmienić

Zasada, bez której nie zrozumiesz przyszłości pracy: jeśli nie zaczniesz wycofywać się z kolejnych obszarów, nie przeskalujesz się. Tak samo jest w biznesie — prezes nie może robić wszystkiego — a Ty jesteś prezesem swojej armii agentów.

Opus 5.5 jest już na poziomie AGI. Możesz się nie zgadzać — mylisz się. To obecnie zdecydowanie najlepszy model: ekstremalnie tania praca, błyskawiczny, oszczędny na tokeny i przy tym bystry. Wszystkie animacje i grafiki w CloudRoom powstały z nim — tak, prosiłem o kilka wariantów i doszlifowałem płynność, ale żaden inny model nie podszedłby nawet blisko. Oczywiście potrzebujesz smaku, żeby ocenić, co jest dobre. Ale Opus to AGI.

Twoim zadaniem jest pozwolić mu gotować — wycisnąć z subskrypcji maksimum i usunąć siebie z drogi. Wielu z Was zostawia ponad połowę tygodniowego limitu nietkniętą. Da się z tym zrobić wiele. Jest zła odpowiedź na ten problem: obniżyć plan i „oszczędzić” sto dolarów — czyli przyznać, że nie umiesz zamieniać tokenów na przychód. A to będzie główna umiejętność przyszłości: czy tokeny zarabiają więcej, niż kosztuje abonament? Tym bardziej że subskrypcja Anthropic jest dotowana rzędu 90% — tokeny Opusa 5.5 dostajesz 50–90% taniej niż przez API. Zamiast ciąć koszty, zrób coś: popraw marketing, produkt, bezpieczeństwo. I kradnij moje automatyzacje: przegląd billingów, kontrola bazy, wątki z feedbackiem klientów, issues i PR-y z GitHuba, przegląd publicznych repozytoriów, alerty piaskownic, przeciąg bezpieczeństwa, upraszczanie kodu, polowanie na brakujące testy.

Mit „AI wyniesie wszystkich”

Na koniec muszę sprostować kłamstwo, które mogliście słyszeć od ludzi pokroju Sama Altmana: że AI przyniesie korzyść każdemu i wszystkich podniesie. Państwo, przepaść rośnie. Jestem teraz w San Francisco, poznałem mnóstwo ludzi całkowicie pochłoniętych tematem — i wszyscy są zgodni: jeśli potrafisz produktywnie i użytecznie prowadzić 50, 100, 200 agentów, to w porównaniu z przeciętną osobą na ulicy nie będzie to nawet uczciwa walka. Większość ludzi wciąż nie używa żadnego AI — znajomi, rodzina, nikogo to nie rusza. A ci, którzy używają, siedzą na darmowych planach. Nie budują fabryk. Ludzie z cutting edge uciekają coraz dalej i stają się absurdalnie bardziej wydajni od reszty. Cena niebycia na cutting edge nigdy nie była tak wysoka. Szefowie wielkich firm tego nie powiedzą — bo w telewizji źle by to wyglądało. Mnie to nie obchodzi: powiem prawdę. Przepaść pęka.

Jak myśleć o przyszłości

Jak do tego dochodzę? Siedam i myślę. Mój zespół robi godzinną sesję — możesz ją nagrać dyktafonem w telefonie — i rozpatrujemy jeden temat: dlaczego ta firma rośnie? Co pociąga za sobą ten trend zachowań? Czym skutkują tanie modele decyzyjne? Bez telefonów, bez komputerów, tylko rozumowanie na głos przez 60–90 minut. Rób to codziennie przez miesiąc, dwa — i będziesz rozumiał przyszłość lepiej niż większość ludzi w AI, łącznie z tymi z samej granicy. Bo myślenie jest trudne. Rozumuj z pierwszych zasad: zachowania ludzi, dynamika rynków, przełomy technologiczne — a potem skutki drugiego i trzeciego rzędu. Nie odchodź od stołu, dopóki nie popłyną pomysły; pierwsze pięć–dziesięć minut zawsze jest jałowe.

Tak właśnie doszedłem do CloudRoom i tezy o nieuchronności chmury: modele są już wystarczająco mocne, by prowadzić setki i tysiące agentów — a my tego nie robimy. Trzeba więc znaleźć wąskie gardła i likwidować je jedno po drugim. I poświęć na to czas, bo — jak mówił Joshua Reynolds (Informacja dodatkowa: cytat przypisywany Joshui Reynoldsowi, brytyjskiemu malarzowi i teoretykowi sztuki XVIII wieku; w transkrypcji nazwisko zniekształcone) — nie ma wybiegu, do którego człowiek by się nie uciekł, byle tylko uniknąć prawdziwego trudu myślenia. Innymi słowy: ludzie zrobią wszystko inne. Będą dekadę po dziesięć godzin dziennie smażyć burgery, żeby tylko nie usiąść i nie pomyśleć, jak zmienić pracę, karierę czy branżę. Myślenie to ta trudna część. Klikanie już nie jest — każdy agent z computer use i kilkoma MCP zrobi to lepiej od człowieka. Prawdziwa, ciężka praca zaczyna się teraz: rozumowanie o przyszłości z pierwszych zasad. Nie uciekaj przed nią.

Zakończenie

Dziękuję za obejrzenie. Jeśli chcesz pracować ze mną bliżej — z pierwszą dziesiątką osób na planie Ultra przeprowadzę osobiście wdrożenie i pomogę wprowadzić agentów chmurowych do firmy. Adresat: właściciel biznesu albo realny superużytkownik z co najmniej dwoma planami po 200 dolarów. Jeśli to nie Ty — spokojnie, to po prostu jeszcze nie dla Ciebie. Życzę produktywnego tygodnia.