Jak wykorzystaliśmy Codex, aby stworzyć aplikację Sora dla systemu Android w ciągu 28 dni

Od 26.04.2026 aplikacja Sora nie jest już dostępna.

W listopadzie wprowadziliśmy na rynek aplikację Sora dla systemu Android, dzięki której każdy użytkownik urządzenia z tym systemem może przekształcić krótkie polecenie w realistyczny film. W dniu premiery aplikacja osiągnęła pierwsze miejsce w sklepie Play Store. Użytkownicy systemu Android wygenerowali ponad milion filmów w ciągu pierwszych 24 godzin.

Za uruchomieniem kryje się pewna historia: pierwotna wersja aplikacji Sora dla systemu Android została stworzona w ciągu 28 dni dzięki narzędziu dostępnemu dla każdego zespołu lub programisty: Codex.

Od 8 października do 5 listopada 2025 r. zespół inżynierów lean współpracujący z Codex i zużywający około 5 miliardów tokenów wprowadził na rynek aplikację Sora dla systemu Android od prototypu do globalnej premiery. Pomimo swojej skali aplikacja charakteryzuje się współczynnikiem awaryjności na poziomie 99,9% i architekturą, która jest dla nas powodem do dumy. Zainteresowanym możemy powiedzieć, że wykorzystaliśmy sekretny model – wczesną wersję modelu GPT‑5.1‑Codex – jest to ta sama wersja, z której każdy programista lub firma może korzystać już dziś za pośrednictwem CLI, rozszerzenia IDE lub aplikacji internetowej.

Po uruchomieniu aplikacji Sora na iOS jej popularność gwałtownie wzrosła. Ludzie natychmiast zaczęli tworzyć ogromną liczbę filmów. Natomiast w przypadku systemu Android dysponowaliśmy jedynie niewielkim prototypem wewnętrznym i szybko rosnącą liczbą użytkowników zarejestrowanych w Google Play.

Częstą reakcją na wprowadzenie kluczowego produktu pod presją czasu jest nagromadzenie zasobów i dodanie procesów. Aplikacja produkcyjna o takim zakresie i jakości zazwyczaj wymaga zaangażowania wielu inżynierów pracujących przez wiele miesięcy, a proces ten jest opóźniany ze względu na konieczność koordynacji. 

Amerykański architekt komputerowy Fred Brooks zasłynął ostrzeżeniem, że „dodanie większej liczby osób do opóźnionego projektu oprogramowania powoduje jego dalsze opóźnienie”. Innymi słowy, gdy próbujemy szybko zrealizować złożony projekt, zatrudnienie dodatkowych inżynierów często może spowolnić pracę, powodując wzrost kosztów komunikacji, fragmentację zadań i koszty integracji. Zamiast zignorować to spostrzeżenie, postanowiliśmy je wykorzystać. Zebraliśmy silny zespół czterech inżynierów – wszyscy mieli do dyspozycji narzędzie Codex, które znacznie zwiększyło ich efektywność pracy.

Dzięki takiej metodzie pracy w ciągu 18 dni dostarczyliśmy pracownikom wewnętrzną wersję aplikacji Sora dla systemu Android, a 10 dni później wprowadziliśmy ją na rynek. Udało nam się zachować wysokie standardy w zakresie praktyk inżynieryjnych dla systemu Android, zainwestowaliśmy w łatwość konserwacji i zapewniliśmy tę samą niezawodność aplikacji, jakiej oczekiwalibyśmy od bardziej tradycyjnego projektu. (Nadal intensywnie korzystamy z Codex, aby rozwijać aplikację i wprowadzać do niej nowe funkcje).

Aby zrozumieć, w jaki sposób korzystaliśmy z narzędzia Codex, warto wiedzieć, w jakich obszarach sprawdza się ono najlepiej, a w jakich wymaga szczegółowych wskazówek. Traktowanie go jak nowo zatrudnionego starszego inżyniera okazało się dobrym podejściem. Dzięki możliwościom Codex mogliśmy poświęcić więcej czasu na kierowanie powstawaniem kodu oraz sprawdzanie go zamiast pisania go samodzielnie.

W jakich obszarach Codex potrzebuje wskazówek

