O czym jest ten film
- Autor przedstawia własną umiejętność „drive screen”, dzięki której agenty kodujące (Claude Code, Codex) sterują całym pulpitem wyłącznie z terminala.
- To lekka alternatywa dla przeładowanych, gotowych narzędzi typu computer use — niczego nie trzeba instalować ani budować dodatkowej otoczki.
- Rozwiązanie przetestowano na Windows, macOS i Linuksie, także przy wielu monitorach i różnych ustawieniach ekranu.
- Codzienne zastosowania obejmują poranny setup (karty w przeglądarce, Obsidian, aplikacje, kontenery Dockera), który oszczędza 10–15 minut dziennie.
- Umiejętność narodziła się z potrzeby testowania desktopowych aplikacji projektów open source, których nie da się obsłużyć automatyzacją przeglądarki.
- To niecałe 400 linii: pełny workflow, twarde zasady wypracowane na własnych błędach oraz mini-CLI ze skryptami do odnajdywania okien, ustawiania fokusu, pisania i wklejania.
- Umiejętność każe agentowi najpierw sprawdzić, czy sterowanie ekranem jest w ogóle potrzebne — bo to najwolniejsza i najbardziej zawodna droga działania.
- Osobny wątek to bezpieczeństwo: odporność najnowszych modeli na ataki prompt injection oraz sytuacje, w których jednak warto sięgnąć po pełną otoczkę narzędziową.
- Całość jest oszczędna pod względem tokenów — zwolnienia wynikają z oczekiwania na interfejs, a nie ze spalania dziesiątek tysięcy jednostek.
- Umiejętność jest dostępna w repozytorium autora: jako wtyczka Claude Code albo folder do skopiowania do dowolnego agenta kodującego.
Redakcyjne tłumaczenie
„Drive screen” — umiejętność, z której korzystam codziennie
Mam nową ulubioną umiejętność, którą używam w Claude Code i Codexie każdego dnia, do dosłownie wszystkiego. Nazwałem ją „drive screen” — sterowanie ekranem. Chcę dziś pokazać, jak działa, bo zbudowałem ją jako lekką alternatywę dla przeładowanych i trudnych w utrzymaniu narzędzi do sterowania komputerem — takich jak wbudowana w platformę Claude funkcja computer use czy Codex computer use. Na rynku jest też mnóstwo rozwiązań open source. Wszystkie są potężne, ale nigdy nie przypadły mi do gustu, dlatego zbudowałem własne. A najpiękniejsze w tym, co powstało, jest to, że wystarczy sam agent kodujący. Nie trzeba niczego instalować ani stawiać żadnej otoczki narzędziowej (tzw. harness). Duże modele językowe — zwłaszcza Fable 5.1 i GPT-6 Astra — są już na tyle dobre, że potrafią prowadzić cały ekran w praktycznie każdej sprawie, posługując się samą linią poleceń. Sam przekonałem się o tym dopiero kilka tygodni temu, kiedy po prostu to wypróbowałem. I tak powstawała ta umiejętność, którą bardzo cenię, bo działa niezależnie od systemu operacyjnego — nie muszę już niczego doinstalowywać ani polegać na wielkim, pudełkowym narzędziu computer use.
(Informacja dodatkowa: w Claude Code „skill”, czyli umiejętność, to pakiet instrukcji i skryptów, które agent wczytuje na żądanie, by powtarzalnie wykonywać określone zadania.)
Dlaczego omijałem gotowe rozwiązania
Jak mówiłem, nigdy nie byłem ich fanem. Zależy mi na pełnej kontroli nad własnym warsztatem, a w tych narzędziach bardzo trudno cokolwiek dostosować czy poprawiać na bieżąco, gdy przy wdrażaniu do codziennego obiegu wychodzą drobne problemy. Dlatego w ogóle trzymałem się z dala od computer use. Kłopot w tym, że sterowanie komputerem bywa niesamowicie użyteczne — i w ostatnich tygodniach uświadamiam sobie to coraz mocniej. Nie bez powodu teraz nie mogę się od tej umiejętności oderwać. Jeśli więc w ogóle nie korzystasz z computer use, zachęcam, żebyś choć zaczął poeksperymentować — na przykład z Codex computer use. Oczywiście zachęcam też, byś wypróbował moją umiejętność; link znajdziesz w opisie. Możliwości podniesienia produktywności, jakie daje agentowi kodującemu taka zdolność, jest bez liku. Owszem, pojawiają się kwestie bezpieczeństwa, zwłaszcza gdy zamiast pełnej otoczki uruchamia się samą umiejętność — wrócimy do tego — ale jest tyle szybkich korzyści, na których polegam każdego dnia, że chcę je tu pokazać.
Poranny start stanowiska pracy
Najbardziej oczywisty przykład: agent pomaga przygotować się do dnia. Włączasz komputer, otwierasz agenta kodującego i mówisz: „przygotuj mi poranek, oto nad czym dziś pracuję”. Może nawet zajrzeć do Twojego menedżera zadań — przez interfejs wiersza poleceń albo MCP — a potem otworzyć odpowiednie karty w przeglądarce, zakładki w Obsidianie, uruchomić aplikację desktopową, kontenery Dockera, cokolwiek potrzebujesz. Ustawi wszystko. Samo to oszczędza mi porządne 10–15 minut każdego ranka, a to się sumuje, zwłaszcza razem z resztą rzeczy, które pokażę. Całość opiera się na umiejętności i prostych poleceniach — żadnych dodatkowych narzędzi. Przetestowałem to na wszystkich trzech systemach: macOS, Linux i Windows, przy konfiguracjach wielomonitorowych i różnych ustawieniach wyświetlania. Działa naprawdę dobrze i świetnie się adaptuje.
Duże modele stały się zaskakująco uniwersalne
I jeszcze jedno: nawet jeśli ta konkretna umiejętność Cię nie pociąga, najważniejszy wniosek — ten, który robi na mnie największe wrażenie — dotyczy tego, jak bardzo wszechstronne stały się duże modele językowe. Mnóstwo zadań wcześniej odpisywałem: „model tego nie zrobi”, „na pewno potrzeba jakiegoś potężnego narzędzia”. Tymczasem już nie. Pewnie i teraz masz w głowie parę rzeczy, o których myślisz, że model sobie z nimi nie poradzi — sterowanie komputerem, montaż wideo. Wydaje Ci się, że trzeba specjalistycznego oprzyrządowania, a tak nie jest. Po prostu spróbuj, teraz. Wrzuć modelowi plik MP4 i powiedz: zmontuj ten film, wytnij wypełniacze typu „yyy”, dodaj materiały ilustracyjne (tzw. B-roll) i przejścia. Zwłaszcza z Fable i Astrą da sobie świetnie radę.
Narodziła się z czystej potrzeby
Szczerze mówiąc, umiejętność drive screen powstała z konieczności. Ostatnio przytłacza mnie lawina wydarzeń w świecie AI — nowe rzeczy, aplikacje, które wypróbowuję, a zwłaszcza sporo projektów open source, jak na przykład Kestra. Wiele z nich ma własny interfejs graficzny albo coś, czego nie obsłużysz automatyzacją przeglądarki. Potrzebowałem więc jakiegoś computer use do testów, ale jednocześnie czegoś superlekkiego i łatwego w zarządzaniu. Nie chciałem wciągać pełnowymiarowego narzędzia. Wtedy po prostu wziąłem adres GitHuba tego projektu — i pozostałych, które testowałem; to tylko jeden przykład — podałem go Claude i powiedziałem: zbadaj sieć, wejdź głęboko w repozytorium, żeby zrozumieć funkcje, potem uruchom aplikację desktopową, dalej steruj moim ekranem i przetestuj różne możliwości, a na koniec zostaw wszystko otwarte, żebym mógł kontynuować własne testy. Nie miałem pojęcia, czy to zadziała. Spodziewałem się, że sięgnie po jakieś większe narzędzie computer use i je zainstaluje albo powie, że nie potrafi, i kazać mi działać ręcznie. Ku mojej miłej niespodziance zrealizował całe zadanie od początku do końca, po prostu uruchamiając polecenia w terminalu.
(Informacja dodatkowa: Kestra to open-source’owa platforma do orkiestracji przepływów pracy.)
W logach sesji wyglądało to mniej więcej tak (zwłaszcza zanim miałem umiejętność): polecenie za poleceniem — klika, robi zrzuty ekranu, analizuje wyniki. Ale wykonał całość. Zajęło to sporo czasu i nie należało do najszybszych — computer use w ogóle taki nie jest — ale pozwoliłem mu działać: przejął komputer, a ja w tym czasie pracowałem na innym urządzeniu. Wracam — wszystko zrobione, a aplikacja wciąż otwarta, żebym mógł dalej testować. Piękna sprawa. A wszystkie te polecenia to na Windows po prostu PowerShell — żadnego dodatkowego narzędzia. Na macOS wystarczy AppleScript. Testowałem na każdym systemie. Wciągnąłem się bez reszty: testuję mnóstwo aplikacji, robię poranny setup, codziennie przygotowuję wszystko pod nagrania i prezentacje.
Od prowizorki do pełnoprawnej umiejętności
Na początku nie było żadnej umiejętności — mówiłem po prostu: „użyj PowerShella, żeby sterować moim ekranem, i zrób to i tamto”. Bardzo szybko jednak okazało się, że potrzebny jest pełny skill, bo czasami sterowanie przez PowerShell w ogóle nie chciało działać. Agent kompletnie się gubił albo powtarzały się określone sytuacje awaryjne, które z czasem utworzyły wyraźne wzorce. Udokumentowałem je wszystkie, rozpisałem workflow, a nawet napisałem kilka skryptów, żeby czynności były bardziej powtarzalne (deterministyczne). I to właśnie spakowałem jako umiejętność dla Was.
(Informacja dodatkowa: poniższy fragment to płatna sekcja sponsorska z oryginalnego materiału, zachowana dla kompletności.)
Fragment sponsorowany: Plural
Sponsorem dzisiejszego filmu jest Plural, który zbudował coś naprawdę fajnego: agentów DevOps żyjących w Twoim własnym klastrze Kubernetes. Ustalają, co się zepsuło, a potem otwierają pull requesty z poprawką. Nazywają to „workbenchami”. Pokażę na przykładzie: w moim klastrze jeden z serwisów, API płatności, restartuje się w pętli. Wystarczy wejść do workbencha, w którym mogę zlecić dowolne zadanie, i napisać: „serwis API płatności restartuje się w pętli; znajdź przyczynę źródłową i otwórz pull request z poprawką”. Plural uruchamia podagenty, z których każda ma własny kontekst i zagłębia się w pody, logi oraz repozytorium GitOps. Po paru minutach dostaję dokładną diagnozę, diff z dowodami, a do tego panel pomagający zrozumieć, co dzieje się w klastrze. A część, którą lubię najbardziej: Plural stawia w moim klastrze instancję Claude Code, która wprowadza poprawkę i otwiera pull request. Agent pracuje w moim środowisku, z moimi kluczami do modeli, a decyzja o scaleniu zmiany i tak należy do mnie. Ten sam workbench można podpiąć pod alerty, uruchamiać cyklicznie (cron) albo wyzwalać hasłem „plural, napraw to” w tickecie Jiry. Plural można hostować samodzielnie albo korzystać z ich chmury; na start jest bezpłatnie. Link w opisie.
Demonstracja na żywo
Zanim przejdziemy do tego, jak umiejętność jest zbudowana, jak utrzymałem ją prostą i jakie wiążą się z nią kwestie bezpieczeństwa, pokażę szybko, jak to wygląda w akcji. Materiał wyraźnie przyspieszę, ale wyślę prompt, żebyśmy zobaczyli całość na własne oczy. Umiejętność się ładuje i bez trudu przechodzi przez każdy krok przygotowania. Wyłączę obraz z kamery i przewinę do przodu. I proszę: wszystko zrobione w niecałą minutę. Wiem, że to bardzo prosty przykład i nie zamierzam teraz robić nic rozbudowanego, ale chodzi o samo tempo. Nie potrzebował też wielu poleceń, bo umiejętność go prowadzi i daje mu narzędzia do szybszego działania. Nawiasem mówiąc, to, co zrobił, obejmowało także walidację środowiska — sprawdzenie, czy ma wszystkie potrzebne narzędzia i odpowiednie uprawnienia na maszynie.
Pod maską: jak zbudowana jest umiejętność
Całość ma nieco mniej niż 400 linii. Ani najdłuższa, ani najkrótsza. Zależało mi na rozpisaniu pełnego workflow dla agenta i na działaniu na każdym systemie operacyjnym; wbudowałem też sporo niuansów — drobne scenariusze awaryjne wyłapane podczas testów.
Workflow zaczyna się od pytania: czy w ogóle potrzebujemy sterowania ekranem? Chcę, żeby agent mógł odmówić i zasugerować coś efektywniejszego, bo czasami computer use wcale nie jest potrzebny — wystarczy inne narzędzie, np. automatyzacja przeglądarki. Jak stoi wprost w umiejętności: sterowanie ekranem to najwolniejszy i najbardziej zawodny sposób wykonywania czegokolwiek na komputerze. Jest za to najbardziej uniwersalne i elastyczne. Do tego dochodzi bezpieczeństwo: na ekranie może pojawić się atak typu prompt injection — agent go zobaczy i wykona coś złego. Wielkie modele już praktycznie nie dają się na to nabrać, co zresztą jest ważnym powodem, dla którego w ogóle powierzyłem im taką możliwość. Ale warto to mieć z tyłu głowy. Dlatego też trzymam się prostych zastosowań; gdybym potrzebował computer use klasy produkcyjnej, nadal sięgnąłbym po większe narzędzie z pełną otoczką.
Na początku pliku umiejętności znajdują się skrypty, które idą w komplecie. Dają większą powtarzalność: zamiast każeć agentowi na żywo kombinować dokładne polecenia — jak to było u mnie na starcie — wszystkie najlepsze praktyki spakowałem w skrypty do odnajdywania okien, ustawiania fokusu, pisania i wklejania. Na każdą z tych czynności jest wiele sposobów; ja wybrałem najlepsze z wielu, wielu godzin testów i złożyłem je w rodzaj mini-CLI, po który agent sięga z konkretnymi poleceniami i argumentami. To mój własny mały interfejs — nie będziemy teraz wchodzić w szczegóły, bo operacji jest sporo, ale to duża część tego, dlaczego całość działa pewnie. I bardzo łatwo to modyfikować: jeśli pracujesz na przykład na innej dystrybucji Linuksa, gdzie coś może działać inaczej, po prostu edytujesz umiejętność. Po instalacji z mojego repozytorium dostajesz całość: dokumentację referencyjną, plik skill.md i wszystkie skrypty.
Niżej mamy twarde zasady — rzeczy, których dowiedziałem się na własnej skórze, budując tę umiejętność i używając jej w kółko; dzięki temu jest niezawodniejsza. Jest pętla sterowania: kiedy działasz w oknie, najpierw odnajdź je poleceniem, zrób zrzut ekranu, żeby rozeznać się w sytuacji, ustaw fokus, dopiero wtedy działaj — a tutaj masz sposoby działania i CLI, które w tym pomaga. Widać, jak wszystko się spina. Jest też osobny zestaw poleceń do obserwowania sesji: jeśli umiejętność ma prowadzić inną sesję agenta kodującego, musi wypatrywać próśb o zatwierdzenie i tym podobnych — dużo tego robiłem. Przy automatycznym prowadzeniu dochodzą różne pułapki, na które trzeba uważać. Część jest specyficzna dla tego, co ja automatyzuję: karty przeglądarki, aplikacje desktopowe, inne sesje agentów kodujących. Może Ty robisz to samo, a może nie — w każdym razie możesz wziąć umiejętność i dopasować ją do siebie: usunąć pułapki, które Cię nie dotyczą, albo dodać własne. Właśnie tego nie zrobisz z dużym narzędziem computer use — i dlatego w kółko wracam do tego, jak cenię tę elastyczność.
Bezpieczeństwo: ataki typu prompt injection
Przy computer use w ogóle trzeba mieć świadomość prompt injection. Link do bardzo dobrego artykułu zostawiam w opisie. Ale powiem tak — choć może jeszcze wyjdzie mi to bokiem — moim zdaniem nie trzeba się tym już specjalnie przejmować, o ile korzystasz z najlepszych nowych modeli, jak Fable 5.1 i GPT-6 Astra. Wychodzi sporo badań pokazujących, że nawet bez wyrafinowanych zabezpieczeń czy pełnej otoczki bardzo trudno jest skłonić te modele do wykonania wstrzykniętej instrukcji. Dziś mnie to nie niepokoi — choćby w przybliżeniu tak bardzo jak kiedyś. I Ty nie musisz się martwić. Zwłaszcza przy prostych zadaniach, jak te z filmu — poranny setup czy testowanie aplikacji — naprawdę nie ma się czym przejmować. Po prostu używaj najmocniejszych modeli: to i tak podnosi niezawodność computer use.
Wydajność i zużycie tokenów
Ta umiejętność jest dość oszczędna pod względem tokenów. Nie jest najszybsza — ale dlatego, że czeka na różne dane wejściowe, a nie dlatego, że spala dziesiątki tysięcy jednostek. Korzystaj na własną odpowiedzialność i zachęcam do lepszych modeli. Ale przynajmniej dla mnie computer use już nie jest ryzykiem — zwłaszcza że mam coś, nad czym tak bardzo panuję.
Instalacja i słowo na koniec
Zainstaluj umiejętność i wypróbuj. Nie musisz dokładać żadnych narzędzi — jest w moim repozytorium umiejętności AI na GitHubie. Możesz zainstalować ją jako wtyczkę Claude Code (dostaniesz wtedy wszystkie moje umiejętności) albo po prostu skopiować folder, do którego linkuję w opisie, do dowolnego agenta kodującego. Mam nadzieję, że Ci się przyda — tak jak mnie przydaje samo odkrywanie, na co stać dziś duże modele: robią niesamowite rzeczy bez dodatkowej otoczki. Jeśli doceniasz ten film i czekasz na więcej o umiejętnościach agentów kodujących i sztucznej inteligencji w programowaniu, będę wdzięczny za łapkę w górę i subskrypcję. Do zobaczenia w następnym materiale.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Sterowanie pulpitem nie wymaga już ciężkich narzędzi
Na czym polega: Nowe modele klasy Fable 5.1 czy GPT-6 Astra potrafią prowadzić cały ekran, wydając polecenia z terminala — PowerShell na Windows, AppleScript na macOS, standardowy shell na Linuksie — bez instalowania platform computer use.
Jak stosować: Weź agenta kodującego, opisz zadanie zwykłym językiem i pozwól mu działać w terminalu; dopiero gdy zabraknie niezawodności, sięgaj po pełnoprawne narzędzie.
Na co uważać: Ta droga jest wolniejsza i bardziej zawodna niż dedykowane rozwiązania — do zadań produkcyjnych autor sam wraca do pełnej otoczki.
2.Zacznij od porannego setupu
Na czym polega: Agent może rano sam otworzyć karty w przeglądarce, zakładki w Obsidianie, aplikacje i kontenery Dockera, czerpiąc wiedzę o zadaniach na dany dzień z menedżera zadań przez CLI lub MCP.
Jak stosować: Sformułuj jedno polecenie typu „przygotuj mi poranek” i podłącz źródło zadań; autor oszczędza tak 10–15 minut dziennie, co w skali miesiąca daje kilka godzin.
Na co uważać: Przy pierwszych uruchomieniach pilnuj, co agent faktycznie otwiera — listę aplikacji i kart warto mieć zapisaną w treści umiejętności.
3.Zanim sięgniesz po sterowanie ekranem, sprawdź alternatywy
Na czym polega: Sterowanie pulpitem to najwolniejszy i najbardziej zawodny sposób działania na komputerze — używaj go tylko wtedy, gdy nie ma prostszej drogi, np. automatyzacji przeglądarki.
Jak stosować: Umieść w umiejętności zasadę, że agent może odmówić i zaproponować szybszą metodę; pozwól mu samodzielnie dobierać narzędzie do zadania.
Na co uważać: Nie każ agentowi klikać w aplikacjach webowych, które da się obsłużyć przez API albo automatyzację przeglądarki — to marnowanie czasu i tokenów.
4.Spakuj sprawdzone polecenia w skrypty
Na czym polega: Zamiast pozwalać agentowi improwizować komendy na żywo, autor zamknął najlepsze praktyki (odnajdywanie okien, fokus, pisanie, wklejanie) w mini-CLI, po który agent sięga z argumentami.
Jak stosować: Po każdej sesji, w której agent się pogubił, przenieś działające polecenia do skryptu i odwołuj się do niego parametrami — to podnosi powtarzalność.
Na co uważać: Skrypty trzeba testować na każdym systemie — to, co działa w PowerShellu, nie zadziała w AppleScript.
5.Trzymaj się pętli: odkryj → zrzut ekranu → fokus → działaj
Na czym polega: Niezawodna sekwencja pracy w oknie: odnajdź je poleceniem, zrób zrzut ekranu dla rozeznania, ustaw fokus, dopiero potem wykonaj czynność.
Jak stosować: Zapisz tę pętlę jako twardą zasadę umiejętności, żeby agent nie próbował działać „na pamięć”, bez spojrzenia na aktualny stan interfejsu.
Na co uważać: Pominięcie zrzutu ekranu to najczęstsze źródło pomyłek — model działa wtedy na nieaktualnym obrazie i klika w złe miejsca.
6.Dokumentuj pułapki jako twarde zasady
Na czym polega: Awaryjne sytuacje powtarzają się w wyraźnych wzorcach — na przykład pułapki przy prowadzeniu innej sesji agenta i czekaniu na jej zatwierdzenia; udokumentowane stają się regułami w pliku umiejętności.
Jak stosować: Prowadź notatki z każdej sesji i przerabiaj powtarzające się błędy na punkty w skill.md — z czasem umiejętność „uczy się” Twoich środowisk.
Na co uważać: Część pułapek jest specyficzna dla konkretnych aplikacji — przy przenoszeniu umiejętności na inne narzędzia weryfikuj, które nadal obowiązują.
7.Nie odpisuj zadań jako „za trudnych dla modelu”
Na czym polega: Autor przekonał się, że czynności uznawane za niemożliwe bez specjalistycznych narzędzi — sterowanie pulpitem czy montaż wideo z wycinaniem wypełniaczy i dodawaniem materiałów B-roll — są dziś w zasięgu samych modeli.
Jak stosować: Zanim zaczniesz szukać narzędzia, wrzuć modelowi surowe dane (np. MP4) i opisz oczekiwany efekt; taki test trwa kilka minut.
Na co uważać: Jakość zależy mocno od wersji modelu — eksperymenty rób na najlepszych dostępnych, słabsze łatwo się zawiodą i zniechęcisz się przedwcześnie.
8.Prompt injection: mniejsze ryzyko, ale nie zero
Na czym polega: Według autora i cytowanych przez niego badań najnowsze modele klasy Fable 5.1 i GPT-6 Astra są bardzo odporne na wstrzyknięte instrukcje nawet bez dodatkowych zabezpieczeń i pełnej otoczki.
Jak stosować: Przy prostych, codziennych zadaniach (poranny setup, testy aplikacji) można pracować „na lekko” — ale zawsze na topowych modelach.
Na co uważać: Przy computer use klasy produkcyjnej oraz na słabszych modelach zachowaj pełne zabezpieczenia — na ekranie może pojawić się wroga treść przygotowana specjalnie pod agenta.
9.Waliduj środowisko na starcie
Na czym polega: Umiejętność zaczyna od sprawdzenia, czy agent ma potrzebne narzędzia i uprawnienia na maszynie — jeszcze przed właściwą pracą, co widać w demonstracji.
Jak stosować: Dodaj krok weryfikacji na początku workflow, żeby braki wykrywać od razu, a nie w połowie wielogodzinnego zadania.
Na co uważać: Wymagania różnią się między systemami — walidacja musi uwzględniać wszystkie platformy, na których pracujesz.
10.Traktuj umiejętność jako punkt wyjścia do własnych modyfikacji
Na czym polega: Niecałe 400 linii to otwarty, edytowalny zestaw: można usuwać niepotrzebne pułapki, dodawać własne i dostosowywać skrypty np. pod swoją dystrybucję Linuksa.
Jak stosować: Skopiuj folder z repozytorium autora do dowolnego agenta kodującego albo zainstaluj wtyczkę Claude Code i zmieniaj go jak własny kod — to właśnie przewaga nad „pudełkowymi” narzędziami.
Na co uważać: Wprowadzaj zmiany stopniowo i testuj po każdej — pełna elastyczność oznacza też pełną odpowiedzialność za niezawodność.