C++’ta Copilot’u Konuşturmak: VS Code İçin Akıllı İpuçları
Copilot bazen neden “iyi ama eksik” kalıyor?
Bakın şimdi, C++ yazarken Copilot’ta en çok hissettiğim şey şu: araç baya iş görüyor, hatta çoğu zaman insanı hızlandırıyor, ama bağlam yoksa biraz kör gidiyor. C++. Öyle bir dil ki, tek dosyaya bakıp akıl yürütmek yetmeyebiliyor; include zinciri, build ayarları, sembol ilişkileri, makro dünyası… Sız ne dersiniz? işin içine bunlar girince modelin önünde ne kadar sağlam veri varsa sonuç da o kadar toparlıyor.
Kısa bir not düşeyim buraya.
Şöyle ki, Bu yüzden custom instructions bana göre sadece üretkenlik konusu değil; kalite konusu da aynı zamanda güven konusu oluyor. Hele bir de büyük legacy codebase’lerde insan eliyle her bağıntıyı takip etmek zorlaşıyor. Copilot’a doğru araçlarla bakmasını söylerseniz yük biraz hafifliyor.
| Kullanım Senaryosu | Küçük Ekip | Büyük Kurumsal Yapı |
|---|---|---|
| Hızlı prototip | Evet, direkt fayda sağlar | Evet ama standartlaştırma şart |
| Legacy C++ kod tabanı | Sınırlı iyileştirme | Bayağı belirgin fayda |
| CMake yoğun proje | Kolay kazanım | Daha yüksek doğruluk |
| Kod standardı koruma | Bazen yeterli olur | Neredeyse şart hâle gelir |
Bunu Türkiye’de nasıl okurum?
Bunu Türkiye’deki şirketler açısından değerlendirirsek durum biraz tanıdık aslında: ekipler genelde yeni araca hevesli başlıyor ama mevcut repo düzeni yeterince disiplinli değilse sonuç karışıyor (ki bu çoğu kişinin gözünden kaçıyor). Bilhassa de outsource çalışan ekiplerde veya uzun yıllardır yaşayan kurumsal ürünlerde bilgi tek kişinin kafasında kalabiliyor (maalesef). Custom instructions tek başına çözüm değil ama o bilgiyi yazılı hâle getirmenin güzel yolu olabilir.
İnanın, Bir de maliyet kısmı var… Azure maliyetini TL bazında düşündüğünüzde kimse boşa giden geliştirme saatini sevmiyor. Eğer bir özellik geliştiricinin her gün 10 dakika zaman kazandırıyorsa bu ufak görünür; ama 20 kişilik ekibe vurduğunuzda ay sonunda karşılığı hissedilir hâle geliyor. Özel komutların getirdiği kazanç tam da burada ortaya çıkıyor: gereksiz geri dönüşleri azaltmak.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
E tabi bütçe kısıtlıysa yaklaşımı sade tutmak lazım. Her repoya onlarca instruction koymayın; önce gerçekten sorun yaşadığınız alanları hedefleyin: symbol context mi eksik, build config mi karışık, yoksa stil mi dağılıyor? Önce dar alan seçin, sonra genişletin.
Nereden başlamalı?
- CMake ve compile database tarafını temizleyin.
- .github/instructions altına sadece gerekli C++ yönergelerini koyun.
- Pilotu küçük bir modülde deneyin. (bence en önemlisi)
- Önerilerin doğruluğunu ölçün: yanlış pozitif kaç tane?
- Sonra tüm repoya yayın. — ciddi fark yaratıyor
Bence bu yaklaşımın en sağlam yanı hız değil; tutarlılık sağlıyor olması.
Bir kez doğru kurarsanız Copilot her seferinde biraz daha az sallamaya başlıyor.
Ama hâlâ ham tarafları var — özellikle çok eski projelerde.
Kendi gözümden artılar ve eksiler
Kendi deneyimimden konuşuyorum, Açık konuşayım, sevdiğim taraflardan biri bunun repo içi yönetilebilir olması. DevOps kafa yapısına yakın dürüyor. Her geliştirici kendi kafasına göre davranmıyor, takım düzeyinde standardizasyon mümkün oluyor — dürüst olayım, biraz hayal kırıklığı —. AZ-305’e hazırlanırken hep şunu düşünürdüm: mimariyi toparlayan şey çoğu zaman büyük yenilik değil, küçük kararların tekrar edilebilir olmasıdır. Burada da aynı mantık var.
Neler iyi çalışıyor?
Daha doğru sembol kullanımı güzel bir kazanım sağlıyor mu? Sağlıyor.
CMake yapılarına duyarlılık önemli mi? Evet.
Legacy projelerde rehberlik ediyor mu? Çoğu durumda ediyor.
Yine de kusursuz diyemem. Mesela bazı senaryolarda instruction metni fazla genel yazılırsa etkisi düşüyor; çok spesifik yazarsanız da bakım yükü artıyor — işte ikilem burada başlıyor! Ben ilk test ettiğimde özellikle macro-heavy projede beklediğim kadar pürüzsüz sonuç alamadım ve orada çözüm instruction’dan çok proje temizliği öldü.
Neye dikkat etmeli?
Copilot’u sihirbaz sanmayın.
O hâlâ bağlama bağımlı çalışıyor.
Yanlış yapılandırılmış repo varsa asistanın yapacağı şey de sınırlı kalır.
Kısacası araç iyi olabilir ama temizlik sizden gelir (yanlış duymadınız)
- Instruction metnini kısa tutun ama net tutun.
- Tümüyle genel cümlelerden kaçının.
- Kod standartlarını repo içinde görünür hâle getirin.
- CMake ve symbol context’i birlikte düşünün.
- Kötü sonucu ölçmeden yaygınlaştırmayın. — bunu es geçmeyin
Küçük ekip mi büyük kurum mu?
Küçük ekipseniz bence olay daha pragmatik ilerlemeli: birkaç can alıcı klasörde başlayıp faydaya bakarsınız ve hemen hissedersiniz ya da etmezsiniz… Büyük kurumdaysanız iş biraz farklı; governance gerekir, çünkü bugün eklenen instruction yarın başka takımı etkileyebilir (özellikle ortak monorepo varsa).
Büyük yapılarda ben genelde pilot–ölçüm–yaygınlaştırma sırasını öneriyorum.
Küçük ekiplerde işe “hemen her yere yayalım” dürtüsü güçlü oluyor.
Ama durun bir dakika — bazen hızlı olmak yerine düzgün temellendirmek daha ucuz çıkıyor.
Bilhassa regülasyonlu sektörlerde bunu defalarca gördüm:
bir gün fazla hız size iki hafta geri dönüş olarak dönebiliyor.
Acı ama gerçek!
Sizin için pratik yol haritası
Vallahi, Lafı gevelemeden söyleyeyim: eğer bu özelliği denemek istiyorsanız önce mevcut CMake yapınızı gözden geçirin, sonra instruction dosyasını ekleyin ve tek bir modül üzerinde test edin. Hemen tüm organizasyona açmayın (ki bu çoğu kişinin gözünden kaçıyor). Önce küçük başlayıp veri toplayın; hangi tip önerilerin iyileştiğine bakın.
Neyse uzatmayayım… Ben olsam şu sırayla giderdim:
- C/C++ DevTools extension’ını kurarım.
- .github/instructions klasörünü hazırlarım.
- CMake entegrasyonunu kontrol ederim.
- Dört-beş gerçek geliştirme senaryosunda denerim.
- Ekrandan gelen çıktıyı ekip içi notlara işlerim. — bunu es geçmeyin
Sıkça Sorulan Sorular
Copilot için custom instructions ne işe yarar?
Dürüst olmak gerekirse, Aslında Copilot’a hangi sinyallere daha çok güveneceğini söylüyorlar. C++ tarafında bu sayede symbol context ve build bilgisi çok daha anlamlı kullanılabiliyor. Yanı sonuç olarak öneriler çok daha işabetli geliyor.
Bunu her repoda kullanmak zorunda mıyım?
Bak şimdi, Hayır, zorunda değilsiniz (bizzat test ettim). Bence en iyi yöntem kritik repolarda pilotlamak. Bilhassa büyük organizasyonlarda önce birkaç projede deneyip görmek çok daha sağlıklı — açıkçası hepsine birden uygulamak biraz kaotik olabiliyor (buna dikkat edin)
Sadece VS Code için mi geçerli?
Makalede anlatılan kullanım VS Code odaklı, hani özellikle GitHub Copilot ve C/C++ DevTools ile birlikte düşünülüyor. Repo seviyesindeki instructions mantığı işe genel olarak workflow odaklı çalışıyor.
CMake olmadan fayda eder mi?
Bazı faydalar görürsünüz ama asıl etki CMake awareness ile geliyor. Tecrübeme göre projenin nasıl derlendiğini aracın bilmesi şart. Build bilgisi olmayan AI biraz tahmin yürütüyor, mesela yanlış header yolları önerebiliyor (bizzat test ettim)
Kaynaklar ve İleri Okuma
Orijinal Microsoft C++ Team Blog yazısı
GitHub Copilot Custom Instructions belgeleri
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.
4 comments