Paano namin ginamit ang Codex para buuin ang Sora para sa Android sa loob ng 28 araw

Simula Abril 26, 2026, hindi na available ang produkto ng Sora.

Noong Nobyembre, inilunsad namin ang Sora Android app sa buong mundo, na nagbibigay sa kahit sinong may Android device ng kakayahang gawing buhay na video ang isang maikling prompt. Sa araw ng paglulunsad, nag-#1 ang app sa Play Store. Bumuo ang mga Android user ng mahigit sa isang milyong video sa unang 24 na oras.

Sa likod ng paglulunsad ay isang kuwento: ang unang bersyon ng production Android app ng Sora ay ginawa sa loob ng 28 araw, salamat sa parehong agent na available sa anumang team o sinumang developer: ang Codex.

Mula Oktubre 8 hanggang Nobyembre 5, 2025, isang lean engineering team na nagtatrabaho kasama ang Codex at gumagamit ng humigit-kumulang 5 bilyong token, ang nag-ship sa Sora para sa Android mula sa prototype papunta sa pandaigdigang paglulunsad. Sa kabila ng laki nito, ang app ay may crash-free rate na 99.9 na porsyento at isang arkitekturang ipinagmamalaki namin. Kung nagtataka ka kung gumamit kami ng isang lihim na modelo, gumamit kami ng maagang bersyon ng GPT‑5.1‑Codex na modelo – ang parehong bersyon na maaaring gamitin ng sinumang developer o negosyo ngayon sa pamamagitan ng CLI, IDE extension, o web app.

Nang ilunsad ang Sora sa iOS, biglang tumaas ang paggamit nito. Agad na nagsimulang bumuo ang mga tao ng tuloy-tuloy na daloy ng mga video. Sa Android, sa kabilang banda, mayroon lang kaming maliit na panloob na prototype at dumaraming bilang ng mga naka-preregister na user sa Google Play.

Isang karaniwang sagot sa isang mataas na panganib at time-pressured na paglulunsad ay ang magdagdag ng mga resource at proseso. Ang isang production app na may ganitong saklaw at kalidad ay karaniwang nangangailangan ng maraming inhinyero na ilang buwang nagtatrabaho at pinapabagal ng koordinasyon. 

Ang Amerikanong arkitekto ng computer na si Fred Brooks ay kilalang nagbabala na “ang pagdaragdag ng mas maraming tao sa isang nahuhuling proyekto ng software ay lalo pang magpapaliban dito.” Sa madaling salita, kapag sinusubukang mag-ship ng kumplikadong proyekto nang mabilis, ang pagdaragdag ng mas maraming inhinyero ay madalas na nagpapabagal sa kahusayan sa pamamagitan ng pagdaragdag sa overhead ng komunikasyon, pagkakawatak-watak ng gawain, at mga gastos sa integrasyon. Sa halip na balewalain, niyakap namin ang insight na ito; bumuo kami ng isang malakas na team ng apat na engineer – lahat ay may kaalaman sa Codex para lubos na mapataas ang impact ng bawat engineer. 

Sa ganitong paraan ng pagtatrabaho, nakapag-ship kami ng panloob na pagtatayo ng Sora para sa Android sa mga empleyado sa loob ng 18 araw at inilunsad ito sa publiko 10 araw pagkatapos. Pinanatili namin ang mataas na pamantayan sa mga kagawian sa Android engineering, namuhunan sa kakayahang magpanatili, at tiniyak na ang app ay sumusunod sa parehong pamantayan ng pagiging maaasahan na aasahan namin mula sa isang mas tradisyonal na proyekto. (Patuloy rin naming ginagamit ang Codex nang malawakan ngayon para paunlarin at magdala ng mga bagong feature sa app).

Para maintindihan kung paano kami nakipagtulungan sa Codex, makakatulong malaman kung saan ito magaling at kung saan ito nangangailangan ng gabay. Ang pagtrato rito na parang bagong hired na senior engineer ay isang magandang paraan. Ang kakayahan ng Codex ay nangangahulugang mas marami kaming oras na magagamit sa pagdidirekta at pagsusuri ng code kaysa sa pagsusulat nito mismo.

Kung saan kailangan ng Codex ng patnubay

