GitHub Copilot’ta .NET İşini Doğru Yerden Tutmak
İşin garibi, GitHub Copilot’la ilgili en büyük yanılgı şu: Her özelliği tek tek ezberlersen daha hızlı olacağını sanıyorsun. Açık konuşayım, pratikte iş öyle yürümüyor. Benim 20+ yıllık sistemcilik ve bulut tarafı tecrübemde de, AZ-305 ve AZ-104 hazırlıklarında da, bir aracı gerçekten verimli yapan şey önce “hangi mod var?” sorusu değil, “elimdeki işi hangi parçaya bölerim?” sorusu öldü.
.NET tarafında bu yaklaşım daha da netleşiyor. Çünkü bir gün eski bir ASP.NET Core servisini anlamaya çalışıyorsun, ertesi gün unit test yazıyorsun, sonra bir controller içindeki karmaşayı toparlaman gerekiyor… İşin aslı şu ki, Copilot’un gücü tam burada çıkıyor. Inline tamamlama günlük işleri hızlandırıyor; chat düşünmeyi kolaylaştırıyor; ajan tarzı akışlar işe belli sınırlar içinde işi senin yerine koşturuyor. Hepsi güzel. Ama hepsini aynı kefeye koyarsan biraz çorba oluyor.
Bir dakika — bununla bitmedi.
Geçen yıl Eylül ayında, İstanbul’da bir finans müşterisinde benzer bir durum yaşadık. Ekip Visual Studio’da sadece kod tamamlatmaya abanmıştı, ama asıl darboğaz kod yazmak değildi; mevcut servisin davranışını çözmekti. Chat’i devreye alınca tablo değişti. Bir anda “bu sınıf ne yapıyor?” sorusuna cevap geldi ve ekip ilk refaktörü çok daha güvenli yaptı. Bence bu doğru yönde atılmış bir adım,. Hâlâ eksik olan şey şu: İnsanların Copilot’u sadece hız aracı sanmaktan vazgeçmesi lazım.
Önce görev, sonra araç
Lafı gevelemeden söyleyeyim: Copilot kullanırken en iyi sonuç genelde “hangi özelliği deneyeyim?” diye sormakla gelmiyor. “Bu işin hangi kısmını devredebilirim?” diye sormak daha iyi çalışıyor (bizzat test ettim). Bu bakış açısı küçük ekiplerde de işe yarıyor, enterprise yapılarda da. Küçük ekipseniz tek başınıza hem analiz hem yazım hem test yapıyorsunuz; büyük kurumsal yapılardaysa roller ayrılıyor. Bağlam kaybı artıyor.
İşte tam da bu noktada devreye giriyor.
Bunu yaşayan biri olarak söyleyeyim, Mesela startup tarafında çalışan biri için inline completion bayağı iş görüyor; çünkü hızlı teslimat baskısı var ve her dakika değerli. Ama kurumsalda çoğu zaman sorun hız değil, güven. O yüzden chat ile açıklama almak, plan çıkarmak ve kontrollü ilerlemek daha mantıklı oluyor. Hani bazen kodu değil de niyeti anlaman gerekir ya… işte Copilot burada fena değil.
İnanın, Ben bunu ilk kez 2019’da kendi lab ortamımda denediğimde fark etmiştim. Bir Azure App Service üstünde çalışan.NET API vardı; ufak görünüyordu ama içeride dependency zinciri uzundu. Sadece otomatik tamamlama ile ilerleyince gereksiz kod ürettim ve geri dönüp temizlemek zorunda kaldım. Sonra chat ile önce servis davranışını analiz ettirdim; fark geceyle gündüz gibiydi.
İşte tam da bu noktada devreye giriyor.
Inline completion: Küçük işler, gerçek kazanç
Inline completion’ı küçümsememek lazım. Evet, gösterişli değil. Ama günün sonunda DTO dolduruyorsan, LINQ ifadesi kuruyorsan ya da Minimal API endpoint iskeleti çıkarıyorsan bayağı zaman kazandırıyor. Mesela tekrar eden C# işleri için işini görüyor (bizzat test ettim)
Şunu net söyleyeyim: Inline öneriler mucize değil. Bazen fazla özgüvenli davranıp yanlış pattern önerebiliyorlar… hatta can sıkıcı derecede emin konuşuyorlar! O yüzden benim tavsiyem şu: kısa parçalar için kullanın, uzun. Kritik mantığı körlemesine kabul etmeyin.
Nerede iyi çalışıyor?
Şunu fark ettim: Testlerin happy-path kısmı, basit mapping işlemleri, küçük validation blokları ve örnek controller action’ları için oldukça rahat kullanılıyor. Hele bir de de Visual Studio içinde çalışırken bağlamın elinin altında olması avantaj sağlıyor.
Araya gireyim: Geçen Mart ayında Ankara’daki bir e-ticaret projesinde bunu gördüm. Takım yeni fiyatlama kuralları ekliyordu ve neredeyse her PR’da aynı tür boilerplate dönüyordu. Inline completion sayesinde bazı tekrarlar ciddi azaldı. Biz yine de kritik kural setlerini elle gözden geçirdik çünkü maliyet hesabı yapan yerlerde hata affetmiyor. Daha fazla bilgi için SharePoint Framework 1.23 ve Ötesi: Asıl Mesaj Ne? yazımıza bakabilirsiniz. Python AI Uygulamalarında Azure App Service: Hız Kazandıran Sessiz Değişim yazımızda bu konuya da değinmiştik.
Nerede zayıf kalıyor?
Karmaşık business logic varsa inline öneri seni yanlış yola sokabiliyor. Hele ki domain dili oturmamış projelerde… orada “tamamla” butonu bazen fazla cesur davranıyor diyebilirim.
Ayrıca performans veya güvenlik hassasiyeti olan bölümlerde otomatik öneriyi doğrudan almak bana göre riskli. Bu konuda %100 emin değilim. Sanırım en iyi kullanım şekli şu: öneriyi al, sonra kendi kafandaki tasarımla karşılaştır.
Chat neden asıl farkı yaratıyor?
Bence Copilot’un gerçek değeri chat tarafında başlıyor. Çünkü burada mesele satır satır kod üretmek değil; açıklama almak, karşılaştırma yapmak ve karar vermek oluyor. Legacy ASP.NET Core servislerinde özellikle çok faydalı buluyorum bunu.
Bir kere Eskişehir’deki bir üretim firmasında beş bağımlılığı olan uzun bir service class gördük. Kod kötüydü demeyeyim de… biraz yorucuydu işte! Chat’e “bu servis ne yapıyor?” dedik; dependency’leri ayırdı, business logic ile altyapı concern’lerini ayırdı ve bize güvenli ilk refaktör adımını gösterdi.
Copilot’a doğrudan “kodu yeniden yaz” demek yerine önce “bunu bana anlat” demek çoğu zaman daha doğru çıkıyor.
Test üretirken neden işe yarıyor?
.NET dünyasında test konusu hep biraz acılıdır… herkes önemini bilir ama kimse boş vakitte oturup edge case kovalamak istemez. Tam burada chat çok yardımcı oluyor.
Küçük bir detay: 2024 Kasım ayında İzmir’de bir SaaS ekibiyle çalışırken pricing method üzerinde bunu kullandık: discount boundary’leri, null input durumu. Cap edilen toplam senaryosu için testler oluşturduk. İlk testi biz yazdık; geri kalan kenar durumlarını chat destekledi. Daha fazla bilgi için Claude Opus 4.8 GitHub Copilot’a Geldi: Peki Gerçekte Ne Değişiyor? yazımıza bakabilirsiniz.
| Kullanım Alanı | Daha Uygun Surfaces | Neden? |
|---|---|---|
| Sade C# doldurma işleri | Inline completion | Hızlı öneri verir |
| Kodun ne yaptığını anlama | Chat | Açıklama ve yorum sağlar |
| Sınırlı kapsamlı görevler | Ajan/CLI akışı | Birkaç adımı sırayla koşturabilir |
Ajan tarzı akışlar: Kontrollü güç
Ajan dediğimiz şey kulağa havalı geliyor ama sihir değil. Daha çok belirlenmiş sınırlar içinde işi sıraya koyan bir yardımcı gibi düşünün (mutfakta tarif okuyan usta çırak misali)..NET tarafında bu yaklaşım özellikle scoped execution gereken işlerde anlam kazanıyor.
E tabi burada dikkat edilmesi gereken nokta şu: Ajan sana rahatlık verir ama kontrol hissini bayağı bırakmamalısın.
Ben açıkçası büyük enterprise yapılarda bu modeli çok severken küçük ekiplerde bazen fazla ağır buluyorum; çünkü setup maliyeti ile kazanılan zaman arasında ince bir çizgi var.
// Örnek düşünce akışı
1) Kodu incele
2) Test stratejisini çıkar
3) Riskli alanları listele
4) Küçük refaktörü uygula
5) Sonucu doğrula
Bunu ilk denediğimde — yanlış hatırlamıyorsam Şubat 2025’te — Visual Studio Code tarafında dotnet-test skill ile ilerledik ve güzel sonuç aldık ama ilk turda test ortamının eksik bağımlılıkları yüzünden hata aldık: xUnit paket sürümü ile proje dosyası uyuşmuyordu. Çözüm basitti aslında; sürümü hizaladık ve tekrar koşturduk… Daha fazla bilgi için TypeScript 7.0 Beta: Hız Değil, Asıl Mesaj Daha Büyük yazımıza bakabilirsiniz. Daha fazla bilgi için DSC v3.2.0 ile Konfigürasyon Kontrolü Daha Olgun Hale Geliyor yazımıza bakabilirsiniz.
Küçük ekip mi büyük kurum mu?
Küçük ekipteyseniz mümkün olduğunca sade kalın derim. Bir developer + bir reviewer + Copilot üçlüsü yeterli olabilir. Büyük kurumdaysanız governance şarttır; yoksa ajanların ürettiği rahatlık sonradan teknik borca dönüşür. Ben Finansbank benzeri sıkı kontrol isteyen ortamlarda bunu net gördüm. Aynı araç iki farklı yerde bambaşka sonuç veriyor. Neyse uzatmayayım:
- Küçük ekip: hızlı prototip + sık manuel kontrol
- Büyük kurum: policy + logging + review zorunlu olsun
- Sensitif veri varsa prompt içine düz veri koymayın
Türkiye’de benimsenme nasıl farklılaşıyor?
Bunu Türkiye’deki şirketler açısından değerlendirirsek tablo biraz karışık.
Kurumsal müşterilerimde gördüğüm kadarıyla bizde insanlar yeni AI araçlarını hemen merak ediyor ama prod’a sokarken frene basıyor.
Haklılar da.
Çünkü regülasyon baskısı yüksek olan sektörlerde yalnızca hız yetmiyor; izlenebilirlik istiyorsunuz.
Mesela bankacılık ve telekom tarafında Copilot’u kişisel üretkenlik aracı olarak başlatıp sonra kontrollü şekilde yaymak daha sağlıklı oluyor.
Bir arkadaşımın Bursa’daki orta ölçekli firmasına baktığımda işe tersini gördüm:
küçük takım oldukları için karar alma hızı yüksekmiş ve Copilot’u birkaç hafta içinde günlük rutine katmışlar.
Ama orada da başka sorun çıktı…
Prompt disiplini yoksa herkes farklı dil konuşuyor gibi oluyor.”
Maliyet gözüyle bakınca ne değişiyor?
Copilot lisansı TL bazında düşünülünce bazı yöneticilere pahalı görünebilir.
Ama ben masanın diğer tarafını da görüyorum:
bir developer’ın günde yarım saat kazanması bile ay sonunda ciddi fark yaratabiliyor.
Yine de bütçe dar işe büyük çoğunluk ekibe aynı anda açmak yerine pilot grupla başlamayı tercih ederim.
Önce senior geliştiricilerden oluşan küçük grupta deneyin;
sonra ölçün;
sonra genişletin.”
Dengeyi kaçırmadan kullanmak için pratik rehber
Laf arasında söyleyeyim, her şeyi Copilot’a bırakmak beni hiç ikna etmiyor.
İyi kullanım modeli insanın kendi muhakemesini merkeze koyuyor.
Ben olsam şöyle başlarım:
önce mevcut projedeki stili öğrenirim,
sonra chat ile açıklama isterim,
en son inline veya ajan desteğiyle işi tamamlarım.
- Meseleyi tanımla: Ne yapacağın belli olsun. — bunu es geçmeyin
- Kodu oku: Önce mevcut davranışı anla.
- Küçük parça seç: Tek seferde devasa refaktör yapma.
- Cevabı doğrula: Test olmadan kabul etme.
Ankara’da geçen ay yaptığımız bir modernizasyon çalışmasında bu yöntem baya işe yaradı.Controller içindeki orchestration mantığını servise taşıdık,HTTP kontratına dokunmadık,ve regresyon riskini düşük tuttuk.Aynısını körlemesine otomatik yeniden yazdırmaya kalksak muhtemelen iki kat zaman giderdi.
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.
3 comments