Jinsi tulivyotumia Codex kujenga Sora kwa Android katika siku 28

Kuanzia tarehe 26 Aprili 2026, bidhaa ya Sora haitapatikana tena.

Mnamo Novemba, tulizindua programu ya Sora ya Android kwa ulimwengu, tukimpa yeyote aliye na kifaa cha Android uwezo wa kubadilisha dokezo fupi kuwa video yenye uhai. Siku ya uzinduzi, programu ilifikia nafasi ya kwanza kwenye Play Store. Watumiaji wa Android walizalisha zaidi ya video milioni moja katika saa 24 za kwanza.

Nyuma ya uzinduzi kuna hadithi: toleo la awali la programu ya uzalishaji ya Android ya Sora lilijengwa kwa siku 28, shukrani kwa wakala yule yule anayepatikana kwa timu yoyote au msanidi programu: Codex.

Kuanzia Oktoba 8 hadi Novemba 5, 2025, Team ndogo ya uhandisi ikifanya kazi pamoja na Codex na kutumia takriban token bilioni 5, ilizindua Sora kwa Android kutoka mfano hadi uzinduzi wa kimataifa. Licha ya ukubwa wake, programu ina kiwango cha kutokuharibika cha asilimia 99.9 na usanifu ambao tunajivunia. Ikiwa unajiuliza iwapo tulitumia muundo wa siri, tulitumia toleo la awali la GPT‑5.1‑Codex muundo— toleo lile lile ambalo msanidi programu yeyote au Business anaweza kutumia leo kupitia CLI, kiendelezi cha IDE, au programu ya wavuti.

Sora ilipozinduliwa kwenye iOS, matumizi yaliongezeka kwa kasi. Watu walianza mara moja kuzalisha mtiririko wa video. Kwenye Android, kinyume chake, tulikuwa na mfano mdogo wa ndani tu na idadi inayoongezeka ya watumiaji waliotangulia kusajiliwa kwenye Google Play.

Jibu la kawaida kwa uzinduzi wa hatari kubwa na ulioshinikizwa na muda ni kuongeza rasilimali na kuongeza michakato. Programu ya uzalishaji ya kiwango na ubora huu kawaida ingehusisha wahandisi wengi wakifanya kazi kwa miezi, ikipunguzwa kasi na uratibu. 

Mwanasayansi wa kompyuta wa Marekani Fred Brooks alionya maarufu kwamba "kuongeza watu zaidi kwenye mradi wa programu uliochelewa kunaufanya uchelewe zaidi." Kwa maneno mengine, unapojaribu kusafirisha mradi mgumu haraka, kuongeza wahandisi zaidi kunaweza kupunguza ufanisi kwa kuongeza mzigo wa mawasiliano, mgawanyiko wa shughuli, na gharama za ujumuishaji. Tuliegemea ufahamu huu badala ya kuupuuzia; tuliunda Team imara ya wahandisi wanne - wote wakiwa na Codex ili kuongeza kwa kiasi kikubwa athari ya kila mhandisi. 

Kwa kufanya kazi kwa njia hii, tulisafirisha ujenzi wa ndani wa Sora kwa Android kwa wafanyakazi ndani ya siku 18 na kuzindua hadharani siku 10 baadaye. Tulidumisha viwango vya juu katika mbinu za uhandisi wa Android, tukawekeza katika udumishaji, na tukashikilia programu kwa kiwango sawa cha kutegemewa ambacho tungetarajia kutoka kwa mradi wa jadi zaidi. (Tunaendelea pia kutumia Codex kwa kiasi kikubwa leo ili kuboresha na kuleta vipengele vipya kwenye programu).

Ili kuelewa jinsi tulivyofanya kazi na Codex, inasaidia kujua ni wapi inang'aa na ni wapi inahitaji mwelekeo. Kuichukulia kama mhandisi mwandamizi aliyeajiriwa hivi karibuni ilikuwa mbinu nzuri. Uwezo wa Codex ulitufanya tuweze kutumia muda zaidi kuelekeza na kukagua msimbo badala ya kuandika sisi wenyewe.

