Debugging dengan AI: Prompt yang Menemukan Penyebab

Debugging dengan AI paling berhasil ketika kamu memberi model apa yang akan kamu berikan kepada rekan kerja di sebelah mejamu: error lengkapnya, kode yang memunculkannya, apa yang kamu harapkan, apa yang terjadi, dan apa yang sudah kamu coret dari daftar kemungkinan. Model tidak bisa menjalankan programmu atau melihat datamu, jadi semua yang diketahuinya tentang bug itu berasal dari apa yang kamu tempel. Satu kebiasaan yang paling berguna adalah meminta penyebabnya sebelum perbaikannya.

Tempel semuanya, bukan hanya error-nya

Dua tab di bawah ini menggambarkan bug yang sama. Sebuah skrip membaca file CSV yang diekspor dari Excel dan crash dengan KeyError: 'email', padahal file itu jelas punya kolom email.

Error-nya sajaLaporan lengkap

EditCopy

Perbaiki ini: KeyError: 'email'

Try it

Example replyReplies vary between models and runs.

KeyError berarti dictionary-nya tidak punya key bernama 'email'. Kamu bisa menghindari error itu dengan memakai .get(), yang mengembalikan None alih-alih memunculkan error:

email = row.get("email")

Atau cek dulu:

if "email" in row:
    email = row["email"]

Balasan pertama benar tentang apa itu KeyError, tapi sarannya justru merugikan di sini. Dengan row.get("email"), crash-nya hilang, dan setiap email menjadi None. Model menjawab versi error yang paling umum karena hanya itu yang digambarkan prompt-nya.

Laporan lengkap berhasil karena dua baris. "Hanya kolom pertama yang gagal" dan "disimpan dari Excel sebagai CSV UTF-8" adalah petunjuk yang mengarah ke byte order mark, dan tidak satu pun ada di pesan error-nya. Kamu jarang tahu detail mana yang menjadi petunjuk, dan itulah kenapa kamu menempel semuanya.

Lima hal yang perlu disertakan

1. Error lengkapnya. Seluruh traceback atau output console, bukan parafrasenya. Nomor baris dan rantai pemanggilannya menunjukkan di mana kegagalan dimulai, yang sering kali beberapa frame jauhnya dari tempat error itu muncul.
2. Kode yang memunculkannya. Fungsi yang gagal dan kode yang memanggilnya. Kalau error-nya menyebut sebuah baris, pastikan baris itu ada di bagian yang kamu tempel.
3. Yang diharapkan dan yang terjadi. Masing-masing satu kalimat. Untuk bug tanpa error sama sekali (output salah, halaman kosong, query yang lambat), inilah seluruh laporan bug-nya.
4. Environment-mu. Versi bahasa, sistem operasi, versi framework dan library kalau itu bisa berpengaruh. Bug encoding, path, dan tanggal sering bergantung pada platform.
5. Apa yang sudah kamu coba. Ini mencegah model menyarankannya lagi, dan hasil setiap percobaan adalah bukti. "Menghapus bagian email membuatnya berjalan" mempersempit bug CSV tadi menjadi satu kolom.

Minta penyebabnya sebelum perbaikannya

Permintaan perbaikan mengundang model untuk mengubah kode sampai error-nya hilang. Permintaan penyebab meminta model bernalar tentang kenapa error itu terjadi, dan perbaikannya mengikuti dari situ. Minta daftar pendek penyebab yang diurutkan, dengan cara mengecek masing-masing, lalu jalankan pengecekannya sendiri. Template ini melakukan hal itu:

Urutkan penyebabnya, belum perlu perbaikan

EditCopy

Fill inbahasaharapankenyataan

PartsTaskContextInputFormat

Task

Bantu aku menemukan penyebab bug di kode JavaScript-ku. Jangan tulis perbaikan dulu.

Context

Yang diharapkan: daftar pengguna muncul saat halaman dimuat Yang terjadi: halaman kosong, dan error ini muncul di console browser

Input

TypeError: Cannot read properties of undefined (reading 'map')function UserList() { const [users, setUsers] = useState(); useEffect(() => { fetch("/api/users") .then((res) => res.json()) .then((data) => setUsers(data)); }, []); return ( <ul> {users.map((u) => ( <li key={u.id}>{u.name}</li> ))} </ul> ); }

