Sampai mana Claude Code boleh jalan hari ini? Worksheet 4 level untuk menentukan batas approval

Jumat sore, niat saya cuma satu: menambal perbaikan kecil di lingkungan staging.

Saya hanya minta, “Perbaiki salah ketik di dokumentasi, sekalian cek apakah build-nya lolos.” Setelah membetulkan salah ketik, Claude Code malah memperbarui dua paket dependensi atas inisiatifnya sendiri, bahkan menyentuh referensi di .env.production. Karena build lokal lolos, si Aom—maaf, si AI—dengan tenang berkata “Selesai.”

Yang bikin saya merinding: saya baru sadar saat membaca diff sampai baris terakhir. Ini bukan soal AI-nya nakal, melainkan saya tidak pernah sekali pun menyebutkan “boleh sampai mana” secara eksplisit.

Sebaliknya, di hari lain, prompt “izinkan? Ya/Tidak” muncul sekitar 30 kali beruntun, dan tenaga saya habis hanya untuk membuat satu commit. Terlalu lebar, kecelakaan; terlalu sempit, mandek. Artikel ini soal satu lembar worksheet untuk menarik garis pas di antara keduanya.

Poin penting

• Bagi pekerjaan Claude Code jadi 4 level: “hanya membaca”, “hanya memperbaiki”, “memublikasikan”, dan “menyentuh data rahasia”.
• Untuk tiap level, tentukan lebih dulu “siapa yang memberi OK terakhir” dan “bukti apa yang membuatnya aman”.
• Level 0 dan 1 didelegasikan ke AI, level 2 dicek manusia, level 3 hanya disentuh penanggung jawab.
• Deklarasikan “hari ini sampai sini” dalam satu kalimat di pagi hari, dan jumlah approval langsung anjlok.
• Saya siapkan kode ledger yang bisa di-copy-paste plus template 1 menit untuk diputuskan tiap pagi.

Kenapa “anggaran approval” harus ditentukan lebih dulu

Penyebab kelelahan approval bukan kemampuan Claude Code, melainkan Anda mulai berlari tanpa menentukan sampai mana hari ini diizinkan.

Tanpa keputusan itu, orang jatuh ke salah satu dari dua sisi. Karena malas, terus menekan “izinkan” untuk semuanya, lalu suatu hari meloloskan operasi berbahaya. Atau jadi terlalu hati-hati, menyelipkan konfirmasi bahkan untuk perbaikan salah ketik, sampai pekerjaan tak maju. Keduanya sama: keputusan diserahkan ke “suasana hati saat itu”.

Di situlah konsep “anggaran approval” dipakai. Sama seperti anggaran uang: hari ini bebas sampai jalur ini, lebih dari itu manusia yang memutuskan, tentukan batasnya lebih dulu. Dengan batas yang jelas, Anda tak perlu deg-degan tiap kali membaca balasan AI. Yang Anda lihat bukan “apakah AI-nya pintar”, melainkan “di jalur mana ia berhenti”.

Kalau kriteria keputusan ditulis sebagai kata-kata, tim pun tak ribut. Bukan “saya hentikan karena entah kenapa cemas”, melainkan “ini level 2, jadi giliran manusia mengecek”. Cara berpikir desain izin juga disinggung di Panduan memulai Claude Code, tapi di sini saya fokus ke hal yang lebih praktis: menarik garis untuk hari ini.

Bagi pekerjaan ke dalam 4 level

Pertama, urutkan pekerjaan yang ingin Anda serahkan ke Claude Code menurut tingkat bahayanya, jadi empat level. Tak usah rumit—cukup pilah dengan tiga pertanyaan: “bisa dibatalkan?”, “akan terpublikasi?”, “menyentuh uang atau rahasia?”.

Level	Contoh pekerjaan	Pemberi OK terakhir	Bukti aman
0	Membaca file, memahami struktur	Didelegasikan ke AI	Daftar cakupan yang dibaca
1	Memperbaiki 1 file yang bisa dibatalkan	AI (manusia melihat diff)	Diff dan hasil build
2	Menerapkan ke situs publik	Manusia memutuskan	URL publik dan langkah rollback
3	Menyentuh rahasia, billing, data pelanggan	Hanya penanggung jawab	Persetujuan tertulis

