Judul asli: Panduan untuk /goal
Penulis asli: @dkundel, anggota Tim Pengembang OpenAI
Diterjemahkan: Peggy

Catatan editor: Artikel ini berasal dari anggota Tim Pengembang OpenAI Dominik Kundel, yang merangkum pengalaman penggunaan fitur Codex「goal mode / /goal」. Artikel ini tidak membahas teknik prompt biasa, melainkan perubahan peran yang sedang terjadi dalam alat pemrograman AI: Codex tidak lagi sekadar asisten kode yang merespons perintah satu putaran, tetapi mulai menjadi Agen eksekusi yang dapat terus maju berdasarkan tujuan yang jelas.

Dalam mode /goal, yang benar-benar penting bukanlah menulis kebutuhan secara panjang dan detail, tetapi menetapkan standar keluar yang jelas dan dapat diverifikasi untuk Codex. Misalnya, "Mengurangi waktu deployment sebesar 30%", "Cakupan pengujian mencapai 100% parity", "LCP turun di bawah 2,5 detik". Indikator-indikator ini memungkinkan Codex menilai apakah tugas sudah selesai, dan juga mencegahnya melakukan trial and error tanpa batas dalam target yang kabur. Pada saat yang sama, pengguna perlu menyediakan arahan, alat, dan lingkungan nyata yang cukup agar Codex dapat mengukur kemajuan dan memverifikasi hasil, bukan hanya menyelesaikan solusi yang tampaknya layak secara lokal atau dalam kondisi asumsi.

Artikel ini juga mengingatkan bahwa tugas visual paling rentan membuat Codex terjebak dalam detail. Daripada meminta "reproduksi pixel-perfect 100%", lebih baik membagi tujuan visual menjadi daftar fungsi, standar sistem desain, dan indikator yang dapat dievaluasi. Untuk tugas jangka panjang yang berlangsung berjam-jam atau berhari-hari, juga perlu dilakukan pelacakan secara berkelanjutan melalui commit, draft PR, dokumen progres, pembaruan Slack, atau obrolan sampingan, agar tidak berakhir dengan sekumpulan perubahan yang tidak dapat dilacak.

Informasi utama dari artikel ini adalah bahwa mode /goal didefinisikan ulang sebagai "mekanisme manajemen tugas jangka panjang". Ketika AI dapat melakukan eksekusi berjam-jam bahkan berpuluh-puluh jam secara berkelanjutan, kemampuan pengembang pun berubah: bukan hanya membuat AI menghasilkan kode, tetapi mendefinisikan tujuan, membangun sistem pengukuran, mengonfigurasi lingkungan eksekusi, dan akhirnya melakukan review serta refleksi. Dengan kata lain, pemrograman AI sedang bertransformasi dari "menulis prompt" menjadi "mengelola eksekutor proyek yang terus bekerja".

Berikut adalah teks aslinya:

Kami meluncurkan mode tujuan (goal mode, atau /goal), untuk membantu Anda mendorong Codex menuju hasil tertentu secara berkelanjutan. Setelah Anda menetapkan sebuah tujuan, Codex akan terus bekerja sampai tujuan tercapai—baik itu membutuhkan beberapa jam, maupun beberapa hari. Sudah ada yang membuat Codex bekerja secara berkelanjutan lebih dari 120 jam untuk satu tujuan yang sama.

Mode tujuan sangat kuat. Untuk memaksimalkan penggunaannya, ada 7 hal yang perlu diperhatikan saat menggunakan /goal.

Tetapkan standar yang jelas dan dapat diverifikasi

Saat Anda mengaktifkan mode tujuan dan memasukkan prompt, prompt tersebut bisa digunakan sebagai prompt awal, tetapi yang lebih penting adalah, prompt tersebut akan menjadi standar keluar dari tujuan ini. Codex akan memeriksa setelah setiap putaran kerja: apakah tujuan ini sudah tercapai.

Oleh karena itu, prompt tujuan Anda tidak perlu terlalu panjang, tetapi harus fokus pada standar yang jelas: dalam kondisi apa, tujuan ini dianggap tercapai.

Dalam banyak kasus, sebuah tujuan yang baik mengandung indikator angka yang jelas, agar model bisa menilai apakah sudah selesai. Contohnya:

「Mengurangi waktu pembangunan dan deployment sebesar 30%.」

「Memigrasi fitur ini dari TypeScript ke Rust dan mencapai 100% kesesuaian pengujian.」

「Mengoptimalkan kerangka kerja aplikasi agar Largest Contentful Paint (LCP) di bawah 2,5 detik.」

Prompt ini tidak selalu harus mengandung angka, tetapi biasanya angka akan memudahkan langkah selanjutnya.

