Kako smo koristili Codex da izgradimo Soru za Android u 28 dana

Od 26.04.2026., proizvod Sora više nije dostupan.

U novembru smo lansirali Soru Android aplikaciju za cijeli svijet, omogućavajući svakome s Android uređajem da pretvori kratak upit u živopisan video. Na dan lansiranja, aplikacija je dostigla prvo mjesto u Play Store-u. Android korisnici su generirali više od milion videa u prvih 24 sata.

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

Od 8. oktobra do 5. novembra 2025. godine, mali inženjerski tim koji je radio zajedno sa Codexom i trošio otprilike 5 milijardi tokena, lansirao je Sora za Android od prototipa do globalnog lansiranja. Uprkos svojoj veličini, aplikacija ima stopu bez padova od 99,9 posto i arhitekturu na koju smo ponosni. Ako se pitate da li smo koristili tajni model, koristili smo ranu verziju GPT‑5.1‑Codex model – ista verzija koju bilo koji programer ili Business može koristiti danas putem CLI-ja, IDE ekstenzije ili web aplikacije.

Kada je Sora pokrenuta na iOS-u, korištenje je eksplodiralo. Ljudi su odmah počeli generirati niz videa. Na Androidu, nasuprot tome, imali smo samo mali interni prototip i sve veći broj unaprijed registriranih korisnika na Google Play-u.

Uobičajena reakcija na lansiranje s visokim ulozima i pod vremenskim pritiskom je povećati resurse i dodati proces. Proizvodna aplikacija ovog obima i kvaliteta obično bi uključivala mnogo inženjera koji rade mjesecima, usporenih koordinacijom. 

Američki arhitekt računarskih sistema Fred Brooks je poznato upozorio da „dodavanje više ljudi na zakašnjeli softverski projekat čini ga još kasnijim.“ Drugim riječima, kada pokušavate brzo isporučiti složen projekat, dodavanje više inženjera često može usporiti efikasnost zbog povećanja komunikacijskih troškova, fragmentacije zadataka i troškova integracije. Umjesto da zanemarimo ovaj uvid, iskoristili smo ga; okupili smo snažan tim od četiri inženjera – svi opremljeni Codexom kako bi drastično povećali uticaj svakog inženjera. 

Radeći na ovaj način, isporučili smo internu verziju Sora za Android uposlenicima za 18 dana i lansirali je javno 10 dana kasnije. Održavali smo visoke standarde u inženjerskim praksama za Android, ulagali u održivost i držali aplikaciju na istom nivou pouzdanosti koji bismo očekivali od tradicionalnijeg projekta. (Također nastavi koristiti Codex opsežno danas kako bismo razvijali i donosili nove funkcije u aplikaciju).

Da biste razumjeli kako smo radili s Codexom, pomaže znati gdje se ističe i gdje mu je potrebna usmjerenost. Tretirati to kao da je novozaposleni viši inženjer bio dobar pristup. Sposobnost Codexa značila je da možemo provoditi više vremena usmjeravajući i pregledavajući kod nego pišući ga sami.

Gdje Codex treba smjernice

1. Codex još uvijek nije dobar u zaključivanju onoga što mu nije rečeno (npr. vaši preferirani arhitektonski obrasci, strategija proizvoda, stvarno ponašanje korisnika i interne norme ili prečice).
2. Slično tome, Codex nije mogao vidjeti kako aplikacija zapravo radi: Nije mogao otvoriti Sora na uređaju, primijetiti da je skrolovanje neobično ili osjetiti da je tok zbunjujući. Samo naš tim bi mogao pokriti ove iskustvene zadatke.
3. Svaki primjer zahtijeva pristupanje. Dijeljenje konteksta s jasnim ciljevima, ograničenjima i smjernicama o tome "kako radimo stvari" bilo je ključno za uspješno izvršavanje Codexa.
4. U istom duhu, Codex se borio s dubokim arhitektonskim odlukama: Prepušten sam sebi, mogao bi uvesti dodatni model pogleda tamo gdje smo zapravo željeli proširiti postojeći ili gurnuti logiku u UI sloj koja je očigledno pripadala repozitoriju. Njegov instinkt je da nešto proradi, a ne da daje prednost dugoročnoj čistoći.

Otkrili smo da je korisno da Codex kreira i održava velik broj AGENT.md datoteka kroz cijelu bazu koda. Ovo je olakšalo primjenu istih smjernica i najboljih praksi kroz sesije. Na primjer, da bismo osigurali da Codex piše kod prema našim smjernicama stila, dodali smo sljedeće u našu glavnu datoteku AGENTS.md:

Gdje Codex briljira

