Inżynieria infrastruktury: wykorzystanie Codex w świecie agentów

W ciągu ostatnich pięciu miesięcy nasz zespół przeprowadził eksperyment: stworzył i wprowadził na rynek wewnętrzną wersję beta oprogramowania, które nie zawierało ani jednego wiersza ręcznie napisanego kodu.

Produkt jest używany codziennie przez pracowników firmy oraz zewnętrznych testerów wersji alfa. Jest wdrażany, uruchamiany, ulega awarii i jest naprawiany. Różnica polega na tym, że każdy wiersz kodu – logika aplikacji, testy, konfiguracja CI, dokumentacja, obserwowalność i narzędzia wewnętrzne – został napisany przez Codex. Szacujemy, że stworzyliśmy to w około 1/10 czasu, jaki zajęłoby napisanie kodu ręcznie.

Ludzie kierują. Agenci wykonują polecenia.

Celowo wybraliśmy to ograniczenie, aby stworzyć coś, co pozwoliłoby nam przyspieszyć tempo prac inżynieryjnych o całe rzędy wielkości. Mieliśmy kilka tygodni na dostarczenie produktu, który ostatecznie składał się z miliona wierszy kodu. Aby to osiągnąć, musieliśmy zrozumieć, co się zmienia, gdy głównym zadaniem zespołu inżynierów oprogramowania nie jest już pisanie kodu, ale projektowanie środowisk, określanie intencji i tworzenie pętli sprzężenia zwrotnego, które pozwalają agentom Codex wykonywać swoją pracę w niezawodny sposób.

Ten artykuł opowiada o tym, czego nauczyliśmy się podczas tworzenia zupełnie nowego produktu wraz z zespołem agentów – co się nie udało, co się nakładało i jak maksymalnie wykorzystać wasz jedyny naprawdę ograniczony zasób: czas i uwagę ludzi.

Pierwsze zatwierdzenie do pustego repozytorium miało miejsce pod koniec sierpnia 2025 roku.

Początkowa struktura repozytorium, konfiguracja CI, reguły formatowania, konfiguracja menedżera pakietów i framework aplikacji zostały wygenerowane przez Codex CLI przy użyciu GPT‑5, w oparciu o niewielki zestaw istniejących szablonów. Nawet początkowy plik AGENTS.md, który określa, jak agenci mają pracować w repozytorium, został napisany przez Codex.

Nie istniał żaden wcześniej napisany przez człowieka kod, który mógłby stanowić podstawę systemu. Od samego początku repozytorium było kreowane przez agenta.

Pięć miesięcy później repozytorium zawiera około miliona wierszy kodu obejmującego logikę aplikacji, infrastrukturę, narzędzia, dokumentację i wewnętrzne narzędzia programistyczne. W tym okresie otwarto około 1500 żądań pull request, które zostały połączone przez niewielki zespół składający się zaledwie z trzech inżynierów zarządzających pracą Codex. Oznacza to średnią przepustowość na poziomie 3,5 PRs na inżyniera dziennie i, co zaskakujące, przepustowość ta wzrosła wraz z rozwojem zespołu, który obecnie liczy siedmiu inżynierów. Co ważne, nie było to tworzenie produktu dla samego tworzenia: produkt był używany przez setki użytkowników wewnętrznych, w tym codziennych użytkowników zaawansowanych.

W trakcie całego procesu tworzenia ludzie nigdy nie wnosili bezpośredniego wkładu w postaci kodu. To stało się kluczową filozofią zespołu: zero ręcznie pisanego kodu.

Brak praktycznego kodowania przez ludzi narzucił inny rodzaj pracy inżynierskiej, skupiony na systemach, szkieletach i wykorzystaniu.

Początkowe postępy były wolniejsze niż oczekiwaliśmy, nie z powodu braku możliwości Codex, ale z powodu niedostatecznie określonego środowiska. Agentowi brakowało narzędzi, abstrakcji i wewnętrznej struktury niezbędnych do osiągnięcia zaawansowanych celów. Głównym zadaniem naszego zespołu inżynierów stało się umożliwienie wam wykonywania użytecznej pracy.

