Cara Memanfaatkan Goals di Codex

• Goals adalah fitur tujuan persisten (persistent objective) yang membuat thread Codex terus bekerja menuju hasil yang telah ditentukan selama beberapa turn
• Cocok untuk tugas seperti profiling, patching, benchmarking, reproduksi flaky test, dan audit berbasis bukti yang sulit ditangani dengan satu prompt saja
• Dengan mendefinisikan hasil (outcome), sarana verifikasi (verification surface), dan batasan (constraints), Codex dapat menentukan sendiri apakah tugas sudah selesai berdasarkan bukti
• Siklus hidupnya dapat dikendalikan dengan perintah /goal, /goal pause, /goal resume, /goal clear, didukung mulai Codex 0.128.0
• Ini adalah struktur completion contract yang dibatasi pada cakupan thread, dan inti utamanya adalah persistensi di bawah kendali pengguna, bukan eksekusi otonom tanpa batas

---

Definisi Goals dan latar belakang pengenalannya

• Goals adalah fitur yang memberi Codex completion condition yang mendefinisikan apa yang harus benar, bagaimana memeriksa keberhasilan, dan batasan apa yang harus dipertahankan
• Codex sudah bekerja dengan baik untuk tugas coding dengan cakupan yang jelas seperti meninjau repositori, memperbaiki bug, menambahkan test, menjelaskan kegagalan, atau mengimplementasikan perubahan yang terfokus
• Goals cocok untuk pekerjaan di mana langkah berikutnya bergantung pada apa yang dipelajari Codex di tengah proses
  • Seperti profiling, patching, benchmarking, reproduksi flaky test, atau mengubah pertanyaan riset menjadi audit berbasis bukti
• Jenis pekerjaan ini tidak membutuhkan prompt yang lebih besar, melainkan tujuan persisten
• Saat Goal aktif, Codex mempertahankan tujuan, mengevaluasi apakah sudah selesai, dan memilih tindakan berikutnya tanpa perlu tujuan diulang pada setiap hasil antara
• Goal bukanlah otonomi latar belakang tanpa batas, melainkan completion contract dengan cakupan tertentu dan tetap di bawah kendali pengguna

Quickstart: Cara menggunakan Goals

• Gunakan Goal untuk pekerjaan yang titik akhirnya jelas tetapi jalur menuju ke sana belum pasti
  • Kandidat yang bagus: optimasi performa, investigasi flaky test, migrasi dependensi, pelacakan bug yang perlu direproduksi, refactoring multi-tahap, tuning berbasis benchmark, dan pekerjaan riset yang membutuhkan artefak akhir
  • Edit satu kali lebih cocok memakai prompt biasa

• Instalasi dan cek versi

  • Goals tersedia mulai Codex 0.128.0
  • npm: setelah npm install -g @openai/codex@latest, jalankan codex --version
  • Homebrew: setelah brew update && brew upgrade --cask codex, jalankan codex --version

• Menetapkan Goal dan perintah siklus hidup

  • Tetapkan dengan format /goal <hasil>, misalnya: /goal Reduce p95 latency below 120 ms without regressing correctness tests
  • /goal: melihat Goal saat ini
  • /goal pause: menjeda Goal yang aktif
  • /goal resume: melanjutkan Goal yang dijeda
  • /goal clear: menghapus Goal saat ini

• Kondisi berhenti (stopping condition)

  • Berhenti saat sukses, dijeda, dihapus, diinterupsi, batas anggaran tercapai, atau muncul blocker yang membutuhkan input pengguna
• Goal mengekspresikan niat itu secara eksplisit dalam situasi ketika Anda harus memberi instruksi berulang setiap turn seperti “lanjutkan”, “coba perbaikan berikutnya yang memungkinkan”, “jalankan benchmark lagi”, atau “sekarang cek test”

Goals vs prompt

• Prompt biasa: “lakukan tugas berikut ini”
• Goal: “terus kerjakan sampai hasil ini menjadi benar”

• Perbedaan perilaku

  • Pada permintaan biasa, Codex menjalankan instruksi langsung, lalu melaporkan hasil dan menunggu
  • Pada Goal, durable target ditempelkan ke thread, sehingga setelah turn selesai Codex memeriksa bukti saat ini dan menilai apakah tujuan sudah terpenuhi
  • Jika belum terpenuhi, Goal masih aktif, dan masih dalam anggaran, pekerjaan bisa dilanjutkan dari status terbaru

• Contoh: /goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

  • Memberikan hasil yang terukur, sarana verifikasi, dan batasan
  • Codex akan mengulang benchmark → memeriksa hot path → membuat perubahan terarah → menjalankan benchmark lagi → menjalankan correctness suite, lalu terus melanjutkan jika hasilnya masih kurang

