Catatan Editor: Artikel ini berasal dari anggota Hubungan Pengembang OpenAI, Dominik Kundel, yang merangkum pengalaman menggunakan fitur Codex "goal mode / /goal". Ini tidak membahas trik prompt biasa, melainkan perubahan peran yang sedang terjadi dalam alat pemrograman AI: Codex tidak lagi sekadar asisten kode yang merespons instruksi satu putaran, tetapi mulai menjadi Agen eksekutif yang dapat terus melaju dengan tujuan yang jelas.
Dalam mode /goal, yang benar-benar penting bukanlah menulis permintaan yang panjang dan rinci, melainkan menetapkan standar keluar yang jelas dan dapat diverifikasi untuk Codex. Misalnya, "Waktu penyebaran berkurang 30%", "Cakupan tes mencapai 100% parity", "LCP turun di bawah 2,5 detik". Indikator-indikator ini memungkinkan Codex menilai apakah tugas telah selesai, juga menghindarkannya dari mencoba-coba tanpa batas dalam tujuan yang samar. Pada saat yang sama, pengguna juga perlu memberikan arahan, alat, dan lingkungan nyata yang cukup, agar Codex dapat mengukur kemajuan, memverifikasi hasil, bukan hanya menyelesaikan solusi yang tampak layak dalam kondisi lokal atau hipotetis.
Artikel ini khususnya mengingatkan bahwa tugas-tugas visual paling mudah membuat Codex terjebak dalam lumpur detail. Daripada menuntut "replikasi 100% tingkat piksel", lebih baik menguraikan tujuan visual menjadi daftar fungsionalitas, spesifikasi sistem desain, dan indikator yang dapat dievaluasi. Untuk tugas jangka panjang yang berlangsung berjam-jam bahkan berhari-hari, juga perlu melacak secara berkelanjutan melalui commit, draft PR, dokumen kemajuan, pembaruan Slack, atau side chat, untuk menghindari akhirnya hanya mendapatkan setumpuk perubahan yang tidak dapat dilacak.
Nilai tambah informasi artikel ini terletak pada definisinya ulang /goal sebagai "mekanisme manajemen tugas jangka panjang". Ketika AI dapat mengeksekusi puluhan bahkan ratusan jam secara berurutan, kemampuan inti pengembang juga berubah: tidak hanya membuat AI menghasilkan kode, tetapi juga mendefinisikan tujuan, membangun sistem pengukuran, mengonfigurasi lingkungan eksekusi, dan pada akhirnya menyelesaikan tinjauan dan evaluasi. Dengan kata lain, pemrograman AI sedang bergeser dari "menulis prompt" menuju "mengelola pelaku rekayasa yang bekerja terus-menerus".
Berikut adalah teks aslinya:
Kami meluncurkan mode tujuan (goal mode, atau /goal) untuk membantu Anda membuat Codex terus mendukung hasil yang spesifik. Setelah Anda menetapkan suatu tujuan, Codex akan terus bekerja hingga tujuan tercapai — baik memerlukan beberapa jam, maupun beberapa hari. Beberapa orang telah membuat Codex bekerja lebih dari 120 jam berturut-turut untuk tujuan yang sama.
Mode tujuan sangat kuat. Untuk memaksimalkan penggunaannya, ada 7 hal yang perlu diperhatikan saat menggunakan /goal.
Menetapkan Standar yang Jelas dan Dapat Diverifikasi
Prompt yang Anda masukkan saat mengaktifkan mode tujuan dapat berfungsi sebagai prompt awal, dan yang lebih penting, akan menjadi standar keluar untuk tujuan ini. Codex akan memeriksa setelah setiap putaran kerja: apakah tujuan ini sudah selesai.
Oleh karena itu, prompt tujuan Anda sebaiknya tidak ditulis terlalu panjang, tetapi fokus pada standar yang jelas: dalam kondisi apa tujuan ini dianggap tercapai.
Dalam banyak kasus, tujuan yang baik sebaiknya mengandung indikator numerik yang jelas, untuk membantu model menilai apakah sudah selesai. Contohnya:
"Mengurangi waktu build dan deployment sebesar 30%."
"Migrasikan fitur ini dari TypeScript ke Rust, dan mencapai 100% konsistensi tes."
"Optimalkan kerangka aplikasi, sehingga Largest Contentful Paint (LCP, metrik pengukuran kecepatan muat konten utama halaman) di lingkungan produksi di bawah 2,5 detik."
Prompt ini tidak harus selalu mengandung angka, namun biasanya angka akan membuat langkah-langkah selanjutnya lebih mudah.
Jika Anda belum yakin bagaimana mendefinisikan tujuan, atau ingin melakukan brainstorming proyek ini bersama Codex terlebih dahulu, tidak perlu memulai percakapan dengan mode tujuan sejak awal.
Codex dapat menetapkan tujuannya sendiri. Anda dapat memulai percakapan normal terlebih dahulu, dan saat Anda siap membuat Codex mulai mengeksekusi, baru minta Codex menetapkan tujuan berdasarkan diskusi sebelumnya.
Anda juga dapat mengedit tujuan kapan saja: klik tombol edit di aplikasi Codex, atau gunakan /goal lagi di CLI.
Berikan Panduan Sebanyak Mungkin
Prompt seperti "Mengurangi waktu build dan deployment sebesar 30%" terdengar keren, dan mungkin membuat Codex menemukan beberapa solusi kreatif. Namun jika Anda sudah kurang lebih tahu di mana letak masalahnya, prompt seperti ini juga dapat membuat Codex mengambil jalan yang salah.
Jadi, jika memungkinkan, lebih baik beri tahu Codex di mana harus mulai memeriksa, alat apa yang dapat digunakan untuk mencapai tujuan, atau berikan petunjuk lain, agar tidak terjebak ke arah yang salah.
Contohnya, rekan saya @reach_vb melakukan hal ini dalam sebuah eksperimen: dia memberi tahu Codex bahwa ia dapat menggunakan browser Chrome untuk masuk ke Google Colab, dan menjelaskan beberapa batasan yang dapat diterima, misalnya saat meminta Codex melatih model, ia dapat membuat dataset sendiri.
Demikian pula, jika Anda ingin memperpendek waktu build, dan sudah tahu di bagian mana sebagian besar waktu dihabiskan, lebih baik arahkan Codex ke area itu terlebih dahulu dalam prompt.
Cara lain adalah, Anda dapat meminta Codex melakukan penelitian awal dalam mode rencana (plan mode), dan membuat file perencanaan untuk mencatat solusi potensial. Kemudian, minta tujuan Anda merujuk pada rencana ini.
Buat Kemajuan yang Terukur
Jika tujuan Anda ambisius, atau Codex memiliki banyak cara untuk mendekati tujuan secara bertahap, maka sangat penting: Anda memberikan alat kepada Codex untuk mengukur kemajuan.
Untuk beberapa tugas, hal ini mungkin sudah terbukti secara alami. Misalnya mengoptimalkan waktu build, meningkatkan cakupan tes, karena Codex biasanya sudah dapat menggunakan alat terkait, atau secara alami akan membuat alat-alat tersebut.
Namun untuk tujuan lain, sebaiknya lakukan brainstorming terlebih dahulu dengan Codex: alat apa yang membantu menilai kemajuan? Atau berikan beberapa petunjuk, agar tahu bagaimana mengonfirmasi apakah sedang mendekati tujuan. Misalnya, membuat alat perbandingan perbedaan visual untuk dua tangkapan layar, atau membuat set evaluasi untuk agen yang sedang Anda debug.
Saya pernah meminta Codex mereplikasi beberapa komponen berdasarkan video, saat itu Codex membuat sendiri alat untuk membandingkan tangkapan layar dan memeriksa perbedaan. Kemudian, ia juga terus mengulangi alat ini, menambahkan mode perbandingan perbedaan yang berbeda.
Tergantung pada tugasnya, Anda juga perlu mempertimbangkan apakah ada standar tambahan yang perlu diukur atau diperiksa. Jika tidak, Codex mungkin menganggap tugas sudah selesai, tetapi menurut Anda sebenarnya belum lengkap.
Misalnya, Codex mungkin untuk "replikasi pixel-perfect" suatu UI, langsung memotong gambar referensi desain dan menyematkannya ke dalam halaman; atau untuk mencapai tingkat kelulusan tes 100%, malah mengurangi cakupan tes. Ini bukan cara penyelesaian yang sebenarnya Anda inginkan.
Buat Lingkungan yang Nyata
Jika Anda ingin Codex benar-benar mencapai kemajuan yang efektif menuju tujuan, ia perlu berjalan dalam lingkungan yang cukup nyata.
Dalam praktiknya, ini berarti: jika Anda ingin mengoptimalkan waktu penyebaran atau masalah latensi, Codex harus dapat mengakses lingkungan penyebaran dan pengujian, dan lingkungan ini harus mensimulasikan lingkungan produksi sebanyak mungkin. Artinya menggunakan teknologi stack yang sama, konfigurasi switch yang sama, serta basis data yang serupa.
Contohnya, kami pernah melakukan debug optimisasi waktu build dan deployment developers.openai.com. Saat itu kami sudah menggunakan deployment preview, sehingga Codex dapat memanfaatkan lingkungan preview ini untuk deployment, dan melihat log terkait. Namun masalahnya, deployment preview kami dibandingkan dengan lingkungan produksi penuh, menonaktifkan beberapa jalur build.
Oleh karena itu, Codex akhirnya harus melakukan deployment manual, mendeploy kode ke lingkungan yang lebih mendekati konfigurasi produksi, agar dapat benar-benar memeriksa masalah.
Demikian pula, Anda juga dapat membuat Codex menggunakan computer use (kemampuan model mengoperasikan antarmuka aplikasi nyata) untuk menguji aplikasi sebenarnya. Untuk mengoptimalkan beberapa masalah performa di iOS, @dimillian bahkan menggunakan perangkat fisik, untuk mendapatkan lingkungan pengujian yang paling akurat.
Atur Tujuan Visual dengan Hati-hati
Memberikan tujuan visual kepada Codex, misalnya "replikasi UI ini 100% pixel-perfect berdasarkan gambar ini", memang sangat menarik. Namun tergantung pada pengaturan spesifiknya, ini juga dapat menimbulkan masalah.
Jika Anda tidak memberikan panduan dan batasan yang sesuai, Codex mungkin akan semakin terperosok dalam detail tertentu, malah mengabaikan tujuan keseluruhan. Misalnya, jika gambar referensi berisi beberapa elemen grafis, dan Anda mengharapkan Codex menghasilkan elemen-elemen ini — baik ikon SVG maupun gambar — ia mungkin menghabiskan banyak energi untuk "bagaimana mereplikasi bahan-bahan ini secara tepat", daripada menguraikan keseluruhan masalah dengan benar.
Selain itu, Codex memerlukan alat untuk melakukan perbandingan visual dengan benar. Ini berarti lebih banyak input gambar, konsumsi token keseluruhan yang lebih tinggi, tetapi belum tentu memberikan cara sederhana bagi Codex untuk mengidentifikasi peluang perbaikan yang bernilai.
Jadi, gambar biasanya lebih cocok sebagai konteks tujuan, bukan satu-satunya standar penyelesaian. Anda harus mencari cara lain untuk membuat Codex menilai apakah tujuan telah tercapai, misalnya daftar fungsionalitas, spesifikasi implementasi, kesesuaian dengan sistem desain, dll.
Lacak Kemajuan
Jika Codex akhirnya bekerja di latar belakang selama berjam-jam bahkan berhari-hari, bahkan berjalan di mesin lain, Anda mudah lupa sejauh mana progresnya, pekerjaan apa yang telah dilakukan.
Tergantung pada tujuan yang berbeda, saya menemukan beberapa cara berikut ini membantu:
· Minta Codex melakukan commit kode pada titik-titik penting, dan push ke draft PR. Terutama saat Anda mengerjakan website, dan memiliki deployment preview, ini akan sangat berguna.
· Minta Codex memperbarui dokumen deliverable untuk manajemen. Ini bisa berupa file HTML, yang dapat Anda buka terus di dalam browser aplikasi; atau halaman yang dideploy melalui Sites untuk dilihat tim; bisa berupa grafik progres yang dirender, atau hanya file Markdown biasa.
Instruksikan Codex untuk secara aktif mempublikasikan pembaruan kemajuan. Anda juga dapat menulis ini ke dalam tujuan: minta Codex mengirim pembaruan ke saluran Slack saat mencapai kemajuan penting, atau tempat lain di mana Anda ingin mencatat kemajuan.
Gunakan jendela chat lain untuk menanyakan status. Jika Anda hanya ingin mengetahui status saat ini dengan cepat, jalankan /side untuk memulai chat samping baru, dan ajukan pertanyaan di sana. Karena akan bercabang dari thread saat ini, ia memiliki semua konteks hingga saat ini, tetapi siklus hidupnya singkat.
Metode alternatif lain di aplikasi Codex adalah: buka chat baru biasa, minta Codex membaca thread tujuan lain, dan jawab pertanyaan Anda. Ini akan sangat kuat terutama jika Anda meminta Codex menetapkan tugas otomatis, yang memeriksa kemajuan secara berkala.
Bersihkan dan Konfirmasi Hasil Akhir
Bagus, tujuan akhirnya selesai! Sekarang apakah langsung bisa menyerahkan hasilnya ke tim, lalu selesai?
Biasanya, terutama dalam tugas optimisasi, saya merasa sangat membantu jika Codex meninjau dan memeriksa kembali pekerjaan yang telah diselesaikannya. Anda dapat menjalankan /review terlebih dahulu untuk melakukan tinjauan kode lokal, tetapi juga patut membuat Codex merenungkan lebih dalam: jalur apa yang telah dicoba untuk mencapai tujuan? Upaya mana yang efektif? Upaya mana yang tidak efektif? Kemudian bersihkan kode berdasarkan hal tersebut.
Karena Codex akan terus bekerja hingga mencapai tujuan, ia mungkin telah mencoba beberapa metode yang kurang baik, bahkan tidak efektif sama sekali, dan perubahan sisa ini mungkin masih tersisa dalam kode akhir.
Beri goal untuk tugas berikutnya juga
Fitur tujuan Codex adalah alat yang sangat kuat, dapat membantu Anda menyelesaikan beberapa tantangan rekayasa yang paling bermakna. Namun hanya ketika Anda menyediakan lingkungan dan instruksi yang benar, ia dapat mencapai tujuan dengan lebih efisien.
Apa yang telah Anda lakukan dengan /goal?










