Geçen hafta bir müşteride aynen şu sahneyi yaşadım: Junior bir geliştirici arkadaş Copilot’a “şu ödeme modülünü çoklu sağlayıcı destekleyecek şekilde refactor et” demiş. On dakika sonra ekibe çağrıldım, adam panikliyor; Copilot 14 dosya değiştirmiş, yeni bir PaymentProvider abstraction’ı kurmuş, factory pattern eklemiş, eski testlerin yarısını da kırmış (ki bu çoğu kişinin gözünden kaçıyor). Kod yanlış mıydı? Hayır. Aslında — hayır dür, daha doğrusu bayağı düzgündü ama ekibin kafasındaki mimariyle hiç alakası yoktu.
Sonra git reset attık. Saat kaybı yaklaşık 2 buçuk saat. Kısa sürdü sanmayın.
Hani, İşte tam bu yüzden Visual Studio’nün yeni Plan agent‘ı çıktığında — ki ben aslında geçen sene Agent mode içine gömülü gelen planlama özelliğinden beri bunu bekliyordum — biraz heyecanlandım. Ama öyle göğe çıkacak kadar değil; çünkü bazı eksikleri de var, hatta can sıkacak yerleri bile var (şaşırtıcı ama gerçek). Onlara da geleceğiz.
Plan Agent Nedir, Neden Şimdi Çıktı?
Eh, Kısaca söyleyeyim: Plan agent, Copilot Chat’in agent picker’ında çıkan yeni bir mod. Seçtiğiniz anda Copilot hemen kod yazmaya dalmıyor. Önce sızı dinliyor, kodu read-only modda tarıyor, takıldığı yerde soru soruyor, sonra da markdown dosyası olarak bir uygulama planı çıkarıyor. Siz onay vermeden tek satır bile değişmiyor. İyi mi? Bence baya iş görüyor.
Bu kulağa basit geliyor, ama işin içinde küçük bir yön değişimi var. Geçen yılki “vibe coding” havasında herkes Copilot’a — kendi adıma konuşayım — “al bunu yap” diyordu; şimdi Microsoft tarafı biraz frene basmış gibi: “Önce düşün, sonra yaz.” Açık konuşayım, kurumsal ekiplerde bu yaklaşım daha az baş ağrıtır. Hatta bazen tek fark o oluyor.
Çok konuştum, örnekle göstereyim.
Plan dosyaları .copilot/plans/plan-{title}.md altına kaydediliyor. Yani isterseniz git’e commit ediyorsunuz, PR review’da bakıyorsunuz, yeni gelen takım arkadaşına da “şu planı oku, sonra konuşalım” diyebiliyorsunuz. İşte benim için asıl kıymetli kısım bu. Planın ortada durması, sonradan kim neye karar verdi sorusunu epey azaltıyor.
Nasıl Çalışıyor — Adım Adım
Açık konuşayım, Akış aslında düz gibi duruyor ama ufak sürprizleri var: (inanın bana)
- Agent seçimi: Copilot Chat’te agent picker’dan “Plan” seçiyorsunuz. Sonra ne istediğinizi anlatıyorsunuz; mesela “bu uygulamaya authentication ekle” kadar genel olabilir ya da “ödeme modülünü Stripe + Iyzico destekleyecek şekilde böl” kadar nokta atışı gidebilir.
- Keşif ve netleştirme: Copilot kodu read-only araçlarla tarıyor. Bir yer muğlaksa soru soruyor; hani şu tıp sorular var ya: “Mevcut
UserService‘i mi genişleteyim yoksa yeni birAuthServicemi açayım?” Tam burada insan biraz rahatlıyor, çünkü kafadan atıp gitmiyor. - Taslak ve iterasyon: Plan çıkıyor. Beğenmediyseniz de boş durmuyorsunuz; “şu adımı 3 parçaya böl”, “edge case’leri ekle”, “şu dosyaya dokunma” diyebiliyorsunuz. Aslında güzel tarafı şu: plan sabit değil, biraz şekil alıyor. — bunu es geçmeyin
- Doğrudan düzenleme: Markdown dosyasını editörde açıp elle değiştirebiliyorsunuz. Chat de senkron kalıyor; yani biri sağdan çekiştirirken öbürü soldan bırakmıyor gibi bir durum yok.
- Implement: “Implement plan” butonuna bastığınızda top Agent mode’a geçiyor. O noktadan sonra kod yazılmaya başlanıyor. Peki neden bu ayrım önemli? Çünkü önce niyet netleşiyor, sonra icraat geliyor.
Ben ilk denediğimde küçük bir takılma yaşadım — plan dosyası oluşmadı ve sistem sessizce bekledi kaldı. Sonra baktım ki .copilot klasörü .gitignore‘da değildi ama workspace tarafında izin işi bozulmuştu (klasik küçük pürüz). Çözüm olarak Visual Studio’yu admin açmadım; o refleks çoğu zaman boşuna uğraştırıyor zaten. Onun yerine solution dizinine write permission verdim ve iş düzeldi.
Evet.
Türkiye’deki Ekipler Açısından Ne İfade Ediyor?
Bak şimdi, Açık konuşayım, Türkiye’deki yazılım ekiplerinin epey büyük bir kısmında, özellikle ajans ve outsource tarafında çalışanlarda, “planlama” biraz lüks gibi görülüyor. Müşteri bugün istiyor, yarına teslim. PRD yok, mimarı doküman yok, bazen Jira ticket’ı bile yok; böyle bir düzende Plan agent’ın ne kadar tutacağı konusunda dürüst olayım, ben de biraz şüpheliyim (kendi tecrübem)
Yine de enterprise tarafta iş değişiyor. Bankacılık, telekom, sigorta gibi sektörlerde çalışan ekipler için bu baya iş görüyor. Çünkü o dünyada her commit’in arkasında bir “neden” olması gerekiyor (yoksa review süreci hemen dağılıyor), plan dosyasını PR’a iliştirmek de code review’ı baştan başka bir seviyeye çekiyor. Bir banka projesinde geçen ay tam da bunu manuel yapıyorduk: Confluence’a plan yazıyor, sonra PR’a link veriyorduk; Plan agent bu işi otomatikleştirebilir.
Bence Plan agent’ın asıl değeri “AI’ın daha iyi kod yazması” değil — “insanın AI ile çalışırken kendi kafasını berraklaştırması”. Bu fark çok önemli.
Bir de junior tarafı var ki, orası ayrı bir hikâye. Junior geliştiriciler için fena olmayan bir öğrenme aracı bu. Senior bir geliştirici nasıl bir feature’a yaklaşır, hangi dosyalara bakar, edge case’leri nasıl düşünür — Plan agent bunu adım adım gösteriyor; yani sadece çıktı üretmiyor, düşünce şeklini de az çok ele veriyor. Logosoft’ta yeni başlayan bir arkadaşa geçen hafta bunu önerdim, “hocam bir feature’a başlamadan önce planı oku, sonra kodu yaz” dedim. İki gün sonra gelip “yaptığım PR’lar daha ilk turda geçiyor” dedi. Tesadüf olabilir tabi ama… hmm, insan yine de durup düşünüyor.
Plan Mode vs Agent Mode: Ne Zaman Hangisi?
Bu soruyu epey alıyorum, o yüzden lafı uzatmadan baştan söyleyeyim. Aşağıdaki tablo, benim sahada gördüklerime göre şekillendi; yani teorik bir güzelleme değil, baya gerçek işlerden süzülen bir özet.
| Senaryo | Önerim | Neden |
|---|---|---|
| Bug fix, tek dosya | Agent mode | Plan zaten aşikar, ekstra adım gereksiz |
| Yeni feature (5+ dosya) | Plan agent | Mimarı kararlar var, önce konuşmak lazım |
| Refactor (legacy kod) | Plan agent | Kırılabilecek yerler önceden tespit edilmeli |
| Test yazma | Agent mode | Pattern belli, hızlı yürüyor |
| Migration (örn..NET 8 → 10) | Plan agent | Adım atlanması felaket, sıralı ilerlemeli |
| Prototip / POC | Agent mode | Hız önemli, mimarı sonra düşünülür |
Evet, bu kadar net. Ama dür bir saniye — bunu mutlak kural gibi okumayın. Ekibinizin olgunluğu, repo’nün hâli, hatta o günkü aciliyet bile seçimi değiştirir. İlginç, değil mi? Hani bazen aynı iş için iki farklı ekip iki farklı yol seçer ya, işte burada da öyle bir durum var.
Ben genelde şöyle bakıyorum: iş tek hamlede bitecek gibiyse Agent mode daha rahat akıyor; (buna dikkat edin). Ortada karar vermeniz gereken birkaç kritik nokta varsa Plan agent tarafı daha az sürpriz çıkarıyor. Kısacası hız ile kontrol arasında gidip geliyorsunuz.
Küçük Bir Trick: Plan’ı Şablon Olarak Kullanmak
İlginç olan şu ki, Bunu ilk fark ettiğimde açık konuşayım, “hmm, fena fikir değil” dedim (kendi tecrübem). Plan dosyaları markdown olduğu için sık yaptığınız işleri şablona çevirmek baya kolay oluyor; mesela “yeni mikroservis ekleme” ya da “yeni endpoint yazma” gibi akışları repo içinde hazır tutabiliyorsunuz. Biz .copilot/plans/templates/ diye bir klasör açtık, içine standart akışları koyduk ve yeni feature başlarken o şablonu kopyalayıp Copilot’a “şuna benzer bir plan çıkar” demeye başladık. Şaşırdım açıkçası, çünkü beklediğimden daha az uğraştırdı.
Neyse, çok dağıtmadan devam edeyim. Bu yaklaşımın güzel tarafı şu: aynı işi her seferinde sıfırdan anlatmıyorsunuz (özellikle ekip içinde tekrar eden işler varsa), üstüne bir de risk alanlarını boş bırakmayıp baştan düşünüyorsunuz. Yani plan sadece “ön hazırlık” olmuyor, biraz da hafıza gibi çalışıyor. Motorun Ötesi: Oyun Yapımında 10 Açık Kaynak Cevher yazımızda bu konuya da değinmiştik.
#.copilot/plans/templates/new-microservice.md
## Hedef
[Servisin amacı]
## Etkilenen Bileşenler
- API Gateway routing
- Service Discovery (Consul)
- Observability (OpenTelemetry)
- CI/CD pipeline
## Adımlar
1. Proje iskeletini oluştur (dotnet new...)
2. Health check endpoint ekle
3. Logging konfigürasyonu
4. Dockerfile + helm chart
5. Pipeline tanımı
## Risk Alanları
- [Doldurulacak]
Peki neden işe yarıyor? Çünkü bu şablonla ekip aynı dili konuşmaya başlıyor; biri “hangi bileşenler etkileniyor” kısmını atlamıyor, diğeri de “risk alanları” satırını sonradan hatırlamaya çalışmıyor. Ufak gibi duruyor ama pratikte ciddi fark ediyor.
Şimdi gelelim işin can alıcı noktasına.
Bilmem anlatabiliyor muyum, Eğer siz de sık tekrar eden işler yapıyorsanız, bence önce küçük bir şablon seti kurun. Sonra bakarsınız; bazı işler doğal olarak Agent mode’a kayar, bazıları işe Plan agent olmadan biraz sakar kalır. Tam da öyle.
Eksikler ve Hayal Kırıklıkları
Şimdi işin can sıkıcı tarafına gelelim. Plan agent her şeyiyle pürüzsüz değil, hatta bazı noktalarda açık konuşayım, beni baya şaşırttı; güzel tarafları var tabii. Bazı küçük gibi duran eksikler, günlük akışta insanın sınırını bozabiliyor.
Tuhaf ama, Birinçisi şu: Büyük monorepo’larda hız düşüyor. 200+ projelik bir solution’da plan üretmesi 40 saniyeyi buldu, yani öyle felaket değil ama ekran başında beklerken zaman biraz uzuyor. Akış da doğal olarak bölünüyor. Microsoft’un bu tarafta caching mekanizmaları üstünde çalıştığını duydum, hmm, bakalım gerçekten toparlayacak mı.
Küçük bir detay: İkincisi de biraz garip aslında: Plan’ı düzenlerken Copilot bazen sizin elle yaptığınız değişiklikleri tam kavrayamıyor. Markdown’da bir adımı sildiğinizde chat tarafı hâlâ o satır duruyormuş gibi davranabiliyor, yani senkron her zaman tam oturmuyor; kısa cevapla söyleyeyim, %100 güven vermiyor.
Üçüncüsü — ve bence en önemli kısmı — Plan agent kodu okuyor ama çalıştırmıyor. Yani “şu test geçti mi”, “bu API — kendi adıma konuşayım — gerçekten dönüyor mu” gibi runtime sorularına net cevap veremiyor; kağıt üstünde çok düzgün duran bir plan, gerçek hayatta bazen ilk kontrolde dağılıyor. Bu yüzden Visual Studio Agent Skills: Copilot’a Takimi Öğretmek yazımda anlattığım custom skill yaklaşımıyla desteklemek gerekiyor — tek başına bırakınca yetmiyor, lafı gevelemeden söyleyeyim. .NET 11 Process API: Deadlock’suz Süreç Yönetimi Geldi yazımızda bu konuya da değinmiştik.
LLM Cold Start Çilesi: Run:AI Streamer ile 6x Hız yazımızda bu konuya da değinmiştik.
.gitignore‘a EKLEMEYIN. Aksine commit edin. PR review’da çok işinize yarayacak. Ama hassas bilgi (DB şifresi, API key) yazmamaya dikkat — Copilot bazen connection string örneği koyabiliyor plana.
FinOps Açısından: Token Maliyeti Ne Ölür?
Bu sorunun cevabı, açık konuşayım, ilk bakışta göründüğü kadar düz değil. Plan agent kodu daha fazla tarıyor, daha çok soru soruyor,. Normal Agent mode’a göre token tüketimi artıyor; insan da bunu görünce önce “vay be” diyor.
Burada, bilmem anlatabiliyor muyum, Ama işin aslı şu: Plan agent kullanmadığınızda Copilot’un yanlış yola sapıp 14 dosyayı kurcalaması da ayrı bir token faturası çıkarıyor. Sonra git reset, ardından bir tür daha deneme… Peki hangisi daha pahalı? Benim gördüğüm kadarıyla orta-büyük feature’larda Plan agent net %20-30 token tasarrufu sağlayabiliyor, küçük işlerde işe tam tersi biraz fazla kaçabiliyor.
Kısa bir not düşeyim buraya.
Copilot Business lisansındaysanız bu hesap zaten sabit, kafaya takmaya pek gerek yok. Ama API üzerinden tüketim modeliyle gidiyorsanız, Copilot Business’ta Yeni Dönem: GPT-5.3-Codex Devrede yazımda anlattığım model seçim yaklaşımına bir göz atın — plan tarafında daha ucuz bir model, implement tarafında işe daha dolu bir model kullanmak baya iş görüyor. Bu konuyla ilgili Kubernetes v1.36 Server-Side Sharded Watch: Saha Notları yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Kubernetes v1.36’da PSI Metrikleri GA: Sahadan Notlar yazımıza bakabilirsiniz.
Pratik İpuçları: İlk Hafta İçin Rehber
Denemek isteyenler için hızlı bir checklist:
- İlk gün: Küçük bir feature’da deneyin. Mesela “şu endpoint’e validation ekle” gibi. Planı açıp bir okuyun, sonra da kendi kendinize “ben bunu böyle mi kurardım?” diye sorun; bazen ilk bakışta düzgün görünen şey, biraz kurcalayınca epey farklı çıkıyor. — ciddi fark yaratıyor
- İkinci-üçüncü gün: Bir refactor görevi verin. Dosya sayısı biraz fazla olsun, işin tadı orada çıkıyor. Hani küçük işlerde herkes konuşur ya, asıl mesele burada belli oluyor; Plan agent’ın neyi yakalayıp neyi ıskaladığını daha net görüyorsunuz.
- Bir hafta sonra: Ekibinizle plan dosyalarını PR’a ekleme alışkanlığı edinin. Review tarafı değişiyor, evet; ama sadece süreç değil, ekip içi tartışma biçimi de yavaş yavaş başka bir yere gidiyor, ve bu bence hiç fena değil.
- İki hafta sonra: Şablonlar oluşturun. Tekrar eden iş akışlarınızı standartlaştırın; yoksa aynı şeyleri tekrar tekrar anlatıp duruyorsunuz, açık konuşayım bu da insanı yoruyor.
Bir de şunu söyleyeyim: Plan agent’ı “kod yazma asistanı” gibi değil, “tasarım arkadaşı” gibi düşünün (kendi tecrübem). Onunla tartışın, fikir alın, kararlarınızı sorgulayın; mesela direkt “tamam, yap” demek yerine “şuna alternatif bir yaklaşım var mı?” diye sorun, çünkü çoğu zaman güzel görünen yolun yaninda daha sakın ama daha temiz bir rota da çıkıyor ortaya.
Evet.
Neyse uzatmayalım: En iyi sonucu bu modda alıyorsunuz.
Startup mı, Enterprise mı? Kim Daha Çok Kazanır?
Açık konuşayım, bu özelliği ilk duyduğumda aklımdan geçen şey şuydu: “enterprise tarafında iş görür, startup için biraz fazla kaçıyor.” Sonra bir-iki hafta kurcaladım, baktım ki olay öyle düz değil; küçük ekipte de baya işe yarıyor, hatta bazen daha da fazla.
Startup’larda değer kısmı başka yerden geliyor. Küçük ekiplerde “senior architect” rolü çoğu zaman boş kalıyor, yani kurucu var, iki-üç developer var, teknik kararlar havada asılı duruyor; Plan agent tam orada devreye girip o eksik “düşünce ortağı” hissini veriyor (bedava bir tech lead gibi düşünün), garip ama gerçek.
Enterprise tarafında işe işin rengi değişiyor. 50 kişilik bir geliştirme ekibinde herkes kafasına göre kod yazınca işler çabuk dağılıyor; Plan agent ile şablonlar. Code review yan yana gelince ortak bir dil oluşuyor, bu da uzun vadede teknik borcun üst üste binmesini ciddi şekilde yavaşlatıyor.
Çok konuştum, örnekle göstereyim.
Sıkça Sorulan Sorular
Plan agent ücretli mi, ekstra lisans gerekiyor mu?
Hayır, zaten sahip olduğunuz GitHub Copilot aboneliğiyle (Individual, Business veya Enterprise) geliyor. Yani ekstra bir kuruş ödemiyorsunuz. Sadece Visual Studio’nün güncel sürümünde Copilot Chat’in agent picker’ından seçmeniz yeterli.
Plan dosyalarını git’e commit etmeli mıyım?
Bence kesinlikle evet. .copilot/plans/ klasörü aslında PR sürecinin doğal bir parçası olmalı. Hem code review kalitesi ciddi şekilde artıyor, hem de ilerleyen zamanlarda “hani biz bu kararı neden almıştık?” diye kafayı yemiyorsunuz. Tek dikkat etmeniz gereken şey şu: plan içinde hassas bir bilgi varsa (API key, şifre falan) onları mutlaka temizleyin.
Plan agent, kodumu Microsoft sunucularına gönderiyor mu?
Evet, tıpkı normal Copilot’ta olduğu gibi context için kod parçaları modele gönderiliyor. Ama şunu da belirtelim: Copilot Business/Enterprise’da bu veriler eğitimde kullanılmıyor (ciddiyim). Enterprise data protection devrede oluyor. Yine de açıkçası regülasyonu sıkı bir sektördeyseniz, mesela sağlık veya finans gibiyseniz, IT politikalarınızı bir kontrol edin derim.
Plan agent çalışırken yanlışlıkla kod değiştirebilir mi?
Size bir şey söyleyeyim, Hayır. Plan modundayken Copilot sadece read-only araçlar kullanıyor, dosyalara dokunmuyor. Asıl değişiklikler ancak siz “Implement plan” butonuna bastığınızda başlıyor; o noktada top Agent mode’a geçiyor. Yani o adıma kadar içiniz rahat olsun.
Plan agent ile Agent Skills birlikte kullanılabilir mi?
Kısacası, küçük bir detay: Evet, hatta tecrübeme göre en iyi kombinasyon zaten bu ikisi. Plan agent stratejiyi çıkarıyor, Agent Skills işe ekibinize özel custom işleri hallediyor, mesela “bizim test pattern’imize göre test üret” gibi şeyleri. İkisi birbirini gerçekten çok güzel tamamlıyor.
Kaynaklar ve İleri Okuma
Plan Before You Build: Introducing the Plan agent in Visual Studio (Resmî Duyuru)
Visual Studio Copilot Agent Mode Dokümantasyonu
GitHub Copilot Resmî Dokümantasyonu
Visual Studio Developer Community (Geri bildirim için) (inanın bana)
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.