• Model mental

  • Prompt: ask → work → result → wait
  • Goal: work → check → continue or complete
• Goal memberikan garis finis, tetapi pekerjaan tetap harus diaudit terhadap bukti

Cara menulis Goal

• Goal yang baik bukanlah prompt yang lebih panjang, melainkan kontrak ringkas tentang bagaimana Codex harus bekerja, apa yang dianggap sukses, dan apa yang harus dilakukan jika sukses belum tercapai

• Enam elemen yang didefinisikan oleh Goal yang kuat

  • Outcome: apa yang harus benar saat pekerjaan selesai
  • Verification surface: test, benchmark, laporan, artefak, output perintah, atau sumber yang membuktikannya
  • Constraints: hal-hal yang tidak boleh mengalami regresi selama Codex bekerja
  • Boundaries: file, tool, data, repositori, atau resource yang boleh digunakan
  • Iteration policy: cara memutuskan langkah berikutnya setelah sebuah percobaan
  • Blocked stop condition: kapan harus melapor dan berhenti jika tidak ada lagi jalur yang dapat dipertanggungjawabkan dalam batasan saat ini

• Pola penulisan

  • /goal <kondisi akhir yang diinginkan> verified by <bukti spesifik> while preserving <constraints>. Use <input/tool/boundary yang diizinkan>. Between iterations, <cara memilih tindakan terbaik berikutnya>. If blocked or no valid paths remain, <apa yang harus dilaporkan dan input yang dibutuhkan untuk melanjutkan>.

• Contoh lemah vs kuat

  • Lemah: /goal Reduce p95 checkout latency below 120 ms without regressing correctness tests
  • Kuat: secara eksplisit menyebut sarana verifikasi (checkout benchmark), cakupan penggunaan (checkout service, benchmark fixtures, test terkait), kebijakan iterasi (catat perubahan, hasil benchmark, dan eksperimen berikutnya), hingga kondisi pelaporan blocker

• Goal untuk riset/investigasi

  • Jika pembuktian tepat mungkin tidak memungkinkan, definisikan standar bukti (evidence standard) sebelum mulai bekerja
  • Contoh: /goal Produce the strongest evidence-backed reproduction of the paper using the available materials and local resources. Attempt the headline results where feasible, verify outputs where possible, and end with a report that separates confirmed findings, approximate reconstructions, blocked claims, and remaining uncertainty.

• Mendelegasikan penulisan Goal ke Codex

  • Disarankan alur kerja dua tahap: jelaskan pekerjaan dengan bahasa biasa → minta Codex menyusun draft Goal → rapikan kondisi sukses, sarana verifikasi, batasan, dan kondisi berhenti karena blocker, lalu aktifkan

Apa yang berubah saat Goal aktif

• Tujuan tetap terlihat

  • Meski test gagal, thread tetap mempertahankan tujuan awal
  • Jika benchmark membaik tetapi belum melewati ambang, Codex akan terus lanjut
  • Jika jalur riset menemui kekurangan data, rencana bukti disesuaikan tanpa kehilangan standar risetnya

• Bisa berlanjut pada thread yang idle

  • Tidak akan melanjutkan saat ada turn lain yang aktif, input pengguna berada di antrean, atau pekerjaan thread lain sedang menunggu
  • Hanya melanjutkan jika thread sedang idle, Goal aktif, dan masih dalam anggaran

• Penyelesaian harus berbasis bukti

  • Tidak bisa dianggap selesai hanya karena model “merasa mungkin sudah selesai”
  • Goal diperiksa terhadap file terkait, test, log, output benchmark, artefak yang dihasilkan, dan bukti konkret lainnya sebelum dinyatakan selesai
• Inti desainnya: Codex bisa terus bergerak, tetapi bukti yang menentukan apakah tugas selesai

Struktur desain Goals di dalam Codex

• Goals diimplementasikan sebagai persisted thread state dalam cakupan thread, bukan memori global atau instruksi tingkat proyek
  • Tujuan melekat pada thread yang memiliki konteks terkait seperti file yang diperiksa, perintah yang dijalankan, diff yang dibuat, log yang dilihat, dan jejak penalaran

• Lapisan arsitektur

  • Mencatat tujuan, siklus hidup, anggaran, dan pembukuan progres sebagai status persisten dalam cakupan thread
  • Status Goal: active, paused, complete, budget-limited
  • Berdasarkan status tersebut, Codex memutuskan apakah harus lanjut, menunggu pengguna, atau merangkum progres alih-alih memulai pekerjaan baru