1. Narzędzie Codex nie radzi sobie jeszcze zbyt dobrze z wnioskowaniem o tym, o czym nie zostało poinformowane (np. preferowane wzorce architektury, strategia produktowa, rzeczywiste zachowania użytkowników oraz wewnętrzne normy lub skróty).
2. Podobnie Codex nie mógł zobaczyć, jak aplikacja faktycznie działa: nie mógł otworzyć aplikacji Sora na urządzeniu i zauważyć, że przewijanie nie działało prawidłowo, ani dostrzec niejasności przepływu. Tylko nasz zespół mógł wykonać te empiryczne zadania.
3. Każda instancja wymaga wprowadzenia. Przedstawienie kontekstu wraz z jasnymi celami, ograniczeniami i wskazówkami dotyczącymi „sposobu działania” miało kluczowe znaczenie dla zapewnienia prawidłowego działania narzędzia Codex.
4. Podobnie narzędzie Codex miało trudności z głęboką oceną architektury: działając samodzielnie, mogło wprowadzić dodatkowy model widoku, podczas gdy my tak naprawdę chcieliśmy rozszerzyć istniejący, lub też przenieść do warstwy interfejsu użytkownika logikę, która wyraźnie powinna znajdować się w repozytorium. Instynktownie dążyło do tego, aby dana funkcja działała, a nie do estetyki w dłuższej perspektywie.

Uznaliśmy za przydatne, aby Codex tworzył i utrzymywał dużą liczbę plików AGENT.md w całym kodzie źródłowym. Dzięki temu łatwo było stosować te same wytyczne i najlepsze praktyki podczas wszystkich sesji. Na przykład dodaliśmy następujący fragment do naszego pliku najwyższego poziomu AGENTS.md w celu zapewnienia, że Codex napisze kod zgodnie z naszymi wytycznymi stylistycznymi:

Z czym Codex radzi sobie doskonale

1. Szybkie odczytywanie i zrozumienie dużych baz kodu: Codex zna zasadniczo wszystkie główne języki programowania, co ułatwia wykorzystanie tych samych koncepcji na wielu platformach bez skomplikowanych abstrakcji.
2. Zakres testów: Codex wykazuje (wyjątkowe) zaangażowanie w pisanie testów jednostkowych obejmujących szeroki zakres przypadków. Nie wszystkie testy były dogłębne, ale szeroki zakres pomógł zapobiec regresji. 
3. Wykorzystanie opinii: Codex również doskonale reaguje na opinie. Po niepowodzeniu CI mogliśmy wkleić dzienniki danych wyjściowych do polecenia i poprosić Codex o zasugerowanie poprawek.
4. Masowo równoległe, jednorazowe uruchamianie: większość użytkowników nie wykorzysta pełnych możliwości liczby sesji, które mogliby faktycznie uruchomić jednocześnie. Bardzo realne jest testowanie wielu pomysłów równolegle i traktowanie kodu jako jednorazowego.
5. Nowe spojrzenie: podczas dyskusji dotyczących projektu wykorzystaliśmy Codex jako narzędzie generatywne do zbadania potencjalnych punktów awarii i odkrycia nowych sposobów rozwiązania problemu. Na przykład podczas projektowania optymalizacji pamięci odtwarzacza wideo Codex przeanalizował wiele zestawów SDK, aby zaproponować rozwiązania, których nie mielibyśmy czasu przeanalizować. Wyniki analizy dokonanej przez Codex okazały się nieocenione w minimalizowaniu zużycia pamięci w ostatecznej wersji aplikacji.
6. Zwiększenie efektywności pracy: w praktyce poświęcaliśmy więcej czasu na recenzowaniu kody i kierowanie nim niż na samo pisanie go. Należy jednak dodać, że Codex doskonale sprawdza się również w przeglądaniu kodu – często wykrywa błędy przed ich scaleniem, co zwiększa niezawodność.

Jak tylko zrozumieliśmy te cechy, nasz model pracy stał się znacznie prostszy. Skorzystaliśmy z narzędzia Codex, aby wykonać znaczną część żmudnej pracy w ramach dobrze znanych schematów i ściśle określonych zakresów, podczas gdy nasz zespół skupił się na architekturze, doświadczeniach użytkowników, zmianach systemowych i finalnych kwestiach dotyczących jakości.

Nawet najlepszy nowy pracownik z dużym doświadczeniem nie ma właściwego punktu widzenia, aby móc od razu podejmować długoterminowe decyzje dotyczące wyważenia poszczególnych aspektów. Aby wykorzystać narzędzie Codex i zapewnić jego niezawodność oraz łatwość utrzymania, kluczowe znaczenie miało samodzielne nadzorowanie projektu systemów aplikacji i kluczowych ustępstw. Obejmowały one kształtowanie architektury aplikacji, modularyzację, wstrzykiwanie zależności i nawigację. Wdrożyliśmy również uwierzytelnianie i podstawowe przepływy sieciowe. 

