Saya membangun produk dengan AI—cara melakukan perbaikan tanpa merusak yang sudah berfungsi

Pelajari lebih lanjut cara bekerja dengan model di dokumentasi Ailoot.

Mengapa pekerjaan paling mahal dimulai setelah peluncuran?#

Anda membuat aplikasi dalam satu malam, menerbitkan tautan, lalu mengirimkannya kepada teman-teman. Aplikasi itu berfungsi. Lalu seminggu kemudian, orang sungguhan pertama datang, mengeklik sesuatu dengan cara yang keliru, dan setengah fiturnya berhenti berfungsi. Anda meminta Claude memperbaikinya—ia memperbaiki satu hal dan merusak hal lain. Terdengar familier?

Di sinilah muncul pertanyaan utama: apa yang harus dilakukan setelah meluncurkan produk, ketika euforia prototipe pertama yang berfungsi sudah berlalu dan Anda masih harus memeliharanya? Anda bisa menyebutnya vibe coding untuk orang dewasa. Membangun itu penuh kegembiraan dan kecepatan. Pemeliharaan menuntut kepala dingin: Anda memahami apa yang sedang diubah dan tetap mengendalikannya. Kebanyakan orang gagal pada bagian kedua ini karena tak ada yang mempersiapkan mereka untuk itu.

Sebuah studi industri menganalisis lebih dari sejuta perubahan kode dari 2.444 tim dan menghitung ke mana uang yang dihabiskan untuk pengembangan AI sebenarnya pergi. Berikut gambarannya:

Panduan “Biaya tersembunyi vibe coding” menjelaskan angka-angka ini lebih terperinci. Di sana, pertanyaannya adalah apa yang Anda bayar. Di sini, pertanyaannya berbeda: 44 sen dari setiap dolar digunakan untuk memperbaiki bug—dan seluruh artikel ini membahas cara mencegah porsi itu bertambah. Pekerjaan untuk menjaganya tetap terkendali disebut pemeliharaan.

Perbedaan antara orang yang melakukan vibe coding untuk orang dewasa dan orang yang hanya mengasuh jaringan saraf terlihat setelah peluncuran. Basis kode orang pertama bertumbuh, mereka membuat perbaikan, dan tidak ada yang rusak. Sebulan kemudian, produk orang kedua berubah menjadi perangkat bocor yang mereka takut sentuh. Berikutnya, saya akan menjelaskan cara masuk ke kelompok pertama.

Apa yang sebenarnya rusak: 5 bencana pascapeluncuran#

Ini adalah postmortem publik tentang produk nyata yang dibangun dengan AI, lengkap dengan angka dan tanggal. Anggap saja sebagai peta ladang ranjau—setiap ranjau sudah meledak untuk seseorang, dan cara menghindarinya sudah diketahui.

Kelima kasus ini punya akar masalah yang sama. Secara default, AI membuat sesuatu berfungsi saat ini, bukan dengan aman sebulan kemudian ketika sedang dibebani. Anda tidak dapat melihat perbedaannya saat mengembangkan produk di komputer sendiri. Perbedaannya terlihat ketika orang asing pertama yang berniat buruk muncul.

Masalahnya bukan pada tidak menulis kode secara manual—banyak orang bekerja dengan cara ini. Masalahnya adalah tidak bertanya, “Apakah basis datanya aman?” Berikutnya, saya akan menunjukkan prompt yang menanyakan hal itu untuk Anda.

Jaring pengaman pertama adalah git dan mengembalikan keadaan seperti “kemarin”#

Ketika Claude merusak sesuatu, Anda memerlukan tombol “kembalikan seperti kemarin”. Secara teknis, tombol itu disebut git, dan cara kerjanya lebih sederhana daripada yang dibayangkan.

Tiga istilah yang perlu dipahami orang nonprogrammer:

1. Repositori — folder proyek Anda yang disimpan di cloud (biasanya di GitHub). Salinan semua kode Anda yang tidak hanya tersimpan di komputer.
2. Commit — titik untuk kembali. Pada dasarnya, Anda memberi tahu kode, “simpan dalam keadaan ini.” Setiap commit adalah penanda yang dapat Anda kunjungi kembali.
3. Deploy — pemindahan. Kode tadinya lokal, di komputer Anda, dan hanya berfungsi untuk Anda. Deploy mengirimkannya ke server eksternal agar berfungsi bagi semua orang.

Selama Anda memiliki titik commit terbaru, Anda dapat mengembalikan apa pun yang rusak dengan satu kalimat. Secara harfiah.

