Risk register sebelum adopsi Claude Code di tim

Jumat sore, rekan kerja saya nyeletuk: “Claude Code enak banget, minggu depan kita pakai bareng-bareng yuk.”

Saya langsung punya firasat buruk. Waktu dia pakai sendiri, dia me-review branch-nya sendiri lalu merge sendiri. Kalau ada kecelakaan, korbannya cuma dia. Tapi begitu dipakai satu tim, ceritanya beda. Atas izin siapa, sampai mana boleh diutak-atik, dan siapa yang mengecek perubahannya? Kalau hal ini belum disepakati lalu enam orang langsung pakai bareng, perubahan yang menghapus database produksi bisa diam-diam ke-merge tanpa ada yang sadar.

Kebetulan saya pernah mengalaminya di tim lain. Tiga orang menjalankan Claude Code dengan setelan masing-masing, lalu satu orang minta “rapikan biar enak dilihat”, dan file konfigurasi bersama ikut tertulis ulang. Senin pagi semua deploy gagal. Mencari penyebabnya makan setengah hari. Tidak ada yang berniat jahat. Cuma memang belum ada “aturan saat menyerahkan kerja ke AI dalam tim”.

Dari situlah lahir risk register yang saya bahas di artikel ini. Disebut register, tapi isinya cuma satu tabel. Tapi ada atau tidaknya tabel ini menentukan apakah adopsi Claude Code di tim berakhir dengan “jadi lebih ringan” atau “habis tenaga buat menangani insiden”.

Poin penting

• Insiden saat adopsi tim bukan soal model yang kurang pintar, tapi soal “siapa, sampai mana, dan atas konfirmasi siapa” yang belum ditentukan.
• Risk register adalah tabel yang menulis “penanggung jawab, cara verifikasi, syarat lanjut” dalam satu baris untuk tiap area berbahaya. Mulai dari 3 baris saja sudah cukup.
• Kunci tiga hal di awal: permission (file mana yang boleh disentuh), CI (bukti perubahan tidak rusak), dan publikasi (konfirmasi perubahan benar-benar tayang).
• Yang diserahkan ke Claude Code hanya sampai “membuat draf dan menjalankan verifikasi”. Hapus file, database produksi, transaksi berbayar, dan force push wajib disetujui manusia.
• Saya sertakan template register siap salin dan contoh setelan yang menolak operasi berbahaya. Triknya: coba dulu dengan satu file saja.

Risk register itu sebenarnya apa?

Risk register adalah tabel yang mendaftar “tempat yang gampang celaka” saat menyerahkan kerja ke Claude Code dalam satu tim.

Tiap baris cukup tiga kolom. Di mana bahayanya, apa bukti bahwa itu aman, dan siapa yang mengecek. Cuma itu. Tidak perlu tools manajemen yang rumit. Awalnya satu lembar spreadsheet pun cukup, bahkan sekadar array di dalam kode juga jalan.

Kenapa harus ditabelkan? Karena “ya pokoknya hati-hati” justru paling berbahaya. Saat orang sibuk, pasti ada konfirmasi yang dilewati. Kalau ditabelkan dan disepakati “jangan merge sebelum baris ini terisi”, insiden berhenti bahkan di Jumat sore yang sibuk. Insiden deploy di awal tadi pun bisa dicegah cukup dengan menulis satu baris: file konfigurasi bersama sebagai “area yang tidak boleh disentuh”.

Tiga titik bahaya yang dikunci lebih dulu

Tempat tim tersandung saat adopsi biasanya terkumpul di tiga hal ini. Sebaliknya, kalau tiga ini sudah ada di register, kecelakaan besar di hari pertama hampir pasti bisa dicegah.

1. Permission (file mana yang boleh disentuh)

Insiden paling sering adalah “diberi akses terlalu luas”. Kalau Anda minta “rapikan repository ini”, Claude Code akan santai menulis ulang file konfigurasi dan definisi CI sekalipun. Maka, tetapkan lebih dulu mana area yang boleh diedit dan mana yang sama sekali tidak boleh disentuh, lalu tulis dalam kata-kata.

