Codex 负责人：「所有人都是 builder」是个很糟糕的主意

Andrew Ambrosino adalah pemimpin tim OpenAI Codex. Berawal dari desainer, pernah menjadi insinyur, juga manajer produk, dan pernah mendirikan startup. Sekarang, Codex yang ia pimpin memiliki lebih dari 5 juta pengguna aktif mingguan. Ia mungkin salah satu orang yang paling cocok untuk menjawab pertanyaan "bagaimana cara membuat produk di era AI".

Menurutnya, ketika hampir semua orang di perusahaan bisa dengan cepat membuat prototipe fitur, masalah sebenarnya bukan lagi "apakah bisa dibuat", melainkan "apakah sebaiknya dibuat".

Dalam perbincangannya dengan Lenny, Andrew Ambrosino menjelaskan secara rinci proses pengembangan internal OpenAI: ketika biaya implementasi ditekan secara drastis oleh AI, setiap aspek pengembangan produk—dari inisiasi proyek, dokumentasi, prototipe, desain, hingga pembagian peran, kolaborasi tim, dan perencanaan produk—semuanya berubah. Aturan lama mana yang mulai tidak berlaku? Standar baru apa yang sedang terbentuk? Ketika implementasi tidak lagi langka, apa yang benar-benar menjadi sumber daya langka?

Beberapa poin inti:

Ketika 90 orang bisa membuat 90 prototipe produk yang tampak siap diluncurkan, yang paling berharga adalah "taste" (selera).

Salah satu syarat keras tim Codex dalam merekrut adalah selera; kemampuan membedakan sinyal dan noise dari lautan konten. Di dunia yang "memiliki token tak terbatas", mereka tidak ingin memproduksi konten sampah.

Jika Codex dirilis tiga bulan lebih awal, itu akan gagal total. Satu-satunya perbedaan adalah kemajuan model. Jangan mudah menilai suatu fitur buruk; mungkin saja waktu yang tepat belum tiba.

Apakah suatu fitur pada akhirnya cukup baik seringkali tidak bergantung pada bentuk fitur itu sendiri, melainkan seberapa cerdas modelnya.

Seperti Codex yang pernah mendisrupsi ChatGPT, Codex juga bisa didisrupsi oleh inovasi baru. Budaya eksplorasi bottom-up harus dipertahankan; tidak bisa mengharapkan tim yang sama untuk merapikan detail sekaligus mendisrupsi dirinya sendiri.

Berikut adalah inti dari perbincangan tersebut.

Biaya implementasi menurun, taste menjadi lebih penting

Lenny: Anda bilang AI mengubah bentuk kerja produk. Anda sekarang bekerja di tim produk AI yang mungkin paling terdepan di dunia. Secara spesifik, bagaimana cara kerja tim produk berubah dibanding dua tahun lalu?

Andrew Ambrosino: Sekarang sebagai pemimpin tim, hal tersulit adalah prosesnya terbalik.

Dulu bagaimana cara membuat produk, semua orang tahu: riset dulu, munculkan ide, buat prototipe. Meskipun kita sudah lama melewati era waterfall development, logika dasarnya masih sama: implementasi itu mahal. Jadi sebelum implementasi, semua risiko harus dihilangkan melalui dokumentasi, riset, dan prototipe. Karena prototipe dan desain lebih murah daripada pengembangan, itu asumsi dasar dulu.

Sekarang asumsi itu berubah total. Siapa pun bisa membuat apa pun. Saya benar-benar percaya, mulai dari nol dengan model-model ini, baik model kami atau perusahaan lain, Anda bisa membuat fitur apa pun yang Anda inginkan. Ini belum tentu bagian tersulit dalam pengembangan perangkat lunak, tapi memang keren.

Anda beri orang tokens tak terbatas, setiap orang di OpenAI proaktif dan punya ide bagus. Jadi setiap orang membuat berbagai macam hal. Sekarang di perusahaan ada fitur yang sangat kami butuhkan, saya yakin ada 90 tim kecil yang tidak terkoordinasi sedang mengimplementasi dan mencobanya masing-masing. Dari 90 percobaan itu, mana yang bagus? Bagian mana yang harus dilipat ke aspek lain? Bagaimana mendefinisikannya? Haruskah itu menjadi bagian dari fitur lain? Berapa banyak opsi dalam sakelar? Itulah hal-hal yang terjadi.

Jadi jawaban singkatnya: terbalik. Bukan orang-orang melakukan peran yang benar-benar berbeda, atau skill menghilang, peran tidak ada. Implementasi bukan lagi bagian termahal; saya berani mengatakan yang termahal adalah taste (selera).

