Codex's Browser Agent Automates Literally Anything

2026-08-13 Nate Herk | AI Automation AI zagraniczne tutorial waga 4/5 19 min czytania

Praktyczny przegląd browser use i computer use w aplikacji Codex: automatyczne QA interfejsu, logowanie przez menedżer haseł, zapisywanie przepływów jako umiejętności. Dla osób automatyzujących pracę bez API.

Robocza publikacja redakcyjna na podstawie publicznego transkryptu YouTube. Źródło: YouTube.

O czym jest ten film

  1. Autor przedstawia funkcję sterowania przeglądarką (browser use) w aplikacji desktopowej Codex jako najlepszą, jaką dotąd testował.
  2. Pokazuje wbudowaną przeglądarkę w oknie Codeksa i tryb adnotacji, w którym można wskazać konkretny element UI i opisać, co poprawić.
  3. Demonstruje automatyczne testowanie QA prostego formularza: agent klika, wpisuje dane, próbuje „zepsuć” aplikację i raportuje znalezione błędy.
  4. Wyjaśnia różnicę między trybem headless (praca w tle) a headed (widoczne działanie agenta).
  5. Drugi przykład: pobieranie wyciągów bankowych z platformy Relay, która nie ma API — cały przepływ zostaje zapisany jako umiejętność (skill).
  6. Pokazuje wbudowany menedżer haseł Codeksa zasilany plikiem CSV, dzięki czemu hasła nie trafiają do historii czatu.
  7. Trzeci przykład: zamiana filmu z YouTube w artykuł na X — z formatowaniem, miniaturą i zrzutami ekranu wklejanymi w treść.
  8. Osobno omawia computer use — sterowanie aplikacjami desktopowymi i ustawieniami komputera, po instalacji odpowiedniej wtyczki.
  9. Formułuje hierarchię decyzyjną automatyzacji: najpierw API, potem deterministyczny skrypt/makro, a dopiero na końcu agent z wizją.
  10. Uczciwie ocenia zysk czasowy — pojedyncza automatyzacja oszczędza może 5–10 minut, prawdziwa wartość to brak przełączania kontekstu i łączenie umiejętności w łańcuchy.

Redakcyjne tłumaczenie

Punkt wyjścia

Sterowanie przeglądarką w Codeksie jest chyba najlepsze, jakiego dotąd używałem. Agent potrafi zrobić dosłownie wszystko w przeglądarce albo bezpośrednio na twoim komputerze. A jeśli gdzieś trzeba być zalogowanym, wystarczy zalogować się raz — Codex zapamięta sesję. Możliwości są więc praktycznie nieograniczone; naprawdę można teraz zautomatyzować niemal wszystko. Pokażę wam, jak to skonfigurować, jakie to proste i kilka sensownych zastosowań.

Pracuję w aplikacji desktopowej Codex, bo szczerze mówiąc to mój podstawowy sposób korzystania z tego narzędzia. Jest naprawdę dopracowana. Przeglądarka wyskakuje po prawej stronie okna — zaraz to pokażę.

Na szczęście żyjemy w świecie, w którym większość potrzebnych nam narzędzi ma API. Dużo łatwiej jest po prostu podpiąć Codeksa przez API. Albo — jeśli wejdziemy w zakładkę wtyczek — mamy tam setki gotowych integracji. Ale co jakiś czas trafia się coś bez API i wtedy z pomocą przychodzi sterowanie przeglądarką.

Wbudowana przeglądarka i adnotacje

Zanim pokażę taką automatyzację, spójrzmy na przykład, w którym budujecie stronę albo aplikację i potrzebujecie agenta z przeglądarką, żeby to przeklikał i przetestował. Jeśli oglądaliście mój niedawny film o budowaniu aplikacji SaaS z AI w jeden dzień, to właśnie stamtąd pochodzi ten materiał: uruchomiłem agenta przeglądarkowego, który przetestował aplikację od podszewki. Wykonał 85 ukierunkowanych kontroli z prawdziwymi przepływami w przeglądarce — czyli klikał, wpisywał, naciskał przyciski i próbował aplikację zepsuć. Znalazł mnóstwo błędów, a my mogliśmy je po prostu naprawić.

W tym przykładzie mam bardzo prostą stronę uruchomioną na localhoście. To formularz zgłoszeniowy. Jeszcze zanim zaczniemy testy, widać kilka problemów: dziwne odstępy, nachodzące na siebie elementy. Można wtedy kliknąć przycisk adnotacji, który pozwala wskazać bardzo konkretne elementy do poprawki. Klikam więc na pole numeru telefonu i opisuję: „To pole nachodzi na inne, wychodzi poza obszar, zasłania pole z nazwą firmy. Napraw to”. Gdy wysyłasz taką adnotację, ląduje ona w oknie czatu. Możesz zrobić kolejną: „Ten blok nie jest wyrównany w tej samej osi Y co elementy pierwszy i trzeci — to też popraw”. Adnotacje zbierają się z boku i wysyłamy je razem.

To trochę taki mechanizm w stylu Lovable czy Claude Design, tyle że dostępny w przeglądarce wbudowanej w Codeksa.

(Informacja dodatkowa: Lovable to popularne narzędzie do generowania aplikacji webowych z opisu tekstowego; wskazywanie elementów na podglądzie i opisywanie poprawek jest tam standardem interakcji).

Drugą fajną rzeczą jest to, że tę przeglądarkę można po prostu obsługiwać samemu. Możesz wejść na Google, wyszukać zdjęcia Wielkiego Kanionu, przechodzić po linkach — korzystać z przeglądarki, mając otwartego Codeksa. Ale oczywiście Codex może też przejąć nad nią kontrolę. Widać tutaj mój kursor, a obok — kursor Codeksa. Po tym poznajesz, że agent szykuje się do przejęcia sterowania.

Automatyczne QA interfejsu

Zmiany zostały wprowadzone, więc zabierzmy się za testowanie interfejsu. Chcę zobaczyć rzeczy, których ja jako człowiek bym nie sprawdził — sam przeklikałbym może pięć czy sześć przypadków brzegowych, a Codex zrobi to znacznie szybciej i znacznie szerzej.

Polecenie brzmi: „Masz otwarty interfejs. Chcę mieć pewność, że nie ma tu błędów i że tego nie da się zepsuć. Użyj sterowania przeglądarką i przetestuj to porządnie. Próbuj różnych rzeczy, staraj się to złamać i powiedz mi, jakie błędy znalazłeś i co trzeba naprawić”.

Przy okazji: istnieje różnica między trybem headless a headed. Headless oznacza, że przeglądarka działa w tle — możesz spokojnie pracować na pierwszym planie, nic nie widzisz, ale agent może w tle wykonać bardzo dużo. Headed to tryb, w którym widzisz, co się dzieje. Tutaj będziemy więc obserwować działanie agenta, ale gdybyś chciał, żeby coś mieliło ci się przez kilka godzin w tle, możesz o to poprosić i nie będzie ci to przeszkadzać w pracy. Jeśli kiedyś natkniesz się na tę terminologię — to właśnie znaczy.

I proszę: kursor zaczyna się poruszać. Agent spróbował kliknąć „dalej” i dostał komunikaty: imię jest wymagane, podaj poprawny adres e-mail, podaj dziesięciocyfrowy numer telefonu. Teraz wpisał jakieś dane i udało mu się przejść dalej. Będzie tak kontynuował kontrolę jakości. Walidujemy, że część pól jest obowiązkowa i że przycisk „dalej” nie przepuszcza dalej bez ich wypełnienia.

Nawiasem mówiąc, część widocznych błędów interfejsu wynika z tego, że wcześniej poprosiłem model o celowe wprowadzenie kilku usterek, żeby pokazać wam adnotacje. Zignorujcie to — teraz chodzi o samą funkcję QA w przeglądarce.

Widać, jak agent klika i nawiguje po interfejsie. Już zaraportował, że główna ścieżka klikania w większości działa, ale potwierdził dwa realne problemy z integralnością danych: niepoprawne dane kontaktowe jednak przechodzą, a zmiana kierunkowego kraju na brytyjski resetuje się do amerykańskiego, gdy wracasz do edycji. Teraz testuje wysyłanie formularza z klawiatury i zachowanie przy restarcie, co często ujawnia obejścia niewidoczne przy zwykłym klikaniu.

Pomyślcie o tym tak: cokolwiek dostaniecie, i tak będziecie chcieli to przetestować. Wolicie mieć coś w ogóle nieprzetestowanego, czy coś, co agent przetestował już sto razy? Zwłaszcza gdy każesz mu celowo próbować to złamać — na pewno znajdzie rzeczy do poprawy. Nieważne, jak dobrze przewidujesz przypadki brzegowe: kiedy wypuścisz aplikację na produkcję i wejdą użytkownicy, ludzie są dziwni i nieprzewidywalni, będą robić różne rzeczy. Taki agent potrafi symulować dziwnych ludzi i znaleźć to, o czym byś nie pomyślał.

Widać nawet, że przełączył widok na mobilny, żeby sprawdzić, czy tam też wszystko działa. I proszę — w wersji mobilnej znalazł kilka błędów responsywności. Tego akurat jeszcze nie testowałem.

Test się zakończył: mamy sporo testów zaliczonych, ale też sporo niezaliczonych. Agent znalazł wszystkie te błędy, testując interfejs, i nie zajęło mu to wcale dużo czasu. Gdybyśmy chcieli podkręcić poprzeczkę, moglibyśmy użyć polecenia /goal i powiedzieć: „Nie przerywaj, dopóki nie wypróbujesz stu różnych, unikalnych scenariuszy brzegowych w interfejsie, a potem wróć do mnie”. Ale i tak znalazł mnóstwo usterek — teraz wystarczy powiedzieć: „Świetnie, wprowadź te zmiany, napraw te błędy”.

Platforma bez API: pobieranie wyciągów bankowych

Kolejny przykład. Masz platformę, z której chcesz pobierać na przykład wyciągi, ale nie ma ona API. Możesz z nią pracować przez sterowanie przeglądarką w Codeksie, bo mechanizm ten używa wizji i AI, żeby analizować, na co patrzy i gdzie kliknąć.

Chcę pokazać, jak łatwo się takie rzeczy buduje. Powiedziałem tylko: „Chcę zbudować taką umiejętność, o to i o to mi chodzi, co by ci pomogło?”. Można nagrać krótkie wideo z Looma, można wysłać zrzuty ekranu ze strzałkami — ale wcale nie trzeba. Wystarczy dość precyzyjnie opisać słowami, co ma się wydarzyć.

Tutaj wyglądało to tak: Codex otworzył Relay, ja się zalogowałem, a on zapisał sesję. Potem powiedziałem: „W panelu Relay jesteś zalogowany. Przejdź do pulpitu, kliknij w konta, znajdź wyciągi, kliknij te dwa konta, pobierz je jako pliki CSV i wrzuć do tego folderu”. Wykonał to za pierwszym razem. Nie musiałem dawać żadnych poprawek — pobrał pliki i zapisał cały przepływ jako umiejętność.

(Informacja dodatkowa: Relay to amerykańska platforma bankowa dla firm; „umiejętność” — skill — to w Codeksie zapisany, wielokrotnego użytku scenariusz działania agenta).

To bardzo przydatne, bo teraz mogę na koniec miesiąca ustawić z tego zaplanowaną rutynę i powiedzieć: „Użyj tej umiejętności na najnowszym miesięcznym wyciągu w Relay”.

W większości przypadków Codex zapamiętuje sesje, gdy jesteś zalogowany. Są jednak ograniczenia — Relay i tak cię wyloguje, bo to platforma bankowa, dbająca o bezpieczeństwo. Widać to tutaj: poprosiłem o powtórzenie zadania i dostałem odpowiedź, że Relay jest otwarty na ekranie logowania i trzeba się zalogować ponownie.

Menedżer haseł w Codeksie

Ciekawe jest to, że możesz wejść w ustawienia i skorzystać z menedżera haseł wbudowanego w Codeksa. Przechodzi to do twojej przeglądarki i możesz zaimportować hasła, żeby Codex sam wypełniał formularze. Dzięki temu nie wklejasz haseł do historii czatu — trzymasz je bezpieczniej.

Wystarczy przygotować plik CSV o takiej strukturze: nazwa, adres URL, nazwa użytkownika, hasło i ewentualne notatki (u mnie puste). Zaimportowałem go jako plik CSV i mamy już hasło do relay.com. Mówię więc: „Spróbuj ponownie, korzystając z menedżera haseł wbudowanej przeglądarki Codeksa. Powinieneś móc się teraz zalogować. Potem uruchom umiejętność na czerwcu”.

Przeglądarka przejęła kontrolę i wpisuje mój e-mail i hasło. Gdyby teraz poprosiła o kod uwierzytelniania dwuskładnikowego z telefonu, oczywiście bym tego nie obsłużył — musiałbym zrobić to ręcznie. Choć gdybym pracował na Macu, gdzie przychodzą moje SMS-y, i użył sterowania komputerem, to technicznie dałoby się zautomatyzować całość. Ale powiedziałbym, że z takimi rzeczami trzeba być ostrożnym.

Jak widać, agent pobrał hasła z menedżera, wkleił je i powinien się teraz zalogować do Relay. Kursor przesunął się do kont, potem do wyciągów i za chwilę pobierze te dwa dokumenty. Naprawdę fajne, że sam to wszystko rozgryzł. Pamiętajcie: uruchomiłem tę umiejętność tylko raz i opisałem ją zwykłym językiem naturalnym.

Czy realistycznie tak właśnie należy postępować, zwłaszcza przy koncie bankowym? Nie. Powinieneś uruchomić tę umiejętność i usiąść obok, obserwując — co najmniej dziesięć razy, bardzo uważnie, upewniając się, że nic nie idzie nie tak, i doprowadzając scenariusz w umiejętności do maksymalnej ścisłości. Bo koniec końców to wizja i AI decydują, w co kliknąć i co zrobić.

Hierarchia decyzyjna: API, makro, agent

Tak o tym myślę: kiedy chcesz coś zautomatyzować, pierwszym odruchem powinno być sięgnięcie po API. To jest właściwa droga — najszybsza, zwykle najtańsza i najbardziej przewidywalna.

Jeśli API nie ma, następne pytanie brzmi: czy da się to zrobić deterministycznym skryptem, makrem? To wciąż byłoby sterowanie przeglądarką w sensie klikającego kursora, ale ten kursor nie potrzebuje rozumowania. Nie musi patrzeć na ekran, ustalać, gdzie kliknąć, a potem — na podstawie tego, jaki interfejs się pojawił — decydować, gdzie kliknąć dalej. Tu chodzi raczej o: „kliknij ten piksel, potem ten, potem ten, za każdym razem tak samo”. To da się zrobić znacznie taniej i bezpieczniej, programując zwykłe makro. I to wcale nie jest trudne — możesz poprosić Claude’a albo Codeksa: „Pomóż mi zrobić deterministyczny skrypt makra, który za każdym razem kliknie te piksele w tej kolejności”.

Ale jeśli nie da się tego powtórzyć identycznie za każdym razem, bo w grę wchodzi element wizji albo rozumowania — wtedy potrzebujesz agenta w przeglądarce. I na szczęście Codex sobie z tym radzi. Testowałem wiele różnych aplikacji, narzędzi wiersza poleceń i rozwiązań do sterowania przeglądarką i jak dotąd Codex jest po prostu solidny.

Jak widać, w moich pobranych plikach są wyciągi pobrane przed chwilą jako archiwum ZIP, a agent przeniósł je do mojego projektu. Wchodzę, przewijam do wyciągów, do folderu z czerwcem — i proszę, pliki są dokładnie tam, gdzie powinny.

Zapamiętane sesje i publikacja artykułu na X

To był przykład, w którym musieliśmy gdzieś zapisać hasło. Ale robiłem to samo z systemem uczelnianym, z platformą X, a nawet z Instagramem — tam nie trzeba się ciągle logować ponownie, bo sesja jest zapamiętywana.

Kolejny przykład: wchodzę na YouTube i kopiuję adres filmu, który wrzuciłem dziś rano. Wracam do Codeksa, wklejam URL i mówię: „Zamień ten film z YouTube w artykuł na X, a potem użyj przeglądarki, żeby go sformatować i umieścić jako szkic artykułu na X. Potem ja to sprawdzę”.

Część z was pewnie myśli: dlaczego nie użyć po prostu API platformy X? Można, ale bywa dziwnie z formatowaniem. Bywa też dziwnie z dodawaniem mediów czy miniatur — przynajmniej w moich wcześniejszych testach. No i to kosztuje, bo za korzystanie z API X płaci się od użycia. A skoro to jest w ramach mojej subskrypcji Codeksa, mogę po prostu uruchomić tę umiejętność i wszystko zostanie sformatowane i załatwione. Mam nawet tę umiejętność dopracowaną tak, że potrafi otworzyć moje filmy z YouTube, zrobić zrzuty konkretnych momentów i wstawić je w odpowiednich miejscach artykułu.

To dość złożony proces, bo zanim artykuł trafi na X, trzeba wykonać kilka kroków. W międzyczasie otwórzmy nowy czat i sprawdźmy, czy sesja X jest zapamiętana: „Otwórz przeglądarkę — chcę ją widzieć tu, w aplikacji — wejdź na X, poprzewijaj trochę i pokaż mi, czy pojawiło się coś nowego w obszarze AI. Po prostu przewiń mój feed”. Skoro to zupełnie nowa sesja, sprawdzimy, czy X jest już zalogowany i czy agent może wchodzić w interakcje.

Świetnie. X się otworzył, jestem najwyraźniej już zalogowany, mój feed jest widoczny, a agent zaczyna przewijać stronę. Zacznijcie już teraz myśleć: jak można by z tego zrobić umiejętności i zaplanować je jako zadania cykliczne? Może co rano miałoby przewijać Instagram, albo twój własny profil, albo oznaczać rzeczy jako przeczytane i nieprzeczytane — spokojnie da się to zrobić, bo zadania zaplanowane ustawiasz w tym samym miejscu i korzystasz z gotowych umiejętności przeglądarkowych.

Agent zauważył dwie rzeczy: Grok Bot i Groka 4.6. To ciekawy przypadek, bo API tu istnieje, ale sterowanie przeglądarką wychodzi taniej — i dlatego akurat tutaj zdecydowaliśmy się to przetestować.

Computer use — sterowanie komputerem

A co ze sterowaniem komputerem, o którym pewnie też słyszeliście? To w zasadzie to samo. Nadal wizja, nadal AI, ale różnica polega na tym, że przeglądarka dotyczy rzeczy z internetu albo tego, co wpisujesz w Chrome, a sterowanie komputerem — rzeczy na twoim komputerze. Zmiana ustawień systemowych, otwieranie aplikacji desktopowych.

Trzeba tylko wejść we wtyczki i faktycznie zainstalować sterowanie komputerem — wpisujesz „computer use”, klikasz „instaluj”, dosłownie dwie sekundy.

Potem mówię: „Codex, użyj sterowania komputerem, żeby otworzyć aplikację desktopową Glydo. Wejdź w ustawienia i włącz możliwość korzystania z urządzeń Bluetooth. Ustaw mi to”.

To działa trochę inaczej, bo nie otwiera się wbudowana przeglądarka — widzisz, jak przejmowany jest twój ekran. Agent uprzedził: „Zatrzymam się, jeśli system poprosi o hasło administratora albo pojawi się wrażliwe pod względem bezpieczeństwa uprawnienie, którego nie mogę bezpiecznie zinterpretować”. Nie powinno do tego dojść, ale dobrze, że taka bariera jest wbudowana.

I ciekawostka: napisał, że dostęp do Bluetootha to uprawnienie prywatności, więc sterowanie komputerem nie pozwoli mu tego zrobić. Ale zapowiedział, że otworzy Glydo — i faktycznie sam otworzył aplikację, ja tego nie zrobiłem. Na nagraniu pewnie tego nie widać, ale mój ekran ma wokół krawędzi wyraźną niebieską poświatę. Zawsze więc będziesz wiedzieć, że Codex korzysta z twojego komputera.

I proszę: mimo wszystko włączył opcję obsługi urządzeń Bluetooth. Myślę, że początkowo się pogubił — uznał, że grzebię w ustawieniach systemowych, a nie w ustawieniach wewnątrz aplikacji, i dlatego potraktował to jako kwestię bezpieczeństwa. Po drodze jednak to rozgryzł.

Sterowanie komputerem jest o tyle ciekawe, że możesz połączyć się ze swoim Codeksem z telefonu. Mogę zarządzać wszystkimi tymi sesjami z komórki. Mógłbym z telefonu powiedzieć: „Użyj sterowania komputerem, zmień mi te ustawienia albo zrób coś w aplikacji desktopowej na moim komputerze”, przed którym akurat nie siedzę. Sterujesz więc komputerem z telefonu.

Finał: artykuł ląduje na X

Wracamy do sesji, w której powstaje artykuł na X. Widać, że agent tworzy miniatury do artykułu. Miejmy nadzieję, że jesteśmy blisko momentu, w którym otworzy X i zacznie tam wklejać treść.

I proszę — właśnie otworzył X. Wchodzi w szkice na moim zalogowanym koncie, sformatuje nowy artykuł, a potem to obejrzymy. Klika przycisk plusa. Chyba nawet lekko przeskalował stronę, robił się wybredny. Wpada tytuł. A potem wkleił całą treść artykułu. Teraz wgrywa miniaturę, która moim zdaniem nie wygląda najlepiej — ta część umiejętności nie została w ogóle dopracowana. Ale i tak fajne, że potrafił ją wygenerować i wstawić. Mnie zostaje tylko sprawdzić, czy wszystko wygląda w porządku, i opublikować.

Gdzie jest realna wartość

Wiem, co pewnie myśli wielu z was o tym całym sterowaniu przeglądarką: „Nate, o co chodzi? Gdzie tu wartość?”. Rozumiem to i dlatego chciałem wam pokazać właśnie ten fragment: API obsłuży jakieś 95% waszych potrzeb automatyzacyjnych, a spora część pozostałych zastosowań przeglądarkowych to po prostu skrypt. Ale kiedy naprawdę tego potrzebujesz, dobrze mieć to w zanadrzu.

Możecie też pomyśleć: „No dobrze, ale ile czasu to realnie oszczędza?”. Realistycznie — może 5–10 minut. Fajne jest jednak to, że mam teraz cały potok takich umiejętności przeglądarkowych: kiedy czegoś potrzebuję, otwieram Codeksa, odpalam umiejętność i wracam do zadania, przy którym byłem. To po prostu pomaga zrobić więcej bez ciągłego przełączania kontekstu. A gdy zaczniesz układać coraz więcej takich potoków i łączyć je ze sobą, dają się osiągnąć naprawdę ciekawe rzeczy.

I patrzcie — udało się. Zrobił dokładnie to, o co prosiłem: otworzył film na YouTube, zrobił zrzuty ekranu, a teraz umieszcza je w artykule. Jeśli to nie dowodzi, że ta rzecz jest inteligentna — robi zrzuty, patrzy na stronę, wie, gdzie kliknąć i co zrobić — to nie wiem, co miałoby dowodzić. Nie licząc tego, że kazałem mu grać w szachy, grać w gry, a nawet ustanowić rekord świata w Tetrisie. Potrafi naprawdę sporo.

Popatrzcie na to: wziął obrazek i przeciągnął go w dół dokładnie tam, gdzie pasuje w artykule. Nie widziałem wcześniej, żeby robił to na żywo. Naprawdę fajne. I dalej to ciągnie.

Na tym kończymy dzisiejszy film. Mam nadzieję, że się podobało i że nauczyliście się czegoś nowego.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Kolejność wyboru narzędzia: API → makro → agent z wizją

Na czym polega: Autor formułuje jasną hierarchię. Najpierw sprawdzasz, czy usługa ma API — to najszybsze, najtańsze i najbardziej powtarzalne. Jeśli nie ma, pytasz, czy wystarczy deterministyczny skrypt klikający zawsze te same punkty. Dopiero gdy trzeba patrzeć na ekran i decydować w locie, sięgasz po agenta z wizją.

Jak stosować: Zanim zbudujesz agenta, poświęć dziesięć minut na sprawdzenie dokumentacji API i katalogu wtyczek. Jeśli przepływ jest zawsze identyczny, poproś model o napisanie zwykłego makra — to tańsze i bezpieczniejsze.

Na co uważać: Kuszące jest odpalenie agenta „bo szybciej”. Agent z wizją to najbardziej zawodne i najdroższe ogniwo — używanie go tam, gdzie wystarczy API, oznacza wprowadzanie losowości w miejsce, które mogło być deterministyczne.

2.Agent przeglądarkowy jako tester QA interfejsu

Na czym polega: Agent klika, wpisuje dane, próbuje obejść walidację i celowo psuć aplikację, generując raport zaliczonych i niezaliczonych testów. W demonstracji z budowy SaaS wykonał 85 kontroli i znalazł mnóstwo błędów.

Jak stosować: Sformułuj polecenie wprost jako zadanie przeciwnika: „staraj się to złamać, wypróbuj różne rzeczy, powiedz, co znalazłeś”. Potem osobnym poleceniem każ naprawić znalezione usterki.

Na co uważać: To nie zastępuje testów automatycznych ani przemyślanego planu testów — agent działa na wizji i nie ma gwarancji powtarzalności. Traktuj wyniki jako listę tropów do zweryfikowania, nie jako certyfikat jakości.

3.Zwiększanie głębokości testów poleceniem celu

Na czym polega: Domyślnie agent testuje przez chwilę i wraca z raportem. Można wymusić większy nakład, ustawiając cel: „nie przerywaj, dopóki nie wypróbujesz stu unikalnych scenariuszy brzegowych”.

Jak stosować: Używaj takiego trybu przed wypuszczeniem czegoś na produkcję, kiedy zależy ci na szerokości pokrycia, a nie na szybkiej odpowiedzi.

Na co uważać: Długo pracujący agent zużywa odpowiednio więcej zasobów i czasu. Sto scenariuszy przy płytkim prompcie da sto płytkich testów — jakość kryterium liczy się bardziej niż liczba.

4.Tryb headless vs headed

Na czym polega: W trybie headless przeglądarka pracuje w tle i nie przeszkadza ci w bieżącej pracy; w trybie headed widzisz każdy ruch agenta.

Jak stosować: Headed przy budowaniu i debugowaniu nowej umiejętności oraz przy wszystkim, co dotyka wrażliwych danych. Headless przy zadaniach długich i już sprawdzonych, które mają mielić w tle.

Na co uważać: Headless to również brak nadzoru. Nie uruchamiaj w tle przepływu, którego nie obserwowałeś wcześniej wielokrotnie na oczy.

5.Zapisywanie przepływów jako umiejętności wielokrotnego użytku

Na czym polega: Jednorazowo opisany słowami przepływ (zaloguj się, wejdź w konta, pobierz wyciągi jako CSV, wrzuć do folderu) zostaje zapisany jako umiejętność i można go potem uruchamiać ponownie oraz planować cyklicznie.

Jak stosować: Zaczynaj od pytania do modelu, co mu pomoże w zbudowaniu umiejętności; zwykle wystarczy precyzyjny opis słowny, bez nagrań i zrzutów ekranu. Powtarzalne zadania miesięczne (wyciągi, raporty) podepnij pod harmonogram.

Na co uważać: Umiejętność zbudowana na jednym udanym przebiegu jest krucha — wystarczy zmiana układu strony i przestaje działać. Zapisany opis powinien być możliwie ścisły, a nie ogólnikowy.

6.Sesje logowania zapamiętane, ale nie wszędzie

Na czym polega: Codex zapamiętuje sesje po jednorazowym zalogowaniu — działa to dla X czy Instagrama. Platformy bankowe, jak Relay, i tak wylogują cię ze względów bezpieczeństwa.

Jak stosować: Przy budowie automatyzacji z góry sprawdź, jak długo dana usługa utrzymuje sesję, i zaplanuj, co się stanie, gdy agent trafi na ekran logowania.

Na co uważać: Automatyzacja, która „działała wczoraj”, może dziś zatrzymać się na logowaniu. W zaplanowanych rutynach zadbaj o czytelną informację o niepowodzeniu, zamiast zakładać sukces.

7.Menedżer haseł zamiast haseł w czacie

Na czym polega: Codex ma wbudowany menedżer haseł, do którego importujesz plik CSV z kolumnami: nazwa, URL, login, hasło, notatki. Agent wypełnia wtedy formularze, a hasła nie trafiają do historii rozmowy.

Jak stosować: Zawsze, gdy automatyzacja wymaga logowania, przenieś dane uwierzytelniające do menedżera zamiast wklejać je do promptu.

Na co uważać: Plik CSV z hasłami w postaci jawnej to sam w sobie poważne ryzyko — usuń go po imporcie i nie trzymaj w katalogu projektu ani w repozytorium. Ogranicz zapisane konta do tych naprawdę potrzebnych.

8.Uwierzytelnianie dwuskładnikowe jako granica automatyzacji

Na czym polega: Gdy pojawi się prośba o kod 2FA z telefonu, agent nie przejdzie dalej — trzeba wpisać kod ręcznie. Autor zauważa, że na Macu z synchronizacją SMS-ów dałoby się to technicznie obejść przez sterowanie komputerem, ale sam odradza pochopne robienie tego.

Jak stosować: Projektuj automatyzacje tak, żeby zatrzymywały się i prosiły o twój udział na etapie 2FA, zamiast próbować go obejść.

Na co uważać: Automatyczne odczytywanie kodów 2FA znosi sens drugiego składnika. Przy usługach finansowych to ryzyko nieproporcjonalne do zaoszczędzonych minut.

9.Nadzorowany docieranie umiejętności przed pełną automatyzacją

Na czym polega: Autor wprost mówi, że jednorazowy sukces to za mało: przy koncie bankowym umiejętność należy uruchomić co najmniej dziesięć razy pod ścisłą obserwacją i dopiero potem jej ufać. Powód jest strukturalny — decyzje agenta biorą się z wizji i modelu, nie z twardego skryptu.

Jak stosować: Traktuj nowe umiejętności jak wdrożenie etapowe: kilkanaście przebiegów obserwowanych, potem tylko odczyt danych, a dopiero na końcu operacje zmieniające stan.

Na co uważać: Skala szkód rośnie z uprawnieniami. Zadania, które mogą przelać pieniądze, usunąć dane albo coś opublikować, nie powinny nigdy działać w pełni bez nadzoru.

10.Realna wartość to brak przełączania kontekstu, nie zaoszczędzone minuty

Na czym polega: Autor uczciwie przyznaje, że pojedyncza automatyzacja oszczędza mu 5–10 minut. Wartość leży w tym, że odpala umiejętność i natychmiast wraca do właściwej pracy, a łączone ze sobą umiejętności tworzą dłuższe potoki — jak zamiana filmu z YouTube w gotowy szkic artykułu na X wraz z miniaturą i zrzutami ekranu.

Jak stosować: Wybieraj do automatyzacji zadania, które wybijają cię z rytmu pracy, a nie te, które trwają najdłużej. Potem szukaj miejsc, gdzie wyjście jednej umiejętności staje się wejściem następnej.

Na co uważać: Nie oszukuj się rachunkiem czasu — budowa i docieranie umiejętności też kosztują. Jeśli robisz coś raz na kwartał, ręczne wykonanie prawdopodobnie wygra z automatyzacją.