Patokan saya sederhana. Artikel, draf, dan kode tes boleh disentuh. .github/, environment variable produksi, setelan deploy, dan migrasi database masuk kategori “berhenti sampai manusia mengecek”. Kalau garis ini diserahkan ke selera masing-masing, aturan jadi berbeda-beda antar orang, dan akhirnya setelan orang paling longgar yang memicu insiden. Menyatukannya jadi satu untuk seluruh tim itu kuncinya.

2. CI (paksa keluarkan bukti tidak rusak)

Kalau Claude Code bilang “sudah saya perbaiki”, itu kesan, bukan bukti. Maka, tulis di register perintah yang mengeluarkan bukti bahwa perubahan tidak rusak. Build lolos, tes hijau, atau tidak ada error tipe. Salah satunya wajib dijalankan “sebelum melaporkan keberhasilan”.

Yang penting di sini, buat perintah verifikasi itu cepat. Kalau tes lengkap butuh 10 menit, tidak ada yang mau menjalankannya. Kalau hanya tes yang berkaitan dengan file yang diubah dan selesai dalam 30 detik, konfirmasi jadi kebiasaan.

3. Publikasi (perubahan yang tayang wajib dilihat sendiri)

Entah halaman monetisasi blog atau API, perubahan yang tampil ke luar wajib disertai catatan “sudah dilihat di URL asli”. Build lolos dan halaman yang benar-benar dilihat pengguna itu benar adalah dua hal berbeda. Buka URL produksi, simpan satu screenshot. Jadikan itu syarat penyelesaian.

URL publik mengembalikan 200 pun, kalau isinya halaman lain, sama saja belum tayang. Halaman berbahasa Indonesia tapi isinya tercampur teks bahasa Inggris, itu juga belum selesai. Kelihatan jelas, tapi justru di hari yang buru-buru langkah ini paling sering dilompati.

Yang diserahkan ke AI dan yang diputuskan manusia

Kalau bingung menarik garis, pakai langsung tabel ini. Sumbu penilaiannya adalah “bisa dibalikkan atau tidak”.

Operasi	Serahkan ke Claude Code	Eksekusi setelah disetujui manusia
Membuat dan merevisi draf	OK
Menjalankan tes dan build	OK
Menjelaskan isi perubahan (ringkasan diff)	OK
Menghapus file		OK
Menulis ke database produksi		OK
Operasi yang menimbulkan biaya		OK
Force push dan menulis ulang history		OK
Deploy dan publikasi produksi		OK

Aturannya satu. Operasi yang sulit dibalikkan, di awal jadikan semua “tanya dulu ke manusia”. Hanya operasi yang sudah terbukti aman yang kemudian dinaikkan ke otomatis. Daripada longgar dari awal lalu celaka, lebih cepat memulai ketat lalu melonggarkan sedikit demi sedikit.

Template risk register siap salin

Pertama, sebelum meminta tolong, buat instruksi yang diberikan ke Claude Code jadi template. Cukup tempel ini tiap kali, dan perluasan kerja yang seenaknya bisa dicegah.

Sebelum bekerja, patuhi hal berikut.
- Yang boleh diedit hanya di dalam src/content/ dan tests/.
- Jangan sentuh .github/, environment variable produksi, setelan deploy, dan migrasi DB. Kalau perlu menyentuhnya, jangan diedit, laporkan alasannya.
- Setelah perubahan, selalu jalankan `npm run check` dan laporkan hasilnya.
- Kalau perlu menghapus file, menulis DB produksi, transaksi berbayar, atau force push, jangan dieksekusi, minta konfirmasi.
Sebelum mengedit, ulangi batasan di atas dengan kata-katamu sendiri, lalu mulai bekerja.

Lalu register-nya sendiri. Awalnya 3 baris sudah cukup. Ganti dengan titik bahaya tim Anda sendiri.

