Approval Claude Code tak lagi bikin ragu: cara membuat log keputusan read/edit/run/deploy

Jumat sore, saya minta Claude Code “tolong perbaiki link di halaman ini saja”. Yang muncul malah pesan konfirmasi sepenuh layar. “Boleh jalankan command ini?” katanya, dan karena sudah capek, saya tekan Enter tanpa benar-benar membaca isinya.

Besok paginya, tampilan harga di situs produksi sudah berubah. Sambil membenahi link, AI ikut “sekalian” mengubah file lain yang memuat angka harga. Yang menekan tombol izin, jelas-jelas saya sendiri.

Masalahnya bukan AI yang terlalu pintar. Yang jadi soal: batas antara operasi yang kemarin saya setujui dan operasi yang hari ini harus saya hentikan cuma ada di kepala saya, dan setiap kali berubah-ubah. Kalau “ah, biarin saja” bergerak menurut suasana hati hari itu, kecelakaan tinggal soal waktu. Hari ini saya tulis cara mengeluarkan batas itu dari kepala: membuat “log approval”.

Poin penting

• Approval Claude Code jadi tidak membingungkan kalau dibagi empat: baca, ubah, jalankan, publikasi.
• Tiap operasi dipilah ke “izinkan, konfirmasi, larang”, lalu alasan dan command pengecekannya dicatat dalam satu file setiap hari.
• Yang diserahkan ke AI adalah riset awal dan draf; yang dipegang manusia adalah harga, publikasi produksi, dan penghapusan.
• Tersedia template log siap salin dan prompt untuk meminta AI membuatkan draf pemilahannya.
• Kalau ragu, jangan masukkan ke “izinkan”. Cuma dengan ini, “kecelakaan sekalian” hampir hilang.

Bagi approval jadi empat: baca, ubah, jalankan, publikasi

Saat memakai Claude Code, bermacam konfirmasi berdatangan. Karena semuanya dipukul rata jadi “Ya atau Tidak”, tiap kali jadi melelahkan. Begitu pekerjaan dibagi jadi empat jenis, keputusan langsung terasa ringan.

• Baca: cuma melihat isi file atau log. Pada dasarnya boleh diizinkan tanpa masalah.
• Ubah: menulis ulang isi file. Untuk typo di artikel boleh santai. Tabel harga lain perkara.
• Jalankan: menjalankan command. Cek perilaku boleh santai, tapi yang berdampak ke luar harus hati-hati.
• Publikasi: menerapkan perubahan ke situs produksi. Bagian ini selalu saya perlakukan sebagai benteng terakhir.

Sama-sama “ubah”, tapi bobot antara typo di badan blog dan file pengaturan pembayaran benar-benar berbeda. Karena itu saya memutuskan bukan cuma jenis operasinya, tapi sampai ke “file yang mana” sebagai satu paket.

Pilah keputusan ke tiga tingkat

Setelah dibagi empat, tiap kategori dipilah lagi ke tiga tingkat. Tidak perlu istilah rumit.

Tingkat	Arti	Contoh
Izinkan	Boleh jalan tanpa nanya	Baca folder artikel, perbaiki typo di badan teks
Konfirmasi	Tanya dulu ke saya sekali	Ubah file harga, publikasi ke produksi
Larang	Kali ini tidak boleh dilakukan	Hapus file secara massal, timpa paksa

Triknya cuma satu. Sedikit saja ragu, jangan masukkan ke “izinkan”. Taruh dulu di “konfirmasi”. Nanti setelah yakin “ini memang aman tiap kali”, baru naikkan ke “izinkan”. Awalnya semua dipegang ketat, lalu hanya yang sudah terbukti aman yang dikendurkan. Cukup ikuti urutan ini, dan kecelakaan harga seperti di pembuka tadi tidak akan terjadi lagi.

Catat dalam satu file tiap hari: template log

Karena dipaksa diingat di kepala, akhirnya berantakan. Cukup satu file per hari, tulis pemilahan hari itu saja. Formatnya bebas, tapi saya akhirnya berhenti di bentuk ini. Bisa langsung disalin dan dipakai.

