O czym jest ten film
- David Ondrej ogłasza premierę Cloudroom — w pełni open-source’owego narzędzia do uruchamiania agentów AI w chmurze, z darmowym planem dostępny od dnia publikacji.
- Każdy wątek („thread”) dostaje własną, izolowaną piaskownicę — osobną maszynę wirtualną z Linuksem — co pozwala skalować się do setek agentów bez konfliktów o zasoby.
- Platforma nie sprzedaje dostępu do modeli: podłączacie swoje subskrypcje (Claude Code, Codex, Cursor, OpenCode, Hermes, pi agent, Grok Build) i używacie ich tokenów także w chmurze.
- Funkcja Teleport przenosi działający wątek z laptopa do chmury i z powrotem w kilka sekund, z zachowaniem całego kontekstu, repozytorium i zależności.
- Agenci chmurowi mogą — na wybranym poziomie uprawnień — sięgać do plików na Macu użytkownika, np. po plik z folderu Pobrane albo klucz z pliku .env.local.
- „Automations” to pętle agentowe uruchamiane harmonogramem lub zdarzeniem, budowane zwykłą rozmową — autor nazywa to mini fabryką oprogramowania.
- Główna teza: laptop jest wąskim gardłem (bateria, zamykanie pokrywy, przegrzewanie, kolizje agentów), więc przyszłość należy do agentów działających w chmurze, uruchamianych coraz częściej automatycznie, a nie ręcznie.
- Dlaczego nikt tego nie zrobił? Według autora: duzi gracze mają „perwersyjne zachęty” (zamknięte ekosystemy, przymus własnego narzędzia), a sama inżynieria — szybkość startu, synchronizacja, ryzyko utraty danych — jest po prostu trudna.
- Architektura: rdzeń w 78% w języku Rust, modularność (GUI i rdzeń jako osobne repozytoria), licencja Apache 2.0, GUI utrzymane na bazie sforkowanego projektu BB; pełne wsparcie dla macOS i Linuksa.
- Produkt celuje w zaawansowanych użytkowników wydających co najmniej 400 dolarów miesięcznie na inferencję; autor rekrutuje zespół i rozważa pierwszą rundę finansowania w grudniu lub styczniu.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Osobna piaskownica dla każdego agenta to fundament bezpiecznego skalowania
Na czym polega: każdy wątek działa w swojej maszynie wirtualnej z Linuksem. Jeśli agent paśnie ofiarą iniekcji promptu albo zainstaluje złośliwy pakiet, szkoda ogranicza się do jednej piaskownicy — reszta pracy i wasz główny komputer pozostają nietknięte. Znika też problem agentówdepoczących sobie na nogi: brudny checkout, testy bazy danych zżerające zasoby itd.
Jak stosować: gdy uruchamiacie równolegle więcej niż kilka agentów, wybierajcie tryb chmurowy zamiast lokalnych drzew roboczych Gita. Powyżej 5–10 równoległych zadań lokalna maszyna przestaje wystarczać.
Na co uważać: darmowy plan ma limity liczby agentów; pełne skalowanie wymaga planów płatnych albo samodzielnego hostowania.
2.Nie płaćcie drugi raz za te same tokeny
Na czym polega: Cloudroom nie jest kolejnym sklepem z inferencją. Podłączacie subskrypcje, za które już płacicie, i korzystacie z nich również w chmurze — niezależnie od narzędzia.
Jak stosować: sprawdźcie listę wspieranych narzędzi (m.in. Claude Code, Codex, OpenCode, Hermes, pi agent) oraz obsługę protokołu ACP; wasze logowania z linii poleceń działają lokalnie i w chmurze.
Na co uważać: limity subskrypcji nadal was obowiązują — sam autor demonstruje przełączanie się między dwoma planami po wyczerpaniu limitu.
3.Teleport: praca nie musi umrzeć razem z baterią laptopa
Na czym polega: jedno kliknięcie przenosi aktywny wątek — z całą historią, repozytorium i zależnościami — do piaskownicy w chmurze i z powrotem, w kilka sekund.
Jak stosować: gdy musicie nagle wyjść, a agenci mają niedokończone zadanie, teleportujcie wątki do chmury przed zamknięciem laptopa; praca biegnie dalej.
Na co uważać: to świeża funkcja w świeżym produkcie — przy krytycznych zadaniach zacommitujcie zmiany przed przenoszeniem.
4.Dajcie agentowi w chmurze dostęp do Maca — ale świadomie i poziomami
Na czym polega: agent działający w chmurze może zajrzeć do folderu Pobrane, znaleźć repozytorium w Dokumentach albo otworzyć podgląd pliku — ale tylko na uprawnieniach, które sami ustawicie: brak dostępu, sam odczyt, pytanie przed każdą zmianą albo pełny dostęp.
Jak stosować: włączajcie dostęp punktowo, do konkretnego zadania; domyślnie trzymajcie wyłączone lub w trybie odczytu.
Na co uważać: pełny dostęp oznacza, że przejęty agent sięgnie także po lokalne sekretne pliki. Wygoda wymaga tu żelaznej higieny uprawnień.
5.Budujcie pętle agentowe zamiast ręcznie odblokowywać każdego agenta
Na czym polega: opisujecie zwykłym językiem, co ma się dziać — np. „co pół godziny sprawdź jedną zależność pod kątem podatności” — a system tworzy i uruchamia pętlę. Można dołożyć logikę warunkową: „jeśli znajdziesz problem, niech drugi model z innej firmy zweryfikuje, czy to nie jest przesada, i w razie wątpliwości zamknij oba wątki”.
Jak stosować: zacznijcie od jednego monitoringu (bezpieczeństwo zależności, przegląd nowych prac naukowych, obserwacja awarii) i rozszerzajcie. Kilka–kilkanaście takich pętli zaczyna pracować jak mini fabryka oprogramowania, w której część zadań startuje bez was.
Na co uważać: pętla z dostępem do prywatnych danych potrafi wyciekać — autor sam wstrzymał swoje automatyzacje na czas nagrania. Jasno określcie, co wolno wysyłać poza wasze środowisko.
6.Migrujcie do chmury stopniowo, projekt po projekcie
Na czym polega: autor przewiduje podział około 90/10 na korzyść chmury w perspektywie pół roku, ale sam zaleca przenoszenie pojedynczych repozytoriów, tydzień po tygodniu, zamiast wielkiego skoku.
Jak stosować: wybierzcie jeden projekt, przenieście, oceńcie opór. Jeśli wszystko działa — dokładajcie kolejne.
Na co uważać: niektóre prace lokalnie mają sens: bardzo prywatne dane, rozwój pod macOS/Xcode, ciężki rendering na potężnej stacji roboczej. Nie forsujcie chmury wszędzie na siłę.
7.Open source (Apache 2.0) daje wam audyt, fork i niezależność
Na czym polega: rdzeń i interfejs Cloudroom to osobne, publiczne repozytoria. Możecie je sforkować, poddać testom penetracyjnym, hostować na własnym sprzęcie albo kazać własnemu agentowi przejrzeć kod za was.
Jak stosować: zanim powierzycie narzędziu produkcyjne repozytoria, przejrzyjcie kod samodzielnie lub zlećcie to agentowi. Gdy polityka firmy wyklucza cudzą chmurę — zostańcie przy self-hostingu.
Na co uważać: samodzielne utrzymywanie puli piaskownic to realny koszt operacyjny i odpowiedzialność za aktualizacje.
8.Nie zakładajcie się przeciwko postępowi AI przy planowaniu mocy
Na czym polega: argument autora: wszyscy używamy dziś więcej agentów niż rok temu, więc za rok będziemy używać jeszcze więcej. Kupując sprzęt „na dziś”, blokujecie się w momencie, gdy potrzeba wzrośnie choćby o 20%.
Jak stosować: przy decyzjach infrastrukturalnych wybierajcie opcje elastyczne i skalowalne (chmura, kontenery) zamiast stałego żelastwa.
Na co uważać: nieograniczone skalowanie kosztuje — ustawiajcie budżety, limity i alerty od pierwszego dnia.
9.Przyszłość: agentów uruchamiają wyzwalacze, nie ludzie
Na czym polega: przy kilkudziesięciu wątkach człowiek gubi kontrolę — jak przy „liczbie Dunbara” dla znajomych, powyżej 50–100 wątków nie pamiętamy, co się w nich działo. W firmie z 5000 programistów prezes nie wydaje poleceń każdemu po kolei; podobnie agencją będą zarządzać inni agenci, harmonogramy, webhooky i zdarzenia (awaria bazy, nowy klient), z automatycznym archiwizowaniem ukończonych zadań.
Jak stosować: projektujcie pracę z agentami od razu z wyzwalaczami i wzajemną weryfikacją (jeden model kontroluje drugiego). Korzystajcie z funkcji typu „purpose” — podglądu celu wątku i postępu — żeby szybko odzyskiwać kontekst.
Na co uważać: autonomia bez logów i przeglądów to ryzyko — archiwizujcie i audytujcie, co agenci narobili.
10.Prosty test dopasowania: ile wydajecie na inferencję
Na czym polega: Cloudroom celuje w osoby z co najmniej dwiema subskrypcjami po 200 dolarów miesięcznie lub wydające ponad 400 dolarów na inferencję. To narzędzie dla poważnych budowniczych i przedsiębiorców, nie dla początkujących ani klientów konsumenckich.
Jak stosować: jeśli macie jeden tani plan — zostańcie przy prostszych aplikacjach. Jeśli prowadzicie zespół mocno używający AI, rozważcie plany Pro/Ultra (onboarding i, w Ultrze, kanał Slack z bezpośrednim kontaktem z autorem).
Na co uważać: przy dużym zainteresowaniu dostęp do wątków chmurowych na darmowym planie bywa kolejkowany (do kilku dni); natychmiastowy dostęp dają plany płatne.
Redakcyjne tłumaczenie
Wprowadzenie: czym jest Cloudroom
Nazywam się David Ondrej i z przyjemnością przedstawiam Cloudroom. To nowe podejście do agentów chmurowych: każdy może uruchomić dowolne narzędzie agentowe — tzw. harness, czyli nakładkę w rodzaju Claude Code czy Codex, która wykonuje polecenia modelu w terminalu — z dowolnym modelem, korzystając z subskrypcji, które już opłaca. Co więcej, każdy agent dostaje własną, odizolowaną piaskownicę (sandbox) — czyli osobny komputer w chmurze. Całość jest w pełni open source na GitHubie, a darmowy plan, pierwszy taki na świecie plan z agentami chmurowymi, rusza właśnie dziś. Zobaczymy, jak poradzi sobie z ruchem, ale nic nie stoi na przeszkodzie, żebyście hostowali wszystko samodzielnie, sforkowali projekt albo kazali własnemu agentowi przejrzeć kod.
Dlaczego warto zwrócić uwagę? Oddanie każdemu agentowi osobnego komputera oznacza skalowanie praktycznie bez ograniczeń — a agenci pracują dalej, nawet gdy laptop straci baterię albo po prostu go zamkniecie.
Pierwsze demo: dziesiątki agentów w kilka sekund
Zacznijmy od tego, jak to wygląda. Podstawowa decyzja przy każdym uruchomieniu: praca lokalna czy w chmurze — sami wybieracie, gdzie wystartuje agent. Pokażę, jak to jest proste. Uruchamiam pięć różnych agentów, każdy z innym narzędziem i innym modelem, i proszę, żeby powiedziały, na jakiej maszynie działają — wszystko jako wątki chmurowe.
Teraz nowy wątek, żeby pokazać łatwość uruchamiania podagentów: dwadzieścia pięć sztuk, każdy na Haiku 5.5, każdy przeszukuje inny fragment bazy kodu w poszukiwaniu drobnych błędów — bez wprowadzania żadnych zmian. Po lewej widać, jak szybko to poszło. Klikam w kolejne wątki: ten działa na Claude Code, ten na Hermesie, ten na OpenCode, dalej pi agent, a ten na Codexie z modelem Astra. Krótko mówiąc: jakie narzędzie lubicie, takiego użyjecie. Claude Code, Cursor, Codex, pi agent, Hermes, OpenCode, Grok Build — płacicie za tokeny raz, w ramach subskrypcji, które już macie. Wspieramy również ACP. (Informacja dodatkowa: ACP, Agent Client Protocol, to otwarty protokół pozwalający jednemu klientowi sterować różnymi agentami kodującymi.)
I to wszystko może działać w chmurze. Pytam: „Na jakiej maszynie jesteśmy?” — wątek chmurowy startuje i w niecałe dwie sekundy agent odpowiada: działamy w piaskownicy Cloudroom, nie na moim MacBooku. Dużo pracowaliśmy, żeby prędkość była zbliżona do lokalnej, i szczerze wierzę, że to najlepsze rozwiązanie dla agentów chmurowych na rynku.
Widzicie właśnie, jak wystartowało dwadzieścia pięć podagentów na Haiku, każdy w swojej piaskownicy. Po odświeżeniu ekranu widać, że mam działające 38 agentów — każdy w osobnym, izolowanym środowisku. Mam włączony tryb prywatności, więc nie widzicie nazw wątków, ale modele są widoczne: Opus 5.5, Haiku 5.5 i inne. A to dopiero czubek góry lodowej.
Wszystko jest dostępne już teraz. W zależności od przepustowości będę wpuszczał kolejne osoby, ale darmowy plan działa od dziś — wchodźcie na cloudroom.dev, link będzie pierwszy pod filmem. Pobierzcie aplikację; lokalnie możecie używać jej bez ograniczeń, jak każdej zwykłej aplikacji. Wasze subskrypcje — Codexa, Claude, Cursora — działają tu od razu. I działa to też w drugą stronę: mówię „zatrzymaj wszystkie te agenty i zarchiwizuj ich wątki” — i gotowe. Cały produkt jest zbudowany agentocentrycznie: agenci mogą modyfikować, aktualizować, archiwizować, zmieniać nazwy, przenosić wątki z lokalnego na chmurowy. Wszystkim sterujecie zwykłym angielskim.
Czym Cloudroom różni się od istniejących rozwiązań
Można spytać: przecież są Cursor Cloud i Codex Cloud. Problem w tym, że każde z nich pozwala używać wyłącznie własnego narzędzia. Anthropic nigdy nie wpuści harnessu Codexa ani pi agenta. Cursor zmusza do Cursora — nie użyjecie tam Codexa, Hermesa czy OpenCode. Nie użyjecie ulubionych narzędzi ani subskrypcji, za które płacicie. Wszystkie te rozwiązania są zamknięte, żadne nie jest open source. Cloudroom jest pierwsze.
Jesteśmy też jedynym narzędziem do kodowania z AI, które daje izolowaną piaskownicę każdemu wątkowi. To, co widać na ekranie, to osobne maszyny wirtualne z Linuksem — każdy agent pracuje na własnym komputerze, całkowicie odseparowanym od pozostałych. Dzięki temu skalowanie nie ma praktycznego sufitu: 38 agentów, 380, 3800. Zobaczymy, dokąd zaprowadzą je najbardziej wytrwani użytkownicy. Darmowy plan ma limity, płatne pozwalają na znacznie, znacznie więcej.
I kluczowa rzecz: to pierwszy taki produkt na świecie z darmowym planem — agenci chmurowi, każdy na własnej, izolowanej maszynie wirtualnej, za zero.
Dlaczego izolowane piaskownice mają znaczenie
Jeśli nie siedzycie w tej dziedzinie na co dzień, może to nie być oczywiste, ale osobne środowiska dla agentów to po prostu właściwa architektura. Sporo ludzi próbuje upchnąć wszystko na Macu Mini, jednej wirtualce albo starym laptopie z domu. To droga donikąd.
Po pierwsze: nieskończone skalowanie jest możliwe tylko wtedy, gdy każdy agent ma własną maszynę. Mac Mini udźwignie może pięć, może dziesięć agentów — ale każdy z nas używa dziś więcej agentów niż rok temu i nie trzeba geniusza, żeby zauważyć, jak szybko AI idzie do przodu. Czystą logiką: za dwanaście miesięcy będziemy ich używać znacznie więcej niż dziś. A gdy kupujecie konkretny kawałek żelastwa i nagle potrzebujecie o 20% więcej mocy — nie ma jak, jesteście zablokowani.
Po drugie: bezpieczeństwo. Gdy któryś agent paśnie ofiarą iniekcji promptu albo zainstaluje szkodliwy pakiet, ostatnią rzeczą, jakiej chcecie, jest jego obecność na waszym głównym komputerze. W izolowanej piaskownicy ucierpieć może tylko ten jeden agent.
Po trzecie: agenci potrzebują ścian, żeby nie wchodzić sobie w paradę. Przy jednym czy dwóch wystąpieniach Codexa czy Claude Code tego nie widać, ale przy pięciu, dziesięciu, piętnastu zaczynają się problemy. Drzewa robocze Gita pomagają — wystarczy jednak, że jeden agent wypchnie coś do głównego checkoutu i już jest brudno, a pozostali się potykają. Albo jeden agent odpala testy bazy danych i zajmuje całą moc maszyny. Współdzielenie jednego komputera przez wielu agentów po prostu nie działa. I szczerze: kto tak pracuje, ten zakłada się przeciwko postępowi AI — a to jedna z tych tendencji, z którymi nie chciano by obstawiać pod prąd, bo tempo ulepszeń tylko przyspiesza.
W Cloudroom jednym promptem wystartujecie sto piaskownic — przed chwilą zrobiliście to z dwudziestoma pięcioma. Potrzebujecie nagle dwudziestu czy trzydziestu agentów, żeby dowieźć zlecenie klienta albo złapać okazję na giełdzie? Proszę bardzo. Ze sprzętem o stałej mocy — niewykonalne.
Codzienne użytkowanie: projekty, skróty, modele
Dosyć fajerwerków, pokażę zwykłą pracę. Pracujecie w projekcie — może to być repozytorium albo lokalny folder, jak wolicie. Przy każdym wątku wybieracie tryb lokalny lub chmurowy, pełną ręką skrótów klawiszowych (są na wszystko). Błyskawicznie przełączacie model — na Astrę, na Opusa — i poziom rozumowania: niski, wysoki, bardzo wysoki, maksymalny. Jeśli dane narzędzie obsługuje tryb „fast”, też go przełączycie jednym ruchem.
Sama praca wygląda tak, jak w aplikacji Codexa, Cursora czy Claude Desktop — jeśli już ich używacie, przesiadka będzie bezbolesna. Przykład: proszę o ulepszenie sekcji aplikacji webowej, żeby wyglądała bardziej autorsko — na przykład żeby kolor dopasowywał się do koloru narzędzia agenta — i żeby pokazać cztery różne warianty, każdy wyrenderowany jako prawdziwy obraz. Prompt poszedł, po lewej startuje nowy wątek, tym razem chmurowy. Ikony od razu pokazują, które wątki biegną w chmurze, a które na moim laptopie.
Teleport: przenoszenie pracy między laptopem a chmurą
Kolejna funkcja to teleportacja wątków — czego, szczerze mówiąc, nie widziałem w żadnym innym produkcie. Pozwala przenieść wątek z MacBooka do piaskownicy w chmurze i z powrotem.
Zacznijmy lokalnie. Pytam agenta: „Na jakiej maszynie jesteśmy?”. Analizuje sprzęt i odpowiada: MacBook Pro. Teraz klikam prawym przyciskiem: „teleportuj do chmury”. Jest ładna, krótka animacja — i ten sam wątek, z tym samym kontekstem, tym samym repozytorium i wszystkimi zależnościami, przenosi się do nowej, izolowanej piaskownicy i tam kontynuuje pracę.
Scenariusz: pracujecie lokalnie godzinę, półtorej, i nagle musicie wyjść — na lotnisko, do kawiarni — a agenci muszą dalej działać. Pytam jeszcze raz: „Sprawdź, na jakiej maszynie jesteśmy”. Odpowiedź: nadal w piaskownicy Cloudroom, nie na Macu. W ciągu dosłownie kilku sekund cały czat, ten sam model, to samo narzędzie — i wszystko pracuje w odseparowanym środowisku w chmurze. I naprawdę trzeba to podkreślić: każdy z tych wątków ma własną piaskownicę.
Dlaczego nikt tego nie zrobił wcześniej
Możecie pomyśleć: wspaniała innowacja, to czemu nie istniała? Dwa powody.
Pierwszy: duzi gracze — wielkie laboratoria i wielkie firmy — mają wypaczone bodźce. Trenują modele, chcą wszystkich danych i każde swoje osiągnięcie trzymają zamknięte. Żadnej otwartości na cudze narzędzia. Weźcie Cursora: przez lata jego atutem było to, że można było użyć dowolnego modelu. Po przejęciu przez SpaceX to się skończyło — najnowszych modeli GPT tam nie użyjecie. Astra była przez dobrych kilka tygodni najlepszym modelem na rynku i nie dało się jej odpalić w Cursorze. (Informacja dodatkowa: według słów autora to właśnie przejęcie Cursora przez SpaceX miało skutkować blokadą modeli konkurencji w tym edytorze.) I to jest sedno problemu istniejących rozwiązań: nie są obojętne wobec wyboru narzędzia. Zmuszają was do własnego harnessu, własnej subskrypcji i własnego interfejsu, choćby wam to nie odpowiadało. A przecież wszyscy już płacimy słone pieniądze za subskrypcje Claude, Codexa, Cursora czy OpenCode — skoro płacicie za tokeny, powinniście móc ich używać. Taka jest cała wizja Cloudroom: dowolny model, dowolne narzędzie, dowolny dostawca inferencji. Nasza infrastruktura — włącznie z rdzeniem — leży w całości na GitHubie, gdzie mamy już ponad 320 gwiazdek.
Drugi powód: to jest po prostu trudne. Z setkami piaskownic — a każda z nich to w praktyce osobny komputer: linuksowa maszyna w chmurze z niezauważalnym internetem, do dyspozycji wyłącznie jednego agenta — łatwo o utratę danych, jeśli nie wiecie, co robicie. Ciągle je tworzyć i zamykać, każda z trwałym stanem — to wyzwanie. Potem szybkość: jeśli nowy wątek startuje dwadzieścia sekund, nikt tego nie użyje. Wciągnęliśmy się w to tak, że start wątku chmurowego trwa mniej więcej tyle, co lokalnego — pół sekundy, i tak to musi czuć. Dalej synchronizacja: wszystkie wasze repozytoria i klucze API muszą być zsynchronizowane między waszym komputerem a chmurą — w pełni wspieramy macOS i Linuksa. I jeszcze jedno: te same logowania, których używacie w liniach poleceń Codexa czy Claude Code, muszą działać i lokalnie, i w chmurze. To też jest ciężkie.
I uwaga: to wszystko musi działać razem. Wystarczy, że jedna z tych rzeczy kuleje, a ludzie nie przeniosą swojej pracy. Agenti chmurowi istnieją od roku i większość osób nadal nie migrowała — właśnie przez tarcie. Dlatego przez ostatnie pięć, sześć tygodni pracowałem z około 25 beta-testerami, po sześć–dziesięć godzin dziennie, polerując każdy z tych elementów. Standard jest jeden: chmura musi działać tak dobrze jak lokalnie — a właściwie lepiej, bo każdy agent dostaje własną maszynę.
Dla kogo jest Cloudroom
Nie konkuruję z produktami konsumenckimi typu Muse czy Instinct. Cloudroom jest dla zaawansowanych użytkowników — dla poważnych budowniczych, przedsiębiorców, ludzi, którzy już płacą za kilka subskrypcji po 200 dolarów miesięcznie. Prosty test: czy płacicie 200 dolarów za Claude Code i 200 za Codexa? Jeśli macie przynajmniej dwie takie subskrypcje — Cloudroom jest prawdopodobnie dla was. To narzędzie dla tych, którzy rozumieją, że przyszłością agentów jest chmura; że niedługo wszyscy będziemy uruchamiać setki, jeśli nie tysiące agentów równolegle — nie tylko wpisując polecenia z klawiatury, ale też przez webhooky, rutyny, awarie baz danych, ulepszenia produktu, pojawienie się klienta. Różne wyzwalacze, różne warunki, całkowicie niezależnie od stanu waszego laptopa.
Moim zadaniem nie jest przekonywanie, że agenci chmurowi to przyszłość — w ciągu najbliższych 6–12 miesięcy stanie się to oczywiste dla wszystkich. Za to przełączanie między planami jest banalne: widać zużycie poszczególnych subskrypcji i jednym kliknięciem zmieniacie plan. Sam mam dwa plany Claude Code — gdy wyczerpię limit na tańszym, przeskakuję na główny i pracuję dalej.
Zaczynajcie na cloudroom.dev, za darmo, i spróbujcie doprowadzić plan do granic. Gdy potrzeba więcej agentów — porównajcie plany na stronie cenowej. Plan Pro albo Ultra, jeśli chcecie bezpośredni dostęp do mnie i zespołu: każdy klient Ultra dostaje dedykowany kanał Slack z moim udziałem. Możecie współkształtować produkt, zgłaszać błędy i pomysły — naprawiamy je w ciągu paru godzin.
Dlaczego przyszłość agentów jest w chmurze
To może nie być oczywiste, więc prześledźmy, jak zmienia się sposób, w jaki używamy agentów. Rok, pół roku temu praca z agentem wyglądała tak: „przeanalizuj to repo i zbuduj funkcję”. Człowiek ręcznie odblokowywał jednego agenta naraz. To nie ma skalowania. Zapytam własne CLI: ile otwartych wątków mam teraz w katalogu z Cloudroom? Odpowiedź krótka, bez wycieków — nagrywam film. Wychodzi 201 otwartych wątków. Przy pięciu, dziesięciu da się je odblokowywać pojedynczo; powyżej dwudziestu, trzydziestu — można oszaleć. Mówię z doświadczenia.
Jest w nas coś w rodzaju limitu pojemności — jak przy znanej „liczbie Dunbara”, według której utrzymujemy około 150 stabilnych relacji. (Informacja dodatkowa: liczba Dunbara to popularna teza psychologii evolutionary, że człowiek jest w stanie utrzymywać ok. 150 znaczących więzi społecznych.) Z agentami jest podobnie: powyżej pięćdziesięciu, stu wątków zupełnie gubimy pamięć, co się w którym działo. Dlatego w Cloudroom jest funkcja „purpose” — najedźcie na nazwę wątku i zobaczcie jego cel oraz procent wykonania. Jestem przekonany, że jesteśmy jedynym narzędziem do kodowania z AI, które to ma — zbudowałem ją dwa dni temu.
W przyszłości większość agentów będzie startować sama: od wyzwalacza, zdarzenia, reguły, instrukcji — od pętli agentowej czy „fabryki oprogramowania”, którą sobie zbudowaliście. Nie od was, odblokowujących każdego z osobna. Pomyślcie o firmie z pięcioma tysiącami programistów: czy prezes mówi każdemu po kolei, co ma robić? Oczywiście nie. Istnieje wielopoziomowa struktura zarządzania, część ludzi to samodzielni inicjatorzy, część dostaje pracę od zgłoszeń klientów. Z agentami będzie tak samo. Cała dziedzina AI inspirowała się ludzkim mózgiem — sieci neuronowe dosłownie. Z zarządzaniem agentami będzie identycznie: gdy będziemy uruchamiać tysiące, część pracy zweryfikuje automatycznie inny agent, część zadań wyda „agent-dyrektor”, niektóre wątki wystartują same, przeanalizują stan bazy albo kondycję systemu i same się zarchiwizują. Wzorce użycia będą zupełnie inne niż dziś.
Do tego potrzebne jest środowisko trwałe: działające zawsze, z szybkim i stabilnym łączem. Nasze piaskownicy mają łącza rzędu 10–15 Gb/s i dostępność na poziomie 99,99%. Agenci muszą być zawsze gotowi — bo skoro przejmują coraz więcej zadań w waszym życiu i firmie, nie może być tak, że przestają działać. A na laptopie? Znajoma sytuacja: bateria pada, trzeba go zamknąć przed wyjściem, w kawiarni Wi-Fi kulawe. Przydarza się codziennie, mnie również. Dlatego agenci chmurowi to przyszłość — zwłaszcza gdy coraz więcej z nich będzie biegać w fabrykach oprogramowania i pętlach agentowych. Nagrałem o tym cały film dwa dni temu, więc jeśli temat was wciąga, obejrzyjcie go po tym.
Automations, czyli pętle agentowe
Pokażę, jak łatwo zbudować w Cloudroom mini fabrykę oprogramowania. Dotąd widzieliście obecny sposób pracy — teraz przyszły. Mamy coś, co nazywamy „automations”, ale uczciwiej byłoby mówić o inżynierii agentowej nowej ery: pętli agentowej albo mini fabryce. Wybieracie wyzwalacze — na przykład harmonogram. Mam tu monitor opóźnień Discorda, bo od dziś Discord mi laguje, to zbudowałem prostą pętlę diagnostyczną. Kilka automatyzacji mam wstrzymane — uruchamiały dane klientów, więc wyłączyłem je przed nagraniem. Inna ciekawa: co drugi dzień o ósmej rano startuje wątek chmurowy, który przeszukuje arXiv — tam, gdzie publikowane są prace naukowe — i sprawdza, co mogłoby mnie zainteresować, co mogłoby mnie czegoś nauczyć. Nie mam ani minuty nadwyżki czasu — pracuję od przebudzenia do snu, z własnej i nieprzymuszonej woli; ćwiczę na siłowni codziennie, więc nikt niech się o moje zdrowie nie martwi. Ale edukować się chcę — więc zbudowałem pętlę, która robi to za mnie, na bieżąco.
Zapomnijcie o klikaniu w interfejs — interfejsy dla ludzi to przeszłość. Wszystko musi być sterowalne przez agenta. Poproszę właśnie tak: „wyjaśnij mi room CLI i co się z nim da zrobić”. Room CLI to nasza linia poleceń dla agentów: mogą nią sterować wszystkim w Cloudroom — spawnować kolejnych agentów, planować automatyzacje, a także sięgać do mojego Maca. I to jest kolejna przełomowa funkcja, której nie ma nikt inny: dostęp agentów chmurowych do waszego laptopa. Zapomnieliście załączyć plik? Agent musi zajrzeć do folderu Pobrane albo wziąć repozytorium z Dokumentów, albo dependency zainstalowane tylko na waszym MacBooku, albo klucz API z pliku .env.local, bo kazałoście mu zrobić research? Większość produktów agentowych polegnie w takich sytuacjach — Claude, Codex, Cursor też — bo nie pozwalają agentom chmurowym dotykać waszego komputera. W Cloudroom mamy to rozwiązane z gracefully dobranymi uprawnieniami: dostęp całkowicie wyłączony, tylko odczyt, pytanie przed każdą zmianą albo pełny dostęp. Poziom wybieracie wy.
Teraz pokażę, jak buduje się automatyzację — rozmawiając. Mówię: „stwórz nową automatyzację, która działa co 30 minut, na GPT‑6.1 w maksymalnym trybie rozumowania z opcją fast; ma robić przegląd bezpieczeństwa wszystkich zależności projektu. Co uruchomienie sprawdza inną zależność — czy nie ma naruszeń albo publicznie dostępnych exploitów. Zrób z tego klonującą automatyzację, przypnij do tego repo i aktywuj”. I gotowe. Mówiłem może dwadzieścia sekund, a powstaje nowa pętla agentowa. Kiedy takich pętli jest jedna, dwie — to jeszcze automatyzacje. Ale przy dziesięciu, dwudziestu, trzydziestu naprawdę zaczyna to być fabryka oprogramowania, w której mnóstwo pracy startuje zupełnie beze mnie. Sam mam około czterdziestu, zwykle włączonych piętnaście–dwadzieścia.
I jeszcze doprecyzuję — tym samym głosem: „gdy automatyzacja coś znajdzie, niech spawnuje podagenta na Opusie 5.5 w najwyższym trybie rozumowania, przez Claude Code, żeby sprawdził, czy to realny problem, czy nie przesada; a jeśli przesada — niech zarchiwizuje oba wątki”. I to już działa: pętla startuje co pół godziny, co pięć godzin — jak zdecydujecie. W przyszłości dojdą kolejne typy wyzwalaczy, będzie jeszcze bardziej konfigurowalne. Buduję po prostu chmurową infrastrukturę dla agentów — nie tylko na dziś, ale na czas, gdy większości agentów nie będziemy już startować sami. Przejdziemy na wyższy poziom: zarządzanie i orkiestracja.
Minuta siedemnaście sekund — i automatyzacja stworzona oraz uruchomiona. Skrypt wypisał 220 zależności, pierwsza jest już sprawdzana — akurat axum — i model pracuje. Nazwałem ją „dependency watch”; przy każdej automatyzacji widać narzędzie, model i poziom rozumowania. Utworzyłem ją w dwadzieścia sekund, mówiąc zwykłym językiem. Tak buduje się oprogramowanie.
I nie chodzi o tę jedną pętlę, tylko o budowanie ich wielu — o pomyślenie, jak wyglądałby zespół pięćdziesiąt razy większy: badacze bezpieczeństwa, frontendowcy, zespół billingowy, zespół testów, zespół od brakujących funkcji produktu, zespół wydajności. Zresztą patrzcie: automatyzacja sama zdecydowała się wystartować recenzenta na Opusie 5.5 i właśnie kopiuje repo z mojego Maca. Tyle rzeczy dzieje się naraz, tak szybko. To jest Cloudroom — tak wygląda praca z agentami chmurowymi. I nic z tego nie dotyka mojego komputera: nagrywam teraz wideo w 4K w OBS, wentylatory są ciche, bo wszystko biegnie w izolowanych piaskownicach w chmurze. Trzydzieści cztery agenty aktywne, czterdzieści dwa uśpione.
Taką pętlę — w której model graniczny jednego laboratorium pracuje, a drugie weryfikuje jego ustalenia i w razie niczego się nie dzieje sama się archiwizuje — można rzucić na testy penetracyjne, ulepszanie produktu, research opinii użytkowników, wszystko bez waszego udziału. Tylko przy poważnym problemie, wymagającym waszego osądu, każe się jej czekać. A gdy poprawka jest oczywista — na przykład wyszła załatana wersja naruszonej zależności — możecie kazać agentowi głównemu naprawić, zaktualizować i wypchnąć na produkcję od razu. Jesteście w pełni kontroli i konfigurujecie wszystko po swojemu. Dlatego mówię: to narzędzie dla power userów.
Laptop jako wąskie gardło: analogia z biurem
Wróćmy na moment do tezy o laptopie. W miarę jak agenci będą potężniejsi, każdy z nich będzie coraz bardziej przypominał pracownika zdalnego. Wyobraźcie sobie, że kogoś zatrudniacie i mówicie: „słuchaj, będziesz pracować na tym komputerze — aha, używa go jeszcze pięć osób z zespołu”. Taki człowiek odszedłby pierwszego dnia. Dokładnie tak czują się agenci. Do tego mocniejsze modele będą potrzebować więcej zasobów — a zwłaszcza sterowanie komputerem, które w ostatnich miesiącach robi ogromne postępy, także w projektach open source, jak agentowe sterowniki GUI czy harnessy przeglądarkowe. Każdy, kto próbował, wie, jak irytujące bywa, gdy agent otwiera okienka, przełącza fokus ekranu albo otwiera kolejne karty przeglądarki — ale jednocześnie chcemy, żeby przeglądarkę i aplikacje używał. Rozwiązanie jest jedno: dać każdemu agentowi własny komputer, czyli izolowaną piaskownicę w chmurze.
Zresztą nikt nie hostuje strony internetowej na laptopie — i te same argumenty dotyczą agentów. lokalnie jest po prostu wygodnie: Claude Code wyznaczył tu szlak, potem narzędzia typu agent zero, CLI Codexa, Hermes — instalacja w terminalu jest prosta. Trudne jest coś innego: zarządzać infrastrukturą dla wielu użytkowników tak, żeby działała i była tania. Dlatego nikt się za to nie zabrał, nikt tego nie otworzył i na pewno nikt nie zrobił tego z darmowym planem — który, nawiasem mówiąc, ma być darmowy na zawsze. Będę pracował ile sił, żeby darmowy plan był jak najmocniejszy. Oczywiście kosztuje mnie to pieniądze i będzie dofinansowywany przez kupujących plany Pro i Ultra — jeśli chcecie wesprzeć, wejdźcie na cloudroom.dev. Ale fakty są takie: żadna firma na świecie nie rozgryzła tego problemu — do dzisiaj.
Lokalnie czy w chmurze? Podział 90/10
Praca lokalna i chmurowa to nie jest wybór czarno–biały. Dość bezpieczne przypuszczenie: za pół roku około 90% pracy będzie wykonywane przez agentów chmurowych i jakieś 10% lokalnie — zależnie od charakteru zadań. Mam w zespole osoby, które działają wyłącznie w chmurze, bo ich praca to research i wiedza, i lokalny tryb po prostu omijają. Ja sam wciąż używam lokalnego — rozwijam przecież Cloudroom i czasem muszę coś poprawić, uruchamiając wątek lokalnie. Są przypadki, gdzie lokalnie ma sens: praca bardzo prywatna, na własnym systemie operacyjnym — choćby rozwój pod macOS w Xcode, bo Apple ogranicza to do sprzętu Mac — albo ciężki rendering, gdy macie Maca Studio albo wypchanego MacBooka Pro, na którym uciśniecie się szybciej niż w linuksowej piaskownicy. Ale dla 90, może nawet 95% zadań chmura jest lepsza — i przekonacie się o tym, przenosząc kolejne kawałki pracy.
I rada praktyczna: przenoście po jednym projekcie naraz. Nie przesuwajcie wszystkiego za jednym zamachem — natkniecie się na tarcie i to będzie zbyt duży skok. Przenieście 10%, potem 20%, jedno repo, drugie, trzecie, co tydzień trochę więcej. Wielu ludzi, z którymi rozmawiałem w pierwszych tygodniach budowy, było pewnych, że ich praca wymaga trybu lokalnego. Gdy zagłębiałem się w szczegóły, okazywało się, że to ograniczenie dotychczasowych rozwiązań chmurowych — Cursora, Devonu czy innych. Nie problem z chmurą jako taką, tylko z jej nieszczególnie dobrą implementacją. Przy porządnym narzędziu tę samą pracę da się zrobić w chmurze równie dobrze, a często lepiej.
Najlepsze narzędzie również do pracy lokalnej
Chcę być jednoznaczny: choć „cloud” stoi w nazwie i produkt jest zbudowany chmurowo w pierwszym rzędzie, Cloudroom jest też najlepszym narzędziem do pracy lokalnej — i jestem tego wysoce pewny. Częściowo dlatego, że zbudowaliśmy go na bazie BB. Ogromny ukłon w stronę BB i jego twórcy — świetne narzędzie; po miesiącu, półtora pracy z nim uznałem, że czas sforkować i przyspieszyć. Ale fundamenty są mocno utwardzone.
Mam dosłownie setki godzin spędzone w interfejsie Cursora — jednym z najlepszych na rynku. I co się działo? Gdy uruchamiałem więcej niż piętnaście drzew roboczych, aplikacja się wysypywała. Tweetowałem o tym wiele razy dziennie. Zespół był wtedy zajęty czym innym, nie przykładali do tego wagi, a w Cursorze siedziało kilka wycieków pamięci — bo to fork VS Code, wszystko jest przeglądarką i nie jest pod to zoptymalizowane. Dużo oprogramowania, powstającego przed obecną generacją modeli, po prostu nie zostało zaprojektowane na taką liczbę agentów — a z Opusem 5.5, który jest tak szybki, a niedługo z Fable 5.5 za rogiem, będziemy ich uruchamiać jeszcze więcej.
Zresztą samo demo: proszę o start stu podagentów lokalnie — połowa na Codexie z GPT‑6, połowa na Claude Code z Haiku 5.5 — żeby wymieniły po jednym konkurencie, bez żadnych zmian. I dodałem: „nie kombinuj, po prostu wystartuj tych stu”. Czasem trzeba modelowi powiedzieć, żeby nie przekombinowywał. Chciałem pokazać, że Cloudroom jest najmocniejszym narzędziem inżynierii agentowej także lokalnie. Sto podagentów ruszyło — po chwili słyszę wentylatory, bo to działa na moim procesorze i karcie. Kazałem je wstrzymać.
Przy okazji porównania: Cursora używałem, bo przyjął każdy model — po przejęciu to się skończyło, trenują własne modele i najnowszych GPT‑ów już nie wpuszczą; gdy wyjdzie Astra 6.5, też jej tam nie będzie. Aplikacja Codexa jest stabilniejsza niż GUI Cursora i wysypuje się rzadziej — ale działają w niej wyłącznie modele GPT. A teraz to Anthropic ma najlepsze modele — seria 5.5 jest znakomita, Fable 5.5 tuż-tuż — i nie użyjecie ich w aplikacji Codexa. W aplikacji Claude z kolei agenci nie mogą sterować innymi wątkami agentów — nie wiem czemu, ale się nie da. Spora część pierwszych beta-testerów przeszła do Cloudrooma właśnie z Claude Desktop z tego powodu.
Jeszcze drobiazg, który robi różnicę: kolejkowanie wiadomości. Możecie wpisać „uprość i skróć poprzednią odpowiedź”, potem zapytać „jaki dziś dzień” — kilka wiadomości w kolejce — a kombinacja command+enter wysyła coś natychmiast, omijając kolejkę. Wszystko to, co znacie z Codexa, Cursora i Claude Desktop, tu jest.
I miara zaufania na wczesnym etapie: między 11 a 15% użytkowników przyprowadziło znajomego, który dołączył, a ponad 25% w ogóle kogoś zaprosiło. Jak na produkt na starcie — szalone liczby.
Dostęp do Maca z agenta chmurowego — demo
Wróćmy do funkcji, o której wspomniałem: prosty i elegancki pomysł, a bardzo potężny. Startuję agenta w chmurze i proszę: „zajrzyj na mojego MacBooka i policz pliki w folderze Pobrane”. Cztery elementy. Dobrze — „wypisz pięć najnowszych, z datami, ale z cenzurą prywatnych nazw, bo nagrywam”. W nowym wątku (command+N) przechodzę na chmurę i pytam: „ile projektów mam w katalogu /code?”. Agent klonuje repozytoria z GitHuba — wszystko jest kompatybilne z gitem i GitHubem. Skoro piaskownice mają tak szybkie łącza, polecam trzymać kod na GitHubie i pozwalać agentom go błyskawicznie pobierać. Odpowiedź: 85 folderów, około 40 projektów; ciekawostka — 40 z nich to kopie strony Cloudroom. Pytam o łączny rozmiar, a potem schodzę głębiej: „wejdź w główne repo /code/cloudroom na moim Macu, znajdź folder branding, w nim główne logo — plik PNG — i otwórz mi je w podglądzie na MacBooku”.
Podkreślam: to wątek chmurowy. Przerywam bieżącą pracę, żeby pokierować — i od tego momentu nie dotykam klawiatury. Dałem agentowi pełne uprawnienia i on — w pełni pod moją kontrolą — może działać na moim MacBooku, gdy zadanie tego wymaga. Nie wymaga? Nigdy tego nie zrobi. Wymaga — załatwi.
Mała uwaga boczna: inferencja u Anthropicika dziś dziwnie wolna, a Opus zwykle jest szybki; może akurat wdrażają Fable — byłoby zabawnie, gdyby mnie to ominęło w trakcie nagrania, ale możliwe, że wkrótce film o Fable. Na Twitterze krążą przecieki, choć kto wie, czy prawdziwe. Na Codexie działa. Widzicie: agent używa narzędzia dostępowego do mojego Maca, znajduje właściwe repo… a szczerze mówiąc, przesadziłem w opisie — z tak mocnymi modelami można mówić ogólnikowo, same sobie poradzą. I proszę: plik otworzył się w podglądzie, na żywo, na moim MacBooku. Nie tknąłem myszką ani klawiaturą. Pytam na koniec: „na jakiej maszynie jesteś?” — potwierdzenie: chmurowa maszyna wirtualna, nie MacBook. Myślę, że widzicie punkt.
Architektura techniczna
Kilka słów dla najbardziej technicznych. Rdzeń pisany jest przede wszystkim w Ruście — 78% kodu — bo ma być tak szybki, jak się da; to język bezpieczny pamięciowo, a agenci Rusta uwielbiają. Produkt jest bardzo modularny: interfejs, aplikacja webowa i rdzeń to osobne aplikacje i osobne bazy kodu, osobne repozytoria na GitHubie — oba dostępne z poziomu strony cloudroom.dev.
Interfejs jest maksymalnie lekki — pokazywałem ponad 200 otwartych wątków, a do tego dorzuciłem jeszcze 100 podagentów lokalnie, czyli ponad 300 otwartych wątków naraz: żadnych lagów, długie czaty działają normalnie, nic się nie sypie. To zasługa fundamentów po BB — jeszcze raz wielkie podziękowania dla tego projektu i jego twórcy. Jeśli już używacie BB, przesiadka na Cloudroom będzie bardzo naturalna: dostajecie w zasadzie darmową moc chmurową na wątki, plus szereg usprawnień z ostatnich pięćdziesięciu dni — szybkie skróty klawiszowe, dopracowany interfejs, przeniesienie takich funkcji jak /context z Claude Code, o które prosiło wielu ludzi.
To jest właśnie piękno open source: projekt sforkowało już 46 osób. Forkujcie, budujcie na tym — to wzmacnia wszystkich. Dlatego nazywam to przełomem technologicznym: czyni agentów chmurowych dostępnymi dla każdego. OpenAI, Anthropic, Cursor, Devon, Cognition — każda z tych firm miała okazję to zrobić. Żadna nie zrobiła. Więc robię to sam.
Kilka dalszych decyzji: piaskownice — o których już mówiliśmy — to kluczowa decyzja architektoniczna. Szybkość — dla zaawansowanych ma znaczenie, więc wszystko jest pod skróty klawiszowe: skok do najstarszego wątku, powrót na górę, command+N na nowy wątek, a w ustawieniach można przypisać klawisze do praktycznie wszystkiego. Pełna kompatybilność z GitHubem — po autoryzacji import idzie gładko. No i systemy: macOS i Linux w pierwszym rzędzie. Jeśli nie macie ani jednej takiej maszyny, moja szczera rada: kupcie przynajmniej jedną. macOS jest po prostu stabilny i przewidywalny, Apple robi najlepszy sprzęt, a inżynierowie z czołówki AI od lat pracują na MacBookach — między innymi ze względu na wspólną pamięć procesora i karty graficznej. Linux jest lekki, konfigurowalny i otwarty. Widać wyraźny trend budowania narzędzi najpierw pod agentów, a ci działają właśnie na tych dwóch systemach. Windows wśród ludzi na froncie z każdym rokiem traci — w korporacjach zostanie, ale power userzy siedzą na Macach i Linuksie. To będzie dobra inwestycja w przyszłość. Jeśli chcecie więcej szczegółów technicznych — mamy bloga na cloudroom.dev/blog, wszystkie wpisy pisane ręcznie, przeze mnie lub mojego inżyniera założyciela. A oba repozytoria są otwarte — możecie kazać własnemu agentowi je przeczytać i wytłumaczyć wam architekturę.
Biznes: darmowy plan, finansowanie, rekrutacja
Na koniec konkrety. Cloudroom to mój następny wielki zakład — idzie w niego 80–90% mojego czasu. To mój kolejny startup AI, który będę budował między San Francisco a Polską. Rekrutujemy: rolę inżynierskie, ale też contentowe — strateg YouTube, montażystów. I ogólnie: jeśli jesteście utalentowani, skupieni, poważnie nastawieni na AI i pracowici — napiszcie do mnie. E-mail znajdziecie w opisie filmu: przedstawcie się, podajcie doświadczenie i rolę, o którą się ubiegacie, i bądźcie maksymalnie zwięzli. Bonus za krótkie wideo z prezentacją.
Dziś jestem w pełni samofinansowany, z bardzo zgranym, małym zespołem — nie muszę zbierać pieniędzy. Ale żeby przyspieszyć, prawdopodobnie pierwszy rundę zamknę w grudniu lub styczniu. Największym kosztem będzie moc obliczeniowa w chmurze: próbuję utrzymać darmowy plan jak najmocniejszy, na zasadzie modelu biznesowego Supabase — tam też macie darmowy plan na zawsze i open source, a gdy przekroczycie limity, kupujecie płatny. Dokładnie ten sam pomysł. Utrzymanie darmowego planu będzie dużo kosztować, więc dofinansują go klienci Pro i Ultra — choć i oni kosztują, bo dostają sporo chmurowej mocy. Nie wiem nawet, czy plany płatne będą rentowne — zobaczymy po starcie, gdy będę miał dane o zużyciu. Ale to właśnie główny argument za zebraniem kapitału pod koniec roku: pokrycie kosztów obliczeń i agresywne zatrudnianie najlepszych ludzi na świecie.
Jak to się zaczęło
Cloudroom powstawał intensywnie przez ostatnie pięć, sześć tygodni — a właściwie dłużej, bo to złożenie kilku projektów: drobnych narzędzi open source publikowanych na moim prywatnym GitHubie oraz w ramach Vector Labs przez jakieś trzy miesiące. Pomysł krystalizował się z tygodnia na tydzień, aż w końcu przybrał kształt: open source’owi agenci chmurowi, nazwani Cloudroom.
Cały czas nurtowało mnie jedno pytanie. Modele są już wystarczająco dobre — Fable, Astra, Opus 5.5. Narzędzia agentowe też. Czego więc brakuje, żeby uruchamiać tysiące agentów produktywnie? I „produktywnie” to słowo klucz: każdy potrafi odpalić tysiące modeli, żeby robiły losowe, bezużyteczne rzeczy. Chodzi o to, żeby robiły realną, wartościową pracę — taką, za którą byście zapłacili — i podnosiły wasze życie i firmę na wyższy poziom. Odpowiedź okazała się być: wszystkiego innego. Całego tarcia po stronie środowiska: internet się zrywa, komputer się przegrzewa, agenty się gryzą, bo jest ich za dużo na jednej maszynie, laptop trzeba zamknąć — i agenty stają. Agenci muszą działać bez przerwy; to, że mogą przestać, powinno być przestępstwem. Te wszystkie powody — i wiele innych, które rozwieziemy po drodze — nie pozwalają dojść do tysiąca agentów pracujących produktywnie. I właśnie te dwa–trzy miesiące pracy zbiegły się w jeden pomysł: Cloudroom.
Przez ostatnie pięcia tygodni testowaliśmy go ciężko, ja i mój zespół, z około dwudziestoma beta-testerami — wielkie dzięki wszystkim, którzy dostali wczesny dostęp i dzielili się uwagami. A wy, oglądający, będziecie pierwszą falą użytkowników — macie szansę współtworzyć ten produkt. Jest do tego wbudowane narzędzie: w dowolnym projekcie mówicie agentowi „zgłoś to Davidowi, twórcy Cloudroom” — na przykład: „dziś aplikacja działała ociężale w wątkach chmurowych, zwykle jest szybko”. Agent ma w room CLI narzędzie wysyłania informacji zwrotnej; trafia do mojej bazy Postgresa, a u mnie automatyzacja chmurowa co dziesięć minut odpala wątek, który to zgłoszenie bada. (Mam ją teraz wstrzymaną — moje główne pętle wyciekały prywatne dane i maile klientów, więc wyłączyłem je przed nagraniem; normalnie działa piętnaście–dwadzieścia automatyzacji.) Więc gdy napotkacie błąd albo willę pomysł — po prostu powiedzcie agentowi: „wyślij to Davidowi”. On już wie, co robić. To naprawdę przyszłość budowania produktu.
I stąd apel do was wszystkich, bez względu na to, co budujecie: potrzebujecie takich pętli agentowych i powinniście zaczynać budować własną fabrykę oprogramowania. Moją rolą jest dostarczenie infrastruktury, żebyście mogli to robić łatwo. Nazwijmy to inżynierią agentową 2.0: orkiestracja dużej liczby agentów, logika i reguły tego, kiedy działają, zarządzanie masą agentów bez startowania każdego z osobna.
Zakończenie
Cloudroom jest zbudowany dla super power userów: ludzi płacących 400, 600, 800 dolarów miesięcznie lub więcej za subskrypcje Codexa, Claude, Cursora — po prostu za inferencję. Jeśli wydajecie ponad 400 dolarów miesięcznie, jesteście moim docelowym odbiorcą. Jeśli prowadzicie firmę i chcecie mocno wdrożyć AI w sobie i całym zespole — również. To nie jest produkt konsumencki i nie dla początkujących; nie konkuruję z Muse ani Instinct. A jeśli to wy — wypróbujcie plan Pro albo Ultra. Oba obejmują osobisty onboarding ze mną lub moim inżynierem założycielem, a klienci Ultra dostają kanał Slack z moim udziałem i zespołem. Problemy was albo waszego zespołu rozwiązujemy w ciągu paru godzin — mam przecież mnóstwo działających agentów, więc mogę sobie pozwolić na dużą dźwignię czasu.
Tyle ode mnie. Dziękuję za obejrzenie — i idźcie tego użyć. cloudroom.dev.