O czym jest ten film
- Czym jest agent działający w chmurze i dlaczego posiadanie własnego, dedykowanego komputera zmienia sposób pracy.
- Kluczowa przewaga: agent w chmurze pracuje niezależnie od twojej maszyny — możesz zamknąć laptopa, a zadanie i tak się dokończy.
- Zastosowanie pierwsze — weryfikacja zgłoszonych błędów: agent próbuje odtworzyć bug i nagrywa dowód.
- Zastosowanie drugie — naprawa błędów z nagraniem dowodowym, że poprawka faktycznie działa.
- Zastosowanie trzecie — QA: agent buduje plan testów i przechodzi całą aplikację funkcja po funkcji.
- Zastosowanie czwarte — pętle i automatyzacje: codzienne skanowanie kodu w poszukiwaniu podatności i błędów, z powiadomieniem na Slacku.
- Dwie polecane platformy: Cursor Cloud Agent i Devon Cloud Agent.
- Konfiguracja: integracja z Linear (MCP), środowisko z uruchomioną wersją aplikacji, zmienne środowiskowe i pętla code review.
- Wykorzystanie „computer use” — agent klika po aplikacji jak człowiek i nagrywa wideo z przebiegu.
- Pełny przykład: przypisanie zadania z Linear bezpośrednio agentowi w chmurze i pozostawienie go do pracy.
Redakcyjne tłumaczenie
Wprowadzenie: połowa mojej pracy z agentami dzieje się już w chmurze
Połowa mojego korzystania z agentów AI dzieje się teraz w chmurze. Kompletnie się w to wkręciłem — nie mogę przestać, i to bez żadnego rozsądnego powodu. Moja produktywność wzrosła, a w dzisiejszym filmie wszystko ci wytłumaczę. Porozmawiamy o tym, czym jest agent działający w chmurze, na cztery różne sposoby go wykorzystuję, jak mam skonfigurowane środowisko, a na koniec — tej części nie przegap — pokażę ci pełny przebieg od początku do końca.
Czym jest agent w chmurze
Zacznijmy od podstaw. Agent w chmurze to agent, który działa w chmurze. Ale mówiąc poważnie — jest tu jedna główna korzyść: agenci w chmurze mają własny, dedykowany komputer. A dzięki temu, że dysponują własnym sprzętem, można z nimi robić naprawdę ciekawe rzeczy.
Po pierwsze, pozwala to uniknąć pewnego problemu. Nie wiem, czy to znasz, ale za dawnych czasów, gdy pisało się kod, po skończonej pracy zamykało się laptopa i było po sprawie. Teraz, przy pracy z agentami, wysyłasz kilka poleceń, masz kilka wątków w toku — i musisz trzymać laptopa otwartego, bo gdy go zamkniesz, wszystkie procesy się zatrzymają. Tak właśnie pracuje większość ludzi.
I to jest ta jedna rzecz, którą musisz zrozumieć o agentach w chmurze: skoro działają na własnym, dedykowanym komputerze, mogą pracować tak długo, jak długo trzeba, aż zadanie zostanie ukończone. Nie zależą ode mnie ani od mojej maszyny.
(Informacja dodatkowa: autor wspomina na marginesie, że z tego samego powodu buduje własny „home lab” — prywatną serwerownię, by mieć własną chmurę.)
To jedna z głównych korzyści: agent ma własny komputer, działa w chmurze i może pracować bez końca. Ale są też inne zastosowania, o których się mówi, a które sprawiły, że jestem nie tylko produktywniejszy — nawet jakość tworzonych przeze mnie aplikacji stała się fenomenalna.
Zastosowanie 1: weryfikacja zgłoszonych błędów
Zamiast opowiadać, pokażę ci żywy przykład. Jeśli oglądasz moje filmy, wiesz, że do śledzenia zadań używam Linear. Muso, mój wspólnik, oznaczył mnie w zgłoszeniu. To błąd w jednej z naszych aplikacji o nazwie Pluto, którą budujemy. W zgłoszeniu jest napisane: „przebieg agenta zawiesza się w stanie streamingu, a inspektor raportuje zawieszony przebieg”. Mamy więc opis problemu od użytkownika, a nawet wideo i zrzut ekranu.
Ufam Muso, to mój kumpel. Ale muszę się upewnić, że to nie był odosobniony przypadek — że nie chodziło o jego przeglądarkę czy coś specyficznego u niego. Muszę mieć stuprocentową pewność, że ten błąd jest prawdziwy.
Są dwie platformy agentów w chmurze, które uwielbiam i z których korzystam: Cursor Cloud Agent oraz Devon Cloud Agent. Pamiętacie Devona, „inżyniera oprogramowania”? Jego platforma agentów w chmurze jest świetna. Platforma Cursora również. Pokażę wam obie, ale w tym przykładzie posłużę się środowiskiem Cursora.
(Informacja dodatkowa: „Devon” (Devin) to znany agent programistyczny reklamowany jako autonomiczny „inżynier oprogramowania”.)
Wszedłem na cursor.com. Jeśli chcesz używać platformy agentów w chmurze, trzeba wejść na stronę WWW — można też przez aplikację desktopową, ale ja wolę wersję webową. Mają też świetne aplikacje mobilne, więc mogę pracować z telefonu.
Napisałem po prostu: „zajmij się zgłoszeniem PLO230 (to zadanie z Linear), ale najpierw sprawdź, czy błąd jest rzeczywisty — spróbuj go odtworzyć”. Agent pracował godzinę i 54 minuty.
Ktoś może powiedzieć: „ale co, jeśli wiem, że ten błąd jest prawdziwy?”. Szczerze wierzę, że danie agentowi kontekstu i odtworzenie błędu pozwala mu w pełni zrozumieć problem, w pełni go zdiagnozować i stworzyć rozwiązanie, które naprawdę go naprawia.
Pracował więc prawie dwie godziny. Wiesz, co ja przez ten czas robiłem? Pracowałem na etacie, ogarniałem swoje sprawy, budowałem dalej. A gdy skończył — zobacz, co mi dostarczył. Dał mi wideo. To nagranie agenta korzystającego z własnego komputera — ma dostęp do komputera, ma maszynę z Linuksem i odtwarza na niej błąd. Dosłownie sam używa mojej aplikacji na żywo. No, nie na żywo w tej chwili, to nagranie — ale widać, jak klika, jak przełącza karty. I potwierdził, że aplikacja się zawiesza. Zablokowała się.
Mam więc nagranie problemu i agent wie, dlaczego on występuje. Raportuje dokładnie, na czym polega usterka — wie, co dokładnie jest nie tak. Teraz mogę mu powiedzieć: „napraw to”. A ponieważ ma kontekst tego, jak błąd się pojawił i na czym polega, lepiej zaproponuje poprawkę — nie prowizoryczny plaster, tylko trwałe rozwiązanie.
Inny przykład: „zajmij się zgłoszeniem PL228 z Linear, ale najpierw sprawdź, czy błąd jest rzeczywisty, a potem spróbuj go odtworzyć”. Tym razem agent załączył zrzut ekranu z odtworzonym błędem. To jest właśnie sposób numer jeden: weryfikacja zgłoszonych błędów.
Zastosowanie 2: naprawa błędów z dowodem
Numer dwa to faktyczna naprawa błędów. Ale uwaga: chcę dowodu naprawy — nagrania, na którym agent rzeczywiście testuje poprawkę. Zwłaszcza gdy zmiana dotyczy interfejsu. Powiedzmy, że był problem po stronie backendu i czat przestał działać — chcę, żeby agent przetestował czat, wysłał wiadomość, nagrał to i mi pokazał. To część mojego procesu przeglądu, w którym potrzebuję od agenta nagrania.
Oto przykład, jak Devon naprawia błąd. W aplikacji Pluto, pod zakładką „więcej”, jest zakładka e-mail — użytkownicy mogą nadać swoim agentom własny, dedykowany adres e-mail, a jako dostawcę usług używamy Agent Mail. Miałem problem: e-maile nie były zatwierdzane. Gdy e-mail został utworzony i aplikacja prosiła użytkownika o zatwierdzenie, kliknięcie „zatwierdź” po prostu nie działało.
Opisałem problem agentowi, agent zaproponował poprawkę, wprowadził ją, utworzył PR (Informacja dodatkowa: PR — pull request, zgłoszenie zmian do włączenia do kodu), a do PR-a dołączył wideo, na którym sam testuje zmianę. Zobacz: agent klika „nowy czat”, pisze „wyślij e-mail ze skrzynki Agent Mail”, to się odpala, klika „zatwierdź”, sprawdza log i — e-mail został wysłany.
Przegląd zmian jest teraz dużo łatwiejszy, bo nie tylko zakładam, że agent zrobił to dobrze — jestem tego niemal pewien, bo widzę to na żywo.
Ktoś zapyta: a co, jeśli agent zwyczajnie halucynuje i myśli, że działa, choć nie działa? Mam wiele przypadków, które to obalają. Widać tu test funkcji, który w niektórych miejscach się nie powiódł — Devon oznacza go jako niepowodzenie, jako błąd. Innym razem: „upload OK, ale indeksowanie nie powiodło się — wyczerpany limit embeddings platformy OpenAI”. To akurat kwestia pieniędzy — skończyły się kredyty — ale agent to wychwycił.
Dzięki agentom w chmurze może się to wszystko dziać w tle, gdy zajmuję się czymś innym. Wiąże się to z moim poprzednim filmem o pętlach — koniecznie go obejrzyj. Pętle mogą działać skutecznie i bez przerwań tylko wtedy, gdy używam czegoś takiego jak agent w chmurze.
Zastosowanie 3: zapewnienie jakości (QA)
Numer trzy to QA, czyli zapewnienie jakości. Za dawnych czasów, gdy pracowałem jako programista w korporacji, dostawało się zgłoszenia w Jirze, proponowało poprawki, wysyłało PR-y. Był tam ktoś od QA, którego zadaniem było testowanie funkcji i wręcz próbowanie jej zepsucia, by sprawdzić, czy działa.
Któregoś dnia chciałem zrobić taki test i to szaleństwo, że mogę zlecić QA sztucznej inteligencji. Poleciłem agentowi przetestować całą moją aplikację. Napisałem: „Chcę, żebyś stworzył plan testów, w którym przejdziesz każdą zakładkę, każdą funkcję, wszystko, co można zrobić w Pluto. Chcę, żebyś to przetestował, udokumentował i nagrał wideo. Jeśli test przechodzi — przechodzi. Jeśli nie — notujemy to i potem naprawiamy. Ale najpierw przetestujmy każdą funkcję i upewnijmy się, że wszystko działa. Zaplanujmy to — ile testów będziemy potrzebować”.
Agent stworzył plan: 166 testów w 21 zestawach. Widać, jak testuje przepływ onboardingu, wpisywanie e-maila, nawigację, sprawdzenie na urządzeniu mobilnym — mnóstwo nagrań, wszystko trwało godzinami. Potem dostałem raport: 147 zaliczonych, 2 niezaliczone, 6 częściowych, 9 zablokowanych przez zmienne środowiskowe (czyli nie skonfigurowałem agenta z wszystkimi potrzebnymi zmiennymi — pokażę to później), a 2 pominięte: jeden dotyczył wycofanej funkcji, drugi zabezpieczenia.
Zamiast ręcznie testować każdą rzecz, mogę powiedzieć agentowi w chmurze: „przetestuj te osiem funkcji, udowodnij, że działają, i nagraj wideo dla każdej z nich” — albo nagraj te, które nie działają, żebym miał kontekst, co jest zepsute i jak to naprawić. To wszystko jest możliwe z agentami w chmurze. Gdybyś uruchamiał to na swojej maszynie — a mam mocnego MacBooka — wentylator zaczyna wyć, wszystko zwalnia. Potrzebujesz agenta w chmurze. To samo można zrobić w Devonie.
Zastosowanie 4: pętle i automatyzacje
Na koniec — pętle i automatyzacje. O pętlach nie będę tu opowiadał, obejrzyj wcześniejszy film. Ale automatyzacje to fajna rzecz, którą ma w szczególności Cursor.
W zakładce automatyzacji jest kilka gotowych przykładów, ale dwie moje własne są szczególnie ciekawe. Pierwsza skanuje kod w poszukiwaniu podatności. Uruchamia się codziennie o 13:00 czasu wschodniego. Szczegółowa instrukcja każe jej sprawdzić każdą część aplikacji pod kątem luk. Gdy coś znajdzie, tworzy PR z poprawką i odzywa się do mnie na Slacku — mam skonfigurowany wyzwalacz Slacka. Dostaję wiadomość: „to był problem, to jest PR, który go naprawia, przejrzyj i scal”. Dzieje się to codziennie.
Druga automatyzacja szuka krytycznych błędów — działa jak ta od bezpieczeństwa, ale dotyczy bugów. Skanuje kod każdego ranka o 7:00. Dlaczego 7:00 i 13:00? Wybrałem losowe godziny, to nie ma znaczenia. Instrukcje każą agentowi przejrzeć kod i znaleźć błędy, a gdy coś znajdzie — utworzyć PR z poprawką i wysłać mi wiadomość na Slacku. To wszystko dzięki agentom w chmurze, bo gdy laptop jest zamknięty, takie rzeczy nie mogą się dziać.
Jak wygląda moja konfiguracja
Są cztery rzeczy, bez których nie wyobrażam sobie pracy z agentami w chmurze.
Po pierwsze — integracja z Linear (MCP). W Cursorze wystarczy wejść w ustawienia, potem integracje i połączyć Linear. Tak samo w Devonie: ustawienia, połączenia — mam podpięty Linear. Linear staje się miejscem, gdzie śledzimy zgłoszenia funkcji, błędy i całą resztę. Zaletą integracji MCP jest to, że gdy Muso wyłapie błąd i chcę na niego skierować agenta z chmury Cursora, wystarczy, że przypiszę mu zadanie — i agent zabiera się do pracy. (Informacja dodatkowa: MCP — Model Context Protocol, standard łączący agentów AI z zewnętrznymi narzędziami i danymi.)
Potrzebujesz miejsca do śledzenia zgłoszeń i błędów. U mnie to Linear. U ciebie może to być GitHub Issues (choć nie wiem, po co byś sobie to robił), Trello czy Notion. Cokolwiek lubisz. Ja bardzo lubię Linear — jego interfejs do mnie przemawia.
Po drugie — skonfigurowanie środowiska. I Cursor, i Devon to potrafią. W ustawieniach Cursora, w sekcji agentów w chmurze, jest zakładka środowisk. Klikam „nowe” i tworzę środowisko. Agent forkuje repozytorium, a potem prosi o zmienne środowiskowe. Podajesz je, są bezpiecznie przechowywane na platformie — robi to za ciebie sama platforma. Odtąd za każdym razem, gdy wywołuję agenta, ma on dostęp do działającej wersji kodu. Jeśli wejdę w zakładkę testów i kliknę „desktop”, zobaczę na komputerze uruchomioną wersję aplikacji. Istnieje ona dlatego, że skonfigurowałem środowisko. Tak samo w Devonie: ustawienia, środowisko, „dodaj repozytorium”.
Za każdym razem, gdy uruchamiam nowy wątek, agent ma pełny dostęp do działającego komputera z uruchomioną aplikacją. Dzięki temu może korzystać z „computer use” i przetestować aplikację po wprowadzeniu zmiany lub odtworzyć błąd.
Po trzecie i czwarte — pętla code review (Grep Loop). Wspominałem o tym w wielu filmach. Grep Loop to skill od ludzi z Greptile, jednego z moich ulubionych agentów do przeglądu kodu. Grep Loop wprowadza informacje zwrotne z przeglądu kodu z powrotem do agenta i dopóki agent nie odniesie się do wszystkich uwag recenzenta, nie przestaje działać — pętli się raz za razem. Po szczegóły odsyłam do mojego najnowszego wcześniejszego filmu o pętlach.
(Informacja dodatkowa: „skill” to pakiet instrukcji rozszerzający możliwości agenta o konkretny sposób działania. Greptile to narzędzie do automatycznego przeglądu kodu.)
Pełny przebieg na żywo
Na koniec pokażę agenta w chmurze w akcji. Wchodzę w Linear i — nawet nie czytam zgłoszenia — po prostu przypisuję je Cursorowi. Widać tę ładną animację; dlatego kocham Linear, praca zaczyna przypominać grę wideo. Gdy wracam do Cursora, mój agent w chmurze już wystartował. Ma kontekst ze zgłoszenia, zaczyna analizować problem i pracować nad poprawką. Może to potrwać 20 minut, 30 minut, godzinę — cokolwiek.
Pokażę też przykład z Devonem. Znów wystarczy przypisać zadanie agentowi Devona, wracam do Devona — i agent zabiera się do pracy.
Jeszcze jedno, o czym zapomniałem wspomnieć: na moim profilu GitHub, w repozytorium ze skillami (link w opisie), dodałem skill o nazwie „evidence-driven testing”. To skill, który każe agentowi nagrać wideo, zweryfikować zmiany i przeprowadzić test — wszystko to, o czym opowiadałem, zamknięte w jednym skillu.
I to jest chyba najlepsza część agentów w chmurze: agent po prostu robi swoje, a ja jestem wolny. Chyba wezmę Biblię i poczytam. Muszę tylko pozwolić mu pracować.
(Informacja dodatkowa: autor kończy film cytatem z Psalmu 1 i typowym dla siebie akcentem religijnym — nie ma to związku z częścią techniczną.)
10 najważniejszych takeaways — z kontekstem zastosowania
1.Agent w chmurze uwalnia cię od własnej maszyny
Na czym polega: Agent działa na dedykowanym komputerze w chmurze, więc pracuje niezależnie od twojego laptopa i może wykonywać zadanie przez godziny — nawet gdy zamkniesz komputer.
Jak stosować: Zlecaj długie zadania (odtwarzanie błędu, pełne QA) agentowi w chmurze i wracaj do własnej pracy; wybierz platformę taką jak Cursor Cloud Agent lub Devon.
Na co uważać: Dłuższy przebieg to realny koszt kredytów i czasu obliczeniowego — pilnuj limitów i nie zakładaj, że „działa w tle” znaczy „za darmo”.
2.Najpierw zweryfikuj, że błąd w ogóle istnieje
Na czym polega: Zanim naprawisz zgłoszony bug, zleć agentowi jego odtworzenie — nawet jeśli ufasz zgłaszającemu i wydaje się oczywisty.
Jak stosować: Formułuj polecenie dwuetapowo: „najpierw sprawdź, czy błąd jest rzeczywisty, potem go odtwórz”, i dopiero potem proś o poprawkę.
Na co uważać: Odtworzenie potrafi trwać długo (w przykładzie prawie dwie godziny); to inwestycja czasu, która opłaca się przy trudnych bugach, ale bywa nadmiarowa przy trywialnych.
3.Kontekst z odtworzenia daje trwalszą naprawę
Na czym polega: Gdy agent sam odtworzy i zdiagnozuje błąd, proponuje trwałe rozwiązanie zamiast doraźnego „plastra”.
Jak stosować: Nie proś od razu o poprawkę — najpierw pozwól agentowi zebrać kontekst (log, nagranie, diagnozę), a naprawę zlecaj na tej podstawie.
Na co uważać: Więcej kontekstu to więcej pracy agenta; przy prostych, dobrze zrozumianych błędach ten narzut się nie zwraca.
4.Żądaj dowodu w postaci nagrania, nie deklaracji
Na czym polega: Agent nagrywa wideo, na którym sam testuje poprawkę (klika, wysyła wiadomość, sprawdza log), co bardzo ułatwia przegląd zmian.
Jak stosować: W poleceniu wprost żądaj „dowodu naprawy z nagraniem, jak testujesz zmianę”, szczególnie przy zmianach w interfejsie.
Na co uważać: Agent może halucynować sukces — mimo nagrania samodzielnie weryfikuj kluczowe przypadki; nagranie zmniejsza ryzyko, ale go nie eliminuje.
5.QA można w dużej mierze zautomatyzować planem testów
Na czym polega: Agent potrafi sam zbudować plan (w przykładzie 166 testów w 21 zestawach), przejść aplikację funkcja po funkcji i zwrócić raport z podziałem na zaliczone/niezaliczone/zablokowane.
Jak stosować: Zleć „stwórz plan testów obejmujący każdą zakładkę i funkcję, testuj, dokumentuj i nagrywaj; notuj porażki do naprawy” — najpierw plan, potem wykonanie.
Na co uważać: Część testów może zostać zablokowana przez brakujące zmienne środowiskowe — bez pełnej konfiguracji raport będzie niekompletny i myląco „czysty”.
6.Skonfiguruj środowisko z działającą wersją aplikacji
Na czym polega: Środowisko forkuje repo i uruchamia żywą wersję aplikacji z bezpiecznie przechowywanymi zmiennymi, dzięki czemu agent może realnie klikać po aplikacji.
Jak stosować: W ustawieniach Cursora lub Devona utwórz środowisko, dodaj repozytorium i wprowadź wszystkie zmienne środowiskowe, zanim zaczniesz zlecać zadania.
Na co uważać: Pominięte zmienne środowiskowe cicho blokują funkcje i testy; kompletność konfiguracji decyduje o tym, czy „computer use” w ogóle zadziała.
7.Podłącz system śledzenia zgłoszeń przez integrację (MCP)
Na czym polega: Integracja z Linear (lub innym trackerem) pozwala przypisać zgłoszenie bezpośrednio agentowi, który przejmuje kontekst zadania.
Jak stosować: Połącz tracker w ustawieniach integracji, a potem uruchamiaj agenta jednym kliknięciem — przypisaniem zadania.
Na co uważać: Agent działa na podstawie tego, co jest w zgłoszeniu — słaby opis zadania da słaby wynik; nie „przypisuj bez czytania”, jeśli zgłoszenie jest niejasne.
8.Ustaw codzienne automatyzacje z powiadomieniem na Slacku
Na czym polega: Cursor pozwala uruchamiać zaplanowane skany kodu (np. podatności o 13:00, błędy o 7:00), które tworzą PR z poprawką i wysyłają wiadomość na Slacku.
Jak stosować: Skonfiguruj automatyzację z jasną instrukcją i wyzwalaczem Slacka, by dostawać gotowe PR-y do przeglądu i scalenia.
Na co uważać: Automatyczne PR-y wymagają ludzkiego przeglądu przed scaleniem — traktuj je jako propozycje, nie gotowe do wdrożenia zmiany; godziny uruchomień są dowolne i nieistotne.
9.Domknij pętlę przeglądu kodu (Grep Loop / Greptile)
Na czym polega: Grep Loop wprowadza uwagi z przeglądu kodu z powrotem do agenta i pętli go, dopóki nie odniesie się do wszystkich zastrzeżeń recenzenta.
Jak stosować: Połącz agenta wykonawczego z agentem przeglądu kodu w pętli, by zmiana nie „kończyła się” przed spełnieniem standardów jakości.
Na co uważać: Pętla działa bez przerwań tylko w chmurze; na lokalnej maszynie zamknięcie laptopa ją zrywa, a długie iteracje kosztują czas obliczeniowy.
10.Standaryzuj proces jako skill („evidence-driven testing”)
Na czym polega: Autor zamknął cały proces (nagraj wideo, zweryfikuj zmiany, przetestuj) w jednym reużywalnym skillu opublikowanym na GitHubie.
Jak stosować: Spisz powtarzalne wymagania jakościowe jako skill, by każdy agent stosował je automatycznie zamiast powtarzania instrukcji za każdym razem.
Na co uważać: Skill jest tak dobry jak zawarte w nim reguły — jeśli pomija istotne przypadki lub konfigurację środowiska, powieli tę lukę w każdym uruchomieniu.