AI w programowaniu to dziś standard, ale nie każde narzędzie warto traktować tak samo. Codex działa zadaniowo, a nie linijkowo — i to faktycznie zmienia sposób pracy. W tym artykule przyglądamy się, jak działa, gdzie się sprawdza i kiedy trzeba zachować ostrożność.
Czym jest Codex?
Codex to narzędzie rozwijane przez OpenAI, zaprojektowane do pracy na poziomie całych repozytoriów i zadań, a nie pojedynczych fragmentów kodu. Jego głównym celem jest wykonanie jasno określonej pracy programistycznej w kontekście całego projektu. Kluczowa idea jest prosta: zamiast podpowiadać kolejne linijki, Codex dostaje zadanie i próbuje przygotować kompletne rozwiązanie, które można potem zreviewować. Programista nadal decyduje o kierunku i jakości, ale nie musi ręcznie przechodzić przez wszystkie techniczne kroki
Jak działa Codex?
Codex działa w modelu agentowym, co w praktyce oznacza, że nie reaguje na pojedyncze zapytania w oderwaniu od kontekstu, ale realizuje ciąg działań prowadzących do wykonania zadania. Każde polecenie uruchamia osobne, izolowane środowisko, w którym agent ma dostęp do repozytorium projektu oraz narzędzi potrzebnych do pracy z kodem.
Po otrzymaniu zadania Codex najpierw analizuje strukturę projektu: przegląda pliki, zależności, konfigurację oraz dostępne testy. Ten etap jest kluczowy, bo agent nie generuje kodu „w ciemno”, tylko próbuje zrozumieć, jak projekt jest zbudowany i gdzie zmiany powinny zostać wprowadzone. Dopiero na tej podstawie planuje kolejne kroki.
Następnie Codex wprowadza zmiany w kodzie. Nie musi to być jedna próba — jeśli projekt posiada testy, agent może je uruchomić i na podstawie wyników poprawiać swoje rozwiązanie. W praktyce przypomina to pracę developera, który implementuje funkcję, uruchamia testy, widzi błędy i iteruje dalej. Różnica polega na tym, że cały ten proces odbywa się automatycznie w ramach jednego zadania
Istotne jest również to, że Codex nie wprowadza zmian bezpośrednio do roboczej wersji projektu. Efektem jego pracy jest propozycja zmian, którą można poddać standardowemu code review. Z perspektywy zespołu oznacza to, że Codex wpisuje się w istniejący workflow, zamiast go omijać. Nadal obowiązują te same zasady dotyczące jakości, testów i odpowiedzialności za kod.
Czym różni się od Copilota i podobnych rozwiązań?
Różnica między Codexem a narzędziami typu Copilot nie polega na jakości generowanego kodu, ale na poziomie abstrakcji. Copilot wspiera pisanie kodu w trakcie pracy, reagując na to, co aktualnie znajduje się w edytorze.
Codex działa zadaniowo. Dostaje cel i próbuje go zrealizować w całości. W praktyce oba podejścia mogą się uzupełniać: jedno przydaje się przy codziennym kodowaniu, drugie wtedy, gdy chcemy zdjąć z siebie całe zadanie i wrócić do niego dopiero na etapie review.
Jakie zadania najlepiej nadają się dla Codex?
Codex nie jest rozwiązaniem uniwersalnym i dobrze jest to jasno powiedzieć. Najlepiej sprawdza się tam, gdzie zadanie jest jasno określone, ale jego realizacja wymaga czasu i przejścia przez większą część kodu.
Przykłady takich zadań to poprawki błędów rozrzuconych po kilku plikach, refaktoryzacje o jasno zdefiniowanym zakresie, implementacja funkcjonalności według specyfikacji czy dostosowywanie kodu do nowych testów. W takich przypadkach Codex potrafi znacząco skrócić czas potrzebny na przygotowanie pierwszej sensownej wersji rozwiązania.
Znacznie gorzej radzi sobie tam, gdzie problem jest nieprecyzyjny albo wymaga głębokiego zrozumienia kontekstu biznesowego. Codex nie podejmuje decyzji projektowych — on realizuje to, co zostało opisane. Jeśli opis jest słaby, efekt również będzie słaby.
Jakość kodu i wpływ na pracę programisty
Jednym z częstych pytań przy narzędziach agentowych jest to, czy nie prowadzą one do obniżenia jakości kodu. W praktyce Codex nie omija żadnych standardowych zabezpieczeń procesu. Kod przygotowany przez agenta nadal trafia do review, nadal powinien przechodzić testy i nadal ktoś z zespołu bierze za niego odpowiedzialność.
Różnica polega na tym, że review dotyczy pełnej propozycji rozwiązania, a nie fragmentów kodu tworzonych na bieżąco. Dla doświadczonych programistów oznacza to przesunięcie pracy z implementacji na ocenę i korektę. To często bardziej efektywne wykorzystanie czasu i kompetencji.
W praktyce zmienia to sposób pracy. Programista rzadziej skupia się na ręcznym wprowadzaniu zmian, a częściej na sprawdzaniu ich sensu, spójności i wpływu na całość projektu. Narzędzia takie jak Codex nie zdejmują odpowiedzialności za kod — przesuwają ją na etap, w którym doświadczenie zespołu ma największą wartość.
GPT-5.2-Codex – co się zmieniło?
Wersja GPT-5.2-Codex jest istotna nie dlatego, że nagle wszystko działa idealnie, ale dlatego, że pokazuje kierunek rozwoju Codex. Zgodnie z informacjami udostępnionymi przez OpenAI, nacisk położono na lepsze utrzymywanie kontekstu większych repozytoriów oraz bardziej stabilną iterację rozwiązań.
W praktyce GPT-5.2-Codex rzadziej gubi się w większych projektach, lepiej radzi sobie z poprawianiem własnych błędów i mniej skłania się do generowania kodu, który wygląda poprawnie, ale nie pasuje do reszty projektu. Różnice są szczególnie widoczne w zadaniach obejmujących wiele plików lub wymagających kilku rund poprawek.
To nadal narzędzie, które wymaga kontroli, ale jego zachowanie jest bardziej przewidywalne i spójne niż w poprzednich wersjach.
Czy to odpowiednie narzędzie do nauki programowania?
Codex może być pomocny w nauce programowania, ale tylko pod pewnymi warunkami. Jako narzędzie do wyjaśniania fragmentów kodu, pokazywania alternatywnych rozwiązań czy szybkiego sprawdzenia pomysłu — jak najbardziej. Problem zaczyna się wtedy, gdy staje się skrótem omijającym proces myślenia.
W nauce programowania kluczowe jest rozumienie, dlaczego coś działa, a nie tylko to, że działa. Narzędzia agentowe łatwo mogą zaburzyć ten proces, jeśli są używane bez refleksji. Dlatego Codex lepiej traktować jako wsparcie do analizy i weryfikacji, a nie jako narzędzie do „robienia zadań za uczącego się”. Tak jak zawsze powtarzam – bez solidnych podstaw AI szybko staje się protezą zamiast pomocy. 🤷
Codex a C++
C++ ma tę przypadłość, że jest dużo starego i brzydkiego kodu na którym były trenowane powszechnie dostępne modele. A jak wiadomo – garbage in, garbage out. Kod wygenerowany przez różne modele, w tym Codex zazwyczaj będzie miał sens, gdy się go czyta, ale gdy spróbujemy go odpalić, szczególnie na jakichś mniej popularnych platformach z procesorami ARM, jak MacOs, NVIDIA Jetson, to szybko możemy natrafić na problemy z pamięcią, których za pomocą AI’a nie będziemy w stanie przeskoczyć. A przynajmniej mnie się to nigdy nie udało.
Specyficzne platformy, specyficzny proces budowania i uruchamiania (np. na zdalnej maszynie, czy w dockerze) powodują, że podejście agentowe nie daje pełni swoich możliwości. Codex może wygenerować kod, ale nie zweryfikuje, czy działa on poprawnie. To mocno ogranicza jego funkcjonalność.
I tu niestety nie mam dobrych wiadomości: tego nie da się zpromptować. Trzeba to po prostu umieć.
Na szczęście są miejsca, gdzie można się tego nauczyć 🥷
https://coders.school/