Saya merusak sesuatu—kemarin semuanya berfungsi, tetapi hari ini tidak. Temukan commit terbaru ketika semuanya masih baik, tunjukkan perubahan sejak saat itu, lalu kembalikan proyek ke keadaan tersebut.

Dua aturan yang harus langsung diterapkan, sebelum orang lain melihat produk:

• Repositori harus privat. Jangan publik. Jika tidak, siapa pun dapat membaca kode Anda dan semua yang ada di dalamnya.
• Masukkan berkas rahasia ke daftar pengecualian. Kunci, kata sandi, dan kredensial akses basis data disimpan dalam berkas terpisah (biasanya .env), dan berkas itu tidak boleh masuk ke repositori. Tambahkan baris untuk .env di .gitignore, dan rahasia itu tetap bersama Anda.

Ada panduan terpisah tentang mengembalikan perubahan dengan aman di Claude Code: Cara mengembalikan perubahan di Claude Code. Tanpa titik untuk kembali, Anda berjalan di atas tali tanpa jaring pengaman, dan cepat atau lambat Anda akan jatuh.

Apa yang dikembalikan oleh /rewind, dan apa yang tidak?#

Claude Code mengambil snapshot keadaan sebelum setiap perubahan yang dibuatnya. Perintah /rewind (atau menekan Esc dua kali) mengembalikan berkas dan percakapan ke titik yang dipilih. Ini praktis: jika Anda merusak fitur lima menit lalu, Anda bisa kembali ke keadaan lima menit lalu.

Namun ada jebakan yang menyebabkan pemula kehilangan data. /rewind tidak mengembalikan semuanya:

Anthropic menjelaskannya secara gamblang: snapshot adalah tombol “undo” lokal, sedangkan git adalah riwayat permanen. Snapshot melengkapi kontrol versi, tetapi tidak menggantikannya.

Kesimpulan praktis bagi orang nonprogrammer: /rewind akan menyelamatkan Anda dari situasi “Claude baru saja merusak fitur”. Namun, jika Claude sempat menghapus baris basis data atau mengunggah kode ke cloud, hanya git dan cadangan basis data yang dapat mengembalikannya. Jadi, pertahankan kedua lapisan: snapshot untuk mengembalikan perubahan dengan cepat, commit untuk riwayat permanen proyek.

Bagaimana membuat perbaikan tanpa merusak yang sudah berfungsi?#

Setiap orang kedua terjebak dalam siklus ini. Anda meminta AI memperbaiki bug kecil. AI menyarankan perubahan yang masuk akal. Perubahan itu merusak hal lain. Anda meminta AI memperbaiki masalah baru tersebut, lalu dua masalah lagi muncul. Begitu seterusnya.

Siklus itu terjadi karena vibe coding bersifat nondeterministik. Prompt yang sama menghasilkan kode berbeda jika digunakan dua kali. Jadi, setiap pengeditan dapat diam-diam menggeser logika di sekitarnya: ambang diskon berubah dari 10 menjadi 12 persen, atau aturan validasi berubah perilaku—tanpa pemeriksaan dari Anda dan tanpa satu pun peringatan. Ini disebut pergeseran logika, dan diam-diam merusak hal-hal yang menghasilkan uang: harga, akses, dan pembayaran.

Ada satu aturan untuk mencegah pergeseran, dan aturan ini cukup sederhana untuk ditempel di dinding: jangan melakukan commit pada kode yang tidak dapat Anda jelaskan kata demi kata kepada orang lain.

Dalam praktik, aturan ini menjadi kerangka siap pakai sebelum mengubah kode yang berfungsi. Kerangka ini membuat AI mengambil langkah kecil dan menunjukkan dengan tepat apa yang berubah.

Sebelum mengubah kode, lakukan hal berikut:

Simpan keadaan saat ini yang berfungsi sebagai titik terpisah untuk kembali (commit).

Jelaskan dengan kata-kata apa tepatnya yang hendak Anda ubah dan di berkas mana.

Buat perubahan sekecil mungkin—hanya yang menyelesaikan tugas saya, tanpa tambahan apa pun.

Tunjukkan apa yang berubah dan jelaskan setiap perubahan agar saya dapat menjelaskannya kepada orang lain.
Jangan sentuh logika harga, akses, atau pembayaran kecuali saya memintanya.