• Continuation bersifat event-driven

  • Bukan loop sederhana, dan hanya diperiksa pada batas aman: setelah turn selesai, tidak ada tugas tertunda, tidak ada input pengguna di antrean, dan thread idle
  • Dispatcher bersifat konservatif: pekerjaan yang hanya berupa perencanaan tidak memicu continuation, interupsi akan menjeda tujuan, saat thread dilanjutkan tujuan dipulihkan jika sesuai, dan jika turn continuation tidak memanggil tool maka auto-continuation berikutnya ditekan untuk mencegah spin

• Lapisan prompting

  • Prompt continuation menjaga Codex tetap selaras dengan Goal aktif, tetapi tetap menuntut audit sebelum dinyatakan selesai
  • Goal dibandingkan dengan bukti konkret seperti file yang diubah, perintah yang dijalankan, test yang lolos, output benchmark, artefak yang dihasilkan, dan bukti riset

• Penanganan anggaran (budget)

  • Saat anggaran tercapai, pekerjaan substantif dihentikan, progres dan blocker dirangkum, lalu langkah berguna berikutnya diidentifikasi
  • Mencapai batas anggaran tidak sama dengan menyelesaikan Goal

• Tool contract

  • Model dapat memulai Goal, tetapi hanya dapat menandai Goal yang ada sebagai complete jika bukti mendukung penyelesaiannya
  • Menjeda, melanjutkan, menghapus, atau mengalihkan ke batas anggaran tetap berada di bawah kontrol pengguna atau sistem

Mengubah Goal yang lemah menjadi Goal yang kuat

• Contoh tuning performa

  • Lemah: /goal Improve performance
  • Kuat: /goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness test suite green
  • Versi kuat memberikan hasil, cara verifikasi, dan batasan, sehingga bisa diketahui kapan pekerjaan belum boleh berhenti
    • Jika p95 membaik dari 180ms → 135ms, Goal masih belum selesai
    • Jika latensi sudah di bawah 120ms tetapi correctness test gagal, tetap belum selesai
    • Jika benchmark tidak bisa dijalankan, blocker dimunculkan alih-alih mendeklarasikan sukses

• Cakupan Goal yang tepat

  • Harus cukup sempit agar bisa diaudit, tetapi cukup luas agar bisa memilih tindakan berikutnya
  • “Fix the failing checkout test” terlalu sempit jika ternyata masalah sebenarnya ada di dependensi hulu
  • “Improve the whole system” terlalu luas karena tidak punya permukaan audit
  • “Make the checkout test suite pass on the current branch without changing public API behavior” adalah contoh yang tepat

• Prinsip yang sama untuk generated artifacts

  • Lemah: /goal Write docs for this feature
  • Kuat: /goal Produce a docs page for Goals that explains the lifecycle, command surface, and two examples. Verify that the page builds locally and that all referenced commands match the current CLI behavior.
  • Versi kuat memberikan halaman yang bisa diperiksa, perintah build, dan perilaku perintah

• Standar bukti untuk Goal riset

  • Definisikan sebelum investigasi dimulai: apa yang termasuk reproduksi tepat, rekonstruksi parsial, dukungan proksi, dan apa yang harus dianggap blocker
  • Goal riset yang kuat menuntut penyusunan inventaris klaim, pemetaan klaim-ke-bukti, implementasi bagian yang dapat dijalankan, pelabelan blocker, dan pembuatan audit yang memisahkan klaim terkonfirmasi, bukti khusus pendukung, klaim yang terblokir, serta ketidakpastian yang tersisa

Menggunakan Goals untuk riset kompleks: studi kasus reproduksi paper kuantitatif

• Ringkasan kasus

  • Target: paper Deep Hedging karya Buehler, Gonon, Teichmann, dan Wood
  • Topik paper: apakah strategi trading neural network dapat mereproduksi hedging berbasis model dalam konteks preferensi risiko, biaya transaksi, dan pengaturan pasar berdimensi tinggi
  • Goal yang benar bukan “mereproduksi paper” secara abstrak, melainkan mencoba klaim angka utama, memisahkan mekanisme yang tepat dari pengganti pembelajaran yang bersifat aproksimasi, dan menyatakan bagian yang tidak mungkin direproduksi secara tepat dengan materi yang tersedia

• Goal riset lemah vs kuat

  • Lemah: /goal Reproduce Buehler et al., "Deep Hedging"
    • Tidak mendefinisikan bagian mana yang penting, apa yang dihitung sebagai reproduksi, bagaimana menangani tidak adanya state pelatihan, atau bagaimana membedakan kecocokan aproksimatif dari reproduksi tepat
  • Kuat: /goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

• Pekerjaan nyata yang dilakukan Codex

  • Memisahkan klaim utama dan klaim pendukung
  • Memetakan klaim ke bukti yang tersedia
  • Merekonstruksi bagian yang bisa diuji secara lokal
  • Memberi label pada klaim yang tidak bisa direproduksi secara tepat dengan materi yang ada

