Satu File, Dua Mode: Kenapa Saya Batal Bikin Panduan Terpisah
Sumber artikel nggak menentukan jenisnya, isi brief yang menentukan. Deteksi mode dari konten, satu guide kanonik, tanpa duplikasi enforcement.
Ringkasan
Awalnya gue mau bikin dua file prompt terpisah buat artikel teknis dan non-teknis, ternyata salah besar karena jenis artikel ditentukan isi brief, bukan sumbernya. Solusinya satu guide dua mode, dideteksi dari konten. Kayak feature detection ala MDN, lebih andal daripada nebak dari asal sumber.
Addendum untuk artikel non-teknis datang ke style guide penulisan blog ini, dan godaan pertama saya langsung muncul: bikin file prompt kedua khusus non-teknis. Dua panduan paralel, satu untuk teknis, satu untuk refleksi. Rasanya rapi banget di kepala.
Saya pikir memisahkan keduanya adalah solusi paling bersih. Prompt teknis isinya perintah dan kode, prompt non-teknis isinya analisis dan opini. Tinggal panggil file yang sesuai, beres.
Ternyata tebakan itu salah besar. Sumber artikel, apakah dari commit diff atau research dossier, sama sekali nggak menentukan jenis artikelnya. Yang menentukan justru isi brief-nya. Commit bisa memicu refleksi non-teknis soal keputusan arsitektur, sementara research dossier bisa memicu artikel teknis berisi troubleshooting. Kalau saya maksa bikin dua panduan paralel, yang terjadi cuma duplikasi logika yang pasti drift seiring waktu.
Kenapa dua file itu jebakan
Solusinya justru lebih sederhana: deteksi mode dari konten brief, lalu pertahankan satu guide dua mode dalam satu file. Ini mirip prinsip feature detection yang direkomendasikan MDN [1]. Daripada nebak-nebak dari identitas asal, kayak browser sniffing dari UA string yang susah dilakukan secara andal dan sering jadi sumber bug, lebih baik tes properti yang relevan lalu kondisikan perilaku berdasarkan hasilnya [4]. Saya nggak perlu tahu brief itu datang dari mana, saya cuma perlu tahu isinya bisa diapain.
Memecah panduan jadi dua file juga melanggar prinsip Single Source of Truth: setiap elemen data dikuasai di satu tempat saja, yang mencegah inkonsistensi dan menyederhanakan version control [2]. Bayangkan ada aturan redaksi baru. Kalau ada dua file, saya harus ingat buat ngubah keduanya. Risiko lupa itu nyata banget.
Dokumentasi prompting Anthropic menekankan hal serupa [3]: beri konteks dan motivasi di dalam instruksi, lalu biarkan model menggeneralisasi darinya. Daripada bikin cabang instruksi yang kaku, saya cukup menjelaskan bahwa mode dideteksi dari isi brief. Technical mode berarti brief berisi hal yang bisa dijalankan atau dicek langsung oleh pembaca. Non-technical mode berarti buktinya berupa jejak pertimbangan yang konkret, ditambah artefak ekuivalen kayak tabel atau checklist.
Peta dua mode dalam satu file
Aturan redaction gate berlaku sama ketatnya di kedua mode, nggak ada pengecualian hanya karena artikelnya non-teknis. Satu fakta lagi yang sering kelewat: bagian addendum soal enforcement redaksi nggak saya duplikasi ke dalam prompt. Aturan itu udah live di fungsi check_redaction pada commit bd55ff0. Satu mekanisme, satu tempat. Nggak perlu ditulis ulang di panduan.
Supaya kebayang, ini pemetaan sederhana gimana satu panduan menangani dua mode yang beda:
| Aspek | Technical Mode | Non-Technical Mode |
|---|---|---|
| Pemicu deteksi | Brief berisi perintah, config, atau kode | Brief berisi riset, opini, atau evaluasi |
| Bentuk bukti | Script sampel yang bisa dijalankan pembaca | Checklist keputusan atau tabel trade-off |
| Gaya bahasa | Imperatif: jalankan, cek | Argumentatif konkret: saya timbang X vs Y |
Checklist buat sistem kamu
Kalau kamu sedang merancang sistem serupa dan bingung kapan memakai route-by-property versus route-by-origin, pakai checklist lima poin ini:
- Apakah identitas asal bisa dipalsukan atau berubah di masa depan? Kalau ya, jangan jadikan itu satu-satunya penentu.
- Apakah properti yang dicek benar-benar relevan sama hasil yang diinginkan? Fokus ke apa yang bisa dilakukan, bukan siapa yang melakukannya.
- Apakah ada lebih dari satu sumber data yang mengklaim hal yang sama? Kalau ada, pilih satu sumber kebenaran dan jadikan yang lain bacaan.
- Apakah logika deteksi ini perlu diupdate di lebih dari satu tempat? Kalau iya, desain kamu udah mulai drift dan perlu disatukan.
- Apakah kamu bisa jelasin alasan pemilihan rute ini ke developer baru dalam satu kalimat tanpa nyebut nama vendor? Kalau nggak bisa, logikanya terlalu terikat konteks.
Saya pribadi menghindari solusi "tergantung kebutuhan" yang nggak punya kriteria jelas. Memilih deteksi mode dari isi brief, bukan dari label sumbernya, adalah keputusan yang saya ambil karena klasifikasi berdasarkan sumber terbukti rapuh. Lebih baik satu guide dua mode yang adaptif daripada dua panduan yang akhirnya saling bertentangan.
Menulis panduan buat diri sendiri itu sama kayak nulis kode. Kalau kamu nemu diri kamu menyalin-tempel logika yang sama ke file baru hanya karena kasusnya beda, itu bukan refaktorisasi. Itu utang teknis yang sedang kamu bangun dengan tangan kamu sendiri.