Mahali ambapo Codex inahitaji mwongozo

1. Codex bado haijawa bora katika kubaini kile ambacho haijaambiwa (kwa mfano, mifumo unayopendelea ya usanifu, mkakati wa bidhaa, tabia halisi ya mtumiaji, na kanuni za ndani au njia za mkato).
2. Vivyo hivyo, Codex haikuweza kuona programu ikiendeshwa: Haikuweza kufungua Sora kwenye kifaa, kugundua kwamba skrini haikuwa sawa, au kuhisi kwamba mtiririko ulikuwa wa kuchanganya. Ni Team yetu pekee inayoweza kushughulikia shughuli hizi za kipekee.
3. Kila mfano unahitaji kujumlisha. Kushiriki muktadha na malengo wazi, vikwazo, na mwongozo kuhusu "jinsi tunavyofanya mambo" ilikuwa muhimu ili kuhakikisha Codex inatekelezwa vizuri.
4. Katika muktadha huo huo, Codex ilikumbana na changamoto za maamuzi ya kina ya usanifu: Ikiwa ingeachwa peke yake, ingeweza kuanzisha muundo wa ziada wa mwonekano ambapo tulitaka kweli kupanua uliopo au kusukuma mantiki kwenye safu ya UI ambayo wazi ilipaswa kuwa kwenye hifadhi. Silika yake ni kufanya kitu kifanye kazi, sio kuweka kipaumbele usafi wa kudumu.

Tuliona ni muhimu kuwa na Codex kuunda na kudumisha idadi kubwa ya faili za wakala.md katika msingi wa msimbo. Hii ilirahisisha kutumia mwongozo huo huo na mbinu bora katika vikao. Kwa mfano, ili kuhakikisha Codex aliandika msimbo kulingana na miongozo yetu ya mtindo, tuliongeza yafuatayo kwenye AGENTS.md yetu ya kiwango cha juu:

Ambapo Kodeksi inazidi kuwa bora

1. Kusoma na kuelewa misimbo mikubwa haraka: Codex inajua kimsingi lugha zote kuu za programu, jambo ambalo linafanya iwe rahisi kutumia dhana zile zile kwenye majukwaa mengi bila dhana changamano.
2. Chanjo ya majaribio: Codex ina shauku (ya kipekee) ya kuandika majaribio ya vitengo ili kufunika aina mbalimbali za kesi. Sio kila jaribio lilikuwa la kina, lakini kuwa na upana wa chanjo kulisaidia katika kuzuia kurudi nyuma. 
3. Kutumia majibu: Kwa njia sawa, Codex ni mzuri katika kujibu majibu. Wakati CI ilishindwa, tunaweza kubandika matokeo ya kumbukumbu kwenye dokezo na kumwomba Codex kupendekeza marekebisho.
4. Utekelezaji sambamba kwa kiwango kikubwa, unaoweza kutupwa: Wengi hawatajaribu mipaka ya idadi ya vikao ambavyo wangeweza kuendesha kwa wakati mmoja. Inawezekana sana kujaribu mawazo mengi kwa wakati mmoja na kuona msimbo kama kitu kinachoweza kutupwa.
5. Kutoa mtazamo mpya: Katika mijadala ya muundo, tulitumia Codex kama zana ya kizazi ili gundua sehemu zinazoweza kushindwa na kugundua njia mpya za kutatua tatizo. Kwa mfano, wakati tulipobuni uboreshaji wa kumbukumbu ya kichezaji video, Codex ilichambua SDK nyingi ili kupendekeza mbinu ambazo hatungekuwa na muda wa kuchambua. Maarifa kutoka kwa utafiti wa Codex yalithibitika kuwa ya thamani isiyopimika katika kupunguza matumizi ya kumbukumbu kwenye programu ya mwisho.
6. Kuwezesha kazi yenye athari kubwa zaidi: Kwa vitendo, tulijikuta tukitumia muda mwingi zaidi kukagua na kuelekeza msimbo kuliko kuandika sisi wenyewe. Hata hivyo, Codex ni mzuri sana katika ukaguzi wa msimbo pia, mara nyingi ikigundua hitilafu kabla hazijaunganishwa, na hivyo kuboresha uaminifu.