{
  "date": "2026-06-07",
  "scope": "hanya badan artikel dan penataan CTA",
  "baca":      { "izinkan": ["site/src/content/**", "site/src/lib/gumroadProducts.ts"] },
  "ubah":      { "izinkan": ["file artikel baru"], "konfirmasi": ["harga", "pengaturan pembayaran", "secret produksi"] },
  "jalankan":  { "izinkan": ["npm run build", "cek tampilan URL publik"], "konfirmasi": ["publikasi", "git push"] },
  "publikasi": { "konfirmasiDulu": ["build lolos", "h1 URL publik benar", "tampilan tiap bahasa dicek mata"] },
  "memoBerikut": "Harga tetap konfirmasi ke depan. Penataan CTA artikel boleh dinaikkan ke izinkan setelah dicek aman."
}

Menulisnya 2-3 menit. Tapi 2-3 menit ini menghapus 10 menit kebingungan keesokan harinya saat berpikir “lho, kemarin ini saya apakan ya”. Satu baris scope diam-diam sangat berguna. Dengan menulis dulu sejauh mana batas kerja hari ini, kita langsung sadar begitu AI keluar dari batas itu.

Yang diserahkan ke AI dan yang diputuskan manusia

Mencampur bagian ini bikin celaka. Mari tegaskan batasnya.

Yang boleh diserahkan ke AI

• Mencari file mana yang kemungkinan terkait
• Membuat draf perubahan
• Menampilkan diff sebelum dan sesudah perubahan
• Menjalankan command untuk mengecek “apakah build lolos”

Yang wajib dipegang manusia

• Perubahan yang menyentuh harga, pembayaran, dan form pendaftaran
• Publikasi ke situs produksi (tombol publikasi ditekan sendiri)
• Penghapusan file atau data
• Pekerjaan yang cara membatalkannya tidak bisa dijelaskan

Aturan saya sederhana: kalau menyangkut salah satu dari “uang”, “produksi”, “menghapus”, “tidak bisa dibatalkan”, keputusan akhir wajib di tangan saya sendiri. Sebaliknya, riset awal dan draf di luar itu boyong saja ke AI tanpa sungkan. Cara berpikir soal batas ini juga saya singgung di pengantar Claude Code untuk yang bukan engineer, dan tanpa pengetahuan teknis pun, asal memutuskan “khusus uang dan produksi, saya sendiri”, itu sudah cukup melindungi.

Prompt agar AI membuatkan draf pemilahan

Pemilahannya sendiri pun bisa dibantu AI. Tapi jangan telan mentah-mentah hasilnya; yang terakhir tetap dilihat sendiri. Kalimat perintah berikut bisa langsung ditempel dan dipakai.

Untuk pekerjaan Claude Code hari ini, pilah operasi ke "izinkan / konfirmasi / larang".
Targetnya empat jenis berikut: baca / ubah / jalankan / publikasi.

Untuk tiap kategori, kembalikan hal berikut:
1. Daftar operasi yang boleh diizinkan
2. Daftar operasi yang harus dikonfirmasi dulu sekali
3. Daftar operasi yang kali ini dilarang
4. Command pengecekan untuk memastikan keamanan (mis. npm run build)
5. Memo untuk lain kali (syarat menaikkan konfirmasi -> izinkan)

Operasi yang menyangkut harga, pembayaran, publikasi produksi, dan penghapusan, kalau ragu masukkan ke "konfirmasi".

Kuncinya ada di baris terakhir. Dengan memasukkan ini, kita mencegah AI seenaknya melonggarkan keputusan dengan bilang “ini izinkan saja pasti aman”. Yang ingin mendalami cara menulis prompt bisa lihat desain prompt Claude Code sekalian.

Tiga situasi di mana ini terasa manjur

