LLM kullanmamız gerektiğini söylediğimizde, kastettiğimiz şey sadece ondan bizim için Kubernetes YAML dosyaları yazmasını istemek ya da sorunlu bir pod’un log’larını kopyalayıp problemin nerede olduğunu sormak değil.

Bunlar faydalı işler ama hâlâ bir chat ortamında LLM’i tek seferlik kullanmaktan ibaret. Bilgileri biz topluyoruz, context’i model’e biz veriyoruz ve ardından aldığımız çıktıyı sisteme yine biz aktarıyoruz. Yani LLM ile sistem arasındaki bütün iletişim hâlâ manuel olarak ve bizim üzerimizden gerçekleşiyor.

Gitmemiz gereken yönün iyi bir örneği, Iron Man filmindeki JARVIS.

İlk uçuş testinden sonra Tony, zırhın yüksek irtifadaki sorunlarını anlatıyor ve altın-titanyum alaşımı kullanılmasını öneriyor. JARVIS yeni tasarımı render ediyor ama sonuç tamamen altın renginde çıkıyor. Tony biraz kırmızı eklemesini istiyor. Yeni versiyon gösteriliyor ve Tony onayladıktan sonra laboratuvar zırhı üretip monte etmeye başlıyor; Tony ise oradan ayrılıyor.

Bu sahnedeki önemli nokta zırhın rengi değil. JARVIS sadece zırhın tasarımı hakkında öneri veren bir chatbot değil. Test sonuçlarına, tasarım model’ine, render yazılımına ve üretim ekipmanlarına erişimi var. Tony amacı ve düzeltmeleri belirliyor, sonucu görüyor ve ardından işi, kendisi sürekli başında durmadan devam edebilen bir sisteme bırakıyor.

LLM kullanımına bakışımız da bu yönde ilerlemeli: Sadece tek seferlik sorulara cevap veren bir tool’dan, gerçek bir workflow’u yürütebilmek için gereken context’e ve tool’lara sahip bir sistem bileşenine dönüşmeli.

Mesela cluster’ın içinde ya da yanında; metrics, logs, traces, events ve deployment geçmişine erişimi olan bir servisimiz olabilir. Bir sorun çıktığında bu bilgileri bir araya getirebilir, son değişiklikleri inceleyebilir, muhtemel nedeni bulabilir ve sonucu bize raporlayabilir.

Sınırlı ve net şekilde tanımlanmış erişimler verirsek bir servisi restart etmek, deployment’ı rollback etmek ya da replica sayısını değiştirmek gibi önceden belirlenmiş bazı işlemleri de yapabilir. Tabii bu tür işlemlerin kayıt altına alınabilir, incelenebilir ve gerektiğinde geri alınabilir olması gerekir.

Bu noktada LLM artık sadece bir soruya cevap veren bir tool değildir; sistemin operasyon döngüsünün bir parçasıdır. Durumu görür, farklı kaynaklardan gelen bilgileri bir araya getirir ve bizim belirlediğimiz sınırlar içinde tepki verir.

OpenChoreo gibi projeler bu yöndeki ilerleyişin örneklerinden biri. OpenChoreo, log’lar, metrics ve servislerin durumu gibi bilgileri agent’lara sunan open-source bir Kubernetes platformu. Böylece agent’lar sorunların nedenini araştırabilir, çözüm önerebilir ve tanımlanmış erişim sınırları içinde bazı sorunları giderebilir.

OpenChoreo’dan bahsetmemin amacı herkesin gidip bu tool’u kurması gerektiğini söylemek değil. Asıl mesele, LLM’leri sadece bir coding agent ya da chat penceresi olarak görmemek. Gerçek değerleri; gerçek context’e, belirli tool’lara ve kontrol edilebilir workflow’lara bağlandıklarında ve sistemin mühendislik yaklaşımıyla tasarlanmış bir parçasına dönüştüklerinde daha da artıyor.