Na tej podstawie napisaliśmy od podstaw kilka reprezentatywnych funkcji. Zastosowaliśmy zasady, których chcieliśmy przestrzegać w całym kodzie źródłowym, na bieżąco dokumentując wzorce obowiązujące w całym projekcie. Dzięki wskazaniu reprezentatywnych funkcji narzędzie Codex mogło działać bardziej niezależnie w ramach naszych standardów. W przypadku projektu, który według naszych szacunków został w 85% napisany przez Codex, starannie zaplanowane podstawy pozwoliły uniknąć kosztownych powrotów do poprzednich wersji i refaktoryzacji. Była to jedna z najważniejszych decyzji, jakie podjęliśmy. 

Celem nie było stworzenie „czegoś, co działa” tak szybko, jak to możliwe, ale raczej „czegoś, co działa tak, jak tego chcemy”. Istnieje wiele „poprawnych” sposobów pisania kodu. Nie musieliśmy dokładnie mówić narzędziu Codex, co ma robić – musieliśmy mu pokazać, co jest „poprawne” w naszym zespole. Kiedy ustaliliśmy punkt wyjścia oraz nasz preferowany sposób tworzenia, Codex mógł rozpocząć pracę.

Aby sprawdzić, co się stanie, spróbowaliśmy użyć polecenia: „Zbuduj aplikację Sora dla systemu Android w oparciu o kod iOS. Do dzieła”, ale szybko zrezygnowaliśmy z tej ścieżki. Mimo iż produkt stworzony przez Codex działał pod względem technicznym, środowisko użytkownika zostawiało wiele do życzenia. Bez jasnego zrozumienia punktów końcowych, danych i przepływów użytkowników jednorazowy kod Codex był zawodny (nawet bez użycia agenta scalanie tysięcy linii kodu jest ryzykowne). 

Postawiliśmy hipotezę, że narzędzie Codex doskonale sprawdzi się w środowisku testowym zawierającym dobrze napisane przykłady – i mieliśmy rację. Poproszenie Codex o „stworzenie ekranu ustawień” bez podawania praktycznie żadnego kontekstu nie dawało dobrych rezultatów. Poproszenie Codex o „stworzenie ekranu ustawień przy użyciu tej samej architektury i wzorców co w przypadku drugiego pokazanego ekranu” było znacznie skuteczniejsze. Ludzie podjęli decyzje dotyczące struktury i ustalili niezmienne elementy. następnie Codex wypełnił tę strukturę dużą ilością kodu.

Kolejnym krokiem w kierunku maksymalnego wykorzystania potencjału Codex było ustalenie, w jaki sposób umożliwić narzędziu Codex pracę przez długi czas (ostatnio ponad 24 godziny⁠) bez nadzoru.

Na początku korzystania z Codex natychmiast przechodziliśmy do poleceń typu: „Oto funkcja. Oto kilka plików. Proszę to skompilować”. Czasami to działało, ale najczęściej powstawał kod, który technicznie się kompilował, lecz znacznie odbiegał od naszej architektury i celów.

W związku z tym zmieniliśmy sposób pracy. W przypadku każdej istotnej zmiany najpierw poprosiliśmy Codex o pomoc w zrozumieniu działania systemu i kodu. Na przykład poprosiliśmy go o przeanalizowanie zestawu powiązanych plików i podsumowanie działania danej funkcji, np. w jaki sposób dane przepływają z interfejsu API przez warstwę repozytorium, model widoku i do interfejsu użytkownika. Następnie poprawialiśmy go lub doskonaliliśmy jego zrozumienie. (Na przykład wskazaliśmy, że dana abstrakcja w rzeczywistości należy do innej warstwy, lub że dana klasa istnieje tylko w trybie offline i nie powinna być rozszerzana).

Współpracowaliśmy z Codex w celu stworzenia skutecznego planu wdrożeniowego tak jak w przypadku zatrudniania nowego, doskonale wykwalifikowanego pracownika. Plan ten często wyglądał jak miniaturowy dokument projektowy określający, które pliki należy zmienić, jakie nowe stany należy wprowadzić i w jaki sposób powinna przebiegać logika. Dopiero wtedy poprosiliśmy Codex o rozpoczęcie realizacji planu, krok po kroku. Praktyczna wskazówka: w przypadku bardzo długich zadań, w których dochodzimy do granicy naszego okna kontekstowego, prosimy Codex o zapisanie planu w pliku, co pozwala nam zastosować tę samą procedurę we wszystkich instancjach.

