Kod Üretmek Kolaylaştı, Peki Ya Canlıya Almak? Yapay Zeka Çağında Platform Mühendisliği

Son bir iki yıldır nereye baksak aynı manşetler: "Yapay zeka artık tek satır komutla mikroservis yazıyor", "Kodlama bitti mi?", "DevOps ve altyapı ekiplerine gerek kalmadı mı?"

Açıkçası sahada olan, gecenin bir yarısı nöbette alarm karşılayan ya da yüzlerce repository’nin bağımlılıklarını yöneten hiçbir mühendis bu pembe anlatıya bütünüyle inanmıyor. Çünkü kod yazmak meselenin yalnızca küçük bir parçası; o kodu güvenli, ölçeklenebilir ve regülasyonlara uygun şekilde prodüksiyona çıkarmak bambaşka bir zanaat.

Geçtiğimiz günlerde InfoQ'da yayınlanan çok değerli bir paneli keyifle inceledim. Masada Shine'dan Davide de Paolis, Alman bankacılık devi DKB'den Stephane Di Cesare, açık kaynak Kubernetes ekosisteminden Camila Macedo ve Harness CTO'su Stephen Cihak gibi sektörün mutfağından gelen isimler vardı. Tartıştıkları ana soru şuydu: Yapay zeka, kurum içi platform mühendisliğini (Platform Engineering) nasıl dönüştürüyor?

Konuşulanları dinlerken altını çizdiğim öyle tespitler oldu ki, altyapı dünyasının nereye doğru evrildiğini bir de benim gözümden, sohbet havasında birlikte değerlendirelim istedim.

1. Darboğaz Yer Değiştirdi: "İç Döngü" Hızlandı, "Dış Döngü" Tıkandı

Stephen Cihak panelde çok kritik bir noktaya parmak basıyor: Eskiden geliştiricilerin bir özelliği yazıp test etmesi günler sürerdi. Şirketler haftada bir, hatta ayda bir sürüm çıkardı. Şimdi ise yapay zeka asistanları sayesinde kod saniyeler içinde yazılabiliyor.

İyi ama o kod yazıldıktan sonra ne oluyor?

Güvenlik taramalarından geçecek mi?
Doğru IAM rollerine sahip mi?
Altyapıyı ayağa kaldıracak Terraform modülü kurumsal standartlara uyuyor mu?
Test ortamı dakikalar içinde sağlanabiliyor mu?

İşte yazılım dünyasında "Inner Loop" dediğimiz kod yazma kısmı makine hızına ulaştı; fakat "Outer Loop" dediğimiz derleme, test, güvenlik taraması ve canlıya alma döngüsü hâlâ insan hızında (hatta bazen haftalık onay toplantılarıyla) çalışıyor. Stephen tam olarak şunu söylüyor:

"Yöneticiler ekiplere 'Yapay zeka araçlarına bu kadar yatırım yaptık, kodlar neden canlıya daha hızlı çıkmıyor?' diye sormaya başladı. Çünkü darboğaz artık kod yazmak değil; o kodu prodüksiyona taşıyacak otoyolun darlığı."

Eğer arkada güçlü bir İç Geliştirici Platformu (Internal Developer Platform - IDP) yoksa, yapay zekanın ürettiği devasa kod yığını güvenlik ve operasyon kapısında birikip sistemi kilitliyor.

2. Yıllardır İhmal Ettiğimiz O "Arka Bahçe"

Davide de Paolis’in paylaştığı bir tecrübe beni hem güldürdü hem de derinden etkiledi. Platform ekiplerinin backlog'unda her zaman "önemli ama asla acil olmayan" işler vardır:

Mimari diyagramları güncellemek,
Modüller için kapsamlı dokümantasyon yazmak,
Tekrarlayan IaC (Infrastructure as Code) şablonlarını temizlemek,
Başlangıç projeleri (boilerplate) oluşturmak.

Proje yöneticilerinin acil özellik baskısı yüzünden bu işler genelde halının altına süpürülür. Davide, yapay zekayı tam da bu ihmal edilmiş teknik borçları eritmek için kullandıklarını anlatıyor.

İşin en ironik tarafı ise şu: Biz yıllardır geliştiriciler birbirini anlasın diye düzgün dokümantasyon yazmadık; şimdi yapay zeka ajanları halüsinasyon görmesin, bağlamı kaçırmasın diye oturup kusursuz bilgi bankaları (Knowledge Graph) inşa ediyoruz!

Ajanlar sayesinde dokümantasyon kültürümüzün zorla da olsa çağ atlaması, yazılım tarihindeki en tatlı tezatlardan biri olsa gerek.

3. Platformu Artık Sadece İnsanlar Tüketmiyor: Dahili MCP ve "Doğru Şablon"

Geleneksel bir İç Geliştirici Platformu (örneğin Backstage tabanlı bir portal), insan geliştiricinin girip butona bastığı ve test veritabanı açtığı bir yerdi. Peki ya geliştirici yerine platformu doğrudan bir Yapay Zeka Ajanı tüketmeye başlarsa?

Burada Davide çok akılcı bir mimari çözümden bahsediyor: Geliştiriciye veya onun kullandığı kod ajanına "Git internetten bulduğun rastgele bir Terraform kodunu çalıştır" demek büyük bir felakete davetiye çıkarır. Bunun yerine platform ekibi, şirkete özel dahili MCP (Model Context Protocol) sunucuları ve yetenekleri (skills) tanımlıyor.

