Kako smo uporabili Codex za izdelavo Sora za Android v 28 dneh

Od 26. aprila 2026 naprej izdelek Sora ne bo več na voljo.

Novembra smo svetu predstavili aplikacijo Sora za Android, ki vsakomur z napravo Android omogoča, da kratek poziv spremeni v živahen videoposnetek. Na dan lansiranja je aplikacija dosegla prvo mesto v trgovini Play Store. Uporabniki Androida so ustvarili več kot milijon videoposnetkov v prvih 24 urah.

Za lansiranjem stoji zgodba: začetna različica produkcijske Android aplikacije Sora je bila zgrajena v 28 dneh, zahvaljujoč istemu agentu, ki je na voljo vsaki ekipi ali razvijalcu: Codex.

Od 8. oktobra do 5. novembra 2025 je podporna inženirska ekipa, ki je sodelovala s Codexom in porabila približno 5 milijard tokenov, lansirala Soro za Android od prototipa do predstavitve na globalni ravni. Kljub svoji velikosti ima aplikacija stopnjo brez zrušitev 99,9 odstotka in arhitekturo, na katero smo ponosni. Če se sprašujete, ali smo uporabili skrivni model, smo uporabili zgodnjo različico GPT‑5.1‑Codex model – isto različico, ki jo lahko danes uporablja vsak razvijalec ali Business prek CLI, razširitve IDE ali spletna aplikacija.

Ko je Sora izšla na iOS, je uporaba močno narasla. Ljudje so takoj začeli ustvarjati niz videoposnetkov. Na Androidu pa smo imeli le majhen interni prototip in naraščajoče število predregistriranih uporabnikov na Google Playu.

Pogost odziv na lansiranje z visokim tveganjem in časovnim pritiskom je kopičenje virov in dodajanje procesov. Produkcijska aplikacija takšnega obsega in kakovosti bi običajno vključevala veliko inženirjev, ki bi delali več mesecev, in bi jih koordinacija upočasnjevala. 

Ameriški računalniški arhitekt Fred Brooks je postal slaven, ko je opozoril, da "dodajanje več ljudi k zamudnemu programskemu projektu tega naredi še bolj zamudnega." Z drugimi besedami, ko poskušate hitro dostaviti kompleksen projekt, lahko dodajanje več inženirjev pogosto zmanjša učinkovitost zaradi povečanja komunikacijskih obremenitev, razdrobljenosti nalog in stroškov integracije. Namesto da bi to spoznanje ignorirali, smo se nanj oprli; sestavili smo močno ekipo štirih inženirjev – vsi opremljeni s Codexom za drastično povečanje vpliva vsakega inženirja. 

Na ta način smo interno različico Sora za Android poslali zaposlenim v 18 dneh in jo javno lansirali 10 dni pozneje. Ohranili smo visoke standarde inženirskih praks za Android, vlagali v vzdržljivost in aplikacijo držali na enaki ravni zanesljivosti, kot bi jo pričakovali od bolj tradicionalnega projekta. (Tudi danes nadaljujemo obsežno uporabljati Codex, da razvijamo in uvajamo nove funkcije v aplikacijo).

Da bi razumeli, kako smo delali s Codexom, je koristno vedeti, kje se izkaže in kje potrebuje usmeritev. Obravnavati to kot novo zaposlenega višjega inženirja je bil dober pristop. Zmožnost Codexa je pomenila, da smo lahko več časa posvetili usmerjanju in pregledovanju kode, namesto da bi jo pisali sami.

Kjer Codex potrebuje smernice

