Claude Code di jam pertama repo orang lain: gambar peta dulu, baru perbaiki

Hari pertama serah terima, saya membuka repo tool internal yang ditinggalkan rekan sebelumnya. README-nya cuma 3 baris, update terakhir 8 bulan lalu. Tanpa pikir panjang saya minta Claude Code, “Pahami proyek ini, lalu perbaiki teks di halaman login.” Lima menit kemudian, file konfigurasi seputar autentikasi dan bahkan script deploy produksi yang tak pernah disentuh siapa pun ikut “dirapikan sekalian”.

Untung saya sadar lewat git status dan mengembalikan semuanya. Tapi membayangkan kalau saya git commit tanpa sadar, sampai sekarang masih bikin merinding. Masalahnya bukan pada seberapa pintar modelnya. Masalahnya adalah saya menyerahkan pekerjaan tanpa tahu mana yang boleh disentuh.

Jam pertama masuk ke kode orang lain bukan waktu untuk memperbaiki, melainkan waktu untuk menggambar peta. Artikel ini merangkum cara menggambar peta itu sebagai langkah yang tidak bikin celaka, bahkan di repo yang baru pertama kali Anda buka.

Poin penting

• Jam pertama bukan untuk “memperbaiki” tapi untuk “menggambar peta”. Pisahkan dulu area yang boleh disentuh dan yang tidak boleh.
• Yang diserahkan ke Claude Code hanya “membaca dan membuat daftar”. Apa yang jadi area terlindungi, manusia yang menentukan.
• Sebelum mulai memperbaiki, tentukan dulu satu command verifikasi (build atau test). Inilah bukti bahwa sesuatu “sudah beres”.
• Perbaikan pertama dibatasi pada hal kecil yang bisa di-rollback dengan satu command git.
• Hasil pemahaman ditulis dalam satu catatan. Orang berikutnya yang masuk ke repo yang sama (termasuk diri Anda di masa depan) tidak perlu mengulang riset yang sama.

Kenapa celaka justru terjadi di jam pertama

Tersandung di repo baru biasanya bukan karena kodenya sulit. Penyebabnya adalah bentuk repo belum terlihat.

Folder mana yang halaman tampilan, di mana logika di balik layar, file mana yang konfigurasi produksi. Selama ini belum jelas dan Anda minta “perbaiki seperlunya”, Claude Code akan menulis ulang area yang luas dengan niat baik. Selama tidak ada yang berkata “jangan sentuh sini”, AI menganggap tempat itu boleh disentuh.

Kasus serah terima paling berbahaya. Aturan tak tertulis dari rekan lama, kebiasaan penamaan, komentar yang entah kenapa masih ada. Konteks seperti ini tidak tertulis di mana pun dalam kode. Manusia pun tidak bisa paham semuanya di hari pertama. Justru karena itu, hal pertama yang dikerjakan bukan mengedit, melainkan membuat peta.

Empat langkah menggambar peta

Urutannya penting. Tentukan area baca, tentukan area terlindungi, tentukan command verifikasi, dan baru terakhir perbaiki satu hal kecil. Jalankan dengan urutan ini.

Langkah 1: tulis tujuan hari ini dalam satu kalimat

“Memahami proyek ini” terlalu luas. Baik Claude Code maupun manusia akan kehilangan titik berhenti kalau tujuannya selebar itu.

Sebagai gantinya, tulis begini: “Perbaiki teks di halaman login pada satu tempat saja, lalu pastikan build lolos.” Tujuan yang bisa dikatakan dalam satu kalimat juga gampang dicek apakah sudah selesai atau belum.

Langkah 2: pisahkan area baca dan area yang tidak boleh disentuh

Inilah inti peta. Sebelum menyerahkan “boleh baca semua” ke Claude Code, ucapkan dulu dalam kata-kata mana yang tidak boleh disentuh.

