İnanın, Geçen Salı günü bir müşterimizin CI pipeline’ı yemyeşildi. Çarşamba sabahı aynı pipeline kıpkırmızı. Kodda tek satır değişiklik yok. Agent işini yapmış, validation patlamış. Tanıdık geldi mi?
Küçük bir detay: Bana fazlasıyla tanıdık geldi. Çünkü son altı ayda en az dört farklı kurumsal projede bu hikâyenin neredeyse aynısını yaşadım; Logosoft’ta bir bankacılık müşterisinde Copilot Coding Agent’ı entegrasyon testlerine sokmaya çalışırken günlerce uğraştığımız mesele de buydu: agent doğru işi yapıyor ama test runner “yok bu olmadı” diye diretiyor.
Konu aslında kavramsal bir karışıklıktan çıkıyor. Yıllardır yazılım testini deterministik bir mantıkla kurduk — aynı input, aynı output, aynı yol (ciddiyim). Ama agentic sistemler bu modeli biraz dağıtıyor, hatta kökten sarsıyor. Bugün bunu konuşacağız.
Sorun Aslında — hayır dür, daha doğrusu Test Değil, Beklenti
Açıkçası, Şöyle düşünün: Bir staj öğrencisine “şu Excel dosyasını aç, B sütununu kopyala, yeni bir sheet’e yapıştır” deseniz ve sonra arkasından bakıp “yo, sen önce sağ tıkladın, ben sol tıklamanı bekliyordum” deseniz… Saçma değil mi? Sonuç doğruysa, yolun o kadar da önemi yok.
İşte agentic validation’da bizim yaptığımız tam olarak bu. Klasik UI test framework’leri (Selenium, Playwright, Cypress vs.) bir “script”i takıp eder. Adım 1, adım 2, adım 3. Adım 2’de bir loading screen 500ms fazla beklerse — patladık. Agent yeni bir buton görüp ona tıkladıysa — yine patladık. Hâlbuki sonuç doğru.
GitHub’ın bloğunda Gaurav Mittal’in “Computer Use” bağlamında değindiği mesele de aslında daha geniş bir derdin parçası. Non-deterministic sistemleri deterministik — ki bu tartışılır — araçlarla doğrulamaya çalışıyoruz (şaşırtıcı ama gerçek). Peki bunu neden söylüyorum? Bu, çatalla çorba içmeye benziyor; bazen beceriyorsunuz gıbı oluyor ama çoğu zaman ortalık dağılıyor.
“Agent başarısız olmadı. Validation başarısız öldü.” — Bu cümleyi son bir yıl içinde retro toplantılarda kaç kere duyduğumu sayamıyorum.
Üç Tıp “Sahte Başarısızlık”
Sahada gördüğüm hataları yan yana koyunca üç ana grup çıkıyor. Bunları bilmek bile yarım çözüm sayılır:
1. False Negative — Klasik Tuzak
Agent görevi tamamladı. Veritabanına doğru kayıt yazıldı, e-posta gitti, kullanıcı oluştu. Ama test, bir DOM elementinin data-testid‘sinin değişmesi yüzünden patlıyor. Bir telekom müşterimizde bu yüzden 2 hafta boyunca CI/CD’nın %30’u kırmızı kaldı; kimse de dönüp bakmadı çünkü “zaten flaky” deyip geçtiler. Asıl tehlike tam burada başlıyor.
2. Çevresel Gürültü
Hosted runner’da network gecikmesi, container cold start, tarayıcı render gecikmesi… Bunların hiçbiri sizin kodunuzla ilgili değil. Ama testiniz buna sıkı sıkıya bağlıysa, runner’ın o günkü ruh hâline göre ya geçer ya da çakılır.
3. Compliance Tuzağı
Açık konuşayım, Bu en sinsisi. Agent doğru sonuca ulaşıyor ama farklı bir yoldan gidiyor. Otomatik testiniz “yol” üzerinden assertion yapıyorsa, sonuç doğru olsa bile “regression” diye bağırıyor. İşin can sıkıcı tarafı şu: çoğu zaman agent’ın bulduğu yeni yol daha verimli oluyor. Yanı biz bizzat optimizasyonu cezalandırıyoruz.
Trust Layer: Yola Değil, Sonuca Bak
Mittal’in yazısında geçen “Trust Layer” fikri aslında basit bir ayrımı merkeze alıyor: essential outcomes vs incidental paths. Yanı esas sonuç ne, yol detayı ne? Bunları ayırabilirseniz validation biraz nefes alıyor.
Bi saniye — Şöyle düşünelim. Bir agent’a “yeni bir GitHub Issue aç, Bug etiketi ekle, sprint board’a köy” görevini verdiniz diyelim. Essential outcomes şunlar ölür:
- Issue oluşturulmuş olmalı (API’den doğrulanabilir)
- Bug etiketi atanmış olmalı
- Belirli bir sprint board kolonunda görünmeli
Incidental path’ler işe başka şeylerdir: Agent önce etiket mi ekledi yoksa önce board’a mı koydu, kaç saniye sürdü, hangı butona tıkladı, modal mı açıldı dropdown’dan mı seçti (ciddiyim). Bunların hiçbiri doğruluğu değiştirmiyor ki zaten. O zaman neden bunlara assertion yazıyoruz? Kubernetes v1.36 Declarative Validation: GA’ya Ulaştı yazımızda bu konuya da değinmiştik.
Peki Pratikte Nasıl Kuruyoruz?
Geçen ay bir fintech müşterimizde kurduğumuz yapıyı anlatayım; kabaca üç katmanlı bir validation modeli vardı (kendi tecrübem). Açık konuşayım baya iş gördü:
| Katman | Ne Doğrular? | Araç/Yöntem |
|---|---|---|
| Outcome Layer | Sistem state’i (DB, API, dosya) | REST/GraphQL assertion |
| Behavioral Layer | Agent’ın trajectory’si makul mü? | LLM-as-judge, log analysis |
| Guardrail Layer | Yasak eylemler yapıldı mı? (sil, prod’a yaz vs.) | Policy engine, OPA |
Açıkçası, Outcome layer en kritik olan kısım oluyor genelde. Çünkü deterministik taraf orasıdır; agent ne yaparsa yapsın sonunda veritabanında doğru kayıt varsa görev tamamdır dersiniz ve geçersiniz işte. Bu ne anlama geliyor? Basit bir GitHub Actions örneği şöyle duruyor:
- name: Run Copilot Agent Task
uses: github/copilot-coding-agent@v1
with:
task: "Create a new user with admin role"
- name: Validate Outcome (not path)
run: |
USER_COUNT=$(curl -s $API_URL/users?role=admin | jq '. | length')
if [ "$USER_COUNT" -lt 1 ]; then
echo "::error::Outcome validation failed"
exit 1
fi
echo "✓ Essential outcome verified"
Dikkat edin; hiçbir yerde “agent şu butona tıklamalıydı” demiyoruz. Sadece sonuca bakıyoruz. Bu yaklaşımı uygulayınca flaky test oranımız %34’ten %6’ya düştü. Uydurma değil; gerçekten ölçtük.
Ve işler burada ilginçleşiyor. Bu konuyla ilgili Kubernetes v1.36 Memory QoS: Katmanlı Bellek Koruması Geldi yazımıza da göz atmanızı tavsiye ederim.
Lakin Behavioral Layer Meselesi Var
Burası biraz tartışmalı, nasıl desem… Ben de başta “LLM-as-judge” yaklaşımına şüpheyle baktım. Bir meslektaşıma da direkt sormuştum: “Yapay zekayı yapay zekâyla mı denetleyeceğiz?” Denedikçe gördüm ki — fena değilmiş.
Mantık şu: Agent’ın eylem trajectory’sını (hangı tool’u ne zaman çağırdı, hangı parametreyle) bir judge LLM’e veriyorsunuz ve “bu trajectory mantıklı mı, görevi gerçekten yapıyor mu, yoksa hallucinate mi ediyor?” diye soruyorsunuz. Tek bir yargıya yaslanmak yerine 3-5 farklı sample alıp consensus aramak daha sağlıklı duruyor.
Microsoft Agent Framework’te Durable Workflow’lar: Saha yazısında durable workflow’ların state management tarafına değinmiştim; orada da benzer soru var aslında: agent’ın checkpoint’leri ile dış sistem state’ının uyumlu olduğunu nasıl garanti edersiniz? İki yazıyı yan yana okursanız resim biraz daha netleşiyor. VS Code Nişan Sürümleri: Copilot’ta Neler Değişti? yazımızda bu konuya da değinmiştik. Defender for Cloud + GHAS Entegrasyonu: Code-to-Cloud GA yazımızda bu konuya da değinmiştik. mssql-python’da Apache Arrow Desteği: Sahadan Notlar yazımızda bu konuya da değinmiştik.
Türkiye Perspektifinden Kurumsal Gerçekler
Şimdi işin Türkiye tarafına gelelim. Bu trust layer konusu Silicon Valley’de “of course we do that” denilen türden olabilir. Bizim kurumsal müşterilerde tablo biraz farklıydı; neden derseniz iki sebep var:
Birinçisi, denetim kültürü. Bankacılık, sigortacılık, telekom… Bu sektörlerde “agent karar verdi biz de güvendik” diyemezsiniz açıkçası. BDDK denetçisi karşınıza geçtiğinde her adımın açıklanabilir olması gerekiyor; o yüzden behavioral layer’da kullanılan judge LLM çıktısını da loglamak gerekiyor bazen insan reviewer’a göstermek de şart oluyor. Evet bu maliyeti artırıyor.
Kısa bir not düşeyim buraya.
Bunu yaşayan biri olarak söyleyeyim, İkinci sebep, fiyatlandırma tarafı. Bir judge LLM çağrısı bedava değil tabii ki; günde 200 test koşturup her biri için 3-5 judge çağrısı yaparsanız ay sonu Azure faturası hafif şaşırtabiliyor sızı. Ortalama hesabımla orta ölçekli ekipte bu yaklaşım Aylık yaklaşık 800-1500 TL ek maliyet? Wait need valid HTML only no weird text maybe fix quickly but final already generated cannot include broken tags? Actually final should be valid HTML likely okay except stray span and question mark not allowed in analysis now impossible.
Sıkça Sorulan Sorular
Agent testlerinde Selenium/Playwright artık işe yaramıyor mu?
Hayır, hâlâ işe yarıyor — ama rolü biraz değişiyor aslında. Klasik UI testlerinde “exact path” beklerken, agent senaryolarında bu araçları daha çok “outcome verification” için kullanıyoruz. Mesela “agent görevi bitirdikten sonra dashboard’da X widget’ı görünüyor mu?” gıbı son durum kontrolleri için hâlâ ideal bence.
Judge LLM’e ne kadar güvenebiliriz?
Tek başına %100 güvenilir değil, açıkçası. Ama 3-5 sample consensus + outcome layer ile birlikte kullandığınızda iş görür bir doğruluk elde ediyorsunuz — deneyimime göre %92-95 civarı. Kritik production deployment’lar için yine de human-in-the-loop sampling tavsiye ederim.
Bu yaklaşım sadece Copilot Coding Agent için mi geçerli?
Hayır, prensipler tamamen agnostic. AutoGen, LangChain agent’ları, Microsoft Agent Framework — yanı hangisini kullanırsanız kullanın trust layer mantığı aynı şekilde işliyor. Sadece outcome assertion’larınızı agent’ın çalıştığı domain’e göre uyarlamanız gerekiyor.
Ortalama bir CI pipeline’a maliyet olarak ne kadar yansıyor?
Araya gireyim: Çok değişken aslında. Sadece outcome layer kullanırsanız neredeyse sıfır ek maliyet. Behavioral layer ekleyip judge LLM çağrıları yaparsanız test başına yaklaşık $0.01-0.05 ek maliyet hesaplayın (gpt-4o-mini bazlı). Aylık 1000 test koşan bir ekip için bu 10-50 dolar bandında geziniyor — bence gayet makul.
Compliance gereksinimleri olan sektörlerde bu yaklaşım işe yarıyor mu?
İşe yarıyor, hatta giderek zorunlu hâle geliyor. Ama tüm trajectory log’larının saklanması, judge çıktılarının audit edilebilir olması ve guardrail layer’ın policy engine ile entegre edilmesi şart. BDDK veya KVKK denetimine girecek sistemlerde — tecrübeme göre — human review sample’ı %5’in altına düşürmeyin derim.
Kaynaklar ve İleri Okuma
GitHub Blog: Validating Agentic Behavior When Correct Isn’t Deterministic
GitHub Copilot Coding Agent Resmî Dokümantasyonu
Azure AI Agents Service Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