Lenny: Jadi dulu orang menulis PRD, dokumen strategi, sekarang langsung buat prototipe. Banyak orang di perusahaan punya ide serupa, jadilah 90 hal berbeda, lalu pilih arah dari situ?

Andrew Ambrosino: Ya, hal seperti itu banyak terjadi. Tidak hanya di OpenAI, Anda sudah lihat banyak pemimpin produk bilang "PRD sudah mati, prototipe yang berkuasa", tapi saya sebenarnya sama sekali tidak setuju dengan pandangan itu.

Karena implementasi menjadi murah di setiap media, sangat menggoda untuk langsung membuat prototipe tanpa berpikir. Apalagi jika Anda bukan insinyur, belum pernah menulis kode, atau tidak punya minat/waktu, Anda pasti akan berkata, "PRD sudah mati, biarkan saya langsung tunjukkan apa yang saya inginkan."

Tapi saya juga melihat fenomena sebaliknya. Bagi insinyur, menulis banyak dokumen justru menjadi sangat menggoda, dokumen yang tidak layak dibaca. Ini bukan berarti penulis dokumen jelek, tapi ketika implementasi melimpah, memilih format yang tepat untuk menyampaikan pendapat Anda menjadi sangat penting.

Jika Anda ingin menyampaikan kejelasan produk di area yang ambiguous, mungkin memang harus menulis dokumen. Jika Anda ingin orang mencoba, stress-test pola interaksi, buatlah prototipe. Kuncinya adalah memilih media yang tepat.

Lenny: Ada konsep "primal mark" (tanda pertama), goresan pertama seniman di kanvas, semua hal berikutnya berkembang dari situ. Maksud Anda, kadang prototipe adalah tanda pertama yang salah? Karena orang akan terpaku padanya, bukan memikirkan opsi yang lebih besar?

Andrew Ambrosino: Ya. Dulu ada sinyal implisit: bagaimana sesuatu terlihat menandakan tahap prosesnya. Jika Anda melihat sesuatu yang terlihat seperti produk yang akan diluncurkan, itu berarti sudah tahap akhir, risiko sudah dihilangkan, desain sudah diperiksa, tujuan bisnis sudah masuk akal.

Sekarang hal-hal itu terlepas. Penyebabnya adalah dulu untuk mendapatkan sumber daya untuk membangun, Anda harus cukup mengurangi risiko, sekarang batas itu tidak ada. Jadi sesuatu yang sebenarnya hanya tahap eksplorasi, sudah terlihat siap diluncurkan, secara visual sudah siap. Tapi mungkin itu bukan arah yang benar, tidak sesuai riset, bukan kebutuhan pengguna, atau bukan yang terbaik untuk bisnis.

Ini bukan untuk terlalu menekankan soal taste. Tapi sekali lagi, mengetahui apa yang harus dilakukan, bagaimana menyajikannya, bagaimana mencapai tujuan, media apa yang digunakan, ini menjadi kemampuan terpenting di setiap bidang.

Lenny: Kata "taste" sekarang menjadi kata populer. Secara spesifik, apa yang Anda maksud dengan "taste yang baik"?

Andrew Ambrosino: Taste perlu dipecah.

Ada aspek estetika, tapi juga aspek pemikiran sistem: bagaimana ini ditempatkan dalam keseluruhan sistem; ada aspek arah: ke mana kita pergi, topik apa ini bagiannya; ada aspek penyampaian: bagaimana informasi ini disajikan; dan sebagian taste adalah aspek interaksi: animasi ini tidak sesuai dengan semantik yang ingin disampaikan, terlalu tergesa-gesa, tidak cocok dengan maknanya.

Hal-hal ini memang sangat penting, tapi masalah taste yang sebenarnya adalah: jika kita bisa melakukan segalanya, apa tujuannya? Bagaimana mencapainya?

Lenny: Ketika AI semakin kuat dan semakin banyak melakukan hal, di area mana otak manusia akan terus bernilai? Taste terasa seperti salah satunya. Tapi output desain AI masih kurang bagus, mengapa model terbaik belum bisa membuat desain yang baik?

Andrew Ambrosino: Ada beberapa alasan praktis, dan beberapa masalah yang lebih sulit. Desain lebih sulit dinilai daripada perangkat lunak. Membuat loop umpan balik untuk melatih model apa itu desain bagus lebih rumit daripada melatih apakah kode bisa dikompilasi, karena taste manusia adalah bagian dari mekanisme umpan balik.

Selain itu, secara historis laboratorium memprioritaskan model untuk bisa mempercepat riset AI. Model yang bisa menulis kode yang benar jelas mempercepat riset, desain tidak bisa dengan argumen yang sama. Bukan berarti desain tidak penting, tapi tidak berada dalam roda gila itu.

