İtiraf edeyim, Geçen ay,. 2026 Ocak sonunda, bir müşteride benzer bir şey yaşadım: ekip her gün aynı benchmark raporlarını açıp aynı kalıpları arıyordu. Açık konuşayım, işin en yorucu kısmı kod yazmak değil; tekrar eden zihinsel yükü taşımak. İşte bu yüzden ajan tabanlı geliştirme fikri bana çok tanıdık geldi. Hani bazen “şunu da otomatikleştirsek ya” dersiniz… sonra bir bakarsınız, yarım gününüz gitmiş.
Tyler McGoffin’in Copilot Applied Science tarafında anlattığı yaklaşımın bende bıraktığı his şu oldu: Bu artık sadece kod üretmek değil, düşünme işinin de bir kısmını devretmek. Tabii kulağa biraz sert geliyor. Ama özellikle büyük eval setleri, trajektori dosyaları, deney kayıtları derken insanın gözleri dönüyor. Ben de Azure danışmanı olarak yıllardır şunu görüyorum: Bir işi ölçeklendiremiyorsanız, sorun genelde teknoloji değil, o işi yapan akışın kendisi oluyor.
Bir dakika — bununla bitmedi.
Neden bu konu bu kadar tuttu?
Ne yalan söyleyeyim, İşin aslı şu ki, çoğu geliştirici önce küçük bir sıkıntıyı çözüyor, sonra fark etmeden kendi iç aracının bakımcısı oluyor. 2019’da Logosoft tarafında eski bir hosting ortamında log analizi için basit scriptler yazmıştık; ilk hafta hayat kurtardı, üçüncü ayda o scriptlerin sahibi ben oldum. Şimdi bakınca gülüyorum ama gerçek buydu. Ajanlarla yapılan iş de biraz öyle — başlangıçta rahatlatıyor, sonra üstüne yeni sorumluluk bindiriyor — valla güzel iş çıkarmışlar —
McGoffin’in yazısındaki güzel nokta şu: Olay sadece “AI ile hızlanmak” değil; tekrar eden analitik yükü sistematik hâle getirmek. Bilhassa benchmark analizinde yüz binlerce satır JSON okumak yerine örüntü yakalayan bir yapı kurmak bayağı işe yarıyor. Burada Copilot’un değeri salt autocomplete değil; görev akışını kavrayıp doğru yere müdahale etmesi (en azından benim deneyimim böyle)
Hmm, bunu nasıl anlatsamdı…
Ben bunu geçen yıl bir finans kuruluşundaki POC sırasında da hissettim. Ekip sürekli farklı GitHub Actions çıktıları ve güvenlik sinyalleri arasında gidip geliyordu. Tek tek bakınca idare eder görünüyordu ama ölçek büyüyünce kaos başlıyor. Aynı durum eval analizinde de var: küçük veri setiyle her şey yolunda gibi duruyor… ta ki on kat büyüyene kadar.
Ajan-driven development tam olarak neyi değiştiriyor?
Burada klasik geliştirmeden farklı olan şey şu: Siz artık sadece komut veren kişi değilsiniz, orkestratörsünüz. Bir ajanı belirli kurallarla eğitiyorsunuz, ona araç veriyorsunuz ve hangi durumda ne yapacağını tarif ediyorsunuz. Yani biraz mutfakta yemek yaptırmak gibi; tarifi vermezseniz ortaya sürpriz çıkıyor (ve çoğu zaman yenmiyor).
Peki neden?
Açık konuşayım, Copilot Applied Science ekibinin yaklaşımında üç hedef dikkat çekici geliyor: paylaşımı kolaylaştırmak, yeni ajan yazmayı kolaylaştırmak (şaşırtıcı ama gerçek). Katkıların ana taşıyıcısı olarak coding agent’ları kullanmak. Ben buna çok sıcak bakıyorum çünkü kurumlarda başarıya giden yol genelde “tek kişinin kahramanlığı” değil, standardize edilmiş kalıp oluyor.
Az önce söyledim ama şimdi daha net söyleyeyim: Bu modelin en büyük artısı hız değil yalnızca; tutarlılık. AZ-305’e hazırlanırken mimarı desenlere nasıl baktığımı hatırlıyorum — aynı prensip burada da geçerli. İyi tanımlanmış sınırlar koyarsanız ajan size saçmalamak yerine işe yarar sonuç veriyor.
| Yaklaşım | Artı | Ekşi |
|---|---|---|
| Klasik manuel analiz | Kontrol sizde | Zaman yer, tekrar eder |
| Sadece Copilot ile destekli çalışma | Hız kazanırsınız | Süreç kişiye bağımlı kalabilir |
| Ajan-driven workflow | Ölçeklenir, paylaşılır | Tasarım hatası olursa yanlış kararları büyütür |
Beni en çok etkileyen tasarım dersi neydi?
Bir dakika, şunu da ekleyeyim: Bu tür projelerde “ajan yapalım” demek yetmiyor; kullanım senaryosunu acımasız biçimde daraltmak gerekiyor. Tyler’ın anlattığı işte amaç herkes için genel amaçlı süper zekâ yapmak değil… belli görevlerde hızlı ve güvenilir yardımcı üretmekti. Bence kritik ayrım bu. Bu konuyla ilgili CodeQL Autofix Raporları Artık Daha Gerçekçi yazımıza da göz atmanızı tavsiye ederim.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Benzer bir şeyi 2024’te İstanbul’da bir telekom müşterisinde yaşadık. Ekip ilk başta “her şeyi yorumlasın” diyordu; sonuç? Güzel demo ama pratikte yavaşlık ve kararsızlık çıktı. Sonra kapsamı daralttık: yalnızca belirli log tiplerini sınıflandıran ve ilgili trajektori parçasını öne çıkaran küçük ajanlar yaptık. Performans fena değildi, hatta bayağı iyi oldu. GitHub Güvenliği: Küçük Repoda Büyük Açıkları Kapatmak yazımızda bu konuya da değinmiştik.
Ajan tasarımında asıl mesele zekâ seviyesi değil; sınır çizme becerisi. Ne yapacağını net söylerseniz fayda verir… yoksa gereksiz özgüvenle ortalığı dağıtabilir.
Kodun kendisi mi önemli, yoksa akış mı?
Kod elbette önemli ama bence artık asıl değer akışta yatıyor. E peki, sonuç ne oldu? GitHub Copilot CLI ile oynarken bunu çok net gördüm; doğru prompt + doğru araç + doğru çıktı formatı birleşince iş hızlanıyor ama süreç bozulursa hız sadece daha hızlı hata üretmeye dönüşüyor (bizzat test ettim) Daha fazla bilgi için GitHub Secret Scanning Büyüdü: Yeni Detektörler, Daha Az Sızıntı yazımıza bakabilirsiniz.
Neyse uzatmayalım; burada mesele “model ne kadar güçlü?” sorusundan çok “hangi adımı otomasyona vermek mantıklı?” sorusu. Örneğin trajectory okuma gibi düşük yaratıcı değerli işler ajana iyi giderken, nihai mimarı kararı hâlâ insanın vermesi gerekiyor.
Ekip içinde paylaşılabilir hâle getirmek neden zor?
İşin garibi, Burası çoğu projede atlanan yer oluyor. Bir kişi için çalışan çözüm ile ekipçe kullanılabilen çözüm arasında uçurum var. Ben bunu Microsoft Azure tarafındaki danışmanlık çalışmalarında defalarca gördüm;proof-of-concept gayet hoş duruyor ama dokümantasyon eksikse kimse kullanmıyor.
Copilot Applied Science ekibinin hedeflerinden biri de buymuş zaten:ajanların paylaşılmasını kolaylaştırmak. Yeni ajan yazmayı basitleştirmek. Bence bu çok doğru bir seçim çünkü iç araçların kaderi genelde iki şeyden biri olur — ya birkaç kişinin gizli gücü olur ya da herkesin terk ettiği eski depoya döner (kendi tecrübem)
- Paylaşılabilirlik: Ajanın parametreleri açık olmalı.
- Tutarlılık: Aynı girdide benzer sonuç vermeli.
- Bakım: Sahibi değişince çöküp gitmemeli.
- Gözlemlenebilirlik: Neyi neden yaptığını izleyebilmelisiniz.
E tabii burada küçük startup ile enterprise arasındaki fark da netleşiyor. Startup tarafında tek ekip tek repo yeterken,enterprise tarafında erişim kontrolü,gizlilik. Maliyet yönetimi devreye giriyor. Bilhassa FinOps gözüyle bakınca her ajan çağrısı ayrı maliyet kalemi olabilir — ufak görünür. Toplandığında can sıkar.
Bazen hayal kırıklığı da oluyor mu?
İşin garibi, Evet,oluyor tabii ki! Her şeyi pembe anlatmayayım… Ajanların bazı görevlerde beklediğiniz kadar iyi çalışmadığı anlar var.
Mesela uzun trajektori zincirlerinde bağlam kayması yaşanabiliyor.
Bir noktadan sonra model kendinden emin biçimde yanlış yere gidiyor. Bunu fark etmek zaman alabiliyor.
Bu durum bana 2025 başında Ankara’daki bir müşteriyle yaptığımız denemeyi hatırlattı;rapor harika görünüyordu ama birkaç uç vakada tamamen sapıtıyordu.
Bunun ilacı da sihir değil aslında:kural seti koymak,doğrulama katmanı eklemek ve gerektiğinde insan onayı istemek. Bu yüzden ben ajana hiçbir zaman tam serbestlik vermekten yana değilim. Güzel özellik ama henüz ham;biraz daha pişmesi lazım diye düşünüyorum. Bu konuyla ilgili GitHub’ın EU Veri Yerleşimi Neden Bir Anda Büyüdü? yazımıza da göz atmanızı tavsiye ederim.
{
"agent": {
"name": "trajectory-inspector",
"inputs": ["json_traces", "benchmark_metadata"],
"steps": [
"pattern_extraction",
"outlier_detection",
"human_review_queue"
],
"output": "summary_report"
}
}Küçük ekip için ne iyi çalışır?
İlginç olan şu ki, Küçük ekiplerde basit akışlar daha iyi sonuç verir. Örneğin dosya özetleme,etiketleme,ilk bulgu çıkarma gibi görevler (şaşırtıcı ama gerçek). Çünkü bakım yükü az olur. Kubernetes’te AI Dönemi: Microsoft’un KubeCon 2026 Hamlesi yazımızda bu konuya da değinmiştik.
Büyük kurumda ne gerekir?
Kısacası, i̇lginç olan şu ki, Büyük kurumda rol bazlı erişim,loglama,versiyonlama ve maliyet takibi şart. Yoksa ajan sayısı arttıkça yönetim kabusa döner.
Peki ben bunu kendi işimde nasıl okudum?
Açık konuşayım, benim için en ilginç kısım şuydu:Bu yaklaşım Azure mimarisi kurarken düşündüğümüz pattern’lerle birebir örtüşüyor. Yani stateless servis,gözlemlenebilirlik,modülerlik,gerekirse insan müdahalesi… hepsi aynı hikâyenin başka kıyafeti.
Zaten AZ-104 ve AZ-500 çalışırken öğrendiğim temel şeylerden biri de buydu:iyi sistem demek en karmaşık sistem demek değildir. Doğru sınırlar çizilmiş sistemdir. GitHub Copilot tarafındaki agent-driven development da buna çok benziyor. Fazla parlak olmayan ama sağlam ilerleyen yapı,uzun vadede daha kıymetli.
Ha bu arada,GitHub Issues. Projeler üzerinde ajan aktivitesinin yükseldiği dönemi anlatan başka yazıları da okuyunca tablo daha netleşiyor:Copilot artık sadece kod öneren araç olmaktan çıkıyor,iş akışı arkadaşı hâline geliyor. Bu dönüşüm biraz ürkütücü olabilir,ama dürüst olayım;kaçınılmaz görünüyor.
Senden geriye ne kalmalı?
Bence alınacak ana ders şu:Teknolojiyi gösterişli olduğu için değil,sizi tekrardan kurtardığı için kullanın។ Agent-driven development tam olarak buraya oturuyor. Eğer elimizdeki iş yüz binlerce satırı okumayı gerektiriyorsa,orada insan enerjisini boşa harcıyoruz demektir.
Ben kendi bloguma yazarken de aynı yaklaşımı seviyorum:önce sıkıcı kısmı makineye bırak,sonra insanın değer kattığı yere odaklan. Çünkü strateji orada başlıyor: Müşterilerde de aynısını söylüyorum;ajanları önce küçük tutun,ölçün,sonra genişletin. Bir anda her şeyi otomasyona boğarsanız sonradan toparlamak zor olur.
Sıkça Sorulan Sorular
Ajan-driven development nedir?
Bunu yaşayan biri olarak söyleyeyim, Ajan-driven development, geliştirmenin bazı bölümlerini AI ajanlarına devreden çalışma şeklidir. Amaç
GitHub Copilot bu yaklaşımda nasıl kullanılıyor?
Copilot burada yalnızca kod tamamlayan araç olmuyor; görev planlama, pattern bulma ve yardımcı aksiyon alma tarafına da giriyor. En çok da tekrar eden işlerde ciddi zaman kazandırabiliyor.
Küçük ekipler için uygun mu?
Evet, hatta bazen küçük ekiplerde daha faydalı oluyor. Süreç sade tutulabiliyor. Ama kapsam dar olmazsa bakım yükü hemen hissediliyor.
Büyük kurumlarda en büyük risk nedir?
Düzensiz erişim, kontrolsüz maliyet ve doğrulanmamış çıktılar en büyük risklerdir. Bu yüzden gözlemlenebilirlik ve onay mekanizmaları şarttır.
Kullanabileceğiniz İlgili Yazılarımızdan Seçmeler
GitHub Issue Triage’ı Copilot SDK ile Akıllandırmak: Ben Olsam Böyle Kurardım
azd Mart 2026: AI Ajanları ve Copilot’la Yeni Dönem (en azından benim deneyimim böyle)
GitHub Copilot Kullanım Ölçümleri: CCA Artık Görünüyor
Kaynaklar ve İleri Okuma
- Orijinal GitHub Blog Yazısı
- GitHub Copilot Resmî Dokümantasyonu (bence en önemlisi)
- GitHub Copilot CLI Tanıtımı — ciddi fark yaratıyor
- Azure Architecture Center
- Azure Cloud Adoption Framework
- GitHub Blog Ana Sayfası (AI & ML Kategorisi)
İçeriği paylaş:
İlgili Yazılar
📬 Bu yazıyı faydalı buldunuz mu?
Azure, DevOps ve bulut teknolojileri hakkında güncel içerikler için beni takip edin!
Yorum gönder