Prinsip lain yang dapat menghemat berminggu-minggu adalah disiplin dalam membatasi tugas. Satu masalah, satu perubahan, implementasi cepat. Jangan meminta AI menulis ulang setengah proyek dalam satu prompt. Pengembang profesional terkadang mulai membangun seluruh Uber padahal yang dibutuhkan hanya satu tombol—lalu mengerjakannya selama berbulan-bulan. Anda tidak memerlukan itu.

Semua yang saya jelaskan berlandaskan satu hal: mengelola konteks. Agar AI tidak merusak logika di sekitarnya, AI perlu mengingat aturan proyek Anda.

Bagaimana memeriksa perubahan sebelum menerbitkannya?#

Di antara “berfungsi di komputer saya” dan “berfungsi untuk semua orang” terdapat langkah perantara yang dilewatkan pemula: salinan uji. Ini adalah snapshot terpisah dari lingkungan produksi tempat Anda memeriksa perubahan sebelum orang sungguhan melihatnya. Siklus kerjanya seperti ini:

1. Bangun dan periksa perubahan sendiri (pengembangan).
2. Deploy ke staging—salinan produksi, tetapi tanpa pengguna sungguhan.
3. Jalankan skenario utama dan pastikan tidak ada yang berubah.
4. Baru setelah itu deploy ke produksi.

Mengapa ini penting setelah peluncuran: setiap rilis membawa risiko. Perubahan kode kecil dapat merusak masuk ke akun. Satu pengaturan yang hilang dapat melumpuhkan seluruh produk. Staging menemukan masalah ini tanpa konsekuensi; di produksi, Anda kehilangan pelanggan.

Agar tidak memeriksa semuanya secara manual setiap kali, beri AI prompt untuk membandingkan perilaku versi baru dengan versi lama di area penting.

Saya akan meluncurkan sebuah perubahan. Jalankan skenario utama produk secara berurutan dan periksa apakah masing-masing masih berfungsi seperti sebelumnya:

Pendaftaran dan masuk pengguna baru.

Pembayaran dan pemberian akses setelah pembayaran.

Hak akses—pengguna biasa tidak dapat melihat data orang lain atau area admin.

Angka utama logika bisnis (harga, diskon, batas) tidak berubah.
Jika ada yang berperilaku berbeda dari versi sebelumnya, berhenti dan tunjukkan dengan tepat apa yang berubah.

Di mana rahasia Anda? Celah terbesar bagi pemula#

Saya akan menjelaskan ranjau terbesar ini secara terperinci karena ranjau ini melumpuhkan lebih banyak produk daripada yang lain. Saat AI menulis kode, cara termudah adalah menaruh kunci di tempat yang langsung membuatnya berfungsi—tepat di dalam kode halaman yang terbuka di browser. Anda tidak akan melihat perbedaannya selama pengembangan. Namun, siapa pun dapat membaca apa pun yang sampai ke browser dengan membuka alat pengembang.

Pendiri yang pelanggannya ditagih $87.500 kemudian mengatakan bahwa satu prompt saja dapat mencegahnya. Tagihan akhirnya dibatalkan, tetapi biaya yang tidak dapat dikembalikan dan hilangnya ketenangan pikiran tetap ada. Berikut prompt tersebut.

Periksa seluruh proyek dan pastikan tidak ada kunci rahasia yang masuk ke browser:

Temukan semua kunci untuk basis data, sistem pembayaran, dan layanan eksternal.

Pastikan masing-masing hanya disimpan di server, dalam variabel lingkungan, dan bukan dalam kode halaman.

Periksa riwayat proyek—apakah ada kunci yang tidak sengaja masuk sebelumnya?
Tunjukkan daftar setiap tempat Anda menemukan rahasia dan apa yang perlu dilakukan untuk masing-masing.

Ranjau berikutnya yang berdekatan adalah memeriksa hak akses hanya di sisi browser. Jika produk Anda memutuskan apakah akan “menampilkan area admin” dalam kode halaman, siapa pun dapat melewati keputusan itu. Hak akses harus selalu diperiksa di server. Basis data hanya boleh memberikan data kepada mereka yang berhak menerimanya—itulah fungsi row-level security (RLS), dan fitur ini harus diaktifkan di setiap tabel.

Sebelum menjual akses atau mengizinkan orang lain masuk, lakukan audit keamanan umum pada produk.

Telusuri proyek seperti penyerang dan temukan celah keamanan:

Apakah ada kunci rahasia yang disimpan dalam kode yang dikirim ke browser atau dalam riwayat proyek?

