Triase bug dengan Claude Code menggunakan loop berulang: reproduksi, minimalkan, identifikasi penyebab yang mungkin, tambahkan tes regresi, dan kirim perbaikan sempit dengan pemeriksaan.
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.
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.
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:
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.
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:
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.
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”:
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.
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.
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.
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:
Jaga catatan Anda ringkas: gejala, hipotesis, bukti, verdict. Ketika satu hipotesis cocok dengan fakta, Anda siap mengunci tes regresi dan hanya memperbaiki yang perlu.
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.
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.
Lakukan pengecekan cepat sendiri:
Setelah tes gagal karena alasan yang tepat, Anda siap menerapkan perbaikan sempit dengan percaya diri.
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 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.
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.
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.
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.
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.
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.
Saat Anda tertekan waktu, loop kecil dan dapat diulang mengalahkan debugging heroik.
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.”
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.
Triase bug adalah kebiasaan mengubah laporan samar menjadi pernyataan yang jelas dan dapat diuji, lalu membuat perubahan terkecil yang membuktikan pernyataan itu sudah tidak benar lagi.
Ini lebih tentang mengurangi ketidakpastian langkah demi langkah daripada mencoba "memperbaiki semuanya" sekaligus: reproduce, minimize, bentuk hipotesis berbasis bukti, tambahkan tes regresi, perbaiki secara sempit, validasi.
Karena setiap langkah menghilangkan jenis tebakan yang berbeda.
Tulis ulang sebagai: “Saat saya melakukan X, saya mengharapkan Y, tetapi saya mendapatkan Z.”
Lalu kumpulkan konteks yang cukup agar bisa diuji:
Mulailah dengan memastikan Anda dapat mereproduksi di lingkungan terkecil yang masih menampilkan masalah (seringkali local dev dengan dataset kecil).
Jika itu "kadang-kadang", coba buat deterministik dengan mengendalikan variabel:
Jangan lanjut jika Anda belum bisa membuatnya gagal sesuai permintaan, karena selanjutnya hanya tebakan.
Meminimalkan berarti menghapus apa pun yang tidak diperlukan sambil menjaga agar bug tetap ada.
Metode praktis adalah “hapus separuh dan uji ulang”:
Perkecil langkah (alur pengguna lebih pendek) dan data (payload lebih kecil, lebih sedikit field/item) sampai Anda punya trigger terkecil yang bisa diulang.
Gunakan Claude Code untuk mempercepat analisis, bukan menggantikan verifikasi.
Permintaan yang baik misalnya:
Lalu Anda memvalidasi: reproduksi lokal, periksa log/trace, dan pastikan tes gagal karena alasan yang tepat.
Batasi ke tiga. Lebih dari itu biasanya berarti repro Anda masih terlalu besar atau observasi Anda terlalu samar.
Untuk tiap hipotesis, tulis:
Pilih level tes terkecil yang sesuai dengan kegagalan:
Tes regresi yang baik:
Buat perubahan terkecil yang membuat tes regresi gagal tadi menjadi lulus.
Aturan praktis:
Jika perbaikan memaksa pembaruan banyak tes yang tidak terkait, besar kemungkinan perubahannya terlalu luas.
Gunakan checklist singkat yang bisa Anda jalankan cepat:
Catat apa yang Anda jalankan dan apa yang tidak dites sehingga hasilnya dapat dipercaya.
Ini memaksa kemajuan dan mencegah debugging tanpa akhir.
