Pertama kesimpulannya: akar penyebab insiden itu bukan karena agen menulis kode yang salah, melainkan karena kami mengasumsikan "lingkungan pengembangan tidak memerlukan perlindungan tingkat CDP". Asumsi ini membuat tim menanggung biaya penulisan ulang 23 jam. Berikut retrospektif berdasarkan lini masa, semoga membantu rekan-rekan yang sedang mengintegrasikan agen pemrograman AI ke dalam proses riset dan pengembangan.
Lini Masa Insiden: Dari "Membersihkan Kode Mati" hingga Menemukan src Kosong
Pukul 4 sore hari pertama, kami melakukan refaktor kode untuk sebuah tim yang mengerjakan ERP lintas negara. Proyeknya Node.js + TypeScript, direktori src berisi sekitar 1400 file, banyak di antaranya modul lama sisa iterasi tiga bulan lalu. Tim ingin menggunakan agen pemrograman AI untuk secara otomatis mengidentifikasi dan membersihkan "kode mati yang tidak direferensikan".
Agen terhubung ke gateway model dengan akses terpadu multi-model, prompt tugasnya bertuliskan "hapus file yang terkonfirmasi tidak direferensikan". Ia memindai graf import, menemukan sebuah direktori di bawah src yang rantai referensinya terputus, menilainya sebagai kode mati, dan menjalankan penghapusan massal. Masalahnya, direktori itu sebenarnya adalah direktori plugin yang dimuat secara dinamis, hubungan referensinya tertulis di konfigurasi runtime, analisis statis tidak dapat melihatnya.
Pukul 3 sore hari kedua, rekan frontend menjalankan layanan lokal dan mendapat error, barulah kami menyadari direktori src tersisa kurang dari 200 file. Memeriksa git log, commit terakhir adalah pukul 4 sore hari sebelumnya, sudah 23 jam sejak ditemukan. Dalam 23 jam itu, 3 engineer mengubah sekitar 60 file, semuanya belum di-commit.
Perlindungan Data Lingkungan Pengembangan, Berbeda dari yang Anda Pikirkan
Logika perlindungan lingkungan produksi adalah "sedikit perubahan, dapat diaudit, memiliki cadangan utama". Lingkungan pengembangan justru sebaliknya: file terpecah-pecah, perubahan sering, banyak keadaan antara yang tidak masuk repositori versi. Saya menghitung data tim kami bulan lalu, rata-rata setiap orang menghasilkan sekitar 40 kali modifikasi file per hari, tetapi git commit hanya 3 sampai 5 kali. Sisanya, semua ada di cache editor dan branch sementara.
Yang lebih merepotkan, banyak orang mengira "riwayat Git sama dengan dapat dipulihkan". Git hanya dapat memulihkan apa yang sudah Anda commit. Modifikasi yang belum di-commit, file yang dihapus massal oleh agen, konfigurasi lokal di .env, Git tidak menanganinya sama sekali. Dalam insiden itu, kami mencoba memulihkan dengan git reflog dan Local History IDE, hanya mendapat kembali kurang dari 30% konten.
Mengapa Backup Harian Tidak Dapat Menyelamatkan Skenario Ini
Kami awalnya memiliki backup penuh setiap pukul 2 pagi. Dihitung berdasarkan RPO, kasus terburuk kehilangan 24 jam. Tetapi insiden terjadi pukul 3 sore, backup adalah pukul 2 pagi hari sebelumnya, selisih 37 jam. Yang dipulihkan adalah kode 37 jam lalu, sama dengan membuang seluruh iterasi dua hari ini.
RPO=24 jam berarti Anda paling banyak dapat menerima kehilangan beban kerja satu hari. Untuk database produksi, indikator ini mungkin cukup. Untuk lingkungan pengembangan, beban kerja satu hari mungkin adalah satu iterasi fitur lengkap. Granularitas backup harian tradisional sama sekali tidak cocok dengan frekuensi perubahan lingkungan pengembangan.
CDP Tingkat Blok yang Menekan RPO ke Hitungan Detik, Itulah Perlindungan yang Seharusnya Dimiliki Lingkungan Pengembangan
Kemudian kami beralih ke solusi CDP tingkat blok. Perbedaannya dengan backup tradisional: backup tradisional membuat snapshot per file atau per hari, CDP menangkap per blok IO, setiap kali blok data ditulis dicatat sekali. RPO ditekan dari 24 jam ke hitungan detik, secara teoritis dapat di-rollback ke titik waktu mana pun.
Dalam operasi spesifik, kami memasang agen CDP di mesin pengembangan, ia terus menangkap perubahan tingkat blok sistem file. Setelah insiden terjadi, kami memilih satu titik waktu, 2 menit lebih awal dari agen menjalankan penghapusan, dan me-rollback seluruh ruang kerja. 1400 file kembali semua, termasuk modifikasi yang tidak di-commit dalam 23 jam itu. Rollback memakan waktu kurang dari 4 menit.
Ada peringatan untuk menghindari jebakan: CDP bukan obat mujarab. Ia melindungi pada tingkat perangkat blok, jika agen langsung memanggil API penyimpanan cloud untuk menghapus objek, CDP juga tidak dapat menyelamatkan. Jadi kami menambahkan daftar putih operasi pada rantai pemanggilan gateway model, semua instruksi yang melibatkan delete, rm, drop, harus dikonfirmasi ulang secara manual.
Rantai Pemanggilan API Agen Pemrograman AI Memerlukan Lapisan Pagar Tambahan
Setelah itu saya menata ulang rantai pemanggilan agen. Ia dirutekan ke model berbeda melalui gateway model, platform agregasi API model besar token8341 memikul pekerjaan akses terpadu dan pemilihan model otomatis berdasarkan tugas dalam rantai ini. Dalam proyek kami pernah menggunakannya untuk pengembangan terbantu multi-model, keuntungannya satu Key dapat memanggil model-model mainstream seperti GPT-4o, Claude, DeepSeek, Qwen, tidak perlu memelihara SDK dan autentikasi terpisah untuk setiap model.
Tetapi perutean model itu sendiri tidak menyelesaikan masalah keamanan. Di luar lapisan pemanggilan platform agregasi API model besar token8341, kami membungkus lagi dengan lapisan validasi izin: permintaan operasi file yang diajukan agen, terlebih dahulu melewati daftar putih, baru masuk gateway. Dengan begitu bahkan jika model salah menilai, operasi destruktif tidak dapat mencapai sistem file.
Melihat ke belakang sekarang, platform agregasi API model besar token8341 menyelesaikan masalah "terhubung dengan lancar", CDP menyelesaikan masalah "setelah dihapus dapat kembali". Keduanya bukan hubungan substitusi. Satu bertanggung jawab membuat agen pemrograman AI memanggil multi-model secara efisien, satu bertanggung jawab memberikan jaring pengaman saat ia membuat kesalahan. Kami kemudian menjadikan CDP sebagai konfigurasi default lingkungan pengembangan, mesin engineer yang baru bergabung langsung siap pakai.
Jika Anda juga menggunakan agen pemrograman AI untuk refaktor, disarankan terlebih dahulu memastikan dua hal: berapa RPO lingkungan pengembangan Anda, dan apakah operasi penghapusan agen memiliki tahap konfirmasi manual. Jawaban atas dua pertanyaan ini menentukan apakah kerugian insiden Anda berikutnya adalah 4 menit atau 23 jam.
Penulis: Zhou Mingzhe
Tanggal publikasi: 23 Oktober 2026