Mara tu tulipotambua sifa hizi, muundo wetu wa kazi ukawa rahisi zaidi. Tulitegemea Codex kufanya kazi nyingi nzito ndani ya mifumo inayofahamika vizuri na mipaka iliyoeleweka, huku Team yetu ikilenga usanifu, uzoefu wa mtumiaji, mabadiliko ya kimfumo, na ubora wa mwisho.

Hata mfanyakazi mpya wa ngazi ya juu hana mtazamo sahihi wa kufanya maamuzi ya muda mrefu mara moja. Ili kutumia Codex na kuhakikisha kazi yake ilikuwa thabiti na inayoweza kudumishwa, ilikuwa muhimu kwamba tuangalie sisi wenyewe muundo wa mifumo ya programu na maamuzi muhimu. Hizi zilijumuisha kuunda usanifu wa programu, ugawanyiko wa moduli, sindikizo la utegemezi, na urambazaji; tulitekeleza pia uthibitishaji na mtiririko wa msingi wa mtandao. 

Kutoka kwenye msingi huu, tuliandika vipengele vichache vya uwakilishi kutoka mwanzo hadi mwisho. Tulitumia sheria tulizotaka msimbo mzima kufuata na tukarekodi mifumo ya mradi mzima tulipokuwa tukiendelea. Kwa kuelekeza Codex kwenye vipengele vya uwakilishi, iliweza kufanya kazi kwa kujitegemea zaidi ndani ya viwango vyetu. Kwa mradi ambao tunakadiria kuwa asilimia 85 uliandikwa na Codex, msingi uliopangwa kwa makini ulisaidia kuepuka kurudi nyuma na kufanya marekebisho ya gharama kubwa. Ilikuwa mojawapo ya maamuzi muhimu zaidi tuliyofanya. 

Wazo halikuwa kutengeneza "kitu kinachofanya kazi" haraka iwezekanavyo, bali kutengeneza "kitu kinachoelewa jinsi tunavyotaka mambo yafanye kazi." Kuna njia nyingi "sahihi" za kuandika msimbo. Hatukuhitaji kumwambia Codex hasa cha kufanya; tulihitaji kumwonyesha Codex kile kilicho "sahihi" kwenye timu yetu. Mara tu tulipokuwa tumeanzisha mahali pa kuanzia na jinsi tulivyopenda kujenga, Codex ilikuwa tayari kuanza.

Ili kuona kitakachotokea, tulijaribu kuhimiza: "Jenga programu ya Sora ya Android kwa kutumia msimbo wa iOS. "Nenda," lakini haraka aliacha njia hiyo. Ingawa kile ambacho Codex iliunda kilifanya kazi kiufundi, uzoefu wa bidhaa haukufikia viwango vya juu. Na bila uelewa wazi wa sehemu za mwisho, data, na mtiririko wa watumiaji, msimbo wa risasi moja wa Codex haukuwa wa kuaminika (Hata bila kutumia wakala, ni hatari kuunganisha maelfu ya mistari ya msimbo.) 

Tulidhani Codex ingefanikiwa katika mazingira ya mifano iliyoandikwa vizuri; na tulikuwa sahihi. Kuomba Codex "kujenga skrini hii ya mipangilio" bila muktadha wowote ilikuwa si ya kuaminika. Kuomba Codex “kujenga skrini hii ya mipangilio kwa kutumia usanifu na mifumo sawa na skrini hii nyingine uliyokiona” kulifanya kazi vizuri zaidi. Wanadamu walifanya maamuzi ya kimuundo na kuweka invariants; Codex kisha ikajaza kiasi kikubwa cha msimbo ndani ya muundo huo.

