JetBrains Copilot Artık CLI Üzerinde Çalışacak: Ne Değişiyor?
JetBrains tarafında Copilot kullananlar için epey önemli bir haber var. GitHub, JetBrains IDE’lerindeki Copilot’un agent harness’ını, yanı ajanı ayakta tutan koşum sistemini, değiştiriyor. Yerel harness emekliye ayrılıyor, yerine Copilot CLI geliyor. Hem de varsayılan olarak.
Açık konuşayım: Bu işin teknik kısmı var tabiî, ama asıl mesele biraz daha başka. Çünkü bu, sadece bir altyapı güncellemesi değil; GitHub’ın “Copilot deneyimini tek bir omurga üzerine toplama” fikrinin sahadaki ilk net işareti gibi dürüyor. Aşağıda ne değiştiğini, neden böyle bir yol seçildiğini ve bunun günlük kullanımda neye benzeyeceğini konuşalım.
Önce şunu netleştirelim: Harness ne demek?
Teknik olmayan okurlar için bir saniye yavaşlayalım (ben de ilk duyduğumda şaşırmıştım). “Agent harness” dediğimiz şey, AI ajanının içinde çalıştığı koşum takımıdır. Model ayrı, harness ayrı. Model size kod öneriyor olabilir ama o modeli plan yaptıran, dosya okutan, terminal komutu koşturan, sonucu kontrol eden (evet, doğru duydunuz). “tamam öldü” dedirten parça harness’tır.
Bir at koşusu düşünün. Atın kendisi modeldir; hız orada, güç orada, dayanıklılık da orada. Ama o atın nereye gideceğini, nasıl yönleneceğini ve ne zaman duracağını belirleyen şey koşum takımıdır. Harness tam olarak bu işte. Ve agentic coding tarafında, bunun etkisi model kalitesi kadar hissediliyor artık.
Şimdiye kadar JetBrains tarafında GitHub kendi yerel harness’ını kullanıyordu (evet, doğru duydunuz). VS Code’da başka bir düzen vardı, GitHub.com’da başka bir yapı vardı, terminalde yine başka bir akış vardı. Kâğıt üstünde mantıklı görünüyor; her platformun kendi huyu var sonuçta. Pratikte işe tablo biraz karıştı.
Evet.
Neden değişiyor: Parçalı yapının bedeli
Geçtiğimiz bir yılda Copilot baya şekil değiştirdi aslında. Eskiden satır satır kod öneren bir araçken şimdi dakikalarca süren ajan oturumları çalıştırıyor; planlıyor, kod yazıyor, test açıyor, hatayı görüyor. Geri dönüp düzeltiyor (bazen de inadına aynı bir düşüneyim… yere tekrar çarpıyor). Bu da doğal olarak harness’a binen yükü artırdı.
JetBrains tarafının kendi harness’ını taşımaya devam etmesinin iki can sıkıcı sonucu vardı: biri gecikme, diğeri tutarsızlık. VS Code’a gelen yeni bir yetenek JetBrains’e haftalar sonra geliyordu bazen aylar sonra. Ayrı kod tabanına uyarlanması gerekiyordu. Mantıklı değil mi? Aynı modeli kullansanız bile görev çıktısı farklı olabiliyordu çünkü prompt yönetimi, tool çağrıları ve hata toleransı birebir aynı davranmıyordu.
- Gecikmeli özellikler: VS Code’a gelen yeni bir yetenek JetBrains’e haftalar — bazen aylar — sonra geliyordu.
- Tutarsız sonuçlar: Aynı modeli kullanmasına rağmen JetBrains’teki görev ile VS Code’daki görev farklı kalite verebiliyordu.
Copilot CLI’a geçişle birlikte GitHub’ın söylediği şey kabaca şu: “Tek omurga olsun, tek harness olsun, herkes benzer kaliteyi görsün.” Ben bu yaklaşımı fena bulmuyorum açıkçası. Ama küçük bir not düşeyim: JetBrains kullanıcısı ile VS Code kullanıcısı birebir aynı profil değil; JetBrains tarafı daha IDE-merkezli düşünüyor çünkü alışkanlıklar öyle şekillenmiş durumda.
Mimarı olarak ne oluyor?
Bak şimdi, yeni düzende Copilot CLI oturumları arka planda makinenizde bağımsız çalışıyor. IDE işe bunları başlatıyor, izliyor ve gerektiğinde yönlendiriyor. Yanı IDE biraz kontrol odasına geçiyor; ajanın asıl koşturduğu yer CLI oluyor.
Buna çok yabancı değiliz aslında. GitHub.com’daki Copilot agent görevleri de benzer mantıkla ilerliyor; VS Code’daki agent oturumları da öyleydi zaten. JetBrains’in bu yapıya katılmasıyla ekosistemdeki parçalar birbirine daha çok benziyor. Neyse uzatmayayım: işin özü tutarlılık.
“Harness’ı tek noktaya çekmek model değişikliklerini de hızlandırır. Yarın GPT-5.5 ya da Claude’un yeni sürümü geldiğinde her IDE için ayrı entegrasyon beklemek yerine, CLI üzerinden tüm yüzeylere aynı anda yayılır.”
Eski yerel oturumlara ne olacak?
Bak şimdi, Bu kısım çoğu kişiyi geriyor biliyorum — haklı da sayılırlar biraz. Cevap basit: mevcut yerel ajan oturumları kaybolmuyor; otomatik olarak Copilot CLI oturumlarına dönüşecekler. Yanı yarıda kalmış bir refactoring varsa onun üstüne devam edebileceksiniz (tabi ortamınız bozulmamışsa). Mantıklı değil mi? Günlük akışta da büyük kırılma yok: IDE’den başlatıyorsunuz, IDE’den takip ediyorsunuz ve izin gerektiğinde yine IDE üzerinden onay veriyorsunuz.
Bu Türkiye’deki ekipler için ne anlama geliyor?
Sahada gördüğüm kadarıyla Türkiye’de Java + JetBrains kombinasyonu hâlâ baskın durumda diyebilirim. Mesela de bankacılıkta, telekomda. Sigortacılıkta IntelliJ IDEA Ultimate fiilen standart gibi kullanılıyor (evet biraz abartılı söyledim ama sız anladınız). Bu ekiplerin Copilot’a geçişi VS Code dünyasına göre daha temkinli ilerledi; çünkü mevcut JetBrains harness’ı bazı yerlerde geri kalıyordu. Ekipler bunu hissediyordu. Daha fazla bilgi için
Kendi müşterilerimde en çok duyduğum cümlelerden biri şuydu: “Hocam Copilot iyi hoş da IntelliJ’de bizde biraz sönük kalıyor.” İşte bu farkın önemli kısmı harness farkından geliyordu sanırım. Yeni yapıyla beraber JetBrains kullanan ekiplerin VS Code kullananlarla aynı yetenek havuzuna yaklaşması gerekiyor — teoride en azından (ciddiyim)
Peki pratikte ne olacak? Önümüzdeki birkaç ay kilit görünüyor bana göre. Çünkü CLI harness’ını VS Code dışındaki bir IDE’ye taşımak kağıtta yazdığı kadar pürüzsüz gitmeyebilir (olabilir de olmayabilir de). Erken benimseyenler — özellikle kurum içindeki “Copilot şampiyonları” — sürtünme noktalarını ilk gören kişiler olacak gibi dürüyor.
Pratik geçiş rehberi: Ne yapmalısınız?
Bunu kurumsal tarafta yönetiyorsanız lafı gevelemeden şu sırayı öneririm:
- Pilot ekip seçin: 3-5 kişilik küçük bir grup yeterli olur; yeniliğe açık olanlar iyi gider.
- Mevcut yerel oturumları temizleyin: Askıda kalan işleri kapatın ki geçişte gereksiz yük olmasın.
- Copilot CLI’yı manuel kurun: Sadece IDE’nın halletmesine bırakmayın; terminalde de görün ve tanıyın.
- Permission politikalarını gözden geçirin: Dosya yazma ve komut çalıştırma onayları farklı gelebilir; güvenlik ekibiyle kısa bir tür atın.
- Geri bildirım toplayın: İlk iki hafta boyunca ne çalıştı ne çalışmadı diye not alın; ciddi bug varsa ilgili kanala açın.
Küçük ekipseniz ya da bireysel kullanıcıysanız prosedürü büyütmeye gerek yok bence. Rollout size geldiğinde varsayılan olarak CLI seçili gelecek zaten. Sadece ilk birkaç oturumda normalden farklı davranış var mı diye biraz dikkat edin yeter.
Bir karşılaştırma tablosu
| Boyut | Eski Yerel Harness | Copilot CLI Harness |
|---|---|---|
| Yeni özellik gecikmesi | Haftalar — aylar | Diğer yuzeylerle es zamanlı |
| Model parity | Gecikmeli | Daha hızlı yayılım |
| Oturum yapısı | IDE içine gömülü | A rka planda bağımsız süreç |
| P aralel görev | Sınırlı | Daha doğal destekleniyor |
| B akım yükü (GitHub için) | Ayrı kod tabanı | Tek omurga |
Sıkça Sorulan Sorular
Copilot CLI’yı ayrıca kurmam gerekiyor mu?
Aslında şart değil. JetBrains plugin’i CLI bileşenini zaten kendi içinde getiriyor. Ama manuel kurulum — ki bu tartışılır — da yapabilirsiniz — hani terminal üzerinden de Copilot kullanıyorsanız, tek seferlik bir kurulumla her iki yüzeyde de çalışıyor. Bu ne anlama geliyor? Bence geliştiriciler için daha fazla kontrol istiyorsanız manuel yol daha mantıklı.
Evet, doğru duydunuz.
Mevcut ajan oturumlarım kaybolacak mı?
Hayır, kaybolmuyor. GitHub’ın açıklamasına göre yanı mevcut yerel oturumlar otomatik olarak Copilot CLI oturumlarına dönüştürülüyor. Yarım bıraktığınız görevlerden kaldığınız yerden devam edebilirsiniz. Yine de açıkçası büyük geçiş öncesi kritik oturumlarınızın özetini bir yere not edin — her ihtimale karşı diyeyim.
Bu değişiklik performansı etkiler mi?
İki yönlü bir etki var. İyi tarafı, CLI harness daha tutarlı sonuçlar üretiyor ve paralel görevleri çok daha iyi yönetiyor. Kötü tarafına gelince, arka planda bağımsız bir süreç çalıştığı için sistem kaynak tüketimi — yanı RAM. CPU — yerel harness’a göre biraz artabiliyor. Düşük donanımlı makinelerde bu fark hissedilir, tecrübeme göre özellikle eski laptoplarda dikkat etmek lazım.
Şirketim Copilot Enterprise kullanıyor, politika ayarları etkilenir mi?
Şunu söyleyeyim, Politika ayarlarınız — mesela model seçimi, izin verilen depolar, içerik filtreleme — korunuyor çünkü bunlar harness seviyesinde değil, hesap. Kuruluş seviyesinde yönetiliyor. Ama dosya sistemi erişim onayları ve komut çalıştırma izinleri CLI harness’ta biraz farklı sunulabiliyor. Mantıklı değil mi? Açıkçası geçiş öncesi güvenlik ekibinizle kısa bir toplantı yapmanızı öneririm.
JetBrains plugin’inde “agent provider” seçeneği nerede?
Settings → Tools → GitHub Copilot → Agent altında bulacaksınız. Rollout size ulaştığında bu menüde Copilot CLI seçeneği görünüyor ve varsayılan olarak zaten seçili geliyor. Tahmin eder mısınız? Eski yerel harness’ı bir süre daha kullanmak isterseniz buradan değiştirebilirsiniz — ama hani uzun vadede deprecate edileceğini de aklınızın bir köşesinde tutun.
Kaynaklar ve İleri Okuma
Microsoft DevBlogs: GitHub Copilot for JetBrains is moving to Copilot CLI
GitHub Docs: Copilot Coding Agent Dokümantasyonu
GitHub Copilot CLI Resmî Repository (inanın bana)
JetBrains Marketplace: GitHub Copilot Plugin (bizzat test ettim)
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.
2 comments