W praktyce oznaczało to pracę w głąb: dzielenie większych celów na mniejsze elementy składowe (projekt, kod, przegląd, test itp.), wysyłanie poleceń do agenta w celu skonstruowania tych elementów i wykorzystanie ich do odblokowania bardziej złożonych zadań. Kiedy coś się nie udawało, rozwiązanie prawie nigdy nie polegało na „większym wysiłku”. Jedynym sposobem na osiągnięcie postępów było powierzenie tej pracy modelowi Codex, dlatego inżynierowie zawsze wkraczali i pytali: „jakich możliwości brakuje i jak sprawić, by były one zrozumiałe i możliwe do wykonania przez agenta?”.

Ludzie wchodzą w interakcję z systemem prawie wyłącznie za pomocą poleceń: inżynier opisuje zadanie, uruchamia agenta i pozwala mu otworzyć pull request. Aby doprowadzić PR do końca, instruujemy Codex, aby lokalnie sprawdzał wasze zmiany, prosił o dodatkowe konkretne recenzje agentów zarówno lokalnie, jak i w chmurze, odpowiadał na wszelkie opinie przekazane przez ludzi lub agentów i powtarzał tę procedurę w pętli, aż wszyscy recenzenci będą zadowoleni (w praktyce jest to pętla Ralpha Wigguma⁠(otwiera nowe okno)). Codex wykorzystuje bezpośrednio nasze standardowe narzędzia programistyczne (gh, lokalne skrypty i umiejętności wbudowane w repozytorium) do gromadzenia kontekstu bez konieczności kopiowania i wklejania przez ludzi do CLI.

Ludzie mogą przeglądać żądania pull request, ale nie ma takiego obowiązku. Z biegiem czasu prawie wszystkie działania związane z recenzowaniem zostały przeniesione do obsługi między agentami.

Wraz ze wzrostem przepustowości kodu, waszym wąskim gardłem stała się wydajność pracowników zajmujących się kontrolą jakości. Ponieważ ograniczeniem był czas i uwaga ludzi, staraliśmy się rozszerzyć możliwości agenta, sprawiając, że takie elementy jak interfejs użytkownika aplikacji, logi i same wskaźniki aplikacji są bezpośrednio czytelne dla Codex.

Na przykład sprawiliśmy, że aplikacja może być uruchamiana dla każdego drzewa roboczego git, dzięki czemu Codex może uruchamiać i obsługiwać jedną instancję dla każdej zmiany. Podłączyliśmy również protokół Chrome DevTools do środowiska uruchomieniowego agenta i stworzyliśmy funkcje umożliwiające pracę z migawkami DOM, zrzutami ekranu i nawigacją. Dzięki temu Codex mógł odtworzyć błędy, zweryfikować poprawki i bezpośrednio przeanalizować zachowanie interfejsu użytkownika.

To samo zrobiliśmy w przypadku narzędzi do obserwowalności. Logi, metryki i ślady są udostępniane w Codex za pośrednictwem lokalnego stosu obserwowalności, który jest efemeryczny dla danego drzewa roboczego. Codex działa w całkowicie izolowanej wersji tej aplikacji – łącznie z jej logami i metrykami, które są usuwane po zakończeniu zadania. Agenci mogą przeszukiwać logi za pomocą LogQL i metryki za pomocą PromQL. W tym kontekście łatwiej jest zrealizować polecenia takie jak „zapewnij, aby uruchomienie usługi trwało mniej niż 800 ms” lub „żaden z czterech krytycznych etapów podróży użytkownika nie może trwać dłużej niż dwie sekundy”.

Regularnie obserwujemy, jak pojedyncze serie Codex pracują nad jednym zadaniem przez ponad sześć godzin (często wtedy, gdy ludzie śpią).

Zarządzanie kontekstem jest jednym z największych wyzwań związanych z zapewnieniem skuteczności agentów w przypadku dużych i złożonych zadań. Jednym z pierwszych wniosków, jakie wyciągnęliśmy, była prosta zasada: należy dać agentowi Codex mapę, a nie tysiącstronicową instrukcję.

Wypróbowaliśmy podejście „jeden duży plik AGENTS.md⁠(otwiera nowe okno)” . Skończyło się to przewidywalną porażką:

• Kontekst jest zasobem deficytowym. Ogromny plik instrukcji przesłania zadanie, kod i odpowiednią dokumentację, przez co agent albo pomija kluczowe ograniczenia, albo zaczyna optymalizować niewłaściwe elementy.
• Zbyt wiele wskazówek staje się brakiem wskazówek. Kiedy wszystko jest „ważne”, nic nie jest ważne. Agenci kończą na lokalnym dopasowywaniu wzorców zamiast celowym nawigowaniu.
• Wszystko natychmiast się psuje. Monolityczna instrukcja zamienia się w cmentarzysko przestarzałych zasad. Agenci nie wiedzą, co wciąż jest aktualne, ludzie przestają go utrzymywać, a plik po cichu staje się uciążliwym balastem.
• Trudno to sprawdzić. Pojedynczy blob nie nadaje się do automatycznych kontroli (pokrycia, aktualności, własności, powiązań między plikami), więc dryf jest nieunikniony.

Zamiast traktować plik AGENTS.md jako encyklopedię, traktujemy go jako spis treści.

Baza wiedzy repozytorium znajduje się w uporządkowanym katalogu docs/ traktowanym jako główne źródło wiedzy. Krótki plik AGENTS.md (około 100 wierszy) jest wprowadzany do kontekstu i służy przede wszystkim jako mapa z odnośnikami do bardziej szczegółowych źródeł informacji w innych miejscach.

Dokumentacja projektowa jest katalogowana i indeksowana, wraz ze statusem weryfikacji i zestawem podstawowych założeń, które definiują zasady działania oparte na podejściu skoncentrowanym na agentach. Dokumentacja architektury⁠(otwiera nowe okno) zawiera ogólny schemat domen i warstw pakietów. Dokument dotyczący jakości ocenia każdą dziedzinę produktu i warstwę architektury, śledząc luki w miarę upływu czasu.

Plany są traktowane jako artefakty pierwszej klasy. Krótkotrwałe, lekkie plany są wykorzystywane do niewielkich zmian, natomiast złożone prace są rejestrowane w planach wykonania⁠(otwiera nowe okno) wraz z dziennikami postępów i decyzji, które są wprowadzane do repozytorium. Aktywne plany, zakończone plany oraz znany dług techniczny są wersjonowane i przechowywane razem, co pozwala agentom działać bez polegania na zewnętrznym kontekście.

Umożliwia to stopniowe ujawnianie informacji: agenci zaczynają od niewielkiego, stabilnego punktu wejścia i uczą się, gdzie szukać dalej, bez bycia przytłoczonym od samego początku.

Egzekwujemy to automatycznie. Specjalne lintery i zadania CI sprawdzają, czy baza wiedzy jest aktualna, zawiera odpowiednie odnośniki i ma prawidłową strukturę. Cyklicznie działający agent „porządkowania dokumentacji” skanuje ją pod kątem nieaktualnych lub przestarzałych informacji, które nie odzwierciedlają rzeczywistego zachowania kodu, a następnie otwiera zgłoszenia pull request dotyczące poprawek.

Wraz z rozwojem bazy kodu konieczna była również ewolucja struktury Codex służącej do podejmowania decyzji projektowych.

Jako że repozytorium jest w całości generowane przez agenta, jest ono zoptymalizowane przede wszystkim pod kątem czytelności Codex. Podobnie jak zespoły dążą do poprawy czytelności swojego kodu dla nowych pracowników działu inżynierii, celem waszych inżynierów było umożliwienie agentowi analizowania całej dziedziny biznesowej bezpośrednio z poziomu samego repozytorium.

Z punktu widzenia agenta wszystko, do czego nie masz dostępu w kontekście podczas działania, praktycznie nie istnieje. Wiedza przechowywana w Google Docs, wątkach czatu lub w głowach ludzi nie jest dostępna dla systemu. Widoczne są tylko lokalne artefakty z repozytorium z wersjami (np. kod, znaczniki, schematy i wykonywalne plany).

Zrozumieliśmy, że z czasem musimy umieszczać w repozytorium coraz więcej kontekstu. Ta rozmowa w serwisie Slack, która pomogła zespołowi uzgodnić wzorzec architektoniczny? Jeśli nie jest ona dostępna dla agenta, jest on nieczytelna, tak samo jak byłaby nieznana nowemu pracownikowi, który dołączyłby do zespołu trzy miesiące później.

