Carane kita nggunakake Codex kanggo ngirim Sora kanggo Android sajrone 28 dina

Wiwit 26 April 2026, produk Sora wis ora kasedhiya maneh.

Ing November, kita ngluncurake app Android Sora menyang saindenging jagad, menehi sapa wae sing nduweni piranti Android kemampuan kanggo ngowahi prompt cekak dadi video sing cetha lan urip. Ing dina peluncuran, app iki tekan peringkat #1 ing Play Store. Pangguna Android ngasilake luwih saka sejuta video ing 24 jam pisanan.

Ing balik peluncuran iki ana sawijining crita: versi awal app Android produksi Sora dibangun sajrone 28 dina, amarga agen sing padha sing kasedhiya kanggo tim utawa pangembang apa wae: Codex.

Saka 8 Oktober nganti 5 November 2025, tim engineering sing ramping sing kerja bebarengan karo Codex lan nggunakke kira-kira 5 milyar token, ngirim Sora kanggo Android saka prototipe nganti peluncuran global. Senadyan skalahe gedhe, app iki nduweni tingkat bebas crash 99,9 persen lan arsitektur sing gawe bangga. Yen sampeyan mikir apa kita nggunakake model rahasia, kita nggunakake versi awal saka model GPT‑5.1‑Codex – versi sing padha sing bisa digunakake pangembang utawa bisnis apa wae dina iki liwat CLI, ekstensi IDE, utawa app web.

Nalika Sora diluncurake ing iOS, panggunaan njeblug. Wong-wong langsung wiwit nggawe aliran video. Ing Android, kosok baline, kita mung duwe prototipe internal cilik lan jumlah pangguna sing wis ndhaptar sadurunge ing Google Play saya mundhak.

Tanggapan umum tumrap peluncuran sing taruhane gedhe lan ditekan wektu yaiku nambah sumber daya lan proses. App produksi kanthi cakupan lan kualitas kaya iki biasane bakal nglibatake akeh insinyur sing kerja nganti pirang-pirang sasi, lan dadi alon amarga koordinasi.

Arsitek komputer Amerika Fred Brooks misuwur ngelingake manawa “nambah wong luwih akeh menyang proyek piranti lunak sing telat bakal nggawe luwih telat.” Tegese, nalika nyoba ngirim proyek rumit kanthi cepet, nambah luwih akeh insinyur asring malah nyuda efisiensi amarga nambah beban komunikasi, fragmentasi tugas, lan biaya integrasi. Kita milih ngetrapake wawasan iki tinimbang nglirwakake; kita nglumpukake tim kuwat sing dumadi saka papat insinyur – kabeh dilengkapi Codex kanggo nambah dampak saben insinyur kanthi drastis.

Kanthi cara kerja kaya iki, kita ngirim build internal Sora kanggo Android menyang karyawan sajrone 18 dina lan ngluncurake kanggo umum 10 dina sawisé. Kita njaga standar dhuwur tumrap praktik engineering Android, nandur modal ing maintainability, lan njaga app iki ing standar reliabilitas sing padha karo sing bakal kita karepake saka proyek sing luwih tradisional. (Kita uga terus nggunakke Codex kanthi ekstensif nganti saiki kanggo ngembangake lan nambah fitur anyar menyang app).

Kanggo mangerteni carane kita kerja karo Codex, penting ngerti ing ngendi dheweke unggul lan ing ngendi dheweke butuh arahan. Nganggep dheweke kaya insinyur senior sing lagi wae direkrut iku pendekatan sing apik. Kemampuan Codex ndadekake kita bisa luwih akeh ngentekake wektu kanggo ngarahake lan mriksa kode tinimbang nulis dhewe.

Ing ngendi Codex butuh pandhuan