Yang selalu saya masukkan ke area terlindungi: autentikasi, billing, file environment variable (.env), dan script deploy produksi. Kalau salah, dampaknya besar dan sulit dikembalikan. Maka di awal saya tegaskan, “boleh dibaca, tapi jangan ditulis”.

Langkah 3: tentukan command verifikasi lebih dulu

Kalau dibilang “sudah diperbaiki”, apa dasarnya kita bisa bilang itu benar-benar beres? Tentukan dulu jawabannya.

Di banyak proyek, command build atau command test menjadi alat verifikasi. npm run build lolos, npm test jadi hijau. Dengan menentukan satu command ini sebelum memperbaiki, Anda tidak menelan bulat-bulat klaim “sudah selesai” dari Claude Code, melainkan menilai lewat lolos-gagalnya mesin.

Langkah 4: cukup satu perbaikan kecil yang bisa di-rollback

Setelah peta jadi, perbaikan pertama jangan rakus. Pilih satu hal yang bisa dikembalikan dengan sekali git checkout, seperti memperbaiki teks, menambah komentar, atau membetulkan typo yang jelas.

Tahan godaan “sekalian itu juga”. Diff yang besar tidak bisa di-review siapa pun, dan rollback-nya pun merepotkan saat terjadi masalah.

Bagian yang diserahkan ke Claude Code vs yang diputuskan manusia

Dalam membuat peta, apa yang diserahkan dan apa yang dipegang sendiri. Kalau ini tercampur, terjadilah celaka seperti di awal tadi.

Pekerjaan	Penanggung jawab	Alasan
Memahami daftar file dan struktur folder	Claude Code	Pembacaan mekanis cepat dan akurat
Riset “fitur ini ada di mana?”	Claude Code	Pencarian dan rangkuman adalah keahliannya
Apa yang jadi area terlindungi	Manusia	Besarnya dampak bergantung konteks. AI tidak tahu
Keputusan akhir command verifikasi	Manusia	Yang tahu seluk-beluk proyek adalah manusia
Perubahan pada produksi, billing, autentikasi	Manusia	Operasi yang sulit di-rollback disetujui manusia

Prinsipnya sederhana. Membaca dan membuat daftar boleh diserahkan. Keputusan yang sulit di-rollback dipegang manusia. Hanya operasi yang sudah terbukti aman yang belakangan boleh dinaikkan kelasnya ke Claude Code.

Desain izin yang lebih rinci saya rangkum di artikel lain. Kalau bingung apa yang harus dihentikan dulu, lihat panduan izin.

Prompt membuat peta yang bisa langsung disalin

Inilah prompt yang benar-benar saya lempar di jam pertama. Tempel apa adanya, cukup ganti nama repo dengan milik Anda.

Saya baru pertama kali menyentuh repo ini. Jangan mengedit apa pun dulu.
Selidiki hal berikut secara berurutan, lalu laporkan hasilnya dalam poin-poin.

1. Struktur folder top-level dan peran masing-masing (boleh tebakan, tapi tandai sebagai tebakan)
2. Command untuk build, test, dan menjalankan (dari package.json atau README)
3. Lokasi file yang berkaitan dengan autentikasi, billing, environment variable, dan deploy produksi
4. "Teks halaman login" ada di file mana

Setelah laporan, kelompok file di poin 3 untuk kali ini berstatus "hanya baca, dilarang edit".
File yang boleh diedit hanya satu file yang ditemukan di poin 4.

Kuncinya adalah memaku di baris pertama dengan “jangan mengedit dulu”. Tanpa ini, ada AI yang langsung mulai memperbaiki sambil meriset.

Script verifikasi yang bisa langsung dijalankan

Setelah peta jadi, akan lebih tenang kalau Anda bisa menjalankan pengecekan yang sama sebelum dan sesudah perbaikan. Script berikut memastikan build lolos serta diff tidak melebar terlalu jauh di antara sebelum dan sesudah perubahan. Berjalan dengan Node.js.