Zapewnienie agentowi Codex szerszego kontekstu oznacza uporządkowanie i udostępnienie odpowiednich informacji, aby mógł je przeanalizować, zamiast przytłaczać go doraźnymi instrukcjami. Przekazanie agentowi tych informacji prowadzi do lepszej koordynacji działań, podobnie jak w przypadku wprowadzania nowego członka zespołu w zasady dotyczące produktów, normy inżynieryjne i kulturę zespołu (w tym preferencje dotyczące emoji).

Takie ujęcie pozwoliło wyjaśnić wiele kompromisów. Preferowaliśmy zależności i abstrakcje, które można było w pełni zinternalizować i przeanalizować w repozytorium. Technologie często opisywane jako „nudne” są zazwyczaj łatwiejsze do modelowania przez agentów ze względu na komponowalność, stabilność API i reprezentację w zestawie szkoleniowym. W niektórych przypadkach tańsze było ponowne wdrożenie przez agenta podzbiorów funkcjonalności niż obejście nieprzejrzystego zachowania bibliotek publicznych. Na przykład zamiast korzystać z ogólnego pakietu typu p-limit wdrożyliśmy własny pomocnik map-with-concurrency: jest on ściśle zintegrowany z naszą instrumentacją OpenTelemetry, ma 100-procentowe pokrycie testowe i zachowuje się dokładnie tak, jak oczekuje tego nasze środowisko uruchomieniowe.

Przeniesienie większej części systemu do postaci, którą można bezpośrednio sprawdzić, zweryfikować i zmodyfikować, zwiększa możliwości nie tylko w przypadku Codex, ale także innych agentów (np. Aardvark) które również pracują nad bazą kodu.

Sama dokumentacja nie wystarczy, aby zachować spójność kodu generowanego w całości przez agenta. Umożliwiamy agentom szybkie wdrażanie bez naruszania podstaw poprzez egzekwowanie niezmiennych zasad, a nie szczegółowe zarządzanie implementacjami. Na przykład wymagamy, aby Codex analizował kształty danych na granicy⁠(otwiera nowe okno), ale nie narzucamy sposobu, w jaki ma to nastąpić (model wydaje się preferować Zod, ale nie określiliśmy konkretnej biblioteki).

Agenci działają najskuteczniej w środowiskach o ścisłych granicach i przewidywalnej strukturze⁠(otwiera nowe okno), dlatego stworzyliśmy aplikację w oparciu o sztywny model architektury. Każda dziedzina biznesowa jest podzielona na stały zestaw warstw, ze ściśle sprawdzonymi kierunkami zależności i ograniczonym zestawem dopuszczalnych krawędzi. Ograniczenia te są egzekwowane mechanicznie za pomocą niestandardowych linterów (oczywiście generowanych przez Codex!) i testów strukturalnych.

Poniższy schemat przedstawia tę zasadę: w ramach każdej domeny biznesowej (np. ustawienia aplikacji) kod może być zależny tylko „do przodu” poprzez stały zestaw warstw (typy → konfiguracja → repozytorium → usługa → środowisko uruchomieniowe → interfejs użytkownika). Kwestie przekrojowe (uwierzytelnianie, łączniki, telemetria, flagi funkcji) są wprowadzane poprzez jeden wyraźny interfejs: Providers. Wszystko inne jest niedozwolone i egzekwowane mechanicznie.

Jest to rodzaj architektury, którą zazwyczaj odkłada się na później, aż do momentu zatrudnienia setek inżynierów. W przypadku agentów kodujących jest to wczesny warunek wstępny: ograniczenia pozwalają na osiągnięcie szybkości bez utraty jakości lub odchyleń architektonicznych.

W praktyce egzekwujemy te zasady za pomocą niestandardowych linterów i testów strukturalnych, a także niewielkiego zestawu „nienaruszalnych reguł stylu projektowego”. Na przykład statycznie egzekwujemy strukturalne logowanie, konwencje nazewnictwa schematów i typów, limity rozmiaru plików oraz wymagania dotyczące niezawodności specyficzne dla platformy za pomocą niestandardowych linterów. Ponieważ lintery są niestandardowe, zapisujemy komunikaty o błędach, aby wprowadzić instrukcje naprawcze do kontekstu agenta.