1. Penggantian artikel blog Ingin mengganti satu link pendaftaran di bawah artikel populer. Kalau saat begini kita minta “perbaiki bagian yang sepertinya terkait”, cakupannya terlalu lebar. Tulis dulu di log “file yang boleh disentuh”, “file yang tidak disentuh”, dan “URL publik yang dicek”. Maka pengecekan setelah kerja berubah dari “kayaknya bagus” jadi “dengan bukti ini boleh dipublikasikan”.

2. Penyortiran pertanyaan masuk AI membaca pertanyaan yang masuk lalu memberi tahu mana saja yang sepertinya prospek. Membaca boleh “izinkan”. Tapi pendaftaran ke daftar pelanggan tetap di “konfirmasi”. Walau AI salah mengklasifikasi, ia berhenti sebelum seenaknya menulis ke data produksi.

3. Cek sebelum publikasi artikel multibahasa Walau pengaturan bahasa di frontmatter benar, kadang badan teks masih tersisa dalam bahasa Inggris. Lihat judul, pembuka, sampai CTA tiap bahasa, dan pastikan pembaca bahasa itu paham langkah berikutnya. Tetapkan pengecekan mata ini sebagai “item konfirmasi sebelum publikasi” di dalam log.

Siap pakai: skrip pengecekan log approval

Sudah menulis log, tapi kalau “pengecekan sebelum publikasi” yang krusial dilompati, percuma. Karena itu, jadikan pengecekan wajib sebelum publikasi sebagai satu skrip. Ini contoh yang menyuruh mesin memastikan apakah build lolos dan apakah judul di URL produksi benar. Asal ada Node.js, ini jalan.

node check-before-deploy.mjs https://claudecode-lab.com/blog/claude-code-permission-decision-log/

Isinya cuma ini.

import { execSync } from "node:child_process";

// Cek URL publik yang dioper lewat argumen
const url = process.argv[2];
if (!url) {
  console.error("Oper URL publik yang ingin dicek");
  process.exit(1);
}

// 1. Pastikan build lolos (kalau gagal di sini, tidak publikasi)
try {
  console.log("Mengecek build...");
  execSync("npm run build", { stdio: "inherit" });
} catch {
  console.error("Build gagal. Publikasi dihentikan.");
  process.exit(1);
}

// 2. Pastikan ada tepat satu judul h1 di URL publik
const res = await fetch(url);
const html = await res.text();
const h1Count = (html.match(/<h1[\s>]/g) || []).length;

if (res.status !== 200) {
  console.error(`URL tidak bisa dibuka (status code: ${res.status}). Tinjau ulang publikasi.`);
  process.exit(1);
}
if (h1Count !== 1) {
  console.error(`Ada ${h1Count} judul h1. Perbaiki jadi satu dulu sebelum publikasi.`);
  process.exit(1);
}

console.log("Build, URL, dan judul lolos cek. Aman untuk dipublikasikan.");

Hanya saat skrip ini hijau, “publikasi” baru diizinkan. Sebaliknya, yang tidak hijau tidak akan dipublikasikan apa pun yang terjadi. Triknya: titipkan keputusan bukan ke suasana hati manusia, tapi ke benar/salah dari mesin.

Kegagalan yang sering terjadi dan cara membenahinya

Jujur saja, saya sudah melakukan semua kesalahannya.

Mengubah pengaturan tanpa menulis alasan. Kalau hanya memperbarui file pengaturan tanpa menyisakan “kenapa begitu”, diri sendiri keesokan harinya mengulang kebingungan yang sama. Cara membenahinya sederhana: tulis satu baris alasan di “memo berikut” pada log. Seperti “harga langsung berhubungan dengan kepercayaan, jadi tetap konfirmasi”.

Mengizinkan publikasi karena terbawa momentum. Karena build lolos, terbawa semangat dan langsung mengizinkan sampai publikasi. Padahal pengecekan sebelum publikasi itu lain perkara. Tetapkan item yang melihat judul URL produksi, tampilan yang rusak, sampai tampilan ponsel sebagai “konfirmasi dulu”, dan jangan publikasi sampai cek mesin lolos.

