Planuj w ChatGPT Pro, wykonuj w Codex: Playbook przekazywania dokumentu projektowego

Workflow, który warto ukraść w tym miesiącu, to nie model, lecz podział pracy. Przekazujesz GPT-6 Pro w ChatGPT adres URL repozytorium, prosisz go o dokument projektowy, a nie patch, i przekazujesz ten dokument Codex lub Claude Code do zaimplementowania. Planista działa na GPT-6 Astra — GPT-6 Pro to nazwa, której limity użycia ChatGPT używają na określenie tego modelu — a Astra to model z 2026-09-03, więc nic tutaj nie jest relacją z premiery ani twierdzeniem o wydaniu. To, co zmieniło się w ciągu ostatnich siedmiu dni, jest węższe i warte dokładnego przytoczenia: 2026-09-17 praktycy zgłosili, że oficjalna wtyczka GitHub w zwykłym ChatGPT Chat, nie w ChatGPT Work i nie w Codex, może edytować pliki repozytorium, tworzyć commity i otwierać pull requesty bez pobierania z limitu Codex/Work. To twierdzenie społeczności, a nie dokumentacja dostawcy — oficjalne strony pomocy wciąż opisują aplikację GitHub jako tylko do odczytu i kierują całe zapisywanie przez Codex — a zastrzeżenia do niego mają równie duże znaczenie jak samo twierdzenie. Wszystko poniżej jest oznaczone jako zgłoszone przez dostawcę, zgłoszone przez społeczność lub odczytane z oficjalnych stron 2026-09-19.

Przepływ pracy, w jednym przebiegu

Praktycy opisują tę samą pętlę z drobnymi odmianami. Powtarza się jedna: wklej adres GitHub do ChatGPT, poproś, aby przeczytał kod i utworzył dokument projektowy, następnie pobierz ten dokument i podaj go wykonującemu agentowi. Niektórzy proszą dodatkowo o pull request; inni zatrzymują się na dokumencie i pozwalają wykonawcy zająć się pisaniem. Tak czy inaczej kształt jest identyczny — planowanie w produkcie czatowym, budowanie w produkcie agentowym — a powód, dla którego warto to kopiować, jest taki, że obie połowy są rozliczane osobno.

• Artefakt planowania — dokument projektowy: interfejsy do dodania, pliki do zmiany wskazane ścieżką, kolejność migracji, testy akceptacyjne i co zrobić, jeśli pójdzie źle.

• Artefakt wykonania — gałąź i pull request, wytworzone przez agenta, który potrafi uruchomić testy, które właśnie napisał.

• Artefakt przeglądu — diff, który jako jedyny powinien kiedykolwiek trafiać do recenzenta.

Dokument projektowy jest elementem nośnym i zasługuje na swoje miejsce z dwóch powodów. Po pierwsze, dokument jest przenośny: ten sam tekst działa niezależnie od tego, czy wykonawcą jest Codex, Claude Code, czy napisany przez ciebie agent skryptowy, więc planowanie, za które zapłaciłeś, nie jest przywiązane do narzędzia jednego dostawcy. Po drugie, to powierzchnia przeglądu, która istnieje zanim cokolwiek zostanie zapisane w twoim repozytorium — co ma ogromne znaczenie, biorąc pod uwagę, że ścieżka zapisu w produkcie czatu jest najsłabiej udokumentowaną częścią całego rozwiązania.

Dlaczego struktura dwóch kubełków to cała sztuczka

ChatGPT nie rozlicza tego workflow z jednej puli. Czat, ChatGPT Work i Codex mają osobne limity, przy czym Work i Codex dzielą między sobą jedną wspólną pulę; klucz API OpenAI to z kolei osobne rozliczenie. To właśnie ta struktura sprawia, że przekazanie zadania jest opłacalne: myślenie odbywa się w puli Czatu, działanie w puli agenta, a dokument projektowy kosztuje jedną wiadomość Czatu, podczas gdy implementacja zużywa limit agenta.

