Cara kami menggunakan Codex untuk membangun Sora untuk Android dalam 28 hari

Mulai 26 April 2026, produk Sora tidak lagi tersedia.

Pada bulan November, kami meluncurkan aplikasi Sora untuk Android ke seluruh dunia, memberikan siapa pun dengan perangkat Android kemampuan untuk mengubah prompt singkat menjadi video yang hidup. Pada hari peluncuran, aplikasi ini meraih peringkat 1 di Play Store. Pengguna Android membuat lebih dari satu juta video dalam 24 jam pertama.

Di balik peluncuran ini ada sebuah cerita: versi awal aplikasi Android produksi Sora dibangun dalam 28 hari, berkat agen yang sama yang tersedia untuk tim atau pengembang mana pun: Codex.

Dari 8 Oktober hingga 5 November 2025, sebuah tim rekayasa yang ramping bekerja bersama Codex dan mengonsumsi sekitar 5 miliar token, meluncurkan Sora untuk Android dari prototipe hingga peluncuran global. Meskipun skalanya besar, aplikasi ini memiliki tingkat bebas crash sebesar 99,9 persen dan arsitektur yang kami banggakan. Jika Anda bertanya-tanya apakah kami menggunakan model rahasia, kami menggunakan versi awal dari model GPT‑5.1‑Codex –versi yang sama yang dapat digunakan oleh pengembang atau bisnis saat ini melalui CLI, ekstensi IDE, atau aplikasi web.

Ketika Sora diluncurkan di iOS, penggunaannya meningkat pesat. Orang-orang segera mulai membuat serangkaian video. Sebaliknya, di Android, kami hanya memiliki prototipe internal kecil dan jumlah pengguna praregistrasi yang terus bertambah di Google Play.

Respons umum terhadap peluncuran yang berisiko tinggi dan tertekan waktu adalah menambah sumber daya dan menambah proses. Sebuah aplikasi produksi dengan cakupan dan kualitas seperti ini biasanya melibatkan banyak insinyur yang bekerja selama berbulan-bulan, diperlambat oleh koordinasi. 

Arsitek komputer Amerika Fred Brooks dengan terkenal memperingatkan bahwa "menambahkan lebih banyak orang ke proyek perangkat lunak yang terlambat membuatnya makin terlambat." Dengan kata lain, ketika berusaha menyelesaikan proyek yang kompleks dengan cepat, menambah lebih banyak insinyur sering kali dapat memperlambat efisiensi dengan meningkatkan beban komunikasi, fragmentasi tugas, dan biaya integrasi. Kami memanfaatkan wawasan ini alih-alih mengabaikannya; kami membentuk tim yang kuat yang terdiri dari empat insinyur—semuanya dilengkapi dengan Codex untuk secara drastis meningkatkan dampak masing-masing insinyur. 

Dengan cara ini, kami mengirimkan build internal Sora untuk Android kepada para karyawan dalam 18 hari dan meluncurkannya secara publik 10 hari kemudian. Kami mempertahankan standar tinggi dalam praktik rekayasa Android, berinvestasi dalam pemeliharaan, dan menetapkan aplikasi pada standar keandalan yang sama seperti yang Anda harapkan dari proyek yang lebih tradisional. (Kami juga lanjutkan menggunakan Codex secara ekstensif saat ini untuk mengembangkan dan menghadirkan fitur-fitur baru ke aplikasi).

Untuk memahami bagaimana kami bekerja dengan Codex, penting untuk mengetahui di mana keunggulannya dan di mana Codex memerlukan arahan. Memperlakukan Codex seperti seorang insinyur senior yang baru dipekerjakan adalah pendekatan yang baik. Kemampuan Codex berarti kami dapat menghabiskan lebih banyak waktu untuk mengarahkan dan meninjau kode daripada menulisnya sendiri.

Di mana Codex memerlukan panduan

