Apa yang harus dilakukan ketika aplikasi buatan AI-mu rusak jam 2 pagi (dan kamu bukan developer)

Kamu membangun aplikasi tanpa menulis kode apa pun. Ia berfungsi sepanjang minggu. Lalu seorang pengguna mengirimimu pesan jam 1:47 pagi bilang tombol signup tidak melakukan apa-apa, dan kamu terbangun mendapati ponselmu menyala di nakas.

Kalau kamu belum pernah harus memperbaiki aplikasi live sebelumnya, momen ini bisa terasa mengerikan. Kamu tidak membaca kode. Kamu tidak tahu apa arti “database” sebenarnya. Kamu tidak yakin apakah ia rusak-parah atau cuma-aneh, dan orang-orang yang biasanya membantu sedang tidur.

Inilah panduan yang tenang dan teratur tentang apa yang harus dilakukan ketika aplikasi buatan AI rusak dan kamu tidak bisa menulis kode. Sebagian besarnya adalah soal tidak memperburuk keadaan, yang merupakan bagian yang tak ada yang memperingatkanmu.

Pertama: jangan men-deploy ulang

Ada sebuah tombol di suatu tempat di AI app builder-mu yang bertuliskan semacam “republish”, “redeploy”, atau “ship”. Kamu akan tergoda menekannya. Jangan, belum.

Menekan deploy ulang pada aplikasi yang setengah rusak bisa mengunci keadaan yang rusak, melenyapkan informasi debug data apa pun yang sedang tergeletak di sekitar, dan membuatnya lebih sulit bagi siapa pun — termasuk AI builder itu sendiri — untuk mencari tahu apa yang salah.

Langkah pertama selalu untuk melihat, bukan bertindak. Kamu bahkan belum mengonfirmasi apa yang rusak.

Langkah 1 — Reproduksi masalahnya sendiri

Buka aplikasi di jendela browser yang baru — mode incognito atau private paling baik, karena ia menghilangkan login lama atau cache apa pun yang mungkin membuat hal-hal berperilaku berbeda untukmu dibanding untuk penggunamu.

Coba lakukan hal persis yang dilaporkan pengguna. Kalau mereka bilang tombol signup tidak berfungsi, coba daftar. Kalau mereka bilang dashboard-nya kosong, coba login dan lihat dashboard-nya.

Kamu mencari salah satu dari tiga hal:

Ia rusak untuk semua orang. Kamu mengalami masalah yang sama. Ini sebenarnya jenis yang paling mudah diperbaiki karena ia konsisten.
Ia berfungsi untukmu. Ini skenario tersulit, karena sesuatu tentang situasi spesifik pengguna (browser mereka, akun mereka, data mereka) adalah masalahnya.
Ia tidak menentu. Ia berfungsi sekali dan rusak di kali berikutnya. Ini yang paling menegangkan tapi juga paling informatif — biasanya berarti sesuatu sedang timeout atau kehabisan sumber daya.

Tuliskan yang mana dari ketiganya yang kamu lihat. Kamu akan membutuhkannya saat meminta bantuan.

Langkah 2 — Periksa hal-hal eksternal yang jelas sebelum menyalahkan aplikasimu

Jumlah momen “aplikasiku rusak” yang ternyata bukan aplikasimu mengejutkan banyaknya. Sebelum kamu menyelam ke dalam AI builder-mu, periksa:

Apakah internet-nya sendiri baik-baik saja? Buka beberapa situs lain. Kalau wifi-mu bermasalah, aplikasimu mungkin baik-baik saja dan kamu yang mungkin rusak.
Apakah AI builder-nya sendiri mengalami gangguan? Sebagian besar AI app builder punya halaman status (cari nama produknya plus “status”). Kalau mereka sedang mengalami malam yang buruk, kamu tidak perlu memikirkan apa pun yang lain.
Apakah salah satu tools yang terhubung tumbang? Kalau aplikasimu memakai Stripe untuk pembayaran, layanan email untuk notifikasi, atau layanan database untuk menyimpan data, semua itu bisa mengalami gangguan. Masing-masing punya halaman status sendiri. Periksa yang diandalkan aplikasimu.

Kira-kira satu dari lima kali, jawabannya adalah “ini sebenarnya bukan aplikasiku”, dan kamu bisa kembali tidur.

Langkah 3 — Lihat pesan error-nya, sekalipun ia menakutkanmu

Kalau aplikasimu menampilkan layar dengan teks di atasnya — bahkan teks yang tampak seperti ocehan — bacalah. Ambil tangkapan layar. Terutama kalau ada string panjang berisi huruf dan angka (orang menyebutnya “stack trace”; tampak seperti sup alfabet tapi ia adalah hal paling berguna yang bisa kamu miliki saat meminta bantuan).

Sebagian besar AI app builder juga punya tempat untuk melihat error yang baru-baru ini terjadi. Mungkin disebut Logs, Activity, Errors, atau Console. Buka. Kamu tidak perlu memahami sebagian besar yang kamu lihat — kamu mencari teks merah terbaru atau error terbaru, dan waktu kejadiannya. Waktu itu penting: error dari kemarin pagi mungkin bukan alasan penggunamu tidak bisa daftar barusan.

Salin error itu. Kamu akan menempelkannya ke suatu tempat yang membantu sebentar lagi.

Langkah 4 — Tanyakan ke AI builder apa yang berubah

Inilah langkah yang paling kurang dimanfaatkan builder non-teknis. Buka chat dengan AI builder-mu dan katakan, dalam bahasa sederhana:

“Aplikasiku rusak. Pengguna tidak bisa daftar — tombolnya tidak melakukan apa-apa. Ini error dari log-nya: [tempel di sini]. Apa yang berubah dalam 24 jam terakhir, dan apa yang bisa menyebabkan ini?”