1. Hindi pa mahusay ang Codex sa pag-unawa sa mga bagay na hindi pa nito nalalaman (hal., ang iyong mga paboritong pattern ng arkitektura, estratehiya ng produkto, totoong pag-uugali ng user, at mga internal na norm o shortcut).
2. Katulad nito, hindi kayang makita ng Codex ang aktwal na pagtakbo ng app: Hindi nito kayang buksan ang Sora sa isang device, mapansin na may mali sa pag-scroll, o maramdaman na nakakalito ang daloy. Tanging ang aming team lamang ang makakagawa ng mga gawaing pangkaranasan na ito.
3. Ang bawat pagkakataon ay nangangailangan ng pag-onboard. Ang pagbabahagi ng konteksto na may malinaw na mga layunin, mga limitasyon, at gabay sa kung “paano namin ginagawa ang mga bagay” ay mahalaga para sa mahusay na pagpapatupad ng Codex.
4. Sa parehong paraan, nahirapan ang Codex sa malalim na paghatol sa arkitektura: Kapag iniwan itong mag-isa, maaari itong magpakilala ng karagdagang view model kung saan talagang nais naming palawigin ang isang umiiral na o itulak ang lohika sa UI layer na malinaw na nabibilang sa isang repository. Ang instinct nito ay makapagpatakbo ng isang bagay, hindi ang unahin ang pagiging malinis nang pangmatagalan.

Nakita naming kapaki-pakinabang na gumawa at magpanatili ang Codex ng maraming AGENT.md na mga file sa buong codebase. Pinadali nito ang paglalapat ng parehong patnubay at pinakamahuhusay na kagawian sa mga session. Halimbawa, para matiyak na sumulat ang Codex ng code na ayon sa aming mga alituntunin sa istilo, idinagdag namin ang sumusunod sa aming top-level na AGENTS.md:

Kung saan namumukod-tangi ang Codex

1. Mabilis na pagbasa at pag-unawa sa malalaking codebase: Alam ng Codex ang halos lahat ng pangunahing wika ng programming, na nagpapadali sa paggamit ng parehong mga konsepto sa maraming platform nang walang kumplikadong abstraction.
2. Saklaw ng testing: Ang Codex ay (natatanging) masigasig sa pagsusulat ng mga unit test upang masaklaw ang iba't ibang kaso. Hindi lahat ng test ay malalim, pero ang pagkakaroon ng malawak na saklaw ay nakatulong sa pag-iwas sa mga regression. 
3. Paglalapat ng feedback: Sa katulad na paraan, mahusay ang Codex sa pagtugon sa feedback. Kapag nabigo ang CI, puwede naming i-paste ang log output sa isang prompt at hilingin sa Codex na magmungkahi ng mga pag-aayos.
4. Malawakang parallel at disposable na pagpapatupad: Karamihan ay hindi itutulak ang mga limitasyon ng bilang ng mga session na kaya nilang patakbuhin sa anumang oras. Napakaposibleng subukan ang maramihang ideya nang sabay-sabay at ituring ang code bilang pansamantala.
5. Nag-aalok ng bagong pananaw: Sa mga talakayan sa disenyo, ginamit namin ang Codex bilang isang generative tool para galugarin ang mga potensyal na punto ng pagpalya at tuklasin ang mga bagong paraan upang lutasin ang isang problema. Halimbawa, habang nagdidisenyo kami ng mga pag-optimize sa memory ng video player, sinuri ng Codex ang maraming SDK upang magmungkahi ng mga pamamaraan na wala kaming oras na i-parse. Ang mga insight mula sa pananaliksik ng Codex ay napatunayang napakahalaga sa pagpapaliit ng memory footprint sa pinal na app.
6. Pag-enable ng mas mataas na leverage na gawain: Sa praktika, mas marami kaming oras na ginugol sa pagrerepaso at pagdidirekta ng code kaysa sa pagsusulat nito mismo. Gayunpaman, mahusay rin ang Codex sa pagsusuri ng code, madalas na natutukoy ang mga bug bago pa man sila i-merge, na nagpapabuti sa pagiging maaasahan.

Nang kinilala na namin ang mga katangiang ito, naging mas simple ang aming modelo ng pagtatrabaho. Umasa kami sa Codex para sa malaking bahagi ng mabibigat na gawain sa loob ng mga kilalang pattern at may malinaw na hangganan, habang ang aming team ay nakatuon sa arkitektura, karanasan ng user, mga sistematikong pagbabago, at pinal na kalidad.

Kahit na ang pinakamahusay na bagong senior hire ay wala pang tamang pananaw para sa paggawa ng mga pangmatagalang trade-off kaagad. Para magamit ang Codex at masigurong malakas at mapapanatili ang trabaho nito, mahalagang kami mismo ang nagmasid sa disenyo ng mga system ng app at mga pangunahing trade-off. Kasama rito ang paghubog sa arkitektura ng app, modularisasyon, dependency injection, at pag-navigate; ipinatupad din namin ang authentication at mga pangunahing daloy ng networking. 