1. Codex durung apik banget kanggo nyimpulake apa sing durung dicritakake marang dheweke (contone pola arsitektur sing sampeyan senengi, strategi produk, prilaku pangguna nyata, lan norma utawa trabasan internal).
2. Semono uga, Codex ora bisa ndeleng app mlaku tenan: dheweke ora bisa mbukak Sora ing piranti, ngerti manawa scroll krasa ora pas, utawa ngrasakake yen sawijining alur mbingungake. Mung tim kita sing bisa nutupi tugas-tugas pengalaman kaya iki.
3. Saben instance mbutuhake onboarding. Nuduhake konteks kanthi tujuan, watesan, lan pandhuan “carane kita nindakake samubarang” kanthi cetha iku penting supaya Codex bisa eksekusi kanthi apik.
4. Kanthi semangat sing padha, Codex kesulitan ing penilaian arsitektur sing jero: yen dibiarke dhewe, dheweke bisa wae nambah view model ekstra nalika sing sejatine kita karepake yaiku ngembangake sing wis ana utawa nyurung logika menyang lapisan UI sing mesthine cetha kalebu ing repository. Instinge yaiku nggawe soko bisa mlaku, dudu ngutamakake kebersihan jangka panjang.

Kita nemokake yen migunani supaya Codex nggawe lan njaga AGENT.md ing jumlah akeh ing saindenging codebase. Iki ndadekake gampang nerapake pandhuan lan praktik paling apik sing padha ing macem-macem sesi. Contone, kanggo mesthekake Codex nulis kode miturut pedoman gaya kita, kita nambahake iki ing AGENTS.md tingkat ndhuwur:

Ing ngendi Codex unggul

1. Maca lan mangerteni codebase gedhe kanthi cepet: Codex ngerti meh kabeh basa pamrograman utama, sing ndadekake luwih gampang nggunakke konsep sing padha ing akeh platform tanpa abstraksi sing rumit.
2. Cakupan testing: Codex (kanthi unik) antusias nulis unit test kanggo nutupi macem-macem kasus. Ora saben test jero, nanging ambane cakupan iki migunani kanggo nyegah regresi.
3. Nerapake umpan balik: Kanthi cara sing padha, Codex apik nanggapi umpan balik. Nalika CI gagal, kita bisa nempelake output log menyang prompt lan njaluk Codex ngusulake perbaikan.
4. Eksekusi paralel masif sing bisa dibuwang: Umume wong ora bakal nyurung wates jumlah sesi sing sejatine bisa dijalanke bebarengan ing siji wektu. Nguji akeh gagasan kanthi paralel lan ndeleng kode minangka barang sing bisa dibuwang iku banget bisa ditindakake.
5. Nawakake perspektif anyar: Ing diskusi desain, kita nggunakke Codex minangka alat generatif kanggo njelajah titik gagal potensial lan nemokake cara anyar kanggo ngrampungake masalah. Contone, nalika kita ngrancang optimasi memori video player, Codex nyaring pirang-pirang SDK kanggo ngusulake pendekatan sing ora bakal sempat kita telaah. Wawasan saka riset Codex mbuktekake banget aji kanggo nyilikake jejak memori ing app final.
6. Ngidini karya kanthi daya ungkit luwih dhuwur: Ing praktik, pungkasane kita luwih akeh ngentekake wektu mriksa lan ngarahake kode tinimbang nulis dhewe. Nanging, Codex uga apik banget ing code review, asring nemokake bug sadurunge digabungake, saengga nambah reliabilitas.

Sawisé kita ngakoni ciri-ciri iki, model kerja kita dadi luwih lugas. Kita ngandelake Codex kanggo nindakake akeh kerja abot ing njero pola sing wis dipahami lan cakupan sing winates kanthi cetha, nalika tim kita fokus ing arsitektur, pengalaman pangguna, owah-owahan sistemik, lan kualitas pungkasan.

Malah rekrutan senior anyar sing paling apik sekalipun ora langsung duwe sudut pandang sing pas kanggo nggawe trade-off jangka panjang. Kanggo nggunakke Codex lan mesthekake asil kerjane kuwat lan gampang dirawat, penting supaya kita dhewe ngawasi desain sistem app lan trade-off utama. Iki kalebu mbentuk arsitektur app, modularisasi, dependency injection, lan navigasi; kita uga ngetrapake autentikasi lan alur jaringan dhasar.

