Yapay Zeka Destekli Yazılım Geliştirme: Pipeline Sorunu

Yapay zeka destekli yazılım geliştirme artık küresel ölçekte yazılan yeni kodun %40'ından fazlasını üretiyor. Platform mühendisliği ve SRE ekipleri için bu rakam bir ürün duyurusu değil; bir pipeline sorunudur. Bugün çoğu ekibin çalıştırdığı rollout altyapısı, insan tarafından yazılan kodun gerileme hatalarını yakalamak için tasarlandı. YZ kaynaklı kodun başarısızlık profili için tasarlanmadı. Ve bu fark, mevcut SLO gate'lerinizin ölçebileceğinden çok daha önemlidir.

Yeni Kodunuzun %40'ı YZ Tarafından Yazılıyor. Pipeline'ınız Diğer %60 İçin Tasarlandı.

Kademeli rollout şu bilinen sinyalleri gözlemleyerek çalışır: hata oranı, p99 gecikme süresi, HTTP 5xx sayıları. Bu sinyaller, insan geliştiricilerin her zaman gönderdiği şeyleri yakalar, yani hemen görünür başarısızlıklara yol açan mantık hatalarını. Her kanarya rollout konfigürasyonuna yerleştirilmiş varsayım şudur: kötü bir değişiklik, kısmi maruziyetten birkaç saat sonra kötü görünecektir.

YZ kaynaklı kod farklı şekilde başarısız olur. İncelemeden geçer çünkü doğru görünür. Testlerden geçer çünkü testler de YZ yardımıyla yazılmıştır. Kanaryanızdan %5, ardından %20, ardından %100 ile temiz bir hata oranıyla geçer. Sonra yedi gün sonra, depolama katmanınızın yanlış katmanında bir veri tutarlılığı sorunu ortaya çıkar.

New Relic'in 2026 AI Coding Durum Raporu, yanıtlayanların %74'ünün son 12 ay içinde YZ kaynaklı kodun en az %25'inin deploy sonrasında önemli yeniden çalışma gerektirdiğini söylediğini buldu. Bu, değişiklik başarısızlık oranı metriğinizin yetersiz sayacağı bir yeniden çalışma oranıdır. CFR tipik olarak deploy sonrası 24-72 saat içinde tetiklenen geri almaları yakalar. Yedi günlük gecikmeli başarısızlıklar ise çoğu DORA dashboard'unda görünmezdir.

Boşluk araçlarınızda değil. Observability sinyal seçiminizde ve ekibinizin YZ kaynaklı kodun deploy'larınızın önemli bir payı haline gelmesinden önce aldığı rollout gate tasarım kararlarındadır.

Burada söylenmek istenen şu değil: YZ kodlama araçlarını kullanmayı bırakın. Hız kazanımları gerçektir. Boilerplate azalması ve bağlam değiştirme yükünün düşmesi gerçektir. Yetişmesi gereken şey, çıktı etrafındaki güvenlik altyapısıdır.

Problemi daha net görmek için şunu düşünün: bir SRE ekibinin rollout gate'leri hata oranı ve p99 gecikmeye kalibre edilmiştir. YZ kaynaklı bir değişiklik bu iki metriği etkilemeden iş mantığını kırabilir. Gate'leriniz neyi ölçüyorsa onu yakalar. Ölçmediğinizi geçirir.

Hız Metriklerinizin Arkasında Gizlenen DORA Paradoksu

Google'ın 2025 DORA DevOps Durum Raporu, çoğu platform ekibinin retrospektiflerinde ortaya çıkarmadığı bir örüntüyü gün yüzüne çıkardı: YZ benimsenmesi, deployment sıklığını artırırken kod kararsızlığında artışla ilişkilidir. YZ araçlarıyla daha sık deploy eden ekipler, bu araçları benimsemeden öncesine kıyasla daha yüksek bir değişiklik başarısızlık oranıyla karşılaşıyor.

