OpenAI Codex Produk Manajer Langsung: Tanpa standar dan peta jalan, bagaimana kami bisa membuat produk?

“Minat dan otonomi adalah kualitas yang paling inti dan paling penting bagi manusia di era AGI.”

Susun & Kompilasi: Deep Tide TechFlow

Tamu: Alex, Kepala Produk Codex; Romain, Pengalaman Pengembang (Developer Experience) Codex

Pemandu: Peter Yang

Sumber podcast: Peter Yang

Judul utama: How OpenAI’s Codex Team Builds with Codex (43 Min) | Alex & Romain

Tanggal tayang: 5 April 2026

Ringkasan poin-poin penting

Alex adalah Kepala Produk Codex, dan Romain menangani pengalaman pengembang. Mereka membuat saya langka sekali bisa benar-benar memahami cara kerja tim Codex, termasuk bagaimana mereka menggunakan Codex untuk membangun produk, serta bagaimana melakukan peluncuran produk tanpa standar produk dan roadmap tradisional. Alex juga membagikan beberapa pandangan unik tentang perkembangan masa depan product manager (PM), serta faktor-faktor yang benar-benar penting dalam rekrutmen.

Ringkasan poin-poin menarik

Pembangunan secara real-time dan “kecepatan berpikir” Codex Spark

• “Saat kamu ingin membangun sesuatu… kamu bisa beralih ke mode cepat bahkan ke Codex Spark, dan kamu akan mendapatkan kecepatan berpikir yang gila itu untuk membangun apa pun. Di kiri adalah GPT-5.4, di kanan adalah Codex Spark, rata-rata sekitar 1200 data (tokens) per detik—kecepatannya benar-benar tidak masuk akal.” ——Romain

Dokumen spesifikasi dan proses pengambilan keputusan

• “Saya merasa dokumentasi spesifikasi yang kami tulis di tim Codex itu sangat sangat sedikit. Padahal, saya pikir sebagian besar pekerjaan adalah membuat sebanyak mungkin keputusan oleh orang-orang yang paling dekat dengan situasi nyata, jadi kami hanya menulis spesifikasi ketika masalahnya akhirnya menjadi jenis masalah yang sulit dimasukkan ke dalam kepala satu orang.” ——Alex

Batas karier yang makin kabur dan evolusi seorang desainer

• “Desainer di tim kami sekarang menulis kode lebih banyak dibandingkan engineer enam bulan lalu. Fokus kami sekarang sudah tidak lagi ‘bisakah menghasilkan kode atau tidak’, hal yang benar-benar penting adalah: kami memutuskan apa yang akan kami kerjakan, dan bagaimana memastikan kualitas produk yang tinggi. Ini juga alasan mengapa untuk fitur yang sangat kompleks, saya cenderung memilih menemukan penanggung jawab yang solid untuk mengelola, bukan menyerahkan sistem seperti itu agar product manager (PM) yang bertanggung jawab atas implementasi dan pemeliharaannya.” ——Alex

Filosofi desain produk: bikin model “tak terlihat”

• “Kami sangat berhati-hati dalam merancang fungsi inti, memastikan fungsi-fungsi itu tidak menjadi penghalang antara pengguna dan model, tetapi membuat model lebih cerdas sehingga bisa menyelesaikan lebih banyak tugas secara otomatis.” ——Alex
• “Lalu berdasarkan itu, kami memikirkan bagaimana mengemas produk dengan cara yang semaksimal mungkin bisa dikonfigurasi untuk pengguna tingkat lanjut, supaya mereka bisa mengeksplorasi dan menggunakannya sendiri. Misalnya, sekarang sudah ada pengguna yang mengimplementasikan sub-agents (sub-entitas/agen kecil).”—Romain

Filosofi perencanaan: menolak “canggungnya perencanaan jangka menengah”

• “Di OpenAI, kami membuat perencanaan untuk tujuan jangka pendek atau tujuan jangka panjang, tapi kami tidak pernah membuat perencanaan jangka menengah karena perencanaan jangka menengah terlalu rumit. Perencanaan jangka pendek biasanya berarti target delapan minggu paling lama dari sekarang, dan delapan minggu adalah rentang waktu terpanjang yang bisa kami tetapkan; kami juga akan menyusun visi jangka panjang. Misalnya, kami bisa membayangkan masa depan satu tahun dari sekarang, mengira model akan menjadi lebih cerdas; namun, perencanaan jangka menengah terasa agak canggung, biasanya berbentuk roadmap produk yang terperinci, dan pada dasarnya kami tidak punya hal seperti itu. Kami lebih banyak menggabungkan visi jangka panjang dan fokus pada tugas-tugas spesifik yang bisa mendorong kami mencapai tujuan.” ——Alex

Perubahan antarmuka karena “delegasi agen cerdas”

• “Penulisan kode akan dilakukan dengan cara ‘delegasi agen cerdas’ (agentic delegation). Kamu akan merasa, membuka beberapa tab di terminal dan membiarkannya berjalan selama beberapa jam adalah bentuk interaksi yang sangat aneh. Jadi kami butuh antarmuka yang benar-benar baru, dan momen itu kebetulan sangat sempurna.” ——Romain

Hilangnya tangga jenjang karier dan “keruntuhan tumpukan talenta”

• “Ini hampir membuat setiap tangga promosi karier tradisional menjadi kabur. Pada dasarnya, setiap orang dari kami adalah ‘builder (pembangun)’, dan semua orang bekerja sama untuk menyelesaikan pembangunan. Jika sebuah startup punya PM, sementara jumlah engineer kurang dari sekitar 20 orang, itu mungkin sinyal bahaya. Minat dan otonomi adalah kualitas yang paling inti dan paling penting bagi manusia di era AGI.” ——Romain / Alex

Standar rekrutmen: portofolio lebih baik daripada CV

• “Saat seseorang menghubungi saya lewat pesan pribadi dan menyatakan tertarik bergabung dengan tim kami, respons pertama saya adalah melihat apakah ada tautan portofolio. Kalau ada tautan, saya selalu membukanya, untuk melihat apakah mereka benar-benar sedang membangun sesuatu; saya lebih suka melihat gagasan mereka serta apa yang benar-benar mereka bangun. Saya benar-benar tidak tahu mereka kuliah di universitas mana.” ——Alex

Demo langsung: membangun sebuah game dalam beberapa detik dengan Codex Spark

Pemandu Peter: Saya sangat bersemangat hari ini memandu Alex dan Romain—mereka berasal dari tim Codex di OpenAI. Mereka akan mendemonstrasikan cara membangun fitur baru Codex, kemampuan apa yang dimiliki Codex, dan bagaimana tim Codex terus-menerus merilis produk. Kalian mau demo cepat tentang hal seperti apa yang sebenarnya bisa dibangun hanya dengan sekali prompt (one-shot)?

Romain:

Tentu. Izinkan saya berbagi layar saya. Sebenarnya ada banyak hal yang bisa saya tampilkan, tapi mungkin cukup sekilas—misalnya, ini adalah aplikasi iOS yang sedang saya bangun. Kalau saya ingin membuat fitur baru untuk aplikasi ini, saya bisa tinggal menyebutkan secara lisan: “Hei, bisakah kamu menambahkan layar baru untuk misi pulang bulan NASA?” Lalu saya mengirim prompt itu dengan GPT-5.4, dan modelnya akan membuat layar baru khusus untuk APP ini.

