Kako smo koristili Codex za izradu Sore za Android u 28 dana

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

U studenom smo lansirali Sora Android aplikaciju u svijet, omogućujući svakome s Android uređajem da pretvori kratki upit u živopisan video. Na dan lansiranja, aplikacija je dosegla prvo mjesto u Play Storeu. Korisnici Androida generirali su više od milijun videozapisa u prva 24 sata.

Iza lansiranja stoji priča: početna verzija Sorine Android aplikacije izgrađena je u 28 dana, zahvaljujući istom izvođaču koji je dostupan svakom timu ili razvojnom inženjeru: Codexu.

Od 8. listopada do 5. studenog 2025., mali inženjerski tim koji je radio uz Codex i trošio otprilike 5 milijardi tokena, lansirao je Soru za Android od prototipa do globalnog lansiranja. Unatoč svojoj veličini, aplikacija ima rezultat bez padova od 99,9 posto i arhitekturu na koju smo ponosni. Ako se pitate jesmo li koristili tajni model, koristili smo ranu verziju GPT‑5.1‑Codex modela – istu verziju koju bilo koji razvojni inženjer ili poslovanje može koristiti danas putem CLI-ja, IDE proširenja ili web aplikacije.

Kada je Sora bila lansirana na iOS-u, korištenje je naglo poraslo. Ljudi su odmah počeli generirati niz videozapisa. Na Androidu smo, nasuprot tome, imali samo mali interni prototip i sve veći broj unaprijed registriranih korisnika na Google Playu.

Uobičajena reakcija na lansiranje s visokim ulozima i vremenskim pritiskom je povećanje resursa i dodavanje procesa. Proizvodna aplikacija ovog opsega i kvalitete obično bi uključivala mnoge inženjere koji rade mjesecima, usporene koordinacijom. 

Američki računalni arhitekt Fred Brooks slavno je upozorio da „dodavanje više ljudi zakašnjelom softverskom projektu čini da još više kasni.” Drugim riječima, kada pokušavate brzo isporučiti složen projekt, dodavanje više inženjera često može usporiti učinkovitost povećanjem komunikacijskog opterećenja, 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 utjecaj svakog inženjera. 

Radeći na ovaj način, isporučili smo unutarnju konstrukciju Sora za Android zaposlenicima u roku od 18 dana i javno je lansirali 10 dana kasnije. Održavali smo visoke standarde inženjerske prakse na Androidu, ulagali u održivost i držali aplikaciju na istoj razini pouzdanosti koju bismo očekivali od tradicionalnijeg projekta. (Codex nastavljamo intenzivno koristiti i danas kako bismo razvijali i uvodili nove značajke u aplikaciju).

Da biste razumjeli kako smo radili s Codexom, pomaže znati gdje se pozitivno ističe a gdje ga treba dodatno usmjeriti. Tretirati ga to kao novozaposlenog višeg inženjera bio je dobar pristup. Sposobnost Codexa značila je da možemo provoditi više vremena usmjeravajući i pregledavajući kôd nego ga pišući sami.

Gdje Codex treba smjernice

1. Codex još nije sjajan u zaključivanju onoga što mu nije rečeno (npr. vaši preferirani arhitekturni obrasci, strategija proizvoda, stvarno ponašanje korisnika i interne norme ili prečaci).
2. Slično tome, Codex nije mogao vidjeti kao aplikacija zapravo radi: nije mogao otvoriti Soru na uređaju, primijetiti da pomicanje nije u redu ili osjetiti da je tijek zbunjujući. Samo je naš tim mogao je pokriti ove iskustvene zadatke.
3. Svaka instanca zahtijeva uvođenje. Dijeljenje konteksta s jasnim ciljevima, ograničenjima i smjernicama o tome "kako radimo stvari" bilo je ključno za uspješno funkcioniranje Codexa.
4. U istom duhu, Codex se suočavao s izazovima dubokih arhitektonskih prosudbi: prepušten sam sebi, mogao bi uvesti dodatni model prikaza tamo gdje smo zapravo htjeli proširiti postojeći ili premjestiti logiku u UI sloj koji jasno pripada repozitoriju. Njegov instinkt je da pomogne nešto proradi, a ne da daje prednost dugoročnom 'urednom' funkcioniranju.