1. Brzo čitanje i razumijevanje velikih kodnih baza: Codex poznaje gotovo sve glavne programske jezike, što olakšava korištenje istih koncepata na mnogim platformama bez složenih apstrakcija.
2. Pokrivenost testiranjem: Codex je (jedinstveno) entuzijastičan u pisanju jediničnih testova kako bi pokrio širok spektar slučajeva. Nije svaki test bio dubok, ali je širina pokrivenosti bila korisna u sprječavanju regresija. 
3. Primjena povratnog odgovora: Na sličan način, Codex je dobar u reagovanju na povratni odgovor. Kada CI ne uspije, možemo zalijepiti izlaz iz loga u upit i zamoliti Codex da predloži popravke.
4. Masivno paralelno, jednokratno izvršavanje: Većina neće dostići granice broja sesija koje bi zapravo mogli pokrenuti u bilo kojem trenutku. Vrlo je izvodljivo testirati više ideja paralelno i gledati na kod kao na potrošni materijal.
5. Nudeći novu perspektivu: U dizajnerskim diskusijama koristili smo Codex kao generativni alat za istražiti potencijalne tačke neuspjeha i otkrivanje novih načina za rješavanje problema. Na primjer, dok smo dizajnirali optimizacije memorije video plejera, Codex je pregledao više SDK-ova kako bi predložio pristupe koje ne bismo imali vremena obraditi. Uvidi iz Codexovog istraživanja pokazali su se neprocjenjivima u smanjenju memorijskog otiska u finalnoj aplikaciji.
6. Omogućavanje rada s većim uticajem: U praksi smo na kraju provodili više vremena pregledajući i usmjeravajući kod nego pišući ga sami. Rečeno to, Codex je također vrlo dobar u pregledu koda, često otkrivajući greške prije nego što se spoje, čime se poboljšava pouzdanost.

Kada smo prepoznali ove karakteristike, naš radni model postao je jednostavniji. Oslonili smo se na Codex da obavi veliki dio teškog posla unutar dobro razumljivih obrazaca i jasno definisanih okvira, dok se naš tim fokusirao na arhitekturu, korisničko iskustvo, sistemske promjene i konačni kvalitet.

Čak ni najbolji novi, stariji zaposlenik nema pravi uvid za donošenje dugoročnih kompromisa odmah. Kako biste iskoristili Codex i osigurali da njegov rad bude robustan i održiv, bilo je ključno da sami nadgledate dizajn sistema aplikacije i ključne kompromise. Ovo je uključivalo oblikovanje arhitekture aplikacije, modularizaciju, ubrizgavanje zavisnosti i navigaciju; također smo implementirali autentifikaciju i osnovne mrežne tokove. 

Na temelju ove osnove, napisali smo nekoliko reprezentativnih značajki od početka do kraja. Koristili smo pravila koja smo željeli da cijela baza koda slijedi i dokumentirali obrasce na razini projekta dok smo napredovali. Usmjeravanjem Codexa na reprezentativne značajke, bio je u mogućnosti raditi samostalnije unutar naših standarda. Za projekat za koji procjenjujemo da je 85% napisan od strane Codexa, pažljivo planirana osnova izbjegla je skupo vraćanje unazad i refaktorisanje. To je bila jedna od najvažnijih odluka koje smo donijeli. 

Ideja nije bila napraviti „nešto što radi“ što je brže moguće, već napraviti „nešto što shvata kako želimo da stvari funkcionišu“. Postoji mnogo „ispravnih“ načina za pisanje koda. Nismo trebali reći Codexu tačno šta da radi; trebali smo pokazati Codexu šta je „ispravno“ u našem timu. Kada smo utvrdili naš početni položaj i kako volimo graditi, Codex je bio spreman započeti.

Da bismo vidjeli šta će se dogoditi, pokušali smo sa upitom: „Izgradi Sora Android aplikaciju na osnovu iOS koda. Go,” ali su brzo odustali od tog puta. Iako je ono što je Codex kreirao tehnički funkcionisalo, iskustvo korištenja proizvoda bilo je ispod prosjeka. I bez jasnog razumijevanja krajnjih tačaka, podataka i tokova korisnika, Codexov jednokratni kod bio je nepouzdan (Čak i bez korištenja agenta, rizično je spojiti tisuće linija koda.) 

Pretpostavili smo da će Codex napredovati u sandbox okruženju s dobro napisanim primjerima; i bili smo u pravu. Tražiti od Codexa da „izgradi ovaj ekran postavki“ s gotovo nikakvim kontekstom bilo je nepouzdano. Zamoliti Codex da „izgradi ovaj ekran postavki koristeći istu arhitekturu i obrasce kao i ovaj drugi ekran koji ste upravo vidjeli“ funkcionisalo je mnogo bolje. Ljudi su donijeli strukturne odluke i postavili invarijante; Codex je zatim popunio velike količine koda unutar te strukture.

