Cara Menulis Instruksi agar Claude Code Hanya Mengubah Satu File

“Tolong perbaiki sedikit paragraf pembuka artikel blog ini.”

Saya mengetik kalimat itu Jumat malam jam 10. Yang ingin saya ubah cuma tiga paragraf pertama dari satu file. Tapi keesokan paginya, waktu saya buka diff-nya, ada 12 file yang berubah. Bukan cuma isi artikel, tapi juga layout bersama, daftar tag, bahkan entah kenapa sampai ke file pengaturan publish. Tanpa sempat saya cek apakah semuanya masih jalan, saya sudah keburu tidur malam itu.

Butuh 30 menit untuk mengembalikan semuanya. Apa yang salah? Bukan karena Claude Code-nya payah. Tapi karena instruksi saya tidak menyebut satu pun batas “sampai mana boleh disentuh”, jadi AI yang pintar itu cuma berinisiatif: “memperbaiki pembuka berarti merapikan bagian terkait juga.” Niatnya baik, justru itu yang bikin repot.

Di artikel ini saya kasih langsung, dalam format siap salin-tempel, “brief permintaan untuk mengedit satu file dengan aman” yang lahir dari kegagalan malam itu. Persempit scope-nya, suruh AI verifikasi sendiri setelah selesai, dan siapkan cara rollback kalau salah. Cuma dengan tiga hal ini, kecelakaan tengah malam itu nyaris hilang total.

Poin penting

• Pekerjaan yang didelegasikan ke AI jadi liar bukan karena modelnya jelek, tapi karena batas area yang boleh disentuh tidak ditulis
• Brief permintaan wajib memuat 5 hal: “file yang dibaca”, “file yang diubah”, “yang tidak boleh disentuh”, “perintah verifikasi”, dan “cara rollback”
• Wajibkan AI menjalankan perintah verifikasi sebelum melapor sukses, supaya manusia tidak jadi tukang tes belakangan
• Mulai dari pekerjaan kecil yang titik berhentinya jelas: perbaikan blog, merapikan laporan bug, menulis ulang teks produk
• Mempersempit scope tidak menurunkan nilai artikel maupun hasil kerja. Justru pembaca jadi lebih mudah menerapkannya ke lingkungannya sendiri

Kenapa “bikin lebih bagus” selalu berujung celaka

Permintaan model “bikin lebih bagus” itu tidak punya garis akhir.

Editor manusia, kalau dimintai tolong Jumat malam yang sibuk, pasti mengonfirmasi dulu: “Cuma tiga paragraf pembuka, kan?” Tapi AI bisa langsung lari tanpa konfirmasi. Apalagi dia jago berinisiatif, jadi dia melebarkan scope sendiri: “kalau memperbaiki pembuka, sekalian rapikan tag dan tambahkan link terkait biar lebih baik.” Niatnya nol jahat. Justru itu yang paling merepotkan.

Yang berfungsi di sini adalah ide menuliskan “titik berhenti” di dalam instruksi. Anda tidak perlu menulis prompt yang panjang dan rumit. Justru lebih baik pendek. Sebagai gantinya, di awal pisahkan dengan jelas mana file yang boleh disentuh dan mana yang tidak boleh. Cuma itu, dan kelakuan liarnya berhenti.

Buat yang ingin mendalami cara menulis prompt itu sendiri, baca juga desain prompt Claude Code supaya terlihat bagaimana “mempersempit scope” yang dibahas di sini terhubung dengan teknik lainnya.

Lima hal yang wajib ada di brief permintaan

Brief yang sekarang saya pakai pasti memuat kelima hal ini. Urutannya pun punya makna.

Item	Isi	Yang terjadi kalau ini tidak ada
File yang dibaca	Area yang boleh dibaca untuk memahami situasi	Membaca tempat yang tidak relevan lalu mengoreksi yang meleset
File yang diubah	1-2 file yang benar-benar boleh ditulis ulang	Terjadi kecelakaan 12 file
Yang tidak disentuh	Pengaturan, hasil build, info rahasia, setelan publish	File penting “dirapikan” lalu terhapus
Perintah verifikasi	Satu perintah cek yang dijalankan setelah perubahan	Sudah rusak tapi tetap dilaporkan “selesai”
Cara rollback	Langkah mengembalikan ke semula kalau salah	Butuh 30 menit untuk pulih