Otkrili smo da je korisno da Codex stvara i održava velik broj AGENT.md datoteka kroz cijelu bazu kôda. To je olakšalo primjenu istih smjernica i najboljih praksi tijekom sesija. Primjerice, kako bismo osigurali da Codex piše kôd u skladu s našim smjernicama za stil, 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 dubinski, ali širina pokrivenosti bila je korisna u sprječavanju regresija. 
3. Primjena povratnih informacija: na sličan način, Codex dobro reagira na povratne informacije. Kada CI ne uspije, možemo zalijepiti izlaz dnevnika u upit i zamoliti Codex da predloži ispravke.
4. Masivno paralelno, jednokratno izvršavanje: većina neće dosegnuti granice broja sesija koje bi zapravo mogli pokrenuti u bilo kojem trenutku. Vrlo je izvedivo testirati više ideja paralelno i gledati na kôd kao na potrošni materijal.
5. Nudeći novu perspektivu: u raspravama o dizajnu koristili smo Codex kao generativni alat za istraživanje potencijalne točke neuspjeha i otkrivanje novih načina za rješavanje problema. Primjerice, dok smo dizajnirali optimizacije memorije za video player, Codex je pregledao više SDK-ova kako bi predložio pristupe koje ne bismo imali vremena sami obraditi. Uvidi iz Codexovog istraživanja pokazali su se neprocjenjivima u smanjenju memorijskog otiska u konačnoj aplikaciji.
6. Omogućavanje rada s većim učinkom: u praksi smo potrošili više vremena na pregledavanje i usmjeravanje kôda nego na njegovo pisanje. Ipak, Codex je također vrlo dobar u pregledu kôda, često otkrivajući greške prije nego spajanja, čime se poboljšava pouzdanost.

Nakon što smo prepoznali te karakteristike, naš radni model postao je jednostavniji. Oslonili smo se na Codex u obavljanju velikog dijela teškog posla kod razumljivih obrazaca i jasno definiranih okvira, dok se naš tim fokusirao na arhitekturu, korisničko iskustvo, sustavne promjene i konačnu kvalitetu.

Čak ni najbolji novi iskusni zaposlenik nema dovoljno dobru točku gledišta da bi mogao odmah odlučivati o dugoročnim kompromisima. Da biste iskoristili Codex i osigurali da je njegov rad robustan i održiv, bilo je ključno da sami nadgledamo dizajn sustava aplikacije i ključne kompromise. To je uključivalo oblikovanje arhitekture aplikacije, modularizaciju, dodavanje ovisnosti 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 kôda slijedi i dokumentirali obrasce na razini projekta kako smo napredovali. Usmjeravanjem Codexa na reprezentativne značajke, mogao je raditi samostalnije unutar naših standarda. Za projekt za koji procjenjujemo da je 85 % napisao Codex, pažljivo planirana osnova izbjegla je skupo vraćanje unatrag i refaktoriranje kôda. 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 shvaća kako želimo da stvari funkcioniraju." Postoji mnogo "ispravnih" načina pisanja kôda. Nismo trebali reći Codexu točno što da radi; trebali smo pokazati Codexu što je "ispravno" u našem timu. Nakon što smo utvrdili našu početnu točku i kako volimo graditi naš kôd, Codex je bio spreman početi s radom.

Da bismo vidjeli što bi se moglo dogoditi, pokušali smo s upitom: "Izgradi Sora Android aplikaciju na temelju iOS kôda. Kreni.” - ali smo brzo odustali od tog smjera. Iako je ono što je Codex stvorio tehnički funkcioniralo, iskustvo proizvoda bilo je ispodprosječno. I bez jasnog razumijevanja krajnjih točaka, podataka i tokova korisnika, Codexov jednokratni kȏd bio je nepouzdan (čak i bez korištenja agenta (izvršitelja), rizično je spojiti tisuće redaka kôda.) 