Hatua yetu inayofuata katika kuongeza uwezo wa Codex ilikuwa kutafuta jinsi ya kuwezesha Codex kufanya kazi kwa muda mrefu (hivi karibuni, zaidi ya saa 24⁠), bila usimamizi.

Mapema katika kutumia Codex, tulirukia dokezo kama, "Hapa kuna kipengele. Hapa kuna baadhi ya faili. Tafadhali ijenge. Hiyo wakati mwingine ilifanya kazi, lakini mara nyingi ilizalisha msimbo ambao kimsingi uliunganishwa, huku ukipotea kutoka kwa usanifu wetu na malengo yetu.

Kwa hivyo tulibadilisha mtiririko wa kazi. Kwa mabadiliko yoyote yasiyo ya kawaida, kwanza tuliuliza Codex kutusaidia kuelewa jinsi mfumo na msimbo unavyofanya kazi. Kwa mfano, tungeuliza isome seti ya faili zinazohusiana na ifupishe jinsi kipengele hicho kinavyofanya kazi; kwa mfano, jinsi data inavyotiririka kutoka API kupitia safu ya hazina, muundo wa mtazamo, na kuingia kwenye UI. Kisha tungeboresha au kurekebisha uelewa wake. (Kwa mfano, tungeonyesha kwamba dhana fulani inapaswa kuwa katika safu tofauti au kwamba darasa fulani lipo tu kwa ajili ya hali ya nje ya mtandao na halipaswi kupanuliwa.)

Vile vile jinsi unavyoweza kushirikiana na mshirika mpya mwenye uwezo mkubwa, tulifanya kazi na Codex kuunda mpango thabiti wa utekelezaji. Mpango huo mara nyingi ulionekana kama hati ndogo ya muundo inayodokeza ni faili zipi zinapaswa kubadilishwa, ni hali mpya zipi zinapaswa kuanzishwa, na jinsi mantiki inavyopaswa kuendelea. Ni hapo tu ndipo tulipomwomba Codex aanze kutekeleza mpango, hatua moja kwa wakati. Kidokezo kimoja cha msaada: kwa shughuli ndefu sana, ambapo tunafikia kikomo cha dirisha letu la muktadha, tungeomba Codex kuhifadhi mpango wake kwenye faili, ikituruhusu kutumia mwelekeo huo huo katika matukio mbalimbali.

Mzunguko huu wa ziada wa kupanga ulithibitisha kuwa wa thamani ya muda. Iliweza kuturuhusu Codex kuendeshwa "bila kusimamiwa" kwa muda mrefu, kwa sababu tulijua mipango yake. Iliwezesha ukaguzi wa msimbo kuwa rahisi zaidi, kwa sababu tuliweza kukagua utekelezaji dhidi ya mpango wetu badala ya kusoma tofauti bila muktadha. Na wakati kitu kilipokwenda vibaya, tungeweza kutatua mpango kwanza na msimbo pili. 

Mwelekeo huo ulionekana sawa na jinsi hati nzuri ya muundo inavyompa Kiongozi wa Teknolojia ujasiri katika mradi. Hatukuwa tu tunazalisha msimbo: tulikuwa tunazalisha msimbo uliounga mkono ramani ya pamoja.

Katika kilele cha mradi, mara nyingi tulikuwa tukiendesha vikao vingi vya Codex kwa wakati mmoja. Mmoja alikuwa akifanya kazi kwenye uchezaji, mwingine kwenye utafutaji, mwingine kwenye kushughulikia makosa, na wakati mwingine mwingine kwenye majaribio au marekebisho. Ilihisi kidogo kama kutumia zana na zaidi kama kusimamia Team.