Tapi kami juga punya model Codex Spark, yang bisa membantu kamu mengonsep dan mengiterasi apa pun dalam hitungan beberapa detik. Saya akan tunjukkan perbedaan respons cepat Spark model. Di kiri adalah GPT-5.4, di kanan adalah Codex Spark. Lalu rata-rata setiap detik bisa menghasilkan sekitar 1200 data—kecepatannya benar-benar gila. Jadi ketika kamu ingin membangun sesuatu, misalnya sebuah game—sebelum percakapan ini dimulai, saya sebenarnya sudah membuka aplikasi Codex dan membuat game 2D kecil yang mirip Animal Crossing menggunakan prompt cepat.

Ketika alur pikir saya sudah jelas, saya benar-benar suka fitur lain yang saya gunakan di Codex: membuka Codex, lalu membuat percakapan melayang di bagian atas layar, sehingga kalau saya benar-benar sedang mengerjakan game ini, saya bisa terus mengiterasi dan menghasilkan lebih banyak ide. Ada ide apa, Peter, untuk perubahan apa yang ingin kamu buat pada game ini?

Peter: Mungkin menambahkan dekorasi lebih banyak, seperti rumah, pohon, dan semacamnya, supaya lebih hidup?

Romain:

Baik, saya akan mengirim tugas ini, dan pada dasarnya dalam beberapa detik Codex Spark bisa melakukan pengeditan. Kita akan melihat perubahan secara real-time, dan selesai—kita sudah melihat pohon baru muncul.

Jadi itulah alasan mengapa saya begitu bersemangat dengan Codex. Kamu benar-benar bisa memiliki model mutakhir seperti GPT-5.4 yang bisa menangani tugas yang sangat kompleks—misalnya menganalisis atau memindahkan jutaan baris kode. Tapi jika inspirasi datang dan alur pikir kamu sudah jelas, kamu bisa beralih ke mode cepat bahkan ke Codex Spark, sehingga kamu bisa mendapatkan kecepatan berpikir yang gila itu untuk membangun apa pun.

Untuk spesifikasi produk, kami hanya menulis sekitar 10 poin inti—cukup itu saja

Pemandu Peter: Saya benar-benar penasaran, bagaimana kalian di tim sebenarnya membangun produk dengan Codex? Alex, apakah kalian masih menulis spesifikasi? Atau kalian meminta GPT menulis spesifikasi? Model apa yang kalian pakai untuk membuat semua itu berjalan?

Alex:

Saya merasa dokumentasi spesifikasi yang kami tulis di tim Codex sangat sangat sedikit. Sebenarnya, saya** pikir sebagian besar pekerjaan adalah membuat sebanyak mungkin keputusan oleh orang-orang yang paling dekat dengan realita,** jadi kami hanya menulis spesifikasi ketika masalahnya akhirnya berubah menjadi jenis masalah yang sangat sulit dimasukkan ke dalam kepala satu orang. Omong-omong, sekarang satu orang bisa memasukkan banyak hal ke dalam kepala karena mereka bisa melakukan banyak hal—mereka telah mendelegasikan sebagian besar pekerjaan pengkodean, jadi satu orang sekarang bisa melakukan banyak. Tapi jika pada akhirnya itu menjadi pekerjaan yang perlu koordinasi lintas beberapa orang, atau mungkin keputusan yang sangat sulit yang harus kita ambil, maka mungkin kita akan menulis spesifikasi. Namun, dokumen yang kami tulis dalam situasi-situasi seperti itu biasanya sangat sangat singkat. Yang kami maksud adalah seperti 10 poin inti, lalu selesai.

Pemandu Peter: Oke. Kalian bisa tunjukkan bagaimana itu bekerja? Misalnya, kamu memberi Codex beberapa poin inti, lalu mungkin ia menulis kebutuhan yang sebenarnya terlebih dulu?

Romain:

Tentu bisa! Tapi saya ingin menunjukkan contoh yang lebih sederhana dulu. Misalkan kita sedang mengembangkan aplikasi iOS yang saat ini sudah menyelesaikan beberapa tugas. Sekarang, kamu punya ide untuk fitur baru, tapi belum yakin arah pastinya. Di tahap ini, kekuatan Codex ada pada kemampuannya membantu kita merencanakan langkah berikutnya. Misalnya, saya hanya perlu menekan tombol Shift+Tab untuk masuk ke “Plan Mode” (Mode Perencanaan), lalu memasukkan “Apa yang akan kita bangun”. Codex kemudian secara otomatis membantu saya membuat rencana awal. Ia akan menganalisis codebase yang ada, memahami kondisi proyek saat ini, lalu mengajukan beberapa ide potensial. Sementara itu, saya juga bisa menambahkan ide saya sendiri untuk mengarahkan model agar menghasilkan rencana yang lebih matang.

Dalam proses ini, kamu akan melihat Codex memberi beberapa saran berdasarkan kode dan berkas yang ada. Misalnya, ia mungkin bertanya: “Apakah kita harus terus menyempurnakan fitur yang sebelumnya disebutkan? Atau kita harus mengoptimalkan reliability dashboard?” Kalau kita memutuskan untuk mengoptimalkan reliability dashboard, ia akan mengarahkan kita untuk memikirkan lebih lanjut: siapa target pengguna dari optimasi ini? Secara keseluruhan, prosesnya terasa seperti bekerja bersama partner yang sedang brainstorming.

Saya sering menggunakan cara ini untuk memancing ide. Misalnya, untuk beberapa perubahan sederhana, saya langsung memasukkan prompt agar Codex menghasilkan kode.

Alex:

Sedangkan untuk perubahan dengan kompleksitas menengah, saya mungkin memintanya membuat rencana yang spesifik, atau membantu saya menalar cara untuk implementasinya. Dan ketika saya punya ide yang masih samar, biasanya saya langsung membuka Codex supaya ia membantu saya memikirkan cara menyelesaikan masalah. Bahkan kalau di kepala saya belum ada kebutuhan fitur yang jelas, Codex tetap bisa membantu saya merapikan alur pikir lewat pertanyaan dan eksplorasi.

Tapi jujur saja, kadang saya tidak langsung menggunakan solusi yang dihasilkan Codex—terutama ketika perubahan tersebut cukup kompleks. Saya menjelajah melalui “Plan Mode” Codex untuk membentuk pemikiran yang jelas, lalu membagikan ide-ide tersebut kepada tim engineer. Pada akhirnya, proses berpikir itu lebih penting daripada rencana yang dihasilkan.

Omong-omong, desainer di tim kami sekarang menulis kode lebih banyak dibandingkan engineer enam bulan lalu. Ini dulu tidak terpikirkan. Hal ini terutama karena kemajuan alat yang membuat desainer bisa terlibat lebih dalam dalam pengembangan. Namun saya juga sering dijadikan bahan bercanda oleh tim karena PR (permintaan penggabungan kode) yang saya ajukan tahun lalu terlalu sedikit. Walaupun banyak perubahan hanya penyesuaian kecil, saya memang merasa saya harus melakukan lebih banyak.

Sekarang, fokus kami** sudah bukan lagi “apakah bisa menghasilkan kode,”** karena agen (Agent) sudah bisa menyelesaikan sebagian besar tugas coding. Yang benar-benar penting adalah: kami memutuskan apa yang akan kami lakukan, dan bagaimana memastikan kualitas produk yang tinggi. Ini juga alasan mengapa untuk fitur yang sangat kompleks, saya lebih cenderung mencari penanggung jawab yang solid untuk mengelola, bukan menyerahkan implementasi dan pemeliharaan sistem tersebut kepada product manager (PM).

