Cara Menulis Prompt Perbaikan Bug untuk AI Coding Agent agar Tidak Menambal Gejala

Saat aplikasi rusak, dorongan pertama biasanya membuka AI lalu menulis “fitur pembayaran error, tolong perbaiki.” Kadang agent memang mengubah sesuatu dan error menghilang. Tetapi tanpa konteks, ia bisa menambal gejala, mengubah perilaku yang sebenarnya benar, atau menambahkan pengecualian baru yang membuat bug sejenis muncul lagi minggu depan. Bugfix yang baik perlu diperlakukan sebagai investigasi, bukan permintaan sulap.

Skematik menghubungkan laporan bug dengan niat asli dari PRD. Prompt perbaikan dapat membawa gejala, langkah reproduksi, perilaku yang seharusnya menurut acceptance criteria, serta arahan untuk menyelidiki penyebab. Ini membantu agent tidak hanya membaca keluhan pengguna, tetapi juga memahami kontrak produk yang seharusnya dipenuhi.

Pisahkan gejala dari dugaan penyebab

Gejala adalah hal yang bisa Anda lihat: tombol Simpan tidak memberi hasil, total invoice salah setelah diskon, atau daftar kosong setelah halaman dimuat ulang. Dugaan penyebab adalah tebakan: mungkin cache, mungkin query, mungkin validasi. Tulis keduanya secara terpisah. Agent harus bebas memeriksa kode dan membuktikan penyebab, bukan dipaksa mengikuti diagnosis yang belum tentu tepat.

• Lingkungan dan peran pengguna saat bug muncul.
• Langkah reproduksi yang dapat dilakukan orang lain.
• Hasil aktual, termasuk pesan error atau data yang salah.
• Perilaku yang seharusnya terjadi menurut produk.
• Batas perubahan: bagian mana yang tidak boleh rusak saat diperbaiki.

Laporan bug yang baik membuat dua orang dapat melihat kegagalan yang sama. Tanpa itu, agent hanya diberi cerita, bukan kasus yang bisa diuji.

Gunakan acceptance criteria sebagai kompas

Kriteria penerimaan memberi jawaban untuk pertanyaan penting: sebenarnya fitur ini harus berperilaku seperti apa? Jika PRD berkata nomor invoice harus unik dan transaksi gagal tidak boleh mengurangi stok, prompt bugfix dapat merujuk ke dua aturan tersebut. Agent lalu memiliki target yang lebih kuat daripada sekadar membuat error hilang dari layar.

Kalau PRD belum memuat perilaku yang diharapkan, jangan menyuruh agent menebak dari UI. Putuskan dulu aturannya bersama pemilik produk. Bug sering membuka celah keputusan lama yang belum pernah ditulis. Memperbaiki dokumen terlebih dahulu dapat mencegah tambalan yang nanti bertentangan dengan fitur berikutnya.

Minta agent menyelidiki sebelum mengubah

Prompt yang sehat meminta agent menelusuri jalur data: input masuk dari mana, validasi terjadi di mana, data disimpan ke mana, dan apa yang dibaca kembali oleh layar. Minta ia menyebut file yang diperiksa, menemukan penyebab paling mungkin, lalu menerapkan perubahan minimal. Setelah itu, agent harus menjalankan atau menambahkan pengujian yang membuktikan skenario gagal sudah tertutup.

Hindari permintaan “refactor sekalian” saat sedang memperbaiki bug. Perubahan besar membuat hasil sulit direview dan mencampur banyak risiko. Pisahkan pekerjaan kebersihan kode ke task lain setelah perilaku inti pulih. Anda akan jauh lebih mudah mengetahui apa yang benar-benar menyelesaikan masalah.

Tambahkan pelajaran yang bisa mencegah kelas bug serupa

Beberapa bug sangat spesifik dan cukup ditutup dengan test regresi. Sebagian lain menunjukkan aturan yang lebih umum, misalnya semua form harus menampilkan error inline saat gagal, atau seluruh mutasi stok harus divalidasi di server. Jika pelajarannya benar-benar berlaku luas, ubah menjadi acceptance criteria atau aturan proyek. Jangan memasukkan nama variabel dan satu kasus spesifik ke aturan global.

Skematik dapat membantu menyusun prompt perbaikan dari catatan bug dan bagian PRD yang relevan. Tetap lakukan review sebelum menjalankannya: pastikan langkah reproduksi tidak memuat data sensitif, perilaku target memang disetujui, dan batas perubahan cukup jelas untuk melindungi area lain.

Template prompt bugfix yang bisa dipakai

1. Jelaskan gejala dan langkah reproduksi dengan data contoh yang aman.
2. Tuliskan hasil aktual dan perilaku yang seharusnya.
3. Minta agent telusuri penyebab di kode sebelum mengubah apa pun.
4. Minta perubahan minimal beserta test yang membuktikan bug tertutup.
5. Minta ringkasan file yang berubah dan risiko regresi yang perlu dicek manual.