AI builder yang baik akan memberi tahu perubahan terkini mana yang paling mungkin bertanggung jawab. Kadang kamu akan langsung mengenalinya (“oh, aku memintanya membuat formulirnya lebih cantik kemarin dan itu mungkin merusak logika submit-nya”). Kadang ia akan menunjuk sesuatu yang tak kamu ingat menyentuhnya, yang juga berguna — artinya sesuatu yang otomatis berubah, seperti tools terhubung yang melakukan pembaruan.

Jangan biarkan AI builder mulai membuat perbaikan dulu. Kamu masih dalam mode diagnosis. Cara paling umum yang saya lihat orang memperparah masalah kecil adalah dengan membiarkan AI mulai “memperbaiki” hal-hal sebelum ada yang memahami apa yang rusak.

Langkah 5 — Putuskan apakah akan roll back

Hampir setiap AI app builder membiarkanmu kembali ke versi aplikasimu yang lebih awal. Kadang disebut “history”, “versions”, “checkpoints”, atau “rollback”.

Kalau kamu bisa dengan jelas mengingat satu jam atau satu hari ketika aplikasi berfungsi, kembali ke versi itu adalah langkah paling andal. Ia memakan biaya berupa perubahan apa pun yang kamu buat di antaranya (yang mungkin bahkan tak kamu inginkan lagi), dan ia memberimu aplikasi yang berfungsi untuk kamu hadapi saat bangun.

Sebuah aturan baik: kalau hal yang rusak adalah sesuatu yang dilakukan pengguna setiap hari (signup, login, pembayaran), roll back dulu dan perbaiki belakangan. Berfungsi-tapi-usang mengalahkan rusak-tapi-terkini setiap saat.

Kalau hal yang rusak adalah fitur yang kamu tambahkan hari ini yang belum diandalkan siapa pun, kamu bisa membiarkannya rusak sampai pagi dan memperbaikinya dengan kepala jernih.

Langkah 6 — Kalau kamu memang harus membiarkan AI builder memperbaikinya

Kalau roll back tidak mungkin, atau kamu memutuskan untuk tidak melakukannya, maka biarkan AI builder mengusulkan perbaikan. Dua hal yang perlu diingat selagi ia melakukannya:

Baca apa yang ia rencanakan untuk diubah sebelum menyetujui. Kamu tidak akan memahami semuanya, tapi kamu bisa mengenali apakah ia mengedit satu hal yang fokus atau menulis ulang separuh aplikasi. Perubahan kecil dan fokus jauh lebih aman daripada yang menyeluruh saat jam 2 pagi.

Uji perbaikannya dengan cara yang sepaling membosankan mungkin. Jangan cuma bertanya “sudah diperbaiki?” lalu memercayai jawabannya. Benar-benar pergi ke aplikasi sendiri di jendela incognito dan lakukan hal yang tadinya rusak. Kalau perbaikannya berhasil, hal yang rusak itu sekarang berfungsi. Kalau tidak, jangan menerima perubahannya hanya karena AI builder bilang ia berhasil.

Langkah 7 — Balas penggunanya, bahkan kalau kamu belum memperbaikinya

Pengguna yang mengirimimu pesan jam 1:47 pagi tidak mengharapkan kamu online. Tapi kalau kamu online, sebuah balasan singkat lebih berarti daripada sebuah perbaikan:

“Terima kasih sudah memberi tahu — aku sedang melihatnya sekarang. Aku akan kirim kabar begitu ia berfungsi lagi.”

Kalau mereka pengguna yang membayar, satu pesan itu adalah pembeda antara mereka memberi tahu orang bahwa kamu cepat merespons dan memberi tahu orang bahwa kamu menghilang. Perbaikannya bisa menunggu sampai pagi. Balasannya tidak bisa.

Pelajaran yang lebih besar: bangun aplikasimu seakan ia mungkin rusak

Kalau kamu merasa ini menegangkan, hikmahnya adalah pengalaman ini akan membentuk ulang cara kamu membangun. Setelah insiden jam 2 pagi pertamamu, kamu akan mulai melakukan hal-hal secara berbeda:

Kamu akan menambahkan pemeriksaan status. Sebuah halaman sederhana yang memberi tahu apakah bagian-bagian penting aplikasimu berfungsi, supaya kamu tidak harus login untuk mengetahuinya.
Kamu akan menyimpan backup data pengguna. Sebagian besar AI builder akan mengekspor datamu jika diminta. Melakukan ini sekali seminggu memakan 30 detik dan menyelamatkanmu di kasus terburuk.
Kamu akan menuliskan apa yang diandalkan aplikasimu. Sebuah daftar singkat setiap tools yang terhubung (pembayaran, email, database, penyimpanan), supaya ketika sesuatu rusak jam 2 pagi, kamu punya checklist alih-alih tebakan.
Kamu akan mengubah satu hal pada satu waktu. Saat kamu membuat 10 perubahan sekaligus dan aplikasi rusak, kamu tidak tahu perubahan mana yang merusaknya. Saat kamu membuat satu perubahan pada satu waktu, kamu tahu.

Kamu bisa membangun aplikasi tanpa coding. Kamu juga bisa menjaga satu aplikasi tetap berjalan tanpa menjadi developer — tapi keterampilan yang terlibat berbeda dari keterampilan membangun. Kamu mempelajarinya sebagian besar dengan cara yang sulit, biasanya pada jam yang tidak nyaman.

Kabar baiknya: setiap kali ia terjadi, ia jadi kurang menakutkan. Saat ketiga kalinya, ia menjengkelkan alih-alih menakutkan. Saat kesepuluh, ia cuma seperti hari Selasa biasa.