Itu alasan praktis, dan itu akan hilang. Model akan menjadi cukup baik dalam desain, tapi ada beberapa hal yang lebih sulit.

Pertama, desain memiliki sifat budaya. Anda ingat tahun lalu setiap situs baru meniru desain Linear. Jika model setiap kali mengeluarkan situs Linear, itu bukan tantangannya. Pentingnya kebaruan dalam desain jauh lebih tinggi daripada rekayasa perangkat lunak. Dalam rekayasa perangkat lunak, Anda ingin model sepenuhnya mengikuti pola yang dikenal, tapi desain membutuhkan keacakan dan kebaruan tertentu.

Kedua, interaksi antara desain visual dan kode. Jika besok perusahaan berganti merek, pendekatan dangkal adalah memperbarui 263 komponen satu per satu. Pendekatan mendalam adalah memahami bahwa dua hal yang terlihat berbeda sebenarnya milik satu gaya daftar, menyampaikan pola interaksi yang sama. Lapisan abstraksi ini, teknologi saat ini belum bisa menjangkaunya.

Lenny: Jenny Wen (Kepala Desain Claude Code Anthropic) mengatakan proses desain sudah mati, langsung bangun saja. Bagaimana pendapat Anda?

Andrew Ambrosino: Saya dan Jenny mungkin setuju dalam banyak hal. Proses desain formal, saya setuju dengannya, sudah mati. Dan sebelum AI saya bukan penggemar proses itu.

Bertahun-tahun lalu saat saya memulai startup, ada artikel berjudul "Pabrik Studi Kasus", yang mengatakan bahwa desainer dilatih untuk mengikuti proses tetap, dan secara bertahap menganggap proses itu sendiri lebih penting daripada hasil. Jika sesuatu melalui proses ini, secara default akan mendapat dua kesimpulan: pertama, pasti bagus, proses menjamin kualitas; kedua, meskipun tidak ada yang menggunakannya, tetap bagus karena sudah melalui proses.

Riset pengguna, divergensi, konvergensi, kerangkanya benar, tapi selalu agak akademis. Premis proses itu adalah implementasi mahal, Anda hanya bisa membangun sekali, jadi sebelum melakukannya, ruang masalah dan ruang solusi harus dieksplorasi sepenuhnya.

Lalu Figma dan Origami muncul, kita memasukkan prototipe interaktif ke dalam proses. Sekarang masalahnya adalah Anda bisa menarik seluruh implementasi ke depan proses. Prototipe yang sepenuhnya disempurnakan, terlihat bisa langsung diluncurkan. Cukup banyak orang di perusahaan melihat dan bertanya, "Bisa kita rilis sekarang?" Tapi sebenarnya, Anda masih dalam tahap awal eksplorasi desain, hanya saja tidak ada yang mengatakannya secara eksplisit.

Jadi mengatakan proses desain sudah mati, benar dan tidak. Jika Anda terikat pada alat tertentu dan rutinitas harian tertentu, maka itu memang mati. Tapi kesadaran "kita sekarang di tahap mana dalam proses" lebih penting dari sebelumnya.

Mengikat proses desain pada media tertentu, itulah bagian berbahayanya. Desainer sekarang punya lebih banyak alat, Anda bisa langsung menempatkan sesuatu ke produk yang ada, bisa melakukan A/B testing. Banyak perusahaan punya versi bayi dari produk, baby Cursor, baby Codex, basis kode yang sangat disederhanakan yang bisa mensimulasikan semua interaksi produk resmi. Anda bisa menggunakannya untuk vibe coding, berkata "Bagaimana jika sidebar seperti ini? Bagaimana jika panel muncul?" Ini alat baru bagi desainer, tapi perlu dikombinasikan dengan pengetahuan lama: di mana posisi Anda dalam proses.

Peran dan jabatan melebur, tapi PM tidak akan hilang

Lenny: Banyak perusahaan bilang "peran sudah mati". Menurut Anda, pembagian peran PM, insinyur, desainer akan benar-benar hilang?

Andrew Ambrosino: Beberapa perusahaan suka mengikuti tren, ekstrem. Bahaya menghilangkan konsep peran adalah bisa sekaligus menghilangkan kesadaran bahwa bidang-bidang ini adalah profesi dengan praktik terbaik yang bisa dipelajari.

Saya dengar banyak perusahaan bilang "kami akan menghapus peran produk", menurut saya itu ide yang sangat buruk, lalu bilang "semua orang adalah builder". Akibatnya, manajemen produk, disiplin yang sudah mengumpulkan praktik terbaik nyata dan benar-benar pernah jatuh, langsung dibuang. Karena ada yang menulis beberapa baris kode, mereka merasa semuanya baik-baik saja. Itu bukan kondisi yang baik.

