Kako smo uz Codex napravili Sora za Android za 28 dana

Od 26. aprila 2026. proizvod Sora više nije dostupan.

U novembru smo širom sveta pokrenuli Android aplikaciju Sora, dajući svakome ko ima Android uređaj mogućnost da kratku instrukciju pretvori u upečatljiv video. Na dan lansiranja aplikacija je stigla do 1. mesta u Play prodavnici. Android korisnici su u prva 24 sata napravili više od milion video-snimaka.

Iza lansiranja stoji jedna priča: početna verzija produkcijske Android aplikacije za Sora napravljena je za 28 dana, zahvaljujući istom agentu koji je dostupan svakom timu ili programeru: Codex.

Od 8. oktobra do 5. novembra 2025, mali inženjerski tim koji je radio uz Codex i potrošio oko 5 milijardi tokena isporučio je Sora za Android od prototipa do globalnog lansiranja. Uprkos tom obimu, aplikacija ima stopu rada bez rušenja od 99,9 odsto i arhitekturu na koju smo ponosni. Ako se pitate da li smo koristili tajni model, koristili smo ranu verziju modela GPT‑5.1‑Codex – istu verziju koju danas svaki programer ili firma može da koristi preko CLI-ja, IDE ekstenzije ili veb-aplikacije.

Kada je Sora lansiran na iOS-u, korišćenje je eksplodiralo. Ljudi su odmah počeli da prave neprekidan tok video-snimaka. Na Androidu smo, nasuprot tome, imali samo mali interni prototip i sve veći broj korisnika koji su se unapred registrovali na Google Play-u.

Čest odgovor na lansiranje sa velikim ulozima i vremenskim pritiskom jeste gomilanje resursa i dodavanje procesa. Produkcijska aplikacija ovog obima i kvaliteta obično bi uključivala mnogo inženjera koji bi radili mesecima, usporeni koordinacijom.

Američki računarski arhitekta Fred Brooks čuveno je upozorio da „dodavanje više ljudi na zakasneli softverski projekat čini ga još zakasnelijim“. Drugim rečima, kada pokušavate da brzo isporučite složen projekat, dodavanje više inženjera često može da uspori efikasnost povećanjem komunikacionog opterećenja, usitnjavanjem zadataka i troškovima integracije. Oslonili smo se na ovaj uvid umesto da ga ignorišemo; okupili smo snažan tim od četiri inženjera – svi opremljeni Codex-om kako bi se drastično povećao uticaj svakog inženjera.

Radeći na ovaj način, isporučili smo internu verziju Sora za Android zaposlenima za 18 dana, a javno lansirali 10 dana kasnije. Zadržali smo visok standard Android inženjerskih praksi, ulagali u održivost i držali aplikaciju na istom nivou pouzdanosti koji bismo očekivali od tradicionalnijeg projekta. (Codex i danas nastavljamo intenzivno da koristimo za razvoj i uvođenje novih funkcija u aplikaciju).

Da bi bilo jasnije kako smo radili sa Codex-om, pomaže da znate gde se ističe, a gde mu je potrebno usmerenje. Dobar pristup bio je da ga tretiramo kao novozaposlenog senior inženjera. Sposobnost Codex-a značila je da možemo više vremena da provedemo usmeravajući i pregledajući kod nego pišući ga sami.

Gde je Codex-u potrebno usmerenje

1. Codex još nije naročito dobar u zaključivanju onoga što mu nije rečeno (npr. vaših omiljenih arhitektonskih obrazaca, strategije proizvoda, stvarnog ponašanja korisnika i internih normi ili prečica).
2. Slično tome, Codex nije mogao da vidi kako aplikacija zaista radi: nije mogao da otvori Sora na uređaju, primeti da skrolovanje deluje čudno ili oseti da je neki tok zbunjujući. Samo je naš tim mogao da pokrije te iskustvene zadatke.
3. Svaka instanca zahteva uvođenje u posao. Deljenje konteksta uz jasne ciljeve, ograničenja i smernice o tome „kako mi radimo stvari“ bilo je ključno da bi Codex radio dobro.
4. U istom smislu, Codex je imao poteškoća sa dubokim arhitektonskim rasuđivanjem: prepušten sebi, mogao bi da uvede dodatni model prikaza tamo gde smo mi zapravo želeli da proširimo postojeći ili da gurne logiku u UI sloj, iako joj je mesto u depou. Njegov instinkt je da nešto proradi, a ne da daje prioritet dugoročnoj urednosti.

Smatrali smo korisnim da Codex pravi i održava velik broj AGENT.md datoteka širom baze koda. To je olakšalo primenu istih smernica i najboljih praksi kroz različite sesije. Na primer, da bismo osigurali da Codex piše kod prema našim stilskim smernicama, dodali smo sledeće u naš glavni AGENTS.md:

Gde se Codex ističe

1. Čitanje i razumevanje velikih baza koda velikom brzinom: Codex poznaje praktično sve glavne programske jezike, što olakšava primenu istih koncepata na mnogim platformama bez složenih apstrakcija.
2. Obuhvat testiranja: Codex je (jedinstveno) entuzijastičan kada je reč o pisanju jediničnih testova koji pokrivaju širok spektar slučajeva. Nije svaki test bio dubok, ali je širina pokrivenosti bila korisna u sprečavanju regresija.
3. Primena povratnih informacija: Na sličan način, Codex dobro reaguje na povratne informacije. Kada bi CI pao, mogli smo da nalepimo izlaz iz loga u instrukciju i zamolimo Codex da predloži ispravke.
4. Masovno paralelno, potrošno izvršavanje: Većina neće gurati granice broja sesija koje zaista mogu da pokrenu u jednom trenutku. Veoma je izvodljivo testirati više ideja paralelno i posmatrati kod kao nešto potrošno.
5. Pružanje nove perspektive: U diskusijama o dizajnu koristili smo Codex kao generativni alat za istraživanje mogućih tačaka otkaza i otkrivanje novih načina za rešavanje problema. Na primer, dok smo osmišljavali optimizacije memorije video-plejera, Codex je pretraživao više SDK-ova kako bi predložio pristupe za koje ne bismo imali vremena da ih sami raščlanimo. Uvidi iz Codex-ovog istraživanja pokazali su se neprocenjivim u smanjivanju memorijskog otiska u finalnoj aplikaciji.
6. Omogućavanje rada sa većim učinkom: U praksi smo na kraju provodili više vremena pregledajući i usmeravajući kod nego pišući ga sami. Ipak, Codex je veoma dobar i u pregledu koda, često hvatajući greške pre nego što budu spojene, čime poboljšava pouzdanost.

Kada smo priznali ove karakteristike, naš model rada postao je jednostavniji. Oslanjali smo se na Codex da obavi ogroman deo teškog posla unutar dobro shvaćenih obrazaca i jasno ograničenih okvira, dok se naš tim fokusirao na arhitekturu, korisničko iskustvo, sistemske promene i završni kvalitet.

Čak ni najbolji novi senior kadar nema odmah pravi pogled za donošenje dugoročnih kompromisa. Da bismo iskoristili Codex i osigurali da njegov rad bude robustan i održiv, bilo je ključno da sami nadgledamo dizajn sistema aplikacije i ključne kompromise. To je uključivalo oblikovanje arhitekture aplikacije, modularizacije, ubacivanja zavisnosti i navigacije; takođe smo implementirali autentifikaciju i osnovne mrežne tokove.

Na toj osnovi napisali smo nekoliko reprezentativnih funkcija od početka do kraja. Koristili smo pravila koja smo želeli da prati cela baza koda i usput dokumentovali obrasce na nivou celog projekta. Upućivanjem Codex-a na reprezentativne funkcije omogućili smo mu da radi nezavisnije u okviru naših standarda. Za projekat za koji procenjujemo da ga je Codex napisao 85%, pažljivo planiran temelj izbegao je skupo vraćanje unazad i refaktorisanje. To je bila jedna od najvažnijih odluka koje smo doneli.

Ideja nije bila da što brže napravimo „nešto što radi“, već da napravimo „nešto što razume kako želimo da stvari rade“. Postoji mnogo „ispravnih“ načina za pisanje koda. Nismo morali da kažemo Codex-u tačno šta da radi; morali smo da mu pokažemo šta je „ispravno“ u našem timu. Kada smo uspostavili početnu tačku i način na koji volimo da gradimo, Codex je bio spreman da počne.

Da bismo videli šta će se desiti, probali smo i instrukciju: „Build the Sora Android app based on the iOS code. Go,” ali smo brzo odustali od tog pravca. Iako je ono što je Codex napravio tehnički radilo, doživljaj proizvoda bio je ispod nivoa. A bez jasnog razumevanja krajnjih tačaka, podataka i korisničkih tokova, jednokratno napisani kod od strane Codex-a bio je nepouzdan (Čak i bez korišćenja agenta, rizično je spojiti hiljade linija koda.)

Pretpostavili smo da će Codex napredovati u sandbox okruženju sa dobro napisanim primerima; i bili smo u pravu. Tražiti od Codex-a da „napravi ovaj ekran sa podešavanjima“ uz gotovo nimalo konteksta bilo je nepouzdano. Tražiti od Codex-a da „napravi ovaj ekran sa podešavanjima koristeći istu arhitekturu i obrasce kao ovaj drugi ekran koji si upravo video“ davalo je znatno bolje rezultate. Ljudi su donosili strukturne odluke i postavljali nepromenljive osnove; Codex je zatim popunjavao velike količine koda unutar te strukture.

