Sampai mana Claude Code boleh jalan sendiri? Aturan 4 tingkat otonomi anti-celaka

Jumat malam, saya minta Claude Code, “Tolong perbaiki link yang putus saja di artikel-artikel lama blog ini”, lalu saya tidur. Paginya saya cek riwayat commit: 12 artikel ikut berubah. Memang link-nya sudah benar. Tapi sekalian, gaya judul pun “dirapikan”, sampai ungkapan lama yang sengaja saya pertahankan ikut ditimpa.

Butuh 2 jam untuk mengembalikan semuanya. Kenapa Claude Code yang katanya pintar malah melakukan hal-hal di luar permintaan? Jawabannya sederhana: saya tidak pernah satu kali pun memberi tahu “sampai mana batas yang boleh dia kerjakan”.

Pola sebaliknya juga ada. Karena jadi takut, saya ubah pengaturan supaya setiap satu baris perubahan dia bertanya, “Ini boleh dijalankan?” Hasilnya, dalam 30 menit saya capek menekan tombol approve, dan akhirnya lebih cepat saya tulis sendiri. Terlalu dilepas lalu celaka, atau terlalu ditahan lalu capek. Banyak orang tersesat di antara dua kutub ini.

Artikel ini soal “4 tingkat otonomi” untuk mengakhiri kebingungan itu. Cukup baca saja, edit yang bisa dibatalkan, terbitkan, dan area khusus manusia, empat garis ini ditarik di awal, maka keputusan harian Anda nyaris hilang.

Poin penting

• Pekerjaan yang didelegasikan ke Claude Code lebih mudah diputuskan bila dibagi 4 tingkat berdasar risiko: hanya baca / edit yang bisa dibatalkan / terbit dan deploy / khusus manusia.
• Setiap tingkat wajib punya satu “bukti selesai”: muncul diff, build lolos, URL publik benar, dan sejenisnya.
• Hapus data, data produksi, tagihan, dan force push tidak pernah diotomatiskan, sebiasa apa pun. Hanya di sini manusia harus menekan tombol setiap kali.
• Tingkat ditulis dalam satu file YAML dan diletakkan dekat CLAUDE.md, supaya Claude Code sendiri bisa melapor “sekarang di tingkat berapa”.
• Mulai dari satu tingkat lebih rendah, lalu naikkan hanya operasi yang sudah terbukti aman. Jangan pernah arah sebaliknya.

Kenapa “garis batas” lebih penting daripada “kepintaran”

Kebanyakan orang yang tersandung dengan Claude Code gagal bukan karena performa model, tapi karena cara menutup pekerjaan. Saya di pembuka tadi begitu. Instruksinya sendiri tidak buruk. Hanya saja batas “cuma link” saya sampaikan lewat kalimat saja. Permintaan berupa kalimat itu seperti instruksi lisan ke rekan kerja yang sibuk di pagi hari: gampang sekali bergeser tafsirnya.

Di sinilah garis batas berdasar risiko jadi ampuh. Putuskan apa yang boleh dilakukan bukan lewat “kalimat permintaan”, tapi lewat “tingkat”. Maka setiap Claude Code hendak melakukan sesuatu, Anda bisa mencocokkan, “Itu operasi tingkat berapa?” Dari adu tafsir bahasa yang ambigu, berubah jadi cek yang mekanis.

Cara pikir ini bukan hal baru. Di pabrik pun, orang yang sekadar berkunjung, orang yang merakit komponen, orang yang menekan tombol pengiriman, dan orang yang membuka brankas, izinnya sudah dipisah sejak awal. Pada Claude Code kita cukup menarik garis yang sama.

Isi keempat tingkat

Empat tingkat yang sebenarnya saya pakai adalah sebagai berikut. Saya tampilkan gambaran besarnya lebih dulu lewat tabel.

Tingkat	Yang dikerjakan	Bukti selesai
0 Hanya baca	Memahami struktur file, mendaftar risiko, mengusulkan command verifikasi	Catatan akhir memuat “daftar file yang dibaca”
1 Edit yang bisa dibatalkan	Memperbaiki satu artikel, memperbarui satu test	Muncul diff dan build lolos
2 Terbit dan deploy	Deploy setelah build, verifikasi URL publik	h1, canonical, CTA, dan langkah rollback lengkap
3 Khusus manusia	(Tidak dikerjakan Claude Code)	—

