Masz gotową aplikację na iOS, a zarząd oczekuje wersji na Androida „na wczoraj”. Tradycyjne podejście zakładałoby zatrudnienie dużego zespołu mobilnego, miesiące refaktoryzacji lub walkę z frameworkami wieloplatformowymi. Jednak OpenAI, wprowadzając aplikację Sora na Androida, wybrało inną drogę. Zamiast armii programistów, postawili na czteroosobowy zespół i potężne wsparcie sztucznej inteligencji. Kluczem do sukcesu okazał się Codex, a konkretnie GPT‑5.1-Codex model AI, który w tym projekcie nie był asystentem, ale de facto „starszym inżynierem”.
Historia ta pokazuje, że budowanie oprogramowania wchodzi w zupełnie nową fazę. Jeśli interesuje Cię, jak wykorzystać te metody w swoim projekcie, warto przyjrzeć się bliżej temu, jak sztuczna inteligencja zmienia programowanie i jakie wnioski płyną z tego konkretnego wdrożenia.
Codex jako „senior dev” w zespole
Najbardziej imponującą statystyką projektu Sora for Android nie jest liczba pobrań, ale czas realizacji. Zespół czterech inżynierów stworzył stabilną, produkcyjną aplikację w zaledwie 28 dni. Jak to możliwe? OpenAI potraktowało model Codex nie jako narzędzie do autouzupełniania kodu, ale jak autonomicznego członka zespołu. Szacuje się, że AI wygenerowało około 85% kodu źródłowego, zużywając przy tym około 5 miliardów tokenów. Koszt projektu za same tokeny to około 110 000zł.
W tradycyjnym modelu powiększanie zespołu, gdy terminy gonią, często prowadzi do opóźnień (zgodnie z prawem Brooksa). Tutaj, zamiast dodawać ludzi, „zatrudniono” instancje modelu Codex. Każdy z czterech inżynierów działał jako architekt i weryfikator, zlecając AI „brudną robotę” – pisanie testów, tłumaczenie logiki czy implementację interfejsów. To podejście pozwoliło uniknąć narzutu komunikacyjnego, który paraliżuje duże zespoły, jednocześnie zachowując niesamowite tempo prac.
Koniec ery React Native? Strategia „Logic is Portable”
Wielu deweloperów staje przed dylematem: pisać natywnie (Swift/Kotlin) czy użyć technologii cross-platformowych jak Flutter. OpenAI, wykorzystując Codex, zaproponowało trzecią drogę. Zamiast szukać wspólnego mianownika w postaci jednego języka, uznali, że logika biznesowa jest uniwersalna, niezależnie od składni.
Proces wyglądał następująco: Codex otrzymywał dostęp do repozytorium iOS oraz backendu. Jego zadaniem było „przeczytanie” modeli danych i logiki napisanej w Swift, a następnie zaproponowanie i napisanie odpowiedników dla Androida. Okazało się, że AI świetnie radzi sobie z tłumaczeniem intencji programisty między platformami. Zamiast utrzymywać wspólną bazę kodu, utrzymywano wspólną logikę, którą AI adaptowało do specyfiki danego systemu operacyjnego. To może być przełomowy moment dla rozwoju aplikacji mobilnych, sugerujący, że przyszłość cross-platform nie leży we frameworkach, lecz w inteligentnej translacji kodu.
Workflow: Najpierw plan, potem kod
Kluczowym wnioskiem z pracy nad Sorą jest zmiana sposobu interakcji z AI. Bezpośrednie polecenie „napisz mi ten ekran” często kończyło się kodem, który działał, ale nie pasował do architektury projektu. Zespół wypracował więc bardziej wyrafinowany proces:
- Analiza: Codex proszony był o przeczytanie zestawu plików i wyjaśnienie, jak działa dana funkcja w istniejącej wersji iOS.
- Planowanie: Następnie AI musiało stworzyć plan implementacji tej funkcji na Androida, uwzględniając istniejące biblioteki i wzorce.
- Weryfikacja: Inżynierowie sprawdzali ten plan. To moment na korektę założeń bez pisania ani jednej linijki kodu.
- Egzekucja: Dopiero po zatwierdzeniu planu, Codex przystępował do generowania kodu krok po kroku.
Ciekawym technicznych detalem, który według twórców Sora dla Androida bardzo usprawniło pracę, było stworzenie pliku AGENTS.md w katalogu domowym. Służył on jako mapa dla AI, wskazując, gdzie znajdują się lokalne repozytoria i co zawierają. Dzięki temu Codex mógł sprawniej nawigować po strukturze projektu, zachowując się jak programista, który zna topografię firmowych zasobów.
Codex pracujący nawet 24 godziny bez nadzoru
Jednym z najbardziej przełomowych elementów pracy nad Sorą na Androida było świadome dążenie do maksymalnego wydłużenia czasu autonomicznej pracy Codex. Zespół OpenAI nie ukrywa, że ich celem było stworzenie warunków, w których model mógłby pracować nieprzerwanie nawet przez kilkanaście, a w skrajnych przypadkach do około 24 godzin bez bezpośredniej kontroli człowieka.
Nie był to efekt uboczny projektu, lecz konkretna decyzja inżynierska. Inżynierowie chcieli sprawdzić, jak daleko można przesunąć granicę pomiędzy „asystą” a realnym delegowaniem odpowiedzialności. Codex miał nie tylko pisać kod, ale również:
- analizować repozytoria,
- podejmować decyzje implementacyjne,
- diagnozować błędy kompilacji,
- poprawiać własne pomyłki,
- kontynuować pracę po napotkaniu przeszkód.
Aby było to możliwe, zadania definiowano jako duże, zamknięte jednostki pracy, a nie drobne polecenia. Zamiast prosić model o pojedynczy ekran czy klasę, powierzano mu całe fragmenty funkcjonalności — często obejmujące logikę domenową, integrację z backendem oraz warstwę interfejsu użytkownika. Po wydaniu polecenia człowiek często „znikał” na wiele godzin, wracając dopiero do efektu końcowego.
Kluczowe było jednak przygotowanie środowiska. Zespół świadomie:
- eliminował niejawne zależności,
- upraszczał architekturę,
- ograniczał liczbę wyjątków i specjalnych przypadków,
- dokumentował decyzje techniczne w sposób jednoznaczny.
Im bardziej przewidywalny był projekt, tym dłużej Codex potrafił pracować samodzielnie. W efekcie model zachowywał się jak pełnoprawny wykonawca zadań, którego rozlicza się z rezultatu po wielu godzinach pracy. To właśnie możliwość niemal dobowej autonomii najmocniej odróżnia Codex od klasycznych narzędzi AI dla programistów.
Wnioski dla Twojego projektu
Budowa aplikacji w oparciu o AI to nie tylko kwestia dostępu do modelu, ale przede wszystkim umiejętność zarządzania nim. Przykład Sory pokazuje, że małe, kompetentne zespoły wyposażone w potężne modele mogą konkurować z technologicznymi gigantami pod względem szybkości dostarczania oprogramowania. Jeśli planujesz budowę własnej aplikacji, rozważ zmianę podejścia: nie traktuj AI jako wyszukiwarki snippetów, ale jako partnera, któremu delegujesz całe moduły zadań – pod warunkiem, że najpierw precyzyjnie zdefiniujesz architekturę.
Więcej szczegółów technicznych na temat tego wdrożenia znajdziesz w oficjalnym wpisie inżynierskim: Shipping Sora for Android with Codex.
Czy im to wyszło – ocenimy jak aplikacja będzie dostępna na Androida w Polsce.
