Bagaimana kamu benar-benar tahu aplikasi hasil vibe coding-mu berfungsi?

Kamu sudah membangun benda itu. Kamu sudah mengklik-kliknya. Tombolnya berfungsi, rekamannya tersimpan, dashboard-nya terupdate. Kamu merasa puas.

Tapi kamu tidak menulis kode itu, dan kalau jujur, kamu mungkin juga belum membacanya. Jadi yang sebenarnya kamu tahu adalah: itu berfungsi sekali, untukmu, saat melakukan satu hal yang kamu coba. Selebihnya soal apakah itu “berfungsi” hanyalah kepercayaan.

Happy path adalah satu-satunya jalur yang diuji kebanyakan orang

Begini biasanya bentuk pengujian aplikasi vibe-coded: kamu mengunggah satu file dan itu terproses. Kamu mengirim satu formulir dan rekamannya muncul. Kamu mengklik satu tombol dan workflow-nya berjalan. Itu saja. Itulah pengujiannya.

Ini bukan soal malas. Ini batas alami dari pengujian manual yang dilakukan oleh orang yang tidak menulis logika di baliknya. Kamu hanya bisa terpikir untuk menguji apa yang bisa kamu bayangkan bisa salah, dan jika kamu tidak bisa membaca kodenya, kamu menguji demonya, bukan sistemnya. Happy path adalah satu-satunya jalur yang pasti dioptimalkan oleh AI, karena itulah skenario dalam prompt yang menghasilkan aplikasi ini sejak awal.

Masalahnya, penggunaan nyata tidak bertahan di happy path. Pengguna sungguhan mengklik dua kali. Mereka membuka dua tab. Mereka menekan tombol kembali lalu mengirim ulang. Tidak satu pun dari itu muncul saat kamu, si pembuat, mengklik-klik aplikasimu sendiri satu kali, dengan hati-hati, dalam urutan yang kamu harapkan digunakan.

Konkurensi adalah titik di mana semuanya benar-benar rusak

Contoh paling jelas adalah konkurensi, dan ini benar-benar sulit diuji secara manual bahkan jika kamu tahu betul apa yang harus dicari.

Bayangkan fitur berbasis kredit: seorang pengguna menjalankan sebuah proses, itu memakan kredit, dan pemeriksaan saldo seharusnya menghentikannya begitu kreditnya habis. Sekarang bayangkan pengguna yang sama membuka lima tab dan memulai lima proses dalam detik yang sama, sebelum pemeriksaan penagihan pertama selesai berjalan. Jika logika ‘cek lalu kurangi’ tidak dibangun untuk menangani tumpang tindih itu, kelima proses bisa lolos pemeriksaan saldo sebelum satu pun dari mereka mencatat pengurangan. Hasilnya adalah pengguna yang menjalankan proses yang tidak mampu dia bayar, saldo kredit yang jadi negatif, dan status akun yang sekarang salah dengan cara yang tidak direncanakan siapa pun.

Kamu tidak akan menangkap itu dengan mengklik tombol sekali. Kamu harus terpikir untuk membuka lima tab, mengatur waktu klik agar jatuh dalam pecahan detik yang sama, dan tahu bahwa ‘cek saldo’ dan ‘kurangi saldo’ adalah dua langkah terpisah yang bisa saling mendahului. Itu bukan kelalaian pengujian. Ini adalah kategori bug yang secara struktural tidak bisa ditemukan oleh klik manual satu per satu, karena bug itu hanya ada ketika beberapa hal terjadi sekaligus, dan satu orang yang menguji sendirian tidak bisa dengan mudah menciptakan kondisi itu dengan sengaja, apalagi mengulanginya.

Ini persis jenis kasus tepi yang ditandai penelitian tentang aplikasi hasil AI sebagai mode kegagalan yang tidak diperhitungkan siapa pun: AI membangun jalur untuk skenario sukses spesifik yang diminta, bukan untuk pengeditan bersamaan, klik ganda, atau celah waktu antar langkah. Dan karena kerusakan yang dihasilkan tidak memunculkan error, itu hanya diam saja sampai sebuah laporan atau saldo terlihat salah berminggu-minggu kemudian.

Kenapa hampir tidak ada yang menulis pengujian yang bisa menangkap ini

Solusi jujur untuk kategori bug ini adalah pengujian otomatis: unit test, integration test, sesuatu yang bisa mensimulasikan lima permintaan bersamaan dan memeriksa hasilnya secara mekanis, bukan mengandalkan imajinasi dan kesabaran manusia. Pengujian otomatis tidak lelah, tidak lupa kasus tepi, dan bisa dijalankan lagi setelah setiap perubahan untuk memastikan sesuatu yang kamu perbaiki hari Senin tidak rusak lagi hari Selasa.