Apakah row-level security (RLS) diaktifkan di setiap tabel basis data, dan apakah hak akses diperiksa di server, bukan hanya di browser?

Apakah backup basis data otomatis sudah dikonfigurasi, dan apakah saya pernah memeriksa bahwa saya dapat memulihkannya?

Apakah basis data produksi dipisahkan dari lingkungan tempat agen AI berjalan?
Untuk setiap butir, beri tahu saya apakah semuanya baik atau apa tepatnya yang perlu diperbaiki.

Ada panduan lengkap terpisah tentang keamanan vibe coding: Cara mengamankan aplikasi buatan vibe coding. Aturannya sederhana: anggap semua yang dilakukan AI secara default tidak aman sampai Anda memeriksanya.

Di mana meng-hosting produk Anda: jenjang hosting#

Anda tidak perlu langsung menyewa server sendiri dan mengonfigurasinya secara manual—itu tugas yang rumit pada tahap awal dan akan menghabiskan waktu Anda. Ada jenjang yang dapat Anda lalui seiring pertumbuhan produk:

1. Hosting gratis (misalnya Vercel)—untuk diri sendiri, pengujian, dan proyek kecil. Ini berfungsi jika platform tersedia bagi audiens Anda dan Anda tidak menyimpan data pribadi orang.
2. Platform dengan deployment satu perintah (Railway)—ketika Anda memiliki backend dan basis data. Anda melakukan deploy dengan satu perintah dan tidak perlu mengonfigurasi server. Hambatan untuk memulai sangat rendah.
3. Server khusus milik sendiri—ketika bebannya tinggi dan Anda memerlukan kendali penuh. Beralihlah ke sini nanti, setelah Anda mencapai batas platform.

Bagi nonprogrammer yang baru meluncurkan produk, opsi termudah adalah platform dengan deployment satu perintah, tanpa konfigurasi server manual. Beralihlah ke server sendiri nanti. Jika Anda ingin mengikuti jalur ini dengan contoh konkret, lihat panduan men-deploy proyek buatan vibe coding ke server sendiri dengan Coolify.

Kapan aplikasi, basis data, dan backup perlu dipisahkan?#

Tiga hal yang tidak seharusnya disimpan dalam satu keranjang: aplikasi, basis data, dan backup. Selagi pengguna masih sedikit, semuanya berada bersama, dan itu tidak masalah. Namun ada tanda yang jelas kapan waktunya memisahkannya.

• Tempatkan aplikasi dan basis data di mesin berbeda. Tandanya: saat beban puncak, CPU dan memori bertahan di atas 70–80 persen, permintaan melambat, dan aplikasi serta basis data berebut sumber daya yang sama. Setelah dipisahkan, Anda dapat memperkuat basis data tanpa menyentuh aplikasi, dan sebaliknya.
• Ikuti aturan backup 3-2-1. Tiga salinan data, pada dua jenis media berbeda, dengan satu salinan di luar lokasi. Ini melindungi dari kegagalan perangkat keras dan ransomware. Hal utamanya adalah backup harus otomatis.

Frekuensi backup bergantung pada seberapa mahal kehilangan data selama beberapa jam. Untuk layanan berlangganan online yang tidak dapat menerima kehilangan catatan pembayaran selama satu jam, interval backup harus lebih singkat dari satu jam, atau diperlukan log transaksi dan pemulihan titik waktu (PITR) yang terverifikasi. Pilih interval berdasarkan kehilangan data maksimum yang dapat ditoleransi, dan uji waktu pemulihan layanan secara terpisah. Sekali sehari cukup untuk blog. Logikanya sederhana: tentukan berapa banyak data yang sanggup Anda kehilangan dan konfigurasikan backup yang sesuai.

Bantu saya memutuskan apakah sudah waktunya memindahkan produk saya ke infrastruktur yang lebih serius. Periksa dan tanyakan setiap poin kepada saya:

Seberapa tinggi beban CPU dan memori saat puncak—apakah penggunaan bertahan di atas 70–80 persen atau tidak?

Apakah basis data dan aplikasi berada di mesin yang sama atau berbeda?

Apakah backup basis data otomatis sudah dikonfigurasi, dan apakah saya sudah menguji pemulihan darinya?

Apakah ada salinan lingkungan terpisah (staging) untuk pemeriksaan sebelum deployment?
Berdasarkan hasilnya, berikan rekomendasi yang jelas: apa yang perlu dibiarkan, apa yang perlu dipisahkan lebih dahulu, dan alasannya.

