Bug 'Kelihatan Beres': Cara Mengenali Kegagalan Senyap di Aplikasi Buatan AI-mu

AI app builder-mu menghasilkan sebuah formulir kontak. Kamu mengetik namamu, menekan submit, melihat pesan sukses yang ramah, lalu beralih ke hal lain. Seminggu kemudian kamu menyebut-nyebut halaman itu ke seorang teman, yang bertanya apakah sudah ada yang mengisinya. Kamu pergi mengecek. Tiga kiriman tertahan di semacam status pending. Tak satu pun pernah sampai ke inbox-mu.

Inilah mode kegagalan yang paling umum pada aplikasi buatan AI, dan ini bukan yang dikhawatirkan kebanyakan orang. Bug yang melemparkan pesan error merah mudah ditemukan — AI builder-mu akan memperbaikinya dalam dua menit. Bug yang berbahaya adalah yang membuat layarnya kelihatan beres, pengguna mengira mereka sudah selesai, dan kamu baru tahu sebulan kemudian.

Tulisan ini adalah checklist untuk menangkap yang seperti itu. Bukan “cara menguji seperti QA engineer” — sekadar lima tempat di mana pengguna sungguhan terjebak oleh aplikasi buatan AI yang tampaknya berfungsi.

1. Kirim sesuatu dan pastikan ia benar-benar sampai ke suatu tempat

Saat AI builder-mu membuat formulir, ajukan satu pertanyaan: ke mana data ini pergi? Bukan secara abstrak — secara harfiah, ke mana kamu bisa pergi untuk melihatnya setelah kamu menekan submit?

Sejumlah formulir yang ternyata cukup banyak ini mengirim ke handler yang mengembalikan “Terima kasih!” tanpa pernah mengirim email, menyimpan ke database, atau memberi tahu siapa pun. Formulir itu hanya kedok yang sopan. Jadi:

Kirim entri uji coba dengan nama palsu tapi mencolok seperti “ZZZ TEST”.
Buka dashboard, database, inbox, spreadsheet — di mana pun kiriman seharusnya mendarat.
Temukan entri “ZZZ TEST”-mu di situ, dengan timestamp yang benar.

Kalau kamu tidak bisa menemukannya dalam waktu kurang dari satu menit, formulirmu rusak, sekalipun ia mengucapkan selamat atas kirimanmu. Aku pernah melihat formulir “contact us” di sebuah landing page berbayar yang mengumpulkan nol lead selama tiga minggu karena langkah email-nya tidak pernah disambungkan. Halamannya terlihat sempurna.

2. Coba jalur yang tak pernah kamu tempuh

Kamu tahu apa yang dilakukan aplikasimu karena kamu menyaksikannya dibangun. Kamu mengklik tombol dengan urutan yang sama setiap kali. Pengguna sungguhan tidak begitu.

Pilih jalur yang terasa paling aneh:

Klik submit dua kali berturut-turut, dengan cepat.
Refresh halaman di tengah-tengah melakukan sesuatu.
Buka di jendela private tanpa login.
Ketik nama dengan apostrof (O’Brien adalah perusak klasiknya).
Ketik angka ke kolom yang meminta angka, tapi buat angkanya negatif atau nol.

Kalau sesuatu rusak secara kasatmata, itu bug sungguhan — tapi setidaknya ia bersuara lantang. Versi “kelihatan beres”-nya adalah ketika klik kedua membuat catatan duplikat dan tidak ada cara untuk mengetahuinya dari layar. Pergilah cek database dan cari dua baris “ZZZ TEST” dengan timestamp berselang dua detik. Kalau kamu menemukannya, formulirnya butuh penjaga duplikat.

3. Tunggu sehari, lalu kembali

Banyak kode yang dihasilkan AI memakai memori sementara yang ter-reset saat aplikasinya redeploy atau reboot. Aplikasi itu menyimpan datamu di dalam sesuatu yang oleh developer disebut “in-memory state” — oke untuk demo, mengerikan untuk hal apa pun yang sungguhan.

Tesnya kejam dan mudah: masukkan beberapa data, tutup tab-nya, tunggu dua puluh empat jam, lalu kembali. Kalau datamu hilang atau berantakan, penyimpanannya tidak nyata. AI builder-mu mungkin perlu diberitahu, dalam bahasa sederhana: “data ini harus bertahan dari restart server.” Sebagian besar builder akan beralih ke database saat diminta; sebagian tidak akan mau kecuali kamu minta.

