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