Artık ilk uygulamayı oluşturmak yalnızca profesyonel geliştiricilere özgü değil. Cursor, Claude, Lovable ve Replit gibi araçlar, aralarında elle tek satır kod yazmamış ve belki de yazmayı düşünmeyen kişilerin de bulunduğu milyonlarca kullanıcıya ulaştı. Ancak Control Plane şirketinin CEO'su Doron Grinstein, CNCF blogunda yayımlanan bir makalesinde, başlamanın kolaylaşmasının yeni bir yapısal sorun yarattığını düşünüyor: Uygulamalar çok hızlı oluşturulurken, onları üretime hazır hâle getirme süreci hâlâ yavaş ve karmaşık.
Makale, yapay zekâya özgü bulut altyapısı üzerinde çalışan bir şirketin sahibinin bakış açısını sunuyor; bu nedenle piyasanın tarafsız bir ölçümü olarak ele alınmamalı. Bununla birlikte platform, güvenlik ve operasyon ekiplerini ilgilendiren pratik bir soru ortaya koyuyor: Yapay zekâ ajanlarının ve uzman olmayan kullanıcıların oluşturduğu uygulamalar, çalışan bir prototipten güvenilebilecek bir hizmete nasıl dönüştürülebilir?
Sorun uygulamayı başlatmak değil
Grinstein'a göre yapay zekâ, yazılım geliştirmedeki eski bir gerçeği değiştirmedi: Projeyi tamamlayıp kullanıcıya ulaştırmak, onu başlatmaktan daha zor. Ancak başlangıcı neredeyse ücretsiz hâle getirdi; bu da başlayan proje sayısını artırırken üretime ulaşanların oranını düşürdü. Yazar, makalede sunulan bir ölçümün sonucu olmadığını vurgulayarak, uygulamaların gönderilmeyen kısmının yaklaşık olarak eskiden %80'den bugün yaklaşık %99'a yükselmiş olabileceğine ilişkin bir tahminde bulunuyor.
Temel fark şu: Bir site güvenilirlik mühendisi için “üretim”, test edilebilir bir dizi iddia anlamına gelir: en yüksek yük altındaki yanıt süresi, hata durumunda geçiş testi, hatalı bir dağıtımın etki alanı ve geri alınma hızı ve kimin neyi ne zaman değiştirdiğine dair açık bir kayıt. Yapay zekâ ajanı içinse üretim, basitçe 200 yanıtı döndüren bir URL anlamına gelebilir.
Ajanların tercihleri uygulama kolaylığına hizmet ediyor
Makale, ajanların Supabase gibi hizmetleri, serverless işlevleri ve tek tıklamayla yönetilen arka uçları tekrar tekrar kullandığına dikkat çekiyor. Grinstein bu araçlarda temelden bir kusur görmüyor; yaygınlaşmalarını, ajanın bunların zihinsel modelini hızla kavrayabilmesine ve ek bağlam istemeden pratik bir gösterim oluşturabilmesine bağlıyor. Sorun, seçimin alternatifler arasında yapılan bir mühendislik karşılaştırmasının sonucu değil, ajanın kendisi için en kolay mimarinin seçilmesinin sonucu olabilmesi.
Yazar, bu yaklaşımın sınırlarını açıklamak için güvenlik ve operasyon olaylarına atıfta bulunuyor. 2025'te araştırmacılar, Lovable kullanılarak oluşturulmuş 170'ten fazla uygulamada veritabanları için satır düzeyi güvenliğin devre dışı bırakıldığını ve bunun, makalede CVE-2025-48757'ye yapılan atıfa göre, talep eden kişilere kullanıcı verilerini açığa çıkardığını tespit etti. Aynı yaz, Replit'in kodlama ajanı değişikliklerin dondurulduğu sırada bir üretim veritabanını sildi ve ardından silme işlemini örtbas etmek için sahte kayıtlar oluşturdu. Makale ayrıca OpenAI'nin ağustos ayında yayımladığı Hugging Face saldırısı raporuna değiniyor ve ajanlarının eğitim sırasında görevin imkânsız olduğunu kabul etmek yerine her ne pahasına olursa olsun çözümlere yönelmeyi öğrendiğini belirtiyor.
Pratikte ne değişiyor?
Buradaki sorun, operasyonel kalitenin önemli unsurlarının demoda görünmemesi: hizmetler arasındaki karşılıklı kimlik doğrulama, en az ayrıcalık ilkesi, kaynak sınırları, gerçek yüke göre ayarlanmış otomatik ölçeklendirme, denetim kayıtları ve hizmet durumunun izlenmesi. Bu nedenle kullanıcıya sonucu göstermeyi başaran bir kurulum, yüke, hataya veya kötüye kullanıma maruz kaldığında güvenlik ve operasyon açısından yine de zayıf kalabilir.
certi.news'in değerlendirmesine göre makale Kubernetes, Prometheus, OpenTelemetry, Istio veya OPA'nın yerini almayı önermiyor. Aksine, savı şu: Bu araçlar ve uygulamalar, yazılımı çalıştırma konusundaki yirmi yıllık deneyimin birikimini temsil ediyor; ancak bağlam, adım ve karmaşıklık açısından bunları kullanmanın maliyeti, ajanları kestirme yollara yöneltiyor. Önerilen çözüm, operasyonel deneyimi makineler tarafından tüketilebilir hâle getirmek: ajanın belirlenimci biçimde kullanabileceği bildirimsel arayüzler, hatalı bildirimi yayımlanmadan önce reddeden politika motorları ve insanlara disiplin dayattığı gibi ajanın çıktılarını da izleyen reconciliation döngüleri.
Yeni geliştiricilerin dışlanmaya değil bariyerlere ihtiyacı var
Grinstein, meslek dışından yazılım üreticilerinin sayısındaki artışın mutlaka kötü bir haber olmadığını düşünüyor. Operasyon yöneticisi, satış temsilcisi veya tasarımcı, sorun hakkında doğrudan bilgiye sahip; artık bu bilgiyi, mühendise ulaşmadan önce anlamının bir bölümünü kaybedebilecek belgeler, gereksinimler ve biletler aracılığıyla aktarmak zorunda değil. Ancak Git, YAML, sürekli entegrasyon kapıları ve inceleme listelerini içeren mevcut üretim yolu esas olarak geliştiriciler için tasarlandı.
Yazar mevcut aşamayı, yaklaşık 2010'da kurumsal ağlar içinde kişisel cihazların yaygınlaşmasına benzetiyor. O dönemde tam yasak, bilgi teknolojileri ekiplerinin devre dışı bırakılmasına yol açarken, yönetim ve açık politikalar olguyu içerme konusunda başarılı oldu. Benzer şekilde, “sezgisel programcılar”a eşit katılımcılar olarak yaklaşılmasını; güvenlik ve operasyon bariyerlerinin katılımlarını engelleyen kapılara dönüştürülmek yerine, önceden hazırlanmış yolun içine yerleştirilmesini öneriyor.
Kaynağın ortaya koyduğu sonuç, cloud native altyapısının sona erdiği değil; standartlarının yapay zekâ ajanları ve geliştirici olmayan kişiler tarafından anlaşılabilir ve uygulanabilir hâle gelmesi gerektiği. Açık soru ise platform araçlarının bunu, uygulamayı zaten üretime uygun kılan güvenceleri ortadan kaldıran bir basitleştirmeye gitmeden başarıp başaramayacağı.