Dalam praktiknya, vibe coder hampir tidak pernah memiliki ini. Menulis rangkaian pengujian adalah keterampilan teknis tersendiri, bisa dibilang lebih sulit daripada menulis aplikasinya sendiri, karena membutuhkan penalaran tentang mode kegagalan, bukan hanya soal fitur yang berfungsi. Agen AI bisa menulis pengujian jika kamu memintanya, tapi seseorang tetap harus tahu untuk memintanya, memahami apa yang sebenarnya diperiksa pengujian tersebut, dan menjaganya tetap mutakhir seiring aplikasi berubah di bawahnya. Bagi pembuat non-teknis yang merilis portal klien pada Selasa sore, itu terlalu jauh untuk dijangkau, dan bahkan pembuat teknis yang ngoding cepat lewat vibe coding jarang berhenti untuk menulis cakupan pengujian bagi kode yang toh akan mereka ganti dengan prompt berikutnya.

Jadi kondisi realistis pengujian pada kebanyakan aplikasi vibe-coded adalah: satu kali klik-klik happy path, dilakukan sekali, oleh orang yang paling tidak siap menebak apa yang bisa salah. Itulah kesenjangan kepercayaan. Kamu tidak memverifikasi bahwa aplikasinya berfungsi. Kamu berharap begitu, berdasarkan satu hal yang kamu coba.

Apa arti sebenarnya dari ‘kepastian visual’

Ada alternatif nyata selain berharap, dan itu bukan “belajar menulis rangkaian pengujian”. Itu adalah membangun bagian-bagian berisiko di atas fondasi yang logikanya sejak awal tidak tersembunyi.

Kepastian visual berarti kamu bisa membuka panel pengaturan dan melihat dengan pasti grup pengguna mana yang bisa melihat sebuah rekaman, filter apa yang diterapkan sebuah blok pada sumber data, dan apa saja yang dilakukan sebuah workflow langkah demi langkah, secara berurutan, tanpa membaca satu baris pun kode yang dihasilkan. Kamu tidak menguji perilaku lalu menyimpulkan aturannya. Kamu membaca aturannya secara langsung.

Ini paling penting untuk kategori di mana kesenjangan kepercayaan paling mahal: logika penagihan, izin akses, dan apa pun yang melibatkan pengguna bersamaan. Platform seperti Softr menangani ini dengan menyimpan izin akses, batasan data, dan langkah workflow sebagai konfigurasi visual yang bisa diperiksa, bukan kode hasil AI yang harus kamu audit baris per baris untuk bisa dipercaya. Jika kamu ingin tahu apakah seorang klien bisa melihat rekaman klien lain, kamu membuka aturan batasan data dan membacanya. Kamu tidak perlu mensimulasikan lima login bersamaan dan berharap AI menangani race condition dengan benar, karena infrastruktur platform sendiri yang sudah diuji itulah yang menegakkan aturan tersebut, bukan pemeriksaan khusus yang ditulis AI untuk prompt spesifikmu.

Bukan berarti setiap fitur khusus lenyap ke dalam panel pengaturan. Untuk UI yang benar-benar khusus, blok vibe coding yang terbatas pada satu komponen dan terhubung lewat lapisan izin dan data platform yang sudah ada adalah risiko yang sangat berbeda dibanding logika bisnis hasil AI untuk seluruh aplikasi, karena dampak dari ‘AI salah pada bagian ini’ hanya sebatas satu blok, bukan sistem penagihan.

Percabangan yang sebenarnya kamu hadapi

Jika aplikasimu adalah proyek akhir pekan atau prototipe yang tidak dibayar siapa pun, rilis saja, klik happy path sekali, dan lanjutkan. Taruhannya persis sama dengan taruhan pengujian manual yang kamu jalankan.

Jika itu portal klien, sistem pemesanan, apa pun yang melibatkan kredit, saldo, atau peran, pertanyaan jujurnya bukan “apakah saya sudah menguji ini?” Melainkan “bisakah saya benar-benar memverifikasi bagian-bagian yang akan menyakitkan jika salah, atau saya cuma mempercayai kata AI?” Jika jawabannya kepercayaan, itu adalah percabangan yang sama dengan yang pernah kami bahas soal masalah Hari Kedua, dan kedua cabang itu sah-sah saja tergantung siapa dirimu.

Jika kamu bisa membaca kode, atau bersedia belajar, tutup kesenjangan itu dengan perangkat yang sesungguhnya, bukan builder yang berbeda. Cursor bekerja di dalam basis kode nyata tempat kamu bisa meminta pengujian konkurensi lalu membaca hasilnya, dan Replit memberimu lingkungan cloud di mana menjalankan rangkaian pengujian adalah bagian normal dari alur kerja, bukan renungan belakangan. Kesenjangan pada kedua kasus itu bukan soal kemampuan AI, melainkan apakah kamu tahu harus meminta pengujian itu dan bisa menilai apakah hasilnya bagus.

Jika kamu tidak bisa, dan kamu membangun jenis aplikasi di mana izin akses yang salah atau saldo negatif adalah masalah nyata, pindahkan bagian-bagian berisiko ke fondasi tempat kamu membaca aturannya, bukan menebaknya. Cek peringkat portal klien kami jika itulah aplikasi yang sedang kamu bangun, karena di situlah tebakan yang salah paling mahal harganya.