Cara Aman Membuat Edit Pertama di Repo Lama dengan Claude Code

Di repo internal yang baru saja saya warisi, hari pertama langsung berantakan.

“Coba baca semua dulu, lalu rapikan bagian yang menurutmu perlu,” begitu saya minta ke Claude Code. Tiga puluh menit kemudian, 23 file sudah berubah. Isinya sebenarnya tidak buruk. Tapi konfigurasi deploy produksi dan file pembayaran yang seharusnya tidak boleh disentuh siapa pun ikut “dirapikan sekalian”. Diff-nya terlalu besar sampai saya sendiri tidak tahu mana perubahan yang benar-benar perlu. Akhirnya semuanya saya buang dan mulai dari nol.

AI yang pintar bisa bikin kecelakaan bukan karena masalah kemampuan. Penyebabnya cuma satu: tidak ada yang menentukan “sampai mana boleh disentuh” sebelum masuk. Hari ini kita susun ulang hari pertama itu menjadi sesuatu yang bisa di-rollback, bisa diverifikasi, dan bisa selesai sampai akhir.

Poin penting

Hari pertama masuk ke kode orang lain, tulis dulu dalam satu halaman: “tempat yang boleh dibaca, tempat yang tidak boleh disentuh, dan perintah verifikasi yang dijalankan setelah selesai”.
Jangan serahkan perombakan besar ke Claude Code sejak awal. Mulai dari satu edit kecil yang bisa di-rollback (merapikan nama test, menambah komentar, dan sejenisnya).
Sebelum laporan “selesai”, selalu jalankan satu perintah verifikasi dan simpan hasilnya.
Hapus file, DB produksi, proses billing, dan force push semuanya dikunci ke “konfirmasi manusia” di hari pertama. Yang sudah terbukti aman baru diotomasi belakangan.
Kalau diff mulai membengkak, jangan utak-atik prompt dulu. Kurangi dulu jumlah file yang boleh disentuh.

Kenapa harus menentukan batas di hari pertama

Repo baru itu seperti kota tanpa peta. File mana yang jadi jantung sistem, dan mana yang kalau disentuh langsung rusak, di awal tidak ada yang bisa melihatnya.

Kalau di sini Anda minta Claude Code “lihat semuanya lalu perbaiki”, AI dengan niat baik akan menyentuh banyak hal. Bukan AI yang salah. Yang salah adalah manusia yang tidak menyerahkan batas wilayahnya. Kalau Anda bilang ke karyawan baru “tolong urus toko sebaiknya”, lalu pengaturan kasir ikut diubah, itu kesalahan yang memberi instruksi, kan?

Jadi yang pertama harus dilakukan bukan menulis prompt pintar, tapi menggambar satu lembar peta. Rak yang boleh dibaca, laci yang tidak boleh dibuka, dan cek penguncian sebelum pulang. Cukup tulis tiga hal ini di kertas, dan hampir semua kecelakaan hari pertama lenyap.

Tiga batas yang ditentukan lebih dulu

Urutan itu penting. Kita kunci dari atas ke bawah.

Yang ditentukan	Contoh konkret	Kenapa ditentukan duluan
Tempat yang boleh dibaca	`src/`, `docs/`, file test	Kalau semua dibaca, AI cenderung mengusulkan perubahan yang tidak relevan
Tempat yang tidak boleh disentuh	`.env`, pembayaran, autentikasi, migrasi DB, konfigurasi deploy produksi	Kalau ini rusak, tidak bisa diperbaiki
Verifikasi setelah selesai	`npm run build`, satu test	Supaya setiap kali ada “bukti bahwa kode berjalan”

Tiga hal ini saya tulis di kertas (boleh juga sebagai teks biasa), lalu saya simpan di ONBOARDING.md di folder kerja. File inilah yang pertama saya berikan untuk dibaca Claude Code. Bagikan petanya dulu, baru biarkan AI berjalan di kota itu.

Yang diserahkan ke AI, dan yang diputuskan manusia

Kalau dua hal ini dicampur, pasti kecelakaan. Mari kita pertegas garisnya.

Pekerjaan yang boleh diserahkan ke Claude Code

Membaca sekilas seluruh repo lalu meringkas strukturnya.
Mencari “fitur ini ada di file yang mana”.
Membuat draf perbaikan kecil yang bisa di-rollback: merapikan nama test, menambah komentar, melengkapi tipe.
Menjalankan perintah verifikasi, membaca log gagal, dan menebak penyebabnya.

Pekerjaan yang harus diputuskan manusia

Apakah mengizinkan perubahan yang masuk ke area terlarang.
Menghapus file, operasi ke DB produksi, proses billing, force push.
Keputusan akhir apakah perubahan desain besar boleh di-merge.
Apakah harus menghentikan saat diff melebar lebih dari perkiraan.