Kila kikao kingeripoti kwetu mara kwa mara nyuma kuhusu maendeleo. Mtu anaweza kusema, "Nimekamilisha kupanga moduli hii; hapa kuna ninachopendekeza," wakati mwingine atatoa tofauti kubwa kwa kipengele kipya. Kila moja ilihitaji umakini, majibu, na ukaguzi. Ilikuwa kwa namna ya ajabu sawa na kuwa kiongozi wa teknolojia na wahandisi wapya kadhaa, wote wakifanya maendeleo, wote wakihitaji mwongozo.

Matokeo yalikuwa mtiririko wa ushirikiano. Uwezo wa msingi wa usimbaji wa Codex ulituwezesha kuepuka kazi nyingi za kuandika kwa mikono. Tulikuwa na muda zaidi wa kufikiria kuhusu usanifu, kusoma maombi ya kuvuta kwa makini, na kujaribu programu. 

Wakati huo huo, kasi hiyo ya ziada ilimaanisha kuwa kila mara tulikuwa na kitu kinachosubiri katika foleni yetu ya ukaguzi. Codex haikuzuiwa na kubadilisha muktadha, lakini sisi tulizuiliwa. Kikwazo chetu katika maendeleo kilihama kutoka kuandika msimbo hadi kufanya maamuzi, kutoa majibu, na kuunganisha mabadiliko.

Hapa ndipo maarifa ya Brooks yanapopatikana kwa njia mpya. Huwezi tu kuongeza vikao vya Codex na kutarajia kuongeza kasi kwa mstari moja kwa moja kama vile huwezi kuendelea kuongeza wahandisi kwenye mradi na kutarajia ratiba kupungua kwa mstari moja kwa moja. Kila "jozi ya mikono" ya ziada, hata kama ni za mtandaoni, huongeza mzigo wa uratibu. Tulikuwa tumegeuka kuwa kiongozi wa orchestra badala ya wachezaji wa solo wa kasi zaidi.

Tulianza mradi wetu na hatua kubwa: Sora tayari ilikuwa imetolewa kwenye iOS. Mara kwa mara tulielekeza Codex kwenye misimbo ya iOS na backend ili kuisaidia kuelewa mahitaji muhimu na vizuizi. Katika mradi mzima tulitania kwamba tulikuwa tumeunda upya wazo la mfumo wa majukwaa mbalimbali. Sahau React Native au Flutter; mustakabali wa majukwaa mbalimbali ni Codex pekee.

Chini ya mzaha kuna kanuni mbili:.

1. Mantiki ni ya kubebeka. Iwe msimbo umeandikwa kwa Swift au Kotlin, mantiki ya msingi ya programu – miundo ya data, miito ya mtandao, sheria za uthibitishaji, mantiki ya Business – ni sawa. Codex ni bora sana katika kusoma utekelezaji wa Swift na kutoa utekelezaji sawa katika Kotlin unaohifadhi maana.
2. Mifano halisi hutoa muktadha wenye nguvu. Kikao kipya cha Codex ambacho kinaweza kuona "hivi ndivyo inavyofanya kazi kwenye iOS" na "hapa kuna usanifu wa Android" ni bora zaidi kuliko kile kinachofanya kazi tu kutoka kwa maelezo ya lugha asilia.

Kuweka kanuni hizi kazini, tulifanya repos za iOS, backend na Android zipatikane katika mazingira sawa. Tulitoa dokeza kwa Codex kama:

Soma miundo na miisho katika msimbo wa iOS kisha pendekeza mpango wa kutekeleza tabia sawa kwenye Android kwa kutumia programu teja yetu ya API na madarasa ya muundo tuliyonayo.

Njia moja ndogo lakini muhimu ilikuwa kueleza katika ~/.codex/AGENTS.md mahali ambapo repo za ndani zipo na kile zinachobeba. Hiyo ilirahisisha Codex kugundua na kuvinjari msimbo unaohusika.