Saya menyambut batas "ini bukan bidangmu, kamu tidak boleh sentuh" yang hilang, tapi perlu keseimbangan. Tidak semua orang bisa melakukan segalanya, baik dari segi luas maupun kedalaman, itu juga mengapa manajer tidak akan hilang.

Dan setiap disiplin memiliki komponen skill. Banyak insinyur tidak mengakui ini, merasa teknik punya skill, peran lain hanya "vibes". Tidak seperti itu, Anda bisa menggunakan Excel bukan berarti Anda bisa bekerja di tim keuangan.

Menurut saya yang terjadi sekarang lebih kepada kolaborasi lintas peran menjadi lebih mudah, mempelajari praktik terbaik bidang lain menjadi lebih mudah, tanpa perlu mengikat efisiensi Anda dalam suatu peran dengan kemampuan menggunakan alat tertentu.

Saya butuh waktu lama merasa tidak seharusnya menjadi insinyur perangkat lunak karena saya tidak peduli dengan bahasa assembly, dan tidak ingin mengingat sistem tipe TypeScript. Peran-peran ini selalu memiliki hambatan tertentu, seolah "berhasil dalam peran ini sama dengan menguasai alat ini". Saya rasa ini mulai larut, tapi orang membesar-besarkannya.

Lenny: Di tim Codex Anda memang ada lebih banyak peleburan peran. Seperti apa sebenarnya?

Andrew Ambrosino: Di tim Codex, kami memang melihat peleburan peran yang lebih besar daripada tim lain di perusahaan dan industri lain. Sebagian karena ini adalah produk teknis untuk insinyur. Jadi desainer kami berbicara bahasa insinyur, manajer produk kami berbicara bahasa teknis dan bisa menulis kode.

Kami punya cara internal untuk mendeskripsikan kolaborasi: sekarang tumpang tindih antar peran jauh lebih besar dari sebelumnya. Mendefinisikan seseorang bukan lagi berdasarkan batas tanggung jawab "di mana desain berakhir, di mana teknik dimulai", melainkan berdasarkan distribusi rata-rata dari semua pekerjaan yang dilakukannya.

Jika Anda membentangkan semua hal yang dilakukan seseorang di tim desain, mungkin termasuk banyak pekerjaan menulis kode, dan juga banyak pekerjaan terkait produk. Tapi jika dirata-ratakan, pada akhirnya ia tetap jatuh di area yang lebih condong ke desain.

Lenny: Anda menyebut pekerjaan manajer produk lebih seperti "zone defense" (pertahanan area). Apa maksudnya?

Andrew Ambrosio: Jika dua manajer produk bekerja sama terlalu erat, biasanya bukan sinyal yang bagus. Anda seharusnya lebih seperti layout berbasis gaya: bentangkan tim, lihat di mana ada celah, mana yang belum tercakup?

Di dunia sekarang, kurasi, bimbingan, dan penyelarasan menjadi pekerjaan terpenting. Setiap orang terus melontarkan ide, seluruh lingkungan penuh noise. Cara top-down dan perencanaan tahunan sudah tidak berfungsi. Kita perlu seseorang sebagai penjaga taste, membimbing sesuatu dari konsep ke produk, dan ini berarti Anda harus menjangkau setiap sudut perusahaan.

Jadi, Anda perlu membentangkan tim, siapa yang ahli dalam apa? Pastikan jarak satu sama lain cukup, pastikan cakupan cukup luas. Lalu isi celah, misalnya: "Kami ingin merekrut insinyur dengan pemikiran produk yang kuat." Kami tidak ingin terjadi sekelompok orang menulis banyak kode, lalu seluruh tim produk harus meninjau dan mengkalibrasi konsistensi produk. Kami ingin setiap orang memiliki kemampuan ini, hanya saja fokus pendalaman masing-masing perlu berubah.

Lenny: Jadi orang yang paling berharga sekarang adalah yang bisa mendorong dari ide hingga selesai, dan memiliki taste untuk tahu "ini bagus"?

Andrew Ambrosino: Ya, menurut saya ini perubahan paling inti saat ini. Ini juga mencerminkan pemahaman saya tentang hubungan IC (individual contributor) dan manajer. Bukan berarti manajemen akan hilang, atau semua orang hanya IC, tapi sekarang setiap orang sampai batas tertentu memegang kedua peran secara bersamaan.

