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 testleriHer ş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.