// verify-edit.mjs
// Memastikan build lolos sebelum/sesudah perbaikan, dan diff tidak lebih besar dari yang diperkirakan
import { execSync } from "node:child_process";

// Tentukan batas atas jumlah file yang berubah, agar tetap dalam jangkauan rollback satu command
const MAX_CHANGED_FILES = 3;

function run(cmd) {
  return execSync(cmd, { encoding: "utf8" }).trim();
}

try {
  // Hitung jumlah file yang berubah
  const changed = run("git diff --name-only")
    .split("\n")
    .filter(Boolean);

  console.log(`Jumlah file berubah: ${changed.length}`);
  changed.forEach((f) => console.log(`  - ${f}`));

  if (changed.length > MAX_CHANGED_FILES) {
    console.error(
      `Diff terlalu lebar (${changed.length} > ${MAX_CHANGED_FILES}).`,
    );
    console.error("Kembalikan dulu dengan git checkout, lalu pecah perbaikan jadi lebih kecil.");
    process.exit(1);
  }

  // Pastikan area terlindungi tidak ikut tersentuh
  const protectedHits = changed.filter((f) =>
    /(^|\/)\.env|auth|billing|deploy/i.test(f),
  );
  if (protectedHits.length > 0) {
    console.error("Ada perubahan masuk ke area terlindungi:");
    protectedHits.forEach((f) => console.error(`  - ${f}`));
    process.exit(1);
  }

  // Pastikan build lolos (ganti sesuai proyek Anda)
  console.log("Memeriksa build...");
  run("npm run build");
  console.log("Build OK. Perbaikan masih dalam jangkauan aman.");
} catch (err) {
  console.error("Verifikasi gagal:", err.message);
  process.exit(1);
}

Jalankan dengan node verify-edit.mjs. Kalau file yang berubah terlalu banyak, atau area terlindungi ikut tersentuh, script berhenti di tempat. Celaka “file autentikasi ikut dirapikan” di awal tadi seharusnya tercegah seandainya saya melewatkannya lewat script ini.

Tiga situasi yang ampuh

Konkretnya di repo seperti apa ini berguna. Berikut tiga pola yang sudah saya coba.

1. Tool internal warisan Saat masuk ke codebase tanpa dokumentasi. Pertama suruh buat daftar struktur folder dan command untuk menjalankan, lalu kunci autentikasi dan file konfigurasi sebagai area terlindungi. Perbaikan pertama pilih yang hasilnya terlihat secara visual, seperti mengubah label di halaman admin.

2. Kontribusi pertama ke repo publik Saat pertama kali mengirim Pull Request ke open source orang lain. Suruh identifikasi command test lebih dulu, lalu kirim satu perbaikan kecil sambil menjaga npm test tetap hijau. Perbaikan satu file yang bisa di-rollback lebih mudah diterima daripada usulan perbaikan yang luas.

3. Menghidupkan kembali proyek lama Saat melanjutkan kode yang terbengkalai setengah tahun. Suruh Claude Code menyelidiki “sampai mana yang masih jalan”, lalu petakan pintu masuk yang rusak. Yang diperbaiki dimulai dari satu tempat yang paling mudah di-rollback.

Jebakan dan cara memperbaikinya

Jebakan 1: ingin memperbaiki semuanya sekaligus Kalau “sekalian refactor” membuat diff membengkak jadi 50 file, tidak ada yang bisa me-review. Cara memperbaiki: pasang batas atas jumlah file yang berubah lewat script verifikasi di atas. Kalau lewat batas, kembalikan dulu lalu pecah.

Jebakan 2: menganggap selesai hanya karena build sukses Walaupun build lolos di lokal, belum tentu tampilan sesuai harapan. Untuk perbaikan teks, satu set kerja itu baru lengkap setelah Anda benar-benar membuka halaman tersebut dan mengecek hurufnya dengan mata.