1. Codex belum sepenuhnya mampu menyimpulkan apa yang belum diberitahukan kepadanya (misalnya, pola arsitektur yang Anda sukai, strategi produk, perilaku pengguna yang sesungguhnya, dan norma atau pintasan internal).
2. Demikian pula, Codex tidak dapat melihat aplikasi benar-benar berjalan: Codex tidak dapat membuka Sora pada perangkat, menyadari bahwa guliran terasa tidak tepat, atau merasakan bahwa sebuah alur membingungkan. Hanya tim kami yang dapat menangani tugas-tugas eksperimental ini.
3. Setiap instans memerlukan orientasi. Berbagi konteks dengan tujuan yang jelas, batasan, dan panduan tentang "cara kami melakukan sesuatu" sangat penting untuk membuat Codex berfungsi dengan baik.
4. Dalam konteks yang sama, Codex mengalami kesulitan dengan penilaian arsitektur yang mendalam: Jika dibiarkan sendiri, Codex mungkin akan memperkenalkan model tampilan tambahan di mana kita sebenarnya ingin memperluas model yang ada atau mendorong logika ke dalam lapisan UI yang seharusnya jelas berada di dalam repositori. Naluri utamanya adalah untuk membuat sesuatu berfungsi, bukan untuk mengutamakan kebersihan jangka panjang.

Kami menemukan bahwa menggunakan Codex untuk membuat dan memelihara sejumlah besar berkas AGENT.md di seluruh basis kode sangat berguna. Ini memudahkan penerapan panduan dan praktik terbaik yang sama di seluruh sesi. Misalnya, untuk memastikan Codex menulis kode sesuai dengan pedoman gaya kami, kami menambahkan hal berikut ke AGENTS.md tingkat atas kami:

Di mana Codex unggul

1. Membaca dan memahami basis kode besar dengan cepat: Codex mengetahui hampir semua bahasa pemrograman utama, yang memudahkan Anda untuk memanfaatkan konsep yang sama di berbagai platform tanpa abstraksi yang kompleks.
2. Cakupan pengujian: Codex sangat antusias (secara unik) dalam menulis pengujian unit untuk mencakup berbagai macam kasus. Tidak setiap pengujian dilakukan secara mendalam, tetapi memiliki cakupan yang luas sangat membantu dalam mencegah regresi. 
3. Menerapkan masukan: Dalam konteks yang sama, Codex sangat bagus dalam menanggapi masukan. Ketika CI gagal, kami dapat menempelkan keluaran log ke dalam prompt dan meminta Codex untuk mengusulkan perbaikan.
4. Eksekusi paralel secara masif dan sekali pakai: Sebagian besar tidak akan mendorong batas jumlah sesi yang sebenarnya dapat dijalankan pada satu waktu. Sangat mungkin untuk menguji berbagai ide secara paralel dan menganggap kode sebagai sesuatu yang dapat dibuang.
5. Menawarkan perspektif baru: Dalam diskusi desain, kami menggunakan Codex sebagai alat generatif untuk menjelajahi potensi titik kegagalan dan menemukan cara baru untuk menyelesaikan masalah. Misalnya, ketika kami merancang optimasi memori pemutar video, Codex menelusuri berbagai SDK untuk mengusulkan pendekatan yang tidak sempat kami telaah. Wawasan dari penelitian Codex terbukti sangat berharga dalam meminimalkan jejak memori pada aplikasi akhir.
6. Memungkinkan pekerjaan dengan tingkat pemanfaatan yang lebih tinggi: Dalam praktiknya, kami akhirnya menghabiskan lebih banyak waktu untuk meninjau dan mengarahkan kode daripada menulisnya sendiri. Namun demikian, Codex juga sangat baik dalam peninjauan kode, sering kali menemukan bug sebelum bug tersebut digabungkan, sehingga meningkatkan keandalan.

Setelah kami mengakui karakteristik ini, model kerja kami menjadi lebih sederhana. Kami mengandalkan Codex untuk melakukan banyak pekerjaan berat dalam pola yang sudah dipahami dengan baik dan lingkup yang terbatas, sementara tim kami fokus pada arsitektur, pengalaman pengguna, perubahan sistemik, dan kualitas akhir.

Bahkan karyawan baru senior terbaik pun tidak memiliki sudut pandang yang tepat untuk membuat pertimbangan jangka panjang dengan segera. Untuk memanfaatkan Codex dan memastikan bahwa kinerjanya kuat dan dapat dipelihara, sangat penting bagi kami untuk mengawasi desain sistem aplikasi dan pertimbangan kunci secara langsung. Ini termasuk membentuk arsitektur aplikasi, modularisasi, injeksi dependensi, dan navigasi; kami juga menerapkan alur otentikasi dan alur jaringan dasar. 