Kuncinya adalah memaksa AI mengembalikan “rencana” dulu sebelum mulai mengedit. Jangan biarkan dia langsung menulis ulang. Suruh dia menyebut dulu “file mana yang dibaca, mana yang diubah, dan kalau salah apa yang rusak.” Kalau rencana yang dikembalikan meleset, di titik itu juga Anda bisa menghentikannya. Jauh lebih murah daripada baru sadar setelah semuanya ditulis ulang.

Area yang didelegasikan ke AI vs area yang diputuskan manusia

Anda tidak perlu menyerahkan semuanya ke AI. Saya menarik garisnya begini.

Bagian yang boleh diserahkan ke AI

• Membaca file untuk memahami situasi
• Menyusun rencana perubahan dan menuangkannya jadi kalimat
• Menulis teks atau kode yang sebenarnya
• Menjalankan perintah verifikasi dan melaporkan hasilnya

Bagian yang dipegang manusia

• File mana yang jadi target perubahan (keputusan scope)
• Menekan tombol publish atau deploy ke produksi
• Keputusan menyentuh file pengaturan atau info rahasia
• Keputusan menghentikan publish ketika verifikasi gagal

Penarikan garis ini justru paling penting bagi yang baru pertama kali mendelegasikan kerja ke AI. Cara memilah area yang diserahkan dan area yang diputuskan manusia juga jadi konsep dasar di memanfaatkan Claude Code untuk non-engineer. Selama belum terbiasa, cukup dengan pembagian kasar: “membaca dan menulis untuk AI, menghapus dan publish untuk manusia.”

Template brief siap salin-tempel

Tempel apa adanya, lalu cukup ganti nama file sesuai lingkungan Anda. Baik di PowerShell maupun bash, tinggal masukkan teks ke variabel dan cek isinya.

brief=$(cat <<'EOF'
Tujuan: melakukan satu edit aman di satu tempat saja.
File yang boleh diubah: site/src/content/blog/example.mdx
Yang tidak boleh disentuh: file package, hasil build, info rahasia, setelan publish/deploy.

Sebelum mulai mengedit, kembalikan hal berikut:
1. File yang dibaca untuk memahami situasi
2. Satu file yang benar-benar akan diubah
3. Apa yang rusak jika perubahan itu salah
4. Perintah cek yang dijalankan setelah perubahan

Setelah selesai mengedit, kembalikan hal berikut:
- Ringkasan diff
- Hasil eksekusi perintah cek
- Langkah untuk mengembalikan ke semula
EOF
)

echo "$brief"

Teks ini tidak mencolok. Nilainya ada pada kemampuan menuangkan batas ke dalam kata sebelum pekerjaan dimulai. Ganti nama file, yang-tidak-disentuh, dan perintah cek untuk repo Anda, lalu serahkan ke Claude Code. Begitu rencana yang baik kembali, suruh dia menyebutkan ulang batasan yang sama sebelum mulai kerja.

Kalau Anda tulis batasan yang sama di CLAUDE.md, ia berlaku otomatis tanpa perlu ditempel setiap kali. Caranya saya rangkum di praktik terbaik CLAUDE.md.

Skrip kecil untuk verifikasi setelah selesai

Jangan percaya kata “selesai.” Ini pilar kedua.

Setelah edit selesai, kita cek secara mekanis apakah file yang berubah benar-benar cuma satu. Skrip di bawah ini sekadar menghitung jumlah file yang berubah tapi belum di-commit, lalu berhenti kalau lebih banyak dari yang diperkirakan. Sudah lengkap dengan komentar dan langsung jalan.

#!/usr/bin/env bash
# Cek apakah file yang berubah cuma satu. Berhenti kalau terlalu banyak.
set -e

# Jumlah file yang diperkirakan berubah (kalau edit 1 file, isinya 1)
expected=1

# Hitung jumlah file yang berubah tapi belum di-commit
changed=$(git status --porcelain | grep -c .)

echo "Jumlah file yang berubah: $changed (perkiraan: $expected)"

if [ "$changed" -gt "$expected" ]; then
  echo "Lebih banyak file berubah dari perkiraan. Silakan periksa diff-nya."
  git status --porcelain
  exit 1
fi

echo "Sesuai scope."

Kalau skrip ini Anda tetapkan sebagai “perintah verifikasi” di brief, AI akan menjalankannya sendiri dan melaporkan hasilnya. Kalau 12 file berubah, tulisan merah akan muncul di saat pelaporan. Bukan saya yang baru sadar setelah bangun pagi, tapi berhenti di tempat saat itu juga. Inilah yang manjur.

