Triase bug dengan Claude Code: loop praktis untuk perbaikan cepat

Apa itu triase bug dan mengapa loop ini penting

Bugs terasa acak ketika setiap laporan berubah jadi misteri satu-satu. Anda mengutak-atik kode, mencoba beberapa ide, dan berharap masalahnya hilang. Kadang hilang, tapi Anda tidak banyak belajar, dan masalah yang sama muncul lagi dalam bentuk lain.

Triase bug adalah kebalikan dari itu. Ini cara cepat mengurangi ketidakpastian. Tujuannya bukan memperbaiki semuanya sekaligus. Tujuannya mengubah keluhan samar menjadi pernyataan yang jelas dan dapat diuji, lalu membuat perubahan terkecil yang membuktikan pernyataan itu kini salah.

Itulah mengapa loop ini penting: reproduksi, minimalkan, identifikasi penyebab yang mungkin dengan bukti, tambahkan tes regresi, implementasikan perbaikan sempit, dan validasi. Setiap langkah menghilangkan jenis tebak-tebakan tertentu. Lewatkan langkah dan Anda sering membayar dengan perbaikan yang lebih besar, efek samping, atau bug yang “terperbaiki” padahal tidak benar-benar terselesaikan.

Berikut contoh realistis. Seorang pengguna berkata: “Tombol Simpan kadang tidak merespon.” Tanpa loop, Anda mungkin menelusuri kode UI dan mengubah timing, state, atau panggilan jaringan. Dengan loop, pertama-tama Anda ubah “kadang” menjadi “selalu, di bawah kondisi ini,” misalnya: “Setelah mengedit judul, lalu cepat berpindah tab, Simpan tetap dinonaktifkan.” Kalimat itu saja sudah kemajuan.

Claude Code bisa mempercepat bagian berpikir: mengubah laporan menjadi hipotesis tepat, menyarankan tempat untuk dilihat, dan mengusulkan tes minimal yang harus gagal. Ia sangat membantu dalam memindai kode, log, dan diff terbaru untuk menghasilkan penjelasan yang masuk akal dengan cepat.

Anda tetap harus memverifikasi apa yang penting. Konfirmasi bug itu nyata di lingkungan Anda. Utamakan bukti (log, trace, tes yang gagal) daripada cerita yang terdengar logis. Jaga agar perbaikan sekecil mungkin, buktikan dengan tes regresi, dan validasi dengan pemeriksaan yang jelas agar Anda tidak menukar satu bug dengan bug lain.

Hadiahnya adalah perbaikan kecil dan aman yang bisa Anda jelaskan, pertahankan, dan cegah kembalinya.

Siapkan workspace triase (sebelum menyentuh kode)

Perbaikan yang baik dimulai dengan workspace bersih dan satu pernyataan masalah yang jelas. Sebelum Anda bertanya ke Claude apa pun, pilih satu laporan dan tulis ulang sebagai:

“Ketika saya melakukan X, saya mengharapkan Y, tetapi saya mendapatkan Z.”

Jika Anda tidak bisa menulis kalimat itu, Anda belum punya bug. Anda punya misteri.

Kumpulkan dasar-dasarnya di awal agar tidak terus berputar. Detail ini membuat saran bisa diuji daripada samar: versi aplikasi atau commit (dan apakah itu lokal, staging, atau produksi), detail lingkungan (OS, browser/perangkat, feature flag, region), input tepatnya (field form, payload API, aksi user), siapa yang melihatnya (semua, peran tertentu, satu akun/tenant), dan apa arti “diharapkan” (copy, state UI, status code, aturan bisnis).

Lalu simpan bukti selagi masih segar. Satu timestamp bisa menyelamatkan berjam-jam. Tangkap log sekitar kejadian (client dan server jika mungkin), screenshot atau rekaman singkat, request ID atau trace ID, timestamp tepat (dengan zona waktu), dan snippet data terkecil yang memicu masalah.

