Yusuf ŞAHİN

Yazar: Yusuf Sahin

  • 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.

  • Tek Ajan Değil, Orkestrasyon Kazanacak

    Agentic AI konuşurken çoğu zaman tek bir güçlü ajan hayal ediyoruz.

    Her şeyi anlayan, planlayan, kod yazan, test eden, dokümantasyon hazırlayan ve hatta deploy eden bir ajan.

    Kulağa etkileyici geliyor.

    Ama gerçek yazılım geliştirme bu kadar basit değil.

    Yazılım geliştirme tek bir iş değildir. Planlama, gereksinim analizi, tasarım, geliştirme, test, güvenlik, review, dokümantasyon ve release kararlarının birleşimidir.

    Bu yüzden gelecekte farkı tek bir süper ajan değil, iyi tasarlanmış bir ajan orkestrasyonu yaratacak.

    Tek ajan neden yeterli olmayabilir?

    Tek ajan fikri cazip çünkü basit görünür.

    Bir hedef verirsin.
    Ajan plan yapar.
    Kod yazar.
    Test eder.
    Sonucu teslim eder.

    Ama büyük ve kurumsal sistemlerde bu yaklaşım risklidir.

    Çünkü hata olduğunda şu soruları cevaplamak zorlaşır:

    • Gereksinim mi yanlış anlaşıldı?
    • Tasarım mı eksikti?
    • Kod mu hatalıydı?
    • Test mi yetersizdi?
    • Güvenlik riski mi gözden kaçtı?
    • Release kararı mı erken verildi?

    Her şeyi tek bir ajana verdiğimizde, sorumluluklar bulanıklaşır.

    Oysa yazılım geliştirme farklı uzmanlıkların birlikte çalışmasını gerektirir.

    AI-native dünyada da bu değişmez. Sadece bazı görevlerde insanlara AI ajanları eşlik etmeye başlar.

    Agent orchestration nedir?

    Agent orchestration, farklı AI ajanlarının bir süreç içinde kontrollü, sıralı ve izlenebilir şekilde birlikte çalışmasıdır.

    Basitçe şu sorulara cevap verir:

    Hangi ajan, ne zaman, hangi bağlamla, hangi yetkiyle çalışacak?

    Ürettiği çıktı nasıl doğrulanacak?

    Hangi noktada insan karar verecek?

    Bu sadece teknik bir konu değildir.

    Aynı zamanda süreç tasarımıdır.

    Çünkü ajanları sisteme eklemek kolaydır. Zor olan, onların kontrolsüz hareket etmeden güvenilir değer üretmesini sağlamaktır.

    Yazılım geliştirmede farklı ajanlar olabilir

    AI-native bir yazılım geliştirme sürecinde farklı ajanlar farklı görevler üstlenebilir.

    Örneğin:

    Planning Agent
