Yusuf ŞAHİN

Etiket: Quality Gates

  • AI Kötü Süreçleri Düzeltmez, Büyütür

    AI ile yazılım geliştirme konuşurken çoğu zaman hızdan bahsediyoruz.

    Daha hızlı kod yazmak.
    Daha hızlı test üretmek.
    Daha hızlı dokümantasyon hazırlamak.
    Daha hızlı analiz yapmak.
    Daha hızlı release’e çıkmak.

    Bunların hepsi değerli.

    Ama burada çok kritik bir gerçek var:

    AI iyi tasarlanmış bir süreci hızlandırabilir.
    Kötü tasarlanmış bir süreci ise daha hızlı karmaşaya dönüştürebilir.

    R. Buckminster Fuller’a atfedilen meşhur bir söz var:

    “A fool with a tool still remains a fool.”

    Yani araç ne kadar güçlü olursa olsun, onu kullanan düşünce yapısı, süreç ve karar kalitesi zayıfsa sonuç kendiliğinden iyi hale gelmez.

    AI da böyledir.

    AI sihirli bir süreç düzeltici değildir.

    Eğer gereksinimler belirsizse, AI da belirsizliğin üzerine üretim yapar.
    Eğer backlog dağınıksa, AI da dağınık bağlamla çalışır.
    Eğer test stratejisi zayıfsa, AI’ın ürettiği testler sahte güven oluşturabilir.
    Eğer mimari kurallar net değilse, AI çalışan ama mimariyi bozan kod üretebilir.
    Eğer release kararı izlenebilir değilse, AI sadece bu kararsızlığı hızlandırır.

    Bu yüzden AI kullanmaya başlamadan önce şu soruyu sormak gerekir:

    Biz gerçekten iyi bir süreci mi hızlandırıyoruz, yoksa kötü bir süreci mi ölçekliyoruz?

    AI hız kazandırır, ama yön vermez

    AI çok hızlı çıktı üretebilir.

    Ama hız tek başına kalite değildir.

    Bir ekip ne istediğini net bilmiyorsa, AI’ın hızlı üretmesi problemi çözmez.

    Tam tersine, yanlış yöne daha hızlı gidilmesine neden olabilir.

    Çünkü yazılım geliştirmede asıl mesele sadece üretmek değildir.

    Doğru problemi anlamak, doğru çözümü tasarlamak, doğru test etmek, doğru zamanda doğru kararı vermek gerekir.

    AI bu adımlara destek olabilir.

    Ama sürecin temel disiplini yoksa AI’ın çıktısı da güvenilir olmaz.

    Belirsiz gereksinim, hızlı yanlış üretim demektir

    Yazılım projelerinde birçok sorun koddan önce başlar.

    İhtiyaç net değildir.
    Kabul kriterleri eksiktir.
    Kapsam sürekli değişir.
    Öncelikler belirsizdir.
    Kim karar verecek belli değildir.

    Böyle bir ortamda AI’a görev verdiğimizde, AI boşlukları tahminle doldurur.

    Ve çoğu zaman bunu çok ikna edici şekilde yapar.

    Sonuçta ortaya çalışan ama yanlış ihtiyacı karşılayan bir çıktı çıkabilir.

    Bu yüzden AI-native SDLC’de gereksinim kalitesi daha da önemli hale gelir.

    Çünkü AI yanlış ihtiyacı çok hızlı şekilde ürüne dönüştürebilir.

    Zayıf test kültürü, AI ile daha tehlikeli hale gelir

    AI test de üretebilir.

    Ama bu, sistemin iyi test edildiği anlamına gelmez.

    AI çoğu zaman mutlu yolu test eder.
    Edge case’leri atlayabilir.
    İş kuralını yanlış anlayabilir.
    Yetersiz assertion yazabilir.
    Kritik regresyon senaryolarını kaçırabilir.

    Eğer ekipte güçlü bir test stratejisi yoksa, AI’ın ürettiği testler sahte güven oluşturabilir.

    Test varmış gibi görünür.

    Ama gerçekten neyi doğruladığı belirsizdir.

    Bu yüzden AI-native dünyada test otomasyonu kadar test aklı da önemlidir.

    Mimari belirsizlik teknik borcu hızlandırır

    AI çalışan kod üretebilir.

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

    Mimari sınırlar net değilse AI:

    • katmanları karıştırabilir,
    • domain kurallarını yanlış yere koyabilir,
    • tekrar eden kod üretebilir,
    • bağımlılık yönünü bozabilir,
    • geçici çözümü kalıcı hale getirebilir,
    • sistemi zamanla daha kırılgan hale getirebilir.

    Bu yüzden AI ile kod üretmeden önce mimari kuralların, modül sınırlarının ve kalite standartlarının net olması gerekir.

    Aksi halde AI teknik borcu azaltmaz.

    Teknik borcu daha hızlı üretir.

    Review kültürü yoksa AI çıktısı kontrolsüz kalır

    AI’ın ürettiği kod, dokümantasyon, test veya analiz doğrudan doğru kabul edilmemelidir.

    Review kültürü zayıfsa, AI çıktısı kolayca sisteme girer.

    Çünkü düzgün görünür.
    Mantıklı görünür.
    Çalışıyor gibi görünür.
    Hatta bazen testten de geçer.

    Ama bu yeterli değildir.

    AI çıktısı şu sorularla değerlendirilmelidir:

    • Doğru ihtiyaca mı hizmet ediyor?
    • Mimariye uygun mu?
    • Testler anlamlı mı?
    • Güvenlik riski var mı?
    • Bakımı kolay mı?
    • İnsan onayı gereken bir karar içeriyor mu?

    AI-native geliştirmede review daha az değil, daha akıllı hale gelmelidir.

    Quality gate yoksa hız risk üretir

    AI ile üretim hızlandıkça quality gate’lerin önemi artar.

    Çünkü hızlanan sadece doğru işler değildir.

    Hatalar da hızlanır.
    Eksik testler de hızlanır.
    Yanlış kararlar da hızlanır.
    Teknik borç da hızlanır.

    Bu yüzden AI çıktısı teslimata dönüşmeden önce doğrulanmalıdır.

    Build geçti mi?
    Testler anlamlı mı?
    Static analysis temiz mi?
    Security riski var mı?
    Fonksiyonel davranış doğru mu?
    Deployment sonrası sistem izlenebilir mi?
    İnsan onayı gereken yerde süreç duruyor mu?

    Quality gate yoksa AI-native geliştirme değil, hızlı ve kontrolsüz üretim vardır.

    Küçük hedefler, kısa iterasyonlar ve PDCA

    AI-native dönüşüm bir anda büyük bir platform kurarak başlamamalı.

    Daha doğru başlangıç küçük, ölçülebilir ve kontrollü hedefler koymaktır.

    Örneğin:

    • önce gereksinim kalitesini iyileştirmek,
    • sonra kabul kriterlerini netleştirmek,
    • sonra test otomasyonunu güçlendirmek,
    • sonra quality gate eklemek,
    • sonra AI çıktısını değerlendirme sürecine almak,
    • sonra agentic akışları kontrollü şekilde denemek.

    Burada PDCA yaklaşımı çok faydalıdır:

    Plan  → Neyi iyileştireceğiz?
