OpenAI Codex

OpenAI Codex: kilka zadań programistycznych naraz, każde sprawdzone przed scaleniem

OpenAI Codex to agent programistyczny firmy OpenAI. Zleca mu się konkretne zadanie – naprawę błędu, nową funkcję, aktualizację zależności albo przegląd zmian – a agent czyta kod, wprowadza poprawki, uruchamia polecenia i przygotowuje wynik do sprawdzenia. Może pracować lokalnie, na komputerze programisty, albo w chmurze, gdzie każde zadanie dostaje osobne, izolowane środowisko i toczy się dalej także wtedy, gdy komputer jest uśpiony.

W G2 TEAM sięgamy po Codex, gdy zadań jest kilka i są od siebie niezależne, a także wtedy, gdy przed scaleniem zmian chcemy dodatkowej, automatycznej recenzji. Agent nie zastępuje przy tym programisty – skraca pisanie kodu, a decyzje i odpowiedzialność zostają po stronie zespołu.

Jak działa Codex

Codex działa w kilku miejscach:

• Codex CLI – wersja dla terminala (wiersza poleceń) na macOS, Linuksa i Windows. Jej kod jest otwarty (open source) i dostępny na GitHubie. Polecenie codex exec uruchamia agenta w skryptach, np. w potoku CI, czyli automatycznym budowaniu i testowaniu kodu po każdej zmianie.
• Rozszerzenie do edytorów kodu (IDE) – dla VS Code i edytorów z nim zgodnych, m.in. Cursora i Windsurfa; Xcode i środowiska JetBrains mają własne integracje z Codexem.
• Aplikacja desktopowa ChatGPT – Codex jako osobny tryb pracy, w którym można prowadzić kilka zadań równolegle.
• Codex Cloud – zadania w chmurze, zlecane z przeglądarki, aplikacji mobilnej lub desktopowej. Przy tworzeniu środowiska Codex pobiera wskazane repozytoria z GitHuba, instaluje zależności i narzędzia, a zespół zatwierdza konfigurację. Wynik można przejrzeć, poprawić i zamienić w pull request – propozycję zmian do przeglądu przed scaleniem z główną wersją kodu.

Na GitHubie Codex recenzuje pull requesty – na żądanie, po komentarzu @codex review, albo automatycznie – i publikuje uwagi skupione na poważnych problemach. Recenzja merge requestów (odpowiednika pull requestów na GitLabie) jest w wersji beta. Zadania można też przekazać ze Slacka albo z systemu zgłoszeń Linear. Instrukcje dla agenta zapisuje się w pliku AGENTS.md: Codex czyta go przed rozpoczęciem pracy, łącząc ustawienia ogólne z zasadami konkretnego repozytorium i jego podkatalogów.

Co zyskuje klient

Codex skraca przede wszystkim czas między zgłoszeniem a zmianą gotową do przeglądu. Drobne poprawki, aktualizacje bibliotek, testy do istniejących modułów czy porządki w kodzie mogą toczyć się równolegle, każde w osobnym środowisku. Programista sprawdza wyniki i odrzuca te, które nie spełniają wymagań. Przy refaktoryzacji (porządkowaniu struktury kodu przy zachowaniu tego, jak działa) i migracjach agent wykonuje mechaniczną część pracy w wielu plikach, a człowiek ocenia, czy całość jest spójna.

Druga korzyść to dodatkowa kontrola. Recenzja Codexa może wskazać błąd logiczny albo pominięty przypadek, zanim zmiana trafi do wersji testowej. Agent przygotowuje też dokumentację: opis struktury repozytorium, listę ryzykownych miejsc w kodzie, notatki do wydania.

Zadania dla agenta opisujemy precyzyjnie, a ustalenia projektu zapisujemy w repozytorium, żeby wynik od początku odpowiadał oczekiwaniom. Przy projektach prowadzonych na GitLabie Codex pracuje lokalnie. Architekturę systemu, model danych i zabezpieczenia projektuje programista. O łączeniu pracy agentów z budową systemów na zamówienie więcej piszemy przy usłudze aplikacje webowe i portale.

Jak pracujemy z Codexem w G2 TEAM

Zadanie dla agenta opisujemy jak dla członka zespołu: z zakresem, plikami, których dotyczy, i warunkiem zakończenia, np. „wszystkie testy przechodzą”. Konwencje projektu zapisujemy w AGENTS.md w repozytorium Git, w którym trzymamy kod i dokumentację klienta. Lokalnie agent ma domyślnie zapis tylko w katalogu projektu i nie łączy się z siecią, a szersze uprawnienia dostaje tylko na czas konkretnego polecenia. Hasła i klucze dostępowe wpisuje człowiek, nie agent.

