O czym jest ten film
- Sterowanie komputerem przez model nie jest nowością, ale GPT-6 Astra — zwłaszcza w trybie high — wynosi tę funkcję na zupełnie inny poziom.
- Autor pokazuje pięć sprawdzonych schematów: wyszukiwanie lotów, testowanie MCP, testowanie własnej aplikacji, automatyzację montażu wideo i konfigurację telefonu.
- Zamiast jednorazowo znaleźć tani lot, Astra potrafi zbudować wielorazowe narzędzie wiersza poleceń (CLI) dla serwisu bez API — a potem uruchamiać je tańszym modelem.
- W testach porównawczych CLI skróciło wyszukiwanie o około 50–70% (77→23 s oraz 50→25 s).
- Agent może zainstalować twój serwer MCP w Claude Code i przejść całą ścieżkę pierwszego użytkownika: od instalacji, przez rozmowę, po weryfikację źródeł w rozwijanych menu.
- Przy okazji takiego testu autor dostał po 20 minutach także ocenę kodu — z wskazaniem funkcji, których struktura powoduje opóźnienia.
- „Incepcja sterowania komputerem”: Codex testuje funkcję computer use w twojej aplikacji, wyłapuje błędy i — przy dostępie do kodu — może poprawiać ją w pętli aż do skutku.
- Narzędzia z własnym CLI potrafią zautomatyzować ok. 80% procesu; computer use domyka resztę — od czatu w Descript, przez klatkowe przeglądanie materiału, po eksport, Dysk Google i wiadomość na WhatsApp.
- Przez iPhone Mirroring agent steruje aplikacjami na telefonie: w pięć minut skonfigurował nowe konto na Instagramie i zwrócił pełną listę zmian.
- Klucz do sukcesu: jasny cel, wyraźne wskazówki w prompcie oraz twarde ograniczenia (zakaz wysyłania wiadomości, zakaz działań destrukcyjnych).
Redakcyjne tłumaczenie
Wprowadzenie: pięć sposobów na computer use w Astrze
Największym skokiem jakościowym w Astrze — wersji GPT-6 — jest to, jak dobrze model potrafi obsługiwać twój komputer. Korzystam z tego na wszystkie sposoby: testuję nim zbudowane przeze mnie aplikacje desktopowe, przepuszczam przez nie pracę montażową, a nawet steruję aplikacjami na telefonie, siedząc przy komputerze. Opanowanie tej jednej funkcji otwiera mnóstwo procesów — zwłaszcza takich, do których nie ma integracji ani interfejsów API. W tym materiale przeprowadzę cię przez pięć schematów, z których sam korzystam, tak żebyś na koniec mógł przenieść je do własnej, codziennej pracy.
(Informacja dodatkowa: „computer use”, czyli sterowanie komputerem, to funkcja pozwalająca modelowi klikać, wpisywać tekst i poruszać się po aplikacjach tak, jak zrobiłby to człowiek przy myszce i klawiaturze.)
Sama funkcja nie jest nowa — istnieje od roku i wielokrotnie omawiałem ją na tym kanale. GPT-6, zwłaszcza po włączeniu trybu high, wynosi ją jednak na zupełnie inny poziom. Zaczynamy od scenariusza bardzo znajomego.
1.Z jednorazowego wyszukiwania lotów — wielorazowe narzędzie
Rezerwacja lotu? To umiemy robić od ponad roku, nawet podstawową wersją computer use. Ale z mocą Astry można pójść o krok dalej: nie wyszukać taniego lotu raz, tylko zbudować własny, powtarzalny proces — na własny użytek interfejs wiersza poleceń (CLI) dla platformy, która nie ma API ani żadnej innej drogi programistycznej do wyszukiwania okazji.
Ta tematyka jest mi zresztą osobiście bliska. W liceum prowadziłem drobny biznes: udostępniałem paczkę skryptów w Pythonie, które łapały błyskawiczne promocje lotnicze. Kiedyś wymagało to sporych umiejętności; dziś wystarczy jedno proste polecenie.
Zadanie łączymy z wewnętrzną przeglądarką Codexa i wysyłamy taki prompt:
Zbuduj wielorazowe narzędzie wiersza poleceń do wyszukiwania lotów Montreal–Sydney dla podanych dat, liczby pasażerów i waluty. Chcę je reużywać — m.in. do zaplanowanego zadania, które będzie polować na gwałtowne spadki cen biletów biznes do moich ulubionych kierunków.
Żeby mieć pewność, że model sięgnie po własną, wewnętrzną przeglądarkę, wprost o tym piszę w prompcie. Bez tego co jakiś czas korzysta z Chrome — czyli z twojej istniejącej przeglądarki — zamiast ze swojej.
Po wysłaniu polecenia widać, jak bardzo przyspieszyły sprawy, zwłaszcza w trybie fast: to, co rok temu ciągnęło się w nieskończoność, dzieje się niemal natychmiast. Model znajduje najlepszą ofertę, a potem odtwarza drogę, którą do niej dotarł — po to, żeby następnym razem dało się to wykonać bardziej programistycznie. Po zakończeniu wyszukiwania zagląda do własnej dokumentacji i buduje proste, „surowe” CLI, z którego skorzysta dowolny agent, z dowolnym modelem. I to jest największa zaleta: ciężką robotę raz wykonuje Astra, a potem cały proces śmiało zlecisz modelowi niższej półki.
Po kilku minutach dostajemy pierwszą wersję narzędzia, ale jest ona zbyt mocno dopasowana do tej jednej konkretnej trasy. Dopytuję więc: czy narzędzie działa z dowolną kombinacją wejść i czy jest na tyle sprytne, by sprawdzać loty składane? Dla jasności: czasem taniej wychodzi polecieć do jednego miasta, potem do kolejnego i tak docierać do celu odcinkami, zamiast kupować jeden bilet. Chcę też, żeby model sięgnął do wiedzy uśpionej w danych treningowych — jestem przekonany, że przetworzył masę blogów i zrzutów stron o wykorzystaniu punktów z rozmaitych programów lojalnościowych oraz o tym, przez które lotniska lata się najtaniej.
Model zaczyna więc przebierać kombinacje miast i sprawdzać, czy cokolwiek to zmienia w cenie. Po kolejnych poprawkach powstaje wersja znacznie solidniejsza: elastyczna, z możliwością wyboru różnych dat wylotu i powrotu oraz różnych sposobów ułożenia podróży.
Miałoby to jednak niewielką wartość, gdyby użycie CLI nie było szybsze niż każdorazowe od-nowa sterowanie komputerem. Dlatego test: dwa losowe zapytania o loty, w dwóch zupełnie nowych sesjach — jedno wykonane przez CLI, drugie zwykłym computer use. Całość trwała blisko siedem minut, a wyniki wyglądają tak: w pierwszym teście (Toronto–Lizbona) czas spadł z 77 sekund przy zwykłej przeglądarce do 23 sekund z CLI — niemal 70 procent oszczędności. W drugim (Toronto–Seul) z 50 do 25 sekund, czyli dokładnie o połowę.
Z tym przykładem ledwie drapiemy powierzchnię. W codziennej pracy pewnie korzystasz z wielu programów, które nie mają backendu, API ani MCP. (Informacja dodatkowa: MCP, Model Context Protocol, to otwarty standard podłączania zewnętrznych narzędzi i danych do modeli językowych.) Podejście, w którym computer use buduje ci interfejs wiersza poleceń, a korzysta z niego potem dowolny agent — lokalny model albo tańszy wariant Codexa — wyznacza nową najkrótszą drogę do automatyzacji.
2.Testowanie własnego MCP oczami pierwszego użytkownika
Drugi sposób wykorzystania to prawdopodobnie coś, czego jeszcze nie próbowałeś. Jeśli choć raz budowałeś własny MCP — korzystasz z niego sam, w małym zespole albo w całej firmie — wiesz, że najtrudniejsze do zasymulowania są testy. A konkretnie: co widzi osoba, która pobiera twój serwer MCP, podpina go do swojego Claude lub Codexa, uruchamia i używa po raz pierwszy? Zaraz pokażę, jak Codex instaluje mój serwer w Claude Code, otwiera to narzędzie i testuje je: ile trwa, jak płynnie działa — krótko mówiąc, przechodzi i opisuje całą ścieżkę użytkownika.
Przykład: jeden z MCP, które niedawno złożyłem, to warstwa pośrednicząca między moją społecznością a jej postami i moimi komentarzami. Każdy może go podpiąć do Claude albo Codexa i płynnie pytać o wiedzę związaną z treściami społeczności albo o rzeczy, które padały we wcześniejszych rozmowach.
Załóżmy, że twoje narzędzie jest już gotowe do testów. Wysyłasz polecenie w rodzaju:
Użyj computer use, otwórz Claude Desktop (jest już zainstalowany na twoim komputerze, więc masz do niego dostęp) i przetestuj istniejący MCP „EA Community Brain”. Poproś go o znalezienie lekcji kursowej o budowaniu lub testowaniu MCP, a następnie podaj tytuł, link do źródła i trzy przydatne wnioski. Pokaż rzeczywiste wywołanie narzędzia i zweryfikuj jeden z wniosków u źródła.
Dodaję jeszcze jeden wers: „przeprowadź kilka wymian zdań, żeby upewnić się, że ścieżka użytkownika jest maksymalnie płynna”. I jeden drobiazg techniczny: proszę model o użycie karty Claude Code. To wystarcza, żeby aplikacja się otworzyła, model sprawdził, czy siedzi na właściwej karcie (widać, jak upewnia się, że to jeszcze nie karta Claude Code — klikamy „Zawsze zezwalaj”), zweryfikował, czy serwer MCP faktycznie jest podłączony, i rozpoczął rozmowę.
Najciekawsze jest to, że nie tylko śledzi konwersację — rozklikuje też rozwijane menu, żeby zobaczyć, co dzieje się pod spodem. Widać wszystkie pobierane lekcje, dokładne źródła i wszystko pomiędzy. Następnie model czyta odpowiedź i wysyła pytanie pogłębiające.
I ten schemat da się przenieść na wiele scenariuszy. Nie tylko Claude Code: jeśli dla jakiegoś narzędzia nie ma wtyczki — powiedzmy, dla desktopowego Gemini — po prostu otwierasz jego aplikację na komputerze i pozwalasz Codexowi nią sterować. W efekcie dwa narzędzia prowadzą ze sobą rozmowę, choć nie ma żadnego API ani wtyczki.
Po dwudziestu minutach takiego testu model wrócił z wnioskami — i nie tylko o samym MCP. W zapisie widać, że monitorował też kod źródłowy i powiedział wprost: struktura tych dwóch funkcji jest nieefektywna i wprowadza opóźnienia. No i znów: to nie domena wyłącznie MCP. Zbudowałeś zestaw umiejętności (tzw. skills) i chcesz mieć pewność, że to, co działa w Codexie, działa równie dobrze w Claude? Masz kolejny sposób na weryfikację.
3.„Incepcja”: computer use testujący computer use
Trzeci przypadek to mój faworyt — i najpewniej najbardziej uniwersalny. Niezależnie od tego, czy testujesz aplikację desktopową, czy mobilną (np. przez TestFlight uruchomioną na komputerze), możesz poprosić computer use o przejęcie aplikacji i przepuszczenie jej przez próbę ogniową — dokładnie tak, jak przed chwilą robiłem to z Claude. Warunek: daj modelowi wskazówki. Wtedy nie tylko znajdzie błędy — jeśli ma dostęp do kodu, będzie poprawiał aplikację i testował ją dalej, aż osiągnie cel.
Spójrzmy na aplikację, którą złożyłem: moją rekonstrukcję GrokBota. Mam pod nią podpiętą serię agentów, dostęp do rzeczy takich jak moja subskrypcja narzędzi programistycznych czy OpenRouter, a nawet możliwość łatwego dodawania kolejnych agentów, zlecenia im wspólnej pracy i przydzielenia im własnych komputerów. Ale ze wszystkich zbudowanych przeze mnie funkcji computer use wypada najsłabiej — bo najtrudniej nauczyć zupełnie surowego agenta sterowania komputerem. I tak rodzi się pomysł na swego rodzaju „incepcję”: użyjemy computer use Codexa do audytu computer use w tej aplikacji i będziemy go poprawiać, aż będzie bez zarzutu.
Otwórz Grokky, mojego klona GrokBota, i przetestuj w aplikacji jej funkcję computer use. Patrz, jak Grokky przegląda internet, porównaj jeden wymóg ze stanem strony, a potem otwórz rozmowę ponownie i sprawdź, czy została zachowana. Wyślij zapytanie o loty w Google Flights, podobne do wcześniejszego — sformułowane tak, by wprost kazało Grokky użyć zdolności komputerowych.
Żebyśmy nie czekali razem godzinami, wysyłamy jedną wiadomość, obserwujemy i wracamy do tematu. W praktyce kazałbym takiemu procesowi pracować godzinami — na przykład z poleceniem w stylu /goal — i obudzić się z listą błędów znalezionych i naprawionych w nocy.
Po wysłaniu polecenia aplikacja startuje i model wpisuje zapytanie. Oto ono: „użyj swoich zdolności computer use”. Powinien automatycznie wyrazić zgodę, a potem obserwować przebieg. Jest przy tym na tyle spostrzegawczy, że sam odnajduje w aplikacji panel podglądu, w którym widać, co robi drugi agent. Efekt: mój surowy agent próbuje ogarnąć Google Flights, a my przyglądamy się computer use obserwującemu computer use.
Ponieważ wszystkie akcje w wywołaniach narzędzi są u mnie w pełni przejrzyste, model naprawdę zaczyna rozumieć, co trwa zbyt długo i co jest przerobione ponad miarę albo zbyt skromnie. Computer use w mojej aplikacji ostatecznie nie zdał testu, z dwóch powodów: używam starszego modelu o mniejszym oknie kontekstowym i nie zbudowałem jeszcze mechanizmu kompaktowania — automatycznego skracania historii rozmowy, gdy kontekst się zapełnia. Codex błyskawicznie wychwycił porażkę. A gdyby ustawić mu cel „doprowadź to computer use do doskonałości”, widziałby każdy błąd, poprawiał kod, wdrażał ponownie, startował aplikację od zera — i kręcił się w tej pętli, aż będzie dobrze.
4.Od renderu 4K po wiadomość na WhatsApp
Przypadek czwarty: automatyzacja pracy nad montażem. Nawet jeśli nie tworzysz treści, kilka trików z tego schematu wykorzystasz gdzie indziej.
Po nagraniu filmu renderuję go w 4K. W zależności od długości i od tego, co jeszcze w tym czasie robi mój komputer, trwa to od 40 minut do czterech godzin. Nagrywam późno — jak ten materiał — i nie zamierzam czekać do trzeciej, czwartej nad ranem na koniec renderu, żeby wprowadzić drobne poprawki i odesłać plik do ekipy montażowej. Dzięki computer use zbudowałem proces, w którym moje zadanie sprowadza się do kliknięcia „renderuj” i wyeksportowania wideo. Resztą zajmuje się Codex: co pół godziny odpytuje system i sprawdza, na jakim etapie jest render i ile mu zostało. Gdy plik jest gotowy, otwiera Descript, wgrywa tam wideo, czeka, aż będzie dostępne, po czym wysyła prompt bezpośrednio do czatu — a tego, nawiasem mówiąc, nie da się zrobić programistycznie, przynajmniej nie łatwo. Potem czeka na odpowiedź, przewija materiał klatka po klatce, żeby wyłapać przypadkowe sceny, w których kaszlę albo kompletnie nie daję rady (zdarza się częściej, niż myślicie), eksportuje plik, sprawdza eksport, wysyła go do folderu na Dysku Google, a na końcu bierze link i dzieli się nim z zespołem.
Takie narzędzia jak Descript mają własne interfejsy wiersza poleceń, ale do tej pory zabierały mnie najwyżej do 80 procent drogi. Computer use pozwala procesy, które były w 80 procentach wykonalne, domknąć do stu — łącznie z fragmentami, które dotąd wymagały człowieka.
Nie mogę renderować wideo w trakcie nagrywania innego, więc przebieg pokazuję na symulacji:
Użyj umiejętności „render → Descript → dostawa” w trybie demo. Wejdź do folderu z moimi filmami, wybierz wideo o obecnym stanie rynku AI i wykonaj na nim cały proces, krok po kroku.
Po wysłaniu polecenia otwiera się aplikacja Descript i wgrywa film, a gdy transfer się kończy, rusza obróbka. Model wysyła w moim imieniu obszerny prompt, czeka na odpowiedź, przygląda się poprawkom pojawiającym się w transkrypcji po lewej stronie ekranu, po czym fizycznie klika przez materiał klatka po klatce — sprawdza, czy nie wyglądam zbyt podejrzanie, i szuka fragmentów do wycięcia, na przykład ciszy, gdzie przez moment nie ma dźwięku. Robię to wszystko po to, żeby ekipa montażowa dostała surowy materiał już wstępnie uporządkowany i musiała dołożyć tylko ostatni szlif. Po audycie transkrypcji — i upewnieniu się, że moje niezliczone zająknięcia zniknęły — klika eksport w 4K, czeka, a gdy na ekranie zobaczy potwierdzenie zakończenia, tworzy link na Dysku Google przez integrację i doprowadza sprawę do końca: otwiera WhatsApp na komputerze i wysyła zespołowi wiadomość z linkiem.
5.Telefon sterowany z komputera: konfiguracja Instagrama
Ostatni przypadek nie jest typowym zastosowaniem computer use — a działa zaskakująco skutecznie. Właśnie założyłem nowe konto na Instagramie, na którym będę publikował treści o AI (jeśli chcesz, śledź profil pokazany na ekranie — wkrótce ruszam z regularną aktywnością). Jako nowicjusz na platformie mam przed sobą cały szereg ustawień, które powinienem włączyć lub wyłączyć, żeby zwiększyć swoje szanse. Zamiast siedzieć z telefonem i przeklikiwać wszystko samemu, wolałem kazać Codexowi zrobić to samo przez computer use.
Może to wyglądać tak:
Użyj otwartej przeze mnie aplikacji iPhone Mirroring, żeby skonfigurować Instagrama na moim telefonie. Właśnie założyłem nowe konto i chcę mieć pewność, że przy publikowaniu kolejnych filmów wszystkie ustawienia są zoptymalizowane pod nowego twórcę — tak, żeby moje materiały osiągały jak najlepsze wyniki. Wiem z filmów o Instagramie, że istnieją ukryte funkcje i przełączniki, które warto zmienić. Przejmij kontrolę nad moim kontem. Nie wysyłaj żadnych wiadomości prywatnych, nie rób nic destrukcyjnego — po prostu zoptymalizuj wszystkie łatwe ustawienia, do których się dobrzesz.
(Informacja dodatkowa: iPhone Mirroring to funkcja systemu macOS, która wyświetla ekran iPhone’a na komputerze i pozwala nim sterować z poziomu Maca.)
Po wysłaniu polecenia model powinien otworzyć iPhone Mirroring na moim Macu, przejąć aplikację — a co było dla mnie dużym zaskoczeniem — przejąć także telefon i przeklikać Instagrama. I faktycznie: łączy się z telefonem, ma teraz kliknąć w pasek wyszukiwania i wpisać nazwę aplikacji, ale zauważa ją bez szukania. Już jest w ustawieniach i aktywności, sprawdza, czy to właściwe, świeżo założone konto, cofa się i klika dalej, doprowadzając wszystko do porządku. Trafia m.in. na zakładkę jakości multimediów, gdzie włącza najwyższą jakość — po prostu przechodzi po wszystkim, co według jego danych treningowych jest kluczowe. A kiedy tak klika przez moje ustawienia, pomyśl, że dokładnie tak samo możesz ogarnąć każdą aplikację, która nie ma wersji na komputer: nawigować nią, sprzątać ustawienia, sprawdzać funkcje i ścieżki użytkownika. Teoretycznie możesz też uruchomić grupę podagentów, które zrobią research, jak zoptymalizować twój profil na Facebooku albo X, a potem wdrożą wszystkie znalezione zmiany. Po pięciu minutach model wraca z pełną listą kontrolną: co zrobił, co włączył, co wyłączył. I możemy działać.
Zakończenie: prompty i dalsze kroki
To w zasadzie wszystko. Mam nadzieję, że widzicie teraz pełny obraz tego, jak potężne bywa computer use w Astrze i jak dzięki niemu kilkukrotnie podnieść wydajność dotychczasowych procesów. Wszystkie prompty z tego materiału — w tym CLI do Google Flights, przydatne do polowania na okazje i planowania podróży — udostępniam całkowicie za darmo w drugim linku pod filmem. Jeśli chcesz wejść głębiej, opanować Astrę i dostać bardziej ekskluzywne materiały: dla mojej społeczności wydałem już osobny film o tym, jak dokładnie promptuję i pracuję z Astrą w różnych zastosowaniach. A jeśli chcesz opanować Claude, Codexa i całą resztę — i znaleźć sposób, żeby te umiejętności zaczęły zarabiać — zajrzyj do pierwszego linku, może spotkam się z tobą w środku. Wam wszystkim dziękuję za obejrzenie: jeśli materiał był pomocny, będę wdzięczny za łapkę w górę i ewentualny komentarz. Do zobaczenia następnym razem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Z computer use buduj trwałe narzędzie, nie jednorazowy wynik
Na czym polega: Astra może nie tylko raz wykonać zadanie (np. znaleźć tani lot), ale też zbudować wielorazowy interfejs wiersza poleceń dla serwisu, który w ogóle nie wystawia API.
Jak stosować: w prompcie opisz zadanie plus wymóg reużycia (różne trasy, daty, waluty, liczba osób). Gotowe narzędzie zlecaj potem tańszemu modelowi lub agentowi lokalnemu; możesz je podpiąć do zaplanowanego zadania pilnującego spadków cen.
Na co uważać: pierwsza wersja często wychodzi zbyt wąska — dopasowana do jednego konkretnego przypadku. Zawsze dopytaj, czy działa dla dowolnej kombinacji i czy testuje warianty, o których sam nie pomyślałeś (np. loty składane).
2.Wprost wskaż, której przeglądarki ma użyć model
Na czym polega: bez wyraźnej instrukcji agent sięga czasem po twoje Chrome zamiast po własną, wewnętrzną przeglądarkę — co zmienia warunki testu i może mieszać w twoich sesjach.
Jak stosować: dopisz w prompcie zdanie „użyj wewnętrznej przeglądarki” i sprawdź w podglądzie działań, czym model faktycznie operuje.
Na co uważać: zachowanie bywa niedeterministyczne — to, co zadziałało raz, może się zmienić po aktualizacji narzędzia.
3.Testuj nowe narzędzia na świeżych sesjach i mierz czas
Na czym polega: przewagę CLI nad zwykłym computer use widać dopiero w uczciwym porównaniu. Autor porównał oba warianty na losowych zapytaniach w nowych sesjach: 77→23 s i 50→25 s.
Jak stosować: to samo zadanie uruchom dwa razy — raz z narzędziem, raz bez — i zmierz czas oraz stabilność wyników, zanim wdrożysz proces na stałe.
Na co uważać: pojedynczy pomiar to za mało; wyniki zależą od trybu pracy modelu (fast/high) i obciążenia komputera, więc powtórz test kilka razy.
4.Niech agent przetestuje twój MCP jak pierwszy użytkownik
Na czym polega: najtrudniejsze przy własnym MCP jest zasymulowanie pierwszego uruchomienia u kogoś. Agent potrafi zainstalować twój serwer w Claude Code i przejść całą tę ścieżkę — z weryfikacją połączenia i źródeł w rozwijanych menu.
Jak stosować: prompt w stylu: otwórz Claude Desktop, upewnij się co do właściwej karty, sprawdź, czy connector działa, zadaj pytanie, podaj źródła, zweryfikuj jeden wniosek i doprowadź kilka wymian zdań.
Na co uważać: przeglądając okna uprawnień, klikaj „zawsze zezwalaj” tylko wtedy, gdy rozumiesz, na co pozwalasz; dłuższe testy z kilkoma rundami rozmowy znacząco wydłużają cały proces.
5.Rozmowa między aplikacjami bez API i wtyczek
Na czym polega: gdy dla narzędzia nie ma wtyczki (np. dla desktopowego Gemini), możesz otworzyć jego aplikację i kazać agentowi nią sterować — dwa programy prowadzą wymianę zdań bez jakiejkolwiek integracji.
Jak stosować: opisz cel rozmowy, wskaż aplikację, dodaj ograniczenia i obserwuj przebieg w podglądzie działań.
Na co uważać: takie rozwiązanie jest kruche — zmiana interfejsu którejkolwiek aplikacji je łamie. Traktuj je jako pomost doraźny, a nie fundament architektury.
6.Przy teście ścieżki użytkownika dostajesz gratis audyt kodu
Na czym polega: po dwudziestu minutach testowania MCP autor dostał nie tylko ocenę działania, ale i wskazanie konkretnych funkcji, których struktura powoduje opóźnienia — bo agent monitorował też źródła.
Jak stosować: daj agentowi dostęp do kodu podczas testu i pytaj wprost o wąskie gardła oraz fragmenty przerobione ponad miarę albo zbyt skromnie.
Na co uważać: agent z dostępem do repozytorium widzi wszystko — ograniczaj zakres i jasno określaj, co może zmieniać, a co tylko komentować.
7.Pętla test–poprawka–wdrożenie dla własnej aplikacji
Na czym polega: „computer use-ception” — Codex steruje komputerem po to, by testować funkcję computer use w twojej aplikacji, wyłapywać błędy i (przy dostępie do kodu) poprawiać ją w pętli aż do osiągnięcia celu.
Jak stosować: podaj cel, kryteria ukończenia i ograniczenia; uruchamiaj proces na godziny (np. z poleceniem /goal) i zbieraj wyniki jako listę błędów do przeglądu rano.
Na co uważać: porażki często wynikają nie z twojego kodu, lecz z ograniczeń samego modelu (małe okno kontekstowe, brak kompakcji rozmowy) — najpierw ustal, gdzie leży prawdziwa przyczyna.
8.Przejrzystość wywołań narzędzi skraca diagnozę
Na czym polega: bo autor eksponuje wszystkie akcje agenta w wywołaniach narzędzi, testujący model od razu widzi, co trwa za długo i co jest przeinżynierowane.
Jak stosować: loguj i pokazuj każdą akcję agenta w aplikacji — audytor (ludzki czy sztuczny) potrzebuje tego wglądu, żeby wskazać realne problemy.
Na co uważać: nadmiar informacji też przeszkadza — szukaj balansu między pełną widocznością a szumem, który utrudnia odczyt.
9.Domykaj „ostatnie 20 procent” procesu computer use
Na czym polega: własne CLI narzędzi typu Descript automatyzowało ok. 80% pracy; resztę — czat, przeglądanie materiału klatka po klatce, eksport, wysyłkę — domyka sterowanie interfejsem.
Jak stosować: zmapuj proces, zautomatyzuj co się da przez API i CLI, a fragmenty wymagające klikania zleć computer use; długie oczekiwania (np. render) rozwiąż odpytywaniem co 30 minut.
Na co uważać: decyzje wymagające gustu lub odpowiedzialności (finalny cięcie montażowe, publikacja) zostaw człowiekowi; sprawdź też, czy agent nie gubi zadania przy wielogodzinnym czekaniu.
10.Sterowanie telefonem z komputera — z twardymi ograniczeniami
Na czym polega: przez iPhone Mirroring agent otworzył na Macu lustrzany odbój telefonu, przejął go i w pięć minut przeklikał ustawienia nowego konta na Instagramie, zwracając pełną listę zmian.
Jak stosować: podaj cel, kontekst (nowe konto, nowy twórca) i jednoznaczne zakazy: żadnych wiadomości prywatnych, nic destrukcyjnego — potem poproś o listę kontrolną wykonanych zmian.
Na co uważać: agent ma w ten sposób pełny dostęp do twojego telefonu — bez precyzyjnych ograniczeń ryzyko jest realne. „Optymalne” ustawienia pochodzą z danych treningowych, więc zweryfikuj je sam, zanim zaczniesz publikować.