Memperlakukan pekerjaan ringan dan berat dengan cara yang sama. Kalau perbaikan typo di badan teks dan perubahan link pendaftaran atau harga sama-sama diputar dengan “izinkan”, suatu saat terjadi kecelakaan seperti di pembuka. Pisahkan pekerjaan yang menyentuh link gumroad, harga, dan form ke rak yang berbeda dari perbaikan typo. Batas ini, kalau ditulis sebagai aturan di cara menulis CLAUDE.md, jadi tidak perlu dipikir tiap kali.

Pertanyaan umum

T. Apa beda log approval dan pengaturan keamanan? J. Pengaturan keamanan menetapkan “apa yang diizinkan”, sedangkan log approval menyisakan “kenapa hari ini keputusan itu diambil”. Pengaturan itu aturan, log lebih mirip buku harian. Dengan keduanya ada, diri sendiri keesokan harinya atau tim bisa mereproduksi keputusan yang sama.

T. Menulis tiap hari itu merepotkan. Ada trik agar konsisten? J. Jangan mengincar kesempurnaan. Awalnya, cukup dua kolom “ubah” dan “publikasi” pun sudah manjur. Buat dalam bentuk yang bisa ditulis 2-3 menit, lalu jadikan kebiasaan menempelnya sebagai input pertama sebelum mulai kerja, maka akan bertahan.

T. Boleh percaya pemilahan yang diusulkan AI? J. Sebagai draf memang praktis, tapi keputusan akhir di tangan manusia. Khususnya baris yang menyangkut harga, produksi, dan penghapusan, walau AI bilang “izinkan saja boleh”, turunkan sendiri ke konfirmasi. Tujuannya mengurangi beban memutuskan, bukan alat untuk melempar keputusan itu sendiri.

T. Apa yang perlu diperhatikan saat dipakai dalam tim? J. Kumpulkan log di satu tempat, dan untuk operasi yang masuk “izinkan”, tulis alasan yang membuat keputusannya sama bagi siapa pun yang melihat. Izin tanpa alasan akan ditafsirkan berbeda oleh tiap orang dan jadi sumber kecelakaan. Cara berpikir memperluas approval secara bertahap bisa dilihat di tangga menaikkan otonomi dengan aman.

T. Apakah blog kecil pun perlu sejauh ini? J. Justru makin kecil skalanya, kecelakaan harga atau link makin langsung berdampak ke pendapatan. Malah individu dan tim kecil yang layak mulai dari satu aturan “khusus uang dan produksi, dikonfirmasi”.

Tautan referensi

• Panduan izin Claude Code
• Panduan memulai Claude Code
• Resmi Anthropic: dokumentasi Claude Code settings

Hasil saat saya benar-benar mencobanya

Setelah menjalankan log approval ini sekitar dua minggu, yang paling manjur justru “pekerjaan ringan”. Perbaikan typo artikel bisa dengan tenang ditaruh di izinkan, tapi harga, link, form pendaftaran, dan pengaturan publikasi tetap di konfirmasi. Cukup menulis dulu pembedaan ini, dan beban berpikir ulang “ini pekerjaan yang boleh diizinkan bukan ya” setiap selesai membaca jawaban AI pun lenyap.

Yang paling sering bikin ragu memang “jalankan” dan “publikasi”. Build boleh diizinkan, tapi publikasi tanpa mengecek URL produksi masih terlalu dini. Setelah sekali memastikan dengan mata sampai judul, tampilan yang rusak, dan tampilan ponsel, jenis publikasi yang sama bisa saya naikkan ke izinkan untuk berikutnya. Karena tahapan begini tercatat, log approval lebih realistis dipakai sebagai memo untuk meringankan keputusan harian ketimbang sebagai dokumen keamanan yang kaku, itu yang saya rasakan sekarang.

Kalau Anda ingin merapikan batas izin untuk tim sendiri, atau ingin menyusun aturan publikasi produksi bersama, lewat training dan konsultasi kita bisa menerjemahkannya ke operasi nyata.