Kode yang ditulis desainer lebih banyak daripada engineer 6 bulan lalu

**Pemandu Peter: **Aplikasi Codex terasa sangat intuitif dan mudah digunakan. Dibanding beberapa produk profesional di luar sana, saya rasa kurva belajar Codex jauh lebih rendah. Produk profesional lain mungkin memang sangat kuat, tapi butuh banyak waktu untuk dipelajari. Bahkan saya merasa, kalau saya tidak mengikuti informasi terkait di Twitter, mungkin saya bahkan tidak akan tahu cara memakainya.

Tapi satu hal yang benar-benar mengesankan saya tentang Codex adalah: selain mudah dan gampang digunakan, ia juga menyediakan banyak fitur tingkat lanjut, seperti skills (skill) dan automations (otomatisasi). Apakah tim kalian sering menggunakan fitur-fitur tersebut?**

Romain:

Ya, kami menggunakannya sangat sering. Bahkan, saya pikir skills adalah salah satu fitur paling menarik di aplikasi Codex. Contohnya, sekarang kalau kamu bekerja bersama desainer menggunakan Figma, kamu cukup membuka Figma melalui skill tersebut, lalu kamu bisa langsung mengekstrak semua detail seperti React components, variabel, dan lainnya dari file Figma, dan Codex akan otomatis menghasilkan kode yang sesuai. Contoh lainnya, kalau kamu sedang mengembangkan sebuah aplikasi dan ingin membagikannya atau melakukan deploy ke Vercel, Cloudflare, atau Render, kamu hanya perlu memberi instruksi sederhana lewat skills, dan Codex akan otomatis menyelesaikan tugas-tugas itu.

Saya baru saja mengobrol dengan seorang teman. Ia bilang dia punya banyak ide untuk memperbaiki produk, lalu ia mengatakan kepada Codex: “Tulis semua tugas ini di Linear supaya aku bisa melacaknya.” Lalu ia menggunakan skill Linear. Setelah itu ia memberi tahu Codex: “Aku mau tidur sekarang, kamu lanjutkan semua tugas yang tadi kita bahas, lalu tandai sebagai selesai.” Hasilnya, ketika dia bangun keesokan harinya, dia mendapati semua tugasnya benar-benar sudah selesai.

Alex:

Terkait kesederhanaan aplikasi yang kamu sebut tadi, saya rasa bisa dibagikan bagaimana cara kami memikirkan desainnya. Di bidang ini, developer pada umumnya sangat suka membangun alat otomatisasi untuk diri sendiri agar menyederhanakan pekerjaan sehari-hari. Kami melihat fitur kunci produk harus sangat bisa dikonfigurasi. Untuk Codex, ia seperti kotak perlengkapan open-source: pengguna bisa masuk lebih dalam, lalu menyesuaikannya sesuai kebutuhan mereka.

Setiap kali kami meluncurkan fitur baru, selalu ada pengguna di Twitter yang mengeluh fitur itu bermasalah (bahkan sebelum fitur itu resmi dirilis). Biasanya penyebabnya karena mereka sendiri mengubah kode atau mem-fork fitur tersebut. Namun menurut saya, hal itu justru membuktikan keberhasilan produk kami, karena pengguna-pengguna terdepan ini sedang mengeksplorasi masa depan bersama kami dan mendorong kemajuan produk.

Tapi kami juga menyadari bahwa** hanya membangun produk untuk pengguna level tinggi itu tidak cukup;** kalau tidak, produk akhirnya akan menjadi kompleks dan sulit dipahami. Kami harus menemukan titik seimbang: memenuhi kebutuhan pengguna advanced sekaligus memastikan produk tetap sederhana dan intuitif untuk pengguna biasa. Karena itu** kami sangat hati-hati dalam merancang fungsi inti, memastikan fungsi-fungsi itu tidak menjadi penghalang antara pengguna dan model, melainkan membuat model semakin cerdas sehingga dapat menyelesaikan lebih banyak tugas secara otomatis.**

Romain:

Lalu berdasarkan itu, kami memikirkan bagaimana mengemas produk dengan cara yang semaksimal mungkin bisa dikonfigurasi untuk pengguna tingkat lanjut, supaya mereka bisa mengeksplorasi dan menggunakannya sendiri. Misalnya, sekarang sudah ada pengguna yang mengimplementasikan sub-agents (sub-entitas/agen kecil). Fitur-fitur ini sebenarnya bukan sesuatu yang kami rancang secara aktif; fitur-fitur itu ditemukan dan dieksperimenkan oleh pengguna sendiri. Dari cara pengguna menggunakan fitur-fitur tersebut, kami belajar banyak.

Selanjutnya, kami akan berpikir: bagaimana membuat fitur-fitur ini juga menjadi super sederhana bagi pengguna lainnya? Codex app adalah contoh yang bagus. Kira-kira ketika GPT-5.2 Codex dirilis pada Desember tahun lalu, kemampuan model mulai stabil secara bertahap, tapi juga melintasi semacam titik batas. Pengguna bisa mulai mendelegasikan tugas yang lebih lama dan lebih kompleks kepada model, dan model bisa menyelesaikannya sekali jalan.

Kami mulai melihat beberapa pengguna sudah memakai tmuxing (menjalankan beberapa tugas paralel di terminal), yaitu cara membagi jendela di terminal agar banyak tugas bisa dijalankan secara bersamaan. Kami melihat beberapa contoh yang sangat menarik di media sosial. Misalnya ada foto Peter Steinberger, di layar ada 18 jendela terminal yang membentang di tiga monitor, seperti semacam “cakar terbuka yang penuh kreativitas”. Kami melihat pengguna menggunakan Codex dengan cara yang sangat canggih seperti itu, dan kami merasa sangat senang.

Pada saat yang sama, kami terus mengoptimalkan fitur delegasi tugas di produk dasar seperti CLI agar semuanya berjalan dengan baik. Namun kami juga menyadari, mungkin hanya 1% engineer terbaik yang akan menggunakan metode kerja seperti itu. Jadi kami berpikir: bagaimana membuat fitur-fitur ini terlihat lebih intuitif? Itulah mengapa kami mengembangkan Codex app.

Saat kamu pertama kali membuka Codex app, ia terlihat seperti jendela chat yang sederhana. Kamu bisa langsung memakainya, ia akan berjalan normal. Tapi seiring waktu, kamu akan perlahan menemukan lebih banyak fitur—misalnya sidebar, kemampuan menjalankan beberapa tugas, serta kemudahan berpindah di antara tugas-tugas. Kamu akan merasa jadi super efisien. Lalu kamu mungkin akan melihat tab “skills” dan membukanya untuk menjelajahi lebih banyak fitur.** Kami ingin pengguna merasakan pengalaman yang hampir seperti bermain game saat menggunakan Codex app, sehingga mereka terus menemukan kemungkinan-kemungkinan baru.**

Romain:

Saya sepenuhnya setuju. Dan ini juga visi yang sama yang kami miliki sejak awal: coding akan dilakukan dengan cara “delegasi agen cerdas” (agentic delegation). Bahkan saat kami mulai mengembangkan Codex hampir satu tahun yang lalu, kami sudah memikirkan masa depan itu. Kami percaya engineer akan bisa menangani banyak tugas sekaligus, sementara model akan bertanggung jawab untuk menjalankan detail-detail yang kompleks.