Contoh: aplikasi React yang dihasilkan Koder.ai menunjukkan “Payment succeeded” tapi order tetap “Pending.” Catat peran pengguna, ID order tepat, body respons API, dan baris log server untuk request ID itu. Sekarang Anda bisa meminta Claude fokus pada satu alur alih-alih bertele-tele.

Terakhir, tetapkan aturan berhenti. Putuskan apa yang akan dihitung sebagai perbaikan sebelum mulai ngoding: tes spesifik yang lulus, perubahan state UI, error tidak lagi muncul di log, plus daftar periksa validasi singkat yang akan Anda jalankan setiap kali. Ini mencegah Anda “memperbaiki” gejala dan mengirim bug baru.

Ubah laporan bug menjadi pertanyaan tepat untuk Claude

Laporan bug berantakan biasanya mencampur fakta, tebakan, dan frustrasi. Sebelum minta bantuan, ubah menjadi pertanyaan tajam yang bisa dijawab Claude dengan bukti.

Mulai dengan ringkasan satu kalimat yang menyebut fitur dan kegagalan. Bagus: “Menyimpan draft kadang menghapus judul di mobile.” Tidak bagus: “Drafts rusak.” Kalimat itu menjadi jangkar untuk keseluruhan thread triase.

Lalu pisahkan apa yang Anda lihat dari apa yang Anda harapkan. Buat saja dan konkret: tombol yang diklik, pesan di layar, baris log, timestamp, perangkat, browser, branch, commit. Jika belum ada, katakan demikian.

Struktur sederhana yang bisa Anda paste:

• Summary (satu kalimat)
• Observed behavior (apa yang terjadi, termasuk teks error)
• Expected behavior (apa yang seharusnya terjadi)
• Repro steps (bernomor, set terkecil yang Anda tahu)
• Environment (versi aplikasi, perangkat, OS, browser, config flags)

Jika detail hilang, minta sebagai pertanyaan ya/tidak agar orang bisa jawab cepat: Apakah terjadi pada akun baru? Hanya di mobile? Hanya setelah refresh? Mulai setelah release terakhir? Bisa direproduksi di incognito?

Claude juga berguna sebagai “pembersih laporan.” Paste laporan asli (termasuk teks dari screenshot, log, dan cuplikan chat), lalu minta:

“Tulis ulang ini sebagai checklist terstruktur. Tandai kontradiksi. Daftarkan 5 fakta paling penting yang hilang sebagai pertanyaan ya/tidak. Jangan menebak penyebab dulu.”

Jika rekan bilang “Gagal acak,” arahkan menjadi sesuatu yang bisa diuji: “Gagal 2/10 kali di iPhone 14, iOS 17.2, saat mengetuk Simpan dua kali cepat.” Sekarang Anda bisa mereproduksinya dengan sengaja.

Langkah 1 - Reproduksi bug secara andal

Jika Anda tidak bisa membuat bug terjadi sesuai permintaan, setiap langkah selanjutnya hanyalah tebakan.

Mulailah mereproduksi di lingkungan terkecil yang masih bisa menunjukkan masalah: build dev lokal, branch minimal, dataset kecil, dan layanan sesedikit mungkin aktif.

Tulis langkah tepatnya agar orang lain bisa mengikutinya tanpa bertanya lagi. Buat agar bisa di-copy-paste: perintah, ID, dan payload sampel harus disertakan persis seperti dipakai.

Template capture sederhana:

• Setup: branch/commit, config flags, status database (kosong, seeded, copy produksi)
• Steps: aksi bernomor dengan input tepat
• Expected vs actual: apa yang Anda kira terjadi, apa yang terjadi
• Evidence: teks error, screenshot, timestamp, request ID
• Frequency: selalu, kadang-kadang, hanya kali pertama, hanya setelah refresh

Frekuensi mengubah strategi Anda. Bug yang “selalu” bagus untuk iterasi cepat. Bug yang “kadang” sering menunjukkan timing, caching, race condition, atau state tersembunyi.

