Cara Membawa Prototipe AI ke Produksi

Untuk membawa prototipe AI ke produksi, Anda menutup celah antara "berfungsi ketika saya mencobanya" dan "tetap berfungsi ketika orang lain memakainya". Dalam praktiknya, ada lima hal: uji alur utama setiap kali Anda mengubah sesuatu, kunci siapa yang bisa melihat dan mengubah apa, pastikan Anda mengetahui error sebelum pengguna memberi tahu Anda, cadangkan data dan buktikan Anda bisa memulihkannya, dan jaga aplikasi tetap cukup cepat di ponsel. Tidak ada yang memerlukan penulisan ulang — ini adalah daftar periksa yang Anda kerjakan bersama AI yang sama yang membuat prototipenya.

Prototipe vs produksi: apa yang benar-benar berubah

Prototipe hanya punya satu pengguna yang hati-hati: Anda. Anda tahu tombol mana yang harus ditekan, Anda mengetik input yang masuk akal, dan jika ada yang rusak, Anda mengangkat bahu lalu meminta AI memperbaikinya. Produksi punya banyak pengguna yang ceroboh, beberapa yang penasaran, dan sesekali yang berniat jahat. Kodenya tidak perlu menjadi "kelas enterprise"; ia perlu menangani situasi yang tidak pernah dihadapi prototipe.

Sisa panduan ini membahas setiap baris tersebut.

Langkah 1: Bekukan lingkup dan catat alur utama

Sebelum mengeraskan apa pun, tentukan apa itu versi pertama. Buat daftar tiga sampai enam alur yang paling penting — misalnya "daftar, buat proyek, undang rekan tim, bayar". Ini menjadi skrip pengujian Anda, target pemantauan, dan hal-hal yang Anda periksa setelah setiap perubahan.

Fitur yang tidak ada di daftar harus dipangkas atau diberi label jelas sebagai beta. Jauh lebih mudah membuat empat alur andal daripada empat belas.

Langkah 2: Uji seperti orang asing, lalu buat bisa diulang

Pembuat aplikasi AI pandai menghasilkan kode yang berfungsi di jalur ideal. Masalah produksi ada di jalur yang tidak ideal. Uji setiap alur utama dengan:

• Input buruk: kolom wajib yang kosong, nama 5.000 karakter, email tanpa @, jumlah negatif, tanggal yang sudah lewat.
• Refresh dan tombol kembali: muat ulang di tengah checkout; tekan kembali setelah mengirim formulir. Apakah ada sesuatu yang terbuat dua kali?
• Dua tab, dua pengguna: masuk dengan dua akun berbeda dan coba buka halaman satu sama lain dengan mengubah ID di URL.
• Lambat dan kecil: layar seukuran ponsel dan koneksi yang dibatasi (alat pengembang browser bisa mensimulasikannya).
• Keadaan kosong: akun baru tanpa data. Prototipe sering dibangun dengan data contoh dan terlihat rusak tanpa itu.

Lalu buat pemeriksaan itu bisa diulang. Minimal, simpan daftar periksa tertulis dan jalankan sebelum setiap rilis. Lebih baik lagi, mintalah AI menulis pengujian otomatis untuk alur yang paling penting:

Tambahkan pengujian end-to-end otomatis untuk alur ini: daftar dengan email, buat proyek, undang pengguna kedua, dan selesaikan checkout di mode uji Stripe. Tambahkan juga pengujian yang memastikan pengguna tidak bisa melihat atau mengedit proyek pengguna lain dengan mengubah URL.

Pengujian yang membuktikan seorang pengguna tidak bisa melakukan sesuatu adalah jenis yang paling sering tidak ada di prototipe.

Langkah 3: Dasar-dasar keamanan yang sering dilewatkan prototipe

Sebagian besar masalah keamanan di aplikasi yang dibuat dengan AI bukanlah hal yang eksotis. Yang hilang adalah pemeriksaan. Telusuri daftar ini, dan lihat daftar periksa keamanan lengkap untuk aplikasi yang dibuat dengan AI:

• Otorisasi di server. Menyembunyikan tombol bukanlah keamanan. Setiap permintaan yang membaca atau mengubah data harus memeriksa, di server, bahwa pengguna yang login diizinkan melakukannya. Jika aplikasi Anda memakai basis data dengan aturan tingkat baris, pastikan aturan itu aktif dan sudah diuji.
• Rahasia tidak boleh ada di browser. Kunci API untuk pembayaran, email, atau penyedia AI harus berada di variabel lingkungan sisi server, tidak pernah di kode front-end. Jika Anda tidak yakin maksudnya, baca apa itu variabel lingkungan dan rahasia.
• Validasi di server. Browser bisa dilewati, jadi ulangi setiap pemeriksaan penting di server.
• Login yang benar. Gunakan pustaka atau layanan autentikasi yang sudah teruji, bukan penyimpanan kata sandi buatan sendiri. Panduan kami tentang menambahkan login ke aplikasi Anda membahas pilihannya.
• Batas laju (rate limit) untuk login, pendaftaran, reset kata sandi, dan apa pun yang mengirim email atau memanggil API berbayar.
• Pesan error yang ramah. Pengguna cukup melihat "terjadi kesalahan"; detailnya masuk ke log Anda, bukan ke layar.
• Ganti apa pun yang bocor. Jika kunci live pernah ditempel di chat, commit, atau tangkapan layar, ganti di penyedianya.