Jika Anda IC, Anda tidak lagi mengetik kode karakter per karakter. Anda sebenarnya mengelola sesuatu, mengelola agents, mengelola pekerjaan yang diorganisir untuk menyelesaikan tugas bersama. Jika Anda manajer tim, pada dasarnya melakukan hal yang sama, hanya dengan granularitas manajemen yang berbeda.

Orang yang biasanya saya cari, selain memiliki kemampuan profesional yang solid, harus memiliki taste. Karena di dunia "token tak terbatas", kita tidak boleh memproduksi konten sampah. Anda harus memiliki kemampuan membedakan sinyal dan noise dari lautan konten.

Setiap kali orang bertanya berapa banyak orang di tim Codex, jawaban saya: "Sekitar 10 hingga beberapa ribu." Kedengarannya seperti lelucon, tapi sebenarnya, pekerjaan semua orang mengalir ke produk ini: riset model, penggunaan browser, kepribadian model, infrastruktur frontend, pengalaman pengguna, semua itu membentuk bagian dari produk.

Tapi di saat yang sama, kami tidak setiap hari menerima PR dari ribuan orang. Tim memiliki insinyur puluhan orang, jumlah desainer sekitar setengah dari insinyur, plus beberapa manajer produk, mayoritas adalah IC. Jangkauan tim besar, tapi lapisan manajemen tidak tebal. Ada banyak orang yang pernah mendirikan perusahaan, banyak yang bekerja dengan "pola pikir pendiri" di perusahaan besar, dan banyak orang dengan taste yang sangat baik.

Seluruh aplikasi Codex dibentuk oleh siklus dogfooding. Kami semua memiliki keinginan bersama: sebisa mungkin menyelesaikan pekerjaan di dalam aplikasi, meskipun untuk sementara bukan alat terbaik, karena hanya dengan begitu akhirnya bisa menjadi alat terbaik. Kami sering sengaja tidak memperbaiki beberapa proses internal, tapi membiarkan produk menjadi lebih baik sehingga bisa mendukung proses tersebut. Ini sebenarnya kondisi yang sangat tidak nyaman. Tapi minggu demi minggu, itu terus berubah.

Codex dirilis tiga bulan lebih awal akan mati, satu-satunya perbedaan adalah kemajuan model

Lenny: Dalam ritme perubahan yang begitu cepat, bagaimana Anda melakukan perencanaan? Seberapa jauh Anda melihat ke depan?

Andrew Ambrosino: Tidak ada yang revolusioner dalam perencanaan kami. Prinsip dasarnya, semakin dekat dengan waktu sekarang, perencanaan harus semakin spesifik. Bukan berarti tidak membuat rencana sembilan bulan, tapi rencana itu harus tetap sangat kabur. Karena presisi apa pun yang Anda tambahkan ke rencana sembilan bulan sekarang adalah presisi palsu, hanya buang-buang waktu.

Di sisi aplikasi produk, apa yang bisa Anda rencanakan di bulan November, mungkin masih benar di bulan Desember, tapi di bulan Februari sudah sama sekali tidak benar.

Di perusahaan saya sebelumnya, ketika kami mulai mendorong pengembangan fitur berdasarkan kemampuan model, proses produk yang ada pada dasarnya runtuh. Lalu berubah menjadi mendaftar semua arah yang menarik, membuat prototipe, menilai mana yang sudah layak sekarang, dan menunda sisanya. Setiap kali ada lompatan baru dalam kemampuan model, kami mengeluarkan kembali hal-hal yang ditunda dan mencobanya lagi. Karena apakah suatu fitur pada akhirnya cukup baik seringkali tidak bergantung pada bentuk fitur itu sendiri, melainkan seberapa cerdas modelnya. Banyak orang tidak puas dengan cara perencanaan saya. Tapi ini memang sangat sulit.

Lenny: Apakah ada contoh spesifik tentang seberapa pentingnya waktu (timing)?

Andrew Ambrosino: Ada cerita bagus tentang Codex. Saya sangat yakin bahwa aplikasi Codex yang kami rilis bulan Februari, jika sudah siap dirilis di bulan November, akan gagal total di pasar. Satu-satunya perbedaan adalah kemajuan model antara November dan Februari. Produk yang sama, bentuk yang persis sama, hasilnya sangat berbeda, hanya selisih beberapa bulan.

Lenny: Jadi yang sekarang tidak berhasil mungkin akan berhasil nanti? Harus menjaga ambisi yang lebih besar?

Andrew Ambrosino: Ya. Saya merekomendasikan orang untuk tidak mudah menilai "ini sekarang tidak berhasil, jadi ini fitur buruk", mungkin saja waktunya belum tiba.

Kembali ke rilis awal Codex, Codex web. Pada dasarnya Anda memberi model satu tugas, ia mengerjakannya, selesai lalu memberi hasil. Kedengarannya tidak radikal, tapi masalahnya ia tidak melakukannya dengan cukup baik, bentuknya terlalu maju.

