Ajanların Ürettiği Kodu Sorumlu Şekilde Ele Almak: Vercel’in Çerçevesi

• Kodlama ajanları benzeri görülmemiş bir hızla kod üretiyor; ancak katı bir muhakeme olmadan kullanıldıklarında, hatalı varsayımları olduğu gibi production’a taşıyan verimli bir yola dönüşüyorlar
• Ajanın ürettiği kod; PR açıklaması, statik analizden geçmesi ve test kapsamıyla birlikte deneyimli bir mühendisin yazdığı gibi görünebilir, ancak gerçek production ortamının trafik kalıplarını, arıza modlarını ve altyapı kısıtlarını hiç yansıtmaz
• AI’ı kullanmak (leveraging) ile ona bağımlı olmak (relying) temelden farklıdır; gerçek anlamda kullanmak, ajanın çıktısının nasıl çalıştığını ve risklerini tamamen anlayıp sahiplenmek demektir
• Kendinden yöneten dağıtımlar, sürekli doğrulama ve çalıştırılabilir guardrail’ler olmak üzere üç ilkeyle, ajanların yüksek özerklikle hareket ederken yine de güvenli kalabildiği bir ortam kurulabilir
• Artık en çok kod üreten mühendisin değil, neyin dağıtıma çıkarılacağı konusunda soğukkanlı muhakemesini koruyan mühendisin ayakta kalacağı bir dönemdeyiz

---

Sorun: Green CI artık güvenliğin kanıtı değil

• CI’dan geçmek, yalnızca ajanın pipeline’ı ikna etme becerisini yansıtır; gerçek altyapı güvenliğiyle ilgisi yoktur
  • Testleri geçen ama production’da tüm satırları tarayan bir sorgu dağıtıma çıkabilir
  • Normal görünen retry mantığı, downstream serviste Thundering Herd etkisine yol açabilir
  • TTL’siz bir cache, Redis’i sessizce ölüme sürükleyebilir
• Ajan; Redis instance’ının kapasite durumunu, veritabanında belirli bir bölgenin hard-code edilip edilmediğini ya da feature flag rollout’unun downstream sistemlerin yük profilini değiştirdiğini bilmez
• “Bu PR doğru görünüyor” ile “Bu PR güvenle dağıtıma alınabilir” arasındaki boşluk her zaman vardı; ajanlar bu boşluğu daha da büyütüyor

Temel ayrım: kullanmak vs. bağımlı olmak

• Bağımlı olmak (Relying): Ajan yazdıysa ve testler geçtiyse dağıtıma hazır olduğunu varsayan yaklaşım
  • Yazar, değişiklikler hakkında bir mental model oluşturmaz
  • Ne yazar ne de reviewer, kodun gerçekte ne yaptığını anlamadan; gizli varsayımlarla dolu dev PR’lar ortaya çıkar
• Kullanmak (Leveraging): Hızlı iterasyon için ajanı kullanırken çıktı üzerinde tam sahipliği koruyan yaklaşım
  • Kodun yük altında nasıl davranacağını tam olarak anlar
  • İlgili riskleri anlar ve üstlenmeye isteklidir
• Adını PR’a koymak, “okudum ve ne yaptığını anlıyorum” demektir; mühendislik sürecinin referans noktası budur

Muhakeme ölçütü: turnusol testi

• Basit test: “Bu PR ile bağlantılı bir production incident’ını sahiplenmek bana rahat gelir mi?”
• PR açmadan önce kendine sorulması gereken üç soru
  • Bu kod ne yapıyor? Rollout sonrası nasıl davranıyor?
  • Production’a ya da müşterilere ne tür olumsuz etkileri olabilir?
  • Bu kodla ilişkili bir incident’ı sahiplenmek bana rahat gelir mi?
• Cevap “evet” ise AI kullanılmıştır ve dağıtıma çıkabilir; “hayır” ise hâlâ yapılması gereken işler vardır

Çözüm: production’ı korumak için üç ilke

• Kendinden yöneten dağıtımlar (Self-driving deployments): Tüm değişiklikler gated pipeline üzerinden kademeli olarak rollout edilir; canary dağıtım performans düşerse otomatik rollback yapar
  • Mühendisin dashboard izlemeye dayanmasına bağlı kalınmaz
  • Sorun çıkarsa tüm trafikte değil, yalnızca trafiğin bir bölümünde izole edilerek ele alınır
• Sürekli doğrulama (Continuous validation): Sadece dağıtım anında değil, altyapının kendisi sürekli test edilir
  • Yük testleri, chaos deneyleri ve felaket kurtarma tatbikatları sürekli çalıştırılır
  • Vercel’in geçen yaz production’da prova ettiği veritabanı failover sürecinin, gerçek Azure arızası yaşandığında müşteriler üzerinde hiçbir etki yaratmamasının nedeni buydu
• Çalıştırılabilir guardrail’ler (Executable guardrails): Operasyonel bilgiyi dokümanlar yerine çalıştırılabilir araçlara kodlamak
  • safe-rollout becerisi, feature flag’in nasıl çalıştığını anlatan bir Notion sayfası değil; flag’i bağlayan, rollback koşulları içeren bir rollout planı oluşturan ve beklenen davranışın nasıl doğrulanacağını belirten bir araçtır
  • Guardrail’ler çalıştırılabilir olduğunda, ajanlar bunlara otonom biçimde uyabilir ve insanların bunları ezberlemesi gerekmez

Vercel’in fiilen yatırım yaptığı alanlar

• Dağıtım pipeline’ının her aşamasında runtime doğrulaması uygulayan ortak altyapı guardrail’lerini güçlendirmek
• Özellikle feature flag ile ilgili PR aşaması statik kontrollerini güçlendirmek
• Staging ortamında production yansıtmalı uçtan uca testleri devreye almak
• Production’da sistem değişmezlerini sürekli doğrulayan salt okunur ajanlar işletmek ve üretici ajanların varsayımlarını denetleyen uzman ajanlardan yararlanmak
• Platform genelinde risk artışı olup olmadığını anlamak için hatalı commit başına üretime kaçan hata oranı gibi metrikler kullanmak

Sonuç: Rekabet avantajı muhakemesi olan mühendiste

• Uygulama (implementation) bollaştı; artık kıt kaynak, neyin güvenle dağıtıma çıkarılabileceğine dair muhakeme
• Düşük kaliteli kodun düşük kaliteli göründüğü dönem bitti; AI araçları daha da güçlenecek, diff’ler büyüyecek ve çıktılara körü körüne güvenme cazibesi artacak
• Hedef, her değişikliğe olağanüstü bir katılık uygulanan bir dünya değil; altyapının kendisinin katı olduğu bir dünya — hızlı dağıtımın varsayılan olarak güvenli olduğu bir ortam