Agent'lar ve Orchestration
SDLC'nin Sonraki Evrimi: ADLC (Agent Development Lifecycle)
The Next Evolution of SDLC: ADLC
ADLC iki şeyi birden anlatıyor: agent üretmenin yaşam döngüsü ve yazılımı agent'larla üretmenin yaşam döngüsü; 2026'da ikisi de araçlaştı, ortak merkezleri hâlâ eval ve kapanan öğrenme döngüsü.
SDLC'nin determinizm, kesin girdi ve bitiş çizgisi varsayımları Agent'larda kırılır; ADLC'nin merkezinde eval seti ve üretimden beslenen kapalı döngü durur.
Salesforce, IBM, AWS ve eval araç üreticileri çerçeveyi yayıyor; terim henüz standart değil ve bir kesim bunu MLOps'un yeniden paketlenmesi sayıyor.
Zihinsel model
SDLC bir köprü inşaatıysa ADLC bir bahçedir: yayın bitiş değil, sürekli gözlem ve budamanın başlangıcıdır.
Neden
- Model aynı girdiye farklı çıktı verir; doğruluk tek değer değil, eval'in tanımladığı kabul edilebilir davranış aralığıdır.
- Kod değişmeden model sürümü değişince davranış kayar; bu regresyonu ancak sabit, versiyonlanan bir eval seti yakalar.
- Kodlama Agent'ı yazmayı ucuzlatınca darboğaz niyeti Spec'e dökmeye ve büyük diff'i doğrulamaya kayar.
Kanıt
AI kullanıcılarının yüzde 66'sı kodlama Agent'ı kullanıyor, ama AI çıktısına karar düzeyinde güvenenler küçük bir azınlık.
The Register, Stack Overflow Developer Survey (2026)Gartner, agentic AI projelerinin yüzde 40'tan fazlasının maliyet, belirsiz değer ve zayıf risk kontrolü yüzünden iptal edileceğini öngörüyor.
Gartner (2025)DORA, AI benimsemesinin önce geçici bir verim düşüşü getirdiğini ve nedenlerinden birinin inceleme yükü olduğunu buldu.
InfoQ, DORA ROI of AI-Assisted Software Development (2026)Karşı görüş
Terim standart değil ve bileşenlerin çoğu MLOps'tan tanıdık; yeni bir döngü adı yalnızca süreç yükü ekleyebilir. Uzun Spec'leri incelemek de kod incelemekten yorucu olabilir ve Agent'lar Spec'e her zaman uymaz.
Kavramlar
Pratikte
- İlk prototipten önce temsilci girdiler ve kabul kriterleriyle küçük bir eval seti yazın.
- Model sürümünü sabitleyin; yeni sürümü eval setinden geçirip kademeli olarak geçin.
- Üretimde olumsuz işaretlenen her konuşmayı etiketleyip eval setine yeni vaka olarak ekleyin.
SDLC, deterministik yazılım için kuruldu: gereksinim yaz, kodla, test et, yayınla, bakımını yap. LLM tabanlı agent'lar hem ürünün kendisi hem de onu geliştiren ekip üyesi haline gelince bu döngünün birçok varsayımı esniyor. ADLC terimi bugün iki anlamda kullanılıyor: Salesforce, IBM ve HoneyHive gibi kaynaklarda Agent Development Lifecycle, yani agent inşa etme ve işletme disiplini; diğer tarafta yazılımı AI agent'larıyla geliştirme süreci, en bilinen örneği AWS'nin Temmuz 2025'te duyurduğu AI-DLC. Ekim 2026 itibarıyla ikinci aile araçlaştı: AWS'nin açık kaynak AI-DLC iş akışları Claude Code, Codex ve Copilot gibi agent'larda insan onay kapılarıyla çalışıyor, GitHub'ın Spec Kit'i spec-driven development'ı yaygınlaştırdı. Kodlama agent'ı artık ana akım: Stack Overflow 2026 anketinde AI kullanıcılarının %66'sı kodlama agent'ı kullanıyor, ama yalnızca yaklaşık %7'si AI çıktısına önemli kararlarda güveniyor. Gartner'ın 2025 tahmini de hatırlatıcı: agentic AI projelerinin %40'tan fazlası 2027 sonuna kadar iptal edilecek. Fark, eval ve yönetişimi baştan kuran ekiplerde.
Çıkarımlar
- ADLC'den bahsederken önce hangi anlamı kastettiğinizi söyleyin: ajan inşa etmek mi, ajanla yazılım geliştirmek mi.
- Ajanlarda doğruluk tek değer değil, kabul edilebilir davranış aralığıdır; bunu eval seti tanımlar.
- İlk prototipten önce 20-30 vakalık eval seti yazın ve her değişiklikte geçme oranını kıyaslayın.
- Yayın bitiş değil başlangıç: üretimdeki her olumsuz etkileşim yeni bir eval vakasına dönüşmeli.
- Ajanla geliştirmede darboğaz kod yazmaktan niyeti tanımlamaya ve diff'i doğrulamaya kayar.
- Kodlama agent'ı ana akım oldu ama güven olmadı: 2026'da AI kullanıcılarının %66'sı agent kullanıyor, önemli kararlarda AI'a güvenen yaklaşık %7.
Alt başlıklar
Terimin güncel kullanımı: iki ADLC
ADLC Ekim 2026 itibarıyla da standartlaşmış bir terim değil, bu yüzden konuyu açarken ilk iş hangi anlamı kastettiğinizi söylemek. Birinci kullanım Agent Development Lifecycle: ajanın kendisini tasarlamak, test etmek, yayınlamak ve izlemek. Salesforce'un mimari dokümanı ideation, development, testing, deployment ve monitoring aşamaları tanımlıyor; IBM DevSecOps tabanlı bir ADLC e-kitabı yayımladı; HoneyHive Nisan 2026'da fikir doğrulamadan sürekli optimizasyona uzanan altı aşamalı bir çerçeve önerdi.
İkinci kullanım Agentic Development Lifecycle: yazılım geliştirme sürecinin kendisinin ajanlarla yürütülmesi. AWS'nin Temmuz 2025'te duyurduğu AI-DLC (AI-Driven Development Life Cycle) bu yaklaşımın en bilinen örneği; Inception, Construction ve Operations aşamaları ile sprint yerine saatler ya da günler süren Bolt adlı döngüler öneriyor.
İkisi rakip değil, iç içe geçiyor. Ajan tabanlı bir ürünü ajanlarla geliştiren bir ekip, iki döngüyü aynı anda yaşıyor. Tartışmanın başında bu ayrımı yapmak, yanlış anlamaların yarısını önler.
Ekim 2026 itibarıyla durum
Son 12 ayda ADLC kavramdan araca geçti.
Agent Development tarafında IBM, DevSecOps tabanlı ADLC e-kitabını yayımladı; HoneyHive Nisan 2026'da altı aşamalı bir çerçeve önerdi ve üretim hatalarını regresyon testine çevirmeyi son aşama yaptı. Anthropic'in Ocak 2026 eval rehberi gerçek hatalardan 20-50 görevle başlamayı ve capability ile regression eval'lerini ayırmayı önerdi. OWASP Eylül 2026'da agent'lar için runtime denetim standardı Agent Control Standard'ı bünyesine aldı.
Agentic Development tarafında AWS'nin AI-DLC'si açık kaynak iş akışlarına dönüştü: awslabs/aidlc-workflows deposu beş faz, insan onay kapıları ve denetim izi tanımlıyor. GitHub'ın Spec Kit'i spec-driven development'ın en bilinen aracı oldu.
Rakamlar: Stack Overflow 2026 anketinde AI kullanıcılarının %66'sı kodlama agent'ı kullanıyor, Claude Code (%66) ve GitHub Copilot (%59) başta. Ama yalnızca yaklaşık %7'si AI çıktısına önemli kararlarda güveniyor. DORA'nın Mayıs 2026 raporu, AI benimsemesinin önce geçici bir verim düşüşü (J-curve) getirdiğini ve bunun bir nedeninin kod inceleme yükü olduğunu vurguluyor.
SDLC'nin hangi varsayımı kırılıyor
Klasik SDLC'nin temelinde üç varsayım var. Birincisi determinizm: aynı girdi aynı çıktıyı verir, test beklenen değeri kontrol eder. İkincisi kesin girdi: gereksinim dokümanı sistemin alacağı girdileri tanımlar. Üçüncüsü bitiş çizgisi: yayın, geliştirme döngüsünün sonu, sonrası bakım.
Ajanlarda üçü de esniyor. Model aynı soruya farklı cevaplar verir, bu yüzden doğruluk tek bir değere değil, kabul edilebilir bir davranış aralığına göre tanımlanır. Girdi serbest metindir; kullanıcının ne yazacağını önceden bilemezsiniz, ancak temsilci örnekler toplayabilirsiniz. Ve yayın bitiş değil başlangıçtır: Salesforce'un ifadesiyle deployment, sürekli izleme ve ayar döngüsünü başlatır.
Bir de bağımlılık değişiyor. Aynı kodu hiç değiştirmeden, sadece model sağlayıcısı sürüm güncellediği için davranış değişebilir. SDLC'de bu bir dış bağımlılık güncellemesine benzer; ADLC'de ise kalıcı bir risk sınıfı olarak süreçte yer alması gerekir.
Eval, ADLC'nin birim testi
ADLC çerçevelerinin neredeyse hepsinde ortak olan bir şey var: eval setleri birinci sınıf artefakt. HoneyHive'ın çerçevesi, başarının daha ilk aşamada programatik olarak çalıştırılabilir değerlendirmelerle tanımlanmasını ve bunların her commit'te koşmasını öneriyor.
Pratik bir başlangıç şu: ilk prototipten önce 20-30 temsilci girdi ve her biri için kabul kriteri yazın. Anthropic'in Ocak 2026 rehberi de benzer bir ölçek öneriyor: gerçek hatalardan türetilmiş 20-50 görev. Örneğin bir iade asistanı için 'sipariş 30 günden eskiyse iade önermez, nedenini açıklar'. Prototip büyüdükçe set 100-200 vakaya çıkar. Her prompt, model ya da araç değişikliğinde geçme oranını önceki sürümle kıyaslarsınız.
Anti-pattern: vibe check, yani birkaç örneği elle deneyip iyi görünüyor demek. Bu ilk demo için yeterli, üretim için değil. Küçük bir prompt değişikliği belirli bir girdi sınıfında sessizce gerileme yaratabilir ve bunu ancak sabit bir eval setiyle görürsünüz. Eval seti, ADLC'de kodun kendisi kadar versiyonlanması gereken bir varlık.
Yayın, izleme ve kapanan döngü
SDLC'de yayın sonrası izleme genellikle hata oranı, gecikme ve kaynak kullanımıyla sınırlı. ADLC'de bunlara davranış kalitesi ekleniyor: ajan doğru aracı seçti mi, kullanıcıyı gereksiz yere insana yönlendirdi mi, cevabı politikaya uygun mu?
Kademeli yayın burada daha da önemli. Yeni bir ajan sürümünü önce trafiğin yüzde 5'ine açıp eval skorları ve kullanıcı geri bildirimleriyle izlemek, geri dönüşü ucuzlatır. Tüm etkileşimleri puanlamak pahalı olduğu için risk ağırlıklı örnekleme kullanılır: yüksek tutarlı işlemler, düşük güven skorlu cevaplar ve şikâyet içeren konuşmalar daha sık incelenir.
Döngüyü kapatan adım, üretimdeki hataların eval setine geri dönmesi. Kullanıcının olumsuz işaretlediği her konuşma, etiketlenip yeni bir test vakasına dönüşür. Böylece eval seti zamanla gerçek kullanımı yansıtır. Bu adımı atlayan ekipler, testlerde yüzde 95 geçen ama sahada şikâyet toplayan bir ajanla baş başa kalır.
Agentic Development: yazılımı ajanlarla geliştirmek
ADLC'nin ikinci anlamı, geliştirme sürecinin kendisini değiştiriyor. Claude Code, Codex ve benzeri kodlama ajanları bir görevi alıp birden fazla dosyada değişiklik yapabiliyor, test çalıştırabiliyor, pull request açabiliyor. Bu durumda darboğaz kod yazmaktan, niyeti net tanımlamaya ve çıktıyı doğrulamaya kayıyor.
AWS'nin AI-DLC önerisi bu kaymayı süreç diline çeviriyor. Inception aşamasında AI iş niyetini gereksinimlere ve iş birimlerine dönüştürüyor, ekip bunu Mob Elaboration denen ortak bir çalışmada birlikte doğruluyor. Construction'da AI mimari, kod ve test öneriyor, ekip teknik kararları canlı olarak veriyor. Epic yerine Unit of Work, sprint yerine Bolt kullanılıyor.
2026'da bu öneri araca dönüştü: AWS'nin açık kaynak AI-DLC iş akışları Claude Code, Codex CLI, Cursor ve Copilot gibi agent'larda çalışıyor, her fazda insan onay kapısında duruyor ve kararların denetim izini tutuyor.
Pratikte bunun karşılığı spec-driven development: önce kabul kriterleri ve kısıtlar yazılıyor, agent bu Spec'e göre çalışıyor. GitHub'ın Spec Kit'i bu yaklaşımın en yaygın aracı. Ama Thoughtworks'ten Birgitta Böckeler'in Ekim 2025 incelemesi uyarıyor: uzun markdown spec'leri incelemek kod incelemekten daha yorucu olabilir ve agent'lar spec'e her zaman uymuyor. Anti-pattern, ajana belirsiz bir istek verip ortaya çıkan büyük diff'i incelemeden merge etmek. İnceleme yükü azalmıyor, biçim değiştiriyor.
Yönetişim, güvenlik ve rol değişimi
ADLC'yi kurumsal ortama taşıyan en önemli fark yönetişim. IBM'in çerçevesi ajanların doğrulanması, sertifikalanması ve kataloglanmasını ayrı bir başlık olarak ele alıyor. Hangi ajan hangi araçlara erişiyor, kim sahibi, en son hangi eval sonucuyla yayına alındı? Bu sorular cevaplanamıyorsa ajan sayısı arttıkça kontrol kaybolur.
Güvenlik de döngünün içine girmeli. Tehdit modelleme tasarım aşamasında, prompt injection ve yetki aşımı testleri test aşamasında, araç çağrısı logları izleme aşamasında yer almalı. OWASP'ın Aralık 2025'te yayımladığı Agentic Applications listesi bu adımlar için iyi bir kontrol listesi; Eylül 2026'da bünyesine aldığı Agent Control Standard da agent'ın araç, model ve veri envanterini (AgBOM) ve runtime denetimini standartlaştırmaya çalışıyor. Gartner'ın Haziran 2025 tahmini, agentic AI projelerinin %40'tan fazlasının maliyet, belirsiz değer ve zayıf risk kontrolü yüzünden 2027 sonuna kadar iptal edileceği yönünde; yönetişim bu yüzden lüks değil.
Roller de kayıyor. Ürün yöneticisi kabul kriterlerini eval vakasına dönüştürmeyi öğreniyor, geliştirici araç tasarımı ve yetki sınırı çiziyor, QA rubrik ve değerlendirme setinin sahibi oluyor. Salesforce'un vurguladığı gibi veri bilimi ve ML mühendisliği becerileri klasik yazılım ekibinin içine giriyor.
Son gelişmeler
Ekim 2026 itibarıyla
Önce kendi cevabını düşün, sonra aç.
ADLC gerçekten yeni bir şey mi, yoksa MLOps'un yeniden paketlenmesi mi?
MLOps'tan çok şey alıyor: versiyonlama, izleme, sürekli iyileştirme. Farkı, ajanların araç kullanması, çok adımlı karar vermesi ve serbest metinle çalışması; bu da eval tasarımına, yetki sınırlarına ve davranış izlemeye ağırlık veriyor. Terim yeni, bileşenlerin çoğu tanıdık; değeri bunları ajan bağlamında tek bir döngüde toplaması.
Küçük bir ekip bu kadar süreci nasıl kaldırır?
Hepsini bir anda kurmak gerekmiyor. Başlangıç için üç şey yeter: sabit bir eval seti, her etkileşimin izlenebilir logu ve üretim hatalarını sete geri ekleme alışkanlığı. AI-DLC iş akışları ve Spec Kit gibi açık kaynak araçlar artık bu iskeleti hazır veriyor. Gerisi agent sayısı ve risk arttıkça eklenir.
Agile ve Scrum ADLC ile ölüyor mu?
Ölmüyor ama ritim değişiyor. AWS'nin AI-DLC önerisi sprint yerine saatler ya da günler süren Bolt döngüleri öneriyor, çünkü agent ile uygulama hızı arttı. DORA'nın 2026 raporu ise hızın kendiliğinden gelmediğini, platform, iş akışı ve ekip uyumu zayıfsa kazancın teslimat zincirinde kaybolduğunu söylüyor. Agile'ın geri bildirim ve iterasyon prensipleri geçerli kalıyor; değişen, törenlerin uzunluğu ve insanın zamanını nereye harcadığı.
Model sağlayıcısı sürüm güncellediğinde ne yapmalı?
Bunu bir bağımlılık güncellemesi gibi ele alın: model sürümünü sabitleyin, yeni sürümü eval setinizle test edin, sonuçlar eşdeğer ya da daha iyiyse kademeli olarak geçin. Eval seti yoksa bu kararı veremezsiniz; ADLC'de eval'in merkezde olmasının bir nedeni de bu.
Notun kaynakları
- Salesforce Architects - Agent Development Lifecycle
- HoneyHive - The Agent Development Lifecycle (Nisan 2026)
- AWS DevOps Blog - AI-Driven Development Life Cycle (Temmuz 2025)
- IBM - AI Agents Demand a New Development Lifecycle (Şubat 2026)
- Stack Overflow Developer Survey 2026 - AI
- The Register - Stack Overflow survey finds devs hooked on AI (Ekim 2026)
- InfoQ - DORA ROI of AI-Assisted Software Development (Mayıs 2026)
Sunum stili
12 slayt. Tıklarsan sunum o slayttan başlar.
Slayt notları
Ajan hem ürünün kendisi hem de onu geliştiren ekip üyesi olunca eski süreç şablonları yetmiyor. Önce terimi netleştirelim.
ADLC Ekim 2026'da da standart bir terim değil. İlk iş hangi anlamı kastettiğinizi söylemek; yanlış anlamaların yarısı buradan çıkıyor.
İkisi rakip değil, iç içe. Ajan tabanlı bir ürünü ajanlarla geliştiren ekip iki döngüyü aynı anda yaşıyor.
Bir yılda hem bulut sağlayıcıları hem kurumsal yazılım şirketleri hem de OWASP kendi çerçevesini çıkardı. İhtiyaç gerçek, standart henüz oturmadı.
Kodu hiç değiştirmeden, sadece model sağlayıcısı sürüm güncellediği için davranış değişebilir. ADLC'de bu kalıcı bir risk sınıfı.
Salesforce'un aşamaları bunlar. Fark, testing'in birim testten eval setine, monitoring'in hata oranından davranış kalitesine genişlemesi.
Her vakanın bir kabul kriteri var. Örnek: sipariş 30 günden eskiyse iade önermez, nedenini açıklar. Anthropic'in Ocak 2026 rehberi de gerçek hatalardan 20-50 görevle başlamayı öneriyor.
Yüksek tutarlı işlemler, düşük güven skorlu cevaplar ve şikâyet içeren konuşmalar daha sık incelenir. Bu adımı atlayan ekip, testte %95 geçen ama sahada şikâyet toplayan bir ajanla kalır.
Birkaç örneği elle deneyip 'iyi görünüyor' demek ilk demo için yeter. Küçük bir prompt değişikliğinin belirli bir girdi sınıfında yarattığı gerilemeyi ancak sabit setle görürsünüz.
Bu sorular cevaplanamıyorsa agent sayısı arttıkça kontrol kaybolur. OWASP Agentic listesi kontrol listesi, Agent Control Standard da runtime denetim için ilk taslak.
Agentic Development tarafında darboğaz kod yazmaktan niyeti Spec olarak tanımlamaya ve diff'i doğrulamaya kayıyor. Belirsiz istekle gelen büyük diff'i incelemeden merge etmek en pahalı anti-pattern.
Pazartesi yapılacak tek şey: bir sonraki ajan özelliği için kod yazmadan önce 20-30 vakalık eval setini yazın.