Naš sledeći korak u maksimizovanju potencijala Codex-a bio je da utvrdimo kako da mu omogućimo da radi dugo vremena (u skorije vreme, više od 24 sata⁠), bez nadzora.

Na početku rada sa Codex-om odmah smo prelazili na instrukcije poput: „Evo funkcije. Evo nekih datoteka. Molim te, napravi to.“ To je ponekad funkcionisalo, ali je uglavnom proizvodilo kod koji se tehnički kompajlirao, dok je odstupao od naše arhitekture i ciljeva.

Zato smo promenili tok rada. Za svaku promenu koja nije trivijalna, prvo bismo tražili od Codex-a da nam pomogne da razumemo kako sistem i kod funkcionišu. Na primer, tražili bismo mu da pročita skup povezanih datoteka i sažme kako ta funkcija radi; recimo, kako podaci teku od API-ja kroz sloj depoa, model prikaza i do UI-ja. Zatim bismo ispravili ili doradili njegovo razumevanje. (Na primer, ukazali bismo mu da određena apstrakcija zapravo pripada drugom sloju ili da data klasa postoji samo za oflajn režim i ne treba je proširivati.)

Slično kao kada biste uključivali novog, veoma sposobnog kolegu u rad, sarađivali smo sa Codex-om da napravimo čvrst plan implementacije. Taj plan je često ličio na minijaturni dizajn dokument koji usmerava koje datoteke treba menjati, koja nova stanja treba uvesti i kako logika treba da teče. Tek tada bismo tražili od Codex-a da počne da primenjuje plan, korak po korak. Jedan koristan savet: za veoma duge zadatke, kada bismo dostigli granicu našeg prozora konteksta, tražili bismo od Codex-a da sačuva svoj plan u datoteku, što nam je omogućavalo da isti smer primenimo kroz više instanci.

Ispostavilo se da je ova dodatna petlja planiranja vredela vremena. Omogućila nam je da pustimo Codex da dugo radi „bez nadzora“, jer smo poznavali njegove planove. Olakšala je pregled koda, jer smo implementaciju mogli da proverimo u odnosu na plan, umesto da čitamo diff bez konteksta. A kada bi nešto pošlo po zlu, prvo bismo debagovali plan, a kod tek potom.

Ta dinamika podsećala je na način na koji dobar dizajn dokument daje poverenje tehničkom vođi u projekat. Nismo samo generisali kod: proizvodili smo kod koji podržava zajednički plan puta.

Na vrhuncu projekta često smo paralelno pokretali više Codex sesija. Jedna je radila na reprodukciji, druga na pretrazi, treća na obradi grešaka, a ponekad još jedna na testovima ili refaktorisanjima. Više je ličilo na upravljanje timom nego na korišćenje alata.

Svaka sesija bi nam povremeno javljala napredak. Jedna bi mogla da kaže: „Završio sam planiranje ovog modula; evo šta predlažem“, dok bi друга ponudila veliki diff za novu funkciju. Svaka je zahtevala pažnju, povratnu informaciju i pregled. Bilo je neobično slično ulozi tehničkog vođe sa nekoliko novih inženjera, od kojih svi napreduju i svima je potrebno usmerenje.

Rezultat je bio tok saradnje. Sirova sposobnost Codex-a za pisanje koda oslobodila nas je mnogo ručnog kucanja. Imali smo više vremena da razmišljamo o arhitekturi, pažljivo čitamo zahteve za pregled izmena i testiramo aplikaciju.

U isto vreme, ta dodatna brzina značila je da nas je u redu za pregled uvek nešto čekalo. Codex nije zapinjao zbog prebacivanja konteksta, ali mi jesmo. Naše usko grlo u razvoju pomerilo se sa pisanja koda na donošenje odluka, davanje povratnih informacija i integraciju promena.

Tu Brooksovi uvidi dobijaju novo značenje. Ne možete jednostavno da dodajete Codex sesije i očekujete linearna ubrzanja, isto kao što ne možete da nastavite da dodajete inženjere projektu i očekujete da se rok linearno skraćuje. Svaki dodatni „par ruku“, čak i virtuelni, donosi dodatno koordinaciono opterećenje. Postali smo dirigent orkestra, a ne samo brži solo izvođači.