Liczby, takie jak publikuje je OpenAI dla strony Chat — dane liczbowe podane przez dostawcę w jego własnej dokumentacji planu, a nie pomiary:

• ChatGPT Pro za 200 dolarów miesięcznie — 200 wiadomości GPT-6 Pro tygodniowo; GPT-5.6 Sol Pro dodatkowo oferuje 170 dziennie, przy czym oba modele razem mają limit 200 dziennie.

• ChatGPT Pro za 100 dolarów miesięcznie — 50 wiadomości GPT-6 Pro tygodniowo, czerpanych z limitu współdzielonego z GPT-5.6 Sol Pro.

• Business Standard — 15 wiadomości GPT-6 Pro miesięcznie, współdzielonych z Sol Pro; Business Premium — 50 wiadomości tygodniowo na tej samej zasadzie współdzielenia.

• ChatGPT Plus — w Chat w ogóle nie ma GPT-6 Pro. Astra osiąga Plus tylko poprzez ChatGPT Work i Codex, czyli dokładnie ten segment, który ten playbook stara się chronić.

Po stronie Work/Codex OpenAI publikuje szacunki, a nie limity, i mówi o tym wprost: około od 5 do 45 wiadomości Astra na pięciogodzinne okno w planie Plus, od 25 do 225 w Pro 5x i od 100 do 900 w Pro 20x, a ta sama strona zaznacza, że rzeczywiste zużycie zależy od złożoności zadania, kontekstu, danych wyjściowych i użycia narzędzi oraz że mogą dodatkowo obowiązywać limity tygodniowe. Te przedziały wynoszą około połowy odpowiednich liczb dla Sol, co jest arytmetycznym powodem, dla którego uruchamianie modelu typu frontier jako agenta jest w ogóle opłacalne.

Praktyczną konsekwencją jest reguła budżetowania, którą można zapisać na kartce. Wiadomości Chat przeznaczaj na decyzje, a użycie agenta na kod. Sesja planowania, w której przez dwadzieścia minut spiera się o interfejs, kosztuje garść wiadomości Chat i tworzy dokument, który oszczędza agentowi godzinę eksploracyjnych edycji — i właśnie takiej wymiany praktycy w tym wątku faktycznie dokonują.

Ścieżka zapisu: co robi konektor i co ludzie twierdzą, że robi

Tu źródła się nie zgadzają, a właśnie ta rozbieżność jest najciekawsza.

Dokumentacja pomocy samego OpenAI jest jednoznaczna: aplikacja GitHub w ChatGPT odczytuje Twoje repozytoria w celu analizy i wyszukiwania, a generowanie kodu, jego edytowanie i wypychanie go do GitHuba to zadanie dla Codeksa. To stanowisko zakładające tylko odczyt i to na nim należy się opierać, jeśli wprowadzasz to do procesu zespołowego, ponieważ to ono ma za sobą dostawcę.

Stanowisko społeczności z dnia 2026-09-17 jest takie, że wtyczka GitHub w wersji webowej w trybie Chat będzie edytować kod, tworzyć commity i otwierać pull requesty, a ponieważ jest to oficjalna wtyczka, a nie serwer MCP strony trzeciej, nie zużywa limitu Codex ani Work. Ten sam wątek zachowuje ostrożność co do zakresu: małe narzędzia, drobne zmiany, małe błędy — duże refaktoryzacje i trudne debugowanie nadal należą do Codex. Jego własni komentatorzy dodają zastrzeżenia warte powtórzenia, ponieważ to właśnie one dają się we znaki:

• Normalne limity ChatGPT nadal obowiązują. „To nie limit Codex” nie znaczy „za darmo”.

• Jakość może się pogorszyć po kilku rundach bez ostrzeżenia, a sesja może w trakcie zadania przełączyć się na mniejszy model.

• Autorzy wątku radzą nie przełączać się na Work, gdy interfejs to oferuje, i ostrzegają, że zalewanie anonimowych stron czatu żądaniami psuje wszystkim korzystanie z sieci.

