Prompt Bukan Permintaan, Melainkan Spesifikasi Kerja
Tugas agen yang sama memberi hasil berbeda setiap eksekusi. Penyebabnya prompt yang menyisakan keputusan pada model; solusinya spesifikasi kerja eksplisit.
Ringkasan
Prompt sama tapi hasilnya beda-beda tiap dijalankan? Bukan modelnya yang error, tapi promptnya kekurangan detail, jadi model nebak sendiri bagian yang gak disebut. Anggap prompt itu spesifikasi kerja: sebutin tujuan, batasan, bentuk output, sama cara verifikasi, hasilnya konsisten dan hemat iterasi.
Tugas agen yang sama, misalnya menulis README untuk modul baru atau menghasilkan validator data, memberi hasil berbeda setiap dijalankan. Prompt yang dipakai persis sama. Dugaan pertama menyalahkan model: temperatur terlalu tinggi, atau modelnya memang tidak stabil.
Log eksekusi menunjukkan hal lain. Prompt-nya kekurangan definisi pekerjaan. Model diam-diam memilih nilai default untuk setiap aspek yang tidak disebutkan, dan setiap eksekusi memilih beda. Masalahnya bukan modelnya; masalahnya instruksi yang menyisakan terlalu banyak keputusan pada model.
Kerangka berpikirnya kemudian bergeser: prompt tidak lagi sebagai permintaan, melainkan sebagai spesifikasi kerja. Sebuah tutorial akademik terbaru merumuskan rekayasa prompt sebagai disiplin mengubah niat manusia yang informal menjadi spesifikasi kerja AI terstruktur, dan menegaskan bahwa prompt terkuat bukan yang terpanjang, melainkan yang membuat perilaku yang diinginkan, sumber yang dibutuhkan, dan kriteria keberhasilan menjadi tidak ambigu.
Spesifikasi minimal yang mengikat
Struktur yang terbukti cukup untuk tugas harian: tujuan, konteks, batasan, bentuk output, dan langkah verifikasi. Sebuah studi empiris di ICPC 2026 mengeluarkan sepuluh pedoman perbaikan prompt untuk pembangkitan kode, dan semuanya berputar di sekitar hal yang sama: spesifikasikan input-output, beri pra dan pasca-kondisi, beri contoh, luruskan ambiguitas. Pasca-kondisi menarik untuk dicermati karena membantu model memverifikasi kebenaran logika outputnya sendiri sebelum diserahkan ke pengguna.
Di tingkat organisasi, pola yang sama muncul sebagai aturan. Standar PRD-STD-001 mewajibkan prompt produksi memuat tujuan, konteks, dan batasan eksplisit, sekaligus melarang kredensial atau data pribadi masuk ke instruksi. Alasannya terukur: prompting ad-hoc terbukti menghasilkan output tidak konsisten, tingkat cacat lebih tinggi, dan siklus iterasi terbuang.
Implementasi di alur kerja sehari-hari bisa sesederhana mengganti cara meminta. Alih-alih "buatkan validator untuk form pengguna", spesifikasinya: buat fungsi validasi untuk form pendaftaran; konteks: aplikasi web portal kota; batasan: gunakan TypeScript, tolak email tanpa domain valid, kembalikan objek error terstruktur; verifikasi: sertakan tiga kasus uji termasuk satu input kosong.
Yang berubah setelah standar dipakai
Hasil eksekusi mulai konvergen. Output yang sama bentuknya antar eksekusi, dan pemeriksaannya objektif: kriteria sukses sudah tertulis di prompt, bukan ada di kepala pengembang. Waktu merumuskan konteks dan batasan di awal memang bertambah beberapa menit, tapi iterasi korektif berulang hilang, dan itulah bagian yang mahal.
Standar semacam ini juga bertahan menghadapi pergantian model. Model akan terus berubah, tapi spesifikasi kerja yang baik membuat perilaku yang diharapkan, batasannya, dan cara memeriksanya tetap eksplisit. Ketiga sumber di atas, dari tutorial akademik, studi empiris, sampai standar organisasi, konvergen ke titik yang sama: kejelasan spesifikasi lebih menentukan hasil daripada kecerdasan model yang dipakai.
Sumber
A Tutorial on Prompt Engineering: From Messy Thoughts to AI Workflows, diakses 10 Oktober 2026.
Guidelines to Prompt Large Language Models for Code Generation, ICPC 2026, diakses 10 Oktober 2026.
PRD-STD-001: Prompt Engineering Standards, diakses 10 Oktober 2026.