Lalu Claude Code keluar, sepenuhnya lokal, tidak terhubung ke cloud, tidak berpura-pura menjadi AGI. Ia akan bertanya, akan menunggu di sana, Anda tidak bisa menitipkan seluruh hidup Anda padanya. Ia jauh lebih mudah digunakan, karena cocok dengan tingkat kemampuan model saat itu.

Kami terlalu "AGI" saat itu, saya sering memikirkan pelajaran ini. Dulu, kegagalan suatu produk di pasar sering memberi tahu banyak tentang bentuk produk atau cara komunikasi. Sekarang berbeda, Anda mungkin perlu merilis hal yang sama enam kali hingga berhasil, bentuknya mungkin tetap sama.

Browser dalam aplikasi juga demikian. Kami pernah memiliki versi yang berfungsi, kembali ke era Atlas, kami sudah memiliki agen yang menjalankan tugas di browser. Sebelumnya ada Operator di ChatGPT, yang tidak berhasil. Tapi jika Operator, Atlas, Codex, dan ChatGPT dirangkai, Anda akan melihat garis evolusi yang kontinu di antara mereka. Pada dasarnya fitur yang sama, hanya dengan perubahan tingkat kecerdasan, dirilis ulang berkali-kali, dan hasilnya berubah total.

Begitu suatu produk atau fitur sudah ada, orang mudah fokus pada berbagai detail dan optimasi kecil, dan memang seharusnya begitu. Tapi ini juga mengapa kami selalu mempertahankan budaya eksplorasi bottom-up. Karena kadang-kadang, seperti aplikasi Codex yang pernah mendisrupsi ChatGPT dengan cara tertentu, Codex sendiri mungkin di masa depan didisrupsi oleh inovasi baru. Anda tidak bisa mengharapkan tim yang sama untuk terus menghasilkan inovasi disruptif dan sekaligus fokus pada kualitas produk dan detail. Pada tahap tertentu, Anda harus merancang mekanisme agar kedua kemampuan ini bisa ada bersamaan.

Lenny: Apa visi Codex? Ke mana Anda akan membawanya?

Andrew Ambrosino: Pada bulan Januari dan Februari tahun ini, dalam pengujian internal, kami menemukan PMF yang jelas dalam alur kerja teknik dan riset. Tapi pada saat yang sama, orang dari pemasaran, komunikasi, keuangan, dan hukum juga menggunakan Codex, meskipun aplikasi ini tidak ramah bagi mereka; ia akan menunjukkan kode, meminta mereka menyetujui eksekusi alat pencarian baris perintah.

Kami mencoba menambahkan kemampuan Codex ke produk lain: aplikasi desktop ChatGPT, browser Atlas. Hasilnya hal yang paling menyebalkan terjadi: tidak ada yang mau meninggalkan aplikasi Codex untuk menggunakan produk yang konon dirancang khusus untuk mereka.

Pelajaran bagi kami adalah bahwa antara alat pengembang dan alat kerja pengetahuan umum, ada banyak kesamaan yang halus. Kami sangat percaya bahwa bentuk produk yang sedang kami bangun adalah bentuk yang tepat untuk menangani berbagai skenario vertikal yang dalam. Mulai dari yang sederhana, lalu secara bertahap menambah kompleksitas sesuai kebutuhan.

Ini bukan produk yang seperti "menggambar persegi panjang di layar, dan semua hal harus dilakukan di dalamnya". Lebih seperti markas besar, Anda mulai bekerja di sini, mengakhiri pekerjaan, mengelola otomatisasi, dan ia akan memanggil semua alat yang Anda butuhkan. Ada yang menyebut bentuk ini "super app", saya harap mereka tidak menyebutnya begitu, karena sekarang saya hampir setiap hari mendengar istilah itu.

Dan Shipper punya ide menarik, ia pikir di masa depan kita akan menggunakan alat SaaS "dari dalam ke luar" di Codex: Notion, Linear, Salesforce tidak akan Anda buka di browser, tapi agen akan mengoperasikannya untuk Anda di Codex. Dan kami memang melakukan itu: browser dalam aplikasi, ekstensi Chrome, computer use, semua ini adalah cara Codex berinteraksi dengan alat eksternal.

Salah satu contoh terbaik: pembuat video internal kami, Brent, menggunakan Codex untuk mengedit video rilis Codex. Codex bukan editor video, tidak memiliki UI itu. Tapi ia memahami Brent menggunakan Premiere Pro, dan bisa melakukan beberapa modifikasi melalui pengeditan file di belakang Premiere Pro. Ketika ia menyadari tidak bisa melakukan semuanya, ia menulis ekstensi Premiere Pro sendiri, menginstalnya ke Premiere Pro, lalu berbicara dengan Premiere Pro melalui ekstensi itu. Kami semua terkejut saat melihatnya.