Dari dasar ini, kami menulis beberapa fitur perwakilan secara menyeluruh. Kami menggunakan aturan yang kami inginkan agar diikuti oleh seluruh basis kode dan mendokumentasikan pola-pola proyek secara keseluruhan saat kami melakukannya. Dengan mengarahkan ke fitur-fitur representatif, Codex dapat bekerja lebih mandiri sesuai dengan standar kami. Untuk proyek yang kami perkirakan 85% ditulis oleh Codex, fondasi yang direncanakan dengan hati-hati menghindari penelusuran ulang dan refaktorisasi yang mahal. Itu adalah salah satu keputusan terpenting yang kami buat. 

Idenya bukan untuk membuat "sesuatu yang berfungsi" secepat mungkin, melainkan untuk membuat "sesuatu yang memahami bagaimana kita ingin sesuatu itu berfungsi." Ada banyak cara “benar” untuk menulis kode. Kami tidak perlu memberi tahu Codex secara persis apa yang harus dilakukan; kami perlu menunjukkan kepada Codex apa yang "benar" di tim kami. Setelah kami menetapkan titik awal dan cara kami suka membangun, Codex siap untuk memulai.

Untuk melihat apa yang akan terjadi, kami memang mencoba memberikan perintah: "Bangun aplikasi Sora Android berdasarkan kode iOS." Kerjakan," tetapi dengan cepat membatalkan rencana itu. Meskipun apa yang dibuat Codex secara teknis berfungsi, pengalaman produk tidak memadai. Dan tanpa pemahaman yang jelas tentang endpoint, data, dan alur pengguna, kode sekali coba Codex tidak dapat diandalkan (Bahkan tanpa menggunakan agen, berisiko untuk menggabungkan ribuan baris kode.) 

Kami berhipotesis bahwa Codex akan berkembang dalam sandbox dengan contoh-contoh yang ditulis dengan baik; dan kami benar. Meminta Codex untuk "membangun layar pengaturan ini" dengan hampir tanpa konteks adalah tidak dapat diandalkan. Meminta Codex untuk "membangun layar pengaturan ini menggunakan arsitektur dan pola yang sama seperti layar lain yang baru saja Anda lihat" ternyata jauh lebih baik. Manusia membuat keputusan struktural dan menetapkan invarian; Codex kemudian mengisi sejumlah besar kode di dalam struktur tersebut.

Langkah kami selanjutnya dalam memaksimalkan potensi Codex adalah mencari cara agar Codex dapat bekerja dalam jangka waktu yang lama (saat ini, lebih dari 24 jam⁠), tanpa pengawasan.

Pada tahap awal penggunaan Codex, kami segera beralih ke prompt seperti, “Ini adalah fiturnya. Berikut adalah beberapa file. Harap bangun itu.” Hal itu kadang-kadang berhasil, tetapi sebagian besar menghasilkan kode yang secara teknis dapat dikompilasi, tetapi menyimpang dari arsitektur dan tujuan kami.

Jadi kami mengubah alur kerja. Untuk setiap perubahan yang tidak sepele, kami pertama-tama meminta Codex untuk membantu kami memahami cara kerja sistem dan kode. Misalnya, kami akan memintanya untuk membaca satu set file terkait dan merangkum bagaimana fitur tersebut bekerja; misalnya, bagaimana data mengalir dari API melalui lapisan repositori, model tampilan, dan ke dalam UI. Kemudian kami akan memperbaiki atau menyempurnakan pemahamannya. (Misalnya, kami akan menunjukkan bahwa suatu abstraksi tertentu sebenarnya lebih cocok berada di lapisan yang berbeda atau bahwa kelas tertentu hanya ada untuk mode offline dan tidak boleh diperluas.)

Demikian pula dengan cara Anda mungkin berinteraksi dengan rekan tim baru yang sangat cakap, kami bekerja dengan Codex untuk membuat paket implementasi yang solid. Paket tersebut sering kali tampak seperti dokumen desain miniatur yang mengarahkan file mana yang harus diubah, keadaan baru apa yang harus diperkenalkan, dan bagaimana logika harus mengalir. Barulah kemudian kami meminta Codex untuk mulai menerapkan paket, satu langkah pada satu waktu. Satu tip yang berguna: untuk tugas yang sangat panjang, di mana kita mencapai batas jendela konteks, kami akan meminta Codex untuk menyimpan paketnya ke dalam file, memungkinkan kami menerapkan arahan yang sama di berbagai instan.