1. Codex še ni odličen pri sklepanju tega, česar mu ni bilo povedano (npr. vaši prednostni arhitekturni vzorci, strategija izdelka, resnično vedenje uporabnikov in notranje norme ali bližnjice).
2. Ravno tako tudi Codex ni mogel videti dejanskega delovanja aplikacije: ni mogel odpreti Sore na napravi, opaziti, da je drsenje nenavadno, ali zaznati, da je potek zmeden. Le naša ekipa bi lahko pokrila te izkustvene naloge.
3. Vsaka instanca zahteva uvajanje. Deljenje sobesedila z jasnimi cilji, omejitvami in navodili o "načinu našega dela" je bilo ključno za uspešno izvedbo Codexa.
4. V istem duhu se je Codex soočal z globokimi arhitekturnimi odločitvami: Če bi bil prepuščen samemu sebi, bi lahko uvedel dodatni model pogleda tam, kjer smo resnično želeli razširiti obstoječega, ali pa bi logiko potisnil v sloj uporabniškega vmesnika, ki bi jasno sodila v repozitorij. Njegov instinkt je, da nekaj deluje, ne pa da daje prednost dolgoročni urejenosti.

Ugotovili smo, da je koristno, da Codex ustvari in vzdržuje veliko število datotek AGENT.md po celotni kodi. To je omogočilo enostavno uporabo enakih smernic in najboljših praks skozi seje. Na primer, da bi zagotovili, da Codex piše kodo v skladu z našimi smernicami za slog, smo na najvišjo raven datoteke AGENTS.md dodali naslednje:

Kjer Codex izstopa

1. Hitro branje in razumevanje obsežnih kodnih zbirk: Codex pozna praktično vse glavne programske jezike, kar olajša uporabo istih konceptov na številnih platformah brez zapletenih abstrakcij.
2. Testiranje pokritosti: Codex je (edinstveno) navdušen nad pisanjem enotnih testov za pokritje širokega spektra primerov. Ni bil vsak test poglobljen, vendar je bila širina pokritosti koristna pri preprečevanju regresij. 
3. Uporaba povratnih informacij: Na podoben način se Codex dobro odziva na povratne informacije. Ko je CI spodletel, smo lahko prilepili rezultate dnevnika v poziv in prosili Codex, naj predlaga popravke.
4. Masovno vzporedno, enkratno izvajanje: Večina ne bo dosegla omejitve števila sej, ki bi jih lahko dejansko izvajala hkrati. Zelo izvedljivo je preizkusiti več idej hkrati in kodo obravnavati kot potrošno.
5. Ponujanje nove perspektive: V razpravah o oblikovanju smo Codex uporabili kot generativno orodje, da razišče potencialne točke odpovedi in odkrivanja novih načinov za reševanje problema. Na primer, medtem ko smo načrtovali optimizacije pomnilnika za video predvajalnik, je Codex pregledal več SDK-jev in predlagal pristope, ki jih sami ne bi imeli časa obdelati. Spoznanja iz raziskav Codexa so se izkazala za neprecenljiva pri zmanjševanju pomnilniškega odtisa v končni aplikaciji.
6. Omogočanje dela z večjim vplivom: V praksi smo na koncu porabili več časa za pregledovanje in usmerjanje kode kot za njeno pisanje. Kljub temu je Codex zelo dober tudi pri pregledu kode, saj pogosto zazna napake, preden pride do združitve, kar izboljša zanesljivost.

Ko smo priznali te značilnosti, je naš delovni model postal bolj preprost. Zanašali smo se na Codex, da je opravil veliko zahtevnega dela znotraj dobro razumljenih vzorcev in omejenih obsegov, medtem ko se je naša ekipa osredotočala na arhitekturo, uporabniško izkušnjo, sistemske spremembe in končno kakovost.

Tudi najboljši novi, višji zaposleni nima takojšnjega pravega pogleda za sprejemanje dolgoročnih kompromisov. Da bi izkoristili Codex in zagotovili, da je bilo njegovo delo robustno in vzdržljivo, je bilo ključno, da smo sami nadzorovali zasnovo sistemov aplikacije in ključne kompromise. To je vključevalo oblikovanje arhitekture aplikacije, modularizacijo, vstavljanje odvisnosti in navigacijo; prav tako smo izvedli preverjanje pristnosti in osnovne omrežne tokove. 