Jika Anda masih ragu bagaimana mendefinisikan tujuan, atau ingin melakukan brainstorming bersama Codex terlebih dahulu, Anda tidak perlu langsung memulai mode /goal.

Codex bisa menetapkan tujuan sendiri. Anda bisa memulai percakapan biasa, dan saat siap agar Codex mulai menjalankan, biarkan Codex menetapkan tujuan berdasarkan diskusi sebelumnya.

Anda juga bisa mengedit tujuan kapan saja: klik tombol edit di aplikasi Codex, atau gunakan lagi /goal di CLI.

Berikan panduan sebanyak mungkin

Seperti prompt "Mengurangi waktu build dan deployment sebesar 30%", terdengar keren dan mungkin akan memancing solusi kreatif dari Codex. Tapi jika Anda sudah tahu secara kasar di mana masalahnya, prompt seperti ini bisa malah membingungkan Codex.

Jadi, jika memungkinkan, lebih baik beritahu Codex dari mana harus mulai troubleshooting, alat apa yang bisa digunakan, atau berikan petunjuk lain agar tidak tersesat ke arah yang salah.

Contohnya, rekan saya @reach_vb pernah melakukan ini: dia memberi tahu Codex bahwa bisa menggunakan Chrome untuk masuk ke Google Colab, dan menjelaskan beberapa batasan yang bisa diterima, misalnya saat melatih model, biarkan Codex menghasilkan dataset sendiri.

Begitu juga, jika Anda ingin mempercepat waktu build dan sudah tahu bagian mana yang paling memakan waktu, sebaiknya arahkan Codex ke area tersebut dalam prompt.

Alternatif lainnya, Anda bisa membiarkan Codex melakukan riset awal dalam mode perencanaan (plan mode), dan membuat file rencana yang mencatat solusi potensial. Kemudian, referensikan rencana ini dalam tujuan Anda.

Buat kemajuan yang terukur

Jika tujuan Anda sangat ambisius, atau Codex memiliki banyak cara untuk mendekati tujuan secara bertahap, hal yang sangat penting adalah: berikan alat ukur kemajuan.

Untuk beberapa tugas, hal ini mungkin sudah otomatis. Misalnya, mengoptimalkan waktu build, meningkatkan cakupan pengujian, karena Codex biasanya sudah bisa menggunakan alat terkait, atau secara alami akan membuat alat tersebut.

Namun untuk tujuan lain, sebaiknya diskusikan dulu dengan Codex: alat apa yang membantu menilai kemajuan? Atau berikan petunjuk agar Codex tahu bagaimana mengonfirmasi bahwa dirinya semakin dekat ke tujuan. Misalnya, buat alat perbandingan visual untuk dua screenshot, atau buat kumpulan evaluasi untuk agen yang sedang Anda debug.

Saya pernah meminta Codex mereplikasi beberapa komponen dari sebuah video, dan dia membuatkan alat untuk membandingkan screenshot dan mendeteksi perbedaan. Kemudian, dia terus mengembangkan alat ini, menambahkan mode perbandingan berbeda.

Gambar: Screenshot yang dibuat Codex untuk membandingkan dua frame visual.

Tergantung tugasnya, Anda juga perlu mempertimbangkan apakah ada standar tambahan yang perlu diukur atau diperiksa. Kalau tidak, Codex mungkin menganggap tugas sudah selesai padahal sebenarnya belum.

Misalnya, Codex mungkin melakukan "reproduksi pixel-perfect" UI tertentu dengan memotong gambar referensi dan menyematkannya ke halaman; atau, demi mencapai 100% tingkat keberhasilan pengujian, malah mengurangi cakupan pengujian. Ini bukan cara yang sebenarnya Anda inginkan.

Buat lingkungan nyata

Jika Anda ingin Codex benar-benar membuat kemajuan yang berarti menuju tujuan, ia harus berjalan di lingkungan yang cukup nyata.

Dalam praktiknya, ini berarti: jika Anda ingin mengoptimalkan waktu deployment atau latensi, Codex harus bisa mengakses lingkungan deployment dan pengujian, dan lingkungan ini harus sedekat mungkin dengan lingkungan produksi. Yakni, menggunakan stack teknologi yang sama, konfigurasi yang sama, dan database yang serupa.

Contohnya, saat kami melakukan debugging pengoptimalan waktu build dan deployment di developers.openai.com, kami sudah menggunakan preview deployment, sehingga Codex bisa memanfaatkan lingkungan tersebut untuk melakukan deployment dan melihat log terkait. Tapi masalahnya, deployment preview dan lingkungan produksi lengkap memiliki jalur build yang berbeda.

Oleh karena itu, Codex akhirnya harus melakukan deployment manual ke lingkungan yang lebih mendekati konfigurasi produksi agar bisa benar-benar memeriksa masalah.