Setelah punya catatan reproduksi, tanyakan ke Claude untuk probe cepat yang mengurangi ketidakpastian tanpa menulis ulang aplikasi. Probe yang baik kecil: satu baris log terarah di boundary yang gagal (input, output, state kunci), flag debug untuk satu komponen, cara memaksa deterministik (seed acak tetap, waktu tetap, satu worker), dataset kecil yang memicu masalah, atau satu pasangan request/response yang bisa diputar ulang.

Contoh: alur signup gagal “kadang.” Claude mungkin menyarankan log ID user yang dihasilkan, hasil normalisasi email, dan detail error unique constraint, lalu jalankan payload yang sama 10 kali. Jika gagal hanya pada run pertama setelah deploy, itu petunjuk kuat untuk cek migrasi, cache warmup, atau data seed yang hilang.

Langkah 2 - Minimalkan ke kasus uji kecil dan dapat diulang

Reproduksi yang baik berguna. Reproduksi minimal sangat kuat. Ia membuat bug lebih cepat dipahami, lebih mudah di-debug, dan kecil kemungkinan “terperbaiki” tanpa sengaja.

Singkirkan apa pun yang tidak diperlukan. Jika bug muncul setelah alur UI panjang, temukan jalur terpendek yang masih memicunya. Hapus layar opsional, feature flag, dan integrasi yang tidak relevan sampai bug hilang (Anda menghapus sesuatu yang esensial) atau tetap ada (Anda menemukan noise).

Lalu perkecil data. Jika bug butuh payload besar, coba payload terkecil yang masih membuatnya rusak. Jika butuh daftar 500 item, lihat apakah 5 gagal, lalu 2, lalu 1. Hapus field satu per satu. Tujuannya adalah seperangkat bagian paling sedikit yang masih mereproduksi bug.

Metode praktis adalah “hapus separuh dan uji ulang”:

• Potong langkah menjadi separuh dan cek apakah bug masih ada.
• Jika ya, pertahankan separuh itu dan potong lagi.
• Jika tidak, kembalikan separuh yang dihapus dan potong lagi.
• Ulangi sampai Anda tidak bisa menghapus apa pun tanpa kehilangan bug.

Contoh: halaman checkout crash “kadang” saat menerapkan kupon. Anda menemukan hanya gagal saat keranjang punya setidaknya satu item diskon, kupon huruf kecil, dan pengiriman diatur ke “pickup.” Itu kasus minimal: satu item diskon, satu kupon huruf kecil, satu opsi pickup.

Setelah kasus minimal jelas, minta Claude membuat scaffold reproduksi kecil: tes kecil yang memanggil fungsi gagal dengan input terkecil, skrip singkat yang memanggil satu endpoint dengan payload yang diperkecil, atau tes UI kecil yang mengunjungi satu route dan melakukan satu aksi.

Langkah 3 - Identifikasi kemungkinan penyebab utama (dengan bukti)

Setelah Anda bisa mereproduksi masalah dan punya kasus uji kecil, berhenti menebak. Tujuan Anda membuat daftar pendek penyebab yang masuk akal, lalu membuktikan atau menolak masing-masing.

Aturan berguna: batasi ke tiga hipotesis. Jika lebih, kemungkinan kasus uji masih terlalu besar atau observasi Anda masih samar.

Petakan gejala ke komponen

Terjemahkan apa yang Anda lihat ke bagian mana yang bisa terjadi. Gejala UI tidak selalu berarti bug di UI.

Contoh: halaman React menampilkan toast “Saved”, tapi record hilang nanti. Itu bisa menunjuk ke (1) state UI, (2) perilaku API, atau (3) jalur penulisan ke database.

Bangun bukti untuk tiap hipotesis

Minta Claude menjelaskan mode kegagalan yang mungkin dalam bahasa sederhana, lalu tanyakan bukti apa yang akan mengonfirmasi tiap hipotesis. Tujuannya mengubah “mungkin” menjadi “cek hal ini persis.”