Requirement Agent
Architecture Agent
Development Agent
Test Agent
Security Agent
Review Agent
Documentation Agent
Release Agent

    Planning Agent gelen talebin kapsamını ve risklerini özetleyebilir.

    Requirement Agent belirsiz gereksinimleri ve eksik kabul kriterlerini işaretleyebilir.

    Architecture Agent tasarım alternatifleri ve mimari etkiler konusunda öneri sunabilir.

    Development Agent kod taslağı hazırlayabilir.

    Test Agent test senaryoları ve edge case’ler önerebilir.

    Security Agent güvenlik risklerini görünür hale getirebilir.

    Review Agent değişikliğin etkisini ve dikkat edilmesi gereken noktaları özetleyebilir.

    Documentation Agent teknik açıklama, release notu veya karar kaydı hazırlayabilir.

    Release Agent canlıya alma öncesi kontrol listesi ve risk değerlendirmesi çıkarabilir.

    Ama burada kritik nokta şu:

    Ajanların varlığı tek başına yeterli değildir.

    Asıl mesele bu ajanların nasıl birlikte çalıştığıdır.

    Orkestrasyon neden önemli?

    Çünkü AI hızlı çıktı üretebilir.

    Ama hızlı çıktı her zaman güvenilir çıktı değildir.

    Bir ajan yanlış bağlamla doğru görünen bir cevap üretebilir.
    Bir ajan eksik gereksinim üzerinden kod yazabilir.
    Bir ajan test üretir ama kritik senaryoları atlayabilir.
    Bir ajan insan onayı gereken bir kararı kendi vermeye çalışabilir.

    Bu yüzden agentic sistemlerde sadece “ajan çalışıyor mu?” sorusu yetmez.

    Daha önemli soru şudur:

    Ajan doğru bağlamda, doğru sınırlar içinde ve doğru kontrol noktalarından geçerek mi çalışıyor?

    Orkestrasyonun değeri burada ortaya çıkar.

    İyi orkestrasyon, ajanları sadece sıraya koymaz. Onların neyi yapabileceğini, neyi yapamayacağını, nerede durması gerektiğini ve çıktısının nasıl doğrulanacağını belirler.

    Context olmadan orkestrasyon olmaz

    Ajanların doğru çalışabilmesi için doğru bağlama ihtiyacı vardır.

    Context yoksa ajanlar tahmin eder.

    Bu yüzden ajanlara şu bilgiler kontrollü şekilde verilebilir:

    • iş ihtiyacı,
    • kabul kriterleri,
    • mimari kararlar,
    • kod standartları,
    • test stratejisi,
    • güvenlik politikaları,
    • deployment kuralları,
    • önceki kararlar.

    Ama burada “her ajana her şeyi verelim” yaklaşımı da doğru değildir.

    Her ajan sadece ihtiyacı olan bağlama erişmelidir.

    Fazla context, kaliteyi artırmak yerine kafa karıştırabilir. Ayrıca güvenlik ve gizlilik açısından da risk oluşturabilir.

    İyi orkestrasyon, ajana doğru zamanda doğru context’i verir.

    Yetki sınırları net olmalı

    Her ajan her şeyi yapamamalıdır.

    Örneğin:

    • Requirement Agent gereksinim önerebilir ama onaylayamaz.
    • Development Agent kod yazabilir ama production’a çıkaramaz.
    • Test Agent test üretebilir ama kaliteyi tek başına garanti edemez.
    • Security Agent risk işaretleyebilir ama riski kabul edemez.
    • Release Agent kontrol listesi hazırlayabilir ama kritik canlıya alma kararını tek başına veremez.

    Bu ayrım çok önemlidir.

    Çünkü agentic sistemlerde en büyük risklerden biri, öneri üretmesi gereken bir ajanın karar verici gibi davranmasıdır.

    Bu yüzden her ajan için sınırlar net olmalıdır:

    • Ne yapabilir?
    • Neyi yapamaz?
    • Hangi veriye erişebilir?
    • Hangi aracı kullanabilir?
    • Hangi durumda durmalıdır?
    • Hangi durumda insana sormalıdır?

    Bu sınırlar olmadan agent orchestration güvenilir hale gelmez.

    İnsan nerede devreye girmeli?

    Agent orchestration tasarlarken en kritik konulardan biri insan karar noktalarıdır.

    Her adımda insan onayı istersek süreç yavaşlar.

    Hiçbir yerde insan onayı istemezsek risk artar.

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

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

    Örneğin insan şu durumlarda devreye girmelidir:

    • kapsam netleşirken,
    • kritik mimari karar verilirken,
    • yüksek riskli kod değişikliğinde,
    • güvenlik istisnası oluştuğunda,
    • production release öncesinde,
    • müşteri etkisi yüksek bir değişiklikte,
    • AI çıktısı belirsiz veya düşük güvenliyse.

    Bunu şöyle özetleyebiliriz:

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

    Yani insan her küçük işi onaylayan kişi olmamalı.

    İnsan, gerçekten karar gereken noktada devreye girmeli.

    İyi orkestrasyon nasıl görünür?

    İyi bir agent orchestration yapısında:

    • ajanların görevleri nettir,
    • yetki sınırları bellidir,
    • context kontrollüdür,
    • çıktılar doğrulanır,
    • kalite kapıları vardır,
    • insan doğru noktada devreye girer,
    • süreç sonradan izlenebilir,
    • release kararı kanıta dayanır.

    Kötü orkestrasyonda ise genellikle bunun tersi olur:

    • her işi tek ajan yapmaya çalışır,
    • sınırlar belirsizdir,
    • context dağınıktır,
    • çıktılar doğrulanmadan kullanılır,
    • insan ya çok geç devreye girer ya da hiç girmez,
    • hata olunca nerede başladığı anlaşılamaz.

    Bu yüzden başarı sadece iyi model seçmekle gelmez.

    Başarı, iyi orkestrasyon tasarımıyla gelir.

    Sonuç

    Agentic AI çağında yazılım geliştirme sadece daha güçlü bir ajan bulma meselesi değildir.

    Asıl mesele, farklı ajanların yazılım teslimat sürecinde nasıl birlikte çalışacağını tasarlamaktır.

    Tek ajan hızlı çıktı üretebilir.

    Ama güvenilir yazılım teslimatı için daha fazlası gerekir:

    Context gerekir.
    Yetki sınırları gerekir.
    Quality gate gerekir.
    İzlenebilirlik gerekir.
    İnsan karar noktaları gerekir.
    Audit trail gerekir.

    Bu yüzden gelecekte kazanan yaklaşım tek bir süper ajan olmayacak.

    Kazanan yaklaşım, iyi orkestre edilmiş ajan sistemi olacak.

    Çünkü yazılım geliştirme tek bir iş değil; birçok kararın, kontrolün ve uzmanlığın birleşimidir.

    Bence yeni dönemin güçlü cümlesi şu:

    Tek ajan değil, orkestrasyon kazanacak.

    Ve yine aynı denge:

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

    Serinin devamı

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

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

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

    Serinin üçüncü yazısı:
    Pipeline Artık CI/CD Değil, Karar Zinciri

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

  • 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-Native SDLC Nedir?

    Bir önceki yazıda şunu söylemiştik:

    AI ile kod yazmak artık yeni oyun değil.
    Yeni oyun, AI ile üretilen yazılımı güvenilir şekilde teslim edebilmek.

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

    Bugün birçok ekip AI araçlarını yazılım geliştirme sürecinde kullanmaya başladı. Kod yazdırıyoruz, hata açıklatıyoruz, test taslakları oluşturuyoruz, dokümantasyon hazırlatıyoruz, bazen de mevcut kodu analiz ettiriyoruz.

    Bunların hepsi değerli.

    Ama burada önemli bir ayrım var.

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

    Bu ayrımı doğru anlamak önemli. Çünkü önümüzdeki dönemde AI sadece geliştiricinin yanında duran bir yardımcı olarak kalmayacak. Yazılım geliştirme yaşam döngüsünün farklı aşamalarında aktif görev alan bir aktöre dönüşecek.

    İşte bu noktada karşımıza AI-Native SDLC kavramı çıkıyor.

    SDLC neydi?

    Önce en temel yerden başlayalım.

    SDLC, yani Software Development Life Cycle, yazılım geliştirme yaşam döngüsüdür.

    Basitçe bir yazılım fikrinin veya iş ihtiyacının ilk değerlendirme aşamasından canlıya alınmasına ve sonrasında bakımına kadar geçen süreci ifade eder.

    Klasik olarak şu adımlarla anlatılır:

    • planlama,
    • ihtiyaç / gereksinim analizi,
    • tasarım,
    • geliştirme,
    • test ve doğrulama,
    • canlıya alma,
    • bakım, izleme ve sürekli iyileştirme.

    Burada küçük ama önemli bir ayrım var.

    Bir ihtiyaç veya fikir elbette sürecin başlangıç sebebidir. Yani çoğu zaman önce bir iş ihtiyacı, problem, fırsat veya talep ortaya çıkar.

    Ama bunu SDLC fazı olarak anlatırken daha doğru akış şudur:

    Önce bu ihtiyacın neden önemli olduğu, kapsamı, hedefi, önceliği ve yapılabilirliği planlama aşamasında değerlendirilir. Sonra gereksinimler daha detaylı analiz edilir ve netleştirilir.

    Yani “ihtiyaç ortaya çıkar” ifadesi sürecin tetikleyicisidir.
    “İhtiyaç / gereksinim analizi” ise planlamadan sonra gelen daha sistematik analiz aşamasıdır.

    Bu ayrımı net yapmak, yazılım geliştirme sürecini doğru anlatmak açısından önemlidir.

    Güvenlik ve kalite ayrı bir son adım değildir

    SDLC anlatılırken bazen güvenlik ve kalite kontrolleri testten sonra gelen ayrı bir aşama gibi düşünülür.

    Ama modern yazılım geliştirme yaklaşımında bu eksik bir bakış olur.

    Güvenlik, kalite, izlenebilirlik ve doğrulama sadece sürecin sonunda yapılan kontroller değildir. Bunlar bütün yaşam döngüsüne yayılması gereken yatay disiplinlerdir.

    Yani güvenlik sadece “testten sonra bakalım” konusu değildir.

    Planlama aşamasında da vardır.
    Gereksinim analizinde de vardır.
    Tasarımda da vardır.
    Geliştirmede de vardır.
    Testte de vardır.
    Canlıya alma ve bakım süreçlerinde de vardır.

    Bu ayrım, AI-native SDLC konusunu anlamak için özellikle önemli.

    Çünkü AI sürece dahil olduğunda sadece daha hızlı kod üretmez. Aynı zamanda daha hızlı öneri, daha hızlı analiz taslağı, daha hızlı test senaryosu ve daha hızlı dokümantasyon da üretir.

    Bu hızın güvenilir olması için sürecin kendisinin iyi tasarlanmış olması gerekir.

    Klasik SDLC’de iş nasıl ilerler?

    Klasik dünyada yazılım geliştirme süreci büyük ölçüde insan ekipleri tarafından yürütülür.

    Bir fikir, problem, fırsat veya iş ihtiyacı ortaya çıkar. Bu, süreci başlatan tetikleyicidir.

    Sonra ekip bu ihtiyacı planlama açısından değerlendirir:

    • Bu iş neden yapılmalı?
    • Hedef nedir?
    • Kapsam ne olabilir?
    • Öncelik seviyesi nedir?
    • Yaklaşık efor ve risk nedir?
    • Hangi ekipler veya sistemler etkilenir?
    • Bu iş gerçekten yapılabilir mi?

    Planlama aşamasından sonra ihtiyaç / gereksinim analizi daha detaylı yapılır.

    Bu aşamada şu sorular netleşir:

    • Kullanıcı neye ihtiyaç duyuyor?
    • İş kuralı nedir?
    • Kabul kriterleri nelerdir?
    • Sınırlar ve varsayımlar nelerdir?
    • Hangi durumlar kapsam dışıdır?
    • Başarı kriteri nedir?

    Sonra tasarım yapılır.
    Geliştirme başlar.
    Testler ve doğrulama yapılır.
    Canlıya alma süreci yürütülür.
    Sonrasında bakım, izleme ve sürekli iyileştirme devam eder.

    Bu akış hâlâ geçerli.

    AI geldi diye yazılım geliştirme bir anda bambaşka bir şeye dönüşmüş değil.

    Hâlâ doğru problemi anlamak gerekiyor.
    Hâlâ iyi planlama yapmak gerekiyor.
    Hâlâ gereksinimleri netleştirmek gerekiyor.
    Hâlâ iyi tasarım yapmak gerekiyor.
    Hâlâ test etmek gerekiyor.
    Hâlâ güvenliği düşünmek gerekiyor.
    Hâlâ canlıya alma riskini yönetmek gerekiyor.

    Ama AI bu sürecin içine girdiğinde hız, rol dağılımı ve sorumluluk dengesi değişmeye başlıyor.

    Eskiden insanlar birçok adımı tamamen manuel yürütüyordu.

    Şimdi bazı adımlarda AI destek veriyor.
    Bazı adımlarda öneri üretiyor.
    Bazı adımlarda taslak hazırlıyor.
    Bazı adımlarda alternatifleri gösteriyor.
    Bazı adımlarda ise doğrudan sürecin parçası haline geliyor.

    İşte klasik SDLC ile AI-native SDLC arasındaki fark burada başlıyor.

    AI destekli geliştirme nedir?

    AI destekli geliştirme, bugün en çok gördüğümüz kullanım şeklidir.

    Geliştirici merkezde durur.
    AI ise ona yardımcı olur.

    Örneğin geliştirici:

    • bir fonksiyon yazdırır,
    • mevcut kodu açıklatır,
    • hata mesajını analiz ettirir,
    • unit test taslağı oluşturur,
    • SQL sorgusu optimize ettirir,
    • dokümantasyon metni hazırlatır,
    • refactoring önerisi alır.

    Bu yaklaşımda AI bir yardımcıdır.

    Geliştirici ne yapmak istediğini bilir, AI’dan destek ister ve çıkan sonucu değerlendirir.

    Bu gerçekten faydalı bir aşama.

    Çünkü geliştiriciye hız kazandırır.
    Rutin işleri azaltır.
    Boş sayfa korkusunu düşürür.
    Alternatifleri hızlıca görmeyi sağlar.
    Bazı hataları daha erken fark etmeye yardımcı olur.

    Ama bu modelde süreç hâlâ büyük ölçüde klasik SDLC’dir.

    Sadece bazı adımlarda AI yardımı vardır.

    Yani ekip AI kullanıyor olabilir, ama bu tek başına o ekibin AI-native çalıştığı anlamına gelmez.

    AI-native geliştirme nedir?

    AI-native geliştirme daha farklı bir şeydir.

    Burada AI sadece geliştiricinin ara sıra kullandığı bir yardımcı araç değildir. Yazılım geliştirme sürecinin tasarımında baştan itibaren dikkate alınan bir aktördür.

    Yani süreç şu soruyla tasarlanır:

    Bu yazılım geliştirme akışında AI hangi adımlarda aktif rol alacak, hangi sınırlarla çalışacak ve ürettiği çıktı nasıl doğrulanacak?

    Bu soru çok önemli.

    Çünkü AI-native yaklaşımda mesele sadece kod yazdırmak değildir.

    Mesele; planlamadan teslimata kadar olan süreci AI, otomasyon, kalite kapıları, izlenebilirlik ve insan kararlarıyla yeniden tasarlamaktır.

    Bir örnek düşünelim.

    Klasik yaklaşımda önce bir fikir, problem veya iş ihtiyacı ortaya çıkar. Ekip bunu planlar, gereksinimleri netleştirir, tasarım yapar, geliştirir, test eder ve yayınlar.

    AI-native yaklaşımda ise süreç şöyle çalışabilir:

    • Bir fikir, problem veya iş ihtiyacı kayıt altına alınır.
    • AI ilk kapsam, hedef, varsayım ve risk taslağı çıkarır.
    • Ekip planlama kararlarını netleştirir.
    • AI gereksinim analizi için eksik ve belirsiz noktaları işaretler.
    • Kabul kriterleri için taslak önerir.
    • İşin teknik parçalara ayrılmasına yardımcı olur.
    • Tasarım alternatifleri üretir.
    • Kod taslağı hazırlar.
    • Test senaryoları çıkarır.
    • Güvenlik açısından dikkat edilmesi gereken noktaları önerir.
    • Dokümantasyon hazırlar.
    • Release öncesi kontrol listesi üretir.
    • Sistem quality gate’leri çalıştırır.
    • İnsan kritik noktalarda karar verir.

    Burada AI artık sadece “kod yazan yardımcı” değildir.

    Sürecin içinde görev alan bir katılımcıdır.

    Ama önemli bir nokta var:

    AI’ın sürecin içinde aktif rol alması, onun kontrolsüz hareket edeceği anlamına gelmemelidir.

    Tam tersine, AI-native SDLC’nin sağlıklı çalışması için sınırlar, kurallar, kalite kapıları ve insan karar noktaları daha net tanımlanmalıdır.

    AI destekli ile AI-native arasındaki fark

    Bu farkı basitçe şöyle düşünebiliriz:

    AI destekli geliştirme:
Geliştirici işi yapar, AI yardımcı olur.

AI-native geliştirme:
Süreç AI, otomasyon, kalite kapıları ve insan kararları etrafında yeniden tasarlanır.

    AI destekli geliştirmede soru şudur:

    AI bana bu işi yaparken nasıl yardımcı olur?

    AI-native geliştirmede soru şudur:

    Bu işi AI ile birlikte daha güvenilir, izlenebilir ve ölçeklenebilir şekilde nasıl tasarlarız?

    Bence asıl kırılma bu ikinci soruda.

    Çünkü birincisi bireysel üretkenlik sorusudur.

    İkincisi organizasyonel yazılım teslimat sistemi sorusudur.

    Bir ekip AI destekli araçlarla daha hızlı kod yazabilir.

    Ama AI-native olabilmesi için sadece hız yetmez.

    Sürecin şu sorulara da cevap verebilmesi gerekir:

    • AI hangi aşamada devreye giriyor?
    • Hangi veriye erişebiliyor?
    • Hangi çıktıyı üretiyor?
    • Bu çıktı nasıl doğrulanıyor?
    • Hangi durumda insan onayı gerekiyor?
    • Hangi kalite kapısından geçmeden ilerleyemiyor?
    • Sonradan denetlenebilir bir iz bırakıyor mu?

    Bu sorulara cevap yoksa, ortada AI kullanımı vardır ama olgun bir AI-native SDLC yoktur.

    AI-native SDLC’de roller değişir

    AI-native SDLC, insanların rolünü ortadan kaldırmaz.

    Ama insanların rolünü değiştirir.

    Geliştirici artık sadece kod yazan kişi değildir.
    Sistemi anlayan, AI çıktısını değerlendiren, mimari sınırları koruyan ve doğru kararı veren kişidir.

    Analist artık sadece gereksinim dokümanı yazan kişi değildir.
    AI tarafından önerilen eksikleri, çelişkileri ve kabul kriterlerini değerlendiren kişidir.

    Test uzmanı artık sadece manuel test yapan kişi değildir.
    AI’ın ürettiği test senaryolarını doğrulayan, eksikleri gören ve test stratejisini yöneten kişidir.

    DevOps artık sadece pipeline çalıştıran ekip değildir.
    AI çıktılarının hangi kalite kapılarından geçeceğini tasarlayan ekip haline gelir.

    Güvenlik ekibi artık sadece canlıya almadan önce kontrol yapan ekip değildir.
    Güvenliğin planlama, gereksinim analizi, tasarım, geliştirme, test ve operasyon süreçlerine nasıl gömüleceğini belirleyen ekip haline gelir.

    Yönetici ise sadece hız ve kapasiteye bakmaz.
    Risk, kalite, doğrulama ve teslimat kanıtına da bakmak zorunda kalır.

    Bu yüzden AI-native SDLC sadece teknik bir konu değildir.

    Aynı zamanda organizasyonel bir dönüşümdür.

    Yeni SDLC’de ajanlar olabilir

    AI-native SDLC zamanla agentic bir yapıya dönüşebilir.

    Yani tek bir AI yardımcısı yerine, farklı görevler için farklı ajanlar çalışabilir.

    Örneğin:

    Intake Agent