Naš sljedeći korak u maksimiziranju potencijala Codexa bio je smisliti kako omogućiti Codexu da radi duže vremenske periode (nedavno, više od 24 sata⁠), bez nadzora.

Na početku korištenja Codexa, prešli smo na upite poput: „Evo je funkcija. Evo nekoliko datoteka. Molim te, izgradite to.” To je ponekad funkcionisalo, ali uglavnom je proizvodilo kod koji se tehnički kompajlirao, dok se udaljavalo od naše arhitekture i ciljeva.

Tako smo promijenili tijek rada. Za svaku značajnu promjenu, prvo smo tražili od Codexa da nam pomogne razumjeti kako sistem i kod funkcionišu. Na primjer, tražili bismo da pročita skup povezanih datoteka i sažme kako ta funkcija radi; na primjer, kako podaci teku od API-ja kroz sloj repozitorija, model prikaza i u korisnički interfejs. Tada bismo ispravili ili poboljšali njegovo razumijevanje. (Na primjer, istakli bismo da određena apstrakcija zaista pripada u drugi sloj ili da određena klasa postoji samo za offline režim i ne bi trebala biti proširena.)

Slično kao što biste angažirali novog, visoko sposobnog saigrača, radili smo s Codexom kako bismo kreirali solidan plan implementacije. Taj plan često je izgledao kao minijaturni dizajnerski dokument koji usmjerava koje datoteke treba promijeniti, koja nova stanja treba uvesti i kako bi logika trebala teći. Tek tada smo zamolili Codex da počne primjenjivati plan, korak po korak. Jedan koristan savjet: za vrlo duge zadatke, gdje dosežemo ograničenje našeg kontekstnog prozora, zamolili bismo Codex da sačuvati svoj plan u datoteku, omogućavajući nam da primijenimo isti smjer kroz instance.

Ispostavilo se da je ovaj dodatni planerski krug bio vrijedan vremena. To nam je omogućilo da Codex radi „bez nadzora” tokom dugih perioda, jer smo znali njegove planove. To je olakšalo pregled koda, jer smo mogli provjeriti implementaciju prema našem planu umjesto da čitamo razliku bez konteksta. A kada nešto pođe po zlu, mogli bismo prvo otkloniti neispravnosti u planu, a zatim u kodu. 

Dinamika je bila slična načinu na koji dobar dizajnerski dokument daje tehničkom voditelju povjerenje u projekt. Nismo samo generirali kod: proizvodili smo kod koji podržava zajednički plan puta.

Na vrhuncu projekta, često smo istovremeno pokretali više sesija Codexa. Jedan je radio na reprodukciji, drugi na pretraživanju, treći na rukovanju greškama, a ponekad još jedan na testiranju ili refaktorisanjima. Osjećalo se manje kao korištenje alata, a više kao upravljanje timome.

Svaka sesija bi nam periodično javljala nazad o napretku. Neko bi mogao reći: „Završio sam s planiranjem ovog modula; evo šta predlažem,” dok bi drugi ponudio veliki diff za novu funkcionalnost. Svaki je zahtijevao pažnju, povratni odgovor i pregled. Bilo je neobično slično biti tehnički lider s nekoliko novih inženjera, svi su napredovali, svi su trebali smjernice.

Rezultat je bio zajednički tok. Codex-ova osnovna sposobnost kodiranja oslobodila nas je mnogo ručnog tipkanja. Imali smo više vremena da razmislimo o arhitekturi, pažljivo pročitamo pull zahtjeve i testiramo aplikaciju. 

Istovremeno, ta dodatna brzina značila je da smo uvijek imali nešto što čeka u našem redu za pregled. Codex nije bio blokiran promjenom konteksta, ali mi jesmo. Naša uska grla u razvoju su se pomjerila sa pisanja koda na donošenje odluka, davanje povratnog odgovora i integraciju promjena.

Ovdje Brooksovi uvidi dolaze do izražaja na novi način. Ne možete jednostavno dodati Codex sesije i očekivati linearna ubrzanja, isto kao što ne možete nastaviti dodavati inženjere na projekt i očekivati da će se raspored linearno smanjivati. Svaki dodatni „par ruku”, čak i virtualni, dodaje teret koordinacije. Postali smo dirigent orkestra umjesto samo bržih solo svirača.

