Begitu kalian mulai nyaman pakai Claude Code buat baca code, review hasil, dan masuk ke repo yang lebih asing, ada satu area yang mulai terasa sangat menggoda.

Debugging.

Dan di sinilah banyak orang jatuh ke jebakan yang sama.

Mereka lihat gejala, lalu langsung minta fix.

Padahal bug yang kelihatan di permukaan belum tentu akar masalahnya ada di situ.

Claude bisa bantu debug, tapi jangan dipakai buat nebak

Karena Claude cepat, kadang kita tergoda buat pakai dia seperti mesin tebak.

"Error ini kenapa?"

"Coba fix bug ini."

"Kira kira penyebabnya apa?"

Pertanyaan seperti itu bisa memulai percakapan, tapi jangan berhenti di sana.

Kalau kalian langsung lompat ke solusi tanpa investigasi yang cukup, kalian berisiko dapet perbaikan yang kelihatan pintar tapi cuma nutup gejala.

Bug-nya bisa hilang sebentar. Akar masalahnya masih hidup.

Mulai dari bukti, bukan dugaan

Cara yang lebih sehat adalah ngajak Claude mulai dari bukti.

Kasih error message yang lengkap. Kasih langkah reproduksi. Kasih file yang relevan. Kasih tahu perubahan terakhir yang mungkin berhubungan.

Lalu minta Claude bantu susun investigasi dulu.

Contohnya:

"Ini error yang muncul, ini langkah buat reproduksi, dan ini file yang saya curigai. Tolong bantu urutkan kemungkinan akar masalah dan bagian mana yang paling layak dicek dulu. Jangan usul fix dulu."

Kalimat seperti ini mengubah ritme kerja cukup jauh.

Kalian nggak lagi minta tebak tebakkan. Kalian lagi minta partner investigasi.

Minta urutan cek, bukan patch instan

Waktu bug muncul, yang paling membantu sering bukan solusi langsung.

Yang paling membantu adalah urutan cek yang masuk akal.

Bagian mana yang paling mungkin salah. Nilai apa yang harus diverifikasi. Alur data mana yang harus dilihat dulu. Komponen mana yang perlu dibandingkan dengan flow yang normal.

Claude cukup bagus untuk bantu bikin urutan cek seperti ini.

Dan begitu urutan ceknya jelas, kalian jadi lebih cepat membedakan mana hipotesis yang kuat dan mana yang cuma asumsi malas.

Claude kuat kalau kalian pakai buat memperjelas logika

Kadang debugging macet bukan karena kalian kurang pintar. Tapi karena logika masalahnya kusut di kepala.

Di situ Claude bisa bantu banyak.

Misalnya kalian bisa tanya:

• "kalau error ini muncul di sini, data buruknya kemungkinan berasal dari mana?"
• "jalur data mana yang paling masuk akal untuk ditelusuri mundur?"
• "kalau saya cuma boleh cek satu lapis dulu, lapis mana yang paling informatif?"

Pertanyaan seperti ini bikin debugging lebih terstruktur.

Bukan lebih dramatis. Bukan lebih cepat karena sulap. Tapi lebih rapi.

Fix datang setelah arah masalah jelas

Begitu penyebabnya mulai kelihatan, baru minta usulan fix kecil.

Ini penting.

Jangan kasih Claude tugas memperbaiki hal yang bahkan arah rusaknya belum jelas.

Kalau investigasi kalian menunjukkan sumber masalah ada di validasi input, ya minta fix kecil di validasi input. Kalau ternyata masalahnya di urutan async call, ya fokus ke situ.

Fix yang lahir dari akar masalah hampir selalu lebih sehat daripada fix yang lahir dari rasa panik.

Penutup

Claude Code bisa jadi partner debugging yang kuat, asal kalian nggak memakainya seperti mesin tembak solusi.

Mulai dari bukti. Minta bantu susun investigasi. Minta urutan cek. Pakai dia buat memperjelas logika masalah sebelum menyentuh perbaikan.

Karena dalam debugging, jawaban cepat yang salah sering lebih mahal daripada investigasi yang tenang.

Di tulisan berikutnya, kita bahas situasi yang mulai sering muncul waktu kalian sudah lebih nyaman: minta Claude bantu perubahan yang menyentuh lebih dari satu file, tanpa bikin scope-nya lepas kendali.