Bir cumartesi sabahı, kahvemi yeni demlemişken telefonum öttü (buna dikkat edin). Müşteri mesaj atmıştı: “Aşkın bey, şu refactoring işi hâlâ duruyor, pazartesi sunum var.” İçimden direkt “eyvah” dedim. Laptop açıldı, Visual Studio 2026, Copilot Chat… derken bir cloud agent fırlattım ortaya. Sonra ne yaptım biliyor müsünüz? Kahvemi içtim, balkona çıktım. Yarım saat sonra PR hazırdı. Garip tarafı şu: kendim oturup yapsam muhtemelen 3-4 saat giderdi, belki de daha fazla.
İşte Visual Studio’nün Nişan güncellemesi bana tam bu hissi veriyor. Copilot artık sadece “yaninızda kod yazan asistan” değil; bazen resmen siz uyurken iş bitiren bir stajyer gibi davranıyor. Bu yazıda hem güncellemenin teknik tarafını anlatacağım hem de sahada, kurumsal müşterilerimde gördüğüm pratik etkileri paylaşacağım. İlginç, değil mi? Araya biraz eleştiri de koyacağım, çünkü her şey pırıl pırıl değil.
Cloud Agent Entegrasyonu: IDE’den Çıkmadan Uzak Sunucuda Kod
Olay şu: Visual Studio’nün içindeki Chat penceresinden agent picker’a tıklayıp “Cloud” seçeneğine geçiyorsunuz. Sonra da ne istiyorsanız yazıyorsunuz, mesela “şu authentication katmanını JWT’den OAuth2’ye çevir, testleri de güncelle” gibi; cloud agent, yani arkada GitHub Copilot coding agent çalışan taraf, önce repository’nizde issue açma izni istiyor, ardından PR hazırlığına giriyor. Kulağa basit geliyor, değil mi?
Bilmem anlatabiliyor muyum, Bu sırada ne yapabilirsiniz? Her şeyi. IDE’yi kapatıp başka projeye geçebilirsiniz, hatta laptop’u kapatıp dışarı da çıkabilirsiniz; işin aslı biraz garip ama hoş, çünkü PR hazır olunca size bildirim düşüyor ve oradan da “View PR” ya da “Open in browser” seçeneklerinden birini seçiyorsunuz.
Durun, bir saniye.
Şimdi durun. Bir saniye. Bunu ilk denediğimde — Logosoft’ta bir sigorta şirketi müşterimizde — şöyle bir hata aldım: “Copilot does not have permission to create issues in this repository.” Yani repo’da Copilot’a doğru izinleri vermeden başlatırsanız sistem direkt tökezliyor. Çözüm de aslında çok düz: repo Settings → Copilot → Coding agent kısmından izinleri açmak; küçük detay gibi duruyor. İlginç, değil mi? Bazen insanı saatlerce oyalıyor.
Kurumsal Müşterilerimde Bu Nasıl Karşılandı?
Şöyle ki, Açık konuşayım — Türkiye’deki kurumsal müşterilerimde cloud agent fikri ilk anda pek sıcak gelmedi. Sebep de malum: “Kodumuz nereye gidiyor? GitHub’da çalışıyor ama hangi data center? KVKK uyumlu mu?” Bir bankacılık müşterimde compliance ekibi tam 3 hafta boyunca bu konuyu masaya yatırdı, sonra vardığımız sonuç şuydu: sandbox repo’larda kullanılabilir, üretim repo’larında işe şimdilik kapalı kalsın (bu beni çok şaşırttı). Bu, sahadan gelen gerçek; Avrupa’da ya da ABD’de tablo değişebilir ama bizim tarafta veri lokasyonu sorusu hâlâ ciddi bir bariyer.
Bunu biraz açayım.
Bi saniye — Küçük ekiplerdeyse hikâye bambaşka. 5-10 kişilik bir startup ekibiyseniz cloud agent resmen fazladan bir geliştirici gibi davranıyor; junior pozisyonu için kalıp dökmeye gerek kalmadan rutin işleri devredebiliyorsunuz. Mesela “TypeScript tıp tanımlarını düzelt” gibi kimsenin bayılmadığı işleri verip siz daha kritik yerlere bakabiliyorsunuz.
Cloud agent, “kodu birine emanet etme” rahatlığına geldiğinizde gerçekten ciddi bir hamle oluyor. Ama o rahatlığa gelmek — özellikle regüle sektörlerde — sandığınızdan uzun sürüyor.
Kullanıcı Düzeyinde Özel Agent’lar: Sizinle Seyahat Ediyor
Geçen ay duyurulan custom agents özelliği vardı hani —.agent.md dosyalarıyla repo bazında özel ajanlar tanımlıyordunuz. Şimdi iş biraz daha kullanışlı bir yere kaydı, çünkü artık kullanıcı düzeyinde ajanlar da var. Bunlar sizinle birlikte projeden projeye dolaşıyor.
Şimdi gelelim işin can alıcı noktasına.
Varsayılan konum: %USERPROFILE%/.github/agents/. Bunu değiştirmek isterseniz Tools → Options bir düşüneyim… → GitHub → Copilot → Copilot Chat → Custom agents user directory’den ayar yapabilirsiniz. Siz ne dersiniz? Yeni bir ajan oluşturmak için agent picker’daki + butonuna tıklayıp sihirbazı takıp etmek yeterli, yani öyle uzun uzun menü gezmeye gerek yok.
Bunun pratikte ne anlama geldiğini anlatayım. Ben kendi makinemde 3 tane kullanıcı düzeyinde ajan tutuyorum şu an:
- azure-reviewer: Azure mimarı kararlarını Well-Architected Framework’e göre denetleyen bir ajan. Her projede aynı standardı uyguluyorum, çünkü sonra “bunu niye böyle yaptık?” sorusu gelince elinizde tutarlı bir kontrol noktası oluyor.
- turkce-yorum: Kod yorumlarını Türkçe yazan bir ajan (müşteri talebi gerektiğinde). Basit gibi duruyor ama bazen ekip içinde iletişimi baya rahatlatıyor.
- cost-checker: Yazılan kodun olası Azure maliyet etkilerini tahmin eden bir ajan — özellikle Cosmos DB ve Service Bus kullanan kodlarda altın değerinde, çünkü küçük görünen bir tercih sonradan faturada kendini gösteriyor. — bunu es geçmeyin
Bir şey dikkatimi çekti: Bu ajanları her yeni projeye taşımak zorunda değilim. Açıyorum, oradalar. Repo bazlı.agent.md dosyaları hâlâ çalışıyor — workspace farkındalığı, kod anlama, araç seçimi, model seçimi, MCP bağlantıları… Hepsi yerinde. Hatta bazı durumlarda ikisini birlikte kullanmak daha mantıklı oluyor; biri genel alışkanlıkları taşıyor, diğeri repo’nün kendi kurallarını söylüyor (buna dikkat edin)
Awesome-Copilot Repo’su: Hazır Şablon Hazinesi
Tuhaf ama, Topluluk awesome-copilot adlı bir repo’da kendi ajan konfigürasyonlarını paylaşıyor. İlginç, değil mi? Sıfırdan yazmaktansa oradan başlamak çoğu zaman daha akıllıca geliyor; bak şimdi, her şeyi elle kurup sonra yarım bırakmak yerine hazır örnekten ilerlemek insanı gereksiz oyalanmadan kurtarıyor.
Ben de geçen hafta oradan bir “code-archaeologist” ajanını alıp kendime uyarladım — eski legacy kodlarda neyin ne işe yaradığını çözmek için yazılmış. Fena değil yani; kod arkeolojisi yapmak isteyenler için göz atmaya değer, hatta bazen ilk bakışta anlamsız duran klasör yapısını bile biraz kurcalayınca taşlar yerine oturuyor. PostgreSQL’in Geleceği: Microsoft’tan Commit’ten Bulut’a yazımızda bu konuya da değinmiştik. Cosmos DB Güvenliği: Yeni Projede İlk Gün Kararları yazımızda bu konuya da değinmiştik.
C++ Kod Düzenleme Araçları: Artık GA
C++ ile uğraşanlar için fena olmayan bir haber var: GitHub Copilot agent mode içindeki C++ Code Editing Tools artık varsayılan şekilde genel kullanıma açık,. GA oldu. Bu araçlar Copilot’a, kod tabanınızın içinde dil bilen bir gezgin gibi dolaşma şansı veriyor; neyin nereye bağlandığını daha rahat sezip biraz daha akıllı davranabiliyor (yanlış duymadınız) (bu beni çok şaşırttı)
İlginç olan şu ki, İki ana araç var:
| Araç | Ne İşe Yarar | Tipik Kullanım |
|---|---|---|
get_symbol_call_hierarchy |
Bir fonksiyonun çağrı zincirini takıp eder | Refactoring, etki analizi |
get_symbol_class_hierarchy |
Sınıf kalıtım hiyerarşisini haritalandırır | Mimarı anlama, polymorphism debug |
Başlamak için çok da uzatmaya gerek yok. Bir C++ projesi açın (IntelliSense yapılandırılmış olmalı), sonra Copilot Chat içindeki Tools ikonundan bu araçları aktif edin. Geri kalanı baya kendi akışında gidiyor; mesela “Bu projedeki ana sınıfları analiz et. Hangi pattern’ler kullanılmış söyle” diye sorduğunuzda, Copilot arka planda bu araçlara dokunup cevap üretmeye başlıyor. Bu konuyla ilgili Claude Opus 4.8 GitHub Copilot’ta: Sahadan İlk İzlenimler yazımıza da göz atmanızı tavsiye ederim.
Evet.
C++ tarafında çalışanlar için ayrı bir not düşeyim; Visual Studio 2026 C++ Yenilikleri: 18.1’den 18.6’ya Saha yazısında bu güncellemenin başka teknik detaylarına da değinmiştim, oraya da bakabilirsiniz. Mantıklı değil mi? Bir de VS Code tarafı için VS Code’da Copilot’a C++ Bağlamı: Custom Instructions yazısı var; hani bazen bağlam işi tek başına bütün farkı yaratıyor ya, işte o tarafa da göz atmak iyi olabilir.
Pratikte Ne Kadar İşe Yarıyor?
Açık konuşayım, küçük ve orta ölçekli projelerde baya iş görüyor. 50-100 sınıflık bir kod tabanında refactoring isterken Copilot artık “bu fonksiyonu değiştirirsem nereler kırılır” sorusuna tek başına yaklaşabiliyor; ama dür bir saniye — 500+ sınıflı eski usul legacy yapılarda, hele template ağırlığı da varsa, iş biraz dağılıyor ve beklediğiniz kadar hızlı toparlayamıyor.
Bakın, bir şey dikkatimi çekti: Bir savunma sanayi projesinde denedik mesela; çağrı hiyerarşisini çıkarması epey zaman aldı. Bazı template özelleştirmelerini atladı, yani ilk bakışta umut veriyor ama köşeli yerlerde hemen tökezleyebiliyor. Her derde deva değil. Beklentiyi ona göre ayarlamak lazım.
Debugger Agent: Çalışma Zamanı Davranışına Karşı Doğrulama
Bu güncellemede en sessiz ama en iş gören parça bence Debugger Agent. Copilot bir bug fix önerdiğinde, eskiden iş biraz hızlıca “derleniyor mu, test geçiyor mu, tamamdır” seviyesinde kalıyordu (ki bu çoğu kişinin gözünden kaçıyor). Şimdi öyle değil; Debugger Agent düzeltmeyi gerçek çalışma zamanı davranışına karşı da yokluyor, yani sadece sözdizimi düzgün mü diye bakmıyor, kod o an gerçekten doğru mu davranıyor, ona da göz atıyor.
Bu ayrım — özellikle yarış koşulları, null reference’lar ve kenar durumlar söz konusuysa — baya fark yaratıyor. Geçen hafta bir e-ticaret projesinde async/await zincirinin içinde bir deadlock vardı; Copilot’un ilk önerdiği fix derleniyordu ama mesele orada bitmiyordu, Debugger Agent çalıştırıp “Hayır, bu deadlock’u çözmüyor, sadece gizliyor” dedi. Başka bir yola itti bizi. Açık konuşayım, o ikinci yaklaşım daha yerindeydi. Daha fazla bilgi için CodeQL 2.25.5 Çıktı: GitHub Actions Taramaları Keskinleşti yazımıza bakabilirsiniz.
Bir dakika — bununla bitmedi.
Türkiye’de Bu Güncelleme: Maliyet ve Adopsiyon Tablosu
Araya gireyim: Şimdi gelelim para tarafına (kendi tecrübem). Çünkü işin aslı, bu güzel özellikler bedava değil; GitHub Copilot Business planı kullanıcı başına aylık 19$ geliyor, Türkiye’de kurla düşününce kişi başı yaklaşık 700-800 TL/ay gibi bir yere oturuyor, 20 geliştiricili bir ekipte de ay sonunda 15-16 bin TL civarı bir fatura çıkıyor.
Araya gireyim: İlk bakışta biraz can sıkıyor. Ama dür bir saniye — eğer cloud agent ile bir geliştiricinin haftada 4-5 saatini geri kazanıyorsanız, bu masraf çoğu senaryoda 1-2 haftada kendini toparlıyor; tabii burada kullanımın gerçekten yoğun olması gerekiyor, yoksa hesap kağıt üstünde güzel durup sahada biraz sönük kalabiliyor.
Ve işler burada ilginçleşiyor.
Sahadan gördüğüm şey şu: ilk ay kullanım yüksek oluyor, sonra düşüyor, sonra yeniden artıyor (özellikle ekip öğrenme eğrisine girince). Evet. Üçüncü aydan sonra ROI daha net görünmeye başlıyor. SPFx 1.23 GA Çıktı: SharePoint Geliştiriciye Mayıs Notları yazımızda bu konuya da değinmiştik.
Startup vs Enterprise: Hangi Senaryoda Ne Kullanmalı?
Bunu yaşayan biri olarak söyleyeyim, Küçük bir ekipseniz (5-15 kişi), cloud agent’ı daha cesur kullanın. Tahmin eder mısınız? Junior almadan önce hangi rutin işleri agente devredebilirsiniz, buna bakın; ben bunu bir startup arkadaşıma önerdim ve üç ay içinde iki junior pozisyonunu açmadan kapattılar, yani tasarruf baya hissedildi.
Kısacası, i̇lginç olan şu ki, Kurumsal taraftaysanız (200+ geliştirici), önce policy kısmını halletmeniz lazım. Hangi repo’lara cloud agent erişebiliyor, hangi data sınıflarına dokunabiliyor, audit log’lar nereye gidiyor? IT governance ekibini sürece katmadan başlarsanız, altı ay sonra geri çekmek zorunda kalabilirsiniz. Yaşandı bu. Gördüm.
İlk Adım Olarak Ne Yapmalısınız?
Pratik bir yol bırakayım, denemek isteyen varsa işine yarar:
- Visual Studio 2026’yı indirin ve en güncel yamayı kurun.
- GitHub Copilot lisansınızın aktif olduğuna bakın (Business ya da Enterprise tarafı daha rahat ediyor).
- Deneme için bir sandbox repo açın. Üretim koduyla başlamak, açık konuşayım, biraz gereksiz risk.
- Repo Settings -> Copilot kısmından coding agent için gereken izinleri verin. (bence en önemlisi)
- Önce küçük bir iş seçin: “README dosyasını güncelle” gibi. Ajanın akışına böyle alışıyorsunuz.
- Sonra yavaş yavaş daha karışık işlere geçin: test ekleme, refactoring, bug fix. Bir anda abanmayın.
- Bir hafta sonra
%USERPROFILE%/.github/agents/klasörüne bakın, orada kendi kullanıcı düzeyi ajanlarınızı oluşturmaya başlayabilirsiniz.
Böyle giderseniz öğrenme eğrisi daha sakın ölür, hem de pahalıya patlayacak hataları baştan kesersiniz. Evet, bu kadar basit görünüyor. Ama bazen basit olan şeyler daha çok iş görüyor.
Eksik Tarafları: Her Şey Tozpembe Değil
Açık konuşayım, işin bu tarafı biraz can sıkıyor. Cloud agent şu an — kendi adıma konuşayım — Türkiye’deki birçok kurumsal müşterimde compliance bariyerine takılıyor — zamanla çözülür gibi duruyor ama bugün gerçek bu, hani başka türlü anlatmaya gerek yok. Custom agent ekosistemi de daha yolun başında; awesome-copilot repo’su fena bir başlangıç veriyor ama buna production-grade ajan kütüphanesi demek için erken, hatta biraz iddialı ölür.
C++ araçları büyük kod tabanlarında yavaş kalabiliyor, evet. Bu da ileride toparlanır muhtemelen, ama şu an göz ardı etmemek lazım. Kısacası elinizdeki hız beklentisini biraz aşağı çekin; yoksa ilk testte insanın morali bozuluyor.
Doğrusu, Bir de Debugger Agent tarafında ilginç bir durum var, şey gibi… bazen gereğinden fazla şüpheci davranıyor (evet, doğru duydunuz). Doğru çözümleri bile “doğrulanamadı” diye geri çevirebiliyor (garip ama oluyor), o yüzden bazı noktalarda manuel müdahale şart hâle geliyor. Yani agent’lara körlemesine yaslanmak yerine onları ikinci bir göz gibi düşünmek daha mantıklı.
İlgili konular için Agent Sandbox: Kubernetes’te AI Agent’ları Çalıştırmak ve Visual Studio Mayıs Güncellemesi: Plan, İncele, İyileştir yazılarıma da bakabilirsiniz — biri altyapı tarafını tamamlıyor, diğeri de resmin diğer üçünü gösteriyor.
Sıkça Sorulan Sorular
Cloud agent kullanınca kodum nereye gidiyor?
Bir bakıma, bunu yaşayan biri olarak söyleyeyim, Cloud agent GitHub’ın kendi altyapısında çalışıyor,. Kodunuz aslında GitHub’ın veri merkezlerinde işleniyor (ciddiyim). KVKK veya benzeri regülasyonlara tabiyseniz, hukuk ve compliance ekibinizle önce mutlaka bir konuşun. Bence en güvenli yol, hassas üretim repo’larında denemek yerine önce sandbox ya da açık kaynak projelerde test etmek.
Custom agent’ları repo bazlı mı tutayım, kullanıcı bazlı mı?
Açıkçası bağlama göre değişiyor. Mesela takimin tamamının kullanması gereken ajanlar — hani coding standards uygulayan türden — repo bazlı olmalı. Kişisel çalışma tarzınıza özel bir düşüneyim… şeyler, favori model seçimi, kişisel kısayollar gibi, bunları kullanıcı bazlı tutun. İkisini karıştırmayın, net bir ayrım yapın, tecrübeme göre sonradan çok kolaylaştırıyor (ki bu çoğu kişinin gözünden kaçıyor)
C++ projemde IntelliSense kurulu değilse ne ölür?
C++ agent araçları doğrudan IntelliSense’e bağımlı. IntelliSense düzgün yapılandırılmamışsa get_symbol_call_hierarchy. Get_symbol_class_hierarchy araçları boş ya da yanlış sonuç dönduruyor. Yani CMake, vcxproj veya compile_commands.json’ınızın doğru kurulu olduğundan emin olun, yoksa araçlardan verim alamazsınız.
Cloud agent bir görevi ne kadar sürede bitiriyor?
Karmaşıklığa göre değişiyor tabii. Basit bir bug fix 5-10 dakika, orta düzey bir refactoring 20-40 dakika, kompleks bir feature ekleme işe 1-2 saat sürebiliyor. Neyse ki PR hazır olunca bildirim geliyor, bence bu süreçteki en güzel şey de bu — bekleme süresinde başka işlerinize bakabiliyorsunuz.
Visual Studio 2026 yerine 2022 kullanıyorum, bu özellikler bende de çalışır mı?
Bak şimdi, Cloud agent entegrasyonu ve yeni custom agent özellikleri için Visual Studio 2026’ya geçmeniz gerekiyor. VS 2022’de GitHub Copilot’un temel özellikleri çalışıyor ama agent tarafındaki yeniliklerin çoğu 2026’ya özel. Açıkçası bu özellikleri aktif kullanacaksanız güncellemeyi ertelememek mantıklı.
Kaynaklar ve İleri Okuma
Visual Studio April Update – Cloud Agent Integration (Microsoft DevBlogs)
GitHub Copilot Coding Agent Resmî Dokümantasyonu
awesome-copilot GitHub Repository
Visual Studio Copilot Chat Context Learn 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.
