Pipeline Artık CI/CD Değil, Karar Zinciri

Bir önceki yazıda AI-Native SDLC kavramını konuşmuştuk.

Orada temel olarak şunu söylemiştik:

AI destekli yazılım geliştirme ile AI-native yazılım geliştirme aynı şey değildir.

AI destekli geliştirmede geliştirici işi yapar, AI ona yardımcı olur.

AI-native geliştirmede ise yazılım geliştirme süreci baştan düşünülür. AI, otomasyon, kalite kontrolleri, izlenebilirlik ve insan kararları bu sürecin doğal parçaları haline gelir.

Bu yazıda bu fikri biraz daha ileri taşıyalım.

Çünkü AI-native yazılım geliştirme konuşuyorsak, sadece kod yazma biçimimizi değil, pipeline kavramını da yeniden düşünmemiz gerekiyor.

Bugüne kadar pipeline dediğimizde çoğunlukla şunu anladık:

Kod commit edilir.
Build çalışır.
Testler koşar.
Paket hazırlanır.
Deploy edilir.

Bu yapı hâlâ çok değerli.

Ama artık tek başına yeterli değil.

Çünkü AI yazılım geliştirme sürecine daha fazla dahil oldukça, pipeline sadece teknik adımları çalıştıran bir otomasyon hattı olmaktan çıkıyor.

Pipeline artık sadece CI/CD değil.

Pipeline artık bir karar zinciri.

---

Önce şunu net söyleyelim: CI/CD bitmiyor

Başlık biraz iddialı durabilir.

“Pipeline artık CI/CD değil” derken CI/CD’nin bittiğini söylemiyorum.

Tam tersine, CI/CD hâlâ modern yazılım teslimatının en önemli parçalarından biri.

Kodun otomatik entegre edilmesi, testlerin çalışması, paketlerin üretilmesi, ortamlar arasında kontrollü dağıtım yapılması hâlâ çok kritik.

Bunlar olmadan sağlıklı bir yazılım teslimat süreci kurmak zor.

Ama mesele şu:

AI-native dönemde pipeline sadece CI/CD adımlarından ibaret kalamaz.

Çünkü artık pipeline’dan beklediğimiz şey sadece kodu bir ortamdan başka bir ortama taşımak değil.

Pipeline’ın şu sorulara da cevap verebilmesi gerekiyor:

• Bu değişiklik neden yapıldı?
• Hangi gereksinime bağlı?
• Kim veya hangi AI ajanı bu çıktıyı üretti?
• Testler gerçekten yeterli mi?
• Güvenlik riski var mı?
• Mimari kurallara uyuyor mu?
• İnsan onayı gerekiyor mu?
• Canlıya alma riski kabul edilebilir mi?
• Sonradan dönüp baktığımızda ne olduğunu anlayabilecek miyiz?

Klasik CI/CD bu soruların bazılarına cevap verebilir.

Ama tamamına cevap verebilmesi için pipeline’ı daha geniş düşünmemiz gerekiyor.

İşte bu yüzden pipeline artık sadece build-test-deploy akışı değil; kaliteyi, riski, güvenliği, onayı ve teslimat kanıtını yöneten bir karar zinciri haline gelmeli.

---

Klasik pipeline ne yapıyordu?

Klasik pipeline genelde teknik otomasyon etrafında şekillenir.

Bir geliştirici kodu repository’ye gönderir.

Sonra pipeline devreye girer:

• kodu alır,
• bağımlılıkları yükler,
• build alır,
• testleri çalıştırır,
• statik analiz yapabilir,
• paket oluşturur,
• container image üretebilir,
• staging veya production ortamına deploy edebilir.

Bu akış yazılım dünyası için büyük bir adımdı.

Manuel işleri azalttı.
Tekrarlanabilirliği artırdı.
Hataları daha erken yakalamaya yardımcı oldu.
Teslimat hızını artırdı.
Ekiplerin daha disiplinli çalışmasını sağladı.

Ama klasik pipeline çoğu zaman şunu varsayar:

Pipeline’a giren değişiklik zaten anlamlıdır, doğru bağlama sahiptir ve teslimata adaydır.

AI-native dönemde bu varsayım daha riskli hale geliyor.

Çünkü pipeline’a giren değişiklik artık sadece insan tarafından üretilmiş olmayabilir.

AI tarafından üretilmiş olabilir.
Bir ajan tarafından önerilmiş olabilir.
Bir otomasyon tarafından oluşturulmuş olabilir.
Birden fazla AI çıktısının birleşimiyle şekillenmiş olabilir.