Tulikuwa tunafanya maendeleo ya majukwaa mbalimbali kwa ufanisi kupitia tafsiri badala ya dhana ya pamoja. Kwa sababu Codex ilishughulikia sehemu kubwa ya tafsiri, tuliepuka kuongezeka kwa gharama za utekelezaji mara mbili.

Somo pana ni kwamba kwa Codex, muktadha ni kila kitu. Codex ilifanya kazi bora zaidi ilipoelewa jinsi kipengele kilivyokuwa kikifanya kazi tayari katika iOS, pamoja na uelewa wa jinsi programu yetu ya Android ilivyopangwa. Wakati Codex ilikosa muktadha huo, haikuwa "ikikataa kushirikiana"; ilikuwa inakisia. Kadri tulivyozidi kuichukulia kama mchezaji mpya wa timu na kuwekeza katika kutoa maingizo sahihi, ndivyo ilivyofanya vizuri zaidi.

Mwisho wa mbio zetu za wiki nne, kutumia Codex kuliacha kuhisi kama jaribio na kuwa mzunguko wetu wa chaguomsingi wa maendeleo. Tulitumia kuelewa msimbo uliopo, kutengeneza mpango wa mabadiliko, na kutekeleza vipengele. Tulipitia matokeo yake kwa njia ile ile tungepitia ya mwenzetu. Ilikuwa tu jinsi tulivyowasilisha programu.

Ilionekana wazi kwamba maendeleo yanayosaidiwa na AI hayapunguzi hitaji la umakini; bali yanaongeza hitaji hilo. Ingawa Codex ina uwezo, lengo lake ni kufika kutoka A hadi B, sasa hivi. Hii ndiyo sababu usimbaji unaosaidiwa na AI hauwezi kufanya kazi bila wanadamu. Wahandisi wa programu wanaweza kuelewa na kutumia vikwazo halisi vya mifumo, njia bora za kubuni programu, na jinsi ya kujenga kwa kuzingatia mipango ya maendeleo ya baadaye na bidhaa. Nguvu kuu za mhandisi wa programu wa kesho zitakuwa uelewa wa kina wa mifumo na uwezo wa kufanya kazi kwa ushirikiano na AI kwa muda mrefu. 

Sehemu za kuvutia zaidi za uhandisi wa programu ni kujenga bidhaa za kuvutia, kubuni mifumo inayoweza kupanuka, kuandika algorithimu changamano, na kufanya majaribio na data, miundo, na msimbo. Hata hivyo, uhalisia wa uhandisi wa programu wa zamani na wa sasa mara nyingi huwa wa kawaida zaidi: kuweka vifungo katikati, kuunganisha sehemu za mwisho, na kuandika maandishi ya boilerplate. Sasa, Codex inafanya iwezekane kuzingatia sehemu muhimu zaidi za uhandisi wa programu na sababu tunazopenda ufundi wetu.

Mara Codex inapowekwa katika mazingira yenye muktadha mwingi ambapo inaelewa malengo yako na jinsi unavyopenda kujenga, timu yoyote inaweza kuzidisha uwezo wake. Uzinduzi wetu wa retro si suluhisho la aina moja kwa wote, na hatudai kuwa tumetatua maendeleo yanayosaidiwa na AI. Lakini tunatumai uzoefu wetu unafanya iwe rahisi kupata njia bora za kuwezesha Codex kukuwezesha wewe. 

Codex ilipozinduliwa kama onyesho la awali la utafiti miezi saba iliyopita, uhandisi wa programu ulikuwa tofauti sana. Kupitia Sora, tulipata kugundua sura inayofuata ya uhandisi. Kadiri miundo yetu na vifaa vinavyoendelea kuboreshwa, AI itakuwa sehemu muhimu zaidi ya ujenzi. 

Utafanya nini na timu yako ya Codex?