Tapi jujur saja, saat itu kemampuan model belum sampai level seperti itu. Kami harus menunggu rilis GPT-5.2 Codex, serta titik batas setelahnya, untuk melihat model bisa bekerja dengan sangat menyeluruh dan andal selama berjam-jam bahkan berhari-hari. Pada saat itulah kami tiba-tiba menyadari bahwa antarmuka terminal tradisional sudah tidak lagi cocok untuk cara kerja seperti itu. Kamu akan merasa, membuka beberapa tab di terminal dan membiarkannya berjalan selama berjam-jam adalah bentuk interaksi yang sangat aneh. Jadi kami butuh antarmuka yang benar-benar baru, dan momen itu kebetulan sangat sempurna.

Alex:

Kalau menilik perjalanan Codex, kami mengalami dua perubahan besar dalam “vibe shift” (perubahan tren).** Yang pertama terjadi pada bulan Agustus tahun lalu,** saat kami merilis produk Codex Cloud. Itu ide yang sangat bagus; pengguna saat itu sangat antusias, tapi mungkin sedikit terlalu cepat pada saat itu. Jadi pada bulan Agustus kami meluncurkan GPT-5, model interaktif coding yang benar-benar hebat, lalu kami memutuskan untuk fokus menyelesaikan masalah yang saat itu bisa ditangani model. Kami kemudian merilis Codex CLI dan plugin IDE; dalam beberapa bulan, jumlah pengguna tumbuh dengan cepat sebanyak 20 sampai 30 kali—itu benar-benar luar biasa.

Perubahan kedua terjadi antara bulan Desember tahun lalu hingga Januari tahun ini. Saat itu, kami akhirnya mewujudkan visi awal: mendelegasikan tugas kepada model. Kemampuan model mencapai level baru—mampu menyelesaikan tugas yang lebih kompleks secara mandiri—yang menandai bahwa kami memasuki tahap yang benar-benar baru.

Perencanaan kami dibagi menjadi jangka pendek dan jangka panjang, tidak melakukan perencanaan jangka menengah

Pemandu Peter: Saya penasaran, bagaimana Codex app dikembangkan? Setahun yang lalu, apakah kalian menetapkan semacam roadmap tahunan, misalnya “kami berencana meluncurkan Codex app pada suatu waktu”? Atau kalian lebih banyak mengamati kebutuhan pasar, lalu melakukan prototipe cepat atas beberapa ide?

Alex:

Sebenarnya tidak seperti itu. Saya pernah mendengar dari peneliti kami Andre sebuah saran yang sangat bagus: di OpenAI, kami merencanakan tujuan jangka pendek atau tujuan jangka panjang, tapi tidak melakukan perencanaan jangka menengah karena perencanaan jangka menengah terlalu kompleks.

Perencanaan jangka pendek biasanya berarti target paling lama delapan minggu dari sekarang, dan delapan minggu adalah rentang waktu terpanjang yang bisa kami tetapkan. Dalam kerangka waktu ini, kami akan menetapkan tujuan yang spesifik, lalu mengumpulkan tim agar fokus penuh untuk menyelesaikannya. Ini adalah kekuatan OpenAI—kami sangat pandai mengorganisasi tim berdasarkan tujuan yang jelas.

Di sisi lain, kami juga akan menyusun visi jangka panjang. Misalnya, kami bisa membayangkan masa depan satu tahun dari sekarang, mengira model akan menjadi lebih cerdas. Misalnya, kami mungkin membayangkan model di masa depan bisa bekerja secara mandiri, tidak lagi perlu menggunakan sumber daya komputer kami, dan tidak lagi terbatas pada hanya menyelesaikan satu hal dalam sekali waktu. Kami ingin punya banyak model yang tak terhingga—yang dapat menyelesaikan tugas secara mandiri, memverifikasi kode sendiri, bahkan mampu melakukan self-deploy dan self-monitoring, dan kami sama sekali tidak perlu memberikan prompt manual kepada mereka.

Namun, perencanaan jangka menengah terlihat agak canggung. Ia biasanya berbentuk roadmap produk yang terperinci, tetapi pada dasarnya kami tidak punya hal seperti itu. Kami lebih banyak menggabungkan visi jangka panjang dan fokus pada tugas-tugas spesifik yang dapat mendorong kami untuk mencapai tujuan.

Sebagai contoh, terkait Codex app, salah satu tujuan strategis kami saat itu adalah membebaskan pengguna dari workspace tertentu. Alat pengembangan tradisional (misalnya VS Code) biasanya terikat pada workspace tertentu, seperti pada titik checkout tertentu dari sebuah codebase atau folder tertentu. Bahkan jika menggunakan git worktree, kamu tetap hanya bisa membuka satu direktori kerja sekaligus, dan CLI juga memiliki batasan yang mirip.

Tapi visi kami adalah: pengguna dapat berkolaborasi dengan agen cerdas (agent) di cloud, dan agen-agen tersebut bisa bekerja secara mandiri. Kami ingin pengguna bisa berinteraksi dengan banyak agen sekaligus, bahkan menyerahkan kepada satu agen untuk mengoordinasikan pekerjaan beberapa agen untuk pengguna—pengalaman seperti itu harus terasa natural dan intuitif.

Pada saat yang sama, kami juga menyadari bahwa jika semuanya benar-benar bergantung pada cloud sejak awal, developer mungkin akan merasa kurang nyaman karena mereka perlu mengatur lingkungan; dan ketika model menjalankan tugas, jika diperlukan campur tangan atau penyesuaian manual, itu juga akan jadi merepotkan. Jadi kami memutuskan untuk mengembangkan pengalaman yang terlokalisasi—yang bisa berkolaborasi mulus dengan folder lokal, sekaligus tetap terhubung dengan agen cerdas di cloud.

Ketika kami mulai mengembangkan aplikasi ini, kami memiliki banyak “pemikiran visi” seperti itu—ide-ide yang masih cukup abstrak. Sementara itu, para engineer kami juga sedang melakukan berbagai prototipe. Mereka akan berkata: “Saya ingin kita punya aplikasi.” Dan dari sana mereka mulai mencoba mengembangkan berbagai versi. Bahkan, kami pernah mengadakan “hack week”, di mana beberapa engineer secara independen mengembangkan versi aplikasi yang berbeda. Mungkin kamu ikut juga, tapi saya tidak ingat.

Ketika proyek ini benar-benar dimulai, satu-satunya hal yang perlu kami tulis dengan jelas adalah**: mengapa kami merasa membangun sebuah aplikasi adalah ide yang bagus. Kami tidak memiliki spesifikasi produk yang spesifik untuk aplikasi ini; kami secara bertahap menetapkan arah produk lewat pekerjaan pengembangan yang nyata. **

Namun saat itu proyek ini masih memiliki beberapa perdebatan—apakah kita benar-benar perlu mengembangkan sebuah aplikasi? Plugin IDE sudah sangat populer—apakah kita harus fokus meningkatkan kualitas plugin tersebut? CLI juga punya potensi. Jadi, kalau kita ingin mengembangkan sebuah aplikasi, apa artinya? Ke arah mana kita harus berusaha? Itu beberapa pertanyaan yang kami hadapi saat proyek ini mulai.

Romain:

Ya, dan untungnya, saat itu kami sudah memiliki solusi plugin IDE yang sangat matang, serta melakukan optimasi mendalam. Pengguna bisa menggunakan plugin itu di VS Code, Cursor, Windsurf, dan IDE lainnya. Kami mengumpulkan banyak pengalaman dari codebase plugin IDE, dan ini memberikan titik awal yang sangat kuat untuk mengembangkan Codex app.

