Cara Debugging Aplikasi yang Dibuat dengan AI: Metode Praktis

Untuk men-debug aplikasi yang dibuat dengan AI, pertama-tama buat bug itu muncul lagi dengan sengaja, lalu kumpulkan bukti — langkah persisnya, pesan error, dan apa yang ditampilkan console serta tab network browser — dan sampaikan ke AI sebagai "saya melakukan X, saya mengharapkan Y, yang terjadi Z". Jika sebuah perbaikan malah memperburuk keadaan, kembalikan ke versi terakhir yang berfungsi alih-alih menumpuk perbaikan di atasnya. Anda tidak perlu membaca kode untuk melakukan semua ini dengan baik.

Panduan ini membahas seluruh siklusnya, termasuk tur singkat alat developer browser untuk non-developer.

Siklus debugging

Setiap perbaikan bug, baik dilakukan manusia maupun AI, mengikuti siklus yang sama:

1. Reproduksi — buat bug terjadi secara andal.
2. Amati — kumpulkan pesan error dan apa yang sedang dilakukan aplikasi.
3. Jelaskan — berikan langkah, hasil yang diharapkan, dan hasil aktual yang presisi kepada AI.
4. Perbaiki — biarkan AI mengubah satu hal.
5. Verifikasi — ulangi langkah persis tadi dan pastikan sudah beres, serta tidak ada yang rusak di sekitarnya.
6. Kembalikan jika perlu — jika keadaan memburuk, batalkan dan coba lagi dengan informasi yang lebih baik.

Sebagian besar waktu yang terbuang pada aplikasi buatan AI berasal dari melewatkan langkah 1, 2, dan 5: mengatakan "rusak", menerima perubahan tanpa mengujinya, lalu meminta perbaikan lagi di atas kode yang sudah rusak.

Langkah 1: Reproduksi bug

Bug yang bisa Anda picu sesuka hati sudah separuh teratasi. Coba temukan rangkaian langkah terpendek yang menyebabkannya.

Tanyakan pada diri sendiri:

• Apakah terjadi setiap kali? Jika hanya kadang-kadang, apa yang berbeda saat terjadi — data tertentu, koneksi lambat, atau sedang logout?
• Apakah terjadi untuk setiap pengguna? Login dengan akun lain. Banyak bug hanya muncul untuk pengguna baru tanpa data, atau untuk pengguna dengan peran yang berbeda.
• Apakah terjadi di setiap perangkat? Coba layar selebar ponsel dan browser lain.
• Apakah mulai setelah perubahan tertentu? Jika dulu berfungsi kemarin, beberapa perubahan terakhir adalah tersangka utama.

Tuliskan langkahnya sebagai daftar bernomor yang singkat. Nanti Anda akan menempelkannya ke prompt.

Langkah 2: Baca pesan error

Pesan error terlihat menakutkan, tetapi Anda hanya perlu beberapa bagian darinya.

Anda tidak perlu memahaminya; Anda perlu menyalinnya persis. "Cannot read properties of undefined (reading 'name')" memberi tahu AI bahwa kode mengharapkan data (kemungkinan booking atau pengguna) yang tidak ada. Parafrasa seperti "ada error undefined" menghilangkan informasi itu.

Beberapa yang umum, diterjemahkan secara kasar:

• Error undefined / null — kode mengharapkan data yang tidak datang. Sering kali karena status loading atau daftar kosong yang tidak ditangani kode.
• 404 Not Found — halaman atau alamat API tidak ada. Sering kali salah ketik pada rute atau tautan ke halaman yang sudah diganti namanya.
• 401 Unauthorized / 403 Forbidden — permintaan tidak login, atau pengguna tidak diizinkan melakukan itu.
• 500 Internal Server Error — kode di sisi server crash. Alasan sebenarnya ada di log server, bukan di browser.
• Error CORS — browser memblokir permintaan ke domain lain. Biasanya masalah konfigurasi di sisi server.

Langkah 3: Gunakan alat developer browser

Setiap browser desktop memiliki alat developer bawaan ("devtools"). Alat ini menunjukkan apa yang dilakukan halaman di balik layar. Di Chrome, Edge, dan Firefox, klik kanan di mana saja pada halaman lalu pilih Inspect, atau tekan F12 (Cmd+Option+I di Mac). Di Safari, aktifkan menu Develop di pengaturan Safari terlebih dahulu.

Anda hanya membutuhkan tiga tab.

Console

Tab Console menampilkan error dan pesan dari kode halaman. Error ditampilkan dengan warna merah. Jika sebuah tombol tidak melakukan apa-apa saat diklik, console sering kali menampilkan error merah tepat pada saat Anda mengklik. Salin teks lengkap error tersebut (klik kanan untuk opsi salin di sebagian besar browser).

Network

Tab Network menampilkan setiap permintaan yang dibuat halaman — memuat data, menyimpan formulir, login. Buka, lalu ulangi langkah yang menyebabkan bug.

• Cari baris berwarna merah atau dengan status 400 ke atas.
• Klik baris yang gagal untuk melihat Response-nya. Error server sering menyertakan pesan di sana yang lebih berguna daripada apa pun di layar.
• Catat URL dan kode status permintaan — "POST ke /api/bookings mengembalikan 500" adalah kalimat yang sangat berguna untuk diberikan ke AI.

Centang Preserve log jika bug melibatkan reload halaman atau pengalihan, agar permintaan tidak hilang.

Elements

