Jika ditanya produk AI mana yang pertumbuhannya paling menakjubkan pada tahun 2026, "Codex" pasti menempati urutan pertama.
Sejak Januari tahun ini, jumlah pengguna aktif mingguan produk ini telah tumbuh lebih dari 5 kali lipat, dengan kurva pertumbuhan yang sangat curam. Saat ini, skala pengguna aktif mingguannya telah mencapai 5 juta. Di antaranya, kecepatan adopsi Codex oleh pekerja pengetahuan (bukan pengembang) adalah 3 kali lebih tinggi daripada kelompok pengembang.
Perlu diperhatikan bahwa kurva pertumbuhan yang curam ini memiliki katalis penting — peluncuran aplikasi desktop pada bulan Februari. Versi desktop ini menyediakan antarmuka penggunaan yang eksklusif dan dioptimalkan, secara signifikan menurunkan hambatan penggunaan, dan mendorong ledakan unduhan serta adopsi Codex.
Di balik kurva pertumbuhan yang curam ini, yang mendorong perubahan bentuk produk adalah peran yang relatif lebih sedikit dibahas secara terbuka — Andrew Ambrosino, Kepala Tim Aplikasi Desktop Codex.
Sebagai orang yang secara langsung bertanggung jawab atas evolusi produk sisi desktop Codex, ia berdiri di antara dua dunia yang tumpang tindih dengan cepat: di satu sisi adalah rantai alat pengembang yang berpusat pada "menulis kode", di sisi lain adalah pintu masuk kerja AI umum yang dengan cepat meluas ke hampir semua skenario pekerjaan pengetahuan. Dari ritme peluncuran produk hingga perubahan perilaku pengguna, hingga bagaimana tim internal mendefinisikan ulang batas "desain", "teknik", dan "produk", apa yang ia lihat seringkali lebih dekat dengan esensi perubahan ini daripada data pertumbuhan itu sendiri.
Wawancara berikut ini, justru dari sudut pandangnya, untuk membongkar apa yang diubah oleh Codex, mengapa bergabung dengan ChatGPT, dan bagaimana arah iterasi masa depannya.
Tautan video: https://www.youtube.com/watch?v=P3KDebPTUrw
Kami telah menyusun sebagian konten wawancara, untuk detailnya silakan lihat video aslinya.
Implementasi Menjadi Lebih Murah,
Lalu Apa yang Menjadi Lebih Mahal?
Beberapa tahun lalu, logika pengembangan produk secara keseluruhan adalah seperti ini: implementasi itu mahal. Jadi sebelum mulai menulis kode, Anda harus melakukan banyak pekerjaan mitigasi risiko di awal — menulis dokumentasi, melakukan penelitian, membuat purwarupa, tujuannya adalah agar desain menjadi lebih murah. Justru karena implementasi itu sendiri sangat mahal, Anda harus merapikan semuanya di tahap awal.
Tapi sekarang asumsi ini benar-benar terbalik. Di OpenAI, situasinya menjadi seperti ini: memberikan banyak token kepada orang, setiap orang punya ide bagus, jadi setiap orang sedang membuat sesuatu. Hasilnya, untuk sebuah fitur yang perlu dibuat, mungkin ada 90 tim berbeda yang secara bersamaan mengeksplorasi 90 cara implementasi yang berbeda.
Ini berarti implementasi bukan lagi bagian yang mahal. Lalu apa yang menjadi lebih mahal? Andrew dengan blak-blakan mengatakan: adalah selera. Lebih spesifik lagi, adalah proses kurasi. Ketika Anda menghadapi 90 percobaan yang berbeda ini, Anda perlu memiliki pandangan untuk menilai: mana yang dilakukan dengan baik? Bagaimana seharusnya ini dilipat ke dalam fungsi lain? Bagaimana seharusnya ini dibingkai? Berapa banyak tingkat tombol toggle ini? Keputusan-keputusan ini sendiri, adalah hal yang sekarang paling mahal dan paling perlu dipikirkan.
Apa sebenarnya selera itu?
Kata "selera" ini sudah terlalu sering disebut di Silicon Valley. Tapi di sini, Andrew memberikannya makna yang sangat konkret.
Ada lelucon menarik, Kepala Produk Linear pernah berkata bahwa ada orang yang terlalu menekankan aspek estetika dari selera, lalu mengambil Paul Graham sebagai contoh — Paul Graham jelas memiliki selera yang baik, tapi dia mengenakan celana kerja. Ini menunjukkan bahwa selera jauh melampaui penampilan. Andrew menjelaskan inti dari selera: ada aspek estetika, tapi itu hanya sebagian; ada aspek pemikiran sistem, yaitu bagaimana sesuatu ini berintegrasi ke dalam seluruh sistem; ada aspek rasa arah, bagian dari tema apa ini; ada aspek cara presentasi. Tentu juga ada aspek detail, seperti apakah animasi interaksi ini sesuai dengan makna semantik yang ingin disampaikan — apakah terlalu cepat, tidak cocok untuk menyampaikan konsep ini.
Tapi masalah selera inti yang sebenarnya adalah seperti ini: Jika kita bisa membangun apa saja, lalu apa yang kita inginkan? Apa ini? Bagaimana kita sampai di sana? Inilah masalah selera yang sebenarnya.
Ini bukan hanya tentang memilih apa yang harus dilakukan. Juga tentang bagaimana menyajikan informasi, bagaimana mencapai tujuan, menggunakan media apa. Selera adalah tempat di mana otak manusia masih paling berharga di era baru ini.
Mengapa AI Sampai Sekarang Masih Tidak Bisa Mendesain dengan Baik?
Ini adalah paradoks yang menarik: Codex sudah sangat kuat dalam menulis kode, tapi ketika digunakan untuk menghasilkan desain, kualitas output sering kali biasa-biasa saja. Jarang yang bisa bilang "Wow, itu benar-benar berhasil".
Andrew berpikir ada beberapa lapisan alasan di balik ini. Pertama adalah alasan praktis. Desain lebih sulit dinilai daripada perangkat lunak, karena selera manusia yang menilai baik buruknya desain itu sendiri adalah bagian dari mekanisme umpan balik. Ini membuat pelatihan model menjadi sulit — tidak seperti kode, sulit untuk mengukurnya dengan standar objektif (apakah kode dapat dikompilasi? Apakah fungsinya normal?). Kedua, dari sudut pandang investasi penelitian, laboratorium secara historis menginvestasikan sumber daya terbanyak untuk meningkatkan kemampuan yang dapat mempercepat penelitian AI itu sendiri. Pada tahap awal model pengkodean, jelas kemampuan menulis kode dengan benar akan mempercepat penelitian. Tapi apakah kemampuan desain bagus atau tidak, dampak akselerasinya terhadap penelitian AI tidak terlalu langsung.
Masalah yang lebih dalam menyangkut kompleksitas pekerjaan desain itu sendiri. Dalam desain ada aspek budaya — apa yang dianggap "desain yang bagus" ditentukan oleh budaya. Tahun lalu semua situs web baru meniru desain Linear, itu memang desain yang bagus, punya selera. Tapi jika sebuah model setiap kali menghasilkan output seperti Linear, itu bukan kemajuan, tapi kegagalan. Desain membutuhkan kebaruan, sedangkan rekayasa perangkat lunak justru sebaliknya, Anda hampir selalu mengharapkan kode mengikuti pola yang diketahui.
Masalah yang paling sulit diselesaikan terletak pada lapisan abstraksi. Ketika kode menggerakkan desain visual, ada interaksi yang mendalam di antara keduanya. Misalnya, sesuatu di sudut kiri atas harus berbagi abstraksi yang sama di basis kode dengan tempat di bawah. Ini bukan hanya soal model perlu menjadi desainer yang lebih baik, tapi model perlu memahami hubungan struktur yang lebih dalam ini — jika perusahaan besok melakukan rebranding, pendekatan dangkal adalah memperbarui 263 komponen satu per satu, tapi pemahaman yang dalam seharusnya adalah: dua hal yang terlihat berbeda ini secara semantik adalah sama, keduanya adalah daftar, keduanya memiliki gaya yang sama, keduanya menyampaikan pola interaksi yang sama. Pemahaman pada lapisan abstraksi seperti ini, saat ini masih jauh dari jangkauan AI.
Mengapa Codex Tidak Bisa Diluncurkan Lebih Awal?
Ini adalah pengamatan yang sangat mendalam: Kesuksesan produk tidak hanya bergantung pada desain itu sendiri, tetapi juga pada momen kemampuan model.
Andrew sangat yakin, jika aplikasi Codex diluncurkan pada November tahun lalu, itu akan gagal total di pasar. Padahal produk dengan bentuk yang sama yang diluncurkan pada Februari, justru meraih kesuksesan besar. Satu-satunya variabel adalah kemajuan kemampuan model selama beberapa bulan di antaranya. Dengan kata lain, desain interaksi produk, antarmuka pengguna, seluruh konsep tidak berubah, tetapi peningkatan tingkat kecerdasan model, sepenuhnya mengubah hasil.
Ini mengungkapkan kebenaran yang mendalam: Di era AI, apakah produk mudah digunakan, apakah berharga, bukan ditentukan oleh desain UI atau desain interaksi secara terpisah, melainkan oleh "apa yang dapat dilakukan model pada momen ini". Ide yang sama, diwujudkan dengan model lama mungkin tidak berguna sama sekali, tetapi dengan model baru mungkin sangat menarik.
Ini juga mengubah cara perencanaan produk. Andrew melihat peralihan ini di perusahaan sebelumnya: Bukan lagi "apa yang kita rencanakan untuk dilakukan sepanjang tahun", melainkan menjadi "kita percaya model dapat melakukan apa pada titik waktu tertentu, mari kita daftar semua hal yang menarik, buat purwarupa untuk semuanya, lalu putuskan mana yang bisa dilakukan sekarang, yang lain disimpan dulu dan ditunggu, saat model mengalami lompatan baru, coba lagi ide-ide yang sebelumnya ditangguhkan dengan model yang telah ditingkatkan". Karena prasyarat keseluruhan fungsi berguna atau tidak, bukan bentuk desainnya, melainkan apakah model cukup pintar.
Apakah Batas Insinyur, Desainer, PM Sudah Hilang?
Lenny menyebutkan, melihat riwayat Andrew, insinyur, desainer, manajer produk, pengusaha semua pernah dia lakukan, sekarang mengelola seluruh aplikasi desktop, lalu bertanya apakah tim desain juga di bawahnya. Andrew tertawa mengatakan "tergantung minggu mana" — hubungan pelaporan selalu berubah, tetapi tim selalu duduk bersama dengan erat, bekerja tertanam satu sama lain.
Andrew berkata, pihak luar sudah membahas "penciutan peran", mengatakan bahwa di masa depan tidak akan ada pembagian peran lagi, tim mereka belum sampai pada tahap itu, tetapi tumpang tindih antar peran memang lebih jelas dibandingkan departemen lain di perusahaan, bahkan seluruh industri — sebagian alasannya adalah Codex memang produk teknis yang ditujukan untuk insinyur, desainer di tim bisa berbicara bahasa insinyur, manajer produk juga bisa menulis kode, misalnya manajer produk lain Alexander memiliki gelar master ilmu komputer, Andrew sendiri justru tidak.
Dia berpikir, sekarang penjelasan yang lebih akurat adalah: Seseorang tidak lagi didefinisikan oleh batasan seperti "desain berakhir di mana, teknik mulai dari mana", melainkan oleh apa yang rata-rata dia habiskan waktunya untuk dilakukan — ini juga terkait dengan cara kerja tim, karena seluruh aplikasi dijalankan dengan "makan makanan anjing sendiri" secara internal, semua orang ingin menyelesaikan pekerjaan sebanyak mungkin di dalam aplikasi, meskipun untuk sementara ini bukan alat terbaik untuk melakukan hal ini, sehingga lama-kelamaan bisa menjadi alat terbaik. Keduanya juga sekilas membicarakan asal-usul gelar "anggota staf teknis", Andrew berpikir mungkin awalnya Xerox yang mulai menyebutnya begitu, sekarang di perusahaan yang digerakkan penelitian sudah menjadi semacam tradisi.
Lenny mengejar, apakah ini berarti di masa depan semua orang akan menjadi "pembangun" tanpa pembagian fungsi, apakah klasifikasi keterampilan PM, desain, teknik ini masih akan ada. Sikap Andrew jelas: Dia tidak setuju dengan penghapusan total pembagian peran. Dia melihat banyak perusahaan yang berteriak "hapus posisi produk, semua orang adalah pembangun", hasilnya praktik terbaik yang terakumulasi selama bertahun-tahun di bidang produk, pengalaman trial and error, justru dibuang sebagai hal yang tidak berguna karena pemikiran "saya juga bisa menulis kode". Perasaan "ini bukan wilayahmu" seperti mengurung diri ini menghilang, dia menyambut baik, tetapi setiap profesi masih memiliki ambang keterampilannya sendiri — bukan berarti siapa pun yang menggunakan Excel, bisa menggantikan tugas di departemen keuangan.
Dia juga menyebutkan, sekarang berganti peran memang lebih mudah daripada dulu, karena kemampuan tidak lagi terikat mati dengan "apakah menguasai alat tertentu": Dia sendiri pernah lama merasa tidak seharusnya menjadi insinyur, karena tidak suka mendalami bahasa assembly, menghafal sintaks TypeScript, dan ambang "menguasai alat tertentu baru dianggap bekerja dengan baik" ini sedang runtuh. Namun dia juga mengingatkan, tren ini saat ini dibesar-besarkan secara berlebihan oleh pihak luar.
Cara Pengembangan Berbantuan AI Paling Mutakhir Saat Ini
Lenny menarik topik kembali satu lapisan: dari menulis kode murni manual, sampai AI bisa menulis 100% kode, sampai sekarang "menulis kode" berubah menjadi "membimbing AI" — mengevaluasi berapa banyak kode yang ditulis seseorang, hampir menjadi "berapa kali Anda mengoreksi arah AI". Dia bertanya, apakah cara paling mutakhir sekarang adalah "loop" (pengembangan siklus mandiri)? Tim-tim AI yang paling maju, sekarang secara konkrit beroperasi bagaimana?
Andrew menyebutkan, masalah mendasarnya adalah, pertanyaan "berapa banyak kode yang ditulis AI" itu sendiri sudah tidak penting lagi, karena berdasarkan standar tahun lalu, sekarang hampir 100% kode ditulis AI; yang sebenarnya harus ditanyakan adalah, apakah kode-kode ini ditulis secara "terawasi", atau "tanpa pengawasan", ini adalah dua hal yang sama sekali berbeda. Dia mengatakan senang melihat standar penilaian ini terus diperbarui, karena ini justru menunjukkan produk bergerak maju. Tim telah melakukan banyak eksplorasi ke arah "pengembangan perangkat lunak mandiri", juga termasuk banyak percobaan terkait "rekayasa harness", misalnya membayangkan model berjalan sendiri di malam hari, melakukan pembersihan repositori kode seperti "pengumpulan sampah".
Dia juga mengakui, saat ini semua model memiliki masalah umum — cenderung membuat kode semakin kompleks. Dia setengah bergurau mengatakan, jika ada tim penelitian perusahaan yang kebetulan mendengarkan, berharap dapat melatih kemampuan model "menghapus kode" menjadi lebih baik. Ini juga masalah nyata yang dihadapi saat pengembangan sepenuhnya diserahkan ke autopilot, baik di sisi manusia maupun repositori kode: bagaimana mengajari model menilai fungsi mana yang harus dilakukan, mana yang harus diabaikan, mana yang harus digabung dan dikategorikan ulang; bagaimana mengajari model membangun struktur abstraksi yang benar. Kemampuan-kemampuan ini sedang membaik, tetapi dia berpikir saat ini belum bisa mencapai tingkat "atur loop biarkan dia sendiri memperbaiki produk, sambil mengawasi Twitter, Slack, email", tetapi tim terus berusaha ke arah itu.
Lenny mengejar, apakah suatu hari nanti, tim malah langsung memberi AI tujuan akhir seperti "menang" atau "beri saya satu miliar" selesai. Andrew tertawa mengatakan dia tidak berani berkata mati, tidak akan mudah menyatakan "tidak akan pernah" atau "pasti akan".
Mengapa Harus Menggabungkan Codex dan ChatGPT?
Ke Mana Masa Depan Codex Akan Menuju?
Codex awalnya adalah alat baris perintah, baru kemudian dibuat menjadi aplikasi independen, posisi awalnya sangat jelas: sebuah "alat pengembang" — bukan IDE, bisa melihat kode, tapi tidak membiarkan mengedit kode.
Sebelum aplikasi secara resmi dirilis ke luar, tim terlebih dahulu melakukan uji coba di internal OpenAI (Januari-Februari). Umpan balik dalam skenario teknik dan penelitian sangat jelas, sangat positif. Tetapi tim juga menemukan bahwa orang-orang dari hampir semua departemen seperti pemasaran, humas, keuangan, hukum juga menggunakan aplikasi ini — meskipun pengalaman ini tidak ramah untuk mereka, antarmukanya penuh dengan kode dan permintaan izin baris perintah, sama sekali bukan pengalaman yang dirancang untuk mereka.
Awalnya, respons tim adalah memindahkan kemampuan Codex ke dalam antarmuka produk lain, seperti aplikasi desktop ChatGPT dan browser Atlas, menjadikannya alat kerja pengetahuan yang lebih umum. Tetapi hasilnya tidak ada yang mau meninggalkan aplikasi Codex untuk menggunakan aplikasi "khusus" yang dibuat itu. Ini membuat tim menyadari: batas antara alat pengembang dan alat pengetahuan umum sedang runtuh, Codex dan ChatGPT lebih mirip pintu masuk berbeda dari kemampuan yang sama, bukan dua jenis produk independen.
Kesimpulan tim adalah: rangkaian produk ini harus dibuat menjadi dasar yang cukup umum, dapat diperluas, mampu sekaligus menangani skenario mendalam seperti keuangan, hukum, sains. Tantangan sebenarnya hanya terletak pada "bagaimana membuatnya cukup umum" — ini juga jawaban tim atas pertanyaan "apakah Codex adalah alat pengembang, atau langsung ChatGPT".
Pembawa acara Lenny kemudian menunjukkan: Codex sudah dibuat lebih mudah digunakan, lebih menyenangkan daripada aplikasi ChatGPT itu sendiri, pengguna semua beralih menggunakannya, jadi penggabungan adalah arah yang pasti, dapat menghindari kebingungan kognitif.
Andrew tertawa merespons, ada yang menyebut arah ini sebagai "aplikasi super" (super app), dia cukup menyesal ada yang mengucapkan kata itu, karena sejak itu, dia setiap hari dikepung oleh sebutan ini.
Lenny mengejar: jangan dulu menyebutnya "aplikasi super", tetapi apakah inti pemikirannya adalah "pengguna pergi ke satu tempat, dapat menyelesaikan semua hal"? Atau, hal ini saat ini belum ada kesimpulan?
Jawaban yang diberikan Andrew, adalah konsep "home base" (markas besar): ini seharusnya adalah "markas" yang bagus, tempat di mana pengguna dapat melacak semua tugas yang harus dilakukan mereka di antarmuka produk yang berbeda, di semua tempat. Beberapa hal, pengguna dapat sepenuhnya menyelesaikannya di dalam aplikasi; hal-hal lain, aplikasi bertanggung jawab untuk memanggil, membuka aplikasi lain untuk menyelesaikannya — misalnya, aplikasi dapat terhubung dengan Excel, aplikasi memang memiliki editor spreadsheet bawaan, tetapi untuk orang yang perlu melakukan pemodelan keuangan rumit untuk pendanaan miliaran dolar di OpenAI, editor bawaan ini mungkin masih jauh dari cukup. Jadi aplikasi akan langsung berbicara dengan plugin Microsoft Excel di desktop komputer pengguna, setelah pekerjaan selesai, pengguna dapat langsung menutup Excel.
Artinya, hal ini sejak awal bukan "kami menggambar kotak di layar, semua hal harus terjadi di dalam kotak ini", melainkan — hal ini seharusnya menjadi "rumah" pengguna: Anda mulai bekerja di sini, menyelesaikan pekerjaan di sini, mengotomatisasi pekerjaan, perlu menggunakan alat apa, dia akan memanggil alat itu.
Untuk menjelaskan hal ini, Andrew menceritakan sebuah kisah konkret. Saat aplikasi Codex pertama kali diluncurkan, tim merekam beberapa video promosi, pekerjaan mengedit video ini jatuh pada fotografer internal. Hasilnya, fotografer menggunakan Codex untuk mengedit video-video ini dari awal sampai akhir — ini adalah salah satu momen pertama kali tim benar-benar menyadari "Astaga, orang-orang ternyata menggunakan ini untuk hal semacam ini".
Fotografer memikirkan menggunakan Codex untuk mengedit video, murni karena rasa ingin tahu, hanya ingin melihat apakah Codex benar-benar bisa melakukan hal ini. Codex itu sendiri sama sekali bukan editor video, antarmukanya juga tidak memiliki UI terkait pengeditan, tetapi dia dapat memahami bahwa fotografer menggunakan Premiere Pro, dan dapat menyelesaikan sebagian operasi pengeditan dengan langsung mengedit file rekayasa di balik Premiere Pro yang mendukung konten tampilan layar — hanya saja ini belum bisa mencakup semua kebutuhan. Lalu, yang dilakukan Codex selanjutnya, adalah menulis sendiri sebuah plugin ekstensi yang dapat dimasukkan ke dalam Premiere Pro, lalu melalui plugin ini "berbicara" dengan Premiere Pro — "Hai, ekstensi Premiere Pro, bisakah kamu membantu saya mengubah titik penanda ini." Ketika tim pertama kali melihat proses ini benar-benar terjadi, semua merasa ini terlalu luar biasa.
Dari sini, Andrew merangkum sebuah model: Di dunia ini sudah ada banyak alat profesional yang mencapai kesempurnaan di bidangnya masing-masing, Codex — sekarang ditambah ChatGPT — ingin melakukan dua hal sekaligus.
Hal pertama, adalah bagaimana berkolaborasi secara mulus dengan alat-alat yang sudah digunakan pengguna: tim tidak perlu membuat ulang editor video yang lebih baik, melainkan membuat Codex dan ChatGPT belajar menggunakan alat yang sudah ada — bisa berinteraksi dengannya, menyerahkan tugas kepadanya, biasanya ini dicapai melalui konektor (connectors), kemampuan penggunaan komputer (computer use), atau seperti kasus Premiere Pro ini, melalui plugin ekstensi.
Hal kedua, adalah konsep yang pernah disebutkan Dan Shipper: pengguna sudah memiliki banyak aplikasi web yang bisa diklik-klik, tetapi berharap dapat membuka aplikasi-aplikasi ini langsung di dalam Codex, biarkan Codex melakukan lebih banyak hal untuk mereka di dalamnya. Kedua mode ini, hampir saling mencerminkan, tim saat ini secara bersamaan mendorong kedua jalur ini dengan kuat.
Artikel ini dari akun WeChat publik "机器之心" (ID:almosthuman2014), penulis: 机器之心