Wynik pracy Codexa przechodzi tę samą ścieżkę co kod pisany ręcznie: osobna gałąź (branch), czyli równoległa wersja kodu, pull request, testy automatyczne, recenzja programisty i dopiero potem scalenie. W projektach prowadzonych na GitHubie automatyczna recenzja Codexa jest dla nas wstępną kontrolą, a nie zatwierdzeniem. Środowiskom w chmurze dajemy dostęp tylko do potrzebnych domen i nie przekazujemy im danych dostępowych do systemów produkcyjnych klienta ani kopii baz z danymi osobowymi.

Codex a inne narzędzia agentowe

Wszystkie trzy narzędzia agentowe, z których korzystamy, czytają i zmieniają kod, ale różnią się miejscem i sposobem pracy agenta. Szczegóły opisujemy na stronach Claude Code i Google Antigravity.

Bezpieczeństwo i poufność kodu

Lokalna praca Codexa opiera się na dwóch warstwach. Piaskownica (sandbox) określa, co agent może technicznie zrobić: gdzie zapisywać pliki i czy łączyć się z siecią. Polityka zatwierdzeń (approval policy) decyduje, kiedy musi się zatrzymać i zapytać. Piaskownicę egzekwują mechanizmy systemu operacyjnego – na macOS Seatbelt, na Linuksie bubblewrap, a w Windows natywna piaskownica Codexa.

• Domyślnie agent nie ma dostępu do sieci, a zapisywać może tylko w katalogu projektu i katalogach tymczasowych.
• W ustawieniu Auto, zalecanym dla katalogów pod kontrolą Gita, agent sam wykonuje edycje i polecenia w obrębie projektu, ale prosi o zgodę na zmiany poza projektem i polecenia wymagające sieci. Do samej analizy kodu można go przełączyć w tryb tylko do odczytu.
• Katalog .git, w którym Git przechowuje historię zmian, oraz katalog konfiguracji Codexa są chronione przed zapisem, nawet gdy agent może edytować resztę projektu.
• Tryb pełnego dostępu, bez piaskownicy i bez pytań, OpenAI opisuje jako niezalecany; ma on sens tylko w odizolowanym kontenerze i przy zaufanych repozytoriach.
• Wyszukiwanie w internecie domyślnie korzysta z indeksu wyników przygotowanego przez OpenAI zamiast pobierać strony na żywo. Ogranicza to ryzyko prompt injection, czyli ukrytych w treści strony poleceń, które mogłyby zmienić zachowanie agenta.

W chmurze każde zadanie dostaje własne, izolowane środowisko. Dostęp do internetu trzeba w nim włączyć, a domeny można ograniczyć do listy dozwolonych. Dane dostępowe do usług zewnętrznych można przekazać jako sekrety sieciowe (network secrets): programy w środowisku widzą tylko ciąg zastępczy, a prawdziwą wartość podstawia serwer pośredniczący, i to wyłącznie przy połączeniach z dozwolonymi domenami.

W planach ChatGPT Business i Enterprise oraz przy API OpenAI domyślnie nie trenuje modeli na danych firmowych, a plan Enterprise daje też ustawienia przechowywania i lokalizacji danych. W planach indywidualnych ta zasada nie obowiązuje domyślnie – dlatego przy kodzie klientów korzystamy z kont firmowych.

Pytania i odpowiedzi

Czy przy Codexie programista jest jeszcze potrzebny?

Tak. Codex wykonuje zadania, które ktoś musi dobrze opisać, a potem ocenić. Programista projektuje architekturę, dzieli pracę na zadania, przegląda każdą zmianę i odpowiada za to, co trafia do klienta.

Czy Codex dostaje dostęp do wszystkich naszych repozytoriów?

Nie musi. Środowisko w chmurze obejmuje repozytoria wybrane przy jego tworzeniu, a wersja lokalna pracuje w katalogu, w którym ją uruchomiono.

Czy to obniża koszt projektu?

W części prac tak: zlecenie może wyjść nawet o 50% taniej – w pracach, które agenci realnie przyspieszają, takich jak powtarzalne zmiany, testy czy aktualizacje zależności. Analiza wymagań, projektowanie i odbiór zajmują tyle czasu co dawniej, dlatego oszczędność liczymy dla konkretnego zakresu.

Zacznijmy od rozmowy

Masz system, który trzeba rozwinąć, uporządkować albo przenieść na nowszą technologię? Opisz go w formularzu „Zapytaj o ofertę” poniżej. Mamy za sobą ponad 400 realizacji i powiemy otwarcie, które etapy Twojego projektu przyspieszy praca z agentami, a które nie.