Prompt yang mencakup banyak hal sekaligus:

Tinjau aplikasi ini untuk keamanan produksi. Periksa bahwa setiap rute API memverifikasi pengguna yang login memiliki data yang dibaca atau diubah, bahwa tidak ada kunci rahasia yang dikirim ke browser, bahwa input divalidasi di server, dan bahwa login serta reset kata sandi dibatasi laju. Buat daftar temuan sebelum mengubah apa pun.

Meminta daftar terlebih dahulu membuat Anda bisa melihat masalahnya dan memutuskan urutannya, alih-alih menerima satu perubahan besar sekaligus.

Langkah 4: Ketahui saat rusak — logging dan pemantauan

Di pratinjau, Anda melihat error saat terjadi. Di produksi, Anda membutuhkan aplikasi yang memberi tahu Anda. Ada tiga lapisan, dari yang paling murah hingga yang paling berguna:

1. Log server. Pastikan error dicatat dengan konteks yang cukup untuk mereproduksinya: rute mana, ID pengguna mana (bukan kata sandi atau kartu mereka), dan bentuk input seperti apa. Mintalah AI menambahkan logging terstruktur jika aplikasi hanya mencetak ke konsol.
2. Pelacakan error. Layanan seperti Sentry atau alat serupa menangkap exception di front-end dan back-end, mengelompokkannya, dan mengirimkan email kepada Anda. Untuk aplikasi kecil, paket gratis layanan-layanan ini sering sudah cukup; periksa batas terkini di situs mereka.
3. Pemeriksaan uptime. Layanan eksternal yang memuat halaman utama dan satu rute API penting setiap beberapa menit dan memberi peringatan jika gagal. Ini menangkap masalah yang membuat aplikasi tidak bisa mencatat log sama sekali.

Tambahkan satu kebiasaan lagi: setelah setiap rilis, buka aplikasi live dan jalankan daftar periksa alur utama Anda di URL asli, bukan hanya di pratinjau.

Langkah 5: Cadangan dan jalan untuk kembali

Dua hal berbeda perlu dilindungi, dan keduanya mudah tertukar.

• Kode. Simpan proyek di version control agar setiap perubahan bisa dibatalkan. Banyak pembuat aplikasi AI menyimpan checkpoint dari file Anda; menyinkronkan ke repositori Git memberi Anda salinan di luar pembuat aplikasi juga.
• Data. Mengembalikan kode tidak mengembalikan basis data. Migrasi yang buruk atau tombol hapus yang bermasalah bisa menghancurkan baris yang tidak akan dikembalikan oleh checkpoint kode mana pun.

Untuk data, siapkan cadangan rutin yang disimpan di luar hosting aplikasi itu sendiri — untuk basis data Postgres, pg_dump terjadwal ke penyimpanan terpisah adalah pendekatan yang umum, dan banyak penyedia basis data terkelola menawarkan cadangan otomatis atau point-in-time recovery. Lalu lakukan langkah yang sering dilewatkan orang: pulihkan cadangan ke basis data percobaan dan periksa bahwa datanya ada.

Mintalah juga AI untuk membuat tindakan destruktif lebih aman: langkah konfirmasi untuk penghapusan, dan "soft delete" (menandai baris sebagai terhapus alih-alih benar-benar menghapusnya) untuk apa pun yang mungkin ingin dikembalikan pengguna.

Langkah 6: Performa yang tetap baik di ponsel

Prototipe terasa cepat karena Anda satu-satunya pengguna dan data yang digunakan sangat kecil. Sebelum meluncurkan:

• Muat data dengan ukuran nyata. Mintalah AI mengisi beberapa ribu baris dan lihat halaman mana yang melambat. Daftar biasanya membutuhkan paginasi, dan basis data biasanya membutuhkan indeks pada kolom yang Anda filter dan urutkan.
• Perkecil gambar. Gambar berukuran besar adalah penyebab paling umum halaman lambat dimuat. Mintalah gambar yang diubah ukurannya dan dikompres, serta lazy loading untuk bagian di bawah lipatan.
• Ukur. Jalankan Lighthouse di alat pengembang Chrome pada URL live dalam mode mobile. Core Web Vitals dari Google adalah target yang masuk akal: Largest Contentful Paint dalam 2,5 detik, Interaction to Next Paint 200 ms atau kurang, dan Cumulative Layout Shift 0,1 atau kurang.
• Perhatikan penundaan "bangun". Hosting yang tidur saat tidak aktif menghemat biaya, tetapi membuat kunjungan pertama setelah masa sepi terasa lebih lambat. Itu sering kali pertukaran yang wajar untuk aplikasi baru; ketahui bahwa itu terjadi.

