writing

Rencana 634 baris yang benar-benar bisa dijalankan: migrasi berpasangan, kontrak dulu, test terdaftar di commit yang sama.

TL;DR: Ternyata dokumen rencana 634 baris itu bukan formalitas, tapi panduan ketat berisi tugas, berkas, dan aturan wajib. Aturannya mekanis: skema database cuma boleh lewat migrasi naik-turun, API ditulis dulu sebelum kode, dan test wajib ikut terdaftar. Nilainya justru di penegasan yang ditolak, jadi aku mau pakai pola ini ke alur kerja berikutnya.

Brief lisan klien dibekukan dulu: kutipan verbatim dipisahkan dari catatan tim, konflik dicatat bukan diputuskan.

TL;DR: Brief lisan klien jangan langsung jadi tiket kerja, bahaya kalau salah tafsir. Tim bekuin omongannya apa adanya di dokumen intake status input, dipisah kutipan verbatim sama catatan tim yang mapetin poin ke dokumen lama. Yang bentrok atau belum jelas ditahan dulu, cuma jalur aman yang masuk backlog sambil nunggu konfirmasi tertulis.

Plan yang dibatalkan tetap bisa menjadi sumber panduan: ekstraksi eksplisit dengan daftar dilarang diangkat, sementara dokumen sumber tetap beku.

TL;DR: Dokumen plan yang udah di-cancel hampir dianggap sampah padahal isinya masih kepake banget. Daripada buka lagi dokumen lamanya atau nyomot diam-diam, tim cuma mindahin yang masih valid ke bagian E di dokumen baru lengkap sama daftar yang dilarang dibawa. Jadi plan lama tetap beku cuma dikasih backlink, jejak keputusannya aman tapi ilmunya tetap bisa dipake.

Format laporan QA dua lapis: laporan sesi append-only log-as-you-go plus berkas modul living, dengan angka hanya dari artefak mesin.

TL;DR: Jadi ceritanya, laporan pengujian sering nggak bisa dipercaya karena angkanya cuma diketik ulang dari ingatan, bukan dari bukti asli. Solusinya: catat sesi sambil jalan (append-only) plus berkas modul yang terus di-update, semua angka wajib dari artefak mesin. Hasilnya, 31 skenario keuji, temuan gampang dilacak balik, nggak ada lagi rekonstruksi di akhir hari.

Pada satu titik pengembangan, berkas prompt penulisan tunggal membengkak sampai 228 baris instruksi yang saling bertentangan.

TL;DR: Dulu prompt nulis cuma satu file berisi 228 baris perintah yang saling tabrakan, bikin hasilnya seret gitu. Solusinya dipecah jadi kontrak bareng 205 baris plus empat file mode: laporan, berita, tutorial, sama explainer. Kontrak jaga fakta, mode atur gaya, dan modenya dipilih sesuai janji ke pembacanya.

Sumber artikel nggak menentukan jenisnya, isi brief yang menentukan. Deteksi mode dari konten, satu guide kanonik, tanpa duplikasi enforcement.

TL;DR: 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.

Minggu lalu, pipeline artikel blog saya gagal total. Saya mengira menempelkan skill 100KB berisi ratusan aturan gaya bahasa ke dalam prompt akan…

Lane C di cron saya: sintesis chat AI buat nyari sudut yang kelewat, verifikasi tetap ke halaman primer yang dibuka sendiri.

TL;DR: Chat AI kepakai sebagai detektor sudut riset, bukan penentu kebenaran; satu sudut baru lolos cek manual, satu klaim Stanford HAI dibuang karena halaman primernya nggak bisa dibuka. Lane C cuma nambah sintesis tanpa menggantikan Lane A, yang tetap jadi ground truth lewat sumber primer dan sitasi terverifikasi. Sitasi itu jejak buat diverifikasi manusia, bukan stempel kebenaran.

Instruksi gaya yang diulang di sepuluh prompt saya kodifikasi jadi skill blog-id-style, satu file yang dimuat agen pas dibutuhkan.

TL;DR: Preferensi gaya yang diulang di banyak prompt itu duplikasi procedural knowledge: sekali lupa satu file, dua artikel beda standar. Solusinya agent skills dari Anthropic, folder instruksi yang dimuat agen secara dinamis; semua aturan gaya kini tinggal di satu skill bernama blog-id-style. Skill itu ibarat onboarding guide: isi cuma yang agen belum tahu, dan tiap perubahan gaya cukup ubah satu file.