• Bagian yang bisa dijalankan

  • Merekonstruksi mekanisme pricing dan hedging
  • Mereproduksi harga referensi Heston
  • Melatih policy untuk eksperimen hedging CVaR
  • Merekonstruksi artefak histogram utama dan hedge surface
  • Mereproduksi slope biaya transaksi Black-Scholes
  • Menjalankan pemeriksaan terlatih untuk contoh biaya transaksi Heston dan contoh berdimensi tinggi

• Bagian yang tetap menjadi blocker

  • Paper tidak menyediakan random seed yang tepat, jalur pelatihan yang dihasilkan, graph TensorFlow, optimizer state, checkpoint, atau keseluruhan state simulasi asli
  • Hasil yang paling jujur adalah reproduksi parsial dan aproksimatif, bukan replay neural network yang tepat

• Menjaga tingkat dukungan epistemik dalam laporan

  • Pengganti terlatih dapat mendukung klaim, kecocokan numerik yang dekat dapat meningkatkan keyakinan, dan gambar yang direkonstruksi dapat memverifikasi sebagian hasil, tetapi tidak satu pun boleh dideskripsikan sebagai pemulihan eksperimen asli secara tepat
  • Contoh ledger:
    • Claim: Deep hedging approximates complete-market Heston hedge without transaction costs
    • Route: rekonstruksi mekanisme model, perbandingan hedge referensi, pelatihan neural network policy
    • Evidence surface: pemeriksaan pricing, histogram, hedge surface
    • Status: Close approximate reproduction
    • Remaining uncertainty: jalur pelatihan asli, seed, dan checkpoint tidak tersedia
• Nilai demonstratif Goals dalam riset adalah menjaga pekerjaan tetap berjalan di tengah ambiguitas, sekaligus mencegah artefak yang tampak meyakinkan berubah menjadi kesimpulan yang diklaim berlebihan; makna selesai didefinisikan sebagai audit per klaim berbasis bukti, kejelasan tentang aproksimasi, dan kejujuran tentang batas antara reproduksi dan replay

Kapan sebaiknya tidak menggunakan Goals

• Tidak cocok untuk edit satu baris, penjelasan sederhana, code review singkat, atau pertanyaan yang diinginkan berhenti setelah satu jawaban → prompt Codex biasa lebih cocok
• Tidak cocok jika garis finisnya ambigu
  • “Make this better” tidak memberikan completion condition yang dapat diandalkan
  • “Refactor this code” juga lemah jika tidak mendefinisikan kondisi akhir yang diharapkan, test, dan batasan
• Jangan gunakan untuk menyembunyikan ketidakpastian
  • Jika data mungkin tidak tersedia, nyatakan itu di dalam Goal
  • Jika benchmark mungkin flaky, jelaskan cara menanganinya
  • Jika bukti proksi diperbolehkan, definisikan cara pelabelannya
• Goals paling kuat ketika tiga sifat ini bergabung: tujuan persisten, garis finis berbasis bukti, dan jalur yang memerlukan investigasi multi-turn

Kesimpulan: pertahankan tujuan, tetapi bukti yang menentukan selesai

• Goals mengubah model operasi Codex dengan menggeser thread dari rangkaian prompt yang terisolasi menjadi loop kerja berbasis state yang berpusat pada hasil yang terdefinisi
• Arsitekturnya sengaja memiliki batas yang jelas
  • Goal dibatasi pada thread, memiliki status siklus hidup dan pembukuan anggaran, serta bisa dijeda, dilanjutkan, dihapus, diselesaikan, atau dihentikan karena anggaran
  • Codex dapat terus bergerak, tetapi hanya di dalam kontrak yang ditentukan pengguna
• Ini berguna untuk pekerjaan yang memang paling bernilai bagi Codex, yaitu debugging, optimasi, migrasi, testing, dan riset
• Pengguna memberikan tujuan, Codex mengikuti bukti, dan Goal menghubungkan keduanya sampai pekerjaan selesai atau secara jujur dinyatakan terblokir
• Untuk riset kompleks, ini menciptakan perbedaan antara menghasilkan jawaban dan menghasilkan audit
• Goal yang baik tidak sekadar meminta Codex untuk menyelesaikan sesuatu, tetapi memberi tahu Codex apa arti dari “sudah selesai”

[hmmhmmhm]

/goal Tolong periksa dan lanjutkan semua hal yang bisa dikerjakan berdasarkan pekerjaan yang sebelumnya sudah saya lakukan sampai jam makan siang pukul 12. Jangan menghentikan pekerjaan sebelum pukul 12.

[shakespeares]

Perintah yang keren.