W przypadku pracy, w której na pierwszym miejscu są ludzie, zasady te mogą wydawać się pedantyczne lub ograniczające. Dzięki agentom stają się one mnożnikami: po zakodowaniu mają zastosowanie wszędzie jednocześnie.

Jednocześnie jasno określamy, gdzie ograniczenia mają znaczenie, a gdzie nie. Przypomina to kierowanie dużą organizacją zajmującą się platformami inżynieryjnymi: centralne egzekwowanie granic, lokalna autonomia. Przywiązujesz dużą wagę do granic, poprawności i powtarzalności. W ramach tych ograniczeń dajesz zespołom – lub agentom – znaczną swobodę w zakresie sposobu przedstawiania rozwiązań.

Wynikowy kod nie zawsze odpowiada ludzkim preferencjom stylistycznym, ale to nie stanowi problemu. Jeśli wynik jest poprawny, możliwy do utrzymania i czytelny dla przyszłych agentów, spełnia on te wymagania.

Ludzki styl projektowy jest stale wprowadzany do systemu. Komentarze z przeglądów, refaktoryzacja żądań pull request i błędy widoczne dla użytkowników są rejestrowane jako aktualizacje dokumentacji lub kodowane bezpośrednio w narzędziach. Gdy dokumentacja jest niewystarczająca, wpisujemy zasadę do kodu.

Wraz ze wzrostem przepustowości agentów Codex wiele konwencjonalnych norm inżynieryjnych utraciło efektywność.

Repozytorium działa z minimalnymi blokującymi bramkami scalania. Żądane pull request są krótkotrwałe. Niestabilne testy często poprawia się poprzez ponowne uruchomienia zamiast blokować postęp bezterminowo. W systemie, w którym przepustowość agentów znacznie przewyższa ludzką uwagę, poprawki są tanie, a czekanie jest kosztowne.

W środowisku o niskiej przepustowości byłoby to nieodpowiedzialne. Tutaj często jest to właściwy wybór.

Kiedy mówimy, że baza kodu jest generowana przez agentów Codex, mamy na myśli wszystko, co znajduje się w bazie kodu.

Agenci generują następujące elementy:

• kod produktu i testy,
• konfiguracja CI i narzędzia do wydawania wersji,
• wewnętrzne narzędzia deweloperskie,
• historia dokumentacji i projektowania,
• środowiska testowe do oceny,
• komentarze do przeglądu i odpowiedzi,
• skrypty zarządzające repozytorium,
• pliki definicji pulpitu produkcyjnego.

Ludzie zawsze pozostają w obiegu informacji, ale pracują na innym poziomie abstrakcji niż kiedyś. Ustalamy priorytety pracy, przekładamy opinie użytkowników na kryteria akceptacji i weryfikujemy wyniki. Kiedy agent ma trudności, traktujemy to jako sygnał: identyfikujemy brakujące elementy – narzędzia, zabezpieczenia, dokumentację – i wprowadzamy je z powrotem do repozytorium, zawsze poprzez napisanie poprawki przez sam Codex.

Agenci korzystają bezpośrednio z waszych standardowych narzędzi programistycznych. Pobierają opinie z przeglądu, odpowiadają bezpośrednio w wątku, wprowadzają aktualizacje i często łączą i scalają własne żądania pull request w jedno zatwierdzenie.

W miarę jak coraz więcej elementów cyklu rozwoju było kodowanych bezpośrednio w systemie – testowanie, weryfikacja, przegląd, obsługa informacji zwrotnych i odzyskiwanie – repozytorium przekroczyło ostatnio znaczący próg, dzięki czemu Codex może kompleksowo obsługiwać nową funkcję.

Po otrzymaniu pojedynczego polecenia agent może teraz wykonać następujące działania:

• sprawdzenie aktualnego stanu bazy kodu,
• odtworzenie zgłoszonego błędu,
• nagranie filmu pokazującego błąd,
• wdrożenie poprawki,
• sprawdzenie poprawki poprzez uruchomienie aplikacji,
• nagranie drugiego filmu pokazującego rozwiązanie,
• otwarcie żądania pull request,
• odpowiedź na opinie agentów i ludzi,
• wykrywanie i naprawianie błędów kompilacji,
• eskalacja do człowieka tylko wtedy, gdy wymagana jest ocena,
• Scalanie zmian