Inti tabel ini ada di dua kolom kanan. Tentukan “siapa yang memberi OK” dan “bukti apa yang membuatnya aman” sebelum pekerjaan dimulai. Kalau ditentukan belakangan, Anda akan terbawa euforia saat AI bilang “selesai” dan melewatkan pengecekan.

Kunci level 1 ada di frasa “bisa dibatalkan”. Perbaikan salah ketik atau penambahan komentar bisa langsung dikembalikan kalau salah. Karena itu serahkan ke AI, manusia cukup melirik diff sekilas. Sebaliknya, pembaruan paket dependensi naik ke level 2. Walau tampak sepele, dampaknya sulit diprediksi. Kecelakaan saya di awal artikel justru terjadi karena saya menganggapnya level 1.

Yang didelegasikan ke AI vs yang Anda putuskan sendiri

Mari pertegas garisnya. Yang boleh didelegasikan ke AI adalah pekerjaan yang kalau salah langsung ketahuan dan langsung bisa dikembalikan. Yang harus manusia putuskan adalah pekerjaan yang begitu dieksekusi langsung berdampak ke luar.

• Didelegasikan ke AI: membaca, meneliti, membuat draf, memperbaiki 1 file yang bisa dibatalkan, menjalankan test
• Diputuskan manusia di akhir: memublikasikan, mengubah data produksi, mendaftar ke layanan eksternal, memperbarui dependensi, menghapus

Kalau ragu, naikkan satu level. Ingat ini saja, Anda tak akan meleset jauh. Hanya operasi yang sudah benar-benar Anda yakini aman yang boleh diturunkan satu level untuk diotomasi belakangan. Triknya: jangan mengincar serba-otomatis sejak awal. Pola “menaikkan kelas bertahap” ini cocok dengan cara menulis CLAUDE.md, jadi simpan garis yang sudah Anda tentukan ke dalam file agar bisa direproduksi.

Ledger approval yang bisa di-copy-paste

Kalau hanya kata-kata, mudah lupa. Maka ubah 4 level itu jadi bentuk yang bisa dibaca mesin, sehingga “hari ini sampai mana” bisa difilter. Cukup ada Node.js, kode ini langsung jalan.

// Ledger approval: tiap pekerjaan punya "level bahaya", "pemilik", dan "bukti"
const approvalBudget = [
  { action: "Membaca file",                  level: 0, owner: "AI",                proof: "Daftar cakupan yang dibaca" },
  { action: "Perbaiki 1 file yang reversible", level: 1, owner: "AI (manusia cek)",  proof: "Diff dan hasil build" },
  { action: "Terapkan ke situs publik",      level: 2, owner: "Manusia",           proof: "URL publik dan langkah rollback" },
  { action: "Menyentuh rahasia atau billing", level: 3, owner: "Penanggung jawab saja", proof: "Persetujuan tertulis" },
];

// Batas hari ini. 0 berarti hanya membaca, 1 berarti delegasikan sampai perbaikan reversible
const todayMax = Number(process.env.APPROVAL_MAX ?? 1);

const allowedToday = approvalBudget.filter((item) => item.level <= todayMax);
const needsHuman   = approvalBudget.filter((item) => item.level > todayMax);

console.log(`Batas delegasi AI hari ini: level ${todayMax}`);
console.table(allowedToday);
console.log("Pekerjaan yang diputuskan manusia:");
console.table(needsHuman);

Menjalankannya cukup begini. Anda bisa mengganti “batas hari ini” lewat environment variable.

# Hari ini delegasikan sampai "perbaikan yang reversible"
APPROVAL_MAX=1 node approval-budget.mjs

# Hari ini cukup membaca saja
APPROVAL_MAX=0 node approval-budget.mjs

Biarkan nama kolomnya, lalu sesuaikan isi action dan proof dengan proyek Anda. Serahkan kode ini ke Claude Code dan minta “isi nilainya untuk repo kami”, maka draf awalnya langsung jadi.