Tab Elements (atau Inspector) menampilkan struktur dan gaya halaman. Paling berguna untuk bug tata letak: arahkan kursor ke elemen untuk melihat ukuran dan spasinya disorot. Anda tidak perlu mengedit apa pun di sini; cukup katakan "footer selebar 2.000 piksel di ponsel dan mendorong halaman ke samping".

Langkah 4: Periksa log server

Beberapa bug terjadi di server, tempat browser tidak bisa melihatnya. Error 500 di tab network adalah tanda klasiknya. Log server — keluaran teks dari backend saat berjalan — biasanya berisi error sebenarnya beserta stack trace (daftar fungsi yang sedang berjalan ketika gagal).

Di mana Anda menemukannya bergantung pada alat Anda. Di sebagian besar pembuat aplikasi AI, Anda bisa membuka terminal atau tampilan log untuk proyek, atau cukup minta AI: "Periksa log server untuk error dari permintaan terakhir dan beri tahu saya apa yang gagal."

Langkah 5: Jelaskan bug kepada AI

Susun informasi yang sudah Anda kumpulkan dalam bentuk seperti ini:

Di halaman Bookings, login sebagai member: saya mengklik Cancel untuk kelas jam 9:00 besok. Diharapkan: booking hilang dan kelas menampilkan satu tempat kosong lagi. Aktual: tidak ada yang berubah di layar. Console menampilkan TypeError: Cannot read properties of undefined (reading 'id') di BookingCard.tsx:31, dan tab network menampilkan DELETE /api/bookings/123 mengembalikan 500. Temukan penyebabnya, perbaiki, dan periksa bahwa pembatalan berfungsi untuk member dengan satu booking dan dengan beberapa booking.

Mengapa setiap bagian penting:

• Di mana dan sebagai siapa mempersempit masalah ke satu layar dan satu peran.
• Langkah persis memungkinkan AI mereproduksinya.
• Yang diharapkan vs yang aktual mendefinisikan apa arti "sudah diperbaiki".
• Teks error dan permintaan yang gagal langsung menunjuk ke penyebabnya.
• "Periksa bahwa…" meminta AI untuk memverifikasi, bukan hanya mengedit.

Jika AI sudah dua kali mencoba memperbaiki dan gagal, minta ia menjelaskan sebelum mengubah apa pun:

Jangan ubah kode dulu. Menurut Anda apa penyebabnya, dan bukti apa yang mendukungnya?

Teori yang salah mudah dikenali saat dituliskan, dan jauh lebih murah untuk dikoreksi daripada perbaikan yang salah.

Langkah 6: Verifikasi, lalu periksa sekitarnya

Ketika AI mengatakan sudah diperbaiki, ulangi langkah persis dari Langkah 1. Lalu periksa hal-hal di sekitarnya:

• Aksi yang sama untuk peran pengguna yang berbeda
• Aksi yang sama dengan tanpa data, dan dengan banyak data
• Halaman yang berbagi komponen dengan yang Anda perbaiki
• Layar selebar ponsel, jika perbaikan menyentuh tata letak

Perubahan AI kadang memperbaiki satu jalur sambil diam-diam merusak jalur lain. Pemeriksaan dua menit sekarang menghemat satu jam kebingungan nanti.

Langkah 7: Kembalikan alih-alih menumpuk

Jika sebuah perbaikan memperburuk keadaan, atau Anda sudah tiga putaran tanpa kemajuan, kembalilah. Mengembalikan ke versi terakhir yang berfungsi dan merumuskan ulang dengan bukti yang lebih baik hampir selalu lebih baik daripada meminta perbaikan keempat di atas tiga perbaikan yang salah. Setiap percobaan yang gagal meninggalkan kode yang membingungkan percobaan berikutnya.

Kebiasaan baik yang memudahkan pengembalian:

• Uji setelah setiap perubahan, agar Anda tahu perubahan mana yang merusak.
• Jaga perubahan tetap kecil — satu fitur atau perbaikan per pesan.
• Catat versi terakhir yang berfungsi sebelum memulai sesuatu yang berisiko.
• Jika kode ada di Git, commit versi yang berfungsi agar bisa kembali ke sana.

Pola bug umum pada aplikasi buatan AI

Saat masalahnya bukan bug

Beberapa "bug" sebenarnya adalah AI yang membangun persis apa yang diperintahkan, dan deskripsinya ambigu. Jika perbaikan yang Anda minta sebenarnya adalah perubahan perilaku, katakan dengan jelas: "Ubah agar…". Jika Anda sendiri tidak yakin apa perilaku yang benar, tentukan itu dulu. Panduan kami tentang menulis prompt untuk pembuat aplikasi AI membahas cara menentukan aturan dengan jelas. Dan jika Anda sedang menyiapkan aplikasi untuk pengguna sungguhan, membawa prototipe AI ke produksi membahas pemeriksaan yang layak dilakukan sebelum peluncuran.

Debugging di Mythex

Mythex memiliki alat untuk setiap langkah siklus:

• Preview untuk mereproduksi bug, termasuk bingkai ukuran ponsel.
• /test meminta agen mengklik pratinjau live Anda seperti pengguna dan melaporkan alur yang rusak.
• /fix mengarahkan agen khusus ke kerusakan.
• Mode Plan memungkinkan agen menyelidiki dan menjelaskan sebelum mengedit apa pun.
• Code → terminal menampilkan log server aplikasi Anda.
• Revert to this point pada balasan mana pun mengembalikan proyek ke checkpoint tersebut.

Jika publikasi gagal, dialog publikasi biasanya menawarkan Fix with AI, yang membaca output build atau log aplikasi. Lihat Debug your app dan Publish troubleshooting di dokumentasi.

Pertanyaan