Jeden z najciekawszych wzorców pracy, jakie zauważyłem w Codex Plus, ma mniej wspólnego z samym pisaniem promptów, a więcej z odpowiednim wyczuciem momentu.
Kiedy zostaje mi ostatnie 3–5% mojego limitu 5-godzinnego albo tygodniowego, nie przeznaczam już tej końcówki na małe polecenia. Robię dokładnie odwrotnie. Wykorzystuję pozostały budżet do uruchamiania największych zadań inżynieryjnych na kilku projektach, które mam wcześniej przygotowane.
Zwykle chodzi o takie rzeczy jak pełne migracje do TypeScript, porządki z ESLint w całym repozytorium, głębokie przeglądy błędów w całych codebase’ach albo duże refaktoryzacje, które normalnie wydawałyby się zbyt kosztowne, by uruchamiać je bez większego namysłu.
Co zmieniło mój workflow
Powód jest prosty: więcej niż raz widziałem, że Codex pracuje dalej nawet wtedy, gdy widoczny limit wygląda już na wyczerpany. Z zewnątrz sesja wydaje się zakończona, ale zadanie nadal posuwa się naprzód, a czasem po prostu kończy się do końca.
Nie przedstawiam tego jako gwarantowanej zasady działania produktu. Opisuję jedynie powtarzające się doświadczenie, które było na tyle wyraźne, że zmieniło mój sposób używania narzędzia. Od kiedy zauważyłem ten wzorzec, ostatnie kilka procent przestało być czymś, co trzeba oszczędzać. Zaczęło wyglądać jak najlepszy moment na uruchomienie najdroższej i najbardziej opłacalnej pracy.
Jak teraz używam tej końcówki limitu
Zamiast wydawać resztę limitu na bezpieczne i tanie prompty, traktuję ją dziś jako okno startowe dla ciężkich operacji inżynieryjnych, takich jak:
- pełne migracje do TypeScript
- porządki z ESLint w całym repozytorium
- głębokie przeglądy błędów w dużych codebase’ach
- duże refaktoryzacje strukturalne
Kluczowe jest przygotowanie. Ten sposób pracy ma największy sens wtedy, gdy projekt jest już gotowy do uruchomienia, a zadanie zostało jasno zdefiniowane. W takim momencie zużywanie reszty na coś małego często wydaje się marnowaniem chwili o najwyższej wartości.
Dlaczego wydaje mi się to ważne
Narzędzia takie jak Codex Plus to nie tylko kwestia czystych możliwości. Liczy się też to, jak rozkłada się wysiłek w czasie. Niewielka zmiana w timingu potrafi znacząco zmienić praktyczną wartość, jaką wyciąga się z tego samego limitu.
W moim przypadku zmieniło to nawet psychologię korzystania z produktu. Ostatnie kilka procent nie wygląda już jak koniec sesji. To raczej moment, w którym przestaję się wahać i przekazuję narzędziu najcięższe zadanie, jakie ma sens uruchomić.
Czasami mam wręcz wrażenie, że Codex dalej pracuje za mnie nawet po zniknięciu widocznego limitu. Nie wiem, czy to celowy przypadek brzegowy, czy po prostu sposób, w jaki niektóre zadania kończą się w praktyce. Wiem tylko, że było to na tyle przydatne, że dziś planuję wokół tego swój workflow.
Praktyczna obserwacja dla programistów
Jeśli używasz Codex Plus do inżynierii oprogramowania, warto sprawdzić własny sposób pracy pod koniec limitu zamiast zakładać, że ostatnie kilka procent trzeba wydawać wyjątkowo ostrożnie. W moim przypadku skuteczniejsze okazało się dokładnie odwrotne podejście.
Jestem bardzo ciekaw, czy inni programiści zauważyli ten sam wzorzec, szczególnie przy migracjach, porządkach lint, dużych przeglądach albo szerokich refaktoryzacjach obejmujących wiele repozytoriów.