Begitu juga, Anda bisa membiarkan Codex menggunakan kemampuan operasi nyata (computer use) untuk menguji aplikasi secara langsung. Untuk mengoptimalkan performa di iOS, @dimillian bahkan menggunakan perangkat fisik agar mendapatkan lingkungan pengujian yang paling akurat.

Hati-hati dalam menetapkan target visual

Memberikan Codex target visual, seperti "reproduksi pixel-perfect UI ini", memang menggoda. Tapi, tergantung pengaturan dan batasan, ini bisa menimbulkan masalah.

Tanpa panduan dan batasan yang tepat, Codex bisa terjebak dalam detail dan mengabaikan tujuan utama. Misalnya, jika referensi gambar berisi elemen grafis tertentu, dan Anda mengharapkan Codex mereproduksi elemen tersebut—baik ikon SVG maupun gambar—dia bisa menghabiskan banyak waktu untuk "menyamakan" elemen tersebut, bukan memecah masalah secara keseluruhan.

Selain itu, Codex membutuhkan alat untuk melakukan perbandingan visual yang benar. Ini berarti input gambar lebih banyak, token yang digunakan lebih tinggi, dan tidak selalu ada cara sederhana agar Codex bisa mengenali peluang perbaikan yang benar-benar penting.

Jadi, gambar biasanya lebih cocok sebagai konteks tujuan, bukan sebagai standar penyelesaian tunggal. Anda harus mencari cara lain agar Codex bisa menilai apakah tujuan sudah tercapai, seperti daftar fungsi, standar implementasi, atau kesesuaian dengan sistem desain.

Pantau kemajuan

Jika Codex bekerja di belakang layar selama berjam-jam atau berhari-hari, bahkan di mesin lain, mudah lupa di mana kemajuannya dan apa yang sudah dilakukan.

Berdasarkan berbagai tujuan, saya menemukan beberapa cara berikut sangat membantu:

· Meminta Codex melakukan commit dan push ke draft PR pada titik-titik penting. Terutama saat mengerjakan website dan ada pratinjau deployment, ini sangat berguna.

· Meminta Codex memperbarui dokumen deliverables untuk manajemen. Bisa berupa file HTML yang bisa dibuka di browser, halaman yang dihosting di Sites untuk tim, grafik progres yang dirender, atau sekadar file Markdown biasa.

· Instruksikan Codex untuk secara aktif mengirim update kemajuan. Anda bisa memasukkan ini ke dalam tujuan: agar Codex mengirimkan update ke Slack saat ada kemajuan penting, atau ke tempat lain yang Anda inginkan.

· Gunakan chat lain untuk menanyakan status. Jika ingin cepat tahu posisi saat ini, jalankan /side untuk membuka obrolan sampingan dan bertanya di sana. Karena percakapan ini bercabang dari thread utama, ia memiliki konteks lengkap sampai saat ini, tapi bersifat sementara.

· Alternatif lain di aplikasi Codex adalah membuka chat baru dan membiarkan Codex membaca thread tujuan lain, lalu menjawab pertanyaan Anda. Jika Anda mengatur otomatisasi untuk cek kemajuan secara berkala, ini bisa sangat kuat.

Bersihkan dan konfirmasi hasil akhir

Bagus, tujuan akhirnya tercapai! Sekarang, apakah saatnya langsung menyerahkan hasil ke tim dan selesai?

Biasanya, terutama untuk tugas optimasi, saya temukan sangat membantu jika Codex mereview dan mengaudit pekerjaan yang sudah dilakukan. Anda bisa menjalankan /review untuk review kode lokal, tetapi juga baik agar Codex melakukan refleksi mendalam: jalur apa yang sudah dicoba, mana yang efektif, mana yang tidak, dan kemudian membersihkan kode berdasarkan itu.

Karena Codex akan terus bekerja sampai mencapai tujuan, ia mungkin mencoba metode yang kurang efektif atau bahkan tidak berguna, dan perubahan tersebut bisa tertinggal di kode akhir.

Buat goal untuk tugas berikutnya

Fungsi tujuan dari Codex adalah alat yang sangat kuat untuk membantu mengatasi tantangan engineering yang paling bermakna. Tapi, hanya jika Anda menyediakan lingkungan dan instruksi yang tepat, ia bisa lebih efisien mencapai target.

Apa yang sudah Anda lakukan dengan /goal?

[Link asli]

Klik untuk mengetahui lebih banyak tentang Low-Tempo BlockBeats yang sedang membuka posisi

Selamat bergabung dengan komunitas resmi BlockBeats:

Telegram langganan: https://t.me/theblockbeats

Telegram diskusi: https://t.me/BlockBeats_App

Akun resmi Twitter: https://twitter.com/BlockBeatsAsia