Započeli smo naš projekat s velikim korakom: Sora je već bila isporučena na iOS-u. Često smo usmjeravali Codex na iOS i backend kodne baze kako bismo mu pomogli da razumije ključne zahtjeve i ograničenja. Tokom projekta smo se šalili da smo ponovo izmislili ideju okvira za više platformi. Zaboravite na React Native ili Flutter; budućnost cross-platform razvoja je samo Codex.

Ispod dosjetke nalaze se dva principa:.

1. Logika je prenosiva. Bilo da je kod napisan u Swiftu ili Kotlinu, osnovna logika aplikacije – modeli podataka, mrežni pozivi, pravila provjere valjanosti, Business logika – ostaju isti. Codex je vrlo dobar u čitanju Swift implementacije i izradi ekvivalenta u Kotlinu koji zadržava semantiku.
2. Konkretni primjeri pružaju snažan kontekst. Svježa Codex sesija koja može vidjeti „ovdje je tačno kako ovo funkcioniše na iOS-u” i „ovdje je Android arhitektura” je daleko efikasnija od one koja radi samo na osnovu opisa u prirodnom jeziku.

Primjenjujući ove principe, učinili smo iOS, backend i Android repozitorije dostupnim u istom okruženju. Dali smo Codexu upite kao što su:

Pročitajte ove modele i krajnje tačke u iOS kodu, a zatim predložite 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 detaljno opisati u ~/.codex/AGENTS.md gdje se nalaze lokalni repozitoriji i što sadrže. To je olakšalo Codexu otkrivanje i navigaciju relevantnim kodom.

Efektivno smo radili na razvoju višeplatformskog softvera putem prevođenja umjesto kroz zajedničku apstrakciju. Budući da je Codex obavio većinu prijevoda, izbjegli smo udvostručenje troškova implementacije.

Šira lekcija je da je za Codex kontekst sve. Codex je najbolje radio kada je shvatio kako funkcija već radi na iOS-u, u kombinaciji s razumijevanjem kako je naša Android aplikacija strukturirana. Kada Codex nije imao taj kontekst, nije „odbijao surađivati”; već je nagađao. Što smo ga više tretirali kao novog člana tima i ulagali u davanje pravih unosa, to je bolje funkcionisalo.

Do kraja našeg četverosedmičnog sprinta, korištenje Codexa prestalo je biti eksperiment i postalo je naš predodređeni razvojni ciklus. Koristili smo ga za razumijevanje postojećeg koda, plan promjena i implementaciju funkcionalnosti. Pregledali smo njegov izlaz na isti način kao što bismo pregledali izlaz kolege. To je jednostavno bio način na koji smo isporučivali softver.

Postalo je jasno da razvoj uz pomoć AI ne smanjuje potrebu za rigoroznošću; povećava je. Koliko god Codex bio sposoban, njegov cilj je da sada stigne od tačke A do B. Ovo je razlog zašto AI-asistirano kodiranje ne funkcioniše bez ljudi. Softverski inženjeri mogu razumjeti i primijeniti stvarna ograničenja sistema, najbolje načine za arhitekturu softvera i kako graditi imajući u vidu budući razvoj i planove proizvoda. Super moći softverskog inženjera budućnosti će biti duboko razumijevanje sistema i sposobnost suradnje s umjetnom inteligencijom kroz duge vremenske horizonte. 

Najzanimljiviji dijelovi softverskog inženjeringa su izgradnja privlačnih proizvoda, dizajniranje skalabilnih sistema, pisanje složenih algoritama i eksperimentisanje s podacima, obrascima i kodom. Međutim, stvarnosti softverskog inženjeringa prošlosti i sadašnjosti često su prilično svakodnevne: centriranje dugmadi, povezivanje krajnjih tačaka i pisanje šablonskog koda. Sada, Codex omogućava da se usredotočite na najznačajnije dijelove softverskog inženjeringa i razloge zbog kojih volimo naš zanat.

Kada je Codex postavljen u okruženju bogatom kontekstom gdje razumije vaše ciljeve i način na koji volite graditi, bilo koji tim može umnožiti svoje sposobnosti. Naša retrospektiva lansiranja nije univerzalni recept, i ne tvrdimo da smo riješili razvoj uz pomoć AI. Ali nadamo se da će naše iskustvo olakšati pronalaženje najboljih načina da osnažimo Codex da osnaži vas. 

Kada je Codex lansiran u istraživačkom pregledu prije sedam mjeseci, softversko inženjerstvo izgledalo je vrlo drugačije. Kroz Soru, imali smo priliku istražiti sljedeći poglavlje inženjeringa. Kako se naši modeli i alati nastavljaju poboljšavati, AI će postati sve neophodniji dio izgradnje. 

Šta ćete napraviti sa svojim vlastitim timom Codexa?