Visual Studio Mayıs Güncellemesi: Planla, Gözden Geçir, İyileştir

Kodu Yazmadan Önce Durmak Neden Değerli?

İşin garibi, Plan agent’ın en hoşuma giden yanı şu: sizi hemen editöre atlamaya zorlamıyor. Önce repo’yu okuyor, soru soruyor, eksik parçaları netleştiriyor ve sonra bir plan çıkarıyor. Hani bazı ekiplerde “hemen başlayalım, sonra bakarız” refleksi vardır ya… işte onun tam karşısında dürüyor bu yaklaşım. Küçük işlerde fazla prosedür gibi görünebilir, ama büyük feature’larda hayat kurtarıyor.

Geçen yıl İstanbul’da bir finans müşterisinde buna benzer bir akış kurmuştuk. Ekip direkt implementasyona dalınca auth katmanı ile logging katmanı birbirine girmişti; üç gün sonra fark ettik ki asıl problem tasarım kararıymış. Eğer o zaman böyle bir planlama adımı olsaydı, ciddi vakit kazanırdık. Açık konuşayım: Plan agent bana biraz “iyi kıdemli mühendis” hissi veriyor; hemen kod yazmıyor, önce neyi neden yapacağını tartıyor.

İşte tam da bu noktada devreye giriyor.

Plan dosyasının markdown olarak kaydedilmesi de önemli detay. .copilot/plans/plan-{title}.md altında tek kaynak gibi davranması güzel fikir. Çünkü sohbet ekranındaki fikir başka olabilir, takım arkadaşının yorumladığı şey başka olabilir; ama plan dosyası ortadaysa herkes aynı sayfada kalıyor. Hani ne farkı var diyorsunuz, değil mi? Kurumsalda benim için değerli olan da bu zaten: konuşma uçup gidiyor ama doküman kalıyor.

Plan agent nasıl düşünmeli?

Bence buradaki asıl fark araçta değil, alışkanlıkta. Plan agent’ı kullanırken amaç “Copilot’a işi yaptırmak” değil; işi birlikte tarif etmek olmalı. Burada, en çok da mimarı bağımlılıkları olan işlerde ilk turda yalnızca kapsamı netleştirmek bile yeterli oluyor.

Hani, Bir dakika, şunu da ekleyeyim: küçük startup ekiplerinde bu akış bazen fazla ağır gelebilir (ben de ilk duyduğumda şaşırmıştım). Eğer iki geliştiriciyseniz ve sprint baskısı yüksekse planı kısa tutarsınız, doğrudan uygulamaya geçersiniz. Ama enterprise tarafta? Orada işler farklı. Güvenlik incelemesi var, release penceresi var, change advisory var… yanı plan olmadan ilerlemek biraz kör uçuş gibi.

Plan agent’ın asıl gücü kod yazdırmasında değil; yanlış yöne gitmeden önce sizi uyarmasında yatıyor.

Gözden Geçirme Katmanı Neden Şimdi Daha Önemli?

Visual Studio güncellemesindeki diğer önemli taraf çok dosyalı değişiklikleri yönetmeye yaklaşım. Bir feature bazen tek dosyada bitmiyor; API değişiyor, testler kırılıyor, config güncelleniyor… Sonra bir bakıyorsunuz PR içinde on beş dosya olmuş ve kimse “bu zincir neden böyle?” diye sormamış.

Ben bunun acısını 2019’da Ankara’daki bir e-ticaret projesinde yaşadım. Checkout akışına küçük görünen bir değişiklik yapılmıştı ama arka planda ödeme servisi çağrılarıyla ilgili iki farklı modül etkilenmişti. Kod review sırasında yüzeysel bakılmıştı; prod’da hata çıkınca hepimiz şaşırdık (aslında şaşırmamamız gerekiyordu). O günden beri çok dosyalı değişikliklerde görsel özet ve kontrollü inceleme benim için lüks değil ihtiyaç öldü (buna dikkat edin) Daha fazla bilgi için Hosted Agents: Agent’lar İçin Güvenli ve Ölçekli Bulut yazımıza bakabilirsiniz.

Küçük ekip mi büyük kurum mu?

Küçük ekipte hızlı karar almak normaldir; hatta çoğu zaman doğru olandır. Ama büyük kurumda reviewer sayısı artsa bile dikkat dağılıyor çünkü herkes kendi parçasına bakıp bütünü kaçırabiliyor. Hani ne farkı var diyorsunuz, değil mi? Yeni inceleme araçları burada fena değil; özellikle hangi dosyada ne kadar oynandığını görmek karar süresini kısaltıyor.

Şöyle ki, E tabi burada dürüst olayım: her yeni özellik sihir değil. Eğer ekibinizde review kültürü zaten zayıfsa araç tek başına mucize yaratmaz. Hatta bazen insanlar “nasıl olsa araç gösterir” deyip daha az düşünmeye başlıyor — bu da beklediğim kadar iyi olmayan taraflardan biri.

Copilot Bağlamını Görmek Neyi Değiştiriyor?