Pretpostavili smo da će Codex napredovati u izoliranom (sandbox) okruženju s dobro napisanim primjerima; i bili smo u pravu. Zatražiti od Codexa da "izradi ovaj zaslon postavki" s gotovo nikakvim kontekstom bilo je nepouzdano. Zamoliti Codex da "izgradi ovaj zaslon postavki koristeći istu arhitekturu i uzorke kao i ovaj drugi zaslon koji je upravo pokazan" pokazalo se daleko boljim. Ljudi su donijeli strukturne odluke i postavili konstante; Codex je zatim ispunio velike količine kôda unutar te strukture.

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

Na početku korištenja Codexa, prešli smo na upite poput: "Ovdje je značajka." Evo nekoliko datoteka. Izgradi to. To je ponekad funkcioniralo, ali uglavnom je stvaralo kôd koji se tehnički kompajlirao, ali se udaljavao od naše arhitekture i ciljeva.

Dakle, promijenili smo tijek rada. Za svaku značajnu promjenu, prvo smo zamolili Codex da nam pomogne razumjeti kako sustav i kôd funkcioniraju. Primjerice, zamolili bismo ga da pročita skup povezanih datoteka i sažme kako ta značajka funkcionira; recimo, kako podaci teku od API-ja kroz sloj repozitorija, model prikaza i u korisničko sučelje. Tada bismo ispravili ili poboljšali njegovo razumijevanje. (Npr., istaknuli bismo da određena apstrakcija zapravo pripada u drugi sloj ili da određena klasa postoji samo za izvanmrežni način rada i ne bi se smjela proširivati.)

Slično kao što biste angažirali novog, vrlo sposobnog člana tima, surađivali smo s Codexom kako bismo stvorili čvrst 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, kada dosegnemo granicu našeg kontekstnog prozora, zamolili bismo Codex da spremi svoj plan u datoteku, omogućujući nam primjenu istog smjera kroz instance.

Ova dodatna planerska petlja pokazala se vrijednom uloženog vremena. To nam je omogućilo da Codex radi bez nadzora dulje vrijeme, jer smo znali njegove planove. To je olakšalo pregled kôda, jer smo mogli provjeriti implementaciju prema našem planu, umjesto da čitamo razlike bez konteksta. I kada bi nešto pošlo po zlu, mogli bismo prvo izvršiti ispravljanje pogrešaka u planu, a zatim u kôdu. 

Dinamika je bila slična načinu na koji dobar dizajnerski dokument daje tehničkom voditelju sigurnost u projekt. Nismo samo smišljali kôd: proizvodili smo kôd koji podržava zajednički plan.

Na vrhuncu projekta, često smo istovremeno pokretali više Codex sesija. Jedan je radio na reprodukciji, drugi na pretraživanju, treći na rukovanju pogreškama, a ponekad još jedan na testiranju ili prepravkama. Osjećaj je bio manje kao korištenje alata, a više kao upravljanje timom.

Svaka sesija bi nas povremeno izvještavala o napretku. Jedan Codex bi rekao: "Završio sam s planiranjem ovog modula; evo što predlažem," dok bi drugi ponudio velike razlike za novu značajku. Svaki je zahtijevao pozornost, povratne informacije i pregled. Bilo je to vrlo slično ulozi tehničkog voditelja s nekoliko novih inženjera koji svi napreduju i trebaju smjernice.

Rezultat je bio zajednički tijek izvedbe. Sirova sposobnost kodiranja Codexa oslobodila nas je od mnogo ručnog tipkanja. Imali smo više vremena da razmislimo o arhitekturi, pažljivo pročitamo zahtjeve za povlačenje 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še usko grlo u razvoju pomaknulo se s pisanja kôda na donošenje odluka, davanje povratne informacije i integriranje promjena.

Ovdje Brooksovi uvidi dolaze do izražaja na nov način. Ne možete jednostavno dodati Codex sesije i očekivati linearna ubrzanja, baš kao što ne možete nastaviti dodavati inženjere u projekt i očekivati da će se radni raspored linearno smanjivati. Svaki dodatni "par ruku", čak i virtualni, dodaje opterećenje koordinaciji. Postali smo dirigent orkestra umjesto bržih solo svirača.