Do    → Küçük bir alanda dene.
Check → Sonucu ölç ve öğren.
Act   → İşe yarıyorsa standartlaştır, yaramıyorsa düzelt.

    AI-native SDLC de böyle gelişmelidir.

    Büyük iddialarla değil, küçük ve sürekli öğrenen iterasyonlarla.

    Çünkü süreç iyileştirme tek seferlik bir proje değildir.

    Öğrenme döngüsüdür.

    AI bu döngüyü hızlandırabilir.

    Ama döngünün kendisi yoksa, AI sadece daha hızlı deneme-yanılma üretir.

    AI kötü süreci görünür hale getirir

    Aslında AI’ın iyi taraflarından biri de budur.

    Kötü süreci gizlemez.

    Çoğu zaman daha görünür hale getirir.

    Backlog dağınıksa belli olur.
    Kabul kriterleri zayıfsa belli olur.
    Test stratejisi eksikse belli olur.
    Mimari kararlar belirsizse belli olur.
    Release süreci izlenebilir değilse belli olur.

    Bu yüzden AI kullanımı bir fırsat da olabilir.

    Çünkü ekip şunu fark eder:

    Sorun AI’da değil, sürecin kendisinde.

    AI’dan iyi sonuç almak için önce süreci iyileştirmek gerekir.

    Nereden başlamak gerekir?

    AI-native olmak için hemen büyük bir agentic platform kurmak gerekmez.

    Önce mevcut sürece dürüstçe bakmak gerekir.

    Şu sorular iyi bir başlangıçtır:

    • Gereksinimler yeterince net mi?
    • Kabul kriterleri yazılıyor mu?
    • Test stratejimiz var mı?
    • Kritik iş akışları otomasyonla korunuyor mu?
    • Kod review gerçekten yapılıyor mu?
    • Mimari kurallar tanımlı mı?
    • Release kararı kanıta dayanıyor mu?
    • Production sonrası sistem izleniyor mu?
    • AI çıktısını nasıl doğruluyoruz?

    Bu sorulara cevap vermeden AI’ı sürece eklemek, çoğu zaman var olan sorunları hızlandırır.

    Başlangıç küçük olmalı.

    Bir ekip.
    Bir ürün.
    Bir süreç problemi.
    Bir ölçülebilir hedef.
    Bir kısa iterasyon.

    Sonra öğren, düzelt, tekrar dene.

    AI-native dönüşümün sağlıklı yolu budur.

    Sonuç

    AI yazılım geliştirmeyi hızlandırabilir.

    Ama kötü süreci düzeltmez.

    Belirsiz gereksinimi netleştirmeden kod üretmek risktir.
    Zayıf test stratejisiyle AI testlerine güvenmek risktir.
    Mimari kurallar olmadan AI kodu almak risktir.
    Review kültürü olmadan AI çıktısını kabul etmek risktir.
    Quality gate olmadan AI ile release yapmak risktir.

    Bu yüzden AI-native SDLC’nin özü sadece AI kullanmak değildir.

    Öz, AI’ı iyi tasarlanmış bir yazılım teslimat sisteminin içine yerleştirmektir.

    Bu da küçük hedefler, kısa iterasyonlar ve sürekli öğrenme ile olur.

    Süreç iyiyse AI değeri büyütür.

    Süreç kötüyse karmaşayı büyütür.

    Bence bu dönemin en net cümlelerinden biri şu:

    AI kötü süreçleri düzeltmez.
    Sadece daha hızlı görünür hale getirir.

    Ve yine aynı dengeye geliyoruz:

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

    Serinin devamı

    Bu yazı, Agentic Software Development serisinin yedinci yazısıdır.

    Serinin önceki yazısı:
    Evaluation-Driven Development: AI Sistemlerinde Test Artık Kod Testi Değil

    Serinin sonraki yazısı:
    Proof-Carrying Delivery: AI ile Üretilen İş Kanıtıyla Gelmeli

  • Evaluation-Driven Development: AI Sistemlerinde Test Artık Kod Testi Değil

    Yazılım dünyasında test uzun yıllar boyunca daha çok şu soruya odaklandı:

    Kod doğru çalışıyor mu?

    Bu soru hâlâ önemli.

    Unit test, integration test, functional test, performance test, security test, UAT… Bunların hiçbiri önemini kaybetmedi.

    Ama AI-native ve agentic sistemlerde artık bu soru tek başına yeterli değil.

    Çünkü sistemin içinde sadece klasik kod yok.

    Artık prompt var.
    Context var.
    RAG var.
    Tool calling var.
    Memory var.
    Agent workflow var.
    İnsan onayı gereken karar noktaları var.

    Bu yüzden yeni soru şu hale geliyor:

    AI doğru bağlamda, doğru aracı, doğru sınırlar içinde kullandı mı?

    İşte Evaluation-Driven Development burada devreye giriyor.

    Evaluation-Driven Development nedir?

    Evaluation-Driven Development, AI destekli veya agentic sistemlerde çıktının sadece çalışıp çalışmadığını değil; doğru, güvenilir, izlenebilir ve beklenen davranışa uygun olup olmadığını değerlendirme yaklaşımıdır.

    Klasik test genelde şunu sorar:

    Fonksiyon beklenen sonucu verdi mi?

    Evaluation ise daha geniş bakar:

    AI bu sonuca nasıl ulaştı?
    Doğru bağlamı kullandı mı?
    Kaynakları doğru yorumladı mı?
    Gerekli yerde durup insana sordu mu?
    Yanlış aracı çağırdı mı?
    Uydurma bilgi üretti mi?
    Güvenlik veya politika sınırını aştı mı?

    Yani AI-native sistemlerde test, sadece kodun davranışını değil, AI’ın karar ve aksiyon sürecini de kapsar.

    Neden şimdi önemli?

    Çünkü AI çıktıları çoğu zaman ikna edici görünür.

    Cümleler düzgün olabilir.
    Kod çalışıyor olabilir.
    Test yazılmış olabilir.
    Dokümantasyon profesyonel durabilir.
    Analiz mantıklı görünebilir.

    Ama görünüm güvenilirlik değildir.

    AI yanlış context kullanabilir.
    Eksik bilgiyle karar önerebilir.
    RAG sonucunu yanlış yorumlayabilir.
    Yanlış tool çağırabilir.
    İnsan onayı gereken yerde otomatik ilerleyebilir.
    Hallucination üretebilir.
    Güvenlik veya gizlilik sınırını aşabilir.

    Bu yüzden AI-native SDLC’de sadece “test geçti mi?” demek yeterli olmaz.

    Şunu da sormak gerekir:

    AI davranışı değerlendirildi mi?

    Artık sadece output değil, süreç de test edilmeli

    Klasik yazılımda çoğu zaman sonuca bakarız.

    Fonksiyon beklenen sonucu verdi mi?
    API doğru response döndü mü?
    UI beklenen davranışı gösterdi mi?

    AI sistemlerinde sonuç kadar, o sonuca nasıl ulaşıldığı da önemlidir.

    Çünkü AI doğru cevaba yanlış yoldan ulaşabilir.

    Yanlış kaynağı kullanıp doğru görünen cevap verebilir.
    Yanlış tool çağırıp sonucu şans eseri doğru yorumlayabilir.
    İnsan onayı gereken yerde durmadan ilerleyebilir.
    Eksik context ile fazla özgüvenli bir çıktı üretebilir.

    Bu yüzden AI-native sistemlerde testin kapsamı genişler.

    Sadece çıktı değil, süreç de değerlendirilmelidir.

    Neleri evaluate etmeliyiz?

    Evaluation-Driven Development içinde birkaç temel alan öne çıkar.

    1. Output Evaluation

    İlk bakılacak şey AI çıktısının kendisidir.

    Şu sorular sorulur:

    • Çıktı doğru mu?
    • Beklenen formatta mı?
    • Eksik bilgi var mı?
    • Uydurma bilgi içeriyor mu?
    • Kullanıcı ihtiyacına gerçekten cevap veriyor mu?
    • Gereksiz özgüvenli veya yanıltıcı mı?

    Bu özellikle dokümantasyon, analiz, özet, kod açıklaması ve karar önerilerinde önemlidir.

    Çünkü AI çıktısı düzgün görünse bile yanlış olabilir.

    2. Context Evaluation

    AI’ın kalitesi büyük ölçüde kullandığı context’e bağlıdır.

    Yanlış context, yanlış sonuç üretir.

    Bu yüzden şu sorular önemlidir:

    • AI doğru dokümanları kullandı mı?
    • Güncel bilgiye mi dayandı?
    • Eski veya geçersiz bilgiyi mi kullandı?
    • Gereksiz context sonucu bozdu mu?
    • Kritik bağlam eksik miydi?

    AI-native sistemlerde context yönetimi test edilmeden güvenilirlik sağlanamaz.

    Çünkü çoğu hata modelden değil, yanlış veya eksik context’ten gelir.

    3. RAG Evaluation

    RAG kullanılan sistemlerde evaluation daha da önemlidir.

    Çünkü cevap sadece modelden değil, getirilen kaynaklardan da etkilenir.

    RAG için şu sorular sorulur:

    • Doğru kaynaklar getirildi mi?
    • Getirilen kaynaklar güncel mi?
    • Cevap kaynaklara dayanıyor mu?
    • Kaynakta olmayan bilgi uyduruldu mu?
    • Benzer ama yanlış doküman kullanıldı mı?
    • Kritik kaynak kaçırıldı mı?

    RAG sistemlerinde başarı sadece “cevap güzel mi?” değildir.

    Başarı, cevabın doğru kaynağa dayanmasıdır.

    4. Tool Calling Evaluation

    Agentic sistemlerde AI sadece cevap üretmez.

    Araç da çağırır.

    Kod çalıştırabilir.
    API çağırabilir.
    Veritabanı sorgulayabilir.
    Dosya okuyabilir.
    Ticket açabilir.
    Deployment başlatabilir.

    Bu yüzden tool calling mutlaka değerlendirilmelidir.

    Şu sorular sorulmalıdır:

    • Doğru araç çağrıldı mı?
    • Araç doğru parametrelerle kullanıldı mı?
    • Gereksiz tool call yapıldı mı?
    • Tool sonucu doğru yorumlandı mı?
    • Hata durumunda doğru davrandı mı?
    • Yetkisi olmayan bir aksiyon almaya çalıştı mı?

    Agentic sistemlerde tool calling kontrol edilmezse, AI sadece yanlış cevap üretmez; yanlış aksiyon da alabilir.

    5. Agent Workflow Evaluation

    Birden fazla adımı olan agentic sistemlerde sadece sonuç değil, akış da önemlidir.

    Ajan doğru sırayla mı ilerledi?
    Doğru noktada durdu mu?
    Gerekli kontrolü yaptı mı?
    İnsan onayı gereken yerde bekledi mi?
    Quality gate’i atladı mı?
    Hatalı adımdan geri dönebildi mi?

    Bu yüzden agent workflow test edilmelidir.

    Özellikle yazılım geliştirme ajanlarında bu çok kritiktir.

    Çünkü bir ajan gereksinimi yanlış yorumlarsa, diğer ajan kodu da yanlış yazabilir, test de yanlış senaryoyu doğrulayabilir.

    Hata zincir boyunca büyür.

    6. Human Decision Evaluation

    AI-native SDLC’de insan tamamen devreden çıkmaz.

    Ama insan her adımda da olmamalıdır.

    Önemli olan insanın doğru karar noktasında devreye girmesidir.

    Bu yüzden şu sorular test edilmelidir:

    • İnsan onayı gereken yerde sistem duruyor mu?
    • Düşük riskli durumda otomasyon ilerleyebiliyor mu?
    • Yüksek riskli durumda approval istiyor mu?
    • AI riskli bir kararı kendi vermeye çalışıyor mu?
    • Onay geçmişi kayıt altına alınıyor mu?

    Bu yaklaşımı şöyle özetleyebiliriz:

    Human-in-the-loop değil, human-at-the-decision-point.

    Yani insan her adımda süreci yavaşlatan kişi değil, kritik karar noktasında devreye giren kişidir.

    Evaluation sadece manuel yapılmaz

    Evaluation deyince her şeyi insanın tek tek kontrol etmesi anlaşılmamalı.

    Bazı değerlendirmeler otomatik olabilir:

    • output format kontrolü,
    • test sonucu,
    • güvenlik scan sonucu,
    • policy check,
    • regression eval,
    • golden dataset karşılaştırması,
    • hallucination kontrolü,
    • tool call doğrulaması,
    • RAG kaynak uygunluğu,
    • metrik bazlı kalite kontrolü.

    Bazı değerlendirmeler ise insan kararı gerektirir:

    • risk kabulü,
    • mimari istisna,
    • ürün kararı,
    • müşteri etkisi,
    • etik veya hukuki hassasiyet,
    • production release onayı.

    Yani evaluation, otomasyon ve insan kararının birlikte tasarlandığı bir kalite yaklaşımıdır.

    Evaluation-Driven Development ve Quality Gates ilişkisi

    Bir önceki yazıda quality gates konusunu konuşmuştuk.

    Evaluation-Driven Development, bu quality gate’lerin AI-native dünyadaki karşılığıdır.

    Klasik quality gate şunu sorar:

    Testler geçti mi?

    AI-native quality gate ise şunu da sorar:

    AI çıktısı güvenilir mi?
    AI doğru context kullandı mı?
    Ajan doğru aracı çağırdı mı?
    İnsan onayı gereken yerde durdu mu?
    Cevap kaynaklara dayanıyor mu?
    Süreç sonradan denetlenebilir mi?

    Bu yüzden evaluation, AI-native SDLC’nin merkezinde olmalıdır.

    Çünkü AI ile üretim hızlandıkça, değerlendirme disiplini zayıf kalırsa risk büyür.

    Evaluation nasıl uygulanabilir?

    Evaluation-Driven Development bir anda büyük ve karmaşık bir sistem kurmak zorunda değildir.

    Küçük başlanabilir.

    Örneğin:

    • AI çıktıları için beklenen format kuralları belirlenebilir.
    • Kritik prompt’lar için test veri setleri hazırlanabilir.
    • RAG cevapları için kaynak doğruluğu kontrol edilebilir.
    • Tool calling senaryoları için başarılı ve başarısız akışlar test edilebilir.
    • İnsan onayı gereken karar noktaları netleştirilebilir.
    • Agent workflow logları izlenebilir hale getirilebilir.
    • Kritik senaryolar için regression eval setleri oluşturulabilir.

    Buradaki amaç, AI’ı yavaşlatmak değildir.

    Amaç, AI’ın hızlı üretimini güvenilir hale getirmektir.

    Sonuç

    AI-native sistemlerde test artık sadece kod testi değildir.

    Kod hâlâ test edilmelidir.

    Ama bunun yanında AI çıktısı, context, RAG, tool calling, agent workflow, insan karar noktaları ve audit evidence da değerlendirilmelidir.

    Çünkü AI sadece metin üretmez.

    Karar önerir.
    Aksiyon alır.
    Araç kullanır.
    Süreçleri tetikler.
    Teslimat zincirine dahil olur.

    Bu yüzden yeni dönemde yazılım kalitesi iki soruyla ölçülecek:

    Sistem doğru çalışıyor mu?

    ve

    AI doğru davrandı mı?

    Bence Evaluation-Driven Development’ın özü burada.

    Ve yine aynı dengeye geliyoruz:

    AI üretir.
    Sistem değerlendirir.
    İnsan kritik kararı verir.

    Serinin devamı

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

    Serinin önceki yazısı:
    Quality Gates: AI Çıktısı Nasıl Teslimata Dönüşür?

    Serinin sonraki yazısı:
    AI Kötü Süreçleri Düzeltmez, Büyütür

  • Quality Gates: AI Çıktısı Nasıl Teslimata Dönüşür?

    AI artık yazılım geliştirme sürecinde çok şey üretebiliyor.

    Kod yazabiliyor.
    Test taslağı çıkarabiliyor.
    Dokümantasyon hazırlayabiliyor.
    Hata açıklayabiliyor.
    Riskleri listeleyebiliyor.

    Ama burada kritik bir ayrım var:

    AI’ın çıktı üretmesi, o çıktının teslimata hazır olduğu anlamına gelmez.

    Kod çalışabilir ama yanlış problemi çözebilir.
    Test yazılmış olabilir ama kritik senaryoları kapsamıyor olabilir.
    Dokümantasyon düzgün görünebilir ama gerçeği tam yansıtmayabilir.
    Deployment başarılı olabilir ama canlı ortamda sistem beklenen davranışı göstermeyebilir.

    Bu yüzden AI çıktısı doğrudan teslimat değildir.

    Önce doğrulanmalıdır.

    İşte burada quality gates, yani kalite kapıları devreye girer.

    Quality gate nedir?

    Quality gate, bir çıktının bir sonraki aşamaya geçmeden önce karşılaması gereken kontrol noktasıdır.

    Basitçe sistem şunu sorar:

    Bu çıktı ilerlemeye hazır mı?

    Ama bu soru sadece “testler geçti mi?” demek değildir.

    AI-native yazılım geliştirmede quality gate daha geniş bir güven zinciridir.

    Şu sorulara bakar:

    • Bu çıktı doğru ihtiyaca mı bağlı?
    • Kod anlaşılır ve sürdürülebilir mi?
    • Static analysis temiz mi?
    • Fonksiyonel davranış doğru mu?
    • Unit, integration ve system testler geçti mi?
    • Güvenlik riski var mı?
    • Performans kabul edilebilir mi?
    • Deployment kontrollü mü?
    • Canlı ortam izlenebilir mi?
    • İnsan onayı gereken yerde duruyor mu?
    • Sonradan denetlenebilir kanıt oluştu mu?

    Çünkü AI ile üretim hızlanırken, doğrulama zayıf kalırsa sadece daha hızlı risk üretmiş oluruz.

    Her projeye aynı kapılar gerekmez

    Burada denge önemli.

    Quality gates, her projeye aynı ağırlıkta uygulanacak sabit bir kontrol listesi değildir.

    Küçük ve düşük riskli bir uygulamada bazı kontroller daha hafif olabilir.

    Ama finans, sağlık, kamu, ödeme sistemleri, kritik veri veya regülasyonlu yapılarda kalite kapıları daha güçlü tasarlanmalıdır.

    Doğru yaklaşım risk bazlıdır.

    Yani önce şu sorular sorulmalıdır:

    • Sistem ne kadar kritik?
    • Hata olursa etkisi ne olur?
    • Güvenlik riski var mı?
    • Regülasyon var mı?
    • Deployment sonrası geri dönüş kolay mı?
    • AI çıktısı hangi kararı veya davranışı etkiliyor?

    Bu yüzden quality gate bir bürokrasi listesi değildir.

    Doğru tasarlanırsa, AI ile hızlanan üretimi güvenilir teslimata dönüştüren risk yönetimi mekanizmasıdır.

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

    Bu seride tekrar ettiğimiz ana cümle burada da geçerli:

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

    AI kod üretebilir.

    Ama sistem şunu kontrol etmelidir:

    • kod build oluyor mu?
    • static analysis temiz mi?
    • testler anlamlı mı?
    • güvenlik riski var mı?
    • performans bozuldu mu?
    • mimari kurallar korunuyor mu?
    • iş davranışı doğru mu?
    • deployment sonrası sistem sağlıklı mı?

    İnsan ise kritik noktada karar verir.

    Bu çıktı kabul edilecek mi?
    Release’e dahil edilecek mi?
    Risk alınacak mı?
    İstisna verilecek mi?
    Geri çevrilecek mi?

    Quality gates bu dengeyi kurar.

    AI-native SDLC’de temel kalite kapıları

    Bence AI-native bir yazılım geliştirme sürecinde kalite kapıları şu başlıklarda düşünülmeli.

    Ama tekrar vurgulamak gerekir: Bunların hepsi her projede aynı derinlikte uygulanmak zorunda değildir.

    1. Requirement ve Design Gate

    İlk soru şudur:

    Doğru problemi mi çözüyoruz?

    AI gereksinim özeti çıkarabilir, kabul kriteri önerebilir, tasarım alternatifi üretebilir.

    Ama kritik iş ve mimari kararlar insanda kalmalıdır.

    Çünkü yanlış ihtiyaca yazılmış kaliteli kod hâlâ yanlış sonuçtur.

    2. Development ve Static Analysis Gate

    AI kod yazabilir.

    Ama geliştiricinin anlamadığı kod, teknik borca dönüşebilir.

    Development Gate şunu sorar:

    • Kod okunabilir mi?
    • Kod sahiplenilebilir mi?
    • PR açıklaması yeterli mi?
    • Değişiklik ilgili task veya requirement ile bağlantılı mı?

    Static Analysis Gate ise kod çalışmadan önce riskleri yakalar:

    • code smell,
    • SAST,
    • dependency check,
    • secret scanning,
    • license compliance,
    • architecture rule check,
    • container ve IaC scanning.

    Bu kapının amacı erken uyarıdır.

    Kod daha çalışmadan görülebilecek riskleri yakalamak gerekir.

    3. Test Pyramid ve Test Automation Gate

    AI test yazabilir.

    Ama AI’ın test yazması, test stratejisinin doğru olduğu anlamına gelmez.

    Test otomasyonu test pyramid mantığıyla düşünülmelidir:

    Çok sayıda hızlı unit test