Bu durumda pipeline sadece “çalışıyor mu?” diye sormamalı.

Daha fazlasını sormalı.

---

AI geldiğinde pipeline’ın soruları değişir

AI ile üretilen kod çalışabilir.

Ama çalışan kod her zaman doğru kod değildir.

Çalışan kod yanlış problemi çözebilir.
Çalışan kod güvenlik açığı içerebilir.
Çalışan kod mimari sınırları bozabilir.
Çalışan kod bakım maliyetini artırabilir.
Çalışan kod gereksinimle bağlantısız olabilir.
Çalışan kod testlerden geçmiş gibi görünüp gerçekte kritik senaryoları kapsamıyor olabilir.

Bu yüzden AI-native pipeline sadece şu soruyla yetinmemeli:

Build geçti mi?

Bu artık tek başına yeterli değil.

Pipeline şunları da sormalı:

Bu değişiklik doğru problem için mi yapıldı?

İlgili gereksinimle bağlantısı var mı?

AI çıktısı nasıl doğrulandı?

Testler davranışı gerçekten kapsıyor mu?

Güvenlik, mimari ve kalite kontrolleri geçti mi?

İnsan kararı gereken bir nokta var mı?

Bu release sonradan denetlenebilir mi?

İşte pipeline’ın karar zincirine dönüşmesi burada başlıyor.

---

Pipeline karar vermez; kararı güvenilir hale getirir

Burada önemli bir ayrım var.

Pipeline insan yerine tüm kararları veren bir mekanizma olmamalı.

Özellikle kurumsal yazılım geliştirmede bazı kararlar sadece teknik değildir.

Risk kararı vardır.
Kapsam kararı vardır.
Öncelik kararı vardır.
İş etkisi kararı vardır.
Müşteri etkisi kararı vardır.
Canlıya alma kararı vardır.

Bu kararların tamamını otomatikleştirmek her zaman doğru değildir.

Ama pipeline bu kararların daha bilinçli verilmesini sağlayabilir.

Nasıl?

Kanıt üreterek.

Örneğin pipeline şunu söyleyebilir:

• Build başarılı.
• Unit testler geçti.
• Integration testler geçti.
• Security scan temiz.
• Mimari kurallar ihlal edilmedi.
• Kod standardına uygun.
• İlgili gereksinime bağlı.
• Risk seviyesi düşük.
• İnsan onayı gerekli değil.

Ya da tam tersini söyleyebilir:

• Test kapsamı yetersiz.
• Kritik güvenlik uyarısı var.
• Değişiklik mimari sınırı ihlal ediyor.
• İlgili gereksinim bağlantısı yok.
• Production deploy için insan onayı gerekiyor.

Bu durumda pipeline sadece teknik bir iş çalıştırmış olmaz.

Karar için gerekli zemini hazırlar.

Yani pipeline’ın görevi insan yerine karar vermek değildir.

Pipeline’ın görevi, insanın daha doğru karar verebilmesi için güvenilir kanıt üretmektir.

---

AI üretir, sistem doğrular, insan karar verir

Bu seride tekrar eden ana cümle burada da geçerli:

AI üretir.
Sistem doğrular.
İnsan karar verir.

Pipeline bu üçlü dengenin merkezinde durur.

AI bir değişiklik üretir.

Bu değişiklik kod olabilir.
Test olabilir.
Dokümantasyon olabilir.
Konfigürasyon olabilir.
Migration olabilir.
Release notu olabilir.

Sistem bu çıktıyı doğrular.

Test eder.
Taramadan geçirir.
Kurallarla karşılaştırır.
Gereksinimle ilişkilendirir.
Risk seviyesini belirler.
Kanıt üretir.

İnsan ise kritik noktada karar verir.

Canlıya alınsın mı?
Kapsam değişsin mi?
Risk kabul edilsin mi?
İstisna verilsin mi?
Geri alınsın mı?
Beklesin mi?

Bu modelde pipeline sadece deploy yapan bir mekanizma değildir.

AI ile insan arasında güvenilir bir doğrulama katmanıdır.

---

Modern pipeline nasıl düşünülmeli?

AI-native dönemde pipeline’ı tek bir teknik akış gibi değil, birkaç katmandan oluşan bir güven ve karar sistemi gibi düşünebiliriz.

Basit bir örnek yapı şöyle olabilir:

Bağlam
İzlenebilirlik
Build
Test
Güvenlik kontrolü
Mimari kontrol
AI çıktısı doğrulama
Risk değerlendirme
İnsan onayı
Deploy
Kanıt ve audit trail

Bu akışın amacı sadece uygulamayı deploy etmek değildir.

Amaç, deploy kararının güvenilir olup olmadığını anlamaktır.

Şimdi bu katmanlara daha sade şekilde bakalım.

---

1. Bağlam: Bu değişiklik neden var?

Pipeline’ın ilk sorusu şu olmalı:

Bu değişiklik hangi bağlamda yapıldı?

Klasik pipeline çoğu zaman kod değişikliğinden başlar.

Ama AI-native pipeline için bağlam çok önemlidir.

Çünkü AI doğru bağlamı anlamazsa, çok hızlı ama yanlış bir çıktı üretebilir.

Bu yüzden pipeline veya ona bağlı sistemler şu bilgileri takip edebilmelidir:

• değişikliğin amacı,
• ilgili iş ihtiyacı,
• kullanıcı hikayesi veya task,
• kabul kriterleri,
• kapsam sınırları,
• varsayımlar,
• etkilenen modüller,
• beklenen davranış.

Bağlam yoksa, AI çıktısını değerlendirmek zorlaşır.

Çünkü neyin doğru olduğunu anlamak için önce ne yapılmak istendiğini bilmek gerekir.

---

2. İzlenebilirlik: Bu değişiklik neye bağlı?

AI-native yazılım teslimatında izlenebilirlik daha önemli hale gelir.

Çünkü sadece kodun değiştiğini bilmek yetmez.

Bu değişikliğin hangi ihtiyaca bağlı olduğunu da bilmek gerekir.

Şu sorular önemlidir:

• Bu commit hangi gereksinime bağlı?
• Bu test hangi kabul kriterini doğruluyor?
• Bu değişiklik hangi kullanıcı hikayesini etkiliyor?
• Bu release hangi iş değerini taşıyor?
• AI tarafından üretilen çıktı hangi bağlamdan beslendi?

İzlenebilirlik yoksa pipeline sadece teknik çıktı üretir.

Ama iş değeriyle bağlantıyı zayıf kurar.

Kurumsal sistemlerde bu ciddi bir eksikliktir.

---

3. Build ve test hâlâ temel

Build ve test hâlâ pipeline’ın temelidir.

Bu değişmedi.

Ama artık test kavramını biraz daha geniş düşünmek gerekir.

Sadece unit test değil; davranış, entegrasyon, regresyon ve kritik iş senaryoları da önemlidir.

AI ile üretilen kod için özellikle şu sorular sorulmalıdır:

• Testler gerçekten anlamlı mı?
• Sadece mutlu yolu mu test ediyor?
• Edge case’ler düşünülmüş mü?
• Hata durumları kapsanmış mı?
• Testler gereksinimle bağlantılı mı?
• AI’ın ürettiği testler gerçekten davranışı doğruluyor mu?

Çünkü AI test de üretebilir.

Ama AI’ın test üretmesi, testin yeterli olduğu anlamına gelmez.

Testin de doğrulanması gerekir.

---

4. Güvenlik sonucu release kararını etkilemeli

AI ile üretilen kod güvenlik açısından mutlaka kontrol edilmelidir.

Çünkü AI bazen çalışan ama güvenli olmayan çözümler önerebilir.

Örneğin:

• zayıf input validation,
• yanlış authentication kontrolü,
• eksik authorization,
• riskli dependency kullanımı,
• gizli bilgi sızıntısı,
• güvensiz konfigürasyon,
• SQL injection riski,
• loglarda hassas veri,
• hatalı secret yönetimi.

Pipeline bu riskleri mümkün olduğunca erken yakalamalıdır.

Ama burada amaç sadece güvenlik taraması çalıştırmak değildir.

Amaç, güvenliği yazılım teslimat kararının parçası haline getirmektir.

Yani güvenlik sonucu sadece rapor olarak kalmamalı.

Release kararını etkileyebilmelidir.

---

5. Mimari ve kod kalitesi korunmalı

AI’ın ürettiği kod bazen yerel olarak doğru görünebilir ama sistemin genel mimarisine zarar verebilir.

Örneğin:

• katman ihlali yapabilir,
• bağımlılık yönünü bozabilir,
• domain kurallarını yanlış yere koyabilir,
• tekrar eden kod oluşturabilir,
• transaction sınırlarını bulanıklaştırabilir,
• modül sınırlarını ihlal edebilir,
• geçici çözümü kalıcı hale getirebilir.

Bu yüzden pipeline sadece test çalıştırmamalı.

Mimari kuralları ve kalite standartlarını da kontrol etmelidir.

Özellikle büyük sistemlerde şu sorular kritik hale gelir:

• Kod doğru katmanda mı?
• Modül sınırlarına uyuyor mu?
• Bağımlılık yönü doğru mu?
• Public API sözleşmesi bozuldu mu?
• Database migration güvenli mi?
• Geriye uyumluluk korundu mu?

AI-native pipeline bu kontrolleri sistematik hale getirmelidir.

---

6. AI çıktısı da doğrulanmalı

AI-native pipeline’ın klasik pipeline’dan ayrıldığı en önemli yerlerden biri burasıdır.

Artık sadece kodu değil, AI çıktısını da değerlendirmek gerekir.

Çünkü AI çıktısı sadece kod olmayabilir.

AI şunları da üretebilir:

• gereksinim özeti,
• task kırılımı,
• tasarım önerisi,
• test senaryosu,
• kod review yorumu,
• risk analizi,
• dokümantasyon,
• release notu.

Bu çıktıların her biri yanlış, eksik veya yanıltıcı olabilir.

Bu yüzden pipeline veya bağlı doğrulama sistemi şu soruları sormalıdır:

• Çıktı beklenen formatta mı?
• Kaynak bağlamla uyumlu mu?
• Gereksinimi yanlış yorumlamış mı?
• Kritik bilgi uydurmuş mu?
• Test edilebilir çıktı üretmiş mi?
• İnsan onayı gerektiren bir kararı otomatik vermeye çalışmış mı?
• Politika dışı bir öneri üretmiş mi?

Bu konu ileride daha da önemli hale gelecek.

Çünkü agentic sistemlerde sadece kodu değil, ajan davranışını da test etmek gerekecek.

---

7. Her değişiklik aynı riskte değildir

Basit bir metin değişikliği ile ödeme sistemine yapılan değişiklik aynı şekilde ele alınmamalıdır.

AI-native pipeline değişiklikleri risk seviyesine göre değerlendirebilmelidir.

Örneğin risk faktörleri şunlar olabilir:

• etkilenen modül,
• değişiklik boyutu,
• müşteri etkisi,
• güvenlik etkisi,
• veri kaybı riski,
• migration riski,
• performans etkisi,
• test kapsamı,
• production geçmişi,
• AI katkı oranı,
• insan review durumu.

Risk düşükse pipeline otomatik ilerleyebilir.

Risk yüksekse insan onayı isteyebilir.

Bu noktada pipeline gerçekten karar zincirine dönüşür.

Çünkü her değişiklik için aynı yolu izlemek yerine, bağlama ve riske göre farklı karar akışları çalıştırır.

---

8. İnsan her yerde değil, doğru yerde olmalı

AI-native pipeline’da insan onayı daha bilinçli tasarlanmalıdır.

Her şeyi insana sormak süreci yavaşlatır.

Hiçbir şeyi insana sormamak ise riski artırır.

Bu yüzden doğru yaklaşım şudur:

İnsan her adımda değil, kritik karar noktalarında devrede olmalıdır.

Örneğin şu durumlarda insan onayı gerekebilir:

• production deploy,
• yüksek riskli değişiklik,
• güvenlik uyarısı,
• veri modeli değişikliği,
• finansal işlem etkisi,
• müşteri deneyimini değiştiren akış,
• test kapsamı yetersizliği,
• policy istisnası,
• AI’ın belirsiz veya düşük güvenli çıktı üretmesi.

Bunu bazen klasik “human-in-the-loop” ifadesinden biraz farklı düşünmek gerekiyor.

Bence daha doğru ifade şu:

Human-at-the-decision-point

Yani insan her küçük adıma müdahale etmez.

Ama kararın gerçekten önemli olduğu yerde devreye girer.

---

9. Deploy sadece teknik dağıtım değildir

Deployment hâlâ pipeline’ın önemli bir parçasıdır.

Ama AI-native dönemde deployment sadece teknik dağıtım değildir.

Deployment artık şu sorularla birlikte düşünülmelidir:

