Debugging dengan AI bisa sangat membantu, terutama saat error-nya panjang, stack trace-nya berlapis, atau kita belum paham bagian mana yang sebenarnya rusak.
Tapi ada satu kebiasaan yang sering membuat hasilnya buruk: menempel error ke AI lalu menulis, "fix ini."
Kadang jawabannya benar. Kadang hanya terlihat benar. AI mungkin memberi solusi umum yang cocok untuk kasus mirip, tapi tidak cocok dengan project kamu. Karena itu, debugging dengan AI sebaiknya dipakai untuk memperjelas masalah dulu, bukan langsung mencari potongan kode ajaib.
Kirim error lengkap, bukan potongan paling bawah
Saat error muncul, banyak orang hanya menyalin baris terakhir. Padahal bagian penting sering ada di atasnya: file mana yang memanggil fungsi, modul mana yang gagal load, atau request apa yang memicu error.
Kirim error lengkap kalau memungkinkan. Kalau terlalu panjang, kirim bagian:
- pesan error utama
- stack trace yang menyebut file project
- command yang dijalankan
- route atau fitur yang dibuka
- perubahan terakhir sebelum error muncul
Prompt:
Saya sedang debugging error ini di project Next.js.
Tolong bantu baca error-nya dulu, jangan langsung memberi kode.
Konteks:
- route yang dibuka: /tutorials
- command: npm run dev
- perubahan terakhir: menambahkan filter tag di searchParams
Error:
[tempel error lengkap]
Tolong jelaskan:
1. arti error ini
2. file mana yang paling perlu dicek
3. 3 dugaan penyebab, urut dari paling mungkin
Dengan prompt ini, AI dipaksa membaca masalah, bukan asal membuat patch.
Jelaskan langkah reproduksi
Error yang sama bisa punya penyebab berbeda tergantung langkahnya.
Contoh:
- error muncul saat build, tapi tidak saat dev
- error muncul di mobile, tapi tidak di desktop
- error muncul setelah login, tapi tidak untuk guest
- error muncul saat data kosong
- error muncul hanya setelah refresh halaman
Langkah reproduksi membuat AI memahami pola.
Tulis seperti ini:
Langkah reproduksi:
1. Jalankan npm run dev.
2. Buka /admin/artikel.
3. Pilih filter Format: Pilar.
4. Klik Filter.
5. Error muncul di server terminal.
Kalau error tidak selalu muncul, tulis juga: "error intermittent" atau "kadang muncul setelah hot reload".
Bedakan gejala dan penyebab
Saat debugging, jangan langsung percaya penyebab pertama yang terlihat.
Misalnya error berbunyi:
Cannot read properties of undefined
Gejalanya adalah ada nilai undefined. Penyebabnya bisa banyak:
- query database tidak mengembalikan data
- include relasi kurang lengkap
- fallback lokal tidak punya field yang sama
- komponen menerima prop yang berbeda
- data loading belum selesai
Minta AI membedakan gejala dan penyebab:
Tolong bedakan antara gejala error dan kemungkinan penyebab aslinya.
Jangan memberi solusi dulu sebelum menjelaskan bukti dari error.
Ini membuat proses debugging lebih rapi.
Minta cara mengecek setiap dugaan
Solusi yang bagus harus bisa diuji.
Setelah AI memberi beberapa dugaan, minta langkah pengecekan:
Untuk setiap dugaan, beri:
- file yang perlu dicek
- log sementara yang bisa ditambahkan
- tanda bahwa dugaan itu benar
- tanda bahwa dugaan itu salah
Contoh:
Jika dugaan AI adalah "data article tidak punya tags", cara mengeceknya bisa dengan melihat query Prisma, include relasi, atau console log shape data sebelum masuk komponen.
Dengan cara ini, kamu tidak menebak-nebak lagi.
Jangan langsung terima patch besar
AI sering memberi patch besar saat diminta memperbaiki bug. Ini berisiko karena satu bug kecil bisa berubah menjadi refactor separuh file.
Gunakan batasan:
Tolong beri fix paling kecil dulu.
Jangan refactor struktur komponen.
Jangan ubah behavior lain.
Kalau butuh perubahan besar, jelaskan alasannya dulu.
Fix kecil lebih mudah dicek. Kalau fix kecil tidak cukup, baru naik ke perubahan berikutnya.
Setelah fix, minta test case
Bug yang sudah diperbaiki perlu dikunci agar tidak balik lagi.
Prompt:
Setelah fix ini, test case apa yang perlu dibuat?
Tolong sertakan:
- kasus normal
- kasus data kosong
- kasus input invalid
- kasus yang dulu menyebabkan bug
Kalau project belum punya test otomatis, buat checklist manual:
- buka halaman yang error
- ulangi langkah reproduksi
- coba data kosong
- coba data panjang
- cek console browser
- cek terminal dev server
Debugging belum selesai hanya karena error hilang. Selesai ketika kita paham penyebabnya dan tahu cara mencegahnya balik.
Contoh prompt debugging yang lebih matang
Pakai template ini:
Saya ingin debugging, bukan langsung minta rewrite.
Project:
- framework:
- bahasa:
- database/library:
- route/fitur:
Masalah:
- error muncul saat:
- langkah reproduksi:
- perubahan terakhir:
Error:
[tempel error]
Tolong jawab dalam format:
1. Arti error dalam bahasa sederhana.
2. Dugaan penyebab paling mungkin.
3. Cara mengecek tiap dugaan.
4. Fix paling kecil yang disarankan.
5. Test/checklist setelah fix.
Template ini bisa dipakai untuk error frontend, backend, build, dependency, atau deployment.
Kesalahan umum saat debugging dengan AI
Pertama, mengirim error tanpa konteks. AI jadi menebak dari pola umum.
Kedua, langsung meminta kode. Padahal yang dibutuhkan kadang hanya memahami penyebab.
Ketiga, tidak mengecek versi library. Jawaban AI bisa memakai API yang tidak tersedia di project.
Keempat, menerima fix yang terlalu luas. Bug kecil bisa berubah menjadi perubahan besar yang susah direview.
Kelima, tidak membuat test atau checklist setelah fix.
Kesimpulan
Debugging dengan AI paling berguna saat kamu memberi error lengkap, langkah reproduksi, dan konteks project. Minta AI menjelaskan masalah, menyusun dugaan, lalu memberi cara mengecek.
Kalau alurnya seperti itu, AI bukan sekadar pemberi kode. Ia menjadi alat bantu membaca masalah dengan lebih cepat, tanpa membuat kita kehilangan kendali atas perubahan.