Zachowanie to zależy w dużym stopniu od konkretnej struktury i narzędzi tego repozytorium i nie należy zakładać, że można je uogólnić bez podobnych inwestycji – przynajmniej na razie.

Pełna autonomia agentów wprowadza również nowe problemy. Codex powiela wzorce, które już istnieją w repozytorium – nawet te nierówne lub nieoptymalne. Z czasem nieuchronnie prowadzi to do dryfu.

Początkowo ludzie zajmowali się tym ręcznie. Nasz zespół spędzał każdy piątek (20% tygodnia) na sprzątaniu „AI slop”. Nic dziwnego, że nie dało się tego skalować.

Zamiast tego zaczęliśmy kodować coś, co nazywamy „złotymi zasadami”, bezpośrednio w repozytorium i stworzyliśmy cykliczny proces czyszczenia. Zasady te są subiektywnymi, mechanicznymi regułami, które zapewniają czytelność i spójność kodu dla przyszłych uruchomień agenta. Na przykład: (1) preferujemy wspólne pakiety narzędziowe zamiast ręcznie tworzonych pomocników, aby zachować centralizację niezmienników, oraz (2) nie analizujemy danych w stylu „YOLO” – weryfikujemy granice lub polegamy na typowanych SDK, aby agent nie mógł przypadkowo budować na podstawie domniemanych kształtów. W regularnych odstępach czasu wykonujemy zestaw zadań Codex w tle, które skanują pod kątem odchyleń, aktualizują oceny jakości i otwierają ukierunkowane żądania pull request dotyczące refaktoryzacji. Większość z nich można przejrzeć w mniej niż minutę i automatycznie scalić.

Przypomina to zbieranie odpadów. Dług techniczny jest jak pożyczka o wysokim oprocentowaniu: prawie zawsze lepiej jest spłacać go stopniowo, małymi kwotami, niż pozwolić, aby narastał, a potem zmagać się z nim w bolesnych dawkach. Ludzki styl jest uchwycony raz, a następnie stosowany konsekwentnie w każdym wierszu kodu. Pozwala wam to również codziennie wychwytywać i eliminować niewłaściwe wzorce, zamiast pozwolić im rozprzestrzeniać się w kodzie przez wiele dni lub tygodni.

Strategia ta sprawdziła się dotychczas podczas wewnętrznego wdrożenia i przyjęcia w OpenAI. Stworzenie realnego produktu dla prawdziwych użytkowników pomogło nam ugruntować nasze inwestycje w rzeczywistości i skierowało nas w stronę możliwości utrzymania go w dłuższej perspektywie.

Nie wiemy jeszcze, jak spójność architektoniczna ewoluuje na przestrzeni lat w systemie w pełni generowanym przez agentów. Wciąż uczymy się, gdzie ludzka ocena ma największe znaczenie i jak ją zakodować, aby przyniosła jak największe korzyści. Nie wiemy również, jak ten system będzie ewoluował wraz z postępującym wzrostem możliwości modeli.

Stało się jasne, że tworzenie oprogramowania nadal wymaga dyscypliny, ale dyscyplina ta przejawia się bardziej w strukturze niż w kodzie. Narzędzia, abstrakcje i pętle sprzężenia zwrotnego, które zapewniają spójność kodu źródłowego, stają się coraz ważniejsze.

Nasze najtrudniejsze wyzwania koncentrują się obecnie na projektowaniu środowisk, pętli sprzężenia zwrotnego i systemów kontroli, które pomagają wam osiągnąć nasz cel: tworzenie i utrzymywanie złożonego, niezawodnego oprogramowania na dużą skalę.

W miarę jak agenci tacy jak Codex zajmują się coraz większą częścią cyklu życia oprogramowania pytania te będą nadal zyskiwać na znaczeniu. Mamy nadzieję, że te wczesne wnioski pomogą Ci zdecydować, gdzie warto zainwestować swój wysiłek, aby móc po prostu zacząć tworzyć.