Ten dodatkowy cykl planowania okazał się wart poświęconego czasu. Dzięki temu mogliśmy pozwolić narzędziu Codex działać „bez nadzoru” przez długi czas, ponieważ znaliśmy jego plany. Ułatwiło to przegląd kodu, ponieważ mogliśmy sprawdzić implementację w odniesieniu do naszego planu zamiast czytać różnice bez kontekstu. A kiedy coś poszło nie tak, mogliśmy najpierw debugować sam plan, a następnie kod. 

Dynamika przypominała sposób, w jaki dobry dokument projektowy pozwala kierownikowi technicznemu poczuć się pewnie co do projektu. Nie tylko generowaliśmy kod: tworzyliśmy kod w taki sposób, aby wspierał realizację wspólnego planu działania.

W szczytowym momencie projektu często prowadziliśmy wiele sesji Codex równolegle. Jedna dotyczyła odtwarzania, inna wyszukiwania, kolejna obsługi błędów, a czasami jeszcze inna testów lub refaktoryzacji. Przypominało to bardziej zarządzanie zespołem niż korzystanie z narzędzia.

Podczas każdej sesji uczestnicy regularnie informowali nas o postępach. Jeden z nich mógł powiedzieć: „Skończyłem planowanie tego modułu; oto moja propozycja”, podczas gdy inny przedstawiał duże zmiany dotyczące nowej funkcji. Każda z nich wymagała uwag, opinii i recenzji. Przypominało to bycie kierownikiem kilku nowych inżynierów, a których każdy robił postępy i potrzebował wskazówek.

Wynikiem tego był wspólny tok pracy. Możliwości kodowania narzędzia Codex uwolniły nas od konieczności ręcznego wpisywania wielu danych. Mieliśmy więcej czasu, aby przemyśleć architekturę, dokładnie przeczytać żądania ściągnięcia i przetestować aplikację. 

Jednocześnie to dodatkowe przyspieszenie oznaczało, że zawsze mieliśmy coś do zrobienia w kolejce recenzji. Codex nie uległ zablokowaniu przez zmianę kontekstu, ale my tak. Nasze wąskie gardło w rozwoju przeniosło się z pisania kodu na podejmowanie decyzji, przekazywanie opinii i integrowanie zmian.

W tym miejscu spostrzeżenia Brooksa nabierają nowego znaczenia. Nie można po prostu dodać sesji Codex i oczekiwać, że nastąpi liniowe przyspieszenie, tak samo jak nie można dodawać kolejnych inżynierów do projektu i oczekiwać, że harmonogram skróci się liniowo. Każda dodatkowa „para rąk”, nawet wirtualnych, zwiększa nakłady związane z koordynacją. Zmieniliśmy się w dyrygenta orkiestry, a nie po prostu szybszymi solistami.

Rozpoczęliśmy nasz z doskonałej pozycji – gdy Sora była już dostępna dla systemu iOS. Często kierowaliśmy Codex do baz kodu iOS i zaplecza, aby ułatwić mu zrozumienie kluczowych wymagań i ograniczeń. Przez cały czas trwania projektu żartowaliśmy, że na nowo odkryliśmy ideę struktury międzyplatformowej. Zapomnij o React Native czy Flutter; przyszłość multiplatformowości to po prostu Codex.

Za tymi słowami kryją się dwie zasady:

1. Logika jest przenośna. Niezależnie od tego, czy kod jest napisany w języku Swift czy Kotlin, podstawowa logika aplikacji – modele danych, wywołania sieciowe, reguły walidacji, logika biznesowa – pozostaje taka sama. Codex bardzo dobrze radzi sobie z odczytywaniem implementacji Swift i tworzeniem jej odpowiednika w języku Kotlin z zachowaniem semantyki.
2. Konkretne przykłady zapewniają bogaty kontekst. Nowa sesja Codex, podczas której można zobaczyć „jak to dokładnie działa w systemie iOS” i „jak wygląda architektura systemu Android”, jest znacznie bardziej skuteczna niż sesja oparta wyłącznie na opisach w języku naturalnym.

