Hari pertama pakai Claude Code di repo lama: cara memilih satu tugas aman tanpa merusak apa pun

Hari ketiga di kantor baru, saya diserahi kode bagian pembayaran yang isinya sekitar 150 file. Dokumentasinya nyaris tidak ada. Setiap orang yang saya tanya menjawab hal yang sama: “Itu sudah jalan, mendingan jangan diutak-atik.” Karena bingung, saya iseng minta Claude Code: “Pahami repo ini, lalu rapikan bagian yang kelihatannya bermasalah.”

Sepuluh menit kemudian, Claude menjawab dengan penuh percaya diri: “Sudah saya rapikan 20 file.” Saya buka diff-nya, dan muka saya langsung pucat. Dia merapikan format file SQL migration, mengurutkan ulang .env.example, dan—ini yang paling parah—diam-diam “mengoptimalkan” jeda retry pembayaran dengan memotongnya jadi setengah. Kodenya memang tetap jalan. Tapi kalau ini sampai naik ke production, telepon keluhan double charge pasti berdering tanpa henti.

Masalahnya bukan Claude kurang pintar. Masalahnya, scope yang saya serahkan di hari pertama terlalu luas. Untuk menyerahkan kode raksasa milik orang lain dengan aman, sebelum mencari AI yang lebih pintar, tentukan dulu empat hal dalam 30 menit: urutan baca, area larangan, tugas kecil pertama, dan cara verifikasi. Hanya dengan ini, kecelakaan hari pertama nyaris hilang. Hari ini saya rangkum isi 30 menit itu dalam bentuk yang bisa langsung Anda salin.

Poin penting

• Hari pertama di kode lama, instruksi “lihat semua lalu perbaiki” justru paling berbahaya, karena Anda lari tanpa scope yang jelas.
• Yang dibuat dalam 30 menit pertama bukan dokumen desain, melainkan satu lembar catatan untuk memilih satu tugas pertama dengan aman.
• Isi catatan cuma empat: urutan baca, area larangan, tugas kecil pertama, dan command verifikasi untuk memastikan tugas selesai.
• Tugas pertama dibatasi ke “tempat yang mudah dibalik”: teks, label tombol, atau nama test sudah pas.
• Yang diserahkan ke AI hanya “menyelidiki dan membuat draf”. Tombol DB production, billing, hapus, dan publish tetap ditekan manusia.

Kenapa instruksi pertama di hari pertama sering bikin tersandung

Claude Code itu cepat. Justru karena cepat, kalau informasi pertama yang Anda berikan terlalu luas, dia akan ngebut mengerjakan bahkan diff yang sebenarnya tidak penting.

Karyawan baru manusia akan bertanya, “Bagian ini boleh saya sentuh, kan?” AI tidak bertanya. Karena niat baik, dia justru memperluas scope. Begitu Anda bilang “rapikan”, dia benar-benar merapikan sampai ke sudut-sudutnya. Merapikan format migration, “mengoptimalkan” retry billing—semuanya dia lakukan karena merasa itu hal baik.

Jadi yang dikerjakan di hari pertama bukan membaca seluruh kode, bukan pula menyusun rencana perbaikan yang megah. Yang dikerjakan adalah menarik batas. Sampai mana boleh dia kerjakan sendiri, dari mana harus tanya manusia. Begitu garis ini ditarik lebih dulu, permintaan ke Claude berubah dari “pikirkan bebas” menjadi “kerjakan dalam batas ini dan tinggalkan buktinya”. Waktu yang dibutuhkan untuk menarik garis cuma 30 menit. Anda tidak perlu memahami seluruh kode.

Satu lembar catatan hari pertama, dibuat dalam 30 menit

Boleh di kertas, boleh di aplikasi catatan. Cukup isi empat poin berikut. Urutannya pun ada artinya.