Garip gelecek ama, Copilot Chat içindeki context window kullanımını görünür yapmak bence çok yerinde bir hamle olmuş. Çünkü bağlam dolunca modelin eski konuşmaları unutmaya başlaması teoride bilinir ama pratikte insan bunu ancak cevaplar saçmalamaya başlayınca fark ediyor (şaşırtıcı ama gerçek). biraz can sıkıcı bir durum yanı.

Çok konuştum, örnekle göstereyim. Kubernetes v1.36: Haru ile Gelen Sakın Güç yazımızda bu konuya da değinmiştik.

Bakın, Pasta grafiği gibi çalışan o küçük halka simgesi ilk bakışta basit dürüyor ama günlük kullanımda baya iş görüyor oluyor. Hele bir de uzun oturumlarda hangi noktada bağlamın daraldığını görmek size iki şey kazandırıyor: gereksiz lafı azaltıyorsunuz ve gerçekten önemli dosyaları öne alıyorsunuz. Git ve GitHub: VS Code’da Başlarken İşin Püf Noktaları yazımızda bu konuya da değinmiştik. Bu konuyla ilgili VSLive! Microsoft AI Hackathon 2026: Takımını Kodla Eve Gönder yazımıza da göz atmanızı tavsiye ederim.

Açık söyleyeyim, ben Azure danışmanlığı yaparken Copilot’u uzun süre açık bırakıp üst üste farklı konuya geçtiğimde cevap kalitesinin düştüğünü birkaç kez yaşadım. Bir toplantıda altyapı konuşurken diğerinde GitHub Actions’a döndüğünüzde model bazen ortayı bulamıyor (şaşırtıcı ama gerçek). Tahmin eder mısınız? işte ring göstergesi bunun erken uyarısı gibi çalışıyor.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Nerede faydalı olur?

Sorun çözme oturumlarında çok faydalı olur çünkü aynı sohbet içinde konuyu kaybetmeden ilerlersiniz. Daha fazla bilgi için Azure Cosmos DB Conf 2026: Benim Gözümden Asıl Mesaj yazımıza bakabilirsiniz.

Neyse uzatmayayım; dokümantasyon üretirken de iş görüyor çünkü hangi referansların hâlâ bağlamda olduğunu görmek rahatlatıcı oluyor.

Ama dürüst olayım: tek başına yetmez.
Bağlam yönetimi iyi olsa bile kötü soru sorarsanız kötü cevap alırsınız.
Araç burada sadece dürüstçe ayna tutuyor.
Bu kadar basit.
Bu kadar önemli.

# Pratik kullanım fikri
1) Önce problemi tek cümlede yaz
2) İlgili dosyaları ekle
3) Plan agent ile taslağı çıkar
4) Context ring dolmadan kritik soruyu sor
5) Sonra implement aşamasına geç
6) PR öncesi muhtemelen manuel gözden geçir

C++ Tarafında Sessiz Ama Kritik Dokunuşlar

Mayıs güncellemesinin arka planında MSVC Build Tools tarafındaki iyileştirmeler de var ve bunlar manşet olmayabilir ama üretimde etkisi büyüktür inanın bana! Ben C++ dünyasına tamamen yabancı biri değilim; AZ-305 hazırlığında hibrit mimarı okurken de performans hassasiyetinin nereden geldiğini tekrar tekrar gördüm. Derleyici iyileştirmeleri bazen kullanıcıya görünmez ama build süresi düşer, binary davranışı toparlanır. Ekip nefes alır.

Buna ben kendi deneyimimden örnek vereyim: 2021’de İzmir’de bir edge senaryosunda çalışan C++ tabanlı servis üzerinde uğraşırken derleme süresi yüzünden CI hattımız tıkanıyordu (evet maalesef). Küçük gibi duran toolchain ayarı bile pipeline’ın toplam süresini ciddi etkiliyordu. O yüzden MSVC tarafındaki güncellemeleri “sadece compiler” diye küçümsememek lazım; bunlar günlük operasyonun nabzını tutuyor.

Maliyet açısından nasıl düşünmeli?

Bütçe gözüyle bakınca Visual Studio’nun sağladığı bu tip akıllı akışlar aslında zamandan tasarruf demek. Türkiye’de TL bazlı maliyet hesabı yapınca insanın aklı hemen lisans ücretine gidiyor ama asıl maliyet developer saatidir. Eğer üç kişinin yarım gününü kurtarıyorsanız araç kendini fazlasıyla amorti eder. Kurumsalda bu hesap çok net çıkar;
startup’ta işe karar biraz daha pragmatik olur:
“Gerçekten kullanacak mıyız?” sorusu belirleyicidir.

Küçük bir detay: Eğer bütçe kısıtlıysa her şeyi aynı anda almaya çalışmayın derim.
Önce Plan agent + kontrollü review alışkanlığını oturtun,
sonra context yönetimini ekleyin,
C++ tarafında işe build hattınızı ölçün. Gerçekten darboğaz varsa toolchain iyileştirmesine gidin.
Yanı mesele özellik kovalamak değil;
işe yarayan parçayı seçmek.
Burası önemli (evet, doğru duydunuz)