Naš projekat započeo je uz ogromnu odskočnu dasku: Sora je već bio isporučen na iOS-u. Često smo Codex-u pokazivali baze koda za iOS i backend kako bismo mu pomogli da razume ključne zahteve i ograničenja. Tokom projekta šalili smo se da smo ponovo izmislili ideju okvira za više platformi. Zaboravite na React Native ili Flutter; budućnost višeplatformskog razvoja je jednostavno Codex.

Iza te dosetke stoje dva principa:.

1. Logika je prenosiva. Bilo da je kod napisan u Swift-u ili Kotlin-u, osnovna logika aplikacije – modeli podataka, mrežni pozivi, pravila validacije, poslovna logika – ostaje ista. Codex je veoma dobar u čitanju Swift implementacije i pravljenju ekvivalentne u Kotlin-u koja čuva semantiku.
2. Konkretni primeri pružaju moćan kontekst. Nova Codex sesija koja može da vidi „evo tačno kako ovo radi na iOS-u“ i „evo kako je strukturisana Android arhitektura“ daleko je efikasnija od one koja radi samo na osnovu opisa prirodnim jezikom.

Primenujući ove principe, učinili smo iOS, backend i Android depоe dostupnim u istom okruženju. Davali smo Codex-u instrukcije poput:

„Pročitaj ove modele i krajnje tačke u iOS kodu, a zatim predloži plan za implementaciju ekvivalentnog ponašanja na Androidu koristeći naš postojeći API klijent i klase modela.“

Jedan mali, ali koristan trik bio je da u ~/.codex/AGENTS.md navedemo gde se lokalni depoi nalaze i šta sadrže. To je Codex-u olakšalo da pronađe i obilazi relevantan kod.

Praktično smo radili višeplatformski razvoj kroz prevođenje umesto kroz deljenu apstrakciju. Pošto je Codex obavio veći deo tog prevođenja, izbegli smo udvostručavanje troškova implementacije.

Šira pouka je da je za Codex kontekst sve. Codex je radio najbolje kada je razumeo kako funkcija već radi na iOS-u, uparenо sa razumevanjem kako je strukturisana naša Android aplikacija. Kada Codex nije imao taj kontekst, nije „odbijao saradnju“; nagađao je. Što smo ga više tretirali kao novog saigrača i ulagali u davanje pravih ulaza, to je bolje radio.

Do kraja našeg četvoronedeljnog sprinta, korišćenje Codex-a prestalo je da deluje kao eksperiment i postalo je naš podrazumevani razvojni ciklus. Koristili smo ga da razumemo postojeći kod, planiramo promene i implementiramo funkcije. Njegov izlaz smo pregledali isto kao što bismo pregledali rad kolege. To je jednostavno bio način na koji smo isporučivali softver.

Postalo je jasno da razvoj uz pomoć AI-ja ne smanjuje potrebu za rigoroznošću; već je povećava. Koliko god Codex bio sposoban, njegov cilj je da stigne od tačke A do tačke B, odmah. Zato kodiranje uz pomoć AI-ja ne funkcioniše bez ljudi. Softverski inženjeri mogu da razumeju i primene stvarna ograničenja sistema, najbolje načine za arhitekturu softvera i kako da grade imajući u vidu budući razvoj i planove proizvoda. Supermoći softverskog inženjera sutrašnjice biće duboko razumevanje sistema i sposobnost da dugoročno sarađuje sa AI-jem.

Najzanimljiviji delovi softverskog inženjerstva jesu pravljenje ubedljivih proizvoda, dizajniranje skalabilnih sistema, pisanje složenih algoritama i eksperimentisanje sa podacima, obrascima i kodom. Međutim, stvarnost softverskog inženjerstva u prošlosti i sadašnjosti često je prizemnija: centriranje dugmadi, povezivanje krajnjih tačaka i pisanje šablonskog koda. Sada Codex omogućava da se fokusiramo na najznačajnije delove softverskog inženjerstva i razloge zbog kojih volimo svoj zanat.

Kada se Codex postavi u okruženje bogato kontekstom, gde razume vaše ciljeve i kako volite da gradite, svaki tim može da umnoži svoje mogućnosti. Naš osvrt posle lansiranja nije recept koji odgovara svima i ne tvrdimo da smo rešili razvoj uz pomoć AI-ja. Ali se nadamo da će naše iskustvo olakšati pronalaženje najboljih načina da osposobite Codex da osnaži vas.

Kada je Codex lansiran u istraživačkom pregledu pre sedam meseci, softversko inženjerstvo izgledalo je veoma drugačije. Kroz Sora imali smo priliku da istražimo sledeće poglavlje inženjerstva. Kako naši modeli i radni okvir nastavljaju da se poboljšavaju, AI će postajati sve neophodniji deo razvoja.

Šta ćete vi napraviti sa svojim timom Codex-a?