C++ Kodunu CLI’da Anlamak: Copilot’a Gelen Akıllı Katman
CLI tarafında asıl mesele ne?
C++ ile uğraşan biriyseniz, işin içine template, makro, include zinciri ve derleme konfigürasyonu girince düz metin araması bir yerden sonra yetmiyor (ben de ilk duyduğumda şaşırmıştım). Hatta bazen insanı baya yanlış yola sokuyor (inanın bana). Ben bunu yıllar önce, 2018 sonbaharında Ankara’da bir finans müşterisinde yaşadım; kod tabanı dışarıdan temiz görünüyordu ama grep ile bulduğumuz sınıfın aslında üç farklı varyantı vardı. Birini seçip ilerledik, sonra build patladı. Klasik.
Microsoft’un GitHub Copilot CLI için getirdiği yeni C++ dil sunucusu tam da bu boşluğu dolduruyor. Yanı olay sadece “kodda şu kelime geçiyor mu?” sorusunu sormak değil; sembol nerede tanımlı, kim önü kullanıyor, hangi tipten türemiş, çağrı zinciri nasıl akıyor… işin aslı şu ki bunlar olmadan C++’ta sağlıklı çıkarım yapmak zor (ki bu çoğu kişinin gözünden kaçıyor)
Bu güncelleme bana biraz IntelliSense’in terminale taşınmış hali gibi geldi. Abartmıyorum. Visual Studio’da veya VS Code’da alıştığımız semantik anlayış şimdi CLI tarafına geliyor. Açık konuşayım, bu baya iş görüyor; çünkü komut satırı hâlâ birçok geliştiricinin hızlı deneme alanı.
Neden sadece grep yetmiyor?
Küçük bir detay: C++’ta arama yapmak bazen samanlıkta iğne aramak gibi değil, daha kötü: aynı iğnenin beş kopyası var. Hangisinin doğru olduğunu derleme sistemi belirliyor. Makrolar işi karıştırıyor, overload’lar ayrı dert, template instantiation ayrı dert… Bir de üstüne proje bazlı include yolları eklenince metin tabanlı sonuçlar baya eksik kalıyor (evet, doğru duydunuz) — bence çok yerinde bir karar —
Şunu fark ettim: Benim 2021’de İzmir’de çalıştığım bir üretim projesinde buna benzer bir sorun yaşamıştık. Geliştirici arkadaşımız “class adı burada geçiyor” diye sevindi ama aslında o işim test klasöründe de vardı, örnek kodda da vardı, gerçek implementasyon işe bambaşka bir yerdeydi. Semantik bilgi olmayınca araç size güven veriyor gibi yapıyor ama tam tersine yoruyor. Bu özellik fena değil dememin nedeni de bu.
Yeni C++ Language Server tam burada devreye giriyor ve Copilot CLI’ya sadece kelime eşleşmesi değil, symbol definitions, referanslar ve tip bilgisi veriyor. Böylece araç artık körlemesine tarama yapmıyor; daha akıllı sorular sorabiliyor. Kağıt üstünde süper dürüyor, pratikte göreceğiz artık diyeyim (şaşırtıcı ama gerçek)
{fmt} örneği neden önemli?
Microsoft’un anlattığı senaryoda internal bir LogLevel tipi için özel formatter yazmak isteniyor. Basit görünüyor ama C++ bilenler bilir; basit başlayan şey çoğu zaman inheritance ağacına dönüşür. Burada Copilot’un görevi yalnızca örnek üretmek değil, mevcut formatter türlerini tarayıp hangisinin base class olarak mantıklı olduğunu önermek.
Bence bu kısım önemli çünkü üretken yapay zekâ araçlarının en zayıf olduğu yerlerden biri bağlam seçimi. Doğru sınıfı öneremiyorsa geri kalan (söylemesi ayıp) her şey süs oluyor. Ben AZ-305 sınavına hazırlanırken bile şunu net gördüm: mimarı kararların çoğu “hangi bileşen birbirine gerçekten uyuyor?” sorusuna dayanıyor. Kod tarafında da durum aynı.
Evet, doğru duydunuz.
Dil sunucusu açıkken Copilot workspace symbol search kullanabiliyor, sonra doğrudan definition’a gidiyor ve base formatter’ları toparlıyor. Dil sunucusu kapalıysa iteratif grep başlıyor; yanı — kendi adıma konuşayım — sistem biraz el yordamıyla ilerliyor (ciddiyim). Durun bir dakika — bu küçük fark gibi görünüyor ama büyük repo içinde dakikalar değil saatler kazandırabilir.
| Durum | Dil Sunucusu Var | Dil Sunucusu Yok |
|---|---|---|
| Sembol bulma | Anlam temelli | Düz metin araması |
| Türetilmiş sınıflar | Doğrudan görülebilir | Kısmen bulunur |
| Yanlış sonuç riski | Düşük | Yüksek |
| Büyük repo etkisi | Baya güçlü | Kafa karıştırıcı olabilir |
Kurulum tarafında işin gerçek yüzü
Neler gerekiyor?
Kullanmak için aktif GitHub Copilot aboneliği gerekiyor. Microsoft C++ Language Server şu an preview aşamasında npm paketi olarak geliyor. Windows, Linux ve macOS desteği olması güzel; yanı platform bağımlılığı açısından fena başlamamışlar.
Peki, şunu fark ettim: Ama gel gelelim iş sadece paketi kurmakla bitmiyor — valla güzel iş çıkarmışlar —. Projeniz için bir adet compile_commands.json üretmeniz gerekiyor, ardından da GitHub Copilot CLI ile projeyi doğru şekilde eşleştirmeniz lazım. CMake kullanan ekipler burada nispeten rahat; çünkü hazır skill ile süreç otomatikleşebiliyor.
{
"command": "cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON..",
"note": "compile_commands.json üretmek için tipik başlangıç"
}MSBuild kullananlar ne yapacak?
E tabi herkes CMake kullanmıyor. Bizim sahada hâlâ çok sayıda.vcxproj tabanlı kurumsal uygulama var; özellikle eski bankacılık. Sigorta sistemlerinde bu normaldir. Sız hiç denediniz mi? Microsoft’un sample application sağlaması güzel olmuş ama ben burada biraz temkinliyim: destek yolu var, evet, fakat native entegrasyon henüz gelecekte planlanıyor denmiş durumda. copilot ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.
Ve işler burada ilginçleşiyor. Daha fazla bilgi için Foundry Hosted Agents ile MAF’ı Prod’a Taşımak: Benim Notlarım yazımıza bakabilirsiniz.
Bakın, küçük bir detay: Bunu ilk okuduğumda hafif hayal kırıklığı yaşadım açıkçası. Çünkü enterprise tarafta MSBuild hâlâ çok yaygın. Insanlar “preview tamam da benim proje ne olacak?” diye soruyor haklı olarak. Yanı ürün doğru yönde gidiyor ama bazı ekipler için yol biraz dolambaçlı kalmış. Daha fazla bilgi için Microsoft 365 Copilot Agent Evaluations: Ajan Kalitesi Ölçümü yazımıza bakabilirsiniz.
Küçük ekip mi büyük kurum mu?
Küçük bir startup iseniz hızlı deneyip sonuç almanız kolay olur; birkaç servisli repo varsa compile database oluşturmak bile fazla vakit almaz. Ama enterprise tarafta durum başka: on binlerce satır kod, karmaşık build zincirleri ve güvenlik politikaları derken her yeni aracın onboarding maliyeti oluşuyor. SkiaSharp 4.0 Preview 1: 10 Yıl Sonra Büyük Atılım Geldi yazımızda bu konuya da değinmiştik.
Kısa bir not düşeyim buraya.
Şahsen, Büyük kurumlarda bence ilk adım pilot olmalı: tek bir modül seçin, compile_commands.json üretin, Copilot CLI’yı orada deneyin ve çıkan sonuçların doğruluğunu ölçün (evet, ölçün). Sonra yaygınlaştırın. Körlemesine tüm organizasyona açmak yerine kontrollü gitmek daha mantıklı.
Maliyet ve verimlilik dengesi nasıl okunmalı?
Aylık lisans yetmez mi?
Sadece lisans maliyetine bakmak eksik olur. Asıl maliyet çoğu zaman mühendis saatidir: yanlış arama sonucu boşa giden süreler, hatalı öneriler yüzünden tekrar yapılan incelemeler. Build kırılınca harcanan mesai… Bunları TL bazında düşündüğünüzde tablo değişiyor. vcpkg Nisan 2026: Kilitler, Hız ve Küçük Ama Kritik Dokunuşlar yazımızda bu konuya da değinmiştik.
Ne yalan söyleyeyim, Birkaç müşteri toplantısında bunu net gördüm: “Araç ucuz mu?” sorusundan önce “ekibimin kaç saatini kurtarıyor?” sorusu gelmeli. Çünkü küçük görünse de günlük on dakika tasarruf eden araç yıl sonunda ciddi etki yaratıyor. Mesela kıdemli geliştiricilerin zamanı pahalıdır; onları grep ekranına mahkûm etmek pek akıllıca değil.
Peki hiç eksiği yok mu?
Kendi deneyimimden konuşuyorum, Var tabi ki var. Preview olması zaten bunu söylüyor. Bazı projelerde compile database eksik ya da hatalı olursa araç sizi yarı yolda bırakabilir. Ayrıca semantic data çok güçlü olsa da her şeyi çözmez; runtime davranışı yine başka mesele.
Açık konuşayım, burada beklentiyi doğru ayarlamak lazım. Bu teknoloji sihirli değnek değil; iyi yapılandırılmış projede parlıyor. Dağınık build sisteminde işe önce düzen istiyor. Az önce X dedim. Aslında Y daha doğru olabilir: önce proje hijyenini toparlayın, sonra bu tür akıllı araçlardan maksimum fayda alın.
C++’ta yapay zekâya güvenecekseniz önce bağlam vermelisiniz; bağlam yoksa en zeki model bile tahmin yürütür.
Sahada ben bunu nasıl değerlendiriyorum?
Hani, Kendi açımdan bakınca bu duyuru sadece “CLI’ya yeni özellik geldi” haberi değil. Daha büyük resimde GitHub Copilot’un IDE dışına taşarak geliştirici iş akışının her yerine yayılmasının devamı (ki bu çoğu kişinin gözünden kaçıyor). Visual Studio’daki code understanding ile başlayan çizgi şimdi terminale inmiş durumda.
Ben Logosoft’ta Azure danışmanlığı yaparken sık sık şunu görüyorum:ekiplerin toolchain’i parçalı olunca verim düşüyor. Bir yerde IDE,bir bir düşüneyim… yerde CI,bir yerde shell,bir yerde ayrı analiz aracı… Kullanıcı her seferinde farklı zihinsel moda geçmek zorunda kalıyor. E peki, sonuç ne öldü? Bu yüzden tekdüze olmayan ama tutarlı çalışan araçlara hep sıcak bakarım.
Bir de şu var:Copilot’un önerdiği şeylerin doğruluğu kadar açıklanabilirliği de önemli. Mesela geçen yıl Kasım ayında İstanbul’da bir AR-GE ekibiyle konuşurken “neden bu sınıf?” sorusuna net cevap alamadıkları için AI aracına güvenleri düşmüştü. Semantik katman işte tam burada güven inşa ediyor.
- Küçük ekip: Hızlı kurulum, hızlı kazanım, düşük operasyon yükü.
- Büyük kurum: Pilot çalışma, kalite metriği, build standardizasyonu şart.
- Bütçe kısıtlıysa: Önce hayatı modüller üzerinde deneyin, tüm repo ile başlamayın. (bence en önemlisi)
Nereden başlanır?
Araya gireyim: Lafı gevelemeden söyleyeyim:denemek istiyorsanız ilk iş compile_commands.json üretin. Sonra proje kökünde dil sunucusunun gerçekten doğru dosyaları gördüğünü kontrol edin. En çok atlanan nokta burası oluyor.
Ayrıca iki şey daha öneririm:önce basit bir formatter ya da utility sınıfıyla başlayın,sonra sonucu gözlemleyin. İkinci olarak,çıkan tavsiyeleri doğrudan kopyalamayın;özellikle template yoğun kodda öneri güzel görünüyor diye hemen prod’a atmayın. Ben kendi testlerimde iki kez yanlış base class önerisi gördüm—özellikle macro ile genişleyen yapılarda—ve manuel doğrulama yapmak zorunda kaldım.
Sıkça Sorulan Sorular
Copilot CLI için C++ dil sunucusu ne işe yarıyor ki?
Aslında C++ kodunu sadece metin olarak değil, semantik olarak anlamasına yardımcı oluyor. Yanı semboller, tanımlar, referanslar ve tip bilgisi sayesinde Copilot çok daha işabetli yanıtlar üretebiliyor — bence bu fark gerçekten hissedilir.
Bunu kullanmak için Visual Studio şart mı?
Hayır. Hedef kullanım zaten CLI tarafı. Ama şunu söylemeliyim: projenizin doğru build bilgisini vermesi gerekiyor; özellikle compile_commands.json dosyası burada kritik bir rol oynuyor.
CMake olmayan projelerde çalışır mı?
Evet, çalışıyor — ama süreç biraz daha uğraştırıcı olabiliyor açıkçası. MSBuild tarafı için örnek bir uygulama var; yine de native destek şu an geleceğe bırakılmış durumda.
Küçük projelerde gerçekten fark yaratır mı?
Bakın, Repo küçükse fark biraz daha sınırlı kalabiliyor, hani çok dramatik bir değişim beklemeyin. Ama yanlış eşleşmeleri azaltması bile bence güzel bir şey. Büyük projelerde işe etkisi çok daha belirgin bir hâl alıyor — tecrübeme göre asıl orada parlıyor.
Kaynaklar ve İleri Okuma
Microsoft C++ Build Tools dokümantasyonu
VS Code C/C++ eklentisi kaynakları
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