Kriteria saya sederhana. “Hal yang kalau salah masih bisa di-rollback pakai git” diserahkan ke AI. “Hal yang tidak bisa di-rollback” manusia yang menekan tombolnya. Asal garis ini dijaga, hari pertama tidak akan ambruk besar.

Template prompt siap salin

Sebelum masuk ke edit pertama, ini yang saya kirim. Jangan langsung minta menulis kode; minta dia mengembalikan rencananya dulu, itu kuncinya.

Ini repo lama yang baru pertama kali saya sentuh. Patuhi aturan berikut.

[Boleh dibaca] hanya src/ dan docs/ dan file test
[Jangan sentuh] .env / autentikasi / pembayaran / migrasi DB / konfigurasi deploy produksi
[Tujuan kali ini] satu perbaikan kecil yang bisa di-rollback (contoh: merapikan nama test)
[Verifikasi] setelah perubahan, selalu jalankan `npm run build` lalu tempel hasilnya

Belum boleh mengubah kode apa pun.
Pertama, kembalikan rencana "file mana yang akan diperbaiki dan bagaimana",
plus aturan di atas yang Anda tuliskan ulang dengan kata-kata Anda sendiri.

Kalau rencana yang kembali benar-benar mengulang batasan kita, berarti lulus. Kalau dia mencoba memperlebar cakupan, hentikan saat itu juga. Kalau rencananya bagus, lanjutkan dengan “lakukan persis seperti itu, sampai jalankan build”.

Menyimpan batas dalam bentuk kode

Aturan di kertas mudah dilupakan. Karena itu rencana onboarding saya simpan juga dalam bentuk yang bisa dibaca mesin. Skrip di bawah ini langsung jalan. Ganti isinya untuk repo Anda sendiri.

#!/usr/bin/env bash
# Rangkum rencana onboarding repo lama ke dalam satu file JSON
set -euo pipefail

cat > onboarding-plan.json <<'JSON'
{
  "goal": "menyelesaikan edit pertama di repo lama dengan aman",
  "readOnlyCommands": [
    "git status --short",
    "git ls-files | head -50",
    "grep -rn \"TODO\\|FIXME\" src | head -20"
  ],
  "protectedAreas": [".env", "billing", "auth", "db/migrations", "deploy/prod"],
  "firstTask": "satu perbaikan kecil pada dokumentasi atau test yang bisa di-rollback",
  "proofCommand": "npm run build",
  "rollback": "git diff -- path/to/changed-file && git checkout -- path/to/changed-file"
}
JSON

echo "=== Rencana onboarding ==="
cat onboarding-plan.json

echo ""
echo "=== Diff saat ini (kosong artinya belum diedit) ==="
git status --short

Skrip ini memang tidak mencolok. Nilainya ada di sini: sebelum mulai kerja, Anda mengunci “area terlarang” dan “perintah bukti” ke dalam file. Cukup ganti protectedAreas dengan tempat-tempat berbahaya di repo Anda, dan peta hari pertama langsung jadi.

Sediakan juga satu perintah verifikasi supaya lebih tenang. Untuk proyek Node.js, cek minimal seperti ini sudah bisa memastikan secara mekanis “apakah ada yang rusak”.

// check.mjs : skrip minimal hanya untuk memastikan build lewat
import { execSync } from "node:child_process";

try {
  // ganti dengan perintah verifikasi proyek Anda sendiri
  execSync("npm run build", { stdio: "inherit" });
  console.log("Verifikasi OK: build lewat. Silakan review diff-nya.");
} catch (e) {
  console.error("Verifikasi GAGAL: build jatuh. Jangan di-merge, cek penyebabnya dulu.");
  process.exit(1);
}

Kalau node check.mjs hijau, kirim diff ke review; kalau merah, hentikan. Cukup dengan satu skrip ini, kecelakaan “harusnya jalan kok” lalu di-merge langsung lenyap.

Tiga cara pakai di lapangan

Kalau ada situasi yang mirip, jangan susun ulang prosedurnya. Cukup ganti namanya dengan kondisi lapangan Anda.

1. Serah terima situs konten Biarkan dia membaca dulu lokasi data artikel, folder gambar, perintah build, dan halaman produk untuk memahami struktur. Edit pertama cukup “perbaikan satu tautan rusak” saja. Kalau build lewat, kirim ke review. Penulisan ulang isi besar-besaran baru dilakukan setelah terbukti aman.

2. Codebase SaaS Tulis tegas autentikasi, billing, dan migrasi DB sebagai area terlarang. Tugas pertama dibatasi sekadar “memperjelas kalimat penjelasan test”, dan baru lanjut setelah disetujui manusia. Kalau di sini lengah, “perbaikan baik hati” bisa masuk ke logika pembayaran dan bikin jantung berdebar.