Alex:

Benar. Bahkan, Codex app dan plugin IDE berbagi banyak kode di level dasar. Keduanya terhubung ke core Codex harness yang sama—sebuah framework open-source yang ditulis dalam Rust, dan CLI juga menggunakannya. Kami memang dengan sengaja memilih desain berlapis agar kode bisa dibagi dan fungsionalitas bisa diperluas antar berbagai alat.

Pemandu Peter: Soal proses memutuskan untuk mengembangkan Codex app… kalau melihat ke belakang, itu tampaknya keputusan yang sangat jelas, karena menggunakan Codex app jauh lebih intuitif dibanding membuka banyak jendela terminal. Tapi alasan utama saat itu adalah: Codex app lebih ramah untuk pemula, dan juga antarmuka terbaik untuk mengelola kolaborasi dari banyak smart agent.

Alex:

Saya pikir cara berpikir tim kami sangat dipengaruhi oleh visi AGI. Kami terus memikirkan: seperti apa wujud pekerjaan di masa depan?

Kalau saya menyebutnya dari sudut pandang lain, kami jelas butuh sebuah antarmuka—yang memungkinkan pengguna mendelegasikan tugas kepada banyak smart agent secara natural. Kami tahu model masa depan akan memiliki kemampuan itu—bahkan, kami sudah melihat pengguna mencoba mendelegasikan tugas lintas smart agent. Kami membutuhkan antarmuka agar cara kolaborasi seperti itu terasa masuk akal, sekaligus bisa diperluas secara mulus ke cloud.

Kami ingin antarmuka itu selaras dengan desain yang ergonomis, sehingga pengguna merasa berkolaborasi dengan banyak smart agent itu pengalaman yang intuitif dan natural—bukan sesuatu yang memerlukan operasi rumit atau trik tertentu.

Romain:

Ya, dan audiens aplikasi ini bukan hanya pemula. Bahkan engineer paling senior dan paling berpengalaman—termasuk engineer top di dalam OpenAI seperti Peter, OpenClaw, dan Greg Brockman—sekarang sudah mulai menjadikan Codex app sebagai alat pengembangan utama mereka. Ini menunjukkan bahwa** visi kami tentang delegasi agen cerdas (agentic delegation) perlahan mulai menjadi kenyataan.**

Alex:

Ya. Kami menyebut Peter karena dia baru saja bergabung dengan OpenAI, dan kami sangat bersemangat. Tahun lalu Oktober, saya sempat membicarakan ide mengembangkan antarmuka baru saat berjalan-jalan dengannya di Fort Mason San Francisco. Saya bilang kami berharap ada antarmuka baru sehingga delegasi tugas (delegation) menjadi lebih natural; saat itu dia bilang bahwa dia tidak akan pernah memakai sesuatu seperti itu.

Tapi akhir pekan lalu, dia mengunggah sebuah tweet: “Ternyata aplikasi ini cukup enak dipakai, dan sekarang saya menyukainya.”

Alex sebagai product manager (PM) Codex: apa isi kerja hariannya

Pemandu Peter: Alex, kamu sebelumnya sempat menjadi satu-satunya product manager (PM) di tim Codex, benar? Sekarang tim Codex ada berapa orang? Kira-kira antara 50 sampai 100 orang?

Alex:

Kurang lebih, sekitar kisaran itu. Pada bulan Mei, tim kami mungkin baru sekitar 8 orang, tapi saya tidak ingat angkanya dengan tepat. Tapi sejak itu tim kami berkembang sangat cepat; sekarang kira-kira berada di rentang 50 sampai 100 orang.

Pemandu Peter: Lalu biasanya bagaimana kamu membagi waktu? Seperti apa rutinitas harianmu? Atau kamu bahkan tidak punya rutinitas kerja harian yang “tipikal”?

Alex:

Belakangan ini saya juga sedang memikirkan pertanyaan itu, karena saya merasa sulit menjawab. Saya sadar bahwa** pola kerja saya sebenarnya bertahap,** dan ini adalah cara pribadi saya—belum tentu cocok untuk semua orang.

Misalnya, saat kami meluncurkan Codex app,** saya benar-benar berada dalam mode eksekusi.** Saat itu, seluruh energi saya fokus pada kualitas produk—memastikan kami tidak melewatkan detail apa pun, memastikan setiap hal kecil tertangani dengan baik. Dalam mode seperti itu, saya menghabiskan banyak waktu menggunakan alat Codex.

Kami menggunakan Codex untuk mendapatkan umpan balik, seperti memahami diskusi di Slack serta umpan balik dari pengguna. Saya akan meminta Codex untuk merangkum informasi ini, lalu mencatatnya ke Linear. Selain itu, saya juga memakai Codex untuk menganalisis kualitas kode dan langsung memanfaatkannya untuk melakukan perubahan kode kecil. Karena kadang menangani masalah kecil langsung dengan Codex lebih cepat daripada mencari orang lain untuk mengoordinasikan tugas dan memprioritaskannya—terutama ketika target kami adalah merilis aplikasi dalam waktu dua minggu.

Dalam proses seperti itu, tentu juga ada banyak pekerjaan yang bersifat manusiawi, seperti menyemangati tim, memotivasi mereka, dan sekaligus bersikap kritis terhadap produk yang sedang kami kembangkan. Saya rasa saya bisa menilai apakah saya sedang dalam mode eksekusi dari seberapa sering saya menggunakan Twitter. Saya juga tidak tahu kenapa, tapi ketika saya perlu berinteraksi dengan orang, saya cenderung lebih sering menggunakan Twitter.

Lalu ada satu mode lain juga, misalnya sekarang: di kepala saya sangat jelas,** kami sudah mencapai tahap baru.** Model kami sekarang sangat kuat—seperti GPT-5.4 yang performanya sangat baik. Pengalaman aplikasi kami juga melebihi ekspektasi, sudah mencakup semua platform termasuk Windows. Jadi sekarang saya merasa, sudah waktunya benar-benar beralih kembali ke cloud dan menginvestasikan lebih banyak fokus di sana.

Ketika kami masuk ke tahap seperti itu, saya akan menghabiskan lebih banyak waktu untuk memikirkan apa yang harus dilakukan selanjutnya serta memahami kondisi saat ini—ini adalah mode koordinasi. Dalam mode ini, waktu saya untuk Codex akan lebih sedikit, lebih banyak untuk komunikasi daripada menulis kode. Jadi setidaknya saya punya dua mode kerja seperti itu—tentu mungkin masih ada lebih banyak lagi.

Pemandu Peter: Kalian perlu melakukan berapa banyak penyelarasan lintas fungsi?

Alex:

Di dalam tim, kami hampir tidak perlu melakukan penyelarasan lintas fungsi yang terlalu banyak. Kami memang sengaja menganggap diri kami seperti tim “kapal bajak laut”. Bahkan di dalam tim Codex sendiri, saat ini hanya ada saya dan dua product manager baru yang baru bergabung. Ada beberapa orang yang memimpin, meski sampai baru-baru ini pada dasarnya semua orang langsung melapor kepada saya; tetapi kami mendorong proyek dengan cara yang agak “kabur”—secara bersama-sama—jadi tidak banyak kerja penyelarasan di dalam tim.

Tapi sekarang makin jelas bahwa bagian penting dari membangun Codex adalah pengembangan coding agent. Dan semua orang makin paham bahwa coding agent bukan hanya berguna untuk menulis kode; ia juga sangat berguna untuk tugas-tugas lainnya.