Buat yang ingin mengotomatiskan verifikasi dan rutinitas harian lebih jauh, teknik meningkatkan produktivitas Claude Code merangkum pola-pola lainnya.

Tiga situasi di mana ini manjur

Ketiganya pekerjaan dengan “titik berhenti” yang jelas. Sebaliknya, kalau titik berhentinya tidak terlihat, itu pertanda pekerjaan tersebut belum sebaiknya dilempar penuh ke AI.

1. Menulis ulang pembuka blog Di awal tuliskan: yang diubah cuma pembuka satu file. Sertakan juga target pembaca dan perintah verifikasi. Dengan ini tangan AI tidak akan menjalar ke seluruh isi artikel atau ke layout. Kecelakaan 12 file saya itu, kalau ada satu baris ini, tidak akan pernah terjadi.

2. Merapikan laporan bug Tunjukkan cuma file log dan satu template, lalu tulis “dilarang merapikan kode yang tidak relevan.” Kalau di tengah merapikan laporan malah ikut di-refactor, review jadi langsung berat. Persempit area yang ditunjukkan, maka output-nya pun ikut menyempit.

3. Menguji teks halaman produk Bukan membangun ulang seluruh halaman, melainkan minta cuma “satu usulan tagline” dan “cek tampilan setelah perubahan.” Karena scope-nya terkunci pada satu usulan, saat menguji A/B pun perbandingannya jadi mudah.

Pertanyaan umum

T. Tidak repotkah menempel brief panjang ini setiap kali? Batasan yang sering dipakai cukup ditulis di CLAUDE.md, jadi berlaku tanpa perlu ditempel tiap kali. Yang perlu Anda tempel tinggal “nama file yang boleh disentuh kali ini” saja.

T. Kalau scope dipersempit, bukankah malah membunuh kelebihan AI? Justru sebaliknya. Semakin sempit scope-nya, semakin AI memperbaiki dengan mantap dan mendalam tanpa bimbang. Instruksi yang luas hanya membuatnya bingung “mau mulai dari mana.”

T. Perintah verifikasi sebaiknya diisi apa? Di awal cukup “cek jumlah file yang berubah” saja. Setelah terbiasa, tambahkan satu per satu: apakah build lolos, apakah ada tes yang gagal, apakah ada link yang putus.

T. Kalau ternyata tetap ada file di luar dugaan yang berubah? Kalau cara rollback sudah ditulis di brief, tinggal kembalikan dengan langkah itu. Triknya, masukkan perintah pengembalian seperti git restore . ke dalam instruksi sejak awal.

T. Sebaiknya mulai dari mana? Pilih satu pekerjaan kecil yang kalaupun gagal masih bisa dikembalikan. Perbaikan artikel draf atau penggantian teks itu pas. Kalau masih ragu dengan operasi dasar, mulai dari panduan memulai Claude Code untuk meratakan fondasi.

Hasil setelah saya coba sendiri

Sejak kecelakaan 12 file itu, saya selalu menulis brief dengan “file yang diubah”, “yang tidak disentuh”, dan “perintah verifikasi” terpasang.

Setelah skrip verifikasi saya tetapkan sebagai “perintah cek”, kasus tercampurnya file di luar dugaan jadi berhenti di tempat saat itu juga. Nyatanya minggu lalu, ketika saya menyuruh memperbaiki teks halaman produk, AI sempat mau menjalarkan tangan sampai ke komponen bersama, tapi begitu jumlah file yang berubah jadi 2, skrip langsung memunculkan warna merah dan berhenti. Tidak ada lagi momen bangun pagi lalu pucat melihat diff.

Satu hal lagi yang saya pastikan: mempersempit scope tidak menurunkan kualitas output. Hari-hari ketika saya membatasi “cuma tiga paragraf pembuka”, justru perbaikan yang kembali lebih tepat sasaran. Daripada menyerahkan banyak ke AI yang pintar, lebih baik meminta sempit lalu memverifikasi sendiri. Kelihatannya memutar, tapi inilah yang paling cepat buat saya, itu kesimpulan saya sekarang.

Kalau Anda ingin membangun mekanisme mendelegasikan editing dan operasional ke AI untuk kebutuhan bisnis perusahaan, di pelatihan & konsultasi penerapan kita bisa menyusunnya bersama mulai dari langkah konkretnya. Untuk awal, coba dulu sekali brief satu file ini di tangan Anda sendiri.

Sebagai referensi, info resmi tool yang dipakai di sini ada di dokumentasi resmi Claude Code.