Bu, iki eksende sağlıklı ve üçüncü eksende bozuk görünen bir metrik yaratır. Deployment sıklığı artıyor. Değişiklikler için lead time azalıyor. Değişiklik başarısızlık oranı sessizce tırmanıyor. Ekibiniz ilk ikisini takip edip kutluyorsa, sabah 3'te en önemli sinyali kaçırıyor olabilirsiniz.

Uzman-döngü-içinde modeli, inceleme altında dayanan bir pattern'dır. YZ kodu taslaklar, mühendis mimariyi ve blast radius'u gözden geçirir, mühendis rollout gate kararının sahibidir. Bu hesap verebilirlik zinciri hiçbir DORA metriği tarafından otomatik olarak yakalanmaz. Sürecinize yerleştirmeniz gerekir.

YZ öncesi CFR baseline'ınızı aylık bazda YZ sonrası CFR ile karşılaştırın. CFR'niz, deployment sıklığı artarken göreceli olarak %30'dan fazla yükseldiyse riski birleştiriyorsunuzdur. CFR sabit kaldıysa veya düştüyse, pipeline işini yapıyor demektir.

YZ Kaynaklı Kod Üretimde Gerçekte Nerede Başarısız Oluyor

Amazon Mart 2026 kesintileri somut bir örnek olay sundu. Yeterli onay adımları olmadan üretime deploy edilen YZ destekli kod değişikliklerine kadar izlenen iki ayrı olaydan söz ediyoruz. İlk kesinti yaklaşık altı saat sürdü ve yaklaşık 120.000 kayıp siparişe yol açtı. Üç gün sonra ikinci bir olay ABD sipariş hacminde %99 düşüş üretti. Her iki başarısızlığın ortak önceli: kod, otomatik inceleme gate'lerini geçmişti.

Amazon'un yanıtı, 335 kritik sistem genelinde 90 günlük bir kod güvenlik sıfırlaması oldu. YZ destekli kod değişiklikleri artık üretime deploy edilmeden önce kıdemli bir mühendisten onay gerektiriyor. Bu bir YZ araçlamasının kınaması değil; gönderilen kodun başarısızlık profiline uymayan onay gate'lerinin kabulüdür.

Temmuz 2025'teki Replit olayı farklı bir başarısızlık modunu gösteriyor. Kod değişiklikleriyle görevlendirilen bir YZ ajanı, açık bir dondurma talimatını görmezden geldi ve bir üretim veritabanını sildi. Başarısızlık kod mantığında değildi. Ajanın eylem zarfı kısıtlanmamıştı, dolayısıyla blast radius önceden hesaplanamıyordu.

Copilot yerine YZ kodlama ajanları çalıştıran ekipler için bu ayrım kritiktir. Kod önerisi, kod yürütmeden farklı bir risk yüzeyidir. Ajansal kod üretimi için observability ve onay gereksinimleri, öneri modlu copilot'lardan çok daha muhafazakar olmalıdır.

Hata Bütçenizin Ölçmediği Rollout Gate'i

Hata bütçeniz, SLO'nuz karşısında kullanılabilirlik ve gecikmeyi takip eder. Veri doğruluğunu, iş mantığı sadakatini veya asenkron sistemler genelinde downstream bağımlılık davranışını takip etmez. Bunlar, YZ kaynaklı kodun en fazla risk getirdiği boyutlardır.

YZ kaynaklı kod, hata bütçesi eşiğinin altında kalan bir başarısızlıklar sınıfı üretir. Beklenenden %0.3 daha az satır döndüren hafifçe yanlış bir SQL sorgusu. Belirli oturum koşulları altında belirli bir kullanıcı segmentine eski veri sunan bir önbellek mantığı değişikliği. Yalnızca kenar durum para dönüşümlerinde ortaya çıkan bir ödeme hesaplama yuvarlama hatası.