Naš smo projekt započeli s velikom prednošću: Sora je već bila isporučena na iOS-u. Često smo usmjeravali Codex na iOS i pozadinske kodne baze kako bismo mu pomogli razumjeti ključne zahtjeve i ograničenja. Tijekom projekta smo se šalili da smo ponovno izmislili ideju okvira za više platformi. Zaboravite na React Native ili Flutter; budućnost cross-platform razvoja je samo Codex.

Iza te dosjetke nalaze se dva načela:.

1. Logika je prenosiva. Bez obzira je li kôd napisan u Swiftu ili Kotlinu, osnovna logika aplikacije – modeli podataka, mrežni pozivi, pravila provjere valjanosti, poslovna logika – ostaje ista. 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 "ovo je točno onako kako ovo funkcionira na iOS-u" i "ovdje je Android arhitektura" daleko je učinkovitija od one koja rukuje samo s opisima na prirodnom jeziku.

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

Pročitaj ove modele i krajnje točke u iOS kôdu, 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 detaljno opisati u ~/.codex/AGENTS.md gdje se nalaze lokalni repozitoriji i što oni sadrže. To je Codexu olakšalo otkrivanje i navigaciju relevantnim kôdom.

Učinkovito smo provodili razvoj na više platformi kroz prevođenje umjesto zajedničke apstrakcije. 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 značajka već funkcionira u iOS-u, u kombinaciji s razumijevanjem kako je naša Android aplikacija strukturirana. Kada Codexu nedostaje taj kontekst, nije "odbijao surađivati"; on je nagađao. Što smo ga više tretirali kao novog člana tima i ulagali u davanje pravih unosa za njega, to je bolje funkcionirao.

Do kraja našeg četverotjednog 'sprinta', korištenje Codexa prestalo je biti eksperiment i postalo je dio našeg zadanog razvojnog ciklusa. Koristili smo ga za razumijevanje postojećeg kôda, plan promjena i implementaciju značajki. Pregledali smo njegov izlaz na isti način kao što bismo pregledali kolegin. To je jednostavno bio način na koji smo isporučivali softver.

Postalo je jasno da razvoj uz pomoć umjetne inteligencije ne smanjuje potrebu za strogošću; povećava je. Koliko god Codex bio sposoban, njegov cilj je sada doći od točke A do točke B. Zato AI-pomognuto kodiranje ne funkcionira bez ljudi. Softverski inženjeri mogu razumjeti i primijeniti stvarna ograničenja sustava, najbolje načine za projektiranje softvera i kako graditi s obzirom na budući razvoj i planove proizvoda. Supermoći softverskog inženjera budućnosti bit će duboko razumijevanje sustava i sposobnost suradnje s umjetnom inteligencijom tijekom dugih vremenskih razdoblja. 

Najzanimljiviji aspekti softverskog inženjerstva uključuju izradu privlačnih proizvoda, dizajn skalabilnih sustava, pisanje složenih algoritama i eksperimentiranje s podacima, uzorcima i kôdom. Međutim, stvarnosti softverskog inženjerstva prošlosti i sadašnjosti često su prilično svakodnevne: centriranje gumbi, povezivanje krajnjih točaka i pisanje predložaka. Sada nam Codex omogućuje usredotočiti se na najznačajnije dijelove softverskog inženjerstva i razloge zbog kojih volimo svoj 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 visoko podići svoje sposobnosti. Naša retrospektiva lansiranja nije univerzalni recept i ne tvrdimo da smo umjetnom inteligencijom riješili razvoj. Ali, nadamo se da će naše iskustvo olakšati pronalaženje najboljih načina za osnaživanje Codexa kako bi on osnažio vas. 

Kada je Codex pokrenut u istraživačkom pretprikazu prije sedam mjeseci, softversko inženjerstvo izgledalo je vrlo drugačije. Putem Sore, imali smo priliku istražiti sljedeće poglavlje inženjeringa. Kako se naši modeli i alati nastavljaju poboljšavati, umjetna inteligencija postat će sve neophodniji dio izgradnje. 

Što ćete napraviti sa svojim vlastitim Codex timom?