Mula sa pundasyong ito, nagsulat kami ng ilang kinatawang feature na kumpleto mula simula hanggang dulo. Ginamit namin ang mga patakaran na gusto naming sundin ng buong codebase at idinokumento ang mga pattern sa buong proyekto habang nagpapatuloy kami. Sa pamamagitan ng pagturo sa Codex sa mga kinatawan na feature, nagawa nitong magtrabaho nang mas malaya sa loob ng aming mga pamantayan. Para sa isang proyekto na tinatayang 85% ay isinulat ng Codex, ang maingat na planadong pundasyon ay nakaiwas sa magastos na pag-urong at pag-refactor. Isa ito sa mga pinakamahalagang desisyon na ginawa natin. 

Ang ideya ay hindi upang gumawa ng "isang bagay na gumagana" sa lalong madaling panahon, kundi upang gumawa ng "isang bagay na nakakaintindi kung paano natin nais na gumana ang mga bagay." Maraming “tamang” paraan para magsulat ng code. Hindi namin kailangang sabihin sa Codex kung ano ang eksaktong gagawin; kailangan naming ipakita sa Codex kung ano ang "tama" sa aming team. Kapag naitakda na namin ang aming panimulang punto at kung paano namin gustong bumuo, handa na ang Codex na magsimula.

Para makita kung ano ang mangyayari, sinubukan naming mag-prompt: “Buuin ang Sora Android app batay sa iOS code. Go," ngunit mabilis na iniwan ang landas na iyon. Kahit na ang ginawa ng Codex ay teknikal na gumana, ang karanasan sa produkto ay hindi kasiya-siya. At kung walang malinaw na pag-unawa sa mga endpoint, data, at daloy ng user, ang single-shot na code ng Codex ay hindi maaasahan (Kahit na hindi gumagamit ng agent, mapanganib na i-merge ang libo-libong linya ng code.) 

Nag-hypothesize kaming uunlad ang Codex sa isang sandbox na puno ng maayos na nakasulat na mga halimbawa; at tama kami. Ang paghingi sa Codex na "bumuo ng screen na ito ng mga setting" na halos walang konteksto ay hindi maaasahan. Mas epektibo ang paghingi sa Codex na “bumuo ng screen na ito ng mga setting gamit ang parehong arkitektura at mga pattern tulad nitong kabilang screen na kakakita mo lang.” Ang mga tao ang gumawa ng mga desisyon sa istruktura at nagtakda ng mga invariant; pagkatapos ay pinunan ng Codex ng malaking bahagi ng code ang loob ng istrukturang iyon.

Ang susunod naming hakbang sa pag-maximize ng potensyal ng Codex ay alamin kung paano i-enable ang Codex na magtrabaho nang mahabang panahon (kamakailan, higit sa 24 na oras⁠), nang walang superbisyon.

Sa simula ng paggamit ng Codex, agad kaming lumipat sa mga prompt tulad ng, “Narito ang feature. Narito ang ilang file. Pakibuo ito.” Minsan gumagana ito, pero kadalasan ay nagreresulta ito sa code na teknikal na nagko-compile, habang lumilihis sa aming arkitektura at mga layunin.

Kaya binago namin ang daloy ng trabaho. Para sa anumang hindi simpleng pagbabago, una naming hiningi ang tulong ng Codex para maintindihan kung paano gumagana ang sistema at ang code. Halimbawa, hihilingin namin dito na basahin ang isang set ng mga kaugnay na file at ibuod kung paano gumagana ang feature na iyon; halimbawa, kung paano dumadaloy ang data mula sa API sa pamamagitan ng layer ng repository, ang view model, at papunta sa UI. Pagkatapos ay itatama o iaakma namin ang pag-unawa nito. (Halimbawa, ituturo namin na ang isang partikular na abstraction ay talagang nabibilang sa ibang layer o na ang isang klase ay umiiral lamang para sa offline mode at hindi dapat i-extend.)

Katulad ng kung paano kang makikipag-ugnayan sa isang bago at napakahusay na kasamahan, nakipagtulungan kami sa Codex upang gumawa ng isang solidong plano sa pagpapatupad. Ang planong iyon ay madalas na parang isang maliit na dokumento ng disenyo na nagtuturo kung aling mga file ang dapat baguhin, anong mga bagong estado ang dapat ipasok, at paano dapat dumaloy ang lohika. Saka lamang namin hiningi sa Codex na simulan ang paglalapat sa plano, nang paisa-isang hakbang. Isang kapaki-pakinabang na tip: para sa napakahahabang gawain, kung saan umaabot tayo sa limitasyon ng ating konteksto, hihilingin namin sa Codex na i-save ang plano nito sa isang file, na nagpapahintulot sa aming ilapat ang parehong direksyon sa iba't ibang pagkakataon.

