Dün akşam bir müşterimle konuşurken ilginç bir şey söyledi: “Aşkın, biz Copilot lisansı aldık ama ekibin yarısı hâlâ sadece otomatik tamamlamayı kullanıyor.” Ben de güldüm, çünkü bu tabloyu son altı ayda en az on farklı firmada gördüm. İşin garibi şu: parayı ödüyorsun, sonra aracın belki yüzde yirmisinden faydalanıyorsun. Evet, biraz can sıkıcı.
Size bir şey söyleyeyim, Bu yazıda lafı çok dolandırmadan, bir.NET geliştiricisi olarak Copilot’tan nasıl daha fazla verim alabileceğinizi anlatacağım. Hem kendi tecrübelerimden hem de sahada not ettiğim şeylerden süzüp getirdiklerim bunlar (inanın bana). Amacım her özelliği tek tek saymak değil — zaten Microsoft’un dokümantasyonu o işi yapıyor. Asıl mesele, hangi işte hangi yüzeyi açacağınızı bilmek. Peki neden? Çünkü yanlış yere yanlış aracı koyunca sonuç pek iç açıcı olmuyor.
Önce Görev, Sonra Mod — Tam Tersi Değil
Çoğu ekipte gördüğüm hata şu: Copilot’un yeni bir özelliği çıkıyor, herkes önü bir yerlere zorla sokmaya çalışıyor. Agent çıktı, “agent ile yapalım”; CLI çıktı, “CLI’dan deneyelim”. Halbuki doğru soru bu değil. Bak şimdi, asıl soru işin ne olduğunda gizli.
Peki neden?
Doğru soru şu: Önümdeki işin hangi parçasını delege edebilirim? Bazen sadece tek satırlık bir LINQ ifadesi tamamlatmak istiyorsundur; inline tamamlama yeter. Bazen koça bir servisi anlaman gerekiyordur; chat’e geçersin. Bazen de “şu issue’yu sen — kendi adıma konuşayım — çöz ben kahvemi içeyim” diyebileceğin bir nokta vardır; orada agent devreye girer. Yani araç değil, iş şekli belirleyici oluyor.
Bi saniye — Açık konuşayım: Ben de ilk başlarda her şeyi agent’a yaptırmaya çalıştım. Şimdi, sonuç? Beklediğim kadar iyi değildi. Çünkü agent’ı küçük ve mekanik işlere koşturmak hem yavaş hem de gereksiz token tüketimi yaratıyor. Tıpkı kıdemli bir developera “şu değişkenin ismini değiştir” demek gibi; ölür tabii ama biraz tuhaf kaçar (ki bu çoğu kişinin gözünden kaçıyor)
Hangi Yüzey, Hangi İş İçin?
Copilot artık dört ayrı yerde karşımıza çıkıyor: Visual Studio, VS Code, Copilot CLI ve bulut tarafındaki coding agent. Bunların hiçbiri “tek doğru” değil; sadece farklı işlere uygunlar. Şöyle kaba bir ayrım yaptım kendime, belki size de yarar sağlar:
Bir dakika — bununla bitmedi.
| Yüzey | En İyi Olduğu İş | Kaçınılması Gereken |
|---|---|---|
| Visual Studio | Enterprise.NET, legacy refactor, Test Agent, debugger entegrasyonu | Hızlı script işleri, multi-repo gezinti |
| VS Code | Cross-platform, container/Docker, frontend+backend karışık projeler | WinForms gibi klasik masaüstü işleri |
| Copilot CLI | Build scriptleri, dotnet komutları, CI/CD debug, terminal akışı | Büyük refactor planları |
| Cloud Agent | Issue → PR otomasyonu, kapsamlı backlog temizliği | Belirsiz, kapsam dışı işler |
Bu tablo elbette taş gibi kural değil. Ama başlangıç için baya iş görüyor — özellikle yeni başlayan ekiplerde.
Chat’i Gerçekten Ne Zaman Kullanmalı?
Chat aslında Copilot’un en az değerlendirilen tarafı. Çünkü çoğu kişi önü Google’ın yerine kullanıyor: “C# 12’de primary constructor nedir?” gibi sorularla gidiyorlar. E iyi de o iş için başka araçlar da yeterli ölür. Chat’in asıl gücü senin kendi kodunla konuştuğu anda ortaya çıkıyor.
Kısa bir not düşeyim buraya. Bu konuyla ilgili Google I/O 2026 Dialogues: Sahneden Saha Notlarım yazımıza da göz atmanızı tavsiye ederim. NL2SQL Gerçekten İşe Yarıyor mu? SQL MCP Server Notları yazımızda bu konuya da değinmiştik.
Senaryo 1: Eski Bir Servisi Anlamak
İşin garibi, Geçen ay bir bankacılık projesinde — adını veremem (evet, doğru duydunuz). Türkiye’nın büyüklerinden biri — 2016’dan kalma (belki yanilıyorum ama) bir ASP.NET Core servisi düştü önümüze. Beş bağımlılık vardı, üç farklı feature flag vardı ve uzunluğu 400 satırı geçen bir ProcessTransaction metodu duruyordu ortada. Geleneksel yaklaşım belli: oku, anla, not al ve sonra dökün; iki günlük iş yani. Microsoft Foundry Nisan 2026: Sahadan Notlar ve Yorum yazımızda bu konuya da değinmiştik.
Ben şöyle bir prompt yazdım Visual Studio chat’ine: Daha fazla bilgi için Cosmos Conf 2026: AI Çağında Veritabanı Nereye Gidiyor? yazımıza bakabilirsiniz.
“Bu servisin sorumluluğunu açıkla, ana bağımlılıkları çıkar, hangi kısımlar business logic hangileri infrastructure concern? Davranışı değiştirmeyecek ilk güvenli refactor adımını öner — kodu yazma, sadece planla.”
Sonuç? Yaklaşık 40 saniyede gelen çıktı benim iki saatte çıkaracağım haritaya oldukça yakındı. Eksikleri vardı tabii; mesela bir race condition’ı atlamıştı. Ama başlangıç noktası olarak fena değildi açıkçası. Asıl numara şurada yatıyor: kör yeniden yazma istemek yerine anlamak için kullanmak.
Senaryo 2: Test Yazdırma — Ama Akıllıca
Test yazdırma Copilot’un gerçekten işe yaradığı yerlerden biri. Lakin burada da ufak bir tuzak var: “şu metoda test yaz” deyince size çoğunlukla happy-path testi veriyorlar karşılığında. Edge case’ler gözden kaçabiliyor. Ben şöyle yapıyorum; önce zemini hazırlıyorum.
- Önce kendim happy-path testini yazıyorum (bu önemli; projenin test stilini model görüyor)
- Sonra chat’e diyorum ki: “bu metoda aynı stilde edge case testleri yaz: null input, sınır değerler, cap’lendiği durumlar ve gözden kaçması kolay senaryoları da açıkla”
- Visual Studio’daysam Test Agent‘ı devreye sokuyorum; VS Code veya CLI’daysam
.NET test skill'i / dotnet-test akışı‘na yaslanıyorum
Bunu birkaç kez denedikten sonra şunu fark ettim: edge case’leri sıraladıktan sonra “neyi atladın” diye tekrar sormak çoğu zaman ekstra iki üç test daha kazandırıyor. Modelin kendi kendini eleştirmesini istemek garip geliyor olabilir ama işe yarıyor hani. Daha fazla bilgi için MSVC 14.51 GA Çıktı: Sahadan Güncelleme Notları yazımıza bakabilirsiniz.
Ajan Tarafı: Heyecan Var mı? Var. Sürpriz Var mı? Fazlasıyla Var.
Tuhaf ama, Ajan tarafı şu an Copilot ekosisteminde en hızlı evrilen bölge gibi duruyor. Bir GitHub issue açıyorsun, agent’a atıyorsun, kahvene gidiyorsun; döndüğünde PR seni bekliyor olabilir. Kulağa hoş geliyor değil mi? Evet ama hemen alkış tutmayalım.
Dürüst olmak gerekirse, Peki neden?
Bunun cevabı basit aslında ama biraz can sıkıcı: iş net kapsamlıysa güzel çalışıyor.
Küçük not:
Geçen hafta Logosoft’ta iç projede denedim bunu.
Görev basitti:
Neyse uzatmayayım; görev DTO’ya yeni alanlar eklemekti, ilgili mapper’ları güncellemekti ve validator’ı genişletmekti.
Geçen hafta Logosoft’ta iç projede denedim bunu.
Görev basitti:
bir DTO’ya yeni alanlar ekle,
ilgili mapper’ları güncelle,
validator’ı genişlet.
Agent sekiz dakikada PR açtı.
Kodu okudum — temizdi,
testler de geçiyordu.
Birleştirdim.
Hayatımdan yaklaşık kırk beş dakika kazandım.
Ama iki gün sonra aynı agent’a
“şu authentication akışını OIDC’ye geçir”
dedim;
ortaya çıkan şey epey karışıktı:
yarım yamalak değişiklikler,
eski koddan kalan parçalar
ve eksik configuration detayları.
Mesaj netti:
agent’a verdiğiniz iş ne kadar küçük ve sınırlıysa,
başarı şansı o kadar yükseliyor.
Aynısını büyük belirsizliklerle denerseniz,
iş biraz dağılıyor.
Tam da öyle.
{}
Let’s continue.
We need final HTML only but preserve tags exactly? Must not include extra weird text.
Sıkça Sorulan Sorular
.NET için hangi Copilot sürümünü kullanmalıyım?
Aslında, Bence.NET tarafı için Business ya da Enterprise sürümleri çok daha mantıklı — valla güzel iş çıkarmışlar —. Bireysel sürüm de aslında işini görüyor, ama enterprise senaryolarda mesela IP indemnification, audit log ve custom model erişimi gibi şeyler gerçekten kritik oluyor (inanın bana). Bankacılık veya finans projelerinde çalışıyorsanız, açıkçası Enterprise’ı düşünmenizi öneririm.
Copilot kodumu Microsoft’a gönderiyor mu?
Araya gireyim: Business ve Enterprise sürümlerinde kodunuz model eğitiminde kullanılmıyor, bu sözleşme güvencesi altında. Ama şunu da söylemek lazım — promptlarınız ve bağlam olarak gönderilen kod parçaları işlem sırasında yine de Microsoft sunucularına gidiyor. Hassas verileriniz varsa, organizasyon seviyesinde content exclusion kuralları tanımlamak iyi bir fikir.
Inline tamamlama mı, chat mi, agent mı daha verimli kullanıyor?
Aslında üçü de farklı işler için var. Inline mekanik tekrarlar için, chat (söylemesi ayıp) anlama ve planlama için, agent işe kapsamı net olan ve delege edebileceğiniz işler için kullanılıyor. Yani “hangisi daha verimli?” diye sormak biraz yanlış — asıl soru şu: hangisi hangi iş için?
Agent’a bir issue verdim, yanlış PR açtı. Ne yapmalıyım?
Önce issue’nuza bir bakın: acceptance criteria net mıydı, dosya yolları belirtilmiş mıydı? Tecrübeme göre sorun genelde prompt tarafında oluyor. Aynı issue’yu bu sefer daha detaylı yazıp tekrar verin, ya da işi daha küçük parçalara bölün. Büyük ve belirsiz işlerde agent maalesef başarısız oluyor.
Türkçe prompt yazınca Copilot anlıyor mu?
Anlıyor, evet. Ama bence karma yazım çok daha iyi sonuç veriyor. Hani teknik terimleri ve kod taleplerini İngilizce, bağlam ve açıklamayı Türkçe yazmak ideal bir denge sağlıyor. Tamamen Türkçe yazınca bazen teknik terimlerde garip çeviriler yapabiliyor, açıkçası o biraz can sıkıcı.
Kaynaklar ve İleri Okuma
Doing More with GitHub Copilot as a.NET Developer — Microsoft.NET DevBlog
GitHub Copilot Resmî Dokümantasyonu
Visual Studio için GitHub Copilot — Microsoft Learn (ben de ilk duyduğumda şaşırmıştım)
GitHub Changelog — Copilot Güncellemeleri
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.