Kamu bisa menjalankan versi tes ini yang lebih cepat dengan bertanya ke builder-mu, di dalam chat, “di mana data untuk formulir ini disimpan, dan apakah ia akan bertahan dari redeploy?” Kalau jawabannya menyebut “in memory”, “session”, atau “untuk run ini”, kamu sudah menemukan bug-nya sebelum ada pengguna yang terkena.

4. Tunjukkan ke satu orang yang bukan kamu

Kamu tahu apa makna aplikasimu. Kamu yang mendesainnya. Kamu yang menamai tombol-tombolnya. Labelnya jelas bagimu karena kamu yang menulisnya.

Tunjukkan ke seorang teman tanpa menjelaskan apa pun. Bilang, “Coba lakukan X.” Amati mereka. Jangan bantu. Tiga hal akan terjadi:

Mereka akan mengklik suatu tempat yang tak kamu duga, dan aplikasinya melakukan sesuatu yang mengejutkan.
Mereka akan mentok pada label yang tampak jelas saat kamu menulisnya.
Mereka akan melakukan hal yang kamu inginkan, tapi dalam separuh langkah yang kamu bayangkan, dan melewati satu layar sepenuhnya — kadang layar yang justru diandalkan aplikasi untuk mereka isi.

Masing-masing dari itu adalah bug sungguhan. Tak satu pun melemparkan error. Temanmu akan bilang, “Oh, lucu,” lalu mengembalikan laptopnya. Kamu akan tahu, dari menyaksikan wajah mereka, bahwa mereka tersesat selama tiga puluh detik di sebuah tempat yang tak kamu kira punya celah.

5. Baca email yang dikirimnya, di ponsel

Kalau aplikasimu mengirim email — konfirmasi, reset password, invoice — buka satu di ponselmu, dan satu lagi di klien email yang berbeda dari yang biasa kamu pakai. Aplikasi buatan AI cenderung menghasilkan email yang terlihat cantik di Gmail desktop tapi terlihat acak-acakan di Outlook di Android.

Logika yang sama berlaku untuk struk PDF, hasil export yang bisa diunduh, dan tombol “bagikan tautan ini”. Hal yang keluar dari aplikasimu, ke dunia nyata, adalah bagian yang paling kurang diuji dari sebuah build AI. Ia juga bagian yang paling banyak dilihat penggunamu. Seorang founder yang aku kenal merilis alur checkout yang indah yang struk PDF-nya, di iPhone, hanyalah satu kotak hitam. Tak ada yang mengeluh — mereka cuma berhenti membeli.

Kebenaran tak nyaman soal “ini berfungsi”

Saat kamu membangun dengan AI app builder, “ini berfungsi” berarti “ia berjalan di mesinku, di browser-ku, dengan klik-klikku yang persis, pada hari aku membangunnya.” Itu klaim yang jauh lebih kecil dari yang kedengarannya.

Aplikasi sungguhan berfungsi ketika:

Orang lain memakainya.
Datanya bertahan lebih lama dari sekadar demo.
Jalur menembus aplikasi adalah jalur yang tak kamu antisipasi.
Output-nya dibaca di perangkat yang tak kamu uji.

Kamu tidak perlu menjadi penguji software untuk merilis sesuatu yang baik. Kamu cukup melakukan lima pemeriksaan ini satu kali, sehari sebelum kamu memberi tahu siapa pun bahwa aplikasinya ada. Itu memakan waktu sekitar dua puluh menit. Itu akan menangkap sembilan dari sepuluh bug senyap yang jika tidak akan sampai ke pengguna berbayar.

Kalau kamu cuma punya waktu untuk satu, lakukan yang pertama. Kirim sesuatu. Temukan ia di seberang sana. Sebagian besar aplikasi buatan AI kelihatan beres. Triknya adalah memastikan ia memang benar beres.

Kalau ini terasa mengena, hal berikutnya yang layak dilakukan adalah duduk dengan selembar kertas dan menuliskan tiga hal yang aplikasimu tidak boleh pernah gagal secara diam-diam — formulirnya, email-nya, pembayarannya, apa pun yang jadi milikmu — lalu menjalani masing-masing dengan pemeriksaan di atas. Dua puluh menit sekarang membelikanmu banyak malam tidur nyenyak di kemudian hari.