Format

Sebutkan maksimal tiga penyebab yang mungkin, yang paling mungkin di urutan pertama. Untuk masing-masing, berikan pengecekan satu baris yang bisa aku jalankan untuk memastikan atau mencoretnya.

Try it

Example replyReplies vary between models and runs.

1. Komponennya di-render sebelum datanya ada. useState() dimulai sebagai undefined, dan React me-render komponennya sekali sebelum effect-nya berjalan, jadi users.map dipanggil pada undefined. Itu saja sudah menghasilkan error yang persis sama denganmu, di setiap pemuatan. Cek: tambahkan console.log(users) tepat sebelum return. Kalau yang tercatat undefined dan error-nya langsung menyusul, inilah penyebabnya.
2. API-nya mengembalikan sesuatu selain array. Kalau API mengembalikan objek seperti { users: [...] }, error-nya akan berbeda (users.map is not a function), jadi ini bukan error yang kamu tempel. Tapi ini masih bisa menjadi masalah berikutnya setelah penyebab 1 diperbaiki. Cek: console.log(data) di dalam .then yang kedua.
3. Request-nya gagal. Belum terlibat: karena render pertama sudah melempar error, React tidak pernah menjalankan effect-nya, jadi request-nya bahkan tidak terkirim. Cek: tab Network tidak menunjukkan request /api/users, yang sekaligus memastikan penyebab 1.

Balasan itu melakukan sesuatu yang dilewatkan jawaban yang langsung memberi perbaikan: balasan itu mencoret penyebab-penyebab karena error yang akan dihasilkannya berbeda dari yang kamu tempel, atau karena kodenya tidak pernah berjalan cukup jauh sampai penyebab itu terjadi. Itu juga alasan kenapa teks error yang persis itu penting. Meminta model menyebutkan penyebab-penyebabnya sebelum menjawab adalah bentuk ringan dari chain-of-thought prompting: penalarannya datang lebih dulu dan kesimpulannya bertumpu di sana.

Buat reproduksi minimal

Reproduksi minimal adalah program terkecil yang masih menunjukkan bug-nya: data yang ditulis langsung alih-alih pemanggilan database, satu fungsi alih-alih seluruh modul. Membuatnya sering kali sudah menemukan bug-nya sebelum kamu bertanya kepada siapa pun, karena setiap bagian yang kamu hapus akan tetap menyisakan bug-nya (berarti bagian itu tidak terlibat) atau membuatnya hilang (berarti bagian itu terlibat). Kalau tidak menemukannya, reproduksi itu menjadi prompt yang ideal: cukup pendek untuk dibaca model baris demi baris, dan bebas dari kode tidak berkaitan yang bisa membuatnya mengejar masalah yang salah.

Kalau bug-nya bergantung pada data, sertakan beberapa baris yang memicunya. Model bisa bernalar tentang [{"id": 1, "name": null}]; model tidak bisa bernalar tentang "beberapa baris di production".

Ketika perbaikannya tidak lagi berhasil

Kalau perbaikan ketiga dari model gagal dengan cara yang sama, permintaan perbaikan keempat kecil kemungkinannya lebih baik. Ada dua hal yang lebih membantu:

• Berikan bukti baru. Tambahkan baris print atau log yang menunjukkan nilai sebenarnya di titik kegagalan, jalankan, lalu tempel output-nya. Bukti yang bertentangan dengan teori model adalah jalan tercepat menuju teori yang lebih baik.
• Mulai percakapan baru. Thread debugging yang panjang dipenuhi teori-teori yang sudah ditinggalkan dan versi-versi lama kodenya, dan model bisa terus membangun di atasnya. Chat baru dengan kode terbaru, error-nya, buktinya, dan satu baris yang berbunyi "sudah dicoret: X dan Y" sering kali lebih jauh hasilnya dalam satu balasan.

Hati-hati dengan jawaban yang yakin tentang perilaku sebuah library. Model bisa menggambarkan opsi atau fungsi yang tidak ada; lihat halusinasi AI untuk cara mengeceknya. Ketika kodenya tidak rusak tapi kamu tidak mengerti kenapa kode itu berperilaku seperti itu, prompt untuk menjelaskan kode adalah alat yang lebih tepat.