Siklus perencanaan tambahan ini ternyata sepadan dengan waktu yang dihabiskan. Ini memungkinkan kami untuk membiarkan Codex berjalan "tanpa pengawasan" untuk waktu yang lama, karena kami mengetahui rencananya. Ini membuat peninjauan kode lebih mudah, karena kami dapat memeriksa implementasi terhadap rencana kami daripada diff perbedaan tanpa konteks. Dan ketika terjadi kesalahan, kita bisa merunut rencananya terlebih dahulu dan kemudian kodenya. 

Dinamika tersebut terasa mirip dengan cara sebuah dokumen desain yang baik memberikan kepercayaan kepada seorang pemimpin teknologi dalam sebuah proyek. Kami tidak hanya membuat kode: kami membuat kode yang mendukung peta jalan bersama.

Pada puncak proyek, kami sering menjalankan beberapa sesi Codex secara paralel. Seseorang bekerja pada pemutaran, yang lain pada pencarian, yang lain pada penanganan kesalahan, dan kadang-kadang yang lain pada pengujian atau refaktor. Hal ini terasa kurang seperti menggunakan alat dan lebih seperti mengelola tim.

Setiap sesi akan secara berkala melaporkan kembali kemajuan kepada kami. Seseorang mungkin berkata, "Saya sudah selesai merencanakan modul ini; berikut adalah yang saya usulkan," sementara yang lain akan menawarkan perubahan besar untuk fitur baru. Masing-masing memerlukan perhatian, masukan, dan peninjauan. Itu sangat mirip dengan menjadi pemimpin teknologi dengan beberapa insinyur baru, semuanya membuat kemajuan, semuanya membutuhkan bimbingan.

Hasilnya adalah alur kolaboratif. Kemampuan pengodean mentah Codex membebaskan kami dari banyak pengetikan manual. Kami memiliki lebih banyak waktu untuk memikirkan arsitektur, membaca permintaan tarik dengan cermat, dan menguji aplikasi. 

Pada saat yang sama, kecepatan ekstra itu berarti kami selalu memiliki sesuatu yang menunggu di antrean tinjauan kami. Codex tidak terhambat oleh pergantian konteks, tetapi kami yang terhambat. Hambatan kami dalam pengembangan bergeser dari menulis kode menjadi membuat keputusan, memberikan masukan, dan mengintegrasikan perubahan.

Di sinilah wawasan Brooks menemukan cara baru. Anda tidak dapat begitu saja menambahkan sesi Codex dan mengharapkan peningkatan kecepatan yang linear, sama seperti Anda tidak dapat terus menambahkan insinyur ke sebuah proyek dan mengharapkan jadwalnya menyusut secara linear. Setiap tambahan "tangan," bahkan yang virtual, menambah beban koordinasi. Kami telah menjadi konduktor sebuah orkestra dibandingkan hanya pemain solo yang lebih cepat.

Kami memulai proyek kami dengan batu loncatan besar: Sora sudah diluncurkan di iOS. Kami sering mengarahkan Codex ke basis kode iOS dan backend untuk membantunya memahami persyaratan dan batasan utama. Sepanjang proyek, kami bercanda bahwa kami telah menemukan kembali gagasan tentang kerangka kerja lintas platform. Lupakan React Native atau Flutter; masa depan lintas platform hanyalah Codex.

Di balik candaan tersebut terdapat dua prinsip:.

1. Logika dapat dipindahkan. Baik jika kode ditulis dalam Swift atau Kotlin, logika aplikasi yang mendasarinya—model data, panggilan jaringan, aturan validasi, logika bisnis—tetap sama. Codex sangat baik dalam membaca implementasi Swift dan menghasilkan padanan dalam Kotlin yang mempertahankan semantik.
2. Contoh konkret memberikan konteks yang kuat. Sesi Codex baru yang dapat melihat "inilah cara kerjanya di iOS" dan "inilah arsitektur Android" jauh lebih efektif daripada yang hanya bekerja dari deskripsi bahasa alami.