Halaman proyek lambat dengan 5.000 baris. Tambahkan paginasi sisi server (25 per halaman), tambahkan indeks basis data untuk kolom yang kami filter dan urutkan, dan tampilkan status loading saat halaman berikutnya dimuat.

Langkah 7: Dasar-dasar operasional

Beberapa hal kecil memisahkan aplikasi hobi dari aplikasi yang dipercaya orang:

• Domain kustom dengan HTTPS. Lihat cara menghubungkan domain kustom.
• Email transaksional dari domain yang terverifikasi untuk konfirmasi pendaftaran dan reset kata sandi — dibahas dalam cara mengirim email dari aplikasi Anda.
• Kebijakan privasi dan syarat yang menjelaskan apa yang benar-benar Anda kumpulkan. Jangan menyalin klaim kepatuhan yang belum Anda penuhi.
• Jalur dukungan — bahkan alamat email yang dipantau.
• Kunci uji dan kunci live yang terpisah untuk pembayaran dan email, serta catatan jelas tentang lingkungan mana yang memakai kunci apa.

Langkah 8: Serah terima yang rapi

Cepat atau lambat, orang lain akan mengerjakan aplikasi ini: freelancer, co-founder baru, atau Anda sendiri enam bulan lagi. Buat itu mudah:

• README yang menjelaskan cara menjalankannya, variabel lingkungan apa yang dibutuhkan (hanya nama, jangan nilainya), dan cara men-deploy-nya.
• Daftar periksa alur utama dan pengujian otomatis.
• Catatan arsitektur singkat: front end, back end, basis data, layanan pihak ketiga, dan di mana masing-masing di-hosting.
• Daftar akses: siapa yang memiliki akses admin ke domain, hosting, basis data, dan akun pembayaran serta email. Letakkan akun-akun ini di bawah email bisnis, bukan email pribadi.
• Kode di Git, idealnya tersinkron ke repositori yang Anda miliki. Jika Anda mungkin memindahkan hosting nanti, baca cara mengekspor dan self-host aplikasi yang dibuat dengan AI.

AI bisa menyusun sebagian besar ini untuk Anda:

Tulis README untuk proyek ini bagi pengembang yang belum pernah melihatnya: apa yang dilakukan aplikasi, tech stack-nya, cara menjalankannya secara lokal, setiap variabel lingkungan yang dibaca (hanya nama dan tujuannya), bagaimana skema basis datanya diatur, dan cara men-deploy-nya.

Daftar periksa kesiapan produksi

• Alur utama sudah ditulis dan diuji, termasuk "tidak bisa mengakses data orang lain"
• Otorisasi dan validasi sisi server di setiap rute data
• Tidak ada kunci rahasia di kode front-end; kunci yang bocor sudah diganti
• Batas laju untuk autentikasi dan apa pun yang memakan biaya
• Pelacakan error dan peringatan uptime mengarah ke kotak masuk yang Anda baca
• Cadangan basis data disimpan di luar hosting aplikasi, dengan satu pemulihan uji yang berhasil
• Paginasi dan indeks sudah diperiksa dengan data yang realistis
• Domain kustom, domain pengiriman email yang terverifikasi, kebijakan privasi
• README dan daftar akses untuk siapa pun yang datang berikutnya

Melakukan ini dengan Mythex

Jika Anda membuat prototipe di Mythex, sebagian besar langkah ini adalah prompt di proyek yang sama. Ketik /test dan Mythex akan mengklik pratinjau live seperti pengguna dan melaporkan alur yang rusak — lihat App Testing. Kunci dimasukkan ke rahasia proyek, bukan ke chat; setiap giliran agen yang berhasil menyimpan checkpoint file Anda yang bisa dikembalikan, dan publikasi memberi Anda URL live dengan hosting dan basis data yang ditagihkan dari saldo kredit yang sama (batas hosting menjelaskan bagaimana aplikasi dan basis data tidur dan bangun kembali). Checkpoint mencakup file, bukan baris database, jadi tetap rencanakan cadangan data Anda. Di paket Pro, Anda bisa menghubungkan domain kustom dan mengekspor kode atau menyinkronkannya ke repositori GitHub Anda sendiri untuk serah terima.

Pertanyaan