Yang masuk tingkat 3 adalah secret key, tagihan, data produksi, dan force push. Di sini, sebiasa apa pun, kita tidak mengotomatiskan. Kerugian saat salah tidak sebanding dengan repot yang dihemat.

Yang penting di tiap tingkat adalah memastikan ada “bukti selesai”. Tanpa bukti, walau Claude Code bilang “sudah selesai”, kita tak tahu apakah benar selesai. Muncul diff, build lolos, buka URL publik dan h1 benar, hal-hal yang bisa diperiksa mesin inilah yang dipilih jadi bukti.

Yang didelegasikan ke AI, dan yang diputuskan manusia

Begitu garis batas jelas, pembagian peran pun jadi alami.

Yang boleh didelegasikan ke Claude Code adalah pekerjaan bervolume tinggi yang hasilnya bisa diperiksa mesin. Membaca banyak file lalu meringkas, memperbaiki artikel dengan format tetap, menjalankan test lalu membaca log. Hal-hal ini lebih cepat dan akurat dibanding manusia.

Yang harus diputuskan manusia adalah keputusan yang tak bisa dibatalkan, dan operasi yang kerugiannya besar. Apakah artikel ini benar layak terbit, apakah ungkapan lama ini boleh dihapus, apakah data pelanggan ini boleh ditimpa. Di sini, Claude Code boleh “mengusulkan”, tapi “eksekusi” ditekan manusia.

Saat ragu, patokannya cuma satu. “Kalau gagal, bisa dikembalikan dalam 10 menit?” Kalau bisa, itu tingkat 1; kalau tidak bisa, tingkat 2 atau 3. Celaka saya di pembuka tadi, begitu butuh 2 jam untuk mengembalikan, sebenarnya itu pekerjaan yang perlu kehati-hatian tingkat 2.

Definisi tingkat yang siap salin

Kalau tingkat hanya disimpan di kepala, akhirnya tetap goyah. Tuliskan ke satu file YAML dan letakkan tepat di root proyek sebagai autonomy.yml. Bila dirujuk dari CLAUDE.md, Claude Code sendiri akan melapor “sekarang tingkat 1, jadi saya tidak menerbitkan”.

# autonomy.yml — garis batas otonomi yang diberikan ke Claude Code
safe_autonomy_ladder:
  level_0_read_only:
    allowed: ["pahami struktur file", "daftar risiko", "usulkan command verifikasi"]
    proof: "catatan akhir memuat daftar file yang dibaca"
  level_1_reversible_edit:
    allowed: ["perbaiki satu artikel", "perbarui satu test"]
    proof: "git diff muncul dan build lolos"
  level_2_publish_or_deploy:
    allowed: ["deploy setelah build", "verifikasi URL publik"]
    proof: "h1, canonical, CTA, dan langkah rollback lengkap"
  level_3_owner_only:
    allowed: []
    examples: ["secret key", "tagihan", "force push", "data pelanggan"]

Pada CLAUDE.md cukup tambahkan satu kalimat berikut.

Sebelum bekerja, baca autonomy.yml dan deklarasikan dulu pekerjaan kali ini ada di tingkat berapa.
Operasi tingkat 2 ke atas tidak dieksekusi, tunggu persetujuan manusia.

Skrip verifikasi untuk mengecek tingkat secara mekanis

Karena hanya mengandalkan deklarasi terasa kurang aman, saya mengawasi secara mesin apakah “operasi tingkat 2 (terbit) terjadi tanpa bukti”. Skrip di bawah, setelah deploy, mengambil URL publik lalu memastikan h1 tidak kosong dan canonical menunjuk slug Anda sendiri. Dengan Node.js 18 ke atas, langsung jalan.

// verify-publish.mjs — periksa "bukti selesai" tingkat 2 secara mekanis
// Cara pakai: node verify-publish.mjs https://claudecode-lab.com/blog/your-slug