Na tej osnovi smo napisali nekaj reprezentativnih funkcij od začetka do konca. Uporabljali smo pravila, ki smo želeli, da jih upošteva celotna koda, in med nadaljevanjem dokumentirali projektne vzorce. Z usmerjanjem Codexa na reprezentativne značilnosti je lahko deloval bolj samostojno v okviru naših standardov. Za projekt, za katerega ocenjujemo, da je bil 85 % napisan s Codexom, je skrbno načrtovana osnova preprečila drago nazadovanje in predelavo. To je bila ena najpomembnejših odločitev, ki smo jih sprejeli. 

Namen ni bil čim hitreje ustvariti "nekaj, kar deluje", temveč "nekaj, kar razume, kako želimo, da stvari delujejo." Obstaja veliko "pravilnih" načinov za pisanje kode. Ni nam bilo treba Codexu natančno povedati, kaj naj naredi; morali smo Codexu pokazati, kaj je za našo ekipo "pravilno". Ko smo določili našo izhodiščno točko in kako želimo graditi, je bil Codex pripravljen za začetek.

Da bi videli, kaj bi se zgodilo, smo poskusili z navodilom: "Zgradite aplikacijo Sora za Android na podlagi kode za iOS. Pojdi," vendar je hitro opustil to pot. Čeprav je to, kar je Codex ustvaril, tehnično delovalo, je bila izkušnja izdelka podpovprečna. In brez jasnega razumevanja končnih točk, podatkov in tokov uporabnikov je bila Codexova enkratna koda nezanesljiva (Tudi brez uporabe agenta je tvegano združitev tisoče vrstic kode.) 

Predvidevali smo, da bo Codex uspeval v peskovniku dobro napisanih primerov; in imeli smo prav. Zahtevati od Codexa, naj "ustvari ta zaslon z nastavitvami" s skoraj nobenim sobesedilom, je bilo nezanesljivo. Zahteva Codexu, naj "zgradi ta zaslonski prikaz z uporabo iste arhitekture in vzorcev kot ta drugi zaslon, ki ste ga pravkar videli," je delovala veliko bolje. Ljudje so sprejeli strukturne odločitve in določili nespremenljivke; Codex je nato zapolnil velike količine kode znotraj te strukture.

Naš naslednji korak pri maksimiranju potenciala Codexa je bilo, da bi ugotovili, kako omogočiti Codexu, da bo deloval dlje časa (trenutno več kot 24 ur⁠) brez nadzora.

Na začetku uporabe Codexa smo hitro prešli na pozive, kot je: "Tukaj je funkcija. Tukaj so nekatere datoteke. Prosim, zgradi to." To je včasih delovalo, vendar je večinoma ustvarjalo kodo, ki se je tehnično prevedla, a se oddaljevala od naše arhitekture in ciljev.

Tako smo spremenili potek dela. Za vsako ne‑trivialno spremembo smo najprej prosili Codex, da nam pomaga razumeti, kako sistem in koda delujeta. Na primer, prosili bi vas, da preberete niz povezanih datotek in povzamete, kako ta funkcija deluje; na primer, kako podatki tečejo iz API-ja skozi plast repozitorija, model pogleda in v uporabniški vmesnik (UI). Nato bi popravili ali izpopolnili njegovo razumevanje. (Na primer, poudarili bi, da določena abstrakcija resnično spada v drugo plast ali da določen razred obstaja samo za način brez povezave in ga ne bi smeli razširjati.)

Podobno kot bi sodelovali z novim, zelo sposobnim sodelavcem, smo s Codexom ustvarili trden načrt izvedbe. Ta načrt je pogosto videti kot miniaturni oblikovalski dokument, ki usmerja, katere datoteke je treba spremeniti, katera nova stanja je treba uvesti in kako naj logika poteka. Šele nato smo prosili Codex, da začne izvajati načrt, korak za korakom. En koristen namig: za zelo dolge naloge, kjer dosežemo omejitev našega sobesedilnega okna, bi prosili Codex, da shrani svoj načrt v datoteko, kar nam omogoča, da isto smer uporabimo v različnih primerih.