Saka pondasi iki, kita nulis sawetara fitur perwakilan saka awal nganti akhir. Kita nggunakke aturan sing kita karepake dituruti dening kabeh codebase lan ndokumentasikake pola sakproyek nalika proses mlaku. Kanthi nuduhake Codex menyang fitur-fitur perwakilan, dheweke bisa kerja luwih mandiri ing njero standar kita. Kanggo proyek sing kira-kira 85% ditulis dening Codex, pondasi sing dirancang kanthi teliti ngindhari mundur langkah lan refactor sing larang. Iki salah siji keputusan paling penting sing kita gawe.

Gagasane dudu nggawe “soko sing bisa mlaku” sakcepet mungkin, nanging nggawe “soko sing paham carane kita pengin samubarang bisa mlaku.” Ana akeh cara “bener” kanggo nulis kode. Kita ora perlu ngandhani Codex kanthi persis apa sing kudu ditindakake; kita perlu nuduhake marang Codex apa sing “bener” ing tim kita. Sawisé kita netepake titik wiwitan lan carane kita seneng mbangun, Codex siap miwiti.

Kanggo ndeleng apa sing bakal kelakon, kita pancen nyoba menehi prompt: “Build the Sora Android app based on the iOS code. Go,” nanging cepet mbatalake jalur kasebut. Sanajan apa sing digawe Codex sacara teknis bisa mlaku, pengalaman produke kurang apik. Lan tanpa pangerten sing cetha babagan titik pungkasan, data, lan alur pangguna, kode one-shot saka Codex ora bisa diandelake (Malah tanpa nggunakke agen, nggabungake ewonan baris kode iku berisiko.)

Kita nduweni hipotesis yen Codex bakal unggul ing sandbox sing kebak conto sing ditulis kanthi apik; lan kita bener. Njaluk Codex kanggo “mbangun layar setelan iki” tanpa meh ana konteks iku ora bisa diandelake. Njaluk Codex kanggo “mbangun layar setelan iki nggunakake arsitektur lan pola sing padha karo layar liyane sing lagi wae sampeyan deleng” asilé luwih apik. Manungsa nggawe keputusan struktural lan netepake invarians; Codex banjur ngisi akeh kode ing njero struktur kasebut.

Langkah sabanjure kanggo ngoptimalake potensi Codex yaiku nemtokake carane ngidini Codex kerja suwe banget (anyar-anyar iki, luwih saka 24 jam⁠), tanpa pengawasan.

Ing awal nggunakke Codex, kita langsung marani prompt kaya, “Iki fiture. Iki sawetara file. Tulung bangun iki.” Kadhangkala iku bisa, nanging paling kerep ngasilake kode sing sacara teknis bisa dikompilasi, nanging nyimpang saka arsitektur lan tujuan kita.

Mula kita ngganti alur kerja. Kanggo saben owah-owahan sing ora sepele, luwih dhisik kita njaluk Codex mbantu kita mangerteni carane sistem lan kode kasebut bisa mlaku. Contone, kita njaluk dheweke maca sakumpulan file sing ana gandhengane lan ngringkes carane fitur kasebut mlaku; umpamané, carane data mili saka API liwat lapisan repository, view model, lan mlebu menyang UI. Banjur kita mbenerake utawa nyaring pangerten kasebut. (Contone, kita bakal nuduhake yen sawijining abstraksi tartamtu sejatine luwih cocog ana ing lapisan liya utawa yen sawijining kelas mung ana kanggo mode offline lan ora kena dikembangake.)

Kaya nalika sampeyan melu kerja bareng kanca tim anyar sing trampil banget, kita kerja bareng Codex kanggo nggawe rencana implementasi sing kuwat. Rencana kasebut asring katon kaya dokumen desain mini sing ngarahake file endi sing kudu diganti, state anyar apa sing kudu ditambahake, lan carane logika kudu mili. Mung sawise iku kita njaluk Codex miwiti nerapake rencana kasebut, langkah demi langkah. Siji tips migunani: kanggo tugas sing dawa banget, nalika kita kena wates context window, kita njaluk Codex nyimpen rencanane menyang file, supaya kita bisa nerapake arah sing padha ing macem-macem instance.

