Masalahnya bukan model AI-nya. Masalahnya adalah cara kita memberi instruksi ke model itu.
Banyak orang mengira hasil generative AI yang tidak konsisten itu soal "model belum cukup pintar". Padahal, di banyak kasus, masalahnya ada di hulu: prompt yang dipakai tidak pernah dirancang untuk konsisten sejak awal.
Di sinilah dua pendekatan ini berbeda arah. Yang satu, conventional prompting, mengandalkan instruksi bebas dan iterasi manual. Yang satu lagi, contract-first, mendekati prompt seperti kontrak teknis yang mengikat struktur output sejak awal.
Masalah Utama: Output yang "Kadang Bagus, Kadang Ngaco"
Kalau kamu pernah pakai AI untuk tugas berulang — generate laporan, ekstraksi data, format konten — kamu pasti kenal pola ini.
Hari ini hasilnya rapi. Besok, dengan prompt yang sama persis, formatnya berubah. Ada field yang hilang. Ada penjelasan tambahan yang tidak diminta.
Ini bukan bug. Ini konsekuensi logis dari cara kerja model bahasa: probabilistik, bukan deterministik. Tanpa batasan struktural yang jelas, model akan selalu punya ruang untuk "berkreasi" — bahkan saat kreativitas itu justru merusak konsistensi yang kamu butuhkan.
Friction di Lapangan: Prompt yang Membengkak
Reaksi paling umum terhadap masalah ini adalah menambah instruksi. Terus-menerus.
"Jangan tambahkan penjelasan." "Selalu gunakan format ini." "Jangan ubah urutan field." Satu per satu, prompt tumbuh jadi dokumen panjang berisi larangan dan pengecualian.
Ini bekerja, sampai akhirnya tidak. Semakin panjang prompt, semakin besar peluang model mengabaikan sebagian instruksi — apalagi kalau instruksi itu saling tumpang tindih atau kontradiktif tanpa disadari.
Tim yang membangun produk berbasis AI biasanya sadar ini di titik paling menyakitkan: saat sistem sudah jalan di production, lalu output tiba-tiba berubah bentuk tanpa perubahan kode apa pun.
Solusi yang Umum Dipakai: Prompt Engineering Konvensional
Pendekatan konvensional biasanya berputar di tiga hal: menulis instruksi lebih detail, memberi contoh (few-shot), dan melakukan trial-and-error sampai output terasa "cukup benar".
Ini masuk akal sebagai titik awal. Untuk kebutuhan sekali pakai — brainstorming, draft cepat, eksplorasi ide — pendekatan ini cukup efektif dan efisien.
Tapi begitu prompt yang sama harus dipakai berulang, oleh banyak orang, di banyak konteks — konvensional mulai retak.
Kenapa Pendekatan Ini Tidak Ideal untuk Skala
Masalahnya bukan few-shot atau instruksi detailnya. Masalahnya adalah prompt konvensional tidak punya "bentuk" yang mengikat.
Instruksi berbasis bahasa alami itu fleksibel — dan fleksibilitas itu dua arah. Model bisa menginterpretasikan ulang instruksi kamu tergantung konteks, panjang percakapan, atau bahkan urutan kalimat.
Analogikan seperti kode tanpa tipe data. Kamu bisa menulis fungsi yang "biasanya" menerima angka. Tapi tanpa validasi tipe, suatu saat ada yang mengirim string, dan sistem kamu diam-diam rusak — bukan karena error, tapi karena tidak ada kontrak yang memaksa bentuk data tetap konsisten.
Prompt konvensional punya masalah yang sama. Tidak ada kontrak. Hanya harapan.
Perkenalkan: Contract-First Prompting
Contract-first membalik urutan berpikirnya. Alih-alih mulai dari "apa yang ingin saya minta", kamu mulai dari "bentuk apa yang harus dihasilkan, apa pun inputnya".
Ini bukan sekadar template. Ini adalah spesifikasi — mirip skema JSON, struktur API, atau interface dalam pemrograman. Sebelum model diminta "berpikir", model dulu diberi kerangka yang membatasi seperti apa hasil akhirnya harus terlihat.
Model tetap generatif di dalam kerangka itu. Tapi bentuk luar hasilnya sudah dikunci sejak awal.
Bagaimana Ini Bekerja, Secara Teknis Tapi Sederhana
Bayangkan folder proyek. Conventional prompting itu seperti minta orang menyimpan file "dengan rapi" — tanpa aturan nama, tanpa struktur folder tetap. Hasilnya rapi menurut orang itu, hari itu, mood itu.
Contract-first itu seperti sudah punya struktur folder baku sejak awal: nama file harus begini, folder harus begitu. Siapa pun yang menyimpan file, hasilnya tetap konsisten — karena strukturnya sudah ditentukan, bukan diserahkan ke interpretasi.
Dalam praktiknya, ini berarti mendefinisikan dulu: field apa saja yang wajib ada, tipe datanya apa, urutan seperti apa, dan apa yang terjadi kalau salah satu bagian tidak bisa diisi. Baru setelah itu, instruksi konten ditambahkan di dalam kontrak tersebut.
Contoh Skenario
Sistem yang mengekstrak data dari dokumen pelanggan untuk masuk ke database.
Dengan conventional prompting: "Tolong ekstrak nama, tanggal, dan nominal dari dokumen ini, format rapi ya." Hasilnya bisa berupa paragraf, bisa berupa list, kadang tanggal ditulis "12 Januari 2026", kadang "2026-01-12" — tergantung dokumen dan mood model hari itu.
Dengan contract-first: kamu tentukan dulu skema keluarannya — field nama (string, wajib), tanggal (format ISO, wajib), nominal (angka, wajib), dan aturan eksplisit kalau salah satu tidak ditemukan di dokumen. Model tetap "berpikir" untuk mencari data itu, tapi bentuk hasil akhirnya tidak pernah berubah-ubah.
Bedanya bukan soal kualitas ekstraksi. Bedanya soal keandalan bentuk — sesuatu yang jauh lebih penting begitu output itu masuk ke sistem lain.
Pergeseran Cara Berpikir yang Sebenarnya Terjadi
Ini bukan soal teknik prompt yang lebih canggih. Ini soal mengubah posisi kamu — dari peminta instruksi jadi perancang sistem.
Conventional prompting menempatkan kamu sebagai orang yang "berbicara" ke AI setiap kali butuh sesuatu. Contract-first menempatkan kamu sebagai orang yang merancang aturan main sekali, lalu membiarkan sistem berjalan di dalam aturan itu berulang kali.
Ini mirip transisi dari menulis skrip manual ke menulis fungsi dengan interface yang jelas. Sekali kontraknya benar, kamu tidak perlu menjelaskan ulang setiap kali — kamu tinggal memanggilnya.
Masalahnya bukan seberapa bagus kamu menulis prompt. Masalahnya adalah apakah hasil itu bisa diandalkan tanpa kamu harus mengawasinya setiap saat.
Kapan Masing-Masing Cocok Dipakai
Conventional prompting tetap relevan untuk eksplorasi, ide cepat, dan konteks satu kali pakai — di mana fleksibilitas justru jadi kekuatan.
Contract-first jadi jauh lebih penting begitu output itu harus konsisten, berulang, atau terhubung ke sistem lain — produk, pipeline data, automation, atau apa pun yang tidak punya manusia untuk mengecek hasil satu per satu.
Pertanyaannya bukan "mana yang lebih baik" secara mutlak. Pertanyaannya adalah: apakah hasil ini perlu diinterpretasikan ulang oleh manusia, atau perlu langsung dipakai oleh sistem?
Kesimpulan
Generative AI tidak butuh instruksi yang lebih panjang, ia butuh batasan yang lebih jelas — dan di situlah bedanya conventional prompting yang mengandalkan pengawasan manusia di setiap langkah dengan contract-first yang mengandalkan struktur sejak awal. Begitu kamu ingin AI bekerja tanpa perlu terus-menerus dicek, bahasa alami saja tidak cukup, kamu butuh kontrak yang mengikat bentuk hasilnya. Contract-first bukan tren baru dalam prompt engineering, melainkan pengakuan sederhana bahwa sistem yang andal selalu dimulai dari struktur, bukan dari harapan.