Teknik Debugging Dibantu AI

Kalau ada satu kebiasaan yang paling sering bikin sesi debugging pakai AI berakhir buntu, itu adalah menempel error log lalu bertanya "ini kenapa, tolong perbaiki". Jawabannya memang datang cepat, tapi sering kali itu tebakan paling mungkin berdasarkan pola teks, bukan hasil penalaran atas kondisi sistem yang sebenarnya. Selama beberapa tahun terakhir saya bergelut dengan sistem yang berjalan di banyak lapisan — Laravel di atas, database di tengah, container dan jaringan di bawah — dan bug yang paling menyita waktu hampir selalu bug yang penyebabnya ada di lapisan yang tidak kelihatan dari pesan errornya. Di situ pola "minta hipotesis dulu, baru investigasi" jadi jauh lebih berguna dibanding pola "minta jawaban langsung".

Kenapa jawaban instan sering menyesatkan

Model bahasa dilatih untuk menghasilkan jawaban yang terdengar meyakinkan, dan itu masalahnya. Kalau saya cuma kasih satu potong stack trace, AI akan mengarang penjelasan yang paling umum untuk pola error semacam itu — misalnya "biasanya ini karena koneksi database timeout" — padahal di kasus saya penyebabnya bisa jadi container PHP yang salah versi, atau proses lain yang menahan lock. Jawaban itu masuk akal secara statistik, tapi belum tentu benar untuk sistem spesifik yang sedang saya hadapi. Efek sampingnya berbahaya: saya jadi menerapkan "perbaikan" untuk penyebab yang salah, bug-nya tetap ada, dan waktu terbuang untuk verifikasi yang seharusnya tidak perlu.

Minta hipotesis, bukan solusi

Pola yang saya pakai sekarang: sebelum minta perbaikan, saya minta AI menyusun daftar hipotesis yang mungkin, diurutkan dari yang paling mungkin sampai paling tidak mungkin, lengkap dengan alasan kenapa tiap hipotesis masuk akal berdasarkan gejala yang saya kasih. Prompt sederhananya kira-kira begini:

Ini gejalanya: [deskripsi error, kapan muncul, kapan tidak]
Ini environment-nya: [Laravel versi X, PHP di dalam container, DB di container terpisah]

Jangan langsung kasih solusi. Susun 3-5 hipotesis penyebab yang mungkin,
urutkan dari paling mungkin, dan untuk tiap hipotesis sebutkan langkah
investigasi konkret yang bisa saya jalankan untuk membuktikan atau
menggugurkannya.

Bedanya terasa langsung. Alih-alih satu jawaban yang mungkin salah, saya dapat semacam daftar periksa yang bisa saya jalankan satu per satu. Kalau hipotesis pertama gugur, saya lanjut ke hipotesis berikutnya sambil membawa informasi baru — dan biasanya di titik ini AI juga jadi lebih tajam karena konteksnya makin lengkap.

Menyempitkan lewat langkah investigasi, bukan tebakan berulang

Langkah investigasi yang diminta harus konkret dan bisa dieksekusi: perintah docker exec untuk masuk ke container yang benar, query untuk mengecek isi tabel, cara membaca log di lapisan mana. Setelah saya jalankan satu langkah, saya laporkan hasilnya apa adanya — termasuk kalau hasilnya "tidak ada apa-apa" atau "malah error lain" — dan minta AI merevisi daftar hipotesis berdasarkan bukti baru itu. Ini yang membedakan debugging terarah dari sekadar coba-coba: setiap giliran percakapan mempersempit ruang kemungkinan, bukan mengulang tebakan dari sudut yang sama. Satu kebiasaan yang saya pegang: kalau AI menyarankan investigasi ke arah yang menurut saya keliru berdasarkan pengalaman dengan sistem itu, saya sampaikan alasannya secara eksplisit, bukan sekadar menolak. Model tidak tahu detail lingkungan saya kecuali saya beri tahu, jadi koreksi saya sendiri adalah bagian dari input yang sama pentingnya dengan gejala aslinya.

Takeaway

Pola "hipotesis lalu investigasi" pada dasarnya memindahkan AI dari posisi "orang yang menjawab" ke posisi "partner yang membantu berpikir sistematis" — mirip cara saya sendiri mendekati bug rumit sebelum ada AI, cuma sekarang prosesnya lebih cepat karena ada yang membantu menyusun opsi dan langkah verifikasi. Untuk bug yang sederhana dan satu lapisan, tentu minta solusi langsung tetap efisien. Tapi begitu masalahnya melibatkan beberapa lapisan sistem sekaligus, memaksa diri — dan AI — untuk berhenti sejenak dan menyusun hipotesis dulu biasanya justru lebih cepat sampai ke akar masalah dibanding lompat langsung ke percobaan perbaikan.