Napatunayan na ang karagdagang planning loop na ito ay sulit sa inilaang oras. Pinayagan kami nitong patakbuhin ang Codex nang “walang bantay” sa mahabang panahon, dahil alam namin ang mga plano nito. Naging mas madali ang pagsusuri ng code, dahil maaari naming suriin ang implementasyon kumpara sa aming plano sa halip na basahin ang isang diff na walang konteksto. At kapag may nangyaring mali, puwede naming i-debug muna ang plano bago ang code. 

Ang dinamika ay parang katulad ng kung paanong ang isang magandang dokumento ng disenyo ay nagbibigay-kumpiyansa sa isang tech lead sa isang proyekto. Hindi lang kami bumubuo ng code: gumagawa kami ng code na sumusuporta sa isang pinagsasaluhang roadmap.

Sa kasagsagan ng proyekto, madalas kaming nagpapatakbo ng maraming sabay-sabay na session ng Codex. Ang isa ay nagtatrabaho sa playback, ang isa sa paghahanap, ang isa sa paghawak ng error, at kung minsan ang isa pa sa mga pagsusuri o pag-refactor. Parang hindi masyadong paggamit ng tool ang pakiramdam kundi parang pamamahala sa isang team.

Ang bawat session ay pana-panahong mag-uulat ng progreso sa amin. Maaaring sabihin ng isa, "Tapos na akong magplano para sa module na ito; narito ang aking mungkahi," habang ang isa naman ay mag-aalok ng malaking pagbabago para sa bagong feature. Bawat isa ay nangangailangan ng atensyon, feedback, at pagsusuri. Parang hindi kapani-paniwala ang pagkakatulad nito sa pagiging isang tech lead na may ilang bagong inhinyero, lahat ay umuusad, lahat ay nangangailangan ng gabay.

Ang resulta ay isang daloy ng pagtutulungan. Ang kakayahan ng Codex sa pag-code ay nagpalaya sa amin mula sa maraming manu-manong pagta-type. Nagkaroon kami ng mas maraming oras para mag-isip tungkol sa arkitektura, maingat na basahin ang mga pull request, at subukan ang app. 

Kasabay nito, ang karagdagang bilis ay nangangahulugan na palagi kaming may nakapila para sa pagsusuri. Hindi na-block ang Codex ng pagpapalit ng konteksto, pero na-block kami. Ang aming bottleneck sa pag-develop ay lumipat mula sa pagsusulat ng code patungo sa paggawa ng mga desisyon, pagbibigay ng feedback, at pagsasama ng mga pagbabago.

Dito nagkakaroon ng bagong pananaw ang mga ideya ni Brooks. Hindi mo basta-basta maidaragdag ang mga session ng Codex at asahan ang linear na pagbilis, katulad ng hindi mo basta-basta maidaragdag ang mga inhinyero sa isang proyekto at asahan na liliit ang iskedyul nang linear. Ang bawat karagdagang "pares ng kamay," kahit na virtual, ay nagdadagdag ng overhead sa koordinasyon. Naging konduktor kami ng isang orkestra kumpara sa pagiging mas mabilis na mga soloista lamang.

Sinimulan namin ang aming proyekto sa isang malaking hakbang: Na-ship na ang Sora sa iOS. Madalas naming itinuturo ang Codex sa iOS at backend codebase para matulungan itong maunawaan ang mga pangunahing kinakailangan at mga hadlang. Sa buong proyekto, pabiro naming sinabi na muli naming naimbento ang ideya ng isang cross‑platform na balangkas. Kalimutan ang React Native o Flutter; ang kinabukasan ng cross‑platform ay Codex lang.

Sa ilalim ng biro ay may dalawang prinsipyo:

1. Madaling dalhin ang lohika. Kahit na ang code ay nakasulat sa Swift o Kotlin, ang pangunahing lohika ng application – mga modelo ng data, mga tawag sa network, mga panuntunan sa validation, business logic – ay pareho. Magaling ang Codex sa pagbabasa ng implementasyon ng Swift at paggawa ng katumbas nito sa Kotlin na pinapanatili ang semantika.
2. Ang mga konkretong halimbawa ay nagbibigay ng malakas na konteksto. Ang isang bagong session ng Codex na makakakita ng “ganito mismo ito gumagana sa iOS” at “ganito ang arkitektura ng Android” ay mas epektibo kaysa sa isang umaasa lamang sa mga natural na paglalarawan ng wika.