Misalnya, kami menemukan bahwa pengguna memakai Codex app bukan hanya untuk menulis kode. Mereka memakainya untuk menyelesaikan berbagai tugas di seluruh siklus pengembangan software, dan sekarang sebagian besar karyawan OpenAI menggunakan Codex app—bahkan untuk non-teknis pun, saya sering melihat mereka memakai aplikasi ini.

Kesadaran ini membuat kami berpikir: kami perlu memikirkan bagaimana memastikan Codex tidak hanya berguna untuk developer. Untuk itu, perlu lebih banyak penyelarasan lintas fungsi, karena sebagai OpenAI kami juga punya ChatGPT, dan banyak pengguna memakainya. Jadi kami perlu sangat berhati-hati memikirkan bagaimana mengintegrasikan produk-produk ini dengan lebih baik.

Romain:

Dari sudut pandang saya, tim pengalaman pengembang kami agak seperti perluasan dari tim Codex. Sebagian besar waktu dan energi kami digunakan untuk Codex, terutama karena beberapa alasan.

Pertama, ini adalah produk yang sangat menggairahkan, dan developer sangat menyukai Codex. Kami ingin membuatnya menjadi lebih baik. Seperti yang dikatakan Alex, mode kerja kami juga bertahap. Kami akan bergabung dengan tim Codex untuk mempersiapkan rilis produk, misalnya menyiapkan materi yang dibutuhkan, serta mengajari developer cara memaksimalkan penggunaan Codex. Setelah rilis, kami juga akan membimbing developer untuk mengeksplorasi penerapan Codex di berbagai skenario.

Hal lain yang juga sangat menarik bagi kami adalah, kalau kamu melihat seluruh platform OpenAI, hari ini sudah ada jutaan developer yang menggunakan API kami untuk membangun aplikasi multimodal—mulai dari gambar hingga suara.

Cara terbaik untuk mengembangkan sekarang adalah menjadikan Codex sebagai titik masuk. Kalau kamu kembali setahun lalu, atau bahkan saat kami baru meluncurkan GPT-5 pada musim panas tahun lalu, kami masih perlu menulis banyak panduan untuk mengajari orang cara membuat prompt untuk GPT-5. GPT-5 adalah model yang kemampuan penalarannya sangat kuat dan sangat berbeda dari GPT-4. Tapi sekarang kami berusaha membantu developer menyelesaikan tugas lewat Codex dan skills bahkan dalam use case seperti itu.

Misalnya, kalau kamu perlu memperbarui sistem integrasi, kami akan menyarankan kamu menggunakan Codex dan fitur skill-nya. Hasilnya, Codex bisa membantu kamu menyelesaikan hampir seluruh tugas tersebut. Jadi tim kami juga sangat menekankan kolaborasi lintas fungsi dan memandang Codex sebagai fondasi dari seluruh platform pengembang OpenAI.

Alex:

Saya rasa ada satu karakteristik yang menarik dari cara kerja tim Codex—bagiku yang paling hebat adalah** interaksi dengan komunitas.** Baik secara online maupun dalam acara tatap muka di dunia nyata, kami sangat menekankan hubungan dengan komunitas.

Dalam rilis produk, pekerjaan kami sangat** berorientasi pada peluncuran—jelas kapan merilis konten apa;** sekaligus sangat** berorientasi pada umpan balik—setiap kali komunitas memberikan feedback, kami cepat bertindak untuk memperbaiki masalah dan berkomunikasi dengan mereka.** Jadi tim kami selalu sangat aktif online, dan menurut saya itu sangat penting.

Misalnya, saat kami meluncurkan Codex app, kami bekerja sangat dekat dengan Dom dan timnya. Mereka membantu mengorganisasi pengujian alpha skala besar, mengundang banyak pengguna agar berpartisipasi bersama dalam pengembangan produk. Berkat feedback mereka, kami tidak hanya meningkatkan aplikasi, tetapi juga menyempurnakan sumber daya terkait seperti skills dan dokumentasi.

Saya rasa inilah keunggulan unik tim Codex: karena kami open-source, kami menjaga transparansi tinggi untuk semua yang kami lakukan, dan komunitas juga memberi dukungan besar serta umpan balik yang luar biasa atas pendekatan itu.

Pemandu Peter: Mari kita bahas Peter (pendiri OpenClaw). Saya adalah pengguna awal OpenClaw. Bagaimana kalian mengintegrasikan Peter ke dalam tim? Visi untuk personal agent ini, apakah terkait dengan pekerjaan yang dia lakukan sekarang? Kalian merencanakan seperti apa?

Alex:

Ada dua sisi yang bisa diceritakan. Pertama, Peter adalah pengguna Codex yang sangat berat. Bahkan, OpenClaw sebagian besar dibangun menggunakan Codex. Dari pengalaman pakainya sendiri, dia memberi banyak feedback ke tim—feedback itu sangat membantu kami memperbaiki Codex. Walau itu hanya “pekerjaan sampingan”-nya, dia benar-benar sangat terlibat, dan kami sangat senang.

Kedua, saya tidak bisa mengungkapkan terlalu banyak detail sekarang, tapi bisa dibilang bahwa** dia sedang membantu kami membangun personal agent generasi berikutnya, dan mengintegrasikannya langsung ke dalam ChatGPT.**

Romain:

Menurut saya, yang paling menarik dari pekerjaan Peter adalah: ketika semua orang memakai OpenClaw, mungkin mereka sudah samar-samar melihat kemungkinan masa depan. Tapi yang benar-benar membuat saya terkesan adalah Peter sudah melihat visi itu sejak sangat awal.

Kalau kita menengok kembali keseluruhan tahun 2025, tahun lalu dia mengembangkan lebih dari 40 proyek open-source, dan semua proyek itu berpusat pada satu visi inti: mengakses alat pribadi seperti kalender, tweet, dan Gmail lewat command line interface. Melalui proyek-proyek itu, sebenarnya dia sudah mengubah visi skills dan command line tools menjadi kenyataan. Coding agent yang kita pakai saat ini pun dibangun berdasarkan visi tersebut.

Ke depan, smart agent ini tidak hanya akan menjadi alat pemrograman, tapi akan menjadi segala jenis personal agent. Jadi dalam proses ini, Peter memberi kami umpan balik yang sangat berharga, karena dia sudah mengembangkan banyak alat yang sekarang menjadi bagian inti dari ekosistem open-source.

Pemandu Peter:

Saya pikir orang seperti Peter yang bisa membangun komunitas open-source yang begitu luar biasa benar-benar patut dikagumi. Alatnya sangat berguna sampai saya tidak ingin membuka aplikasi lain mana pun. Saya cuma ingin mengobrol dengan robot kecil saya.

Alex:

Kamu menghubungkannya ke sistem apa? Kamu menghubungkannya ke semuanya?

Pemandu Peter:

Benar. Saya menghubungkannya ke banyak layanan. Misalnya, ia bisa mengakses informasi perbankan saya, akun YouTube saya, asisten suara, kalender, serta layanan Google. Saat saya rebahan di tempat tidur, istri saya bertanya, “Kamu sedang bicara dengan siapa?” Saya jawab, “Saya sedang mengobrol dengan robot OpenClaw saya.”

Tapi sekarang ada banyak “spekulan” yang membebankan biaya hingga 5000 dolar untuk membantu orang menyiapkan OpenClaw. Jadi kalau kalian bisa membuatnya lebih mainstream, lebih mudah dipakai, itu akan menjadi terobosan besar—dan kalian memang sedang bergerak ke arah yang tepat.