Izkazalo se je, da je bila ta dodatna načrtovalna zanka vredna časa. To nam je omogočilo, da smo Codex pustili delovati "nenadzorovano" dalj časa, ker smo poznali njegove načrte. To je olajšalo pregled kode, ker smo lahko preverili implementacijo glede na naš načrt, namesto da bi razliko brali brez sobesedila. In ko je šlo kaj narobe, smo lahko najprej poiskali in odpravili napake v načrtu in nato v kodi. 

Dinamika je bila podobna tisti, ki jo dober oblikovalski dokument daje tehničnemu vodji za zaupanje v projekt. Nismo zgolj ustvarjali kode: proizvajali smo kodo, ki je podpirala skupno načrt.

Na vrhuncu projekta smo pogosto izvajali več vzporednih sej Codexa. Eden je delal na predvajanju, drugi na iskanju, tretji na obravnavi napak, včasih pa še kdo na testiranju ali prenovi. Občutiti je bilo manj kot uporaba orodja in bolj kot vodenje ekipe.

Vsaka seja bi nam občasno poročala o napredku. Nekdo bi lahko rekel: »Končal sem s načrtovanjem tega modula; tukaj je moj predlog,« medtem ko bi drugi ponudil obsežno razliko za novo funkcijo. Vsak je zahteval pozornost, povratne informacije in pregled. Bilo je nenavadno podobno temu, da ste tehnični vodja z več novimi inženirji, ki vsi napredujejo in vsi potrebujejo usmerjanje.

Rezultat je bil sodelovalen tok. Codexove osnovne zmožnosti kodiranja so nam omogočile, da ni bilo tako veliko ročnega tipkanja. Imeli smo več časa, da premislimo o arhitekturi, natančno preberemo zahteve in preizkusimo aplikacijo. 

Hkrati je ta dodatna hitrost pomenila, da smo vedno imeli nekaj v čakalni vrsti za pregled. Codex ni bil blokiran zaradi preklapljanja sobesedila, mi pa smo bili. Naše ozko grlo v razvoju se je premaknilo od pisanja kode k sprejemanju odločitev, dajanju povratnih informacij in vključevanju sprememb.

Tukaj Brooksovi vpogledi pristanejo na nov način. Ne morete preprosto dodajati sej Codex in pričakovati linearnih pospeškov, prav tako kot ne morete nenehno dodajati inženirjev k projektu in pričakovati, da se bo časovni načrt linearno skrajšal. Vsak dodaten "par rok", tudi virtualen, poveča usklajevalno breme. Postali smo dirigent orkestra namesto zgolj hitrejši solisti.

Začeli smo naš projekt z velikim mejnikom: Sora je že bila izdana na iOS-u. Pogosto smo usmerjali Codex na iOS in zaledne zbirke kode, da bi mu pomagali razumeti ključne zahteve in omejitve. Skozi celoten projekt smo se šalili, da smo ponovno izumili idejo o večplatformnem okviru. Pozabite na React Native ali Flutter; prihodnost večplatformnosti je zgolj Codex.

Za domislico se skrivata dve načeli:

1. Logika je prenosljiva. Ne glede na to, ali je koda napisana v Swiftu ali Kotlinu, osnovna logika aplikacije – podatkovni modeli, omrežni klici, pravila za preverjanje veljavnosti, poslovna logika – ostajajo enaki. Codex je zelo dober pri branju implementacije v Swiftu in ustvarjanju enakovredne implementacije v Kotlinu, ki ohranja semantiko.
2. Konkretni primeri zagotavljajo močno sobesedilo. Nova seja Codexa, ki lahko vidi "tukaj je točno tako, kakor to deluje na iOS-u" in "tukaj je arhitektura Androida", je veliko bolj učinkovita kot tista, ki deluje samo na podlagi opisov v naravnem jeziku.