Sa paggamit ng mga prinsipyong ito, ginawa naming available ang mga repo ng iOS, backend, at Android sa parehong kapaligiran. Nagbigay kami ng mga prompt sa Codex gaya ng:

“Basahin ang mga modelo at endpoint na ito sa iOS code at pagkatapos ay magmungkahi ng plano upang ipatupad ang katumbas na gawi sa Android gamit ang aming umiiral nang client at mga klase ng modelo ng API.”

Isang maliit ngunit kapaki-pakinabang na trick ay ang pagdetalye sa ~/.codex/AGENTS.md kung saan nakalagay ang mga lokal na repo at kung ano ang nilalaman ng mga ito. Naging mas madali para sa Codex na matuklasan at i-navigate ang kaugnay na code.

Epektibo naming ginagawa ang cross-platform development sa pamamagitan ng pagsasalin sa halip na sa shared abstraction. Dahil Codex ang humawak ng karamihan sa pagsasalin, naiwasan naming madoble ang gastos sa implementasyon.

Ang mas malawak na aral ay na para sa Codex, ang konteksto ang pinakamahalaga. Ginawa ng Codex ang pinakamagaling nitong trabaho noong naintindihan nito kung paanong gumagana na ang feature sa iOS, kasabay ng pag-unawa sa pagkakaayos ng aming Android app. Noong kulang nito ang konteksto ng Codex, hindi ito "tumatangging makipagtulungan"; ito ay nagtatangkang manghula. Mas mahusay ang pagganap nito habang itinuturing namin itong bagong kasamahan at namumuhunan kami sa pagbibigay ng tamang input.

Sa pagtatapos ng aming apat na linggong sprint, ang paggamit ng Codex ay hindi na pakiramdam na isang eksperimento at naging aming default na loop sa pag-develop. Ginamit namin ito para maunawaan ang umiiral na code, para sa plano ng mga pagbabago, at magpatupad ng mga feature. Sinuri namin ang output nito sa parehong paraan na susuriin namin ang sa isang kasamahan. Ganoon lang talaga ang pag-ship namin sa software.

Naging malinaw na ang AI na tumutulong sa pag-develop ay hindi nagpapababa ng pangangailangan para sa kasipagan; sa halip, pinapataas pa ito. Kahit gaano pa man kahusay ang Codex, ang layunin nito ay makarating mula A hanggang B, ngayon. Ito ang dahilan kung bakit hindi gumagana ang pag-code na may tulong ng AI kung wala ang tao. Ang mga software engineer ay kayang umunawa at mag-apply ng mga tunay na limitasyon ng mga sistema, ang pinakamahusay na paraan upang magdisenyo ng software, at kung paano bumuo nang iniisip ang mga plano para sa hinaharap na pag-develop at mga plano ng produkto. Ang mga super power ng software engineer ng hinaharap ay ang malalim na pag-unawa sa mga sistema at ang kakayahang makipagtulungan sa AI sa mahabang panahon. 

Ang pinakakawili-wiling bahagi ng software engineering ay ang pagbuo ng mga nakakaakit na produkto, pagdidisenyo ng mga sistemang madaling i-scale, pagsusulat ng mga komplikadong algorithm, at pag-eeksperimento sa data, mga pattern, at code. Gayunpaman, ang mga realidad ng software engineering noon at ngayon ay madalas na mas karaniwan: pag-sentro ng mga button, pagkabit ng mga endpoint, at pagsusulat ng boilerplate. Ngayon, ginagawang posible ng Codex na magtuon sa mga pinakamakabuluhang bahagi ng software engineering at ang mga dahilan kung bakit mahal natin ang ating sining.

Kapag na-set up na ang Codex sa isang kapaligirang mayaman sa konteksto kung saan nauunawaan nito ang iyong mga layunin at kung paano mo gustong bumuo, ang anumang team ay maaaring maparami ang kakayahan nito. Ang aming launch retro ay hindi isang sukat na akma sa lahat na resipe, at hindi namin sinasabing nalutas na namin ang AI‑assisted development. Ngunit umaasa kami na ang aming karanasan ay makakatulong na mas mapadali ang paghahanap ng pinakamahusay na mga paraan upang bigyang-kapangyarihan ang Codex na bigyang-kapangyarihan ka. 

Nang ilunsad ang Codex sa isang research preview pitong buwan na ang nakalipas, ibang-iba ang itsura ng software engineering. Sa pamamagitan ng Sora, nagawa naming galugarin ang susunod na kabanata ng engineering. Habang patuloy na umuunlad ang aming mga modelo at harness, ang AI ay magiging lalong hindi mapapalitang bahagi ng konstruksyon. 

Ano ang gagawin mo sa sarili mong team ng Codex?