Geliştiricinin ajanı AWS üzerinde bir servis ayağa kaldırmak istediğinde, Stack Overflow'dan ya da genel internet havuzundan kod kopyalamıyor; doğrudan platform ekibinin hazırladığı, güvenlik testlerinden geçmiş, onaylı modül reposunu referans alarak çalışıyor.

Böylece geliştirici hız kazanırken, platform ekibi de altyapının kendi belirlediği güvenlik ve mimari standartlarda kaldığından emin oluyor.

4. Korkuluklar ve "Yolun Ortası": Deterministik Olmayan Bir Dünyayı Yönetmek

Yapay zeka modelleri olasılıksaldır (non-deterministic). Yani aynı prompt'u verdiğinizde bazen 5 farklı yaklaşımla kod üretebilir.

Finans ve regülasyon tarafında çalışan DKB’den Stephane Di Cesare ve Camila Macedo bu konuda oldukça temkinli. Stephane çok şık bir benzetme yapıyor:

"Bir arabayı yolun kenarındaki korkuluklara (guardrails) çarpa çarpa süremezsiniz. Önemli olan sadece sınırları çizmek değil, sürücüye yolun tam ortasının neresi olduğunu da açıkça göstermektir."

Platform mühendisliğinin yeni görevi tam olarak bu:

Yolun Ortasını Göstermek (Paved Path): Ajanlara şirket mimarisinin ana omurgasını net API'ler ve net şablonlarla öğretmek.
Korkulukları Dikmek (Guardrails): AWS SCP (Service Control Policies), dinamik sandbox hesapları ve en düşük yetki (least privilege) kurallarıyla donatmak. Ajan hata yapsa bile prodüksiyon veritabanını silemeyeceği ya da açık bir S3 bucket yaratamayacağı sınırları önceden çizmek.

5. Köy Yolu mu, Otoyol mu?

Stephen Cihak'ın paneldeki yol analojisi durumu harika özetliyor:

"Eski iki şeritli köy yollarında en fazla 60 km hızla gidebilirsiniz. Yoldan çıktığınız an şarampole yuvarlanırsınız. Ancak modern bir otoyolda şeritler ayrılmıştır, zemin kusursuzdur ve çok yüksek hızlara güvenle çıkabilirsiniz. İnsanları makine hızında koşturmak istiyorsanız, otoyol gibi sağlam ve regüle edilmiş yapılar inşa etmek zorundasınız."

Eğer altyapınızda hâlâ haftada bir toplanan Değişiklik Onay Kurulları (CAB - Change Advisory Board) varsa, yapay zekanın getirdiği hız sadece ekipler arasındaki sürtünmeyi ve stresi artırır. Geleceğin platform mühendisliği; karar kanıtlarını otomatik toplayan, denetim izlerini (audit trail) arka planda çıkaran ve geliştiriciyi yavaşlatmadan otoyol konforu sunan bir altyapı inşa etmektir.

6. Başarıyı Nasıl Ölçmeliyiz? (Kullanılan Token Sayısı Değil!)

Yöneticilerin en çok merak ettiği soru: "Platform ekibi olarak yapay zekadan gerçekten verim alıyor muyuz?"

Uzmanların ortak kanaati çok net: Başarı, harcanan API token'larıyla veya üretilen satır sayısıyla ölçülemez. Asıl başarı kriterleri şunlar:

Fikirden Canlıya Çıkış Süresi (Lead Time): Bir ekibin yeni bir servisi sıfırdan canlıya taşıması 3 hafta mı sürüyor, yoksa platform şablonlarıyla 1 saate mi indi?
Bilişsel Yük (Cognitive Load): Geliştirici Slack kanallarında "Bu sunucunun loguna nereden bakıyorduk?", "Kubernetes ingress ayarı nasıl yapılıyordu?" diye sürekli destek aramak zorunda kalıyor mu?
Güven ve Psikolojik Rahatlık: Geliştiriciler platformu "sürekli engel çıkaran bir denetçi" olarak mı görüyor, yoksa "hata yapmalarını engelleyen bir güvenlik ağı" olarak mı benimsiyor?

Benim Değerlendirmem: Yapay Zeka Rolümüzü Çalmıyor, Angaryayı Alıyor

Panelde Camila'nın söylediği gibi: Yıllar önce derleyiciler (compilers) çıktığında da "Artık Assembly yazmayacağız, yazılımcılık bitiyor mu?" endişesi vardı. Derleyiciler işimizi elimizden almadı; bizi mikro işlemci komutları sayma angaryasından kurtarıp daha büyük problemler çözmeye odakladı.

Bugün yapay zeka ile platform mühendisliğinin yaşadığı dönüşüm de farksız.

Konfigürasyon yazmak, log taramak veya standart CI/CD dosyalarını kopyala-yapıştır yapmak artık yapay zekaya devredilebilecek operasyonel yükler. Bir platform mühendisinin asıl değeri ise sistemin dayanıklılığını kurgulamak, geliştirici deneyimini (DevEx) kusursuzlaştırmak ve şirket içindeki mühendislerin güvenle basıp hızlanabileceği otoyolları tasarlamaktır.

Kısacası; yapay zeka çağında platform mühendisliği ölmüyor, aksine hiç olmadığı kadar merkezi ve stratejik bir konuma yerleşiyor.