Yeterli sayıda integration / contract test
Daha az ama kritik API / E2E test
İhtiyaca göre UAT, exploratory, alpha ve beta testleri

    Her şeyi UI testiyle doğrulamak yavaş ve kırılgan olur.

    Sadece unit testlere güvenmek de sistem davranışını kaçırabilir.

    Bu yüzden asıl soru şudur:

    Bu davranışı en hızlı, en güvenilir ve en az bakım maliyetiyle hangi seviyede test ederiz?

    Araç seçimi de buna göre yapılmalıdır.

    Örneğin unit test için xUnit, JUnit, pytest veya Jest; UI/E2E için Playwright, Cypress veya Selenium; performance için k6, JMeter veya Gatling düşünülebilir.

    Ama araçtan daha önemli olan şey şudur:

    Test otomasyonu güven vermeli, ekibe bakım yüküyle zarar vermemelidir.

    4. Functional Test & Automation Gate

    Teknik testlerin geçmesi, sistemin iş davranışını doğru yaptığı anlamına gelmez.

    Functional Test Gate şunu sorar:

    Sistem, kullanıcının ve iş biriminin beklediği davranışı gerçekten yapıyor mu?

    Burada ana iş akışları, kullanıcı rolleri, yetkiler, form validasyonları, iş kuralları, hata mesajları ve kabul kriterleri doğrulanır.

    AI teknik olarak doğru görünen ama iş kuralını yanlış uygulayan kod üretebilir.

    Bu yüzden fonksiyonel test otomasyonu AI-native SDLC’de kritik hale gelir.

    Özellikle sık tekrarlanan regresyon senaryoları, kritik iş akışları, login, yetkilendirme, ödeme, onay, kayıt gibi ana fonksiyonlar otomasyon için güçlü adaylardır.

    5. Integration, SIT ve System Test Gate

    AI ile üretilen kod lokal olarak doğru çalışabilir.

    Ama gerçek sorun çoğu zaman entegrasyon noktalarında çıkar.

    Bu kapı şu soruları sorar:

    • API contract bozuldu mu?
    • Database, queue, cache veya dış servis entegrasyonları çalışıyor mu?
    • Sistemler arası veri akışı doğru mu?
    • Kritik iş akışları uçtan uca geçiyor mu?
    • Hata durumlarında sistem beklenen davranışı gösteriyor mu?

    CIT, SIT ve system test seviyeleri kurumdan kuruma farklı isimlendirilebilir.

    Önemli olan isim değil, entegrasyon riskinin erken yakalanmasıdır.

    6. Dynamic Analysis, Security ve Performance Gate

    Static analysis kodun yapısına bakar.

    Dynamic analysis ise çalışan sistemin davranışına bakar.

    Burada DAST, API security testleri, runtime kontroller, load test, stress test, response time, throughput, CPU ve memory davranışı gibi başlıklar devreye girer.

    AI’ın ürettiği kod doğru çalışabilir ama performans açısından kötü olabilir.

    Ya da güvenlik açığı taşıyabilir.

    Bu yüzden security ve performance sonuçları sadece rapor olmamalıdır.

    Kritik risk varsa release durmalıdır.

    7. Release, Deployment ve Observability Gate

    Başarılı deployment, başarılı teslimat anlamına gelmez.

    Deployment sadece canlıya alma adımıdır.

    Asıl soru şudur:

    Canlı ortamda sistem sağlıklı mı?

    Bu yüzden release öncesinde rollback planı, migration planı, feature flag, deployment stratejisi, monitoring ve alert kuralları hazır olmalıdır.

    Deployment sonrasında ise observability devreye girer:

    • error rate arttı mı?
    • response time bozuldu mu?
    • loglarda beklenmeyen hata var mı?
    • trace, metric ve log korelasyonu var mı?
    • kritik iş metrikleri etkilendi mi?
    • rollback gerekiyor mu?

    AI-native sistemlerde buna ek olarak AI agent kararları, tool call kayıtları, prompt-context-output ilişkisi ve hatalı AI davranışları da izlenebilmelidir.

    Çünkü izleyemediğimiz sistemi güvenilir şekilde yönetemeyiz.

    8. Agentic Testing ve Audit Evidence Gate

    AI-native dünyada sadece uygulamayı değil, AI davranışını da test etmek gerekir.

    Özellikle agentic sistemlerde şu sorular önemlidir:

    • Ajan doğru bağlamı kullandı mı?
    • Doğru aracı çağırdı mı?
    • Tool call sonucunu doğru yorumladı mı?
    • RAG sonucu güvenilir mi?
    • İnsan onayı gereken yerde durdu mu?
    • Policy dışı çıktı üretti mi?
    • Hallucination riski var mı?

    Bu yüzden test artık sadece “kod doğru çalışıyor mu?” sorusu değildir.

    Asıl soru şudur:

    Ajan doğru bağlamda, doğru sınırlar içinde, doğru davranışı gösterdi mi?

    Son olarak tüm bu sürecin kanıtı tutulmalıdır.

    Hangi AI çıktısı kullanıldı?
    Kim review etti?
    Hangi testler geçti?
    Hangi riskler kabul edildi?
    Kim onay verdi?
    Ne zaman deploy edildi?
    Deploy sonrası sistem sağlıklı mıydı?

    Bu kanıt yoksa, süreç denetlenebilir değildir.

    Sonuç

    AI çıktısı değerlidir.

    Ama AI çıktısı tek başına teslimat değildir.

    Teslimat olması için doğrulanması gerekir.

    Doğru ihtiyaca bağlı olmalıdır.
    Development ve static analysis kapılarından geçmelidir.
    Test pyramid’e uygun testlerle doğrulanmalıdır.
    Fonksiyonel test otomasyonu iş davranışını kontrol etmelidir.
    Integration, SIT ve system testlerle sistem etkisi görülmelidir.
    Security ve performance kontrollerinden geçmelidir.
    Deployment kontrollü yapılmalıdır.
    Canlı ortam observability ile izlenmelidir.
    AI agent davranışları test edilebilir ve denetlenebilir olmalıdır.

    Ama bütün bunlar her projeye aynı ağırlıkta uygulanmak zorunda değildir.

    Doğru yaklaşım risk bazlıdır.

    Kritik sistemlerde kapılar daha sıkı olur.
    Düşük riskli sistemlerde daha hafif uygulanabilir.

    Önemli olan AI ile hızlanan üretimi kontrolsüz bırakmamaktır.

    Çünkü yeni dönemin temel dengesi değişmiyor:

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

    Quality gates, bu dengenin çalışmasını sağlayan güven zinciridir.

  • 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

  • AI ile Kod Yazmak Eski Oyun

    Yazılım dünyasında uzun zamandır en değerli şeylerden biri kod yazabilmekti.

    Bir ihtiyacı anlamak, onu teknik tasarıma çevirmek, kodlamak, test etmek ve canlıya almak ciddi emek isterdi. Hâlâ da istiyor. Ama artık bu sürecin bazı parçaları eskisi gibi değil.

    Bugün AI destekli araçlar bize kod öneriyor, test yazıyor, hata açıklıyor, dokümantasyon hazırlıyor, hatta bazen var olan kodu bizden daha sabırlı şekilde analiz ediyor.

    Bu gerçekten büyük bir değişim.

    Ama bence asıl değişim sadece “AI kod yazabiliyor” noktasında değil.

    Asıl değişim, yazılım geliştirme sürecinin baştan sona yeniden düşünülmesi gerektiği yerde başlıyor.

    Çünkü artık mesele sadece şu değil:

    Daha hızlı nasıl kod yazarız?

    Asıl mesele şu:

    Daha hızlı üretilen kodu nasıl güvenilir şekilde teslim ederiz?

    Bence önümüzdeki dönemin en önemli farkı burada oluşacak.

    Süreç aynı görünüyor:

    Analiz → Tasarım → Kod → Test → Dağıtım

    Ama yaklaşım değişiyor.

    Artık her aşama AI ile desteklenebilir, ama her aşama aynı zamanda daha güçlü doğrulama, izlenebilirlik ve yönetişim gerektirir.

    AI analiz taslağı çıkarabilir.
    Ama ihtiyacın doğruluğunu iş birimiyle netleştirmek gerekir.

    AI mimari öneri sunabilir.
    Ama kararın güvenlik, ölçeklenebilirlik ve sürdürülebilirlik açısından değerlendirilmesi gerekir.

    AI kod yazabilir.
    Ama kodun standartlara, mimariye ve kalite kurallarına uygunluğu kanıtlanmalıdır.

    AI test senaryosu üretebilir.
    Ama test kapsamı, risk ve iş kritikliğiyle ilişkilendirilmelidir.

    AI dokümantasyon hazırlayabilir.
    Ama dokümantasyonun yaşayan sistemle uyumlu kalması gerekir.

    Bu yüzden “AI ile kod yazmak” bana göre artık oyunun sadece küçük bir parçası.

    Yeni oyun şu:

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

    Geleceğin yazılım geliştirme süreci sadece daha hızlı kod üreten ekiplerin değil; daha hızlı üretilen çıktıyı güvenilir, izlenebilir ve yönetilebilir şekilde teslim eden ekiplerin avantajlı olduğu bir döneme gidiyor.

    Bu da bizi klasik CI/CD yaklaşımının ötesine taşıyor.

    Artık sadece kodun build edilmesi, test edilmesi ve deploy edilmesi yetmez.

    Yeni nesil yazılım teslim sürecinde şunlar da kritik hale geliyor:

    • Gereksinimden koda izlenebilirlik
    • AI tarafından üretilen çıktının doğrulanması
    • Test kapsamının riskle ilişkilendirilmesi
    • Güvenlik ve kalite kapılarının otomatik çalışması
    • Mimari kararların kayıt altına alınması
    • İnsan onayının doğru noktalarda devreye girmesi

    Bence önümüzdeki dönemde asıl farkı yaratacak kavramlardan biri de bu olacak:

    Agentic Software Delivery

    Yani sadece AI ile kod yazmak değil; analizden dağıtıma kadar yazılım teslim sürecini ajanlar, doğrulama mekanizmaları, kalite kapıları ve insan kararlarıyla birlikte yeniden tasarlamak.

    Çünkü hız tek başına yeterli değil.

    Hız + güvenilirlik + izlenebilirlik + yönetişim birlikte olduğunda gerçek dönüşüm başlıyor.

    AI ile kod yazmak artık yeni değil.

    Asıl mesele, AI ile üretilen yazılımı güvenle teslim edebilmek.

Top