const url = process.argv[2];
if (!url) {
  console.error("Berikan URL publik sebagai argumen");
  process.exit(1);
}

const res = await fetch(url);
if (res.status !== 200) {
  console.error(`HTTP ${res.status}: belum berhasil terbit`);
  process.exit(1);
}

const html = await res.text();

// Apakah h1 ada dan ada isinya
const h1 = html.match(/<h1[^>]*>(.*?)<\/h1>/s);
const hasH1 = Boolean(h1 && h1[1].replace(/<[^>]+>/g, "").trim());

// Apakah canonical menunjuk halaman ini sendiri
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]*>/i);
const canonicalOk = Boolean(canonical && canonical[0].includes(new URL(url).pathname));

console.log(`h1 ada:          ${hasH1 ? "OK" : "NG"}`);
console.log(`canonical cocok: ${canonicalOk ? "OK" : "NG"}`);

if (hasH1 && canonicalOk) {
  console.log("Bukti tingkat 2 lengkap. Bisa dianggap selesai terbit.");
} else {
  console.error("Bukti belum cukup. Jangan dianggap selesai dulu.");
  process.exit(1);
}

Kalau Anda mengira HTTP 200 saja berarti sukses, Anda tak akan sadar walau yang muncul adalah halaman fallback beranda atau artikel lama. Setelah memeriksa h1 dan canonical, barulah bisa dibilang “tingkat ini selesai”.

Tiga situasi tempat ini ampuh

1. Tepat setelah masuk repo baru Membiarkan langsung mengedit padahal struktur dan command-nya belum dipahami sering merusak file konfigurasi. Awalnya izinkan hanya tingkat 0, lalu minta dia laporkan susunan file, command yang bisa dipakai, dan area berbahaya kalau disentuh. Setelah peta jadi, baru naik ke tingkat 1.

2. Memperbaiki typo artikel Ini cukup tingkat 1. Begitu muncul diff dan build lolos, bukti pun lengkap. Celaka saya di pembuka tadi, kalau di sini saya menulis jelas batasnya “perbaikan typo saja, jangan ubah gaya kalimat”, pasti tercegah. Template kalimat permintaan ke Claude Code seperti ini.

Kerjakan di tingkat 1.
Target: hanya typo dan salah ketik yang jelas pada content/blog/foo.mdx
Yang tidak boleh: parafrase judul, ubah gaya bahasa, edit file lain
Setelah selesai tunjukkan git diff, dan cek sendiri apakah perubahannya hanya perbaikan typo.

3. Tepat sebelum terbit ke produksi Pada tingkat 2, wajib minta dia memastikan: build lolos, variabel lingkungan lengkap, diff sesuai dugaan, dan ada langkah rollback. Jalankan skrip verifikasi di atas sebagai langkah terakhir, maka isi URL publik pun ikut tercek.

Tiga kesalahan yang pernah saya buat

Jujur saja, sampai mengendap di 4 tingkat ini saya berkali-kali celaka.

Pertama, melompati tingkat sekaligus. Saya lewati tingkat 0 dan langsung minta edit besar di tingkat 1, hasilnya muncul diff yang terlalu besar untuk diverifikasi, sampai saya sendiri tak tahu mana yang benar. Sekarang saya selalu naik berurutan dari 0.

Kedua, menganggap “selesai” hanya dari build lokal. Karena di lokal lolos, saya terbitkan. Tapi di produksi yang tampil halaman lama, dan setengah hari saya tak sadar. Sejak itu, saya tidak menganggap selesai sampai melihat h1 dan canonical URL publik.

Ketiga, mengandalkan persetujuan hanya pada mata saya sendiri. “Nanti saya cek terakhir saja” pasti runtuh di malam saat lelah. Sejak saya memasukkan cek yang bisa dipahami mesin, jumlah karakter, link putus, error tipe, ke dalam “bukti” tiap tingkat, kelewatan tengah malam turun drastis.

Cara memulai

Jangan langsung mengincar agen pintar serba otomatis. Pilih satu pekerjaan kecil yang bisa dibatalkan walau gagal. Cek typo draf, tinjauan awal sebuah perubahan, verifikasi sebelum terbit ke staging. Sekitar inilah yang pas.

Urutannya selalu sama. (1) Tentukan sempit batas yang boleh dibaca, (2) perjelas hasil keluarannya, (3) sebisa mungkin serahkan verifikasi ke command, (4) operasi berbahaya (hapus, data produksi, tagihan, force push) awalnya semua diset “tanya manusia”. Hanya operasi yang sudah terbukti aman yang dinaikkan setingkat demi setingkat. Penurunan tingkat ke arah sebaliknya tidak dilakukan.

Kalau Anda tersandung di pengaturan izin yang rinci, baca dulu cara memulai Claude Code; untuk cara menulis aturan tingkat di CLAUDE.md, lihat cara menulis CLAUDE.md, maka 4 tingkat ini bisa langsung diterjemahkan jadi konfigurasi. Kalau premisnya orang non-engineer yang akan masuk tim, baca juga cara pakai untuk non-engineer.

Pertanyaan umum

T. Pembagian tingkat itu, apa harus diset manual tiap kali? Tidak. Buat satu autonomy.yml dan rujuk dari CLAUDE.md, maka setelahnya Claude Code sendiri yang mendeklarasikan “sekarang tingkat 1”. Pengaturannya cukup sekali di awal.

T. Apakah aman mengotomatiskan sampai “terbit” tingkat 2? Kalau buktinya bisa dilengkapi mesin, boleh diotomatiskan setelah Anda terbiasa. Tapi wajib menyelipkan mekanisme yang memeriksa isi URL publik, seperti skrip verifikasi di atas. Mempercayai HTTP 200 saja itu yang paling berbahaya.

T. Bagaimana membedakan operasi yang harus masuk tingkat 3? Pikirkan lewat “kalau gagal cukup minta maaf, atau perlu ganti rugi?” Menimpa data pelanggan, tagihan, dan hapus di produksi termasuk yang kedua, jadi tingkat 3. Sebiasa apa pun tidak diotomatiskan.

T. Apa tim kecil pun perlu garis batas? Justru makin sedikit orang makin ampuh. Siapa yang menyetujui jadi mudah kabur, jadi dengan membagikan tabel tingkat, “operasi ini siapa yang memberi OK” terlihat sekali pandang.

T. Kalau prompt-nya disusun rapi, bukankah pembagian tingkat tak perlu? Prompt itu tafsirnya goyah. Kemampuan menulis permintaan yang baik dilatih terpisah di praktik prompt; sementara pembagian tingkat adalah “jaring pengaman yang tidak bergantung pada kemahiran kalimat”. Kalau keduanya ada, itu paling kuat.

Hasil yang benar-benar saya coba

Sejak memasukkan 4 tingkat ini ke operasi blog saya sendiri, celaka seperti di pembuka “dikerjai hal yang tidak diminta” jadi nol. Yang saya pastikan ada 2 hal.

Satu, setelah autonomy.yml dirujuk dari CLAUDE.md, Claude Code mulai mendeklarasikan sendiri sebelum bekerja, “kali ini tingkat 1 jadi tidak menerbitkan”. Saya merasakan langsung bahwa kalau garis batas diberikan lewat tingkat, bukan kalimat, tafsirnya tak goyah.

Satu lagi, setelah saya wajibkan menjalankan verify-publish.mjs tiap selesai terbit, fenomena “halaman lama tampil di produksi” yang dulu setengah hari tak saya sadari, kini bisa terdeteksi tepat setelah terbit. Cukup melihat h1 dan canonical, jebakan HTTP 200 pun tertutup.

Daripada mencari model yang lebih pintar, lebih dulu tentukan tingkat yang membuat tidak cedera walau jatuh. Terlihat memutar, tapi inilah yang paling cepat, begitu yang saya rasakan sekarang. Kalau tim Anda sudah di tahap ingin merapikan aturan izin Claude Code, di pelatihan dan konsultasi kita bisa merancang garis batas itu bersama. Untuk pengaturan izin resmi, cek juga dokumentasi Anthropic.