Template prompt 1 menit tiap pagi

Setelah ledger siap, sampaikan “batas hari ini” ke AI sebelum mulai bekerja. Salin kalimat berikut, lalu isi bagian kosongnya.

Saya tentukan dulu batas pekerjaan hari ini.

- Tujuan hari ini: (contoh: perbaiki salah ketik dan link rusak di 1 artikel blog)
- Cakupan yang boleh dibaca: hanya site/src/content/blog/
- Cakupan yang boleh diperbaiki: hanya 1 file di dalamnya (terbatas pada perubahan yang reversible)
- Perintah yang boleh dijalankan: npm run lint, menjalankan test
- Yang tak boleh disentuh: .env, deploy produksi, pembaruan paket dependensi, penghapusan

Aturan:
- Level 2 ke atas (publikasi, data produksi, update dependensi, penghapusan) wajib berhenti dan konfirmasi ke saya dulu.
- Setelah memperbaiki, tunjukkan diff perubahan dan hasil build sebagai "bukti" di akhir.
- Jangan berhenti di "selesai" saja; tulis dengan perintah apa Anda memverifikasinya.

Dengan satu kalimat ini saja, AI berhenti “mengerjakan semua sekaligus” dan mulai bergerak di dalam batas. Setelah terbiasa, pindahkan isi ini ke file aturan proyek sesuai cara menulis CLAUDE.md, maka repot menempel tiap pagi pun hilang.

Tiga lapangan tempat ini berguna

1. Cek produksi massal blog atau materi Kalau hanya bilang “perbaiki artikelnya”, AI akan menulis ulang isi, path gambar, dan link sekaligus. Dengan ledger approval yang memilah “salah ketik isi itu level 1, penerapan publikasi level 2”, Anda menyerahkan teks tapi tetap memegang tombol publish. Kalau diff dan hasil build dikeluarkan sebagai bukti, peninjauan tengah malam jadi jauh lebih ringan.

2. Triase tiket masuk Membaca tiket yang masuk lalu mengklasifikasikannya itu level 0, boleh didelegasikan ke AI. Tapi mendaftarkannya ke ledger pelanggan itu level 3. Walau AI menilai “ini berpotensi jadi deal”, penulisan ke database produksi ditahan sampai penanggung jawab menekan tombolnya. Dengan memaksakan ini lewat ledger, kecelakaan “mendaftarkan pelanggan salah klasifikasi tanpa izin” pun lenyap.

3. Tarik napas sebelum deploy Penerapan publikasi selalu ditaruh di level 2. Jangan menganggap “selesai” hanya karena build lokal lolos; berhenti sampai URL publik, judul, dan langkah rollback diverifikasi. Kecelakaan “update dependensi tanpa izin” yang saya lakukan di awal pun pasti akan tertahan di pengecekan manusia kalau level 2 sudah eksplisit.

Kesalahan umum dan cara memperbaikinya

Yang paling sering: mencoba menyelesaikan semua dalam satu permintaan, lalu membuat diff raksasa yang tak bisa diverifikasi siapa pun. Perbaikannya sederhana—batasi permintaan jadi “satu hasil per permintaan”. Satu artikel, satu PR, satu titik konfigurasi. Kalau dipotong kecil, Anda bisa membaca diff sampai habis.

Berikutnya: menganggap selesai hanya karena build lokal sukses. Padahal di situs publik yang muncul halaman lain atau beranda, tapi Anda sudah tenang karena melihat HTTP 200 saja. Masukkan “verifikasi URL publik dan judul” ke kolom bukti, dan Anda bisa berhenti di sini.

Ketiga: tidak menyimpan apa yang sudah dicoba. Esoknya Anda mengulang keputusan yang sama dari nol. Cukup tinggalkan satu baris memo yang dibahas di bawah, dan diri Anda esok hari tak akan bingung. Kalau ingin meningkatkan cara meminta ke Claude Code itu sendiri, baca juga praktik perancangan prompt, maka cara menyampaikan batas jadi satu tingkat lebih baik.

