To jest wersja do trzymania pod ręką. Otwierasz ją w trakcie pracy, robisz kolejny krok i odhaczasz punkt. Kolejność jest celowa: każda faza opiera się na poprzedniej, więc rób je po kolei — od założenia projektu po automatyzację, która działa bez ciebie.
Przewodnia myśl jednym zdaniem: Codex to współpracownik, którego prowadzisz i poprawiasz — nie automat do życzeń. Pierwszy efekt rzadko jest idealny; system staje się lepszy z każdym użyciem.
0. Zanim zaczniesz — co musisz mieć
- Załóż lub miej konto ChatGPT — to wszystko, czego potrzeba na start. Darmowy próg ma ograniczony dostęp; do realnej pracy weź plan płatny, żeby nie wpaść w limit za szybko.
- Pobierz aplikację Codeksa na swój system. Działa też w edytorze kodu i w terminalu, ale na początek wystarczy aplikacja.
- Znajdź u góry trzy pokrętła: model, jego szybkość i poziom „wysiłku” (od niskiego, przez średni i wysoki, po bardzo wysoki).
- Ustaw poziom wysiłku według reguły: średni do planowania i prostych zadań, wysoki na duży projekt, najwyższy zostaw na trudny błąd, którego nic innego nie rozwiązuje. Przy banalnym zadaniu najwyższy poziom potrafi przekombinować.
- Zajrzyj w ustawieniach do sekcji limitów — zobaczysz, ile zostało ci z bieżącej sesji i kiedy się odnawia. Każdy poziom wysiłku kosztuje inną liczbę tokenów: niski najmniej, najwyższy najwięcej.
1. Załóż projekt i daj mu kontekst
- Kliknij „nowy czat”, dodaj projekt i wskaż folder, w którym ma żyć — może być pusty.
- Poproś Codeksa o plik
AGENTS.mdz kontekstem o tobie i celu projektu, na przykład: „Załóż plik AGENTS.md z kontekstem o mnie i o celu tego projektu”. Codex sam go ułoży. - Przejrzyj
AGENTS.mdi sprawdź, że zapisał, kim jesteś, jaki jest cel projektu i dokąd zmierzasz. To dokument, który Codex czyta na starcie każdej nowej rozmowy. - Zapamiętaj zasadę: wiedzę zapisujesz w plikach, nie w głowie i nie w jednej rozmowie. Bez
AGENTS.mdustalenia z jednego okna znikają w następnym.
2. Podłącz dane i ustaw uprawnienia
- Sprawdź, czy twoje dane siedzą w usłudze z gotową wtyczką (konektorem) — Dysk Google, Slack, SharePoint, GitHub. Jeśli tak, zaloguj się tak jak do poczty i korzystaj z niej.
- Gdy gotowej wtyczki nie ma, zapytaj wprost samo narzędzie, jak inaczej się połączyć: „Pomóż mi ustalić, jak podłączyć się do moich danych, i wytłumacz to krok po kroku”. Codex przeprowadzi cię przez założenie klucza dostępowego (klucza API).
- Wklej klucz wyłącznie do pliku o nazwie
.env(z kropką na początku). Kropka mówi narzędziu, żeby nigdy nie udostępniało tego pliku publicznie. Klucza nie wkleja się do byle dokumentu ani nie wysyła w świat. - Na start zostaw uprawnienia domyślne — Codex pyta o zgodę na kolejne kroki. Pełen dostęp (działanie bez pytania) włącz dopiero, gdy rozumiesz, co narzędzie robi.
- Każ sprawdzić połączenie: „Przetestuj, czy ten klucz działa”, i poczekaj, aż Codex zamelduje, że pobiera dane.
- Jeśli po drodze coś się nie udało, poproś, żeby zapisał tę wiedzę w projekcie, „żeby ten błąd nigdy się nie powtórzył”. Zapisana porażka nie wraca.
3. Zrób pierwszy efekt i zamień go w umiejętność
- Włącz tryb planowania — Codex niczego nie wykonuje, tylko rozpisuje plan i dopytuje. Ruszy do działania dopiero po akceptacji planu.
- Sformułuj prośbę możliwie precyzyjnie: powiedz, które wskaźniki cię interesują i jakiego efektu szukasz. Mgliste polecenie daje mglisty wynik — jakość wejścia decyduje o jakości wyjścia.
- Przejrzyj plan, który Codex przedstawi, i zaakceptuj go dopiero, gdy się zgadza. W rozmowie najtaniej się myli i poprawia.
- Gdy efekt jest dobry, zamień go w umiejętność (ang. skill) — zapisany przepis na to, jak zrobić to dobrze: „Zamień to, co właśnie zrobiłeś, w umiejętność, żeby za każdym razem powtórzyć ten sam proces”.
- Zdecyduj, gdzie trzymasz umiejętność: globalnie (działa w każdym projekcie) albo lokalnie (tylko w tym jednym) — wystarczy poprosić o jedno lub drugie.
- Traktuj każde użycie jako okazję, żeby dopracować przepis. Receptę można ulepszać, tak jak przepis kulinarny.
4. Zbuduj pulpit i opublikuj go w sieci
- Wskaż Codeksowi gotowy arkusz (możesz „otagować” konkretny plik) i poproś o pulpit (dashboard) — stronę z wykresami i wnioskami.
- Opcjonalnie poproś, żeby najpierw użył generatora obrazów i zaproponował wygląd oraz logo, zanim zbuduje resztę.
- Pozwól zadziałać pętli weryfikacji — Codex sam ogląda własną stronę, wyłapuje usterki i je poprawia, zanim odda wynik. Nie musisz pilnować każdego piksela.
- Pamiętaj o haczyku: powstała strona działa tylko lokalnie (adres zaczyna się od „localhost”). Wklejona znajomemu pokaże pustkę. Żeby otworzyć ją z telefonu albo komukolwiek pokazać, trzeba ją opublikować.
- Opublikuj projekt dwoma darmowymi na start narzędziami: GitHub (repozytorium, czyli zbiór twoich plików w chmurze) i Vercel (robi z kodu działający adres w internecie). Poproś: „Pomóż mi podłączyć ten projekt do GitHuba i opublikuj go”.
- Korzystaj z tego, że oba narzędzia rozmawiają ze sobą: zmiana wysłana na GitHub trafia automatycznie do wersji na Vercelu. Testuj zmiany lokalnie — do publicznej wersji trafią dopiero, gdy je zatwierdzisz.
5. Ustaw automatyzację i naucz się ją sprawdzać
- Otwórz w projekcie nowy czat i opisz automatyzację — zaplanowane zadanie, które Codex uruchamia sam, na przykład: „W każdą niedzielę o 17:00 uruchom umiejętność, odśwież dane i wyślij zmiany na stronę”. Prompt może brzmieć chaotycznie — Codex dopyta o brakujące szczegóły.
- Zajrzyj w ustawienia automatyzacji i wybierz właściwy model oraz poziom wysiłku. Domyślnie zadanie potrafi ustawić się na słabszy model i wtedy się ślimaczy albo gubi.
- Wiedz, że automatyzacja działa lokalnie — gdy wyłączysz komputer albo zamkniesz aplikację, przestaje chodzić. Żeby pracowała całą dobę, trzeba ją przenieść do chmury (osobny, dalszy krok).
- Nie oczekuj, że zadanie będzie idealne za pierwszym razem. Gdy coś się zatnie, zatrzymaj je, zapytaj „co się dzieje?”, rozwiąż drobiazg sam i jedź dalej. To oszczędza czas i tokeny.
- Użyj sterowania przeglądarką (ang. browser use): poproś Codeksa, żeby sam otworzył gotową stronę, poklikał po niej, spróbował ją „zepsuć” i zgłosił usterki. Przydaje się do testów własnych efektów i tam, gdzie dane trzeba ręcznie wyklikać.
- Wpisz test na stałe do umiejętności: „nie oddawaj mi wyniku, dopóki sam go nie sprawdzisz w przeglądarce”.
Na co uważać
- Nie zlecaj niczego, zanim nie założysz
AGENTS.md. Bez kontekstu w pliku wiedza modelu znika między rozmowami. - Klucz dostępowy wkłada się tylko do
.env. To hasło do twoich danych — nigdzie indziej. - Pełen dostęp to ryzyko, gdy nie rozumiesz narzędzia. Historie o agentach, które skasowały bazę albo rozesłały lawinę maili, to zwykle skutek mglistych instrukcji i zbyt wczesnego oddania pełnej kontroli.
- Mgliste polecenie = mglisty efekt. Większość pracy odbywa się w precyzji prośby, nie w sile modelu.
- „localhost” to nie publiczny adres. Strona działa tylko u ciebie, dopóki jej nie opublikujesz.
- Automatyzacja lubi domyślny słabszy model i działa tylko przy włączonym komputerze. Sprawdź oba ustawienia, zanim uznasz zadanie za gotowe.
Cały projekt to zwykły folder z plikami. Dzięki czytelnej strukturze może w nim pracować dowolne narzędzie agentowe — Codex, Claude Code czy inne — bo wszystkie czytają ten sam katalog. Pierwszy ruch jest banalny: wypisz nudne, powtarzalne czynności ze swojego tygodnia, wybierz jedną, zamień ją w umiejętność. Potem następną.