Putaran perencanaan ekstra iki jebul pantes kanggo wektu sing diwenehake. Iki ngidini kita ngeculake Codex mlaku “tanpa pengawasan” suwene wektu dawa, amarga kita ngerti rencanane. Iki nggawe code review luwih gampang, amarga kita bisa mriksa implementasi adhedhasar rencana kita tinimbang maca diff tanpa konteks. Lan nalika ana sing salah, kita bisa debug rencanane luwih dhisik lan kodené sawisé.

Dinamika iki krasa mirip karo cara dokumen desain sing apik menehi kapercayan marang tech lead marang sawijining proyek. Kita ora mung ngasilake kode: kita ngasilake kode sing ndhukung roadmap sing dienggo bebarengan.

Ing puncak proyek, kita kerep mbukak pirang-pirang sesi Codex kanthi paralel. Siji lagi nggarap playback, liyane search, liyane error handling, lan kadhangkala liyane maneh kanggo test utawa refactor. Rasane kurang kaya nggunakke alat lan luwih kaya ngatur tim.

Saben sesi bakal nglaporake kemajuan marang kita saka wektu ke wektu. Sing siji bisa ngomong, “Aku wis rampung ngrancang modul iki; iki usulku,” dene liyane menehi diff gedhe kanggo fitur anyar. Saben siji mbutuhake perhatian, umpan balik, lan review. Rasane mirip banget karo dadi tech lead sing duwe sawetara insinyur anyar, kabeh maju, kabeh butuh pandhuan.

Asilé yaiku alur kolaboratif. Kemampuan ngoding mentah Codex mbebasake kita saka akeh ngetik manual. Kita nduweni luwih akeh wektu kanggo mikir babagan arsitektur, maca panyuwunan tarik kanthi teliti, lan nyoba app kasebut.

Ing wektu sing padha, kacepetan ekstra kasebut ateges mesthi ana sing nunggu ing antrean review kita. Codex ora keganggu amarga context switching, nanging kita iya. Bottleneck ing pangembangan pindhah saka nulis kode dadi nggawe keputusan, menehi umpan balik, lan ngintegrasi owah-owahan.

Ing kene wawasan Brooks tekan kanthi cara anyar. Sampeyan ora bisa mung nambah sesi Codex lan ngarepake peningkatan kacepetan linear, padha kaya sampeyan ora bisa terus nambah insinyur menyang proyek lan ngarepake jadwal nyusut kanthi linear. Saben “pasangan tangan” tambahan, sanajan virtual, nambah beban koordinasi. Kita wis dadi dirijen orkestra tinimbang mung solois sing luwih cepet.

Kita miwiti proyek iki kanthi pijakan gedhe: Sora wis luwih dhisik dirilis ing iOS. Kita kerep nuduhake codebase iOS lan backend marang Codex kanggo mbantu dheweke mangerteni syarat lan watesan utama. Sajrone proyek, kita guyon yen kita wis nemokake maneh gagasan framework lintas platform. Lali React Native utawa Flutter; masa depan lintas platform ya mung Codex.

Ing balik guyonan iki ana rong prinsip:.

1. Logika iku portabel. Apa kodené ditulis ing Swift utawa Kotlin, logika aplikasi dhasar – model data, panggilan jaringan, aturan validasi, logika bisnis – padha. Codex apik banget maca implementasi Swift lan ngasilake padanan ing Kotlin sing njaga semantik.
2. Conto konkret menehi konteks sing kuat. Sesi Codex anyar sing bisa ndeleng “iki persis carane iki mlaku ing iOS” lan “iki arsitektur Android” bakal luwih efektif tinimbang sesi sing mung kerja saka deskripsi basa alami.

Nerapake prinsip-prinsip iki, kita nggawe repo iOS, backend, lan Android kasedhiya ing lingkungan sing padha. Kita menehi Codex prompt kaya:

“Wacanen model lan titik pungkasan iki ing kode iOS banjur usulake rencana kanggo ngetrapake prilaku sing setara ing Android nggunakake API client lan kelas model sing wis ana.”

Salah siji trik cilik nanging migunani yaiku njlentrehake ing ~/.codex/AGENTS.md ing ngendi repo lokal manggon lan apa isine. Iki ndadekake luwih gampang kanggo Codex nemokake lan navigasi kode sing relevan.

Sejatine kita nindakake pangembangan lintas platform liwat terjemahan tinimbang abstraksi bebarengan. Amarga Codex nangani sebagian besar terjemahan kasebut, kita bisa ngindhari biaya implementasi tikel pindho.

Pelajaran sing luwih amba yaiku manawa kanggo Codex, konteks iku segalane. Codex nindakake karya paling apik nalika dheweke ngerti carane fitur kasebut wis mlaku ing iOS, dipasangake karo pangerten babagan carane app Android kita disusun. Nalika Codex kurang konteks, dheweke ora “nolakke kerja sama”; dheweke lagi ngira-ngira. Saya kita nambani dheweke kaya kanca tim anyar lan nandur modal kanggo menehi input sing pas, saya apik kinerjane.

Ing pungkasan sprint patang minggu kita, nggunakke Codex ora krasa kaya eksperimen maneh lan dadi puteran pangembangan bawaan kita. Kita nggunakke kanggo mangerteni kode sing wis ana, ngrancang owah-owahan, lan ngetrapake fitur. Kita mriksa output-é padha kaya kita mriksa karya kanca tim. Iki mung dadi cara kita ngirim piranti lunak.

Dadi cetha yen pangembangan sing dibantu AI ora nyuda kabutuhan kanggo ketelitian; malah nambah. Senajan Codex banget mumpuni, tujuane yaiku lunga saka A menyang B, saiki uga. Iki sebabé ngoding sing dibantu AI ora bisa mlaku tanpa manungsa. Insinyur piranti lunak bisa mangerteni lan nerapake watesan sistem ing donya nyata, cara paling apik kanggo ngrancang arsitektur piranti lunak, lan carane mbangun kanthi nggatekake pangembangan lan rencana produk ing mangsa ngarep. Superpower insinyur piranti lunak mbesuk yaiku pangerten sistem sing jero lan kemampuan kanggo kerja kolaboratif karo AI sajrone rentang wektu sing dawa.

Bagean paling menarik saka teknik piranti lunak yaiku mbangun produk sing narik, ngrancang sistem sing bisa diskalakake, nulis algoritma rumit, lan bereksperimen karo data, pola, lan kode. Nanging, kasunyatan teknik piranti lunak biyen lan saiki kerep luwih mundane: nyetel tombol supaya ana ing tengah, nyambungake titik pungkasan, lan nulis boilerplate. Saiki, Codex ndadekake kita bisa fokus ing bagean teknik piranti lunak sing paling migunani lan alasan kenapa kita tresna marang kerajinan iki.

Sawisé Codex disetel ing lingkungan sugih konteks sing ndadekake dheweke paham tujuan sampeyan lan carane sampeyan seneng mbangun, tim apa wae bisa nggedhekake kemampuane. Retro peluncuran kita dudu resep sing pas kanggo kabeh wong, lan kita ora ngaku wis ngrampungake pangembangan sing dibantu AI. Nanging kita ngarep-arep pengalaman kita nggawe luwih gampang kanggo nemokake cara paling apik supaya Codex bisa nguatake sampeyan.

Nalika Codex diluncurake ing research preview pitung sasi kepungkur, teknik piranti lunak katon beda banget. Liwat Sora, kita bisa njelajah bab sabanjure saka engineering. Nalika model lan harness kita terus saya apik, AI bakal dadi bagean sing saya ora bisa dipisahake saka proses mbangun.

Apa sing bakal sampeyan gawe karo tim Codex sampeyan dhewe?