Stosując te zasady w praktyce, udostępniliśmy repozytoria iOS, zaplecza i systemu Android w tym samym środowisku. Daliśmy narzędziu Codex między innymi następujące polecenia:

„Zapoznaj się z tymi modelami i punktami końcowymi w kodzie iOS, a następnie zaproponuj plan wdrożenia równoważnego zachowania w systemie Android przy użyciu naszego istniejącego klienta API i klas modeli”.

Małą, ale przydatną sztuczką było wyszczególnienie w pliku ~/.codex/AGENTS.md lokalizacji lokalnych repozytoriów i ich zawartości. Dzięki temu Codex był w stanie łatwiej wyszukiwać i przeglądać odpowiedni kod.

W rzeczywistości zajmowaliśmy się tworzeniem oprogramowania na różne platformy poprzez tłumaczenie zamiast wspólnej abstrakcji. Byliśmy w stanie uniknąć podwojenia kosztów wdrożenia dzięki temu, że większość tłumaczenia została wykonana przez Codex.

Ogólna lekcja jest taka, że dla Codex kontekst ma kluczowe znaczenie. Codex uzyskał najlepsze rezultaty, gdy zrozumiał, jak dana funkcja działała już w systemie iOS, w połączeniu ze zrozumieniem struktury naszej aplikacji dla systemu Android. Brak tego kontekstu nie oznaczał, że Codex „odmawiał współpracy”, ale że opierał się na domysłach. Im bardziej traktowaliśmy go jak nowego członka zespołu i inwestowaliśmy w zapewnienie mu odpowiednich danych wejściowych, tym lepsze osiągał wyniki.

Pod koniec naszego czterotygodniowego sprintu korzystanie z Codex przestało być eksperymentem i stało się naszym domyślnym cyklem programowania. Korzystaliśmy z niego, aby lepiej zrozumieć istniejący kod, planować zmiany i wdrażać nowe funkcje. Ocenialiśmy jego wyniki tak samo, jak ocenialibyśmy wyniki kolegów z zespołu. W ten sposób po prostu dostarczaliśmy oprogramowanie.

Stało się jasne, że rozwój wspomagany przez AI nie zmniejsza potrzeby zachowania rygoru, a wręcz przeciwnie – zwiększa ją. Choć Codex jest bardzo wydajny, jego celem jest natychmiastowe dotarcie z punktu A do punktu B. Dlatego kodowanie wspomagane AI nie może funkcjonować bez udziału ludzi. Inżynierowie oprogramowania potrafią zrozumieć i zastosować rzeczywiste ograniczenia systemów, najlepsze sposoby projektowania oprogramowania oraz sposoby tworzenia z uwzględnieniem przyszłych planów rozwoju i produktów. W przyszłości inżynierowie oprogramowania będą musieli dysponować dogłębną wiedzą na temat systemów oraz umiejętnością długotrwałej współpracy z AI. 

Najciekawsze aspekty inżynierii oprogramowania to tworzenie atrakcyjnych produktów, projektowanie skalowalnych systemów, pisanie złożonych algorytmów oraz eksperymentowanie z danymi, wzorcami i kodem. Jednak realia inżynierii oprogramowania w przeszłości i obecnie są często bardziej prozaiczne: centrowanie przycisków, podłączanie punktów końcowych i pisanie szablonów. Teraz Codex pozwala skupić się na najważniejszych aspektach inżynierii oprogramowania oraz na tym, co uwielbiamy w naszej pracy.

Po skonfigurowaniu narzędzia Codex w środowisku bogatym w kontekst, w którym cele oraz sposoby kompilacji są dla niego zrozumiałe, każdy zespół może zwielokrotnić swoje możliwości. Nasze podsumowanie wprowadzenia nie jest uniwersalnym przepisem i nie twierdzimy, że rozwiązaliśmy kwestię rozwoju wspomaganego przez AI. Mamy jednak nadzieję, że nasze doświadczenie ułatwi znalezienie najlepszych sposobów na zyskanie nowych możliwości dzięki Codex. 

Kiedy siedem miesięcy temu wprowadzono Codex w badawczej wersji poglądowej, inżynieria oprogramowania wyglądała zupełnie inaczej. Sora pozwoliła nam odkryć nowy rozdział inżynierii. W miarę doskonalenia naszych modeli i narzędzi wspomagających sztuczna inteligencja stanie się coraz bardziej nieodzowną częścią procesu tworzenia. 

Co stworzysz wraz z własnym zespołem narzędzi Codex?