Di tempat kerja, saya banyak bekerja dengan para vibe coder, dan itu membuat saya memikirkan soal pemeliharaan. Software perlu dirawat setelah dirilis, paket menjadi usang, kerentanan ditemukan, dan saat Anda baru mulai membangun dengan AI, semua ini mudah terlewat dari pikiran.
Lalu saya sadar bahwa saya seharusnya menerapkan pemikiran yang sama pada proyek saya sendiri, jadi saya menelusuri riwayat git-nya. Saya menemukan cukup banyak hal, meski bukan yang saya perkirakan, dan salah satunya masih terbuka pada hari saya melihatnya.
Jadi tulisan ini bukan lagi tentang apa yang dilupakan orang lain. Ini tentang saya.
Satu peringatan, tiga aplikasi
Pada 14 Oktober, Next.js merilis perbaikan untuk dua kerentanan kritis dan satu kerentanan tingkat tinggi. "Kritis" di sini berarti remote code execution, yaitu dalam kondisi tertentu, orang asing di internet bisa menjalankan kodenya sendiri di server Anda tanpa login. Perbaikannya hadir di versi 16.4.1.
Saya menjalankan tiga aplikasi di Next.js, semuanya dibangun dengan alat coding AI dan semuanya dengan satu penanggung jawab yang sama, yaitu saya. Inilah yang terjadi:
| Aplikasi | Kapan kodenya pindah ke versi yang sudah ditambal | Waktu setelah peringatan | Aktif di produksi |
|---|---|---|---|
| chandlernguyen.com | 18 Oktober | 4 hari | 18 Oktober |
| DIALØGUE | 29 Oktober | 15 hari | 29 Oktober |
| Prova | 3 November | 20 hari | 3 November |
Saat saya melihat pada 3 November, Prova masih terkunci di Next.js 16.2.6, versi yang dipakainya sejak Mei, dan itulah yang berjalan di produksi. Menjalankan pnpm audit --prod menampilkan 5 peringatan kritis, semuanya di Next.js.
Angka itu terdengar lebih buruk daripada yang saya temukan, jadi saya ingin bersikap adil. Saat saya memeriksa satu per satu dengan alat AI saya, sebagian besar yang kritis tidak berlaku untuk Prova. Prova tidak punya fungsi use cache, tidak berjalan di Windows, dan saya tidak menemukan input yang dikendalikan penyerang yang mencapai kode next/og. Yang terkait optimasi gambar kemungkinan besar juga tidak berlaku di Vercel, tetapi itu kesimpulan dari cara platform tersebut berperilaku, karena saya tidak menemukan pernyataan Vercel yang mengatakannya. Yang jelas berlaku adalah masalah denial of service tingkat tinggi di Server Actions, artinya seseorang bisa saja mengganggu aplikasi, dan itu tetap aktif sampai ditambal.
Saya memindahkan produksi ke Next.js 16.4.5 pada hari yang sama. Hasil audit turun dari 5 kritis menjadi 0, dan sebagian besar yang tingkat tinggi juga hilang. Yang tersisa berada di luar Next.js dan masih harus saya selesaikan, jadi ini lebih baik tetapi belum bersih.
Semua itu tidak bisa saya sebut pemeliharaan yang baik. Peringatan terburuk umumnya tidak mengenai Prova karena kebetulan cara aplikasinya dibangun, bukan karena ada yang memeriksa. Itu keberuntungan, dan saya hanya tahu karena akhirnya saya melihat.
Saya juga tidak bisa banyak berbangga atas baris pertama. Commit situs saya pada 18 Oktober adalah upgrade toolchain umum, dari Next.js 16.1.6, dan pesannya tidak menyebut peringatan itu. Mungkin itu hanya kebetulan waktunya pas.
Mengapa sibuk tidak membantu
Penjelasan yang mudah adalah Prova terabaikan, dan ada benarnya. Ada jeda 41 hari antar-commit pada Agustus dan September.
Namun, penjelasan itu runtuh di bulan Oktober. Prova punya 175 commit bulan itu. Saya merilis perbaikan untuk iOS, penagihan, email, dan terjemahan, dan versi Next.js-nya tidak bergerak. Pada 30 Oktober saya bahkan menulis rencana pemeliharaan dependensi. Baris statusnya berbunyi: "direncanakan; implementasi belum dimulai."
Jadi aktivitas bukanlah pemeliharaan, dan menurut saya inilah bagian terpenting bagi siapa pun yang membangun dengan AI. Saat Anda membuat fitur, Anda langsung mendapat umpan balik. Anda bisa melihat tombolnya, mengkliknya, dan melihatnya bekerja. Saat kerentanan diumumkan pada paket yang Anda pasang lima bulan lalu, Anda tidak mendapat apa-apa. Aplikasi tetap menyajikan halaman, tes tetap hijau, dan build tetap lolos. Tidak ada yang rusak, dan justru karena itulah tidak ada yang melihat.
Ini seperti alarm asap yang hanya berbunyi kalau Anda datang dan bertanya padanya. Alat AI membuat pembangunan rumah jauh lebih murah. Alat itu tidak memasang alarmnya.
Ini juga pernah terjadi pada saya sebelumnya. DIALØGUE tidak punya commit antara 6 Oktober 2025 dan 11 Januari 2026. React2Shell, kerentanan kritis Next.js dan React, menjadi publik pada awal Desember. Commit tambalan saya bertanggal 11 Januari, lebih dari lima minggu kemudian, dan catatan deployment produksi tertua yang masih bisa saya lihat berasal dari 18 Januari, jadi saya tidak bisa memastikan apa yang berjalan pada bulan Desember. Yang kemungkinan besar paling membantu saya tidak ada hubungannya dengan saya: Vercel mengatakan telah meluncurkan aturan firewall untuk semua pelanggannya, sekaligus dengan tegas mengatakan agar tidak mengandalkannya sebagai pengganti tambalan.
Saya ingin memperjelas satu hal, karena istilah "vibe coder" bisa terdengar seperti hinaan. Saya belajar coding lewat kursus terstruktur, termasuk sertifikat keamanan siber, repo-repo ini punya tes dan tahap review yang wajib dilewati, dan hal ini tetap terjadi. Jadi menurut saya ini bukan masalah pemula. Menurut saya inilah yang terjadi secara default ketika membuat software menjadi murah dan tidak ada yang ditugaskan untuk mengawasinya.
Seperti apa alarmnya
Kabar baiknya, pemeriksaan yang sangat kecil bisa banyak mengubah hal ini.
Pada 27 Oktober, saya menambahkan pnpm audit --prod ke CI situs saya, yaitu rangkaian pemeriksaan otomatis yang berjalan saat kode di-push. Pada 28 Oktober pemeriksaan itu gagal, karena peringatan di library perender email yang ikut terbawa ke situs saya tetapi tidak pernah dipakai, dan pada 29 Oktober saya menghapus library itu. Butuh dua hari dan saya tidak perlu mengingat apa pun.
Tidak ada yang pintar dari semua itu. Seseorang, atau sesuatu, hanya perlu ditugaskan untuk melihat.
Memperbarui paket tidak akan menyelamatkan saya
Kalau tulisan ini berhenti di situ, Anda akan mendapat rasa tenang yang palsu, karena beberapa perbaikan yang lebih tidak nyaman yang saya lakukan pada bulan Oktober tidak ada hubungannya dengan paket usang. Itu kesalahan di produk saya sendiri.
Di DIALØGUE, misalnya:
- Fungsi database yang punya hak istimewa bisa dipanggil hanya dengan public key, dan pengguna yang login bisa menjangkau fungsi yang seharusnya hanya untuk backend saya.
- Podcast yang sudah di-refund bisa hidup kembali dan selesai tanpa dikenai biaya lagi, dan itu benar-benar terjadi pada sejumlah kecil podcast.
Di Prova, peran database publik mewarisi izin yang tidak pernah dipilih siapa pun, seperti TRUNCATE, karena berasal dari default platform. Tidak ada jalur aplikasi yang memakainya, tetapi izin itu ada.
Tidak ada upgrade versi yang bisa memperbaiki satu pun dari masalah ini. Aplikasi-aplikasi ini berjalan dengan masalah-masalah tersebut, dan di sini pun tidak ada yang rusak. Masalahnya baru muncul karena sebuah security review memang mencarinya, dan security review yang pernah saya lakukan sebelumnya pada produk-produk ini tidak menangkap semuanya.
Apakah ada yang disalahgunakan? Saya tidak tahu, dan saya tidak bisa mengetahuinya sepenuhnya. Log database saya hanya mencakup sekitar 90 hari ke belakang, dan beberapa masalah ini lebih tua dari itu. Dalam periode yang bisa saya lihat, saya tidak menemukan panggilan dari luar ke fungsi-fungsi itu. Itu hanya mencakup jendela waktu terbatas dan tidak menunjukkan bahwa tidak terjadi apa-apa. Saya juga tidak bisa memastikan siapa atau apa yang memulai ulang podcast yang sudah di-refund itu, meski dugaan terbaik saya adalah retry di kode saya sendiri.
Ini juga bukan daftar yang lengkap. Saya masih mengerjakan masalah lain, dan tidak akan menjelaskannya selama masih terbuka.
Soal model ternyata bukan seperti yang saya kira
Saya tadinya mau menulis bahwa model AI lama membuat Anda membayar lebih mahal. Saya tidak bisa mendukung klaim itu. Saya sudah mencari, dan tidak ada perbandingan biaya sebelum dan sesudah di satu pun repo ini, jadi itu hanya tebakan.
Yang saya temukan lebih aneh. Model untuk draf skrip dan review di DIALØGUE disetel ke gemini-3.5-flash sampai 12 Oktober. Dokumentasi Google kini menyebutkan bahwa endpoint itu tidak akan dimatikan dan otomatis mengalihkan permintaan ke gemini-3.6-flash. Saya tidak tahu kapan pengalihan itu dimulai, jadi saya tidak bisa memberi tahu model mana yang menjawab dan selama berapa lama. Nama model di konfigurasi Anda tidak membekukan modelnya.
Harga juga berubah. Gemini 3.8 Flash, yang saya gunakan untuk Prova dan DIALØGUE sejak Oktober, tercantum seharga $0.75 per juta token input dan $3.75 per juta token output sampai 31 Desember. Mulai 1 Januari 2027, harganya menjadi dua kali lipat, yaitu $1.50 dan $7.50. Saya baru pindah bulan lalu, dan masih harus menghitung dampaknya pada biaya saya.
Melakukan upgrade juga bukannya tanpa risiko, dan saya tidak mau berpura-pura begitu:
- Tidak lama setelah saya memindahkan Ask Sydney ke DeepSeek Flash, setidaknya satu pertanyaan gagal di produksi karena model menginginkan lebih banyak putaran pencarian daripada yang diizinkan kode saya.
- Saat saya memindahkan embedding Prova, proses pertama gagal setelah tabel knowledge base dikosongkan, sehingga retrieval menurun sampai saya memulihkannya.
- Migrasi yang sama itu mengungkap pengaturan produksi yang tadinya akan mengirim nama model Claude ke API Google.
Yang membuat migrasi Prova bisa dipercaya adalah hal yang membosankan. Saya punya evaluasi tercatat dari sebelum perubahan, 22 dari 24 keputusan sprint review benar, dan saya mendapat skor yang sama sesudahnya. Tanpa itu, saya hanya bisa berharap.
Haruskah Anda memeliharanya sama sekali?
Pertanyaan tersulit adalah yang hampir saya lewatkan. Setiap aplikasi yang Anda rilis adalah langganan kecil yang harus terus Anda bayar dengan perhatian Anda, dan AI membuatnya sangat mudah untuk berlangganan lebih banyak lagi.
Dengan STRAŦUM, saya mengambil pilihan lain. Saya memensiunkannya dan menerbitkan v1 sebagai implementasi referensi. Repositorinya menyatakan bahwa proyek ini tidak dipelihara sebagai layanan produksi, dan file keamanannya mencantumkan peringatan yang saya ketahui, termasuk masalah dependensi saat build yang belum ada perbaikannya, yang dinilai berisiko praktis rendah. Menurut saya itu hasil yang sepenuhnya jujur. Versi yang tidak jujur adalah aplikasi yang masih menerima pendaftaran sementara tidak ada yang mengawasinya.
Apa yang akan saya lakukan pada hari Senin
Jika Anda sudah merilis sesuatu dengan AI dan ada orang yang memakainya, inilah daftar yang akan saya jadikan titik awal. Tidak ada yang perlu sempurna.
- Jalankan audit sekali, hari ini.
npm audit --omit=devataupnpm audit --prod, di setiap repo yang aktif. Lalu tanyakan pada alat AI Anda hasil mana yang berlaku untuk cara aplikasi Anda dibangun, karena tidak semuanya berlaku. - Jadikan pemeriksaan itu otomatis. Tambahkan ke CI agar bisa gagal tanpa Anda harus mengingatnya. Untuk aplikasi yang jarang Anda sentuh, gunakan juga jadwal berkala, karena pemeriksaan yang hanya berjalan saat push tidak membantu di bulan yang sepi.
- Baca izin Anda, bukan hanya paket Anda. Tanyakan apa yang bisa dilakukan seseorang hanya dengan public key Anda dan tanpa akun. Lalu ujilah di salinan lokal, jangan berasumsi.
- Cari secret di riwayat Anda. Jika kunci asli pernah ter-commit, cabut kuncinya. Menghapus barisnya saja tidak cukup.
- Cari tahu seberapa jauh log Anda mencakup ke belakang sebelum Anda membutuhkannya. Itu menentukan apakah Anda kelak bisa menjawab pertanyaan apakah sesuatu telah disalahgunakan.
- Simpan satu evaluasi kecil untuk setiap fitur AI. Bahkan 20 contoh nyata dengan jawaban baik yang sudah diketahui akan memberi tahu apakah pergantian model memperburuk keadaan.
- Periksa halaman penghentian dan harga penyedia AI Anda secara berkala. Masukkan ke kalender. Jika Anda memakai Gemini 3.8 Flash, 1 Januari sudah menjadi tanggal yang baik untuk memulai.
- Putuskan pertahankan atau pensiunkan untuk setiap aplikasi. Jika Anda tidak akan mengawasinya, matikan layanannya atau katakan terus terang.
Saya masih mencari tahu seberapa banyak dari semua ini yang bisa diserahkan kepada agen secara terjadwal. Yang pasti saya tahu, menulis rencana pada 30 Oktober tidak menambal apa pun.
Jika Anda membangun dengan AI, kapan terakhir kali Anda memeriksa sesuatu yang sudah Anda rilis, dan apa yang Anda temukan? Saya sungguh ingin tahu, terutama jika Anda punya alarm yang lebih baik daripada milik saya.