Niezależny japoński opis tego samego wzorca prowadzi do zgodnego wniosku, ale bez twierdzenia o limicie: jeśli integracja z GitHubem obsługuje akcje zapisu, zwykły czat może odczytać repozytorium, zmodyfikować pliki, utworzyć gałąź i otworzyć pull request; obowiązują zwykłe limity szybkości czatu; a Codex i Work korzystają ze współdzielonej puli agentów, więc zwykły czat służy do edycji kilku plików, a Codex do długich zadań programistycznych. Tam, gdzie oba opisy są zgodne, zgodność jest częścią użytkową: czat to kanał drobnych zmian, Codex to kanał długich sesji, a pule są osobne.

Istnieją serwery MCP firm trzecich, które udostępniają prawdziwy przepływ pracy git — branch, diff, commit, push, otwarcie pull requesta — z uprawnieniami, które możesz stopniować od tylko do odczytu aż po push. Jeśli chcesz, aby ścieżka zapisu była deterministyczna i audytowalna, a nie zachowaniem, na które liczysz, to jest właśnie ta droga; jeśli chcesz pozostać w granicach tego, co dokumentuje OpenAI, planuj w Chat i pisz w Codex.

Tak czy inaczej, to właśnie przekazanie dokumentu projektowego sprawia, że ścieżka zapisu w czacie jest możliwa do obrony. Sesja czatu z zakresem zapisu w repozytorium to większe przyznanie uprawnień niż sesja czatu z zakresem odczytu, a dokument jest artefaktem, który przeglądasz, zanim to uprawnienie zostanie wykorzystane.

Przekazanie, krok po kroku

• Wskaż planerowi repozytorium — publiczny adres URL wklejony do promptu albo konektor GitHub, jeśli został przez Ciebie autoryzowany — i poproś, aby przeczytał kod, zanim cokolwiek zaproponuje.

• Poproś o dokument projektowy, a nie o patch. Wymagaj ścieżek plików, interfejsów, które są dodawane lub zmieniane, kolejności, w jakiej zmiany muszą być wprowadzane, oraz testów, które potwierdzają każdy krok.

• Poproś je o zacytowanie plików, które faktycznie przeczytało. Dokument projektowy opisujący interfejs, którego nie ma w repozytorium, to najczęstszy powód, dla którego ten workflow zawodzi — a cytaty pozwalają wychwycić to w minutę, a nie w ciągu całego sprintu.

• Zapisz dokument w repozytorium, zamiast wklejać go do następnego narzędzia. Wykonawca, który czyta plik, może odczytać go ponownie; wykonawca, który otrzymał wklejony tekst, ma tylko jedną szansę.

• Uruchom executor, przekazując mu dokument jako instrukcję, i ogranicz zakres jednego pull requesta do jednej jego sekcji. To w długich sesjach jakość agenta po cichu się pogarsza.

• Następnie utrzymuj planistę w roli wyłącznie recenzenta. Gdy dokument jest błędny, zaplanuj ponownie i zaktualizuj dokument — nie pozwól wykonawcy improwizować z jego pominięciem, ponieważ praca improwizowana jest tym, czemu dokument miał zapobiegać.

Gdzie to się psuje

• Nieaktualny stan repozytorium — planner odczytał domyślną gałąź, podczas gdy Ty pracujesz na gałęzi funkcyjnej, więc ścieżki plików w dokumencie są o jedną wersję do tyłu. Wskaż, którą gałąź odczytać, albo wklej drzewo gałęzi.

• Dryf dokumentu projektowego — dokument i kod się nie zgadzają, a wykonawca podąża za dokumentem. Wspomniany powyżej krok z cytowanymi plikami to tanie zabezpieczenie.

• Zaskoczenie limitem w złym kierunku — dwudziestominutowa rozmowa planistyczna jest tania pod względem wiadomości w Chat i kosztowna pod względem uwagi; długie uruchomienie agenta to odwrotność. Budżetuj pulę, z której faktycznie wydajesz.

