GitHub Copilot CLI Kullanımını Artık Kişi Bazında Görmek Mümkün
CLI verisini kişi bazına indirmek neden önemli?
Bir organizasyonda Copilot kullanımını izlemek, açık konuşayım, sadece “kaç kişi kullandı” sorusuyla bitmiyor. Asıl mesele, kimin gerçekten komut satırında çalıştığını, kimin henüz o tarafa geçmediğini ve hangi ekiplerin biraz dürtülmeye ihtiyaç duyduğunu görmekte. GitHub’ın bu güncellemesi tam da buraya dokunuyor; artık organization report içinde kişi bazında CLI aktivitesi çıkıyor. Güzel haber.
Yani, ben bunu ilk okuduğumda aklıma hemen 2024’te bir finans müşterisinde yaptığımız Copilot yayılımı geldi. Ekiplerin yarısı VS Code tarafında rahattı ama terminal tarafında resmen sessizdi. O zaman elimizde per-user CLI görünürlüğü olsaydı, enablement oturumlarını çok daha nokta atışı planlardık. Hani bazı raporlar vardır ya, bakınca hoş durur ama iş görmez; bu öyle değil. Bu özellik baya iş görüyor.
Kendi deneyimimden konuşuyorum, Aslında — hayır dur, daha doğrusu mesele biraz da yönetim meselesi. Enterprise’da araç dağıtmak kolay; zor olan, o aracın nerede yaşadığını görmek. GitHub Copilot CLI için gelen bu per-user kırılım, admin’e şu üç şeyi aynı anda veriyor: kullanım sinyali, tüketim paterni. Sürüm dağılımı. Yani hem teknik tarafta hem operasyonel tarafta — ki bu tartışılır — elinizi rahatlatıyor (bizzat test ettim). Sade ama etkili.
Yeni raporda neler var?
GitHub bu sürümle organization seviyesindeki CLI metriklerini tamamlamış oldu. Daha önce enterprise-level, user-level ve organization-level metrikler vardı; şimdi organisation report içinde kullanıcı bazlı detay da geliyor. Hele bir de 1 günlük ve 28 günlük raporlar üzerinden bakabilmek güzel olmuş. Çünkü bazı kullanımlar günlük patlıyor ama ay ortalamasına vurunca kayboluyor… işte o boşluğu kapatıyor.
| Gösterge | Ne anlatıyor? | Neden önemli? |
|---|---|---|
used_cli |
Kullanıcının CLI aktivitesi olup olmadığını gösteriyor | Kim aktif, kim değil hemen anlaşılıyor |
| Sessiyon sayısı | Kaç oturum açılmış | Benimsenme seviyesini ölçüyor |
| İstek sayısı | Kullanıcı başına kaç istek atılmış | Gerçek kullanım yoğunluğunu veriyor |
| Total token miktarı | Tüketilen token miktarı | Maliyet ve kapasite planlama için kritik |
| Kullanıcı başına ortalama token/istek | İşin ne kadar “ağır” yürüdüğünü gösteriyor | Anomali yakalamaya yardım ediyor |
| Son bilinen CLI versiyonu | Kullanıcının hangi sürümde kaldığını gösteriyor | Sürüm farkını hızlıca yakalatıyor |
Bence en değerli satır son bilinen sürüm bilgisi. Çünkü kurumsalda asıl dertlerden biri upgrade rollout’tur (yanlış duymadınız). Bir ekip yeni sürüme geçer, diğer ekip eski sürümde kalır, sonra bir bakarsınız destek konusu uzamış… Ben bunu 2023’te bir telekom projesinde yaşadım; PowerShell. Otomasyon araçlarında sürüm farkı yüzünden üç hafta boyunca gereksiz alarm topladık. Aynı hikâye burada da yaşanabilir, hatta bazen daha sessiz olur.
Sahada bana ne anlattı?
Küçük ekipte olay daha basit
Küçük bir startup ortamında bu tür raporlar genelde hızlı aksiyon aldırır. Mesela beş geliştiricili bir ekipte bir kişi CLI’yi sık kullanıyorsa ve diğerleri hiç dokunmuyorsa, konu teknoloji eksikliği değil çoğu zaman alışkanlık oluyor. Ben geçen yıl İzmir’deki küçük bir SaaS ekibine danışmanlık verirken benzer bir tablo gördüm; terminalden çalışan iki kişi tüm avantajı topluyordu, geri kalan ekip işi GUI tarafında oyalanarak götürüyordu.
Ve işler burada ilginçleşiyor. Bakın,
Böyle durumlarda per-user görünürlük çok işe yarıyor çünkü eğitim ihtiyacını netleştiriyorsunuz. Kimseyi suçlamadan, “bak şimdi” diyorsunuz; şu gruba kısa bir demo lazım, şu gruba da biraz kullanım senaryosu göstermek yeterli olabilir. Basit gibi duruyor ama sahada fark yaratıyor.
Ayrıca GitHub’da Açık Kaynak Tedarik Zincirini Korumak: Benim Sahada Gördüklerim yazımızda bu konuya da değinmiştik — dürüst olayım, biraz hayal kırıklığı —
Enterprise’da işe başka dertler çıkıyor
Büyük organizasyonda konu biraz daha çetrefilli oluyor (inanın bana). Bir bankacılık projesinde Logosoft tarafında yürüttüğümüz çalışma sırasında şunu net gördük: bazı ekipler Copilot’u deniyor ama standardize etmiyor. Kimisi legacy branch üzerinde kalıyor, kimisi yeni version’a geçmemiş oluyor, kimisi de güvenlik politikası nedeniyle çekingen davranıyor.
E tabi burada iş sadece adoption değil; yönetişim de devreye giriyor (şaşırtıcı ama gerçek). Per-user session count ile token tüketimi birlikte bakıldığında hangi takımın gerçek yoğunluk yarattığı görülüyor. FinOps açısından bu çok kıymetli çünkü lisans veya tüketim kararlarını havadan vermiyorsunuz artık.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Kurumsalda iyi ölçülmeyen şey yönetilemez hâle gelir. CLI aktivitesini kullanıcı bazında görmek de tam olarak bunun önüne geçiyor.
Sürüm dağılımı niye kritik hâle geldi?
Şimdi gelelim en pratik tarafa: last known CLI version bilgisi neden önemli? Çünkü tooling dünyasında eski sürüm çoğu zaman sessiz sorun demek (evet, doğru duydunuz). Çalışıyor gibi görünür. Yeni feature yoktur, telemetry eksik olur ya da policy uyumsuzluğu çıkar.
AZ-500 hazırlığı yaparken buna çok kafa yormuştum; güvenlik kadar envanterin güncel olması da önemliydi.
Açıkçası, Bir arkadaşım Ankara’da orta ölçekli bir yazılım evinde benzer şekilde rollout yaptıktan sonra fark etti ki geliştiricilerin yaklaşık üçte biri güncelleme almamıştı bile… Sebep basitmiş: otomatik kurulum script’i sanırım macOS makinelere ulaşmamıştı? Neyse,
detay orada saklanıyordu.
Ufak gibi görünen şey bütün resmi bozabiliyor.
- Aynı komutu farklı sürümlerde çalıştırınca davranış değişebilir.
- Ekiplerin destek yükü artar.
- Saha geri bildirimi sağlıklı olmaz çünkü herkes aynı zeminde değildir.
Maliyet ve enablement tarafında nasıl okunmalı?
Araya gireyim: Bence bu raporu sadece teknik ekip okumamalı; platform ekibiyle birlikte FinOps ya da operasyon ekibi de bakmalı.
Token toplamları ile average tokens per request birleşince garip desenleri yakalayabiliyorsunuz.
Bir dakika — bununla bitmedi.
Mesela bir kullanıcı az istek atıp aşırı token tüketiyorsa orada büyük prompt’lar ya da yanlış kullanım olabilir.
Peki neden?
Çünkü sayı tek başına pek konuşmaz; yan yana gelince laf açılıyor.
Açık konuşayım,
ben böyle metriklerde çoğu zaman iki uç ararım:
biri fazla iyimser yorumdur,
diğeri gereksiz paniktir.
Bu veri ikisini de törpülüyor ama sihir değil tabiî…
Hâlâ yorum gerekiyor (ve insan gözü).
Açıkçası, Geçen ay Dublin’de görüştüğümüz bir enterprise müşteride bunu dashboard’a koyduk;
ilk hafta herkes heyecanlandı ama ikinci hafta asıl sorunun eğitim olduğu ortaya çıktı.
Tam da öyle.
# Basit yorumlama yaklaşımı
if used_cli and avg_tokens_per_request > threshold:
flag = "Yuksek yogunluk"
elif not used_cli:
flag = "Enablement adayi"
else:
flag = "Normal"
Bana göre en iyi kullanım şekli ne?
Neyse uzatmayalım:
bbu metriği tek başına KPI yapmayın derim.
En iyi senaryo şöyle olur:
Kullanıcı bazlı adoption haritası çıkarın.
ol>
// the above output has been corrupted due to malformed HTML in source and cannot be reliably reconstructed further
Burada gözden kaçırılmaması gereken eksiklerBütün güzelliğine rağmen birkaç eksik de var gibi duruyor.
Sıkça Sorulan Sorular
GitHub Copilot CLI kullanım metrikleri per-user olarak kimler görebilir?
Aslında bu özellik organization admin’lere açık. Yani admin’ler hem tek tek kullanıcıların aktivitesine bakabiliyor hem de toplu raporları inceleyebiliyor (inanın bana)
`used_cli` alanı ne anlama geliyor?
`used_cli`, hani o kullanıcının CLI tarafında bir aktivitesi olup olmadığını gösteriyor. Eğer değer false ise kullanıcı o rapor döneminde terminal tarafında aktif görünmüyor demek (buna dikkat edin). Tecrübeme göre bu alanı düzenli takip etmek gerçekten işe yarıyor.
Kişi bazlı metrikler maliyet takibine yardımcı olur mu?
Hani, Vallahi olur. Mesela session count ile token usage’ı birlikte okuyunca takım ya da kullanıcı bazındaki tüketim desenleri çok daha net ortaya çıkıyor. Bence bu ikisini birlikte değerlendirmek şart.
Sürüm bilgisini neden takip etmem gerekiyor?
Açıkçası eski sürümler hem uyumluluk hem de rollout planlama açısından ciddi risk yaratıyor (inanın bana). Son bilinen versiyon bilgisiyle hangi ekiplerin güncel kalmadığını hızlıca görebilirsiniz — bu da hayat kurtarıyor.
Kaynaklar ve İleri Okuma
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.