Jebakan 3: menyampaikan area terlindungi hanya lewat lisan Walaupun di prompt Anda bilang “jangan sentuh autentikasi”, di tengah pekerjaan panjang itu bisa terlupakan. Cara memperbaiki: tolak perubahan ke area terlindungi secara mekanis lewat script verifikasi. Lindungi dengan command, bukan dengan ingatan manusia.

Jebakan 4: tidak menyimpan peta yang sudah diselidiki Sudah susah payah satu jam memahami, tapi kalau tidak ada catatan, lain kali Anda mengulang riset yang sama. Tulis struktur folder, command verifikasi, dan area terlindungi dalam satu catatan, dan diri Anda di masa depan akan tertolong.

Catatan peta itu lebih ampuh lagi kalau Anda tulis di CLAUDE.md sebagai aturan proyek. Cara menulisnya saya rangkum di praktik terbaik CLAUDE.md.

Pertanyaan umum

T. Di jam pertama, benar-benar tidak perlu memperbaiki apa pun? J. Boleh saja memperbaiki, tapi batasi pada “satu tempat kecil yang bisa di-rollback”. Memakai sisa waktu untuk membuat peta justru lebih cepat, karena celakanya berkurang.

T. Apakah berbahaya menyerahkan “boleh baca semua” ke Claude Code? J. Kalau hanya membaca, tidak berbahaya. Yang berbahaya adalah izin “menulis”. Bacaan boleh luas, tulisan harus sempit. Inilah pembagian dasarnya.

T. Bagaimana dengan proyek yang command verifikasinya tidak diketahui? J. Pertama suruh Claude Code mengajukan kandidat dari package.json atau README. Kalau tetap tidak jelas, jadikan minimal “tidak ada diff yang muncul saat git status” sebagai verifikasi paling dasar.

T. Apakah hal yang sama bisa dilakukan di PowerShell? J. Bisa. Logika menghitung hasil git diff --name-only lalu membandingkannya dengan batas atas bisa ditulis langsung di PowerShell juga. Sesuaikan script verifikasi dengan lingkungan yang Anda pakai.

T. Apakah langkah ini bisa dijalankan pemula? J. Bisa. Justru makin ampuh untuk pemula. Walaupun belum paham kode sepenuhnya, kalau “tempat yang boleh disentuh” ditentukan lebih dulu, celaka besar bisa dicegah. Bagi yang ingin memantapkan dasar, baca panduan pemula lebih dulu akan terasa lebih mulus.

Hasil yang benar-benar saya coba

Langkah ini saya buat untuk diri sendiri setelah celaka di awal tadi. Yang paling ampuh saat dicoba adalah memasukkan “batas atas jumlah file yang berubah” dan “pengecekan otomatis area terlindungi” ke dalam script verifikasi.

Faktanya, ketika saya jalankan sekitar 3 kali di repo warisan, sekali script berhenti karena jumlah file yang berubah melewati batas. Setelah saya lihat isinya, ternyata Claude Code menulis ulang sampai komponen bersama sambil memperbaiki teks. Seandainya itu lolos, diff-nya jadi tak terbaca jangkauan dampaknya. Berkat script yang berhenti, saya bisa memecah perbaikan jadi dua dan mengirimnya terpisah.

Bukan “kalau diserahkan ke AI pintar pasti aman”, tapi “serahkan dalam jangkauan yang masih bisa dikembalikan walau jatuh”. Cukup menggambar peta lebih dulu, rasa jam pertama berubah total. Kalau Anda yang bukan engineer ingin membagikan pembagian ini di tim, pintu masuk untuk non-engineer juga berguna.

Cara pakai resmi Claude Code juga bisa Anda cek di dokumentasi resmi Anthropic. Bagi yang ingin memantapkan aturan operasi di tangan sendiri dan membuatnya bisa direproduksi di tim, di pelatihan dan konsultasi kita akan memetakan repo Anda sendiri bersama-sama.