1. Tentukan urutan baca sesempit mungkin. Bukan langsung semua file, tapi README dan package.json saja dulu. Dari sini Anda tahu bahasanya apa, cara menjalankannya bagaimana, dan tool apa yang dipakai. Berikutnya, dua atau tiga halaman atau route utama. Itu sudah cukup.
2. Tulis area larangan. Pembayaran, autentikasi login, environment variable, migration database. Nyatakan dengan jelas: “boleh dibaca, tapi jangan diubah.” Kalau tidak ditulis, Claude akan memperlakukan area ini sebagai target edit biasa.
3. Pilih satu tugas kecil pertama. Batasi ke tempat yang mudah dibalik. Teks di akhir artikel, label tombol, nama test yang membingungkan. Yang kalau gagal pun bisa langsung dikembalikan.
4. Tentukan cara memastikan tugas selesai. Apakah build lolos, apakah diff sesuai perkiraan, apakah tampilan tidak rusak. Jangan menilai dari “perasaan”, tapi dari hasil command.

Begitu empat poin ini terisi, sebagian besar kecemasan hari pertama hilang. Sebabnya, yang Anda pegang bukan lagi “Claude akan berbuat apa”, melainkan “sampai mana saya menyerahkan ke Claude”.

Apa yang diserahkan ke AI, apa yang diputuskan manusia

Begitu pembagiannya ditulis menjadi kata-kata, Anda tidak akan ragu setiap kali. Beginilah cara saya membaginya.

Pekerjaan	Diserahkan ke Claude	Diputuskan manusia
Membaca kode dan merangkum struktur	Buat drafnya	Pemahaman akhir dicek sendiri
Mengusulkan area larangan	Sebutkan kandidatnya	Billing & auth wajib dipastikan manusia
Memperbaiki teks atau label	Boleh diserahkan	Lihat diff lalu setujui
Menulis ke DB production	Tidak	Dieksekusi manual oleh manusia
Hapus, publish, billing	Tidak	Manusia yang menekan tombol

Intinya, taruh semua operasi berbahaya di sisi “tanya manusia” sejak awal. Hanya operasi yang sudah terbukti aman yang belakangan dinaikkan ke mode otomatis. Jangan dibalik. Membuka izin lebar di awal lalu mengetatkannya setelah terjadi kecelakaan—itu urutan yang terbalik.

Kalau Anda ingin memahami pola pikir ini lebih pelan, baca juga Panduan langkah awal Claude Code dan Checklist 30 menit pertama Claude Code. Keduanya menyambung gerak hari pertama Anda.

Template prompt yang bisa langsung disalin

Pertama, kuncinya adalah jangan langsung menyuruhnya mengedit. Awalnya minta dia “hanya membaca dan merangkum dalam tabel”.

Saya baru pertama kali menyentuh repo ini. Jangan edit apa pun dulu.
Baca dengan urutan berikut, lalu kembalikan hasilnya dalam tabel.

1. Baca README dan package.json, sebutkan bahasa, command untuk menjalankan, dan dependency utama
2. Daftar tempat berbahaya untuk disentuh (billing, auth, env var, DB migration), lengkap dengan path file
3. Sebutkan 3 kandidat "tugas kecil pertama" yang mudah dibalik, beserta alasannya
4. Untuk tiap kandidat, tuliskan command untuk memastikan selesai (build, cek diff, dsb.)

Sekali lagi: pada tahap ini jangan mengedit satu karakter pun.

Setelah tabelnya kembali, periksa sendiri apakah ada “area larangan” yang terlewat. Kalau ada yang kurang, tambahkan, baru setelah itu minta satu tugas saja.

Dari kandidat tadi, kerjakan hanya XX (perbaikan teks di akhir artikel).
Jangan sentuh billing, auth, env var, atau migration sama sekali.
Setelah edit, jalankan `npm run build` lalu tunjukkan diff lewat `git diff --stat`.
Kalau ada yang rusak, jelaskan penyebab dan cara memperbaikinya dalam 1 baris, lalu berhenti.

Kalau “area larangan” sudah ditulis di CLAUDE.md sejak awal, Anda tidak perlu menempel catatan peringatan ini setiap kali. Cara menulisnya saya rangkum di Best practice CLAUDE.md.

Kode kecil untuk menyerahkan pengecekan ke mesin

Kalau “siapkan dulu baru serahkan” hanya mengandalkan ingatan manusia, di hari yang sibuk pasti ada yang terlewat. Jadi, biarkan mesin yang menilai apakah satu lembar catatan tadi minimal sudah lengkap. Kode berikut langsung jalan dengan Node.js.

