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.
Geçen sene Kasım ayında bir müşteride — Ankara’da çalışan orta ölçekli bir ekipti — eski bir C++ kod tabanında Copilot önerilerinin sık sık “yakın ama tam değil” kaldığını gördüm. Kod doğru yola gidiyor gibi görünüyordu ama kullanılan sınıfın gerçek yaşam döngüsü başka yerde tanımlıydı. Yanı hani kağıt üstünde fena değil, pratikte işe biraz bekle-gör durumu. İşte custom instructions tam burada devreye giriyor.
Aslında — hayır dur, daha doğrusu dur, şöyle anlatayım: Bu konu sadece “daha iyi autocomplete” meselesi değil. Daha çok Copilot’un hangi tür kanıtla karar vereceğini yönlendirmek gibi düşünün. Bir dedektife ipucu veriyorsunuz; rastgele sokakta dolaşmasın, doğrudan doğru raflara baksın istiyorsunuz. İlginç, değil mi? C++ tarafında da bunu yapınca öneriler daha tutarlı hâle geliyor.
Custom instructions neyi değiştiriyor?
Microsoft’un son yaklaşımı bana göre güzel bir yönde atılmış adım. Çünkü Copilot’u sadece kod arama mantığına bırakmak yerine, C++ language service tools ile daha yakın çalıştırıyorsunuz. Yanı model, dosya içinde kelime eşleştirmekten ziyade sembol ilişkilerine ve build konfigürasyonuna daha çok yaslanıyor. Küçük gibi duran bu fark var ya, büyük projelerde baya hissediliyor.
Bir dakika — bununla bitmedi.
Garip gelecek ama, 2019’da kendi lab ortamımda benzer bir şeyi klasik IDE eklentileriyle denemiştim. O zamanlar toolchain’in verdiği bilgi ile editörün gördüğü bilgi birbirine pek uymuyordu ve öneriler sürekli yarım kalıyordu. Şimdi mesele biraz daha olgunlaşmış durumda. Özellikle.github/instructions klasörüyle repo seviyesinde davranışı sabitlemek bence iş görüyor.
Şunu söyleyeyim, Bir de şu var: kurumsal ekiplerde herkesin Copilot’tan beklediği şey aynı olmuyor. Küçük startup’ta hızlı prototip için yeterli olan öneri tipiyle enterprise ortamındaki beklenti aynı değil. Enterprise tarafında hata toleransı düşük; kod stili, mevcut mimarı ve build uyumu daha kritik. Startup tarafında işe hız ön planda… Tahmin eder mısınız? ama orada da yanlış yönlendiren akıllı asistan kimse istemez.
Nasıl açılıyor?
Peki, garip gelecek ama, İşin pratik tarafı aslında çok basit görünüyor. Reponun köküne.github/instructions altında ilgili instruction dosyasını koyuyorsunuz ve GitHub Copilot bunu otomatik alıyor. Buradaki can alıcı nokta şu: custom instruction dosyasını ekledim öldü demek yetmiyor; repo düzeninizin de buna uygun olması lazım. Yoksa araç var ama data zayıf kalır.
.github/
└── instructions/
└── cpp-language-service-tools.instructions.md
Açık konuşayım, ilk denememde ben bu yapıyı fazla büyülü sandım ve hemen mucize bekledim. Beklediğim kadar değildi. Sonra fark ettim ki asıl fark, instruction metninin yanında projenin build tanımlarının düzgün olmasıyla ortaya çıkıyor. Yanı yarım iyi yapıdan tam verim alamıyorsunuz.
C++ tarafında niye özellikle önemli?
C++ dünyası biraz nazlıdır… Bunu kötü anlamda söylemiyorum; sadece detay sever diyorum. Aynı sınıf farklı derleme seçeneklerinde bambaşka davranabilir, makrolar yüzünden görünürlük değişebilir, include sırası bile hayat kurtarabilir ya da baş ağrıtır. Copilot’un bu karmaşayı anlaması için ham kod taramasından fazlasına ihtiyacı var.
Doğrusu, CMake build awareness burada baya işe yarıyor çünkü proje nasıl derleniyorsa asistanın da önü bilmesi gerekiyor. Aksi hâlde size mantıklı görünen ama gerçek projede patlayan bir öneri gelebiliyor. Ben bunu 2024’ün ilk çeyreğinde İstanbul’daki bir finans projesinde net gördüm: aynı sınıfın iki ayrı target altında farklı compile definition alması yüzünden önerilerden biri direkt yanlış yere gidiyordu.
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder