O czym jest ten film
- Autor pokazuje setup, w którym kilka agentów kodujących (Codex) działa w tle i co 10 minut ulepsza jego aplikację bez jego udziału.
- Trzy wyspecjalizowane agenty: ogólny (bugi, wydajność, refaktoryzacja), bezpieczeństwa (podatności, OWASP Top 10) oraz ulepszeń (nowe funkcje, UI/UX).
- Każdy agent sam znajduje zmianę, tworzy branch, commit i pull request — człowiek tylko przegląda PR-y i decyduje, co scalić.
- Wyjaśnienie, dlaczego lokalny komputer i „scheduled tasks” w Codex/Claude Desktop są zawodne (wyłączenia prądu, niestabilne Wi-Fi).
- Dlaczego Codex Cloud nie nadaje się do ciągłej pracy: brak zadań cyklicznych, kontener tymczasowy niszczony po ~12 godzinach.
- Rekomendowane rozwiązanie: tani wynajęty VPS działający 24/7, na którym uruchamiamy Codex.
- Krok po kroku: utworzenie fine-grained personal access token w GitHubie z precyzyjnymi uprawnieniami.
- Konfiguracja VPS-a z gotowym szablonem Codex, logowanie przez subskrypcję ChatGPT zamiast klucza API.
- Ustawienie cron jobów, które wywołują Codex w trybie headless (
codex exec) z konkretnym promptem dla każdego agenta. - Ostrzeżenie autora: nie przekazujcie tokenów bezpośrednio agentowi — zróbcie to bezpieczną metodą.
Redakcyjne tłumaczenie
Pomysł: zespół deweloperów pracujący w tle
Ostatnio eksperymentuję z różnymi przepływami pracy, w których agenty kodujące działają w tle i nieustannie ulepszają moje aplikacje. W tym przypadku mam trzy agenty uruchamiane co 10 minut, które wyszukują różne rzeczy do poprawienia — bez żadnego zaangażowania z mojej strony.
Pierwszy to agent ogólny: wskazuje poprawki błędów, optymalizacje wydajności i tym podobne. Drugi to agent bezpieczeństwa, który szuka podatności. Trzeci to agent od ulepszeń — wyszukuje wartościowe usprawnienia, takie jak nowe funkcje czy zmiany w UI i UX.
Żeby pokazać, jak to wygląda w praktyce: kupiłem niedużą aplikację CRM, której używam w swojej firmie. Idealnie byłoby mieć zespół deweloperów, który po prostu znajduje poprawki i wprowadza je za mnie automatycznie — ale nie każdego na to stać. W tym rozwiązaniu agenty uruchamiają się co 10 minut, przechodzą przez kod, znajdują coś do naprawienia, wprowadzają zmianę, tworzą commit i branch, a następnie otwierają pull request.
Dzięki temu wystarczy, że wejdę na GitHuba i przejrzę pull requesty. Z podsumowania od razu widzę, co agent próbuje zmienić w aplikacji. Jeśli zmiana mi się podoba, po prostu ją scalam i automatycznie trafia do aplikacji.
Dlaczego nie lokalny komputer i nie Codex Cloud
Może się to wydawać podobne do zaplanowania zadania w aplikacji Codex albo w Claude Desktop. Problem w tym, że żeby to działało, musisz mieć stale włączony komputer lub laptop. Do tego dochodzą inne kłopoty — przerwy w dostawie prądu czy zrywające się Wi-Fi.
Muszę też wspomnieć o Codex Cloud. To darmowa usługa OpenAI. Wystarczy podłączyć repozytorium GitHub i poprosić agenta o zmianę, a on utworzy dla ciebie pull request. Ma to jednak ograniczenia. Pierwsze i chyba najważniejsze: nie sądzę, żeby dało się tu ustawić zadania cykliczne. Po drugie, Codex Cloud tworzy tymczasowy kontener, pobiera do niego kod i instaluje zależności — jest więc pewien „zimny start”. Kontener z całym twoim kodem i danymi jest dostępny, jak sądzę, tylko przez 12 godzin. Po tym czasie zostaje zniszczony, co oznacza, że tracisz kod, bazę danych, wszystko.
(Informacja dodatkowa: „zimny start” to opóźnienie przy pierwszym uruchomieniu, zanim środowisko pobierze kod i zainstaluje zależności).
Codex Cloud sprawdza się więc świetnie przy jednorazowych pull requestach. Ale jeśli chcesz, żeby agent stale pracował nad projektem w tle i nigdy nie tracił kodu ani bazy danych, potrzebujesz zupełnie innego rozwiązania.
Rozwiązanie: własny VPS działający 24/7
Jedną z opcji jest uruchomienie Codex bezpośrednio na swoim komputerze i ustawienie cron joba — agent będzie działał, dopóki komputer jest włączony i online. Osobiście tego nie chcę: mój komputer często się wyłącza, a Wi-Fi bywa niestabilne.
Dlatego wolę wynająć tani VPS i tam uruchomić Codex. VPS, czyli Virtual Private Server, to po prostu maszyna — jak komputer — którą wynajmujesz od innej firmy. Jest bezpieczna i prywatna: cokolwiek na niej uruchomisz, należy do ciebie. Różnica polega na tym, że jest dostępna przez całą dobę.
Jak wygląda Codex w terminalu
Jeśli nie masz doświadczenia z oknem terminala — nie panikuj, naprawdę nie jest tak źle. Wystarczy uruchomić polecenie codex, żeby otworzyć Codex. Jeśli używałeś kiedyś Claude Code, poczujesz się jak w domu.
Różnica polega na tym, że Codex można podłączyć do konta ChatGPT, co wychodzi taniej niż na przykład Claude Code, a model GPT 5.5 dorównuje pod względem kodowania czemuś takiemu jak Opus 4.8. Jest naprawdę dobry w programowaniu. W innym filmie porównuję Codex i Claude Code obok siebie — sądzę, że zgodzisz się, że z konta ChatGPT wyciśniesz znacznie więcej niż z Claude Code.
Codex używa się normalnie: można z nim rozmawiać, zmieniać model. Wybiorę GPT 5.5, a ponieważ to model do kodowania, ustawiam poziom „extra high” — zależy mi, żeby zmiany w kodzie były wartościowe i precyzyjne. Poprosiłem Codex, żeby zaplanował trzy różne zadania, które uruchamiają Codex w tle — do poprawy bezpieczeństwa aplikacji, dodawania usprawnień i tak dalej. Konfiguracja jest banalnie prosta.
Już w trakcie pokazywania Codex, gdy wróciłem na GitHuba i spojrzałem na pull requesty, widziałem, że do aplikacji dokładane są kolejne zmiany. Gdyby to zostawić na dzień czy tydzień, aplikacja rozwinęłaby się drastycznie. Co ważne — nie musimy scalać wszystkiego. Kontrola jest po naszej stronie. Możemy otworzyć dowolny pull request, zobaczyć, na czym polega zmiana, zajrzeć w kod i — jeśli nam się nie podoba — po prostu go zamknąć. A jeśli jesteśmy zadowoleni, scalić. To naprawdę jak zespół deweloperów pracujący w tle i nieustannie ulepszający naszą aplikację.
Krok 1: repozytorium na GitHubie i token dostępu
Najpierw musisz umieścić projekt na GitHubie — to z niego korzystam w tym filmie. Jeśli używasz innego systemu repozytoriów, na pewno da się jakoś podłączyć agenta, ale najważniejsze jest, żeby kod był dostępny w miejscu takim jak GitHub.
Następnie tworzymy token dostępu, którego agent będzie używał do repozytoriów. Dajemy przy tym bardzo precyzyjną kontrolę nad tym, do których repozytoriów agent ma dostęp i jakie działania może w nich wykonywać.
W profilu przechodzimy do „Settings”, potem w dół do „Developer settings”, następnie „Personal access tokens” i „Fine-grained tokens”. Tworzymy nowy token — swój nazwałem „Codex team”. Wybieramy właściciela zasobów (resource owner) i ustawiamy datę wygaśnięcia tokena, co jest dobrym pomysłem. W sekcji dostępu do repozytoriów można wybrać repozytoria publiczne, wszystkie albo tylko wybrane — polecam to ostatnie. Rozwijam listę i wybieram repozytorium CRM Forge.
W uprawnieniach klikamy „Add permission” i dodajemy kolejno: Contents, Metadata, Issues, Pull requests oraz Actions. Dla wszystkich, gdzie to możliwe, ustawiamy „Read and write” — nie wszystkie na to pozwalają (na przykład Codespaces metadata jest tylko do odczytu), ale wszędzie, gdzie się da, wybieramy odczyt i zapis, zwłaszcza dla pull requestów. Klikamy „Generate token”, kopiujemy go i przechowujemy w bezpiecznym miejscu.
(Informacja dodatkowa: fine-grained personal access token to token GitHuba o precyzyjnie ograniczonych uprawnieniach i zasięgu, bezpieczniejszy od klasycznego tokena z pełnym dostępem).
Krok 2: konfiguracja VPS-a
Nie lubię sam zajmować się infrastrukturą, więc korzystam z gotowego hostingu — jest bardzo prosty w konfiguracji. Link do strony zostawię w opisie filmu. Wybieramy plan; ja biorę plan KMv2. Zaletą tych serwerów jest to, że można na nich uruchomić także inne rzeczy, na przykład n8n. Wybieramy okres rozliczeniowy; można też włączyć codzienne automatyczne kopie zapasowe, ale ja się tym nie przejmuję.
(Informacja dodatkowa: n8n to popularne narzędzie open source do automatyzacji przepływów pracy i integracji między aplikacjami).
Wybieramy system operacyjny, a w sekcji „Application” upewniamy się, że zaznaczony jest OpenAI Codex. Możesz wpisać kod „Leoncodex”, który da dodatkowe 10% zniżki na plan. Potem wystarczy przejść do płatności.
Krok 3: logowanie do Codex na VPS-ie
Z panelu VPS-a przechodzimy do terminala. Wygląda mniej strasznie, niż mogłoby się wydawać — wpiszmy clear, żeby oczyścić ekran i widzieć, co robimy. Ponieważ postawiliśmy serwer z szablonu Codex, sam Codex jest już zainstalowany. Wystarczy uruchomić polecenie codex.
Mamy kilka opcji logowania. Pierwsza nie zadziała, bo jesteśmy na VPS-ie. Jeśli masz konto ChatGPT, wybierz drugą opcję. Jeśli nie chcesz używać subskrypcji, możesz wygenerować klucz API OpenAI i skorzystać z trzeciej opcji — ale polecam subskrypcję, bo będzie znacznie tańsza niż płacenie z klucza API. Wybieram więc drugą opcję, klikam link, kopiuję kod, wklejam i potwierdzam. Gotowe — mogę zamknąć tę zakładkę. Loguję się do Codex, testuję, wysyłając „hey”, i dostaję odpowiedź, co oznacza, że wszystko działa.
Krok 4: dostęp agenta do GitHuba
Teraz musimy dać agentowi dostęp do repozytorium GitHub. Możemy po prostu poprosić o to Codex, na przykład: „Skonfiguruj dostęp do GitHuba. Musisz umieć odczytywać repozytoria, klonować je, czytać issues i tworzyć pull requesty. Użyj tego fine-grained personal access tokena”.
Istnieją zapewne dużo bezpieczniejsze sposoby — możesz poprosić agenta, żeby przeprowadził cię przez kroki. To proste polecenie w terminalu, które ustawia zmienną środowiskową. U mnie jest to jednak token jednorazowy, którego po nagraniu nie będę używał, więc udostępniam go agentowi. Spodziewałem się nawet, że Codex zaprotestuje i ostrzeże mnie, żeby ten token usunąć. Co ciekawe, agent w ogóle nie zaprotestował — po prostu przyjął token.
Ale szczerze: nie udostępniajcie tych tokenów agentom. Jeśli chcesz używać tego naprawdę, poproś agenta, żeby wyjaśnił ci bezpieczny sposób ustawienia tej zmiennej. I to wszystko — agent ma teraz dostęp do repozytorium.
Krok 5: klonowanie projektu
Możemy teraz poprosić agenta: „Utwórz nowy folder o nazwie projects i sklonuj do niego repozytorium CRM Forge”. Agent pobierze kod z repozytorium na VPS. Kod żyje teraz w folderze projects, a w nim znajduje się folder CRM Forge z kodem projektu. Teraz możemy skonfigurować agenty działające w tle.
Krok 6: cron joby i tryb headless
Jak to właściwie działa? Ustawiamy cron job — to instrukcja dla systemu operacyjnego, żeby uruchamiał program lub polecenie w stałych odstępach czasu albo o konkretnej porze dnia. Codex można wywołać właśnie takim poleceniem.
Wychodzę z Codex i uruchamiam go w trybie headless — bez otwierania okna terminala. Można wtedy uruchomić Codex bezpośrednio z promptem, a on zwróci wynik, na przykład: codex exec z poleceniem „napisz wiersz o automatyzacji AI w małych firmach”.
(Informacja dodatkowa: tryb headless to uruchomienie bez interaktywnego interfejsu — polecenie wykonuje się w tle i zwraca sam wynik, co jest niezbędne przy cron jobach).
Żeby ustawić cron joby i te agenty w tle, na szczęście nie musimy robić nic ręcznie — poprosimy o to Codex. Wysyłamy prompt w stylu:
„Ustaw cron job, który uruchamia się co 10 minut i robi co następuje. Uruchamia sesję
codex execz promptem: Twoją rolą jest ulepszanie aplikacji CRM Forge w folderzeprojects. Przeprowadź audyt kodu i znajdź błędy, optymalizacje wydajności, refaktoryzacje itd. Następnie wprowadź zmianę w feature branchu, utwórz commit i otwórz pull request. Upewnij się, że nie istnieje już PR dla tej samej zmiany, zanim cokolwiek zrobisz”.
Ten ostatni warunek jest ważny: jeśli mamy już pull request dla danej poprawki błędu czy zmiany w UI, agent nie powinien robić nic. Codex utworzy teraz cron job. U mnie mówi, że podobny już istnieje — bo pracuję na tym samym VPS-ie, którego użyłem we wstępie. Ale możemy dodać dowolnie wiele cronów.
Drugi z nich mówi: „Jesteś ekspertem od bezpieczeństwa pracującym nad aplikacją CRM Forge i masz przeprowadzić audyt bezpieczeństwa względem OWASP Top 10”. Mogę też utworzyć agenta, który nieustannie dodaje wartościowe usprawnienia — aktualizuje UI lub UX albo wskazuje nowe funkcje. On również działa co 10 minut.
(Informacja dodatkowa: OWASP Top 10 to uznana lista dziesięciu najczęstszych i najgroźniejszych kategorii podatności aplikacji internetowych).
Możesz robić, co chcesz — dodać kolejnego agenta, który stale przegląda issues albo pull requesty na GitHubie. To zależy od ciebie, granicą jest tylko wyobraźnia.
Zakończenie
Jeśli chcesz nauczyć się budować agenty kodujące jak profesjonalista, sprawdź mój Agentic Coding Masterclass. Kurs uczy wszystkiego, co trzeba wiedzieć o wykorzystaniu agentów do tworzenia prawdziwego oprogramowania — dodaliśmy właśnie całą sekcję o tworzeniu design systemów oraz kompletny projekt „build along”, w którym budujesz prawdziwą aplikację SaaS z uwierzytelnianiem użytkowników, a nawet z narzędziami MCP, dzięki którym inne systemy AI mogą korzystać z twojej aplikacji. Dodaliśmy też kurs Claude Code i wciąż uzupełniamy materiały.
Mam nadzieję, że film był przydatny. Jeśli tak — zostaw łapkę w górę i zasubskrybuj kanał. Do zobaczenia w następnym. Cześć!
10 najważniejszych takeaways — z kontekstem zastosowania
1.Ciągłe ulepszanie kodu przez agenty działające w tle
Na czym polega: Zamiast wywoływać agenta ręcznie, ustawiasz kilka agentów, które co 10 minut same audytują kod i otwierają pull requesty. Efekt przypomina mały zespół deweloperów pracujący non stop.
Jak stosować: Zacznij od jednej aplikacji z porządnym repozytorium i jednego agenta ogólnego. Sprawdź jakość generowanych PR-ów przez kilka dni, dopiero potem dokładaj kolejne agenty.
Na co uważać: „Co 10 minut” to marketingowa częstotliwość — przy większym projekcie może generować szum i zużywać limity. Dostosuj interwał do realnego tempa, w jakim jesteś w stanie przeglądać PR-y.
2.Człowiek zostaje bramkarzem przez pull requesty
Na czym polega: Agenty nie wgrywają zmian bezpośrednio — tworzą branch, commit i pull request. Ty przeglądasz podsumowanie oraz kod i decydujesz, czy scalić, czy zamknąć.
Jak stosować: Ustaw regułę, żeby żaden PR nie był mergowany automatycznie. Włącz w repozytorium ochronę gałęzi głównej i wymagany przegląd, żeby technicznie wymusić kontrolę człowieka.
Na co uważać: Wygoda scalania „na oko” z samego podsumowania jest zwodnicza. Zawsze czytaj rzeczywisty diff — agent potrafi napisać przekonujący opis do wątpliwej zmiany.
3.VPS zamiast lokalnego komputera i Codex Cloud
Na czym polega: Lokalny komputer bywa wyłączony i traci sieć, a Codex Cloud niszczy kontener po około 12 godzinach i nie obsługuje zadań cyklicznych. Tani VPS działa 24/7 i trzyma kod oraz bazę na stałe.
Jak stosować: Wynajmij najtańszy plan VPS wystarczający do uruchomienia Codex; ten sam serwer wykorzystasz też do innych narzędzi (np. n8n).
Na co uważać: Na VPS-ie to ty odpowiadasz za aktualizacje, bezpieczeństwo i kopie zapasowe. Rozważ włączenie automatycznych backupów — autor je pominął, ale przy realnym projekcie to ryzyko.
4.Trzy wyspecjalizowane role zamiast jednego agenta
Na czym polega: Podział na agenta ogólnego (bugi, wydajność, refaktoryzacja), bezpieczeństwa (OWASP Top 10) i ulepszeń (funkcje, UI/UX) daje wyraźniejsze, bardziej ukierunkowane zmiany.
Jak stosować: Nadaj każdemu agentowi wąską, jednoznaczną rolę w promptcie. Węższy zakres = mniejsze, łatwiejsze do przejrzenia PR-y.
Na co uważać: Kilka agentów pracujących na tym samym kodzie może otwierać nakładające się lub konfliktujące PR-y. Warunek „sprawdź, czy PR na tę zmianę już nie istnieje” jest tu konieczny, ale niedoskonały.
5.Fine-grained token GitHuba z minimalnymi uprawnieniami
Na czym polega: Zamiast pełnego dostępu tworzysz token o precyzyjnym zakresie: wybrane repozytoria oraz uprawnienia Contents, Metadata, Issues, Pull requests i Actions (odczyt i zapis, gdzie to możliwe).
Jak stosować: Ogranicz token do jednego repozytorium i ustaw datę wygaśnięcia. Nadaj tylko te uprawnienia, których agent faktycznie potrzebuje.
Na co uważać: Uprawnienie do zapisu w Actions i Contents jest potężne. Traktuj taki token jak sekret produkcyjny — jego wyciek oznacza dostęp do kodu i możliwość uruchamiania workflowów.
6.Nie przekazuj tokenów bezpośrednio agentowi
Na czym polega: Autor sam wkleił token do promptu, ale wyraźnie odradza tę praktykę. Bezpieczniej poprosić agenta, by przeprowadził cię przez ustawienie zmiennej środowiskowej.
Jak stosować: Ustaw sekret jako zmienną środowiskową na VPS-ie samodzielnie (poza kontekstem czatu z agentem). Poproś agenta jedynie o instrukcję, a nie o wykonanie z podanym tokenem.
Na co uważać: Wklejony w rozmowę token trafia do logów i historii sesji. Jeśli mimo wszystko to zrobisz, użyj tokena jednorazowego i natychmiast go unieważnij — dokładnie jak w nagraniu.
7.Logowanie przez subskrypcję ChatGPT, nie klucz API
Na czym polega: Codex można podłączyć do konta ChatGPT, co według autora wychodzi taniej niż płacenie za tokeny kluczem API, a model GPT 5.5 jest mocny w kodowaniu.
Jak stosować: Na VPS-ie wybierz opcję logowania przez subskrypcję (nie pierwszą, która na serwerze nie zadziała). Klucz API zostaw jako opcję awaryjną.
Na co uważać: Rozliczenie subskrypcyjne ma swoje limity użycia — agenty działające co 10 minut potrafią je szybko wyczerpać. Monitoruj zużycie, zanim uznasz setup za „darmowy w tle”.
8.Cron + tryb headless jako silnik automatyzacji
Na czym polega: Cron job uruchamia codex exec w trybie headless z zadanym promptem w regularnych odstępach. To on zamienia jednorazowego agenta w stale pracujący proces.
Jak stosować: Poproś Codex, żeby sam utworzył cron joby, ale potem przejrzyj wpisy crontab i zweryfikuj ścieżki, interwały oraz treść promptów.
Na co uważać: Nakładające się uruchomienia (nowa sesja startuje, zanim poprzednia skończy) mogą powodować konflikty. Przy dłuższych audytach rozważ dłuższy interwał lub blokadę zapobiegającą równoległym uruchomieniom.
9.Precyzyjny prompt z warunkiem deduplikacji PR-ów
Na czym polega: Prompt agenta jasno definiuje rolę, zakres audytu, sposób wprowadzenia zmiany (feature branch → commit → PR) oraz wymóg sprawdzenia, czy PR na tę samą zmianę już nie istnieje.
Jak stosować: Trzymaj się tej struktury: rola + zakres + procedura commitowania + reguły stop. Im konkretniej, tym mniej przypadkowych zmian.
Na co uważać: Rozpoznawanie „tej samej zmiany” przez agenta jest zawodne — może dublować PR-y albo pomijać coś istotnego. Okresowo porządkuj otwarte pull requesty.
10.Ostrożność wobec agentów zmieniających bezpieczeństwo i infrastrukturę
Na czym polega: Agenty mają uprawnienia do zapisu, potrafią modyfikować konfigurację bezpieczeństwa i uruchamiać workflowy GitHub Actions — a autor zauważa, że Codex bez wahania przyjął wrażliwy token.
Jak stosować: Traktuj cały setup jak środowisko o podwyższonym ryzyku: testuj na aplikacji niekrytycznej, izoluj repozytorium, przeglądaj każdą zmianę dotykającą zależności lub konfiguracji.
Na co uważać: Automat, który sam „ulepsza” bezpieczeństwo, może też coś zepsuć lub wprowadzić regresję. Nie zostawiaj procesu bez nadzoru na produkcji i nie mergeuj zmian bezpieczeństwa bez świadomej weryfikacji.