// Mengecek secara mekanis apakah satu lembar catatan hari pertama "siap diserahkan ke Claude"
const repoMap = {
  goal: "Pilih satu tugas pertama yang mudah dibalik",
  readFirst: ["README.md", "package.json", "src/routes/"],
  protectedAreas: [".env", "billing/", "migrations/", "wrangler.toml"],
  firstTask: "Perbaiki teks di akhir artikel (jangan sentuh kode pembayaran)",
  proofCommands: ["npm run build", "git diff --stat"],
};

function isReady(map) {
  const reasons = [];
  if (map.readFirst.length < 2) reasons.push("Urutan baca terlalu sempit / belum diatur");
  if (map.protectedAreas.length === 0) reasons.push("Area larangan masih kosong");
  if (!map.proofCommands.some((c) => c.includes("build"))) {
    reasons.push("Tidak ada command verifikasi build");
  }
  if (!map.firstTask) reasons.push("Tugas pertama belum dipilih");
  return { ready: reasons.length === 0, reasons };
}

const result = isReady(repoMap);
console.log(result.ready ? "Boleh diserahkan" : "Jangan diserahkan dulu: " + result.reasons.join(", "));

Saat dijalankan, hasilnya seperti ini.

node check-repo-map.mjs
# => Boleh diserahkan

Coba kosongkan protectedAreas jadi array kosong, lalu jalankan: muncul “Jangan diserahkan dulu: Area larangan masih kosong”. Hanya segini saja, tapi cukup untuk menghentikan kecelakaan paling umum—“lupa menulis area larangan tapi sudah terlanjur jalan full otomatis”—sebelum tugas diserahkan. Catatan ini bisa langsung Anda tempel di CLAUDE.md atau di issue, supaya diri Anda esok hari maupun rekan tim bisa memakai kembali keputusan yang sama.

Tiga situasi nyata yang benar-benar berhasil

1. Mengelola blog, melindungi link artikel yang menghasilkan uang Saat ingin memperbaiki hanya jalur ajakan di akhir artikel populer, kalau Anda minta Claude “perbaiki teksnya”, dia gampang ikut mengubah URL link produk. Maka tutup scope-nya: “Teks boleh diperbaiki, tapi URL tujuan jangan diubah satu karakter pun. Setelah selesai, tunjukkan build dan diff.” Dengan begini, link yang langsung menyumbang revenue tetap utuh, hanya kalimatnya yang dipoles.

2. Di SaaS, jangan dekat-dekat proses billing Saat teks penjelasan di halaman setting membingungkan, yang diperbaiki murni teks tampilan saja. Logika billing atau ganti paket tidak boleh disentuh. Kalau billing/ sudah masuk ke “area larangan” di catatan, Anda bisa mencegah Claude yang karena niat baik malah ikut menyentuh proses retry.

3. Di tool internal, perbaiki hanya nama kolom output Ada keluhan bahwa nama kolom di output CSV membingungkan. Yang diperbaiki cuma string nama kolom, sementara logika agregasi itu urusan lain. Begitu Anda minta “hanya string tampilan nama kolom. Jangan sentuh rumus. Tunjukkan output dengan data sampel”, verifikasinya pun selesai dalam sekejap.

Yang sama dari ketiganya bukan soal Claude kurang mampu, melainkan satu hal: kalau batasnya tipis, pasti celaka. Makin jelas batas yang ditulis, makin aman dan cepat AI bergerak.

Jebakan yang sering terjadi dan cara memperbaikinya

Jebakan 1: Menyuruh membaca semua file sejak awal. Waktu dan token habis untuk merapikan hal-hal kurang penting, sementara perubahan inti jadi tipis. Cara memperbaiki: batasi target baca ke README dan package.json plus dua atau tiga route utama. Pemahaman keseluruhan diperluas sedikit demi sedikit setelah satu tugas selesai.

Jebakan 2: Tidak menulis area larangan. Claude memperlakukan billing, auth, dan konfigurasi deploy sebagai target edit biasa. Cara memperbaiki: tulis daftar proteksi lengkap dengan path file, dan tempatkan permanen di CLAUDE.md. Peringatan lisan akan terlupa, tapi yang tertulis tetap tinggal.

Jebakan 3: Percaya “sudah selesai” tanpa menetapkan command verifikasi. Anda jadi harus menebak setiap kali apakah laporan selesai itu benar. Cara memperbaiki: masukkan “jalankan build dan tunjukkan diff” ke dalam prompt sejak awal. HTTP 200 atau jawaban yang terdengar meyakinkan bukan bukti sukses. Hanya hasil yang benar-benar dijalankan yang boleh dipercaya.

Pertanyaan umum

T. Bukankah lebih aman memahami keseluruhan kode lama dulu baru menyerahkannya? Idealnya begitu, tapi di hari pertama pemahaman menyeluruh tidak akan selesai. Kalau menunggu sampai selesai, tidak ada yang maju. Jadi tutup dulu “area larangan”, lalu mulai dari satu tugas yang mudah dibalik. Pemahaman justru lebih cepat tumbuh sambil bekerja.

T. Seberapa kecil tugas pertama sebaiknya? Patokannya: selesai dalam satu file, satu teks, atau satu command. Kalau diminta besar, Claude dengan baik hati akan memperluas scope. Kalau Anda maju ke berikutnya setelah memeriksa build dan screenshot, kecepatan tetap terjaga sambil waktu untuk membatalkan berkurang.

T. Di mana sebaiknya menulis area larangan? Menulisnya di CLAUDE.md adalah yang paling berkelanjutan. Cara menempelkannya ke prompt setiap kali pasti terlupa di hari sibuk. Kalau diletakkan di satu tempat sebagai aturan proyek, dia otomatis berlaku bahkan untuk tugas baru.

T. Saya sudah bilang “jangan disentuh” tapi Claude tetap menyentuhnya. Biasanya karena target proteksi berhenti di nama file, bukan satu direktori penuh. Tulis dalam bentuk rentang seperti billing/, bukan cuma billing.js. Kalau masih dilanggar, sisipkan satu lapis di awal prompt: “deklarasikan dulu file target sebelum mengedit”, maka dia lebih mudah berhenti.

T. Apakah catatan ini harus dibuat ulang setiap kali? Cukup buat sekali per repo, selebihnya bisa dipakai ulang. Kalau ditempel di CLAUDE.md dan issue, diri Anda esok hari maupun rekan tim bisa mewarisi keputusan yang sama. Tinggal tambahkan kalau ada target proteksi baru yang ditemukan.

Hasil yang benar-benar saya coba

Setelah insiden kode pembayaran di awal tadi, saya mencoba prosedur yang sama di repo lama lainnya. Pertama saya larang dia mengedit sama sekali, lalu pakai prompt di atas untuk minta tabel saja. Hasilnya, dia benar mengangkat billing/ dan migrations/ sebagai kandidat target proteksi. Hanya saja file environment variable terlewat, jadi saya tambahkan .env sendiri. Saya kembali sadar betapa pentingnya menjalankan ini dengan asumsi manusia akan ikut memeriksa.

Tugas pertama saya batasi ke satu perbaikan teks di akhir artikel, lalu saya cek sampai npm run build dan git diff --stat baru dinyatakan selesai. Diff-nya hanya 7 baris, dan tidak satu karakter pun kode pembayaran tersentuh. Kode pengecekan tadi juga saya jalankan betulan, dan saya konfirmasi bahwa mengosongkan protectedAreas membuatnya berhenti dengan pesan “Jangan diserahkan dulu”. Daripada mencari AI yang lebih pintar, tentukan dulu scope kecil yang bisa langsung dibalik kalau tersandung. Inilah yang paling ampuh di hari pertama menyerahkan kode milik orang lain.

Kalau Anda sudah sampai tahap ingin menyepakati pola tim soal cara memasukkan Claude Code ke kode lama perusahaan, di pelatihan & konsultasi kita bisa membereskan cara menarik batas sambil melihat repo Anda yang sebenarnya. Untuk prasyarat resmi, ada baiknya cek juga Anthropic Claude Code getting started supaya lebih tenang.