Planning Agent
Requirement Agent
Architecture Agent
Development Agent
Test Agent
Security Agent
Review Agent
Documentation Agent
Release Agent

    Her ajan farklı bir konuda görev alabilir.

    Intake Agent gelen fikri, problemi veya talebi kayıt altına almaya yardımcı olabilir.
    Planning Agent kapsam, hedef, öncelik ve risk taslağı çıkarabilir.
    Requirement Agent gereksinimlerdeki eksik, çelişkili veya belirsiz noktaları işaretleyebilir.
    Architecture Agent tasarım alternatifleri önerebilir.
    Development Agent kod taslağı hazırlayabilir.
    Test Agent test senaryoları oluşturabilir.
    Security Agent riskleri işaretleyebilir.
    Review Agent kodu ve değişiklik etkisini inceleyebilir.
    Documentation Agent teknik açıklamaları hazırlayabilir.
    Release Agent canlıya alma kontrol listesini çıkarabilir.

    Ama burada kritik nokta şudur:

    Ajanların varlığı tek başına yeterli değildir.

    Önemli olan bu ajanların nasıl orkestre edildiğidir.

    Hangi ajan ne zaman çalışacak?
    Hangi veriyle çalışacak?
    Hangi aracı kullanabilecek?
    Hangi çıktıyı üretecek?
    Hangi durumda durup insana soracak?
    Hangi kalite kapısından geçmeden ilerleyemeyecek?

    Bu sorular cevaplanmadan kurulan agentic yapı risklidir.

    Çünkü AI-native SDLC’nin amacı sadece otomasyon değildir.

    Amaç güvenilir otomasyondur.

    Quality gate olmadan AI-native olmaz

    AI-native SDLC’de en önemli konulardan biri quality gate yaklaşımıdır.

    Çünkü AI çıktı üretebilir.

    Ama her çıktı doğru değildir.
    Her kod güvenli değildir.
    Her test yeterli değildir.
    Her öneri mimariye uygun değildir.
    Her açıklama gerçeği tam olarak yansıtmayabilir.

    Bu yüzden AI çıktısının teslimat sürecine girmeden önce doğrulanması gerekir.

    Quality gate dediğimiz şey burada devreye girer.

    Örneğin:

    • testler geçti mi?
    • güvenlik taraması temiz mi?
    • mimari kurallara uyuyor mu?
    • kod standardına uygun mu?
    • ilgili gereksinim ile bağlantısı var mı?
    • değişiklik açıklanabilir mi?
    • insan onayı gerekiyor mu?
    • release riski kabul edilebilir mi?

    Bu kontroller yoksa, AI-native olduğunu düşündüğümüz şey aslında sadece hızlı ve kontrolsüz üretim olabilir.

    Bu yüzden ben bu dönemi şu cümleyle özetlemeyi seviyorum:

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

    AI-native SDLC’nin kalbinde bu denge var.

    AI-native SDLC neden şimdi önemli?

    Çünkü yazılım geliştirme ekipleri artık sadece daha fazla iş yapmak zorunda değil.

    Daha hızlı, daha güvenli, daha izlenebilir ve daha kontrollü teslimat yapmak zorunda.

    Özellikle kurumsal dünyada yazılım geliştirme sadece “çalışan kod” üretmekten ibaret değil.

    Şirketler şunu bilmek istiyor:

    • Bu değişiklik neden yapıldı?
    • Kim istedi?
    • Hangi ihtiyaca bağlı?
    • Hangi testlerden geçti?
    • Hangi riskler değerlendirildi?
    • Kim onayladı?
    • Ne zaman canlıya alındı?
    • Sorun çıkarsa geri dönüş planı var mı?
    • Sonradan denetlenebilir mi?

    AI-native SDLC bu sorulara daha sistematik cevap verebilmelidir.

    Sadece kod üretmemeli.

    Kanıt da üretmelidir.

    Çünkü AI ile üretilen iş arttıkça, o işin nasıl doğrulandığı daha önemli hale gelir.

    AI-native olmak için nereden başlanır?

    AI-native SDLC’ye geçmek için hemen tüm süreci ajanlarla doldurmak gerekmez.

    Hatta bence doğru başlangıç bu değildir.

    Daha sağlıklı başlangıç, mevcut yazılım geliştirme sürecine dürüstçe bakmaktır.

    Şu sorular sorulmalı:

    Yazılım geliştirme sürecimizde en çok nerede zaman kaybediyoruz?

    Hangi adımlar tekrar ediyor?

    Hangi kararlar belirsiz kalıyor?

    Hangi kontroller manuel yapılıyor?

    Hangi kalite kapıları eksik?

    AI çıktısını bugün nasıl doğruluyoruz?

    Bu sorulara cevap verdikten sonra küçük adımlarla başlanabilir.

    Örneğin:

    • planlama taslağı oluşturma,
    • gereksinim özeti çıkarma,
    • kabul kriteri önerme,
    • task kırılımı hazırlama,
    • test senaryosu üretme,
    • kod review destekleme,
    • dokümantasyon hazırlama,
    • release checklist oluşturma,
    • risk analizi çıkarma.

    Ama her adımda şu ilke korunmalı:

    AI’ın ürettiği şey doğrudan doğru kabul edilmemeli; sistem tarafından doğrulanmalı ve gerektiğinde insan tarafından değerlendirilmelidir.

    Bu yaklaşım yavaş gibi görünebilir.

    Ama uzun vadede daha sağlıklıdır.

    Çünkü amaç sadece AI kullanmak değil, AI ile güvenilir bir yazılım teslimat sistemi kurmaktır.

    AI-native SDLC bir araç meselesi değildir

    Burada en sık yapılan hatalardan biri şu:

    Bir AI coding tool kullanınca AI-native olunduğunu sanmak.

    Hayır.

    Bir ekibin AI tool kullanması onu otomatik olarak AI-native yapmaz.

    AI-native olmak bir araç meselesi değil, sistem tasarımı meselesidir.

    Şirketin planlama disiplini zayıfsa,
    backlog yapısı dağınıksa,
    acceptance criteria belirsizse,
    test otomasyonu yetersizse,
    mimari kurallar tanımlı değilse,
    review süreci yüzeyselse,
    release kararı izlenebilir değilse,

    AI tool kullanmak tek başına yeterli olmaz.

    Hatta bazı durumlarda karmaşayı büyütebilir.

    Çünkü AI kötü süreçleri düzeltmez.

    Sadece mevcut süreci hızlandırır.

    Süreç iyiyse, iyi sonucu hızlandırır.
    Süreç kötüyse, karmaşayı hızlandırır.

    Bu yüzden AI-native SDLC konuşurken sadece araç listesi değil, süreç tasarımı konuşmak gerekir.

    Sonuç

    AI-Native SDLC, AI’ın yazılım geliştirme sürecinde sadece yardımcı bir araç olarak değil, sürecin aktif bir parçası olarak konumlandığı yeni bir yaklaşımdır.

    Ama bu yaklaşımın sağlıklı çalışması için sadece AI kullanmak yetmez.

    Planlama gerekir.
    Gereksinim analizi gerekir.
    Süreç gerekir.
    Kalite kapıları gerekir.
    İzlenebilirlik gerekir.
    Doğrulama gerekir.
    İnsan kararı gerekir.

    Bence önümüzdeki dönemde yazılım ekipleri arasındaki fark sadece hangi AI aracını kullandıklarıyla oluşmayacak.

    Asıl fark, AI’ı yazılım teslimat sisteminin içine ne kadar güvenilir şekilde yerleştirdikleriyle oluşacak.

    Çünkü AI ile kod üretmek kolaylaşacak.

    Ama AI ile güvenilir yazılım teslim etmek hâlâ iyi tasarlanmış bir SDLC gerektirecek.

    Bu yüzden yeni dönemin temel sorusu şu olmalı:

    AI bize nasıl daha hızlı kod yazdırır?

    değil.

    AI ile yazılım teslimat sistemimizi nasıl daha güvenilir hale getiririz?

    Bence AI-native SDLC’nin gerçek anlamı burada başlıyor.

    Serinin devamı

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

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

    Serinin sonraki yazısı:
    Pipeline Artık CI/CD Değil, Karar Zinciri

  • 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.

  • Blog Güncellemesi

    Blog yeni temaya güncellendi

  • Blog Güncellemesi

    Eski blog verileri de taşınarak güncelleme yapıldı

  • Google – Kişi Bulucu

    Depremzede ve yakınlarına yardımcı olmak için Google’ın hazırladığı kişi bulucu aracını kullanabilirsiniz…


    Source: rss

Top