• Cicha degradacja — sesja czatu, która po kilku rundach przechodzi na mniejszy model, wciąż wygeneruje dokument projektowy brzmiący pewnie. Oceń dokument merytorycznie, a nie w oparciu o założenie, że napisał go model flagowy.

• Rozszerzanie uprawnień — ścieżka zapisu, niezależnie od tego, czy prowadzi przez wtyczkę, czy przez serwer MCP, daje sesji czatu możliwość zmiany Twojego kodu. Stopniuj uprawnienia i odbieraj je, gdy zmiana zostanie wprowadzona.

Uruchamianie połowy executora przez jeden endpoint

Połowa tego workflow odpowiadająca za planowanie żyje w produkcie subskrypcyjnym i ta część jest taka, jaka jest. Połowa wykonawcza to wywołanie API i to jest ta połowa, którą warto mieć na własność. Jeśli oskryptujesz executor — małą pętlę agenta, zadanie CI, które zamienia zatwierdzony dokument projektowy w gałąź — wywołanie modelu jest jedynym elementem, który musi być podmienialny, ponieważ model, którego będziesz chciał w następnym kwartale, to nie model, wokół którego planujesz dzisiaj.

Po to właśnie jest warstwa routingu. openai/gpt-6-astraznajduje się za tym samym punktem końcowym zgodnym z OpenAI coponad 200 innych modeli, przy czym cena katalogowa dostawcy jest przekazywana przy 0% marży — więc gdy dostawca zmienia cenę, cena po naszej stronie zmienia się tego samego dnia, a nie dopiero przy kolejnym odnowieniu umowy. Automatyczne przełączanie awaryjne pozwala umieścić nieprzetestowany model na części ruchu, mając pod spodem sprawdzony model, co jest uczciwym sposobem sprawdzenia, czy tani model wykonawczy jest wystarczająco dobry do twoich testów. A DSL routingu łączy kilka modeli w jedno wywołanie, dzięki czemu model recenzujący może sprawdzić diff modelu wykonawczego na tym samym kluczu, w tej samej ścieżce żądania, bez drugiej integracji.

Nic z tego nie zmienia struktury przekazania. Zmienia to koszt eksperymentowania z tą połową, którą kontrolujesz: jeden klucz, jeden endpoint i ciąg modelu, który możesz zmienić bez dotykania pipeline'u.

Kto powinien teraz to uruchomić, a kto powinien poczekać?

Jeśli już płacisz za plan ChatGPT w wariancie Pro i już używasz Codex lub Claude Code, ten sposób przekazywania warto wdrożyć w tym tygodniu, ponieważ te dwie pozycje są już rozdzielone na Twoim rachunku, a dokument projektowy jest najtańszym elementem w całym cyklu. Zacznij od zmiany, którą rozumiesz na tyle dobrze, by wychwycić zły plan: poproś o dokument, przeczytaj cytowane pliki, a potem przekaż go dalej.

Jeśli korzystasz z Plus, ostudź oczekiwania. Astra jest dla Ciebie dostępna przez Work i Codex, ale nie przez Chat, więc połowa tego playbooka dotycząca planowania nie jest dostępna w opisanej formie — planowałbyś i realizował z tej samej puli, co usuwa argument ekonomiczny i pozostawia jedynie dyscyplinę najpierw spisania dokumentu. Ta dyscyplina wciąż jest warta zachowania. Zniżka już nie.

A jeśli powodem, dla którego tego chcesz, jest ścieżka zapisu w czacie, a nie przekazanie, poczekaj, aż dokumentacja OpenAI dogoni wątek na forum. Możliwość, której przeczą własne strony pomocy dostawcy, należy trzymać w repozytorium roboczym, dopóki strony się nie zmienią.

Ten sam klucz daje dostęp do reszty katalogu, a Ty możesz przeglądać pełny katalog modeli, aby zobaczyć, co jeszcze kryje się za jednym punktem końcowym kompatybilnym z OpenAI.