// Risk register adopsi tim: tulis "penanggung jawab, bukti, syarat lanjut" satu baris per titik bahaya
type RolloutRisk = {
  area: string;       // area yang berbahaya
  risk: string;       // apa yang bisa terjadi
  owner: string;      // penanggung jawab konfirmasi
  proof: string;      // bukti bahwa aman
  nextGate: string;   // syarat boleh lanjut
};

const rolloutRisks: RolloutRisk[] = [
  {
    area: "permission",
    risk: "Claude Code menulis ulang sampai konfigurasi bersama",
    owner: "lead",
    proof: "daftar boleh-edit dan dilarang-edit terdokumentasi",
    nextGate: "coba dulu satu file saja",
  },
  {
    area: "CI",
    risk: "perintah verifikasi lambat atau tidak ada",
    owner: "developer",
    proof: "build hijau, atau hanya tes terkait yang hijau",
    nextGate: "masukkan langkah verifikasi ke template PR",
  },
  {
    area: "publikasi",
    risk: "perubahan yang tayang belum dicek di halaman asli",
    owner: "ops",
    proof: "screenshot URL publik",
    nextGate: "simpan catatan prosedur rollback",
  },
];

console.table(rolloutRisks);

Simpan agar bisa jalan dengan node lalu eksekusi, dan tabelnya akan tercetak. Tidak megah, tapi nilainya ada pada “bisa menuangkan titik bahaya jadi kata-kata sebelum mulai kerja”. Kalau aturannya jadi “jangan merge sebelum tiap baris terisi”, register berubah jadi penjaga gerbang yang mencegah insiden.

Cocok untuk tim seperti ini (tiga contoh)

Kalau ada situasi yang mirip, jangan buat register dari nol, cukup ganti namanya saja.

1. Tim kecil berdua Sebelum menyentuh kode bersama, baca bareng dan tuangkan dalam satu lembar: area mana yang boleh diedit, mana yang tidak boleh disentuh, dan operasi mana yang butuh persetujuan manusia. Cuma dengan ini, insiden “salah satu merusak setelan tanpa yang lain tahu” lenyap. Justru tim kecil sering celaka karena “ah, pasti dia ngerti tanpa dibilang”, jadi menuliskannya di awal sangat berharga.

2. Tim yang melewati review Lead mewajibkan, sebelum perubahan buatan Claude Code masuk review, ada “hasil menjalankan perintah verifikasi” dan “ringkasan poin perubahan”. PR tanpa keduanya tidak dilihat, itu disepakati. Targetnya: reviewer bisa membaca diff, menjalankan ulang verifikasi, dan menjelaskan cara mem-balikkannya.

3. Tim yang punya halaman monetisasi Perubahan halaman yang langsung berkaitan dengan uang, seperti blog atau halaman produk, sebelum dianggap selesai wajib menyimpan screenshot URL publik. Jangan berhenti di “build lolos”, cek layar yang benar-benar dilihat pengguna. Lihat dengan mata sendiri apakah judul, isi, gambar, dan alur sesuai harapan.

Kegagalan umum dan cara memperbaikinya

Jujur saja, register ini pun awalnya tidak langsung berjalan mulus. Saya bagikan tiga kekonyolan saya.

Tiap orang membuat aturan sendiri Awalnya saya serahkan setelan ke masing-masing, dan rentang yang boleh diedit jadi berbeda-beda antar orang. Orang dengan setelan paling longgar yang memicu insiden. Cara memperbaikinya sederhana: satukan daftar boleh-edit dan dilarang-edit jadi satu untuk seluruh tim, lalu taruh di repository.

Menunda kegagalan CI Kalau “nanti diperbaiki sekalian” jadi kebiasaan, adopsi tim pertama berakhir dengan kesan buruk “begitu pasang Claude Code malah rusak”. Kalau perintah verifikasi gagal, hentikan di tempat, dan jadikan aturan: tetap status draf sampai hijau.

Membiarkan penanggung jawab kabur lalu menghindari keputusan sulit Tanpa menentukan “siapa yang menyetujui”, keputusan paling sulit, yaitu reflect ke produksi, jadi menggantung. Kolom owner di register wajib diisi. Jangan lanjut dengan kolom kosong. Cuma dengan ini, keputusan tidak lagi mandek.

Kalau Anda merasa kerja mulai melebar, jangan menulis ulang seluruh instruksi, tapi rapatkan dengan urutan: persempit area yang boleh disentuh, keluarkan verifikasi lebih dulu, tentukan satu orang penanggung jawab konfirmasi. Menyimpan kegagalan sebagai bahan berbagi dalam tim juga penting. Kalau hanya melihat contoh sukses, Anda tak akan sadar sedang masuk ke kondisi berbahaya.

Pertanyaan umum

Q. Tim kecil pun butuh register? Berdua pun butuh. Justru makin sedikit orang makin sering celaka karena merasa “pasti ngerti tanpa dibilang”. Awalnya template 3 baris sudah cukup, jadi buat dalam 5 menit lalu bagikan.

Q. Apakah cukup hanya dengan setelan permission Claude Code? Setelan permission adalah “mekanisme yang mencegah akses”, sedangkan register adalah “aturan operasi: siapa mengecek dengan apa”. Dua-duanya perlu. Cegah secara teknis lewat setelan, jalankan konfirmasi manusia lewat register. Detailnya lihat panduan setelan permission.

Q. Perintah verifikasi sebaiknya pilih yang mana? Perintah terpendek yang bisa membuktikan “tidak rusak” di tim Anda. Salah satu dari pengecekan tipe, menjalankan hanya tes terkait, atau build. Kalau tes lengkap butuh 10 menit tidak ada yang mau menjalankan, jadi pertama tentukan satu yang selesai dalam 30 detik.

Q. Apakah tetap jalan kalau ada anggota yang bukan engineer? Jalan. Register hanya soal membaca tabel dan mengisinya, jadi bisa dioperasikan walau tidak bisa baca kode. Cara memulai untuk non-engineer bisa dilihat di cara pakai untuk non-engineer.

Q. Aturan khusus proyek sebaiknya ditulis di mana? Tulis di CLAUDE.md repository, maka Claude Code membacanya tiap kali. Kalau area yang dilarang diedit dan perintah verifikasi dikumpulkan di sini, mudah disamakan dengan register. Cara menulisnya saya rangkum di cara menulis CLAUDE.md. Cek juga dokumentasi resmi Claude Code dari Anthropic sebagai sumber primer.

Hasil setelah saya coba sendiri

Setelah insiden deploy di awal tadi, saya berhenti pusing memikirkan “percaya Claude Code atau tidak”. Yang saya lihat sekarang justru: baris mana di register yang belum terisi.

Setelah benar-benar memperkenalkan register 3 baris dan menetapkan secara tertulis file konfigurasi bersama sebagai “area yang tidak boleh disentuh”, merge yang merusak setelan jadi nol. Setelah perintah verifikasi dijadikan “wajib sebelum melaporkan keberhasilan”, tidak ada lagi kerusakan yang baru ketahuan saat review, dan revert berkurang terlihat jelas. Setelah konfirmasi screenshot dimasukkan ke halaman publik, kelalaian “build lolos tapi yang tayang halaman lain” pun berhenti.

Yang saya pastikan cuma tiga hal ini. Daripada mencari agent yang lebih pintar, lebih dulu buat operasi yang bisa dibalikkan walau jatuh. Kelihatan memutar, tapi untuk adopsi tim inilah yang paling cepat, itu yang saya rasakan sekarang.

Kalau Anda sudah di tahap ingin serius mendorong adopsi Claude Code di perusahaan, atau ingin merancang aturan operasi bersama-sama, di pelatihan dan konsultasi kita bisa menyusun prosedur konkretnya bersama. Mulailah dulu dengan menuliskan tiga baris titik bahaya tim Anda sendiri.