Tiga hipotesis umum dan bukti yang perlu dikumpulkan:

• Mismatch UI/state: klien memperbarui state lokal sebelum server mengonfirmasi. Bukti: ambil snapshot state sebelum dan sesudah aksi, dan bandingkan dengan respons API yang sebenarnya.
• Edge case API: handler mengembalikan 200 tapi diam-diam melewatkan pekerjaan (validasi, parsing ID, feature flag). Bukti: tambahkan log request/response dengan correlation ID, dan verifikasi handler mencapai panggilan tulis dengan input yang diharapkan.
• Masalah database atau timing: transaksi rollback, conflict error, atau “read after write” dilayani dari cache/replica. Bukti: periksa query DB, baris yang terpengaruh, dan kode error; log boundary transaksi dan perilaku retry.

Jaga catatan Anda ringkas: gejala, hipotesis, bukti, verdict. Ketika satu hipotesis cocok dengan fakta, Anda siap mengunci tes regresi dan hanya memperbaiki yang perlu.

Langkah 4 - Tambahkan tes regresi yang gagal karena alasan yang tepat

Tes regresi yang baik adalah sabuk pengaman Anda. Ia membuktikan bug ada, dan memberi tahu kapan Anda benar-benar memperbaikinya.

Mulailah dengan memilih tes terkecil yang mencocokkan kegagalan nyata. Jika bug hanya muncul ketika beberapa bagian bekerja bersama, unit test bisa melewatkannya.

Pilih level tes yang cocok dengan bug

Gunakan unit test ketika satu fungsi mengembalikan nilai yang salah. Gunakan integration test ketika boundary antar bagian bermasalah (handler API + DB, atau UI + state). Gunakan end-to-end hanya jika bug bergantung pada alur pengguna penuh.

Sebelum minta Claude menulis apa pun, nyatakan ulang kasus yang diminimalkan sebagai perilaku yang ketat dan dapat diharapkan. Contoh: “Jika user menyimpan judul kosong, API harus mengembalikan 400 dengan pesan ‘title required’.” Sekarang tes memiliki target yang jelas.

Lalu minta Claude menyusun tes gagal terlebih dahulu. Jaga setup minimal dan salin hanya data yang memicu bug. Namai tes berdasarkan pengalaman pengguna, bukan fungsi internal.

Verifikasi draft (jangan percaya begitu saja)

Lakukan pengecekan cepat sendiri:

• Konfirmasi tes gagal pada kode sekarang karena alasan yang dimaksud (bukan karena fixture hilang atau impor salah).
• Periksa assert spesifik (status code, message, rendered text).
• Pastikan tes mencakup satu bug, bukan sekumpulan perilaku.
• Nama tes fokus ke pengguna, mis. “rejects empty title on save” bukan “handles validation.”

Setelah tes gagal karena alasan yang tepat, Anda siap menerapkan perbaikan sempit dengan percaya diri.

Langkah 5 - Terapkan perbaikan sempit

Setelah Anda punya repro kecil dan tes regresi yang gagal, tahan keinginan untuk “membersihkan” banyak hal. Tujuannya menghentikan bug dengan perubahan terkecil yang membuat tes lulus karena alasan yang benar.

Perbaikan sempit mengubah permukaan sekecil mungkin. Jika kegagalan di satu fungsi, perbaiki fungsi itu, bukan seluruh modul. Jika pengecekan boundary hilang, tambahkan pengecekan di boundary, bukan menambah perubahan di seluruh rantai panggilan.

Jika Anda menggunakan Claude untuk membantu, minta dua opsi perbaikan, lalu bandingkan cakupan dan risikonya. Contoh: jika form React crash saat field kosong, Anda mungkin mendapatkan:

• Opsi A: Tambah guard di submit handler yang memblokir input kosong dan menampilkan error.
• Opsi B: Refactor state handling sehingga field tidak pernah bisa kosong.

