Visual Studio’da Plan Agent: Kodu Yazmadan Önce Durup Düşünmek
Bir feature’a dalıp sonra “bu değil” demek…
Şunu açık konuşayım: Copilot’un ya da başka bir ajan tabanlı aracın en büyük tuzağı, sizi fazla hızlı üretime itmesi. Bir şey istiyorsunuz, o da kolları sıvıyor, dosyaları kurcalıyor, birkaç dakika sonra bakıyorsunuz… evet, çalışan bir şey var ama (belki yanılıyorum ama) sız aslında bambaşka bir yön düşünüyordunuz. İşin aslı şu ki, bu durum sadece küçük ekiplerde değil, kurumsal yapılarda daha da can sıkıcı oluyor. Çünkü yanlış yönde atılan her adım; review yükü, test maliyeti ve bazen de güvenlik riski demek.
Microsoft’un Visual Studio içine getirdiği Plan agent tam burada anlamlı dürüyor. Önce planı netleştiriyor, sonra kodlamaya geçiyor (yanlış duymadınız). Bu yaklaşım bana biraz mimarın önce çizim yapıp sonra inşaata başlamasını hatırlatıyor. Hani temeli atmadan önce ölçüp biçmek gibi… Basit görünüyor ama çoğu projede eksik olan tam da bu.
Peki neden?
2024’ün sonlarında bir fintech müşterisinde benzer bir akış yaşadık; İstanbul Ataşehir’deki ekip Copilot ile doğrudan hayata geçirmea atlayınca ödeme modülünde gereksiz dosya değişiklikleri oluştu. Sonra geri dönüp planlama katmanı ekledik ve sürpriz şekilde review süresi neredeyse yarıya indi. O gün şunu net gördüm: iyi kod yazmak kadar, doğru işi seçmek de önemli.
Şahsen, Bir de şu var: Plan agent’in kıymeti sadece “yanlış kodu önlemek” değil. Asıl farkı, belirsizliği azaltması. Bazen müşteri ne istediğini biliyor sanırız ama detay sorunca tablo değişir. “Kimlik doğrulama ekle” derler mesela; sonra MFA mı olacak, SSO mu olacak, hangi tenant modeli kullanılacak çıkar ortaya. E tabi işte burada plan aşaması hayat kurtarıyor.
Peki neden?
Plan agent nasıl çalışıyor?
Şahsen, Kullanım akışı oldukça sade. Visual Studio içinde Plan agent’i seçiyorsunuz, ardından yapmak istediğiniz şeyi anlatıyorsunuz (ciddiyim). Copilot önce kod tabanını okuma araçlarıyla tarıyor; yanı elini sürmeden önce etrafı yokluyor diyelim. Ambiguity varsa soru soruyor, netse taslağı çıkarıyor.
Vallahi, Bu bana 2019’da kendi lab ortamımda yaptığım eski usül danışmanlık işlerini hatırlattı. O zamanlar otomasyon yoktu; Azure Stack tarafında — kendi adıma konuşayım — bir migration için önce saatlerce whiteboard çalışması yapardık. Şimdi aynı mantık daha hızlı geliyor ama fikir aynı: önce düşün, sonra koş.
Kısa bir not düşeyim buraya.
Plan hazır olunca sız önü direkt düzenleyebiliyorsunuz. Markdown dosyası olarak saklanması bence baya iyi bir tercih; çünkü plan artık chat penceresinde kaybolan geçici bir metin olmaktan çıkıyor. Takımla paylaşılabiliyor, üzerinde yorum yapılabiliyor, gerektiğinde versiyonlanabiliyor.
Benim gözümde Plan agent’in gerçek değeri “kod üretmek” değil; yanlış başlangıç yapma ihtimalini düşürmesi.
Akışın dört kritik noktası
İlk nokta kapsamın tarif edilmesi. Ne kadar net anlatırsanız ilk taslak o kadar iyi olur. İkinci nokta soru-cevap kısmı; burası küçük gibi görünür ama çoğu zaman projeyi kurtaran bölüm burasıdır.
Aslında, Üçüncü nokta planın birlikte rafine edilmesi. Dördüncü nokta işe implement’e geçiş izni vermek. Yanı sistem size “ben hazırım” demiyor; sız “tamam, şimdi başla” diyorsunuz.
.copilot/plans/plan-{title}.md altında tutuluyor. Ve sonuç: ekip içi inceleme ve revizyon daha rahat hâle geliyor.
Neden şimdi önemli öldü?
Ajan araçlarının en büyük problemi hızla birlikte gelen acelecilikti. Çoğu ekipte problem teknik değil; süreç problemi oluyor. Bilhassa enterprise tarafta güvenlik onayı, mimarı kontrol ve test kapıları varken doğrudan implementasyon bazen iş akışını bozuyor. Bu konuyla ilgili LLM Cold Start Derdi: Blob Stream ile Hız Kazanmak yazımıza da göz atmanızı tavsiye ederim.
Bunu Türkiye’deki şirketler açısından değerlendirirsek durum biraz daha ilginçleşiyor. Kurumsal müşterilerimde gördüğüm kadarıyla bizde karar mekanizmaları çoğu zaman çok katmanlı ilerliyor. Ürün sahibi ayrı konuşuyor, güvenlik ayrı bakıyor, operasyon ekibi ayrı yorumluyor… Böyle olunca planın yazılı ve paylaşılabilir olması ciddi avantaj veriyor — valla güzel iş çıkarmışlar — Daha fazla bilgi için T-SQL Regex Artık Büyük Veride de Rahat: CU5 Detayı yazımıza bakabilirsiniz.
Küçük startup tarafında işe mesele başka: orada hız öncelikli olduğu için bazı ekipler “planla vakit kaybetmeyelim” diyebilir. Açık söyleyeyim, erken aşamada bu yaklaşım bazen — en azından ben öyle düşünüyorum — işe yarar gibi görünür ama ürün büyüdükçe borç bırakır. Enterprise’da işe tersi; ilk günden plan disiplini koymazsanız sonraki sprintlerde duvara toslarsınız. Bu konuyla ilgili npm’de İmzayı Sıkılaştıran Yeni Dönem: Stage Queue ve Allow Flag’ler yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Azure NetApp Files ile EDA Yükünü Bulutta Taşımak: Neden İşe Yarıyor? yazımıza bakabilirsiniz.
Ağustos 2025’te Levent’te bir üretim projesinde buna çok yakın bir şey yaşadık; AI destekli refactor sırasında üç ayrı servis beklenmedik biçimde etkilendi çünkü başlangıç niyeti yeterince net yazılmamıştı (evet, doğru duydunuz) — dürüst olayım, biraz hayal kırıklığı —. Sonradan plana dönüp işi parçalara — itiraz edebilirsiniz tabi — ayırdık ve hata oranı düştü… yanı evet, kağıt üstünde ekstra adım gibi dürüyor ama pratikte masraf azaltıyor.
| Senaryo | Sadece Agent Mode | Plan agent + Implement |
|---|---|---|
| Küçük MVP | Daha hızlı başlangıç | Birkaç dakika gecikir ama yön netleşir |
| Kurumsal refactor | Daha fazla risk | Daha kontrollü ilerler |
| Ekip içi review | Zayıf iz bırakır | Plandan dolayı takip kolaylaşır |
| Maliyet etkisi | Tahmin zorlaşır | Daha öngörülebilir olur |
Sahada ne işe yarar?
Bence en kuvvetli kullanım alanı refactoring ve yeni özellik tasarımı arasında kalınan anlar. Hani ne farkı var diyorsunuz, değil mi? Mesela ödeme modülüne yeni sağlayıcı ekleyeceksiniz; hemen kod yazmaya başlamak yerine önce hangi dosyalar dokunacak, edge case’ler ne olacak, rollback senaryosu nasıl işleyecek bunu görmek güzel oluyor. MSVC’de SPGO Neyi Değiştiriyor: PGO’nun Pratik Hali yazımızda bu konuya da değinmiştik.
Bazı durumlarda beklediğim kadar iyi değildi desem yalan olmaz… Hele bir de çok karmaşık monolith yapılarda read-only tarama bile yeterince bağlam bulamayabiliyor çünkü kod zaten yılların iziyle dolu oluyor. Orada insan müdahalesi şart kalıyor; yanı sihirli değnek değil bu.
Kime daha uygun?
Küçük ekipler için bu özellik biraz lüks gibi gelebilir ama bence erken disiplin kazandırdığı için değerli olabilir. Bilhassa de tek kişinin hem product owner hem developer olduğu ortamlarda fikirlerin kaybolmasını engelliyor.
Eh, Büyük kurumsal yapılarda işe fayda daha bariz görünüyor çünkü onay zinciri uzun oluyor ve her değişikliğin gerekçesini göstermek gerekiyor (mesela denetim zamanı). Plan agent burada belge üretme alışkanlığını doğal hâle getiriyor.
Aman ha, unutmayın: yerler
- Planda belirsiz ifadeler bırakmayın; “gerekirse”, “uygun görülürse” gibi muğlak kelimeler sonucu zayıflatır.
- Kod tabanı eskiyse ajan yanlış yere odaklanabilir; ilk planda mutlaka gözden geçirin.
- Plandaki dosya listesini körü körüne kabul etmeyin, özellikle güvenlik veya veri erişimi olan projelerde. (bu kritik)
- Eğer bütçe sınırlıysa önce dar kapsamlı görevlerde deneyin; tüm feature set’i aynı anda vermeyin.
- Plandan memnun kalmadan implement’e basmayın… cidden gerek yok. — ciddi fark yaratıyor
Kendi notlarım: hız mı kontrol mü?
AZ-305’e hazırlanırken hep şu ayrımı düşünmüştüm: teknoloji seçimi ile mimarı karar aynı şey değil. Burada da benzer durum var; Copilot size teknik olarak yardım ediyor. Karar disiplinini sizin vermeniz gerekiyor.
Bunu oturtamazsanız araç sizi götürüyor gibi görünürken aslında sız araca yetişmeye çalışıyorsunuz.
Nisan 2026’da Maslak’taki bir holding dönüşüm projesinde benzer mantığı DevOps akışına uyguladık: pipeline’dan önce change plan çıktısı almak review süresini azalttı ve sürprizleri düşürdü.
Bu yüzden Plan agent’i yalnızca IDE özelliği diye görmek bana eksik geliyor; süreç iyileştirme aracı gibi düşünmek daha doğru.
E tabi maliyet tarafını da unutmamak lazım.
Azure tarafında ya da genel bulut harcamalarında plansız başlayan işler genelde fazla döngü tüketir: fazla prompt, fazla revizyon, fazla deneme… Sız hiç denediniz mi? TL bazında bakınca küçük görünür ama ay sonunda can sıkar.
Hele bir de danışmanlık verdiğim orta ölçekli şirketlerde bunu defalarca gördüm — iki saatlik yanlış yönlenme bazen bir günlük teslimatı etkiliyor.
Kısacası benim görüşüm ne?
Bence bu doğru yönde atılmış bir adım. Hâlâ pişmesi gereken yerleri var.
Mesela planların takım içinde standartlaştırılması için şablon desteği biraz daha güçlü olsa fena olmazdı.
Yine de mevcut hâliyle bile “önce düşün sonra yap” kültürünü güzel taşıyor.
Ve açıkçası buna ihtiyacımız vardı.
Çok fazla ekip doğrudan üretime koşuyor…
Pratikte nasıl başlamalı?
- Lokal ya da test repoda küçük bir görev seçin.
- Planda hedefi tek cümlede net yazın.
- Cevaplanan soruları mutlaka okuyun.
- Planda dokunulan dosyaları gözden geçirin.
- Anladığınızdan emin olmadan implement’e geçmeyin.
- Ekip arkadaşınıza paylaşmadan önce markdown’u temizleyin.
Eğer bugün deneyecekseniz ilk iş olarak authentication veya küçük bir refactor görevi verin derim.
Böylece hem soru sorma davranışını hem de plan kalitesini görürsünüz.
İlk denemede devasa migration vermeyin… kötü tat bırakabilir!
Sıkça Sorulan Sorular
Plan agent ile normal Copilot Agent Mode arasındaki fark ne?
Plan agent önce her şeyi anlayıp bir plan çıkarıyor, sonra uygulamaya geçiyor. Normal Agent Mode işe hani daha doğrudan aksiyona dalıyor. Aslında kontrol sizin için önemliyse Plan agent çok daha mantıklı bir seçenek.
Plandaki dosyayı elle düzenleyebilir mıyım?
Evet, kesinlikle.
Plan zaten markdown olarak saklandığı için doğrudan edit edebilirsiniz, yanı ekstra bir şey yapmanıza gerek yok.
Tecrübeme göre bu özellik ekip içi review’larda baya işe yarıyor.
Büyük kurumsal projelerde gerçekten işe yarar mı?
Şunu fark ettim: Evet,
özellikle çok paydaşlı projelerde faydası çok daha belirgin hissediliyor. Mesela onay mekanizması olan ortamlarda yazılı bir plan olması ciddi rahatlık sağlıyor. Ama açıkçası karmaşık legacy sistemlerde yine de insan gözü şart, bunu atlamamak lazım.
Kod değişmeden önce güven veriyor mu?
Açık konuşayım, Bence evet,
çünkü niyet ile çıktı arasındaki farkı erkenden yakalatıyor, bu çok değerli.
Yine de yüzde yüz garanti beklememek lazım;
ajan sonuçta tahmin ediyor,
son doğrulama yine size kalıyor.
Kaynaklar ve İleri Okuma
Visual Studio Copilot Plan Agent Resmî 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.
4 comments