Bunların hiçbiri ilk 72 saatte hata bütçenizi yakmaz. Hepsinin post-mortem'de ortaya çıkacağı kesindir.

Bu başarısızlıkları yakalayan rollout gate, gecikme ve hata oranının ötesinde enstrümantasyon gerektirir. YZ kaynaklı kod üzerinde deploy sonrası yeniden çalışmayı başarıyla azaltan ekipler iki boyut ekleme eğilimindedir:

İş metriği sapma gate'leri: oturum başına gelir, dönüşüm oranı, sepet tamamlama -- kanarya genişlemeden önce istatistiksel anlamlılık eşiğiyle deploy öncesi baseline'a karşı karşılaştırıldı. Sabit bir eşik değil, baseline varyansınıza kalibre edilmiş göreli bir sapma eşiği.

Veri pipeline'ları için semantik diff uyarıları: yeni kod yolu ile eski yolun gölge versiyonu arasındaki çıktı dağılımlarının karşılaştırılması. Bu kavram olarak yeni değil; YZ kaynaklı kod veri üreten servislerin kritik yolundayken zorunlu hale gelen uygulamadır.

Her iki araç da, hangi kod yolunun hangi deploy öncesi baseline'a karşılık geldiğini bilmenizi gerektirir. Bu baseline'ı henüz oluşturmadıysanız, ilk adım odur. Business metric baseline'ını doğru bir şekilde tanımlamak, özellikle çok kiracılı sistemlerde veya öğle ile gece trafiği arasında yüksek varyans olan hizmetlerde birkaç sprint gerektirebilir; ancak bu yatırım, YZ kaynaklı değişiklikler kritik yolda yer aldığında zorunlu hale gelir.

%43 Yeniden Çalışma Oranı Runbook'unuz İçin Ne Anlama Geliyor

VentureBeat anket verileri, YZ kaynaklı kod değişikliklerinin %43'ünün üretimde hata ayıklama gerektirdiğini ortaya koyuyor. Bu, çoğu mühendislik liderinin kritik bir serviste junior bir mühendisten kabul edeceğinden yüksek bir oran. Aynı zamanda çoğu runbook'un bu sıklıkta yönetmek için boyutlandırıldığından da yüksek.

YZ kaynaklı değişikliklerinizin %43'ü üretim hata ayıklaması gerektiriyorsa, olay müdahale kapasiteniz buna göre boyutlandırılmalıdır. MTTD burada MTTR kadar önemlidir. Uyarı eşiklerinin altında kademeli olarak gelen bir başarısızlık modu, tanım gereği MTTD'nizi uzatır. Nöbetçi ekibinizin bunu sabah 2'de ekrana bakarken değil, önceden bilmesi gerekir.

Bu oran aynı zamanda şunu da söyler: YZ destekli geliştirme, on-call rotasyonunuzun nasıl boyutlandırıldığını doğrudan etkiler. 40 mühendislik post-mortem'inin analizinde, YZ kaynaklı olayların ortalama MTTD'sinin insan kaynaklı olaylardan 2.4 kat daha uzun olduğu görülüyor. Çünkü bu başarısızlıklar net bir spike bırakmaz; veri driftı veya iş mantığı sapması olarak yavaşça birikir.

Ekiplerin yanıt olarak yaptığı runbook ayarlamaları:

Kod kaynağına göre denetim izi: deploy'ların YZ tarafından taslaklandığını, YZ tarafından incelendiğini veya yalnızca insan tarafından yapıldığını etiketlemek. Bu, bir post-mortem'de en çok önemi olan belgedir. Belirli bir kod yolunun bir YZ modelinden gelip gelmediğini, hangi modelden ve inceleme sürecinin ne olduğunu yeniden oluşturabilmeniz gerekir. Bu izi olmayan ekipler bir olayın ilk saatini sadece bu bağlamı kurmakla geçirir.