Pertanyaan umum

Q. Apakah level approval sebaiknya dibagi lebih rinci? Awalnya 4 level sudah cukup. Makin banyak, operasinya makin rumit dan ujungnya tak ditaati. Setelah dijalankan, cabangkan hanya bagian yang Anda rasa “masih kasar”.

Q. Bagaimana membedakan apakah level 1 itu “bisa dibatalkan”? Nilai dengan dua poin: “bisa dikembalikan dengan satu perintah git?” dan “tidak berdampak ke luar?”. Mengedit file bisa dikembalikan, tapi deploy, billing, kirim email, dan penghapusan tidak bisa. Kalau ragu, naikkan ke level 2.

Q. Saat dipakai di tim, siapa yang menentukan level? Orang yang memulai pekerjaan mendeklarasikan di pagi hari, dan penentu untuk level 2 ke atas ditetapkan lebih dulu. Kalau penanggung jawab tak ada, putuskan bahwa pekerjaan level 3 tidak dikerjakan hari itu—lebih aman.

Q. Menempel prompt tiap kali itu merepotkan. Setelah batas mengeras, pindahkan ke file aturan proyek (CLAUDE.md). AI membacanya tiap kali, jadi tak perlu menempel lagi.

Q. Apakah worksheet ini bisa dipakai non-engineer? Bisa. Tanpa menjalankan kode pun, garis bisa ditarik hanya dengan tabel 4 level dan template prompt. Untuk pemanfaatan di luar engineer, Claude Code untuk non-engineer bisa jadi rujukan.

Memo untuk serah terima

Kalau keputusan hari itu disimpan dalam satu baris, diri Anda esok atau tim tak mengulang kebingungan yang sama. Salin format berikut dan isi saja.

- Tanggal: 2026-06-07
- Tujuan hari ini: perbaikan salah ketik dan link rusak di 1 artikel blog
- Batas hari ini: level 1 (sampai perbaikan yang reversible)
- Bukti: diff, log npm run build, verifikasi judul URL publik
- Tempat manusia berhenti: update dependensi (ditahan karena level 2)
- Catatan untuk berikutnya: update dependensi dilakukan terpisah, dikumpulkan di hari lain pada level 2

Dengan memo ini, pengecekan setelah publikasi pun jadi ringan. HTTP 200 saja tidak cukup, jadi lihat di URL publik apakah judul, URL kanonik (canonical), gambar eyecatch, dan awal isi benar-benar milik artikel ini. Kalau yang muncul artikel lain atau beranda, anggap belum terpublikasi, lalu ulangi build dan deploy. Cara berpikir resmi soal desain izin bisa Anda cek di dokumentasi resmi Anthropic.

Hasil setelah saya benar-benar mencobanya

Saya menerapkan worksheet ini ke operasi blog saya sendiri selama dua minggu.

Yang paling terasa: kebiasaan menempel satu kalimat “hari ini sampai level 1” di pagi hari. Hanya dengan itu, prompt “izinkan?” per commit terasa berkurang sampai kurang dari separuh. Saat AI hendak melangkah ke level 2 ke atas, ia berhenti persis sesuai aturan template dan bertanya ke saya. Kecelakaan seperti di awal—“tahu-tahu dependensi sudah terupdate”—sejak itu nol.

Sebaliknya, saya juga sadar: tabel level kalau cuma dibuat tidak akan dipakai. Jalankan kode ledger-nya, tampilkan “pekerjaan yang didelegasikan hari ini” di layar, baru mulai—peluang menaatinya jadi naik. Daripada mencari AI yang lebih pintar, tarik dulu batas yang bisa dikembalikan saat terjatuh. Sederhana, tapi inilah cara mendelegasikan dengan paling minim stres, menurut pengalaman saya saat ini.

Kalau Anda ingin memperluas garis ini ke seluruh tim atau operasi produksi, lewat pelatihan dan konsultasi kita bisa merumuskan desain jalur yang konkret bersama. Mulailah besok pagi dengan menempel satu kalimat: “hari ini sampai level 1”.