Z uporabo teh načel smo omogočili, da so iOS, zalednje in Android repozitoriji na voljo v istem okolju. Dali smo Codexu pozive, kot so:

Preberite te modele in končne točke v iOS kodi in nato predlagajte načrt za implementacijo enakovrednega vedenja na Androidu z uporabo našega obstoječega API odjemalca in razredov modelov.

Majhen, a uporaben trik je bil podrobno opisati v ~/.codex/AGENTS.md, kje se nahajajo lokalni repozitoriji in kaj vsebujejo. To je Codexu olajšalo odkrivanje in navigacijo po ustrezni kodi.

Razvoj smo na več platformah učinkovito razvijali s prevajanjem namesto s skupno abstrakcijo. Ker je Codex opravil večino prevajanja, smo se izognili podvajanju stroškov implementacije.

Širša lekcija je, da je za Codex sobesedilo vse. Codex je najbolje deloval, ko je razumel, kako funkcija že deluje v iOS-u, skupaj z razumevanjem, kako je naša aplikacija za Android strukturirana. Ko je Codexu manjkalo sobesedilo, ni "odklanjal sodelovanja"; ugibal je. Bolj ko smo ga obravnavali kot novega člana ekipe in vlagali v zagotavljanje pravih vnosov, bolje je deloval.

Do konca našega štiritedenskega sprinta je uporaba Codexa prenehala biti eksperiment in postala naš privzeti razvojni cikel. Uporabili smo ga za razumevanje obstoječe kode, načrt sprememb in implementacijo funkcij. Njegov rezultat smo pregledali na enak način, kot bi pregledali rezultat sodelavca. To je bilo preprosto tako, kako smo dostavljali programsko opremo.

Postalo je jasno, da razvoj s pomočjo umetne inteligence ne zmanjšuje potrebe po strogosti; nasprotno, jo povečuje. Čeprav je Codex sposoben, je njegov cilj zdaj priti od točke A do B. To je razlog, zakaj programiranje s pomočjo umetne inteligence brez ljudi ne deluje. Programski inženirji lahko razumejo in uporabljajo realne omejitve sistemov, najboljše načine za arhitekturo programske opreme ter kako graditi z mislijo na prihodnji razvoj in načrte izdelkov. Super moči jutrišnjega programskega inženirja bodo globoko razumevanje sistemov in sposobnost sodelovanja z umetno inteligenco na dolgotrajnih horizontih. 

Najbolj zanimivi deli programskega inženiringa so ustvarjanje privlačnih izdelkov, oblikovanje razširljivih sistemov, pisanje kompleksnih algoritmov in eksperimentiranje s podatki, vzorci in kodo. Vendar pa se resničnosti preteklega in sedanjega programskega inženiringa pogosto nagibajo k bolj vsakdanjim nalogam: centriranje gumbov, povezovanje končnih točk in pisanje osnovne kode. Zdaj Codex omogoča, da se osredotočite na najpomembnejše dele programskega inženirstva in utemeljitve, zakaj imate svojo obrt radi.

Ko je Codex postavljen v okolje, obogateno s sobesedilom, kjer razume vaše cilje in način, kako radi gradite, lahko katera koli ekipa pomnoži svoje zmožnosti. Naša retrospektiva lansiranja ni univerzalna rešitev in ne trdimo, da smo razvoj rešili s pomočjo umetne inteligence. Vendar upamo, da bo naša izkušnja olajšala iskanje najboljših načinov za opolnomočenje Codexa, da opolnomoči vas. 

Ko je bil Codex pred sedmimi meseci lansiran v raziskovalni predogled, je programski inženiring videti zelo drugače. Preko aplikacije Sora smo lahko raziskali naslednje poglavje inženiringa. Ko se naši modeli in orodja nenehno izboljšujejo, bo umetna inteligenca postala vse bolj nepogrešljiv del gradnje. 

Kaj boste ustvarili s svojo lastno Codex ekipo?