3. Repo legacy lama “Modernisasi seluruhnya” itu kata terlarang. Diff-nya akan jadi besar sampai tak terbaca. Sebagai gantinya, mulai dari langkah kecil yang bisa diverifikasi build: memperbaiki typo nama fungsi, merapikan nama test. Sekali berhasil, lanjutkan langkah berikutnya dengan pola yang sama.

Setiap contoh punya “titik berhenti”. Karena ada titik berhenti, pekerjaan tidak melebar tanpa batas.

Contoh kegagalan, dan cara memperbaikinya

Saya tulis jujur saja. Beberapa kali pertama, semuanya gagal.

Minta bantuan tanpa menulis area terlarang -> diff jadi terlalu besar untuk di-review, akhirnya semua dibuang. Cara memperbaikinya sederhana: sebelum mengulang menyusun kalimat permintaan, kurangi dulu “file yang boleh dibaca”. Semakin sempit cakupannya, semakin sempit ruang AI untuk lepas kendali.

Menjalankan build setelah semua perubahan selesai -> jadi tidak tahu edit mana yang merusak. Sekarang saya jalankan verifikasi setiap kali memperbaiki satu file. Momen rusaknya tercatat, jadi penyebabnya langsung ketahuan.

Mengandalkan mata sendiri saja untuk verifikasi -> di hari sibuk pasti ada yang terlewat. Sekarang, “hal yang bisa diketahui mesin” benar-benar saya serahkan ke mesin. Build lewat atau tidak, hasil test, tautan rusak. Mata manusia hanya untuk keputusan desain yang tidak bisa ditangkap mesin. Dengan ini, review tengah malam berkurang drastis.

Saya menulis jebakan-jebakan ini di artikel karena pembaca tidak akan sadar dirinya dalam kondisi berbahaya kalau hanya melihat contoh sukses. Catat singkat permintaan mana yang melebar dan verifikasi mana yang terlewat, supaya diri Anda berikutnya tidak jatuh ke lubang yang sama.

Pertanyaan umum

T. Edit pertama sebaiknya pilih apa? J. Pilih “hal yang kalau salah masih bisa di-rollback pakai git checkout”. Merapikan nama test, menambah komentar, memperbaiki typo termasuk aman. Fitur baru atau perubahan konfigurasi tidak cocok untuk hari pertama.

T. Seberapa detail harus menulis area terlarang? J. Cukup “tempat yang kalau rusak tidak bisa diperbaiki” saja. .env, autentikasi, billing, konfigurasi deploy produksi, migrasi DB. Di awal cukup kunci lima ini, dan kecelakaan fatal hampir bisa dicegah.

T. Bisakah saya melewati langkah meminta Claude Code mengembalikan rencana? J. Saya sarankan jangan dilewati. Dengan sedikit usaha meminta dia menuliskan ulang rencananya, Anda bisa menemukan ketidaksesuaian cakupan sebelum mengedit. Jauh lebih murah daripada baru sadar setelah kode ditulis.

T. Apakah perintah verifikasi cukup build saja? J. Di hari pertama, satu build sudah cukup. Setelah terbiasa, tambah satu test terkait. Kalau dari awal mau menjalankan semua test, terlalu berat dan tidak berkelanjutan. Mulai kecil, tambah setelah log sukses menumpuk.

T. Apa yang perlu diperhatikan saat menerapkan ke tim? J. Tulis batas-batasnya di file bersama seperti ONBOARDING.md supaya semua orang memakai peta yang sama. Kalau area terlarang berbeda-beda per orang, standar review pun jadi goyah.

Yang saya konfirmasi setelah mencobanya

Setelah “kecelakaan 23 file” di awal tadi, saya mengubah urutan onboarding. Saya berhenti mencari prompt pintar, dan lebih dulu mengunci area terlarang serta perintah verifikasi di onboarding-plan.json. Cukup dengan ini, kecelakaan yang menyentuh pembayaran atau konfigurasi produksi jadi nol.

Di hari saya membatasi edit pertama ke “merapikan nama test”, diff-nya cukup 8 baris dan build lewat sekali jalan. Review tidak sampai dua menit. Sebaliknya, di hari lain saat saya minta tanpa menentukan batas, diff membengkak lagi dan semuanya dibuang. Bedanya bukan pada kecerdasan model, tapi pada apakah saya menggambar peta sebelum masuk.

Kalau Anda ingin mengukuhkan pola menyentuh kode orang lain dengan aman lewat contoh nyata di tim sendiri, saya bantu menyusun cara onboarding yang sesuai pekerjaan Anda lewat pelatihan dan konsultasi. Mulailah hari ini dengan menuliskan lima area terlarang di repo Anda sendiri.