Küçük bir detay: Açık konuşayım: GitHub Copilot, JavaScript ya da Python tarafında bazen gerçekten takım arkadaşı gibi hissettiriyor. Ama C++’a gelince işler bir anda sertleşiyor. Header dosyaları, template metaprogramming, makro tuzakları, CMake’in o meşhur build configuration karmaşası… bunların hepsi LLM’ler için baya mayın tarlası. Geçen ay bir müşteride eski bir C++ kod tabanını modernize etmeye uğraşırken bunu iliklerine kadar gördük; Copilot’un önerdiği şeylerin yarısı projedeki gerçek sembollerle alakasızdı. std::vector öneriyordu ama biz custom bir allocator kullanıyorduk mesela.
İşte tam burada Microsoft’un Şubat’ta duyurduğu C++ symbol context. CMake awareness güncellemesi benim — ki bu tartışılır — için önemliydi (şaşırtıcı ama gerçek). Şimdi bunun üstüne, VS Code için yeni bir custom instructions seti de geldi. Yani Copilot’a “kardeşim, C++ kodu yazarken şu language service tool’larına bak, gözünü kapatıp tahmin yürütme” diyebiliyoruz artık. Neyse uzatmayalım; bu yazıda neyin nasıl kurulduğuna, gerçekte ne işe yaradığına ve Türkiye’deki ekiplere ne kazandırdığına gireceğim.
Custom Instructions Olayı Aslında Nedir?
Bak şimdi, Copilot bağlamı iki yerden topluyor: bir, açık olan dosyalardan; iki, repository içinde yaptığı o meşhur “kod araması” ile. İkinci kısım özellikle büyük projelerde biraz kumar gibi oluyor. Çünkü Copilot bazen yanlış dosyaya bakıyor, bazen de ilgisiz bir header’ı referans alıyor; — bence çok yerinde bir karar —. Siz ne dersiniz? Işin aslı pek güven vermiyor.
Bir dakika — bununla bitmedi.
Şöyle söyleyeyim, Custom instructions işe Copilot’a “şu kuralları her zaman uygula” demenin yolu. Repository’nın köküne küçük bir markdown dosyası koyuyorsun — Copilot her istemde önce ona bakıyor, sonra cevabını ona göre şekillendiriyor. C++ için hazırlanan dosya da kabaca şunu söylüyor: “Geleneksel grep tarzı kod aramasına güvenme. Onun yerine C++ language service’in sembol bilgisini ve CMake build context’ını kullan.”
Disket sürücü zamanından beri yazılım geliştiren biri olarak söyleyeyim; kağıt üstünde basit duran bu yaklaşım pratikte baya iş görüyor. Çünkü C++ language service zaten IntelliSense için arka planda sembol grafiğini çıkarıyor. Copilot’un da aynı kaynağa bağlanması… mantıklı geliyor, değil mi? Evet.
Kurulum: Aslında Çok Basit
Vallahi, İşin teknik tarafı şaşırtıcı derecede sade. awesome-copilot deposunda topluluk tarafından maintain edilen bir koleksiyon var; orada cpp-language-service-tools.instructions.md diye bir dosya bulacaksınız. Bu dosyayı alıp kendi repository’nizin köküne şu yola atıyorsunuz:
your-repo/
├──.github/
│ └── instructions/
│ └── cpp-language-service-tools.instructions.md
├── src/
├── CMakeLists.txt
└──...Bitti. Yani gerçekten bu kadar. VS Code’da Copilot extension’ı bu dosyayı otomatik olarak fark ediyor ve her prompt’ta bağlama dahil ediyor. Bazı CI/CD pipeline işleri bundan daha uğraştırıcı olmuştu, açık konuşayım.
applyTo alanını kullanabilirsiniz. Yoksa TypeScript yazarken Copilot kafası karışabiliyor — denedim, biliyorum.
İlk Hata: Benim Başıma Gelen
İlk denediğimde tabi yine ufak bir çamura battım. Dosyayı .vscode/instructions/ altına koymuştum — yanlışmış. Doğru yer .github/instructions/. Yarım saat boyunca “neden çalışmıyor” diye uğraştım. Eğer Copilot output panel’ine bakıp “instructions loaded” satırını görmüyorsanız, büyük ihtimalle yol yanlıştır. Çözüm basit: dosyayı doğru klasöre taşıyın ve VS Code’u yeniden başlatın (ben de ilk duyduğumda şaşırmıştım)
Çok konuştum, örnekle göstereyim.
Peki Gerçekten Ne Fark Yaratıyor?
Şimdi en kritik kısma geldik. Custom instructions’ı eklediğinizde Copilot, geleneksel kod arama yerine language service tool’larına yöneliyor. Bu somut olarak ne demek? Üç senaryoda anlatayım:
Senaryo 1 — Refactoring: Bir sınıfın metodunu yeniden adlandırmak istiyorsunuz diyelim. Eski Copilot dosyaları tarayıp tahmin yürütüyordu. Yeni yaklaşımda sembol tablosuna bakıp pek çok referansları daha net görüyor; override edilmiş metodlar, template instantiation’lar, friend declaration’lar… hepsini yakalamaya çalışıyor.
Senaryo 2 — Header karmaşası: #include hangisini gerektiriyor sorusu var ya, işte orada eskiden rastgele header önerileri çıkabiliyordu. Şimdi language service’in build graph’ından gerçekten hangi translation unit’in neyi gördüğünü çekmeye çalışıyor. MSVC’de SPGO Devri: Production’dan PGO Kalitesi yazımızda bu konuya da değinmiştik.
Senaryo 3 — CMake bilinci: Projede birden fazla target varsa (Debug, Release, farklı platform varyantları), Copilot artık hangi target için kod yazdığınızı daha iyi anlayabiliyor gibi davranıyor. Conditional compilation çok olan projelerde bu ciddi rahatlık sağlıyor. Bu konuyla ilgili npm Staged Publishing GA: Tedarik Zinciri Artık Daha Güvenli yazımıza da göz atmanızı tavsiye ederim.
Logosoft’ta bir savunma sanayi müşterimizde, 800K satırlık bir C++ kod tabanında bunu test ettik. Refactoring önerilerinin doğruluk oranı %40’lardan %75’lere çıktı. Mükemmel mi? Hayır. Ama “ben Copilot’a güvenmiyorum” diyen senior developer’ların yüzü ilk defa güldü.
Hangi Tool’lar Devreye Giriyor?
Ne yalan söyleyeyim, Konu biraz teknikleşiyor. Dağıtmadan gidelim: Custom instructions, Copilot’a şu tool’ları öncelikli kullanmasını söylüyor.
| Tool | Ne işe yarıyor? | Eskiden ne yapılıyordu? |
|---|---|---|
| Symbol lookup | Sınıf, fonksiyon ve makro tanımlarını bulma | Grep tarzı metin arama |
| Reference finding | Bir sembolün tüm kullanım yerleri | Dosya bazlı tahmin |
| Build configuration | Aktif CMake target ve compile flag’leri | Bilinmiyordu, varsayım yapılıyordu |
| Include graph | Translation unit’in gördüğü header ağacı | Sadece açık dosyalar görülüyordu |
| Type information | auto, template deduction ve tür çıkarımı |
Baya sık yanlış tahmin ediliyordu |
Neyse, tablo tamam ama mesele sadece tablo değil; esas fark bu araçların birlikte çalışmasında çıkıyor.
Ve işler burada ilginçleşiyor. Cosmos Conf 2026: AI Çağında Veritabanı Nereye Gidiyor? yazımızda bu konuya da değinmiştik.
Türkiye’deki Ekipler İçin Pratik Değerlendirme
Vallahi, Lafı buradan biraz yerel tarafa çekeyim. Türkiye’de C++ ile ciddi iş yapan üç ana sektör var gibi duruyor: savunma sanayi, oyun geliştirme ve gömülü sistemler (otomotiv, beyaz eşya). Her birinin Copilot’tan beklentisi farklı oluyor.
Savunma sanayi tarafı, fena hâlde geniş legacy kod tabanlarıyla uğraşıyor çoğu zaman. Burada Copilot’un en büyük (söylemesi ayıp) katkısı eski koda dokunurken sembol grafiğini doğru görmesi olurdu diye düşünüyorum; yeni custom instructions tam buraya oturuyor gibi duruyor. Ama küçük bir not düşeyim: Bu sektörde air-gapped (internetten izole) ortamlar yaygın olduğu için Copilot oralarda zaten çalışmıyor olabilir. O ekipler için GitHub Copilot Enterprise’ın self-hosted runner senaryolarına bakmak gerekiyor; o da ayrı mevzu. Azure NetApp Files EDA İçin: Bulutta Çip Tasarımı Devri yazımızda bu konuya da değinmiştik.
Oyun stüdyoları tarafında işe Unreal Engine ile çalışan ekipler bu özellikten ciddi fayda görebilir diye düşünüyorum.
UE’nın o devasa header zinciri eskiden Copilot’u baya zorluyordu; hatta bazen çıldırttığı bile ölüyordu desek yeridir.
Motorun Ötesi: Oyun Yapımında 10 Açık Kaynak Cevher‘de de bahsetmiştim — Türkiye’de oyun stüdyoları araç-gereç tarafına yeni yeni yatırım yapıyor ve bu tıp ufak ama etkili kazanımlar boş değil.
İşte tam da bu noktada devreye giriyor.
Gömülü sistem tarafı
burası biraz daha karışık. Daha fazla bilgi için NL2SQL Gerçekten İşe Yarıyor mu? SQL MCP Server Notları yazımıza bakabilirsiniz.
Yani, Cünkü oradaki C++ genelde C++14 ya da C++17 standardında oluyor; hatta bazen freestanding implementation görüyorsunuz.
>Custom instructions bu senaryolarda da çalışıyor ama compiler-specific intrinsics konusunda hâlâ zayıf kalabiliyor.
Garip gelecek ama, Aklınızda bulunsun.
Evet?
- Küçük ekip (1-5 developer, <50K satır kod):Kulaktan kulağa hoş geliyor ama custom instructions burada hayatı değil gibi duruyor; çünkü zaten herkes kodun tamamına yakınını biliyor.
Yine de eklemenizi öneririm.
Beş dakikalık iş sonuçta ve en azından öneri kalitesi artıyor. - Anasını satayım orta ölçek (10-30 developer, 100K-500K satır):Burada fark daha belirgin oluyor.
Onboarding süresi düşüyor.
Yeni gelen developer Copilot’a soru sorduğunda daha isabetli cevap alma ihtimali yükseliyor. - Koskoca enterprise (50+ developer, milyon satır+):Burası bence asıl alan.
Hatta custom instructions’ı kendi domain’inize göre genişletmek (coding standard’larınız, naming convention’larınız) ciddi fark yaratabiliyor.
Ufak bir ayar gibi görünse de etkisi büyüyor.
Maliyet Tarafı
Bunu da pas geçmeyeyim: Copilot Business veya Enterprise lisansları aylık kişi başı yaklaşık 19-39 USD bandında geziyor. TL bazında orta ölçekli bir ekipte yıllık birkaç yüz bin lira gibi maliyet çıkabiliyor; kaba hesapla can sıkabiliyor yani.
Ama custom instructions’ın bu maliyeti haklı çıkarma oranını artırdığını söylemek mümkün gibi duruyor.
Tek başına lisans almak yetmez tabii; ekibe doğru kullanım eğitimi de lazım.
Yoksa lisans alırsın da herkes “tab tab tab” basmaktan ileri gitmez (inanın bana)
Peki İlk Adım Olarak Ne Yapmalısınız?
Kafanız karışmasın diye pratik bir liste bırakayım:
- . VS Code’da en güncel C/C++ DevTools ve GitHub Copilot@extensionlarını yükleyin.
- .
@awesome-copilot@reposundan ilgili instructions dosyasını indirin. - . Dosyayı kendi repository’nizde
.github/instructions/@altına atın. - . VS Code Output panel’de “GitHub Copilot” kanalını açın — instructions’ın yüklendiğini doğrulayın.
- . Küçük bir test yapın:Copilot Chat’e “Bu projedeki
HelloLogger@sınıfının tüm türevlerini listele” gibi sembol odaklı bir soru sorun.Eskiyle karşılaştırın. (bence en önemlisi) - . Ekip içinde geri bildirim toplayın.İşe yaramayan kısımlar varsa GitHub Issues’a yazın — bu instructions community-driven, gerçekten okuyup düzeltiyorlar.
Sıkça Sorulan Sorular
Bu custom instructions sadece VS Code’da mı çalışıyor?
Şu an için evet, bu C++ instructions seti aslında VS Code’daki Copilot için optimize edilmiş. Visual Studio’nün da kendi içinde benzer mekanizmaları var — Agent Skills gibi şeyler — ama orada farklı işliyor. JetBrains tarafında işe henüz böyle bir entegrasyon yok maalesef.
GitHub Copilot Free planında çalışıyor mu?
Dürüst olmak gerekirse, Evet, custom instructions özelliği Free dahil tüm planlarda çalışıyor. Ama açıkçası, Free planın istek limitleri var ve büyük projelerde hızla o limite takılıyorsunuz. Ciddi bir C++ ekibiyseniz bence Business veya Enterprise’a geçmekte fayda var.
Mevcut projemde performansı düşürür mü?
Hayır. Instructions dosyası aslında prompt’a eklenen birkaç satır metin, yani performans etkisi yok denecek kadar az (ciddiyim). Hatta tecrübeme göre tam tersi oluyor — Copilot yanlış cevap verip sızı geri dönüp düzeltme yapmaktan kurtardığı için net bir performans artışı yaşıyorsunuz.
Kendi instructions dosyamı yazabilir mıyım?
Hani, Kesinlikle, hem de öneririm. awesome-copilot repository’sindeki dosyayı bir başlangıç noktası olarak alın, kendi coding standard’larınızı, naming convention’larınızı, kullanmadığınız library’leri ekleyin. Sonra ekip içinde paylaşıp PR ile geliştirin — mesela bizim Logosoft’taki birkaç ekipte hani tam böyle yapıyoruz.
CMake kullanmıyorum, MSBuild ile çalışıyorum. Yine işe yarar mı?
Symbol context kısmı yarar, evet. Ama build configuration awareness kısmı şu an ağırlıklı olarak CMake odaklı (ciddiyim). MSBuild tarafında yanlış bilgi almamak için Visual Studio’nün kendi Copilot entegrasyonunu kullanmak bence daha mantıklı bir seçenek olabilir.
Kaynaklar ve İleri Okuma
Yani,
C++ Team Blog: Giving Copilot more C++ context using custom instructions in VS Code
GitHub: awesome-copilot repository
cpp-language-service-tools.instructions.md (doğrudan dosya)
vscode-cpptools Issues — geri bildirim için
vscode-cmake-tools Issues — CMake tarafı için
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.