Opsi A biasanya pilihan triase: lebih kecil, lebih mudah direview, dan kurang mungkin merusak hal lain.

Untuk menjaga perbaikan sempit, sentuh sesedikit file mungkin, pilih perbaikan lokal daripada refaktor, tambahkan guard/validasi di tempat nilai buruk masuk, dan pertahankan perubahan perilaku eksplisit dengan satu before/after yang jelas. Tinggalkan komentar hanya jika alasannya tidak jelas.

Contoh konkret: endpoint API Go panic saat query param opsional hilang. Perbaikan sempit adalah tangani string kosong di boundary handler (parse dengan default, atau kembalikan 400 dengan pesan jelas). Hindari mengubah util parsing bersama kecuali tes regresi membuktikan bug ada di kode bersama itu.

Setelah ubahan, jalankan kembali tes gagal dan satu atau dua tes dekatnya. Jika perbaikan Anda memaksa pembaruan banyak tes yang tidak terkait, itu sinyal perubahan terlalu luas.

Langkah 6 - Validasi perbaikan dengan pemeriksaan yang jelas

Validasi adalah tempat Anda menangkap masalah kecil yang mudah terlewat: perbaikan yang lulus satu tes tetapi memecah jalur dekatnya, mengubah pesan error, atau menambah query lambat.

Pertama, jalankan kembali tes regresi yang Anda tambahkan. Jika lulus, jalankan tes tetangga: tes di file yang sama, modul yang sama, dan apa pun yang mencakup input serupa. Bug sering bersembunyi di helper bersama, parsing, pengecekan boundary, atau caching, jadi kegagalan relevan biasanya muncul di dekatnya.

Lalu lakukan pengecekan manual singkat menggunakan langkah laporan asli. Buat singkat dan spesifik: lingkungan yang sama, data yang sama, urutan klik atau panggilan API yang sama. Jika laporan samar, uji skenario persis yang Anda gunakan untuk mereproduksinya.

Daftar pemeriksaan validasi sederhana

• Tes regresi lulus, plus tes terkait di area yang sama.
• Langkah manual reproduksi tidak lagi memicu bug.
• Penanganan error masih masuk akal (pesan, status code, retry).
• Kasus tepi masih berperilaku (input kosong, ukuran maksimal, karakter asing).
• Tidak ada dampak performa yang jelas (loop ekstra, panggilan ekstra, query lambat).

Jika ingin bantuan tetap fokus, minta Claude rencana validasi singkat berdasarkan perubahan Anda dan skenario gagal. Bagikan file yang Anda ubah, perilaku yang dimaksud, dan apa yang mungkin terpengaruh. Rencana terbaik singkat dan bisa dieksekusi: 5–8 pemeriksaan yang bisa Anda selesaikan dalam beberapa menit, masing-masing dengan kriteria lulus/gagal jelas.

Terakhir, rekam apa yang Anda validasi di PR atau catatan: tes yang dijalankan, langkah manual yang dicoba, dan batasan (mis. “tidak dites di mobile”). Ini membuat perbaikan lebih mudah dipercaya dan ditinjau di kemudian hari.

Kesalahan umum dan jebakan (dan cara menghindarinya)

Cara tercepat membuang waktu adalah menerima "perbaikan" sebelum Anda bisa mereproduksi masalah sesuai permintaan. Jika Anda tidak bisa membuatnya gagal dengan andal, Anda tidak bisa tahu apa yang sebenarnya membaik.

Aturan praktis: jangan minta perbaikan sampai Anda bisa mendeskripsikan setup yang dapat diulang (langkah tepat, input, lingkungan, dan apa yang "salah"). Jika laporan samar, habiskan menit pertama mengubahnya menjadi checklist yang bisa Anda jalankan dua kali dan mendapatkan hasil sama.

Jebakan yang memperlambat