Tangga karier tradisional sudah tidak lagi cocok

Pemandu Peter: Saya ingat kalian pernah mengatakan sesuatu seperti, “Sekarang kebanyakan tim tidak lagi membutuhkan PM sebanyak itu.”

Romain:

Saya rasa hal yang paling mengejutkan tentang alat-alat ini bukan sekadar soal PM atau apakah kita perlu PM.** Ini hampir membuat setiap tangga promosi karier tradisional menjadi kabur.** Dulu, kita punya pembagian peran yang jelas: desainer bertanggung jawab atas desain, engineer bertanggung jawab atas pengembangan, PM bertanggung jawab atas manajemen—mungkin dengan proporsi tertentu seperti semacam “golden ratio”.

Tapi sekarang, kalau kamu engineer, produktivitasmu meningkat secara signifikan. Kalau kamu desainer, kamu bisa mendapatkan semacam “kemampuan super” dari alat-alat ini, menjadi lebih teknis. Kalau kamu PM, dulu kamu hanya bisa menulis dokumen strategi, tapi sekarang kamu bisa langsung membuat prototipe. Ini tidak berarti kamu harus bertanggung jawab pada sebuah fitur untuk miliaran pengguna, tapi kamu benar-benar bisa menggunakan alat-alat ini untuk membangun sesuatu, serta menunjukkan visimu kepada tim.

Jadi yang paling membuat saya terpukau adalah,** sekarang batas di antara semua jenjang karier mulai kabur. Kita semua pada dasarnya adalah “builder (pembangun)”, dan semua orang bekerja sama untuk menyelesaikan pembangunan.**

Alex:

Saya ingat pernah mengatakan di suatu tempat online bahwa jika sebuah startup punya PM, dan jumlah engineer kurang dari sekitar 20 orang, itu mungkin sinyal bahaya—mungkin saya memang pernah mengatakan hal semacam itu.

Saya rasa seperti yang kamu katakan,** semua peran ini sedang menyatu satu sama lain.** Desainer bisa melakukan lebih banyak pekerjaan engineering, engineer bisa masuk ke area desain, dan PM pun bisa ikut membangun. Tapi engineer biasanya perlu fokus menulis kode, sehingga dulu mereka tidak menangani penyortiran tugas atau bagian manajemen proyek dari PM.

Namun sekarang, hal-hal itu jadi jauh lebih mudah. Kamu bisa langsung meminta agent—misalnya Codex—untuk menganalisis feedback dan prioritas, sehingga engineer bisa lebih banyak waktu fokus pada pekerjaannya sendiri. Saya rasa sekarang setiap orang bisa mengerjakan pekerjaan orang lain.

Scott Belsky pernah mengemukakan sebuah ide,** yang disebut “collapse the talent stack”.** Saya suka pandangan itu, dan menurut saya ini memang sedang terjadi.** Semakin sedikit orang yang dibutuhkan di ruang itu, semuanya berjalan semakin lancar, dan setiap keputusan jadi lebih jelas.**

Jadi pertanyaannya: PM masih bisa berperan apa? Saya pikir banyak PM sebenarnya perlu mempertimbangkan untuk pindah peran. Misalnya, kalau kamu seorang PM yang terus ingin menjadi engineer, tapi kamu lebih jago mengelola orang dan kemampuan engineering-mu tidak kuat, maka sekarang mungkin kamu bisa menjadi engineering manager. Dengan adanya smart agent, peran itu mungkin jadi lebih jelas dan tegas. Begitu juga, beberapa PM mungkin lebih condong menjadi desainer, lebih dekat dengan pekerjaan membangun yang nyata.

Menurut saya, pada akhirnya itu tergantung minat pribadi. Untuk saya,** minat dan otonomi adalah kualitas yang paling inti dan paling penting bagi manusia di era AGI.** Jadi kalau minatmu lebih ke menulis kode, dan kamu sebelumnya mengambil peran itu hanya karena ada kebutuhan orang yang mengerjakan pekerjaan PM, maka sekarang kamu sepenuhnya bisa beralih menjadi engineer dan tetap menyelesaikan hal yang sama dari sudut pandang engineering. Bidang desain pun sama.

Tapi jika kamu benar-benar tertarik berinteraksi dengan pengguna, bahkan jika itu membuatmu menjauh dari pekerjaan membangun yang nyata—misalnya mencoba memahami kebutuhan pengguna, menggali tren pasar—maka dalam sebuah tim yang cukup besar, PM masih punya ruang untuk berperan.

Romain:

Saya mau menambahkan satu hal lagi: saya masih percaya bahwa setiap area masalah perlu seseorang dari kalangan manusia yang bertanggung jawab atas area tersebut, tetapi saya tidak berpikir orang itu harus selalu PM. Sangat tergantung pada sifat produk.

Kita sangat beruntung karena kita bekerja untuk Codex, sebuah alat yang ditujukan untuk developer. Kita sendiri adalah pengguna terbaik dari alat itu. Dan karena ia open-source, kita bisa langsung berinteraksi dengan komunitas untuk melakukan pengembangan bersama.

Tapi kalau kamu kembali ke sepuluh tahun lalu, misalnya ketika saya bekerja di Stripe—saat itu perusahaan berjumlah 250 orang, tapi tidak ada PM, bahkan tidak ada alat AI apa pun. Kenapa? Karena Stripe adalah produk API, dan semua orang adalah engineer yang punya pemahaman yang sangat intuitif tentang apa itu API yang bagus. Saat itu kami membangun API yang sesuai dengan impian kami: solusi elegan yang bisa diwujudkan hanya dengan beberapa baris kode.

Tapi kalau kamu berada di bidang yang berbeda—misalnya engineer tidak punya intuisi sebanyak itu tentang kebutuhan pengguna—maka kamu mungkin butuh lebih banyak PM untuk berkomunikasi dengan klien dan memahami kebutuhan mereka.** Terutama ketika industri atau area yang kamu layani tidak sepenuhnya selaras dengan intuisi engineer, peran PM akan semakin penting.** Namun kami di tim Codex sangat beruntung, karena yang sedang kami bangun adalah alat yang juga ingin kami gunakan sendiri.

Alex:

Dalam kondisi seperti ini,** peran PM mungkin hanya sebuah label—yang mengacu pada orang yang paling tertarik pada pengguna dan paling peduli pada kebutuhan pengguna.** Orang itu bisa saja seorang engineer yang sangat dekat dengan pengguna. Jadi menurut saya, label-label karier ini perlahan kehilangan arti tradisionalnya, meski terasa agak membingungkan, itu bukan hal buruk.

Pemandu Peter:

Saya juga menemukan hal yang mirip di tim saya. Menurut saya engineer terbaik tidak akan bertanya, “Jadi sekarang kita harus membangun apa?” Mereka akan proaktif berinteraksi dengan pengguna, mencari tahu sendiri apa yang perlu dikembangkan, lalu mendiskusikannya dengan saya. Cara itu membuat tujuan semua orang jadi sangat selaras.

Romain:

Itu sebenarnya cara kerja tim Codex. Banyak fitur yang kalian lihat dipakai di Codex app sebenarnya adalah ide-ide brilian yang diajukan engineer dari bawah ke atas (bottom-up), karena mereka sendiri juga membutuhkannya.

Alex:

Tapi yang ingin saya katakan adalah: ada satu tipe engineer yang benar-benar saya suka untuk bekerja sama.** Mereka suka berinteraksi dengan pengguna dan memikirkan fitur apa yang harus dibangun.** Biasanya orang-orang seperti ini juga sangat hebat dalam membangun sistem: cepat, berkapabilitas tinggi, dan punya alur pikir yang jelas. Tapi ada juga engineer yang sama sekali tidak tertarik berinteraksi dengan pengguna; mereka hanya ingin fokus membangun sistem. Saya rasa orang-orang seperti itu juga punya ruang pengembangan yang besar.

Sekali lagi, inilah pandangan saya tentang era AI—** kita semua bisa menjadi lebih “jadi diri sendiri”.** AI dan tim akan membantu kamu mengerjakan hal-hal yang tidak ingin kamu lakukan, sehingga kamu bisa fokus pada minat dan keunggulanmu.

Pemandu Peter:

Saya benar-benar merasa label “builder (pembangun)” itu sangat penting. Saya pikir banyak PM ingin menjadi pemimpin, tapi tangga karier tradisional adalah: setelah kamu jadi posisi seperti VP, kamu justru tidak punya waktu untuk membangun sesuatu. Setiap hari kamu ada di rapat review produk, hanya memberi beberapa feedback, tapi tidak punya waktu untuk benar-benar mengembangkan. Saya rasa banyak PM tidak ingin seperti itu, dan saya ingin tetap dekat dengan pengguna serta benar-benar merilis produk.

Alex:

Saya sepenuhnya setuju.** Saya sebenarnya tidak menganggap PM sebagai peran kepemimpinan.** Lebih tepatnya, saya cenderung melihatnya sebagai peran untuk “mengisi kekosongan.” Kadang peran itu perlu memikul tanggung jawab kepemimpinan tertentu, tapi bahkan jika demikian,** kepemimpinan lebih banyak berfungsi membantu tim mencapai kesepakatan, bukan sekadar mengandalkan satu orang untuk mengusulkan solusi jenius.**

Ada satu hal yang bisa saya pastikan: di OpenAI, PM terbaik akan benar-benar mendalami detail-detail spesifik. Dan saya pikir bergabung ke OpenAI melalui posisi kepemimpinan level senior adalah hal yang sangat menantang, karena budaya di sini tetap menekankan perhatian pada detail. Jadi** cara terbaik adalah langsung terjun ke detail sejak awal.**

Tim Codex dalam rekrutmen, apa yang mereka utamakan? (Jawabannya bukan CV-mu)

Pemandu Peter: Saat kalian merekrut untuk tim Codex, selain memastikan kandidat adalah pengguna berat Codex, kualitas apa lagi yang kalian cari?

Alex:

Saya sudah menyebut sebelumnya bahwa saya sangat menghargai** otonomi (agency) kandidat.** Kami ingin menemukan orang yang benar-benar proaktif melakukan hal-hal, dan itu salah satu kualitas terpenting.

Di OpenAI, khususnya di tim Codex, budaya kami bukan seperti “begitu kamu bergabung, kami akan memberimu daftar 12 tugas yang tingkat kesulitannya meningkat.” Gaya kami lebih seperti: “Selamat datang! Sekarang mulai eksplorasimu.”

Karena itu, kami cenderung mencari orang yang** self-driven—mereka punya dorongan untuk bertindak, punya ide sendiri, tahu apa yang ingin mereka lakukan, dan tidak takut untuk menantang gagasan yang ada.** Karena jujur saja, beberapa gagasan yang sudah ada mungkin saja salah dari awal—mungkin hanya keputusan kebetulan saat kami memutuskannya dulu.

Rekan tim ideal bagi saya adalah orang yang** bersedia mengambil tanggung jawab tambahan, bahkan bersedia bertanggung jawab atas area yang belum jelas.** Kualitas-kualitas itu yang kami utamakan. Untuk skill spesifik, kami biasanya memprioritaskan kandidat yang kemampuan teknisnya kuat dan terkait engineering.

Romain:

Saya sepenuhnya setuju. Di tim pengalaman pengembang (DevX) saya, saya biasanya mencari orang yang memiliki** otonomi tinggi.** Mereka harus sangat kuat secara teknis, terutama dalam menggunakan alat seperti Codex. Tapi selain itu, saya juga sangat menghargai mereka yang antusias bekerja bersama developer dan builders, serta mau berbagi pengetahuan.

Misalnya, minggu ini kami baru mengumumkan bahwa Thomas akan bergabung dengan tim saya. Ia adalah orang yang mengembangkan open-source Codex monitor. Ia bukan hanya sangat kreatif, tetapi juga pengguna berat Codex, dan sangat antusias berbagi pengalamannya tentang bagaimana ia memakai Codex untuk membangun tools.

Kami butuh orang seperti itu karena kami sedang berusaha membawa jutaan developer menuju masa depan cerah yang diwakili oleh Codex. Saya yakin agentic coding sedang mengubah cara pandang tradisional kami tentang pengembangan software, pembuatan aplikasi, dan pembangunan produk. Tujuan kami adalah menunjukkan kemungkinan itu ke seluruh dunia dan membantu developer belajar bagaimana memanfaatkan tools ini untuk mewujudkan kreativitas mereka sendiri. Itulah kualitas yang saya cari.

Alex:

Saya mau menambahkan: menurut saya kandidat ideal untuk tim DevX bisa dijelaskan secara sederhana sebagai** “engineer yang sangat hebat sekaligus pandai memanfaatkan media sosial untuk berinteraksi dengan komunitas.”**

Romain:

Kamu benar sebagian. Tapi saya ingin menambahkan satu hal: kami berharap kandidat punya rasa tanggung jawab yang kuat terhadap komunitas, dan juga mempertimbangkan kebiasaan penggunaan media sosial yang berbeda-beda di berbagai wilayah secara global. Misalnya, di beberapa tempat, developer mungkin lebih cenderung menggunakan LinkedIn atau platform lain, bukan Twitter. Jadi kami perlu memperluas definisi ini: kandidat perlu punya performa yang baik dalam media sosial di seluruh dunia.** Kami terutama menghargai mereka yang suka berinteraksi dengan komunitas, antusias mengajar, dan berbagi pengetahuan.**

Pemandu Peter:

Sebenarnya, otonomi seseorang bahkan bisa terlihat sebelum wawancara. Misalnya, apakah mereka sudah pernah mempublikasikan karya secara online? Apakah mereka punya side projects?

Alex:

Ketika seseorang mengirimi saya pesan pribadi dan menyatakan tertarik untuk bergabung dengan tim kami, respons pertama saya adalah: “Ada tautannya?” Kalau ada tautan, hampir semuanya saya buka untuk melihat. Saya akan penasaran memeriksa karya mereka, untuk memahami apakah mereka benar-benar sedang membangun sesuatu.

Tentu ada juga orang yang menyertakan surat lamaran yang menjelaskan kenapa mereka tertarik pada posisi itu, bahkan menyertakan resume, tapi saya lebih ingin melihat pemikiran mereka dan apa yang benar-benar mereka bangun. Beberapa hari lalu saya juga menyadari ada hal yang menarik—saya benar-benar tidak tahu mereka kuliah di universitas mana.

Pemandu Peter: Siapa peduli? Siapa yang peduli? Saya benar-benar senang kita hidup di era ketika pendidikan tinggi yang penuh omong kosong ini tidak lagi terlalu penting. Asal saya bisa melihat apa yang benar-benar kamu bangun, itu sudah cukup.