Ini adalah pola yang bagus: alat profesional melakukan hal profesional. Codex tidak perlu menjadi editor video yang lebih baik; ia bisa berinteraksi dengan alat profesional secara mulus.

Tidak penting bisa menulis kode, yang penting bisa menghapus kode

Lenny: Dari menulis kode manual hingga AI menulis 100% kode, lalu ke agents dan loops. Bagaimana tim paling terdepan sekarang benar-benar bekerja?

Andrew Ambrosino: Loops? Itu minggu lalu.

Kami terus mendiskusikan "berapa persen produk ditulis oleh AI". Dengan standar tahun lalu, sekarang 100% kode ditulis oleh AI. Jadi pertanyaannya bukan lagi "berapa persen yang ditulis AI", melainkan "apakah kode ditulis dengan pengawasan atau tanpa pengawasan", ini dimensi yang sepenuhnya berbeda. Saya menyambut standar yang terus diperbarui, karena berarti kami membuat kemajuan produk.

Kami telah melakukan banyak eksplorasi dalam pengembangan perangkat lunak otonom, misalnya banyak harness engineering, seperti "bagaimana jika model secara otomatis melakukan garbage collection dan pembersihan basis kode di malam hari?"

Tapi saat ini semua model memiliki masalah: mereka selalu menambah kompleksitas. Jika ada peneliti yang mendengarkan: tolong, buat model belajar menghapus kode. Ketika Anda mencoba sepenuhnya menyerahkan pengembangan ke mode otonom, ini menjadi masalah serius, baik di tingkat manusia maupun di tingkat basis kode.

Hal yang sama berlaku untuk feature requests. Bagaimana Anda mengajarkan model untuk menilai fitur mana yang layak dikerjakan, mana yang harus diabaikan, mana yang harus digabungkan dan didefinisikan ulang? Dan bagaimana mengajarkan model untuk membangun abstraksi yang benar?

Kemampuan ini terus berkembang. Tapi saya tidak berpikir kita sudah mencapai tahap di mana kita bisa mengatur satu loop, membiarkan model secara otomatis "memperbaiki aplikasi", terus memantau Twitter, Slack, dan email, lalu menyelesaikan iterasi secara otonom. Meskipun, kami memang sedang mencoba mewujudkannya.

Lenny: Apakah Anda pikir kita akan mencapai tahap itu? Menetapkan satu tujuan: "menang"?

Andrew Ambrosino: "/goal hasilkan 1 miliar dolar untukku." Saya tidak tahu. Saya tidak akan mengatakan tidak akan pernah atau akan selalu seperti ini.

Lenny: Sebagai kepala produk dan teknik, bagaimana Anda sendiri menggunakan AI untuk bekerja?

Andrew Ambrosino: Saya merasa mungkin sekarang saya punya pekerjaan terbaik di dunia.

Saat mulai mengerjakan Codex, tujuan pribadi saya adalah membuatnya cukup baik sehingga saya bisa menggunakannya untuk menulis kode Codex. Itu adalah siklus dogfooding yang sangat erat. Saya tidak bisa melakukan sesuatu, perbaiki, lalu saya bisa, lalu bisa lebih banyak.

Lalu peran saya berubah. Saya perlu lebih banyak melakukan product discovery, mencari tahu apa yang dilakukan tim, memperbaiki hal yang melenceng. Codex menjadi alat saya untuk melakukan itu. "Bantu saya buat spreadsheet untuk mengatur data ini." "Bantu saya lakukan riset mendalam internal, lihat eksplorasi apa yang pernah dilakukan di arah ini sebelumnya."

Rangkaian rilis bulan Mei: browser dalam aplikasi, computer use, pembuatan artefak. Itu pertama kalinya kami menggunakan "vibe coordination" untuk mengelola rilis. Saya punya satu dokumen Notion mencatat semua tugas, lalu menggunakan Codex untuk secara otomatis mengumpulkan kemajuan dari PR dan saluran Slack, memperbarui tracker status. Saat itu saya merasa ini adalah cara paling canggih untuk mengelola rilis produk.

Sekarang setiap pagi, saya membaca laporan harian yang dihasilkan Codex untuk saya, menyaring dari 3000 saluran Slack yang saya ikuti hal-hal yang perlu perhatian saya. Saya bisa membalas "beri saya lima pertanyaan, saya akan jawab." Ia akan menyesuaikan diri. Saya bilang "lain kali jalankan, kurangi perhatian pada alur kerja ini" atau "ini terjadi tapi tidak muncul di laporan, pastikan lain kali tertangkap", ia akan memperbarui cara notifikasi, menyesuaikan fokus perhatian.