Memperbaiki tanpa kasus reproduksi. Wajibkan skrip atau langkah minimal yang "gagal setiap saat". Jika hanya "kadang-kadang", tangkap timing, ukuran data, feature flag, dan log sampai tidak acak lagi.

Memperkecil terlalu cepat. Jika Anda mengurangi kasus sebelum memastikan kegagalan baseline, sinyal bisa hilang. Kunci baseline reproduksi dulu, lalu perkecil satu per satu.

Membiarkan Claude menebak. Claude dapat mengusulkan penyebab yang mungkin, tapi Anda tetap perlu bukti. Minta 2–3 hipotesis dan pengamatan tepat yang bisa mengonfirmasi atau menolak tiap hipotesis (satu baris log, breakpoint, hasil query).

Tes regresi yang lulus karena alasan yang salah. Tes bisa “lulus” karena tidak pernah melewati path gagal. Pastikan tes gagal sebelum perbaikan, dan gagal dengan pesan atau assert yang diharapkan.

Menangani gejala bukan pemicu. Jika Anda menambahkan pengecekan null tetapi masalah sebenarnya adalah “nilai ini tidak seharusnya pernah null”, Anda mungkin menyembunyikan bug yang lebih dalam. Lebih baik perbaiki kondisi yang menciptakan state buruk itu.

Pemeriksaan cepat sebelum menyelesaikan

Jalankan tes regresi baru dan langkah reproduksi asli sebelum dan sesudah perubahan. Jika bug checkout hanya terjadi saat kode promo diterapkan setelah mengubah pengiriman, pertahankan urutan penuh itu sebagai “kebenaran”, meskipun tes minimal Anda lebih kecil.

Jika validasi Anda bergantung pada “terlihat bagus sekarang”, tambahkan satu pemeriksaan konkret (log, metrik, atau output spesifik) supaya orang berikutnya bisa memverifikasinya dengan cepat.

Checklist cepat, template prompt, dan langkah selanjutnya

Saat Anda tertekan waktu, loop kecil dan dapat diulang mengalahkan debugging heroik.

Checklist triase satu halaman

• Reproduce: dapatkan repro andal dan catat input tepat, lingkungan, serta expected vs actual.
• Minimize: reduksi ke langkah atau tes terkecil yang masih gagal.
• Explain: daftarkan 2–3 penyebab utama yang mungkin dan bukti untuk masing-masing.
• Lock it in: tambahkan tes regresi yang gagal karena alasan yang tepat.
• Fix + validate: lakukan perubahan paling sempit, lalu jalankan checklist validasi singkat.

Tulis keputusan akhir dalam beberapa baris agar orang berikutnya (seringnya Anda di masa depan) bisa mempercayainya. Format berguna: “Root cause: X. Trigger: Y. Fix: Z. Why safe: W. What we did not change: Q.”

Template prompt yang bisa dipaste

• “Given this bug report and logs, ask me only the missing questions needed to reproduce it reliably.”
• “Help me minimize: propose a smaller test case and tell me what to remove first, one change at a time.”
• “Rank likely root causes and cite the exact files, functions, or conditions that support each claim.”
• “Write a regression test that fails only because of this bug. Explain why it fails for the right reason.”
• “Suggest the narrowest fix, plus a validation checklist (unit, integration, and manual checks) that proves we didn’t break nearby behavior.”

Langkah selanjutnya: otomasi apa yang bisa diotomasi (skrip repro yang disimpan, perintah tes standar, template untuk catatan root-cause).

Jika Anda membangun aplikasi dengan Koder.ai (koder.ai), Planning Mode dapat membantu merencanakan perubahan sebelum menyentuh kode, dan snapshot/rollback mempermudah bereksperimen dengan aman saat Anda menyelesaikan repro yang rumit. Setelah perbaikan tervalidasi, Anda bisa mengekspor kode sumber atau melakukan deploy dan hosting aplikasi yang diperbarui, termasuk menggunakan domain kustom bila perlu.