YI'nın Altyapı Kararlarını Alamadığı Gerçeği ve Çözüm Yolu

YI'nın Altyapı Kararlarını Alamadığı Gerçeği ve Çözüm Yolu

May 25, 2026 infrastructure-as-code terraform ai-development devops cloud-architecture application-design vibe-coding

Neden Yapay Zeka İnfrastruktur Kararlarını Alamaz (ve Bunu Nasıl Çözebileceğin)

Muhtemelen hype'ları duymuşsundur: "Yapay zekaya kodunu yazdır." Ve açıkçası? Uygulama mantığı için harika çalışıyor. Route'lar, veritabanı sorguları, yardımcı fonksiyonlar—bu alanlarda dil modelleri gerçekten parlıyor. Ama kimsenin yeterince konuşmadığı kritik bir kör nokta var.

Bir Terraform dosyasını yapay zekaya verdiğin andan itibaren her şey yıkılmaya başlıyor.

İnfrastruktur Bağlamının Sorunu

Rahatsız edici gerçek şu: yapay zeka modelleri sözdiziminde mükemmel. Bütün gün geçerli HCL yazarlar. Sorun kod değil—kodun arkasındaki mantık.

Basit bir örnek düşün: yapay zeka ajanından mesajlaşma sisteminize yeni bir event eklemesini istiyorsun. Belki SNS üzerinden yayınlanması ve SQS'te sıraya alınması gereken bir order-created event'i. Model itaatsizce üretir:

  • SNS topic'i
  • Dead-letter queue'ya sahip SQS queue'su
  • Topic subscription'ı
  • Yayın yapan servise kapsamlı IAM politikası

Iyi görünüyor, değil mi? Ama o konfigürasyondaki her sayı ve kapsam kararı tamamen taslak. Visibility timeout 60 saniye mi yoksa 600 saniye mi olmalı? IAM politikası belirli bir bucket'a mı kapsamlı olmalı yoksa wildcard mi kullanmalı? Message retention 14 gün mi yoksa varsayılan mı olmalı?

Yapay zeka modeli eğitim verilerinde "doğru görünen" değerleri seçer, senin gerçek iş yükünün, ekibinin operasyonel alışkanlıklarının veya geçen çeyrekte birinin replay window'dan yediği dersin hiçbir anlayışı olmadan.

Kod İncelemesinin Gizli Maliyeti

İşte gerçekten acı verici kısım: kod inceleme yükü küçülmüyor. Patlamaya başlıyor.

Uygulama kodu incelemek nispeten basit. Mantığı kontrol ediyorsun, edge case'leri test ediyorsun, belki güvenlik sorunlarını denetliyorsun. Ama otomatik üretilmiş altyapıyı incelemek? Şimdi şunu kontrol etmek gerekiyor:

  • HCL sözdiziminin AWS IAM semantiği ile uygunluğu
  • Önerilen kaynakların mevcut pipeline mimarisiyle uygunluğu
  • Ekip kuralları ve asla yazılı hale getirilmemiş örtülü bilgi
  • Tüketen servisin role'ünün bu hesapta var olup olmadığı

İnceleyici insan derleyici haline geliyor, yapay zekanın göremediği tüm bağlamı taşıyor. Ve yanlış bir şey yayınlandığında—yanlış timeout, yanlış kapsam, yanlış retention politikası—saat 3'te senin beeper'ı çalıyor, CI pipeline'ının değil.

Asıl Sorun: Ayrılmış Sorumluluklar

Açık aslında araç sorunları değil. Özel modüller, hizmet katalogları ve politika validatörleri sonsuz sayıda yapay zeka ajanının çevresine ekleyebilirsin. Hiçbiri açığı kapamazsa, çünkü açığın kökü mimaridedir.

Uygulama kodunun ve altyapı kodunun ayrı repo'larda ayrı inceleme döngüleri vardır. Yapay zeka altyapı kararlarını gerçekten destekleyeceği uygulama mantığından ayrı şekilde alır. O kararları doğru almak için gereken bağlam düzenlenilmekte olan dosyada basitçe mevcut değil.

Daha fazla araç sadece kırık bir sisteme daha fazla bürokrasi ekler.

Daha İyi Bir Yaklaşım: Altyapıyı Derleme Zamanı Sorunu Olarak Görmek

Ya altyapı hiç ayrı bir sorun olmasaydı?

Bunu düşün: uygulama kodu yazıp altyapıya kısaca işaret etmek yerine, altyapını tipi belirtilmiş uygulama kodunun parçası olarak açıklasaydın. Framework geri kalanını halleder—provisioning, IAM scoping, dead-letter queue'lar, subscriptionlar, hepsi tipi belirtilmiş kodun gerçekten ihtiyaç duyduğu şeylerden türetilir.

Şimdi pub/sub topic tanımlaması şöyle görünür:

export const orderCreated = new Topic<OrderCreatedEvent>("order-created", {
  deliveryGuarantee: "at-least-once",
});

Ayrı HCL dosyası yok. Elle denetlenmesi gereken IAM politikası yok. Timeout değerlerini tahmin etme yok. Framework tam olarak ne ihtiyaç duyduğunu biliyor çünkü onu kullanan ve üreten uygulama kodunu görebiliyor. Tehlikeli altyapı kararları "bir yapay zeka ajanının kör yere yaptığı bir şey" kategorisinden "framework'ün bildirilen tiplerden belirleyici şekilde hesapladığı bir şey" kategorisine geçer.

PR'ın artık tek bir TypeScript diff'i, TypeScript diff'i artı elli satır Terraform artı manuel olarak doğrulaması gereken politikalar yerine.

Bu Neden "Vibe Coding"in İçin Önemli

Bu da neden "altyapınızı vibe coding'e tabi tutmak" uygulama vibe coding'ine göre fundamentally farklı bir mimari gerektirir. Kod tipi belirtildiğinde, test edildiğinde ve izole edildiğinde yapay zekaya güvenle uygulama mantığını devredebilirsin. Ama altyapı kararları sisteminizin başka yerlerinde yaşayan bağlam gerektirir.

Çözüm daha iyi yapay zeka promptları veya daha sofistike araçlar değil. İnsan ve altyapı arasındaki ek noktayı tamamen kaldırmak. Framework altyapıyı onun yanında değil kodundan türeterek derlediğinde, tehlikeli kararlar yapay zeka ajanının elinden çıkıyor—ve gece yarısı insan derleyici oynayan kod inceleyicilerin elinden de çıkıyor.

Bu, güvenle vibe coding'e tabi tutabileceğin altyapı.

Read in other languages:

RU BG EL CS UZ SV FI RO PT PL NB NL HU IT FR ES DE DA ZH-HANS EN