• Hangi ortama çıkılıyor?
• Rollback planı var mı?
• Feature flag kullanılacak mı?
• Canary veya blue-green deployment gerekli mi?
• Monitoring hazır mı?
• Alert kuralları güncel mi?
• Release notu hazır mı?
• Operasyon ekibi bilgilendirildi mi?
• Müşteri etkisi var mı?

Yani mesele sadece deploy butonuna basmak değildir.

Mesele, deploy kararının güvenilir olmasıdır.

---

10. Geleceğin teslimatı kanıtla gelecek

AI-native pipeline’ın en kritik çıktılarından biri kanıttır.

Çünkü ileride şu sorular sorulacaktır:

• Bu değişiklik neden yapıldı?
• Hangi AI çıktısı kullanıldı?
• Kim review etti?
• Hangi testler geçti?
• Hangi güvenlik kontrolleri çalıştı?
• Hangi riskler kabul edildi?
• Kim onay verdi?
• Hangi ortamda ne zaman yayınlandı?
• Sorun çıkarsa hangi değişiklik geri alınmalı?

Bu soruların cevabı e-posta, chat mesajı veya kişisel hafızada kalmamalıdır.

Pipeline bu bilgilerin izini tutmalıdır.

Bu yüzden geleceğin yazılım teslimatı sadece kodla değil, kanıtla birlikte gelmelidir.

Bunu şöyle özetleyebiliriz:

AI ile üretilen iş, kanıtıyla birlikte teslim edilmelidir.

---

Eski pipeline ve yeni pipeline

Klasik pipeline şöyle özetlenebilirdi:

Commit
Build
Test
Deploy

AI-native pipeline ise daha geniş düşünülmelidir:

Bağlam
İzlenebilirlik
Build
Test
Güvenlik
Mimari kontrol
AI çıktısı doğrulama
Risk değerlendirme
İnsan onayı
Deploy
Kanıt

Bu daha karmaşık görünebilir.

Ama amaç karmaşıklık eklemek değil.

Amaç kontrolsüz hızı güvenilir teslimata dönüştürmektir.

Çünkü AI ile üretim hızı arttığında, doğrulama sistemi zayıf kalırsa risk de artar.

---

Bu dönüşüm neden önemli?

Çünkü yazılım ekipleri artık sadece daha hızlı geliştirmek zorunda değil.

Daha güvenilir geliştirmek zorunda.

Özellikle AI ile birlikte şu riskler daha görünür hale geliyor:

• hızlı ama bağlamsız kod üretimi,
• eksik testlerle gelen sahte güven,
• güvenlik açıklarının fark edilmeden yayılması,
• mimari borcun hızla büyümesi,
• review süreçlerinin yüzeyselleşmesi,
• kim neyi neden yaptı sorusunun kaybolması,
• insan kararının yanlış noktada devreden çıkarılması.

Bu yüzden modern pipeline’ın görevi sadece otomasyon değildir.

Modern pipeline’ın görevi güvenilir teslimat sağlamaktır.

---

Sonuç

CI/CD hâlâ önemli.

Ama AI-native yazılım geliştirme döneminde pipeline sadece CI/CD olarak düşünülürse eksik kalır.

Çünkü artık pipeline’ın görevi sadece kodu build etmek, test etmek ve deploy etmek değildir.

Pipeline bağlamı korumalıdır.
Gereksinimle bağlantıyı izlemelidir.
AI çıktısını doğrulamalıdır.
Güvenlik ve mimari kontrolleri çalıştırmalıdır.
Risk seviyesini değerlendirmelidir.
Gerektiğinde insan onayı istemelidir.
Teslimat kanıtı üretmelidir.

Yani pipeline artık sadece teknik bir otomasyon hattı değildir.

Pipeline artık karar zinciridir.

Bu zincirin amacı insanı devreden çıkarmak değildir.

Amaç, insanın daha doğru karar verebilmesi için sistemi güvenilir kanıtlarla desteklemektir.

Bence yeni dönemin özeti yine aynı yere geliyor:

AI üretir.
Sistem doğrular.
İnsan karar verir.

Ve bu dengenin çalıştığı en önemli yerlerden biri artık pipeline’dır.

---

Serinin devamı

Bu yazı, Agentic Software Development serisinin üçüncü yazısıdır.

Serinin ilk yazısı:
AI ile Kod Yazmak Eski Oyun

Serinin ikinci yazısı:
AI-Native SDLC Nedir?

Serinin sonraki yazısı:
Tek Ajan Değil, Orkestrasyon Kazanacak

---