Ada pertanyaan terpisah: basis data terkelola atau milik sendiri. Bagi tim kecil, basis data terkelola hampir selalu lebih baik: milik sendiri lebih murah dari sisi perangkat keras, tetapi menghabiskan waktu berjam-jam untuk pemeliharaan. Jika Anda bekerja sendiri dan produk Anda bukan infrastruktur, waktu tersebut lebih mahal daripada selisih harga server.

Bagaimana mengotomatiskan pemeliharaan?#

Pemeliharaan manual melelahkan. Ada dua cara untuk menguranginya: pemantauan dan agen patroli.

Pemantauan menggunakan dua alat berbeda untuk dua pekerjaan berbeda:

1. “Apakah situs aktif?”—pemantau waktu aktif (misalnya UptimeRobot). Alat ini melakukan ping ke produk setiap beberapa menit dan mengirim peringatan jika situs tidak aktif. Ada paket gratis.
2. “Apa tepatnya yang rusak?”—pelacak kesalahan (misalnya Sentry). Alat ini mengumpulkan kesalahan di dalam aplikasi dan menunjukkan di mana serta mengapa sesuatu gagal.

Alat pertama menangkap bahwa produk tidak aktif. Alat kedua menunjukkan fitur mana yang gagal dan alasannya. Bersama-sama, keduanya menjawab pertanyaan, “Apakah saya akan mengetahui kegagalan sebelum pelanggan menulis ke dukungan?”

Tingkat kedua otomatisasi adalah agen patroli. Bayangkan sebuah agen real estat: pukul tujuh pagi, agen AI membaca pertanyaan di situs, melihat bahwa formulir pemesanan rusak, menemukan penyebabnya di kode, lalu membawa perbaikan siap pakai beserta penjelasan. Anda meninjaunya dan berkata “ya”—perbaikan itu di-deploy. Urutannya penting: pertama selesaikan masalah pengguna (berikan akses, minta maaf), lalu selidiki penyebabnya dan uangnya.

Satu aturan lagi mengenai akses AI ke basis data produksi: berikan akun hanya-baca, dan sembunyikan data pribadi di balik lapisan perantara agar agen melihat “nama”, bukan nama asli seseorang. Dengan begitu, meskipun melakukan kesalahan, agen secara fisik tidak akan mampu menghapus atau merusak data produksi. Insiden di tabel di atas, ketika agen menghapus basis data produksi, tepat menggambarkan akibat tidak adanya pembatasan ini. Panduan Apa yang harus dilakukan jika AI menghapus basis data Anda menjelaskan apa yang harus dilakukan jika bencana sudah terjadi.

Kapan waktunya menghentikan produk?#

Bagian pemeliharaan yang paling sering diremehkan adalah mengetahui kapan harus berhenti memelihara. Setiap orang yang banyak membangun produk punya kuburan proyek: membangun satu, mengutak-atiknya, lalu meninggalkannya. Itu wajar, dan bukan kegagalan. Kegagalan adalah menyeret sesuatu yang tidak digunakan siapa pun selama berbulan-bulan karena menyesali waktu yang sudah dihabiskan.

Ambang batas yang dapat digunakan untuk mengambil keputusan:

1. Dua minggu—cukup untuk melihat apakah sebuah ide berhasil. Jika pengguna sungguhan pertama kembali, lanjutkan. Kesunyian adalah jawaban.
2. Tiga bulan—batas tegas. Jika belum berhasil dalam tiga bulan, hentikan. Dengan kecepatan vibe coding, menghabiskan enam bulan untuk menguji satu ide terlalu lama.

Menutup proyek sulit secara psikologis, jadi perlakukan itu sebagai keputusan, bukan perasaan. Melepaskan proyek yang sudah Anda investasikan mirip memecat karyawan yang tidak mampu melakukan pekerjaannya: tidak menyenangkan, tetapi mempertahankannya lebih mahal daripada melepaskannya.

Pemeliharaan adalah pekerjaan untuk menjaga agar produk tetap hidup dan berguna bagi orang. Segala hal lainnya—git, backup, pemantauan—hanyalah alat untuk membantu Anda mencapai titik ketika produk mulai bekerja untuk Anda setiap hari.

Membangun produk dengan AI dalam satu malam adalah separuh pekerjaan. Menjaganya tetap hidup dan aman seiring pertumbuhan—itulah arti vibe coding untuk orang dewasa.

Untuk langkah berikutnya—Ailoot.