Dengan menerapkan prinsip-prinsip ini, kami membuat repositori iOS, backend, dan Android tersedia dalam lingkungan yang sama. Kami memberikan prompt kepada Codex seperti:

“Bacalah model dan endpoint ini dalam kode iOS dan kemudian usulkan rencana untuk menerapkan perilaku yang setara di Android menggunakan klien API dan kelas model yang sudah ada.”

Satu trik kecil namun berguna adalah memperinci di ~/.codex/AGEN.md di mana repo lokal berada dan apa yang mereka kandung. Hal itu mempermudah Codex untuk menemukan dan menavigasi kode yang relevan.

Kami secara efektif melakukan pengembangan lintas platform melalui penerjemahan alih-alih abstraksi bersama. Karena Codex menangani sebagian besar terjemahan, kami menghindari penggandaan biaya implementasi.

Pelajaran yang lebih luas adalah bahwa bagi Codex, konteks adalah segalanya. Codex melakukan pekerjaan terbaiknya ketika memahami cara kerja fitur tersebut di iOS, dipadukan dengan pemahaman tentang struktur aplikasi Android kami. Ketika Codex kekurangan konteks tersebut, itu bukan berarti "menolak untuk bekerja sama"; melainkan sedang menebak. Makin kami memperlakukannya seperti rekan satu tim baru dan berinvestasi dalam memberikan masukan yang tepat, makin baik kinerjanya.

Pada akhir sprint empat minggu kami, penggunaan Codex berhenti terasa seperti eksperimen dan menjadi siklus pengembangan default kami. Kami menggunakannya untuk memahami kode yang ada, merencanakan perubahan, dan mengimplementasikan fitur. Kami meninjau hasilnya dengan cara yang sama seperti kami meninjau hasil kerja rekan kerja. Begitulah cara kami menyelesaikan perangkat lunak.

Menjadi jelas bahwa pengembangan yang dibantu AI tidak mengurangi kebutuhan akan ketelitian; justru meningkatkannya. Meskipun Codex sangat canggih, tujuannya adalah untuk mencapai tujuan dari A ke B, secepatnya. Inilah mengapa pengodean berbantuan AI tidak dapat berfungsi tanpa manusia. Insinyur perangkat lunak dapat memahami dan menerapkan batasan dunia nyata dari sistem, cara terbaik untuk merancang perangkat lunak, dan cara membangun dengan mempertimbangkan pengembangan masa depan dan paket-paket produk. Kekuatan super dari insinyur perangkat lunak masa depan adalah pemahaman sistem yang mendalam dan kemampuan untuk bekerja secara kolaboratif dengan AI dalam jangka waktu yang panjang. 

Bagian paling menarik dari rekayasa perangkat lunak adalah membangun produk yang menarik, merancang sistem yang dapat diskalakan, menulis algoritma yang kompleks, dan bereksperimen dengan data, pola, dan kode. Namun, realitas rekayasa perangkat lunak di masa lalu dan sekarang sering kali lebih membosankan: memusatkan tombol, menghubungkan endpoint, dan menulis kode template. Sekarang, Codex memungkinkan kita untuk fokus pada bagian-bagian paling penting dalam rekayasa perangkat lunak dan alasan mengapa kita mencintai pekerjaan ini.

Setelah Codex diatur dalam lingkungan yang kaya konteks di mana ia memahami tujuan Anda dan cara Anda membangun, tim mana pun dapat menggandakan kemampuannya. Peluncuran retro kami bukanlah resep seragam untuk semua, dan kami tidak mengklaim telah menyelesaikan pengembangan yang dibantu AI. Namun kami berharap pengalaman kami memudahkan Anda menemukan cara terbaik untuk memberdayakan Codex agar dapat memberdayakan Anda. 

Ketika Codex diluncurkan dalam pratinjau riset tujuh bulan yang lalu, rekayasa perangkat lunak tampak sangat berbeda. Melalui Sora, kami dapat menjelajahi babak selanjutnya dari teknik. Seiring dengan terus meningkatnya model dan sistem pengendalian kami, AI akan menjadi bagian yang makin tak tergantikan dalam proses pembangunan. 

Apa yang akan Anda buat dengan tim Codex Anda sendiri?