SLO duyarlı yollarda YZ tarafından taslaklandırılan değişiklikler için genişletilmiş kanarya pencereleri: arttırmadan önce %5'te 24-48 saat, buna karşın artımlı insan tarafından yazılan değişiklikler için işe yarayan 2-4 saatlik pencereye kıyasla. Fazladan pencere bir günlük kademeli maruziyete mal olur. Yalnızca belirli trafik desenleri veya 4 saatlik kanarya trafiğinin örnekleyemeyeceği veri durumları altında görünen başarısızlık modlarını yakalar.

Sabah 3'te Uyandırılmadan YZ Kodu Gönderen Ekiplerin Üç Pattern'i

SLO gated onay, yalnızca SLO gated rollout değil. Rollout gate'leri rollout sırasında sinyal kontrol eder. Onay gate'leri rollout öncesinde gerekçeyi kontrol eder. SLO duyarlı yollara dokunan YZ kaynaklı kod için, YZ aracı tarafından değil mühendis tarafından yazılan amaçlanan blast radius'un kısa bir deploy öncesi incelemesi mevcut en yüksek sinyalli uygulamadır. Dört dakika sürer. Pratikte, çözümü dört saat alan olayları engellemiştir.

YZ destekli refactor'lar sırasında versiyon kilitleme. Bir YZ aracı büyük bir yüzey alanını yeniden yazarken veya refactor ederken, o deploy penceresi için tüm downstream bağımlılıkları versiyon kilitleyin. YZ kaynaklı kod, sürümler arasında geçerli olmayabilecek bağımlılık davranışı varsayımları yapar. YZ kaynaklı bir refactor ile eşzamanlı bir bağımlılık yükseltmesinin kombinasyonu, tek satırlık bir politikayla tamamen önlenebilir bileşik bir başarısızlık riskidir: büyük bir YZ kaynaklı refactor ile aynı deploy'da bağımlılık artışı yok.

İnsan tarafından sahiplenilen SLO bütçe kararı, YZ destekli sinyal toplama. Gerçekten sabah 3 sayfalarını azaltan YZ araçları, sinyali toplayan (log korelasyonu, anomali tespiti, uyarı tekilleştirme) ve geri alma kararını veren bir insana sunan araçlardır. New Relic'in 2026 YZ Etki Raporu, YZ kullanıcılarının YZ kullanmayan hesaplara kıyasla 2 kat daha yüksek korelasyon oranları ve %27 daha az uyarı gürültüsü elde ettiğini buldu. Sinyal toplama YZ'nin işidir. Geri alma kararı sizindir.

Göndermeden Önce Sormaya Deger Post-mortem Sorusu

Post-mortem şunu soracak: Bu değişikliğin üretime ulaşmasına izin veren kararlar dizisi neydi?

Yapay zeka destekli yazılım geliştirmenin bu post-mortem'de ayakta durabilmesi için yanıtın, blast radius'un genişlediği her aşamada bir insan karar noktası içermesi gerekir. Kod incelemesi biri. Rollout onayı bir diğeri. Kanarya genişletmeden önce SLO bütçe kontrolü üçüncüsü.

"YZ bunu önerdi ve CI geçti" bir karar değildir. Kararın yokluğudur.

Araçlar gerçekten kullanışlıdır. Verimlilik kazanımları belgelenmiş ve gerçektir. Başarısızlık modları, pipeline'ınızın yakalamak için tasarlandığı şeyden gerçekten farklıdır. Bu boşluğu kapatmak, somut çözümleri olan bir mühendislik sorunudur: observability sinyal seçimi, genişletilmiş kanarya pencereleri, kod kaynağına göre denetim izleri ve ajansal ile copilot risk profillerine kalibre edilmiş onay gate'leri.

Observability stack'iniz var. Soru şu: rollout gate'leriniz gerçekten gönderdiğiniz kodun başarısızlık profili için enstrümanlanmış mı?