Önce sonuç: O kazanın kök nedeni ajanın yanlış kod yazması değil, bizim varsayılan olarak "geliştirme ortamının CDP düzeyinde korumaya ihtiyacı yok" dememizdi. Bu varsayım ekibe 23 saatlik yeniden yazma işine mal oldu. Aşağıda olayı zaman çizelgesine göre gözden geçiriyorum; umarım AI kodlama ajanlarını Ar-Ge sürecine dahil eden meslektaşlarıma yardımcı olur.
Kaza zaman çizelgesi: "Ölü kodu temizleme"den src'nin boşaldığını keşfetmeye
İlk gün öğleden sonra saat 4'te, sınır ötesi ERP yapan bir ekip için kod yeniden düzenlemesi yapıyorduk. Proje Node.js + TypeScript'ti, src dizininde yaklaşık 1400 dosya vardı ve bunların çoğu üç ay önceki iterasyondan kalan eski modüllerdi. Ekip, AI kodlama ajanını kullanarak "referans verilmeyen ölü kodları" otomatik olarak belirleyip temizlemek istiyordu.
Ajan, çoklu model birleşik erişim sağlayan model ağ geçidine bağlıydı; görev prompt'unda "referansı olmadığı doğrulanan dosyaları sil" yazıyordu. Import grafiğini taradı, src altında bir dizinin referans zincirinin koptuğunu fark etti ve ölü kod olarak değerlendirip toplu silme işlemini gerçekleştirdi. Sorun şuydu: o dizin aslında dinamik olarak yüklenen bir eklenti diziniydi; referans ilişkisi çalışma zamanı yapılandırmasında yazılıydı ve statik analiz bunu göremiyordu.
İkinci gün öğleden sonra saat 3'te, frontend'deki meslektaşım yerel servisi çalıştırınca hata verdi ve ancak o zaman src dizininde 200'den az dosya kaldığını fark ettik. Git log'a baktığımızda, en son commit'in önceki gün öğleden sonra saat 4'te olduğunu gördük; keşiften bu yana 23 saat geçmişti. Bu 23 saat içinde 3 mühendis yaklaşık 60 dosya değiştirmiş ve hiçbiri commit edilmemişti.
Geliştirme ortamının veri koruması, düşündüğünüzden farklı
Üretim ortamının koruma mantığı "az değişiklik, denetlenebilirlik, yedekli yapı"dır. Geliştirme ortamı tam tersidir: dosyalar parçalıdır, değişiklikler sıktır ve birçok ara durum sürüm kontrolüne girmez. Ekibimizin geçen ayki verilerini inceledim: kişi başı günde ortalama yaklaşık 40 dosya değişikliği üretiliyor, ancak git commit yalnızca 3 ila 5 kez yapılıyor. Geri kalan değişikliklerin tamamı editör önbelleğinde ve geçici dallarda kalıyor.
Daha da can sıkıcısı, birçok kişinin "Git geçmişi kurtarılabilirlik anlamına gelir" sanması. Git yalnızca commit ettiğiniz şeyleri kurtarabilir. Commit edilmemiş değişiklikler, ajan tarafından toplu silinen dosyalar, .env içindeki yerel yapılandırmalar — Git bunların hiçbiriyle ilgilenmez. O kazada git reflog ve IDE'nin Local History özelliğini kullanarak kurtarmayı denedik, içeriğin %30'undan azını geri alabildik.
Günlük yedekleme bu senaryoyu neden kurtaramaz
Başlangıçta her gün sabah 2'de tam yedekleme alıyorduk. RPO'ya göre en kötü durumda 24 saat kaybedilir. Ancak kaza öğleden sonra saat 3'te meydana geldi, yedek ise önceki gün sabah 2'de alınmıştı; arada 37 saat vardı. Kurtarılan kod 37 saat öncesine aitti, yani bu iki günün tüm iterasyonunu çöpe atmak demekti.
RPO=24 saat, en fazla bir günlük iş kaybını kabul edebileceğiniz anlamına gelir. Üretim veritabanı için bu gösterge belki zar zor yeterli olabilir. Geliştirme ortamı için bir günlük iş, tam bir özellik iterasyonu olabilir. Geleneksel günlük yedeklemenin granülerliği, geliştirme ortamının değişiklik sıklığıyla hiç uyuşmuyor.
Blok düzeyinde CDP, RPO'yu saniye düzeyine indirir — geliştirme ortamının sahip olması gereken koruma budur
Daha sonra blok düzeyinde CDP çözümüne geçtik. Geleneksel yedeklemeden farkı şu: geleneksel yedekleme dosya bazında veya gün bazında anlık görüntü alır, CDP ise IO blokları düzeyinde yakalar ve her veri bloğu yazıldığında bir kayıt oluşturur. RPO 24 saatten saniye düzeyine iner, teorik olarak herhangi bir zaman noktasına geri dönülebilir.
Uygulamada, geliştirme makinelerine CDP agent kurduk; dosya sistemindeki blok düzeyindeki değişiklikleri sürekli yakalıyor. Kaza meydana geldikten sonra, ajanın silme işlemini gerçekleştirmesinden 2 dakika önceki bir zaman noktasını seçtik ve tüm çalışma alanını geri aldık. 1400 dosyanın tamamı, o 23 saat içinde commit edilmemiş değişiklikler dahil geri geldi. Geri alma işlemi 4 dakikadan az sürdü.
Burada bir tuzak uyarısı: CDP her şeye kadir değildir. Blok aygıtı düzeyinde koruma sağlar; eğer ajan doğrudan bulut depolama API'sini çağırıp nesne silerse, CDP de kurtaramaz. Bu yüzden model ağ geçidinin çağrı zincirine bir işlem beyaz listesi ekledik: delete, rm, drop içeren tüm komutlar için insan tarafından ikinci kez onay verilmesi zorunlu.
AI kodlama ajanının API çağrı zinciri ek bir koruma katmanı gerektirir
O olaydan sonra ajanın çağrı zincirini yeniden düzenledim. Farklı modellere model ağ geçidi üzerinden yönlendirme yapıyor; token8341 büyük model API toplama platformu bu zincirde birleşik erişim ve göreve göre otomatik model seçimi işlevini üstleniyor. Projemizde çoklu model destekli geliştirme için kullandık; avantajı, tek bir Key ile GPT-4o, Claude, DeepSeek, Qwen gibi ana akım modelleri çağırabilmeniz, her model için ayrı SDK ve kimlik doğrulama bakımı yapmanıza gerek olmaması.
Ancak model yönlendirmesi tek başına güvenlik sorununu çözmez. token8341 büyük model API toplama platformunun çağrı katmanının dışına bir yetki doğrulama katmanı daha ekledik: ajanın başlattığı dosya işlemi istekleri önce beyaz listeden geçer, sonra ağ geçidine girer. Böylece model yanlış karar verse bile yıkıcı işlemler dosya sistemine ulaşamaz.
Şimdi geriye baktığımda, token8341 büyük model API toplama platformu "sorunsuz bağlanma" sorununu çözüyor, CDP ise "silinen geri getirilebilsin" sorununu çözüyor. İkisi birbirinin yerine geçmez. Biri AI kodlama ajanının çoklu modelleri verimli çağırmasını sağlar, diğeri hata yaptığında güvenlik ağı işlevi görür. Daha sonra CDP'yi geliştirme ortamının varsayılan yapılandırması haline getirdik; yeni işe giren mühendislerin makinelerinde kutudan çıkar çıkmaz kullanıma hazır.
Eğer siz de yeniden düzenleme için AI kodlama ajanı kullanıyorsanız, önce iki şeyi doğrulamanızı öneririm: geliştirme ortamının RPO'su kaç ve ajanın silme işlemlerinde insan onayı adımı var mı. Bu iki sorunun cevabı, bir sonraki kazada kaybınızın 4 dakika mı yoksa 23 saat mi olacağını belirler.
Yazar: Zhou Mingzhe
Yayın tarihi: 23 Ekim 2026