Lenny: Bagaimana pengaturannya? Seperti apa alur kerjanya?

Andrew Ambrosino: Masih dalam tahap penemuan. Cuma buat tugas terjadwal: "Periksa saluran Slack saya, ini hal yang saya pedulikan, kelompokkan seperti ini, ini beberapa konteks." Beberapa kali pertama mungkin perlu bimbingan. Untungnya saya tidak perlu mencari cara mengedit instruksi; saya langsung bicara "lain kali ubah ini untukku", dan ia memperbarui.

Tapi saya pikir ini juga masalah inti dari bentuk chatbot. Saya tahu cara mengaturnya karena bagi saya ini adalah product discovery. Tapi jika Anda tidak bekerja di OpenAI, tidak mengembangkan ini, Anda tidak akan mau repot mencari tahu. Kita perlu memikirkan bagaimana membuat bentuk ini bisa digunakan oleh orang biasa.

Lenny: Saya sendiri menggunakan Codex untuk membuat otomatisasi filter spam. Salah satu langkahnya harus ke Google Cloud Console mengatur sejumlah API trigger, antarmukanya sangat menyebalkan. Saya suruh Codex melakukannya, dan ia langsung mengambil alih komputer saya, menggunakan fitur computer use.

Andrew Ambrosino: Ia berkata: "Saya tidak peduli apakah Anda punya konektor atau tidak, bung, saya langsung mulai mengeklik."

Memisahkan batas antara konektor, browser dalam aplikasi, ekstensi Chrome, dan computer use, adalah hal yang sangat menarik. Seringkali, batas-batas ini hanya diraba-raba berdasarkan perasaan.

Saya pikir alur kerja pribadi ini sangat menarik. Semua orang mencoba berbagai macam hal, masing-masing akan membangun sistem yang sangat berbeda. Tapi perlahan, beberapa pola umum akan muncul. Lalu kami akan menyadari: "Ini harus menjadi pengalaman tingkat pertama dalam produk."

Misalnya memori (memory). Banyak orang mengatur basis pengetahuan Obsidian atau ruang Notion untuk membangun istana pikiran mereka. Anda seharusnya tidak perlu melakukannya sendiri; harus ada fitur memori yang cukup umum yang melakukannya untuk Anda. Kami terus menyaring: mana yang efektif untuk individu tetapi harus tetap di tingkat pribadi, mana yang harus masuk ke produk sebagai komponen dasar.

Lenny: Orang di luar hanya melihat Anda menang. Pasti ada hal yang tidak berhasil?

Andrew Ambrosino: Lucu Anda menggambarkannya seperti itu. Ini pertama kalinya saya merasa tidak gagal.

Saya dulu mendirikan startup selama bertahun-tahun, pada akhirnya hampir membubarkan dan menjual perusahaan. Bekerja di industri yang sangat diatur, seluruh proses terasa seperti kegagalan terus-menerus. Lalu pergi ke startup lain, mengerjakan alat AI di industri tertutup dan diatur lainnya, juga gagal berulang kali. Saya sebenarnya banyak gagal. Kadang hanya masalah waktu, keterampilan, semangat, dan peluang pasar yang kebetulan selaras.

Bahkan dalam proyek yang menggabungkan Codex dan ChatGPT ini, ada banyak kegagalan kecil. Kami bilang "seharusnya seperti ini", kirim ke Slack, langsung 2000 pesan mengatakan betapa bodohnya kami. Ini yang saya suka dari OpenAI: orang akan langsung memberi tahu, tanpa ampun terhadap kegagalan produk internal, itulah mengapa produk eksternal cukup bagus. Sebelum mencapai posisi saya sekarang, saya gagal sekitar 10 hingga 15 tahun. Jadi setiap hari saya masih sedikit terkejut bahwa semuanya berjalan lancar.

Lenny: Apa saran terakhir untuk pembaca?

Andrew Ambrosino: Jangan "menikah seumur hidup" dengan alur kerja Anda saat ini. Yang benar-benar harus dipertahankan adalah hasil yang hanya bisa Anda berikan secara unik. Lalu, teruslah mencoba mengubah proses Anda. Jika keterampilan yang paling Anda banggakan adalah "Saya paling mengerti auto layout Figma", apa yang Anda lakukan? AI juga akan menjadi lebih baik dari Anda. Temukan hal yang layak dilakukan, lalu cari cara untuk melakukan hal itu.