Otwierasz aplikację po raz pierwszy i wygląda dokładnie jak ChatGPT: lista czatów po lewej, pole rozmowy na środku. Tylko że tym razem AI nie tylko odpowiada — czyta twoje pliki, zakłada arkusze, klika w przeglądarce i uruchamia kod na twoim komputerze. To jest Codex, agent programistyczny od OpenAI (tej samej firmy, która stworzyła ChatGPT). Pokażę ci go tak, jak go uczę: jeden projekt od pustego folderu do działającego pulpitu w internecie, a po drodze cały interfejs. Poprowadzę cię przez sześć kroków — założenie projektu, plik kontekstowy, podłączenie danych, pierwszy efekt zamieniony w umiejętność, publikację strony w sieci i automatyzację, która działa bez ciebie.
Jedno zastrzeżenie na start, bo zaoszczędzi ci rozczarowania: to nie jest magia. Codex nie „zrobi wszystkiego sam za pierwszym razem”. Działa jak współpracownik, którego prowadzisz, poprawiasz i któremu z czasem ufasz coraz bardziej. Moim zdaniem najlepiej myśleć o nim nie jak o automacie do życzeń, lecz jak o kimś, kogo właśnie wdrażasz do pracy. I jeszcze jedno: to nie jedyne takie narzędzie. Po drugiej stronie jest Claude Code od firmy Anthropic — inny silnik, inne mocne strony. Nie chodzi o to, który wygrywa, tylko który pasuje do konkretnego zadania.
Zanim założysz cokolwiek, przyjrzyj się temu, co masz przed sobą. Codex to aplikacja, w której rozmawiasz z modelem AI jak w ChatGPT, ale pracujesz w projektach — czyli w konkretnych folderach na swoim komputerze. Model (czyli „mózg” AI, tutaj jeden z modeli GPT od OpenAI) dostaje przy tym „ręce”: czyta i tworzy pliki, przegląda arkusze Excela, steruje myszką i przeglądarką, uruchamia kod. Rozmowa w przeglądarce tego nie potrafi — tam po prostu piszesz i dostajesz tekst. Tutaj agent realnie działa na twoich danych.
Zanim cokolwiek zbudujesz, warto wiedzieć, gdzie są pokrętła. U góry wybierasz model, jego szybkość oraz poziom „wysiłku” — od niskiego, przez średni i wysoki, po bardzo wysoki. Reguła, którą sama bym ci dała: do planowania i prostych zadań ustaw średni, wysoki włącz na duży projekt, a najwyższy zostaw na trudny błąd, którego nic innego nie rozwiązuje. Dlaczego nie zawsze maksimum? Z dwóch powodów. Po pierwsze, przy banalnym zadaniu najwyższy poziom potrafi przekombinować — robi z igły widły. Po drugie, każdy poziom kosztuje inną liczbę tokenów (token to drobny fragment tekstu, jednostka, którą rozlicza się model). Niski kosztuje najmniej, najwyższy najwięcej. W ustawieniach, w sekcji limitów, widać, ile zostało ci z bieżącej sesji i kiedy się odnawia — warto tam zaglądać.
Żeby zacząć, wystarczy konto ChatGPT. Jest darmowy próg z ograniczonym dostępem, ale do realnej pracy lepszy jest plan płatny — szybciej w niego nie wpadniesz. Pobierasz aplikację na swój system i tyle. Codex działa też w edytorze kodu czy w terminalu z pełniejszymi możliwościami, ale na początek aplikacja zaprowadzi cię bardzo daleko.
Jeszcze słowo o Claude Code, bo różnica jest praktyczna. Z obserwacji rynku: Claude bywa lepszy w swobodnym myśleniu i planowaniu, a Codex — w pragmatycznym wykonaniu długiego planu i w wyszukiwaniu błędów. Jeśli chcesz wejść w to głębiej, mam osobny tekst o tym, dlaczego Claude Code bywa najpotężniejszym narzędziem. W tym tekście zostajesz przy Codeksie.
Krok 1: załóż projekt i daj mu kontekst o sobie
Pierwszy odruch większości ludzi to od razu coś zlecić. Zatrzymaj się. Zanim cokolwiek powstanie, dajesz narzędziu kontekst — kim jesteś i dokąd zmierzasz. To kilka minut, które zwracają się dziesięciokrotnie.
Zaczynasz od nowego projektu: klikasz „nowy czat”, potem dodajesz projekt i wskazujesz folder, w którym ma żyć. Może być pusty — niech nazywa się na przykład „YouTube Analytics Demo”, bo właśnie taki projekt zbudujesz: system, który pobierze komentarze z kanału YouTube, przeanalizuje je, zbierze w arkuszu i pokaże na pulpicie dostępnym z telefonu. Od pustego folderu do działającego efektu.
Teraz najważniejszy nawyk: tworzysz plik AGENTS.md. To zwykły dokument tekstowy, który Codex czyta na starcie każdej nowej rozmowy — jego „dokument wdrożeniowy”. Wpisujesz w niego, kim jesteś, jaki jest cel projektu i dokąd zmierzasz. Nie musisz pisać go ręcznie. Wystarczy poprosić: „Załóż plik AGENTS.md z kontekstem o mnie i o celu tego projektu — buduję pulpit z analizą komentarzy z YouTube, który chcę opublikować w sieci”. Codex sam go ułoży, a ty go przejrzysz.
Po co to wszystko? Bo bez takiego pliku wiedza modelu znika między rozmowami. To, co ustalisz w jednym oknie, w nowym może już nie istnieć — pamięć pojedynczego czatu nie przenosi się sama. Zapisanie kontekstu w pliku sprawia, że projekt „pamięta” sam siebie, a ty nie zaczynasz za każdym razem od zera. To pierwsza z kilku zmian myślenia, które chcę ci pokazać: wiedzę zapisuje się w plikach, nie w głowie i nie w jednej rozmowie.
Krok 2: podłącz dane i rozsądnie ustaw uprawnienia
Pierwsza realna przeszkoda w każdym projekcie to dostęp do danych. Tu potrzebujesz komentarzy z YouTube — i tu pojawia się świetny moment na drugą zmianę myślenia: gdy nie wiesz, czy coś jest w ogóle możliwe, nie szukaj od razu odpowiedzi gdzie indziej. Zapytaj samo narzędzie. Napisz wprost: „Pomóż mi ustalić, jak podłączyć się do moich danych z YouTube, żeby pobrać komentarze, i wytłumacz to krok po kroku”. To właśnie mechanizm, dzięki któremu większość ludzi najszybciej uczy się tych narzędzi — pytasz agenta i prosisz, żeby wyjaśnił, zamiast zgadywać.
Codex ma gotowe wtyczki (zwane też konektorami) — połączenia z popularnymi usługami jak Dysk Google, Slack, SharePoint czy GitHub. Tam logujesz się tak samo, jak logujesz się do poczty: klikasz, podajesz hasło, gotowe. To najprostsza droga i jeśli twoje dane siedzą w jednej z tych usług, korzystaj z niej. Problem w tym, że dla YouTube gotowej wtyczki nie ma. Gdy jej brakuje, pytasz Codeksa, jak inaczej się połączyć, a on prowadzi cię przez założenie klucza dostępowego (klucza API — to taka cyfrowa karta wstępu, którą program przedstawia się usłudze, żeby dostać dane). W tym wypadku zakładasz projekt w panelu chmurowym dostawcy, włączasz dostęp do danych YouTube, generujesz klucz i wklejasz go u siebie.
I tu uwaga, którą musisz zapamiętać raz na zawsze: klucz wklejasz wyłącznie do pliku o nazwie .env (z kropką na początku). Ta kropka mówi narzędziu, żeby nigdy nie udostępniało tego pliku publicznie. Klucz to hasło do twoich danych — nie wkleja się go do byle dokumentu ani nie wysyła w świat.
Drugi wątek to uprawnienia, czyli ile Codex może zrobić bez pytania o zgodę. Domyślnie często pyta o pozwolenie na kolejne kroki — „mam dostać się do sieci?”, „mam nadpisać ten plik?”. To bezpieczne, ale spowalnia. W ustawieniach ogólnych można to poluzować aż do pełnego dostępu, w którym agent działa bez pytania. Moja rada brzmi rozsądnie i nudno: na początku zostaw ustawienia domyślne. Pełen dostęp włącz dopiero, gdy rozumiesz, co narzędzie robi — wtedy faktycznie oszczędza czas, ale wymaga zaufania, na które trzeba sobie zapracować. Słyszałeś pewnie historie o agentach, które skasowały bazę albo rozesłały lawinę maili. To prawie zawsze skutek mglistych instrukcji i zbyt wczesnego oddania pełnej kontroli, nie złośliwości narzędzia.
Gdy klucz jest na miejscu, każesz Codeksowi sprawdzić połączenie: „Przetestuj, czy ten klucz działa”. On uruchamia próbę, czasem trafia na drobny błąd, sam próbuje innej drogi i w końcu melduje, że pobiera komentarze. Jeśli po drodze coś się nie udało, zrób rzecz, która buduje mądrzejszy system: poproś, żeby zapisał tę wiedzę w projekcie, „żeby ten błąd nigdy się nie powtórzył”. Każda porażka to dane. Zapisana — nie wraca.
Krok 3: zrób pierwszy efekt i zamień go w umiejętność
Masz dane, więc czas na pierwszy konkret. Włącz tryb planowania — to przełącznik, w którym Codex niczego nie wykonuje, tylko rozpisuje plan i dopytuje, co dokładnie ma powstać. Dopiero po akceptacji planu rusza do działania. Zawsze zaczynam od planowania, bo tu, w rozmowie, najtaniej się myli i poprawia.
Prosisz mniej więcej tak: „Pobierz około 200 moich najnowszych komentarzy, znajdź w nich wzorce i pokaż wszystko w arkuszu Excela — z wykresami i wnioskami, które pomogą mi tworzyć treści, na które ludzie czekają”. Codex dopyta o szczegóły (z ilu filmów, jak klasyfikować komentarze), przedstawi plan, a po akceptacji złoży arkusz: udział pytań, najczęściej wymieniane narzędzia, kategorie komentarzy, pomysły na treści, gotowe okazje do odpowiedzi i surowe dane w osobnej zakładce. Pierwszy efekt potrafi być całkiem niezły.
Ale powiem ci uczciwie to, co łatwo przemilczeć: przy ogólnym poleceniu efekt bywa ogólny. Jeśli polecenie jest mgliste, wynik też. Im dokładniej powiesz, czego szukasz — które wskaźniki cię interesują, na jakie komentarze polujesz — tym bardziej trafiony rezultat. To trzecia zmiana myślenia: jakość wejścia decyduje o jakości wyjścia, a większość pracy odbywa się w precyzji prośby, nie w sile modelu.
A teraz rzecz, dla której naprawdę warto przejść ten krok — umiejętność (po angielsku skill). To zapisany przepis: zwykły plik tekstowy z instrukcją „jak zrobić to dobrze, krok po kroku”. Gdy raz wypracujesz dobry efekt, mówisz: „Zamień to, co właśnie zrobiłeś, w umiejętność, żeby za każdym razem, gdy poproszę o analizę komentarzy z YouTube, powtórzyć ten sam proces”. Od tej chwili wystarczy naturalnym językiem powiedzieć „zrób to”, a Codex odtworzy całą procedurę — z którego źródła pobrać dane, jak je przeanalizować, jak zbudować arkusz.
Lubię tu obraz przepisu kulinarnego, bo świetnie oddaje sedno. Gdy ktoś prosi cię o naleśniki, otwierasz przepis i trzymasz się proporcji, składników i czasu — i wychodzą tak samo za każdym razem. Bez przepisu zgadujesz, a efekt skacze. Co więcej, przepis można ulepszać: raz dorzucisz więcej czekolady, raz skrócisz smażenie — i aktualizujesz recepturę. Tak samo z umiejętnością: każde użycie to okazja, żeby ją dopracować. Umiejętność możesz trzymać globalnie (działa w każdym projekcie) albo lokalnie (tylko w tym jednym) — wystarczy poprosić o jedno lub drugie. Budowanie własnej biblioteki takich przepisów to dla mnie sedno całej pracy z Codeksem.
Krok 4: zbuduj pulpit i opublikuj go w sieci
Surowe dane w arkuszu to dopiero połowa. Teraz robisz z nich pulpit (dashboard) — stronę z wykresami i wnioskami, na którą miło spojrzeć. Wskazujesz Codeksowi gotowy arkusz (możesz „otagować” konkretny plik, żeby wiedział, z czego korzysta) i prosisz o ładną stronę z wizualizacją danych. Możesz dodać, żeby najpierw użył generatora obrazów i zaproponował wygląd oraz logo — to drobiazg, który robi różnicę, bo agent najpierw szkicuje koncept, a potem dopiero buduje resztę.
Tu zobaczysz coś, co naprawdę warto docenić: Codex ma wbudowaną pętlę weryfikacji. Zanim odda wynik, sam ogląda własną stronę, wyłapuje usterki i je poprawia. Potrafi zameldować: „test przeszedł, robię jeszcze jeden przegląd wizualny” — znajduje kilka problemów, naprawia je, sprawdza ponownie i dopiero wtedy oddaje gotowy pulpit. Nie musisz pilnować każdego piksela; narzędzie samo robi kilka podejść.
Jest jednak haczyk, który myli wszystkich na początku. Powstała strona działa tylko lokalnie — na twoim komputerze, pod adresem zaczynającym się od „localhost”. Skopiuj ten adres i wklej znajomemu, a zobaczy pustkę, bo strona żyje wyłącznie u ciebie. Żeby otworzyć ją z telefonu albo komukolwiek pokazać, trzeba ją opublikować.
Służą do tego dwa darmowe na start narzędzia. Pierwsze to GitHub — chmura na pliki i kod z historią zmian. Tworzysz tam repozytorium (po prostu zbiór twoich plików i folderów w chmurze) i wysyłasz do niego projekt. To jak przeniesienie dokumentu z dysku lokalnego do chmury, żeby był dostępny z każdego urządzenia. Drugie to Vercel — usługa, która z tego kodu robi działający adres w internecie, taki, który każdy może otworzyć. Codex pomaga połączyć jedno z drugim: zakłada repozytorium, podłącza konto, wysyła pliki. Pytasz go po prostu: „Pomóż mi podłączyć ten projekt do GitHuba i opublikuj go”.
Najwygodniejsze jest to, że oba narzędzia „rozmawiają” ze sobą. Każda zmiana wysłana na GitHub trafia automatycznie do publicznej wersji strony na Vercelu. Brzmi jak trzy miejsca do ogarnięcia — Codex, GitHub, Vercel — ale w praktyce zarządzasz tylko jednym: Codeksem. I jeszcze jedna zaleta tego układu: zmiany testujesz lokalnie, a do publicznej wersji trafiają dopiero, gdy je zatwierdzisz. Każesz zmienić tło na czerwone, oglądasz to u siebie, a jeśli ci się nie spodoba — publiczna strona nigdy nie drgnie. Czysty rozdział między wersją roboczą a tą, którą widzi świat.
Krok 5: ustaw automatyzację i naucz się ją sprawdzać
Ostatni element układanki to automatyzacja — zaplanowane zadanie, które Codex uruchamia sam, bez twojego udziału. Otwierasz w projekcie nowy czat i opisujesz, czego chcesz: „W każdą niedzielę o 17:00 uruchom umiejętność analizy komentarzy, dopisz nowe wiersze do arkusza, odśwież statystyki, a potem wyślij zmiany na stronę, żeby pulpit sam się zaktualizował”. Prompt może brzmieć trochę chaotycznie — to nic, Codex dopyta o brakujące szczegóły i ustawi cotygodniowe zadanie, które samo pobierze komentarze, przeliczy dane i opublikuje świeży pulpit.
Są tu dwie pułapki, które chcę, żebyś znał, zanim na nie wpadniesz. Pierwsza: automatyzacja domyślnie potrafi ustawić się na inny model, niż chcesz — zwykle słabszy. Zajrzyj w jej ustawienia i wybierz właściwy model oraz poziom wysiłku, bo na domyślnym zadanie potrafi się ślimaczyć albo gubić. Druga, ważniejsza: takie zadanie działa lokalnie. Gdy wyłączysz komputer albo zamkniesz aplikację, automatyzacja przestaje chodzić. Żeby pracowała naprawdę całą dobę, trzeba ją przenieść do chmury — to osobny, dalszy krok.
Wpisz sobie głęboko jedną zasadę: nie oczekuj, że automatyzacja będzie idealna za pierwszym razem. To nierealne. Lubię tu porównanie do uczenia dziecka jazdy na rowerze. Nie puszczasz kierownicy od razu — najpierw idziesz obok, podtrzymujesz, poprawiasz, a z czasem oddajesz coraz więcej samodzielności i w końcu zdejmujesz boczne kółka. Tak samo tutaj: każde uruchomienie to dane, dzięki którym ulepszasz zadanie. Gdy coś się zatnie — a potrafi się zaciąć choćby na otwartym pliku, którego agent nie może nadpisać — nie patrz bezradnie. Zatrzymaj zadanie, zapytaj „co się dzieje?”, rozwiąż drobiazg sam i jedź dalej. To oszczędza i czas, i tokeny, które inaczej spaliłyby się na błądzeniu.
Wtedy też przydaje się sterowanie przeglądarką (po angielsku browser use): prosisz Codeksa, żeby sam otworzył gotową stronę, poklikał po niej, spróbował ją „zepsuć” i zgłosił usterki. Widać przy tym, jak porusza kursorem po ekranie. Przydaje się to dwojako — do testowania własnych efektów (znajduje rzeczy, które sam przeoczysz) oraz tam, gdzie nie ma gotowego połączenia i dane trzeba ręcznie wyklikać na stronie. Najlepsze jest to, że taki test możesz wpisać na stałe do umiejętności: „nie oddawaj mi wyniku, dopóki sam go nie sprawdzisz w przeglądarce”. Tak narzędzie z każdym dniem pilnuje swojej pracy coraz lepiej.
Co z tego wynosisz
Cofnij się na chwilę i spójrz na całość. Zbudowałeś projekt od pustego folderu: założyłeś go, dałeś mu kontekst, podłączyłeś dane, zrobiłeś pierwszy efekt i zamieniłeś go w umiejętność, opublikowałeś pulpit w sieci i ustawiłeś automatyzację, która co tydzień sama go odświeża. To kawał drogi jak na jeden krótki projekt.
Jest jednak jeden wniosek, który spina wszystko inne — i moim zdaniem najważniejszy. Cały ten projekt to zwykły folder z plikami. To, że pliki są ułożone w czytelną strukturę, sprawia, że może w nich pracować dowolne narzędzie agentowe — Codex, Claude Code czy inne — bo wszystkie czytają ten sam katalog. Możesz je nawet łączyć: jednym zaplanować, drugim wykonać, trzecim wyłapać błędy. Dlatego pytanie nigdy nie brzmi „które narzędzie jest najlepsze”, tylko „które najlepiej pasuje do tego zadania”. Jeśli zaczynasz od zera i chcesz najpierw poukładać podstawy, mam osobny tekst o tym, jak złożyć prosty stack AI na początek.
Zostaje cicha zasada na koniec, ta sama, która wracała w każdym kroku: te systemy nie mają być idealne od razu — mają być coraz lepsze, bo każde użycie to dane, które w nie wkładasz. A jeśli szukasz pierwszego ruchu, jest banalnie prosty. Wypisz nudne, powtarzalne czynności ze swojego tygodnia — te, które chciałbyś, żeby działy się, gdy śpisz. Wybierz jedną. Zamień ją w umiejętność. Potem następną.