Copilot kullanımında yeni dönem: Cohort verisi ne anlatıyor?
GitHub’ın Copilot usage metrics API tarafına eklediği bu yeni cohort yaklaşımı, açık konuşayım, sadece bir “metrik güncellemesi” değil — itiraf edeyim, beklentimin üstündeydi —. Asıl mesele şu: artık elinizde kaç kişinin aktif olduğu bilgisi tek başına yetmiyor; insanlar Copilot’u nasıl kullanıyor, oraya bakabiliyorsunuz. Ben bunu ilk okuduğumda aklıma direkt 2024 sonbaharında görüştüğüm bir finans müşterisi geldi (evet, doğru duydunuz). İstanbul’da, cuma öğleden sonra yaptığımız toplantıda ekip bana şunu sormuştu: “Bizde Copilot lisansı var ama gerçekten yayılıyor mu?” İşte bu soru, yeni cohort mantığının tam kalbine dokunuyor.
Copilot adoption hikâyesini doğru anlatmak istiyorsanız önce aktiviteyi değil davranışı okuyun; yoksa rakamlar güzel görünür ama karar yanlış çıkar.
Küçük ekip ile enterprise arasında fark nerede?
Küçük startup’larda iş ilk bakışta daha basit gibi dürüyor,. Açık konuşayım bazen tam tersi oluyor; herkes bir şey deniyor, süreç daha oturmadan araç değişiyor (hani o “yarın başka tool’a geçeriz” hali). Startup tarafında ben olsam önce Phase 1’i düzgün kurarım, sonra birkaç gönüllüyle Phase 2 pilotunu çeviririm.
Büyük kurumsal yapılarda işe olay pilot açmak değil; pilotu dağıtmadan ölçeklemek. Orada security team ayrı konuşur, compliance ayrı takılır, IT bambaşka yerden gelir… Herkesin kendince haklı olduğu bir ortam var ama iş ağır akıyor, öyle de bir gerçek. Bu yüzden adoption raporuna sadece geliştirici gözüyle bakmak bana eksik geliyor; organizasyonun verdiği sinyali de yanına koymak lazım.
İşte tam da bu noktada devreye giriyor.
Maliyet kısmında da küçük bir not bırakayım: Azure tarafında ya da genel SaaS bütçelerinde TL bazında baktığınızda çoğu zaman ilk kavga lisans üzerinden çıkıyor, fakat asıl para enablement tarafında gidiyor — eğitim saatleri, liderlik zamanı, governance kurulumu… Kağıtta pek görünmüyorlar ama faturayı şişiren şeyler genelde bunlar oluyor.
Bütçe dar işe benim yaklaşımım net olurdu: herkese aynı anda agresif rollout yapmak yerine bazı takımları seçip phase progression ölçmek daha mantıklı geliyor. Evet, biraz yavaş gibi dürüyor. Ama az kullanıcıyla derin öğrenme yapınca neyin işe yaradığını daha net görüyorsunuz; sonra genişletmek çok daha rahat oluyor.
Bence en mantıklı uygulama sırası şöyle:
- Lisans ve erişim kontrolünü doğrulayın.
- User-level report ile Phase dağılımını çıkarın.
- Takım bazında teams filter kullanın.
- Aynı faz içinde engagement trendine bakın.
- Eğitim planını phase’e göre ayarlayın.
{
"report": "user-level",
"fields": ["ai_adoption_phase", "version"],
"window_days": 28,
"engagement_rule": "at_least_2_days"
}
Beni ikna eden taraflar ve eksik kalan noktalar
Beni en çok ikna eden şeylerden biri, geriye dönük bağlamı düşünmeleri öldü. version alanıyla sınıflandırmayı v1 diye bir düşüneyim… etiketlemek bence yerinde bir hareket. Ürün yüzeyi değiştikçe sınıflar da kayıyor, bugün iyi duran tanım yarın biraz yamulabiliyor.
Bir de şu var: agent-first ile multi-agent ayrımı kağıt üstünde baya temiz görünüyor, ama pratikte bazı ekiplerde sınırlar bulanıklaşıyor. Bu kötü mü? Tam olarak değil. Ama raporu okuyan kişinin biraz temkinli davranması gerekiyor, yoksa metriklere fazla güvenip yanlış yere sevinmek de mümkün.
Şahsen, Ben kendi adıma en çok bununla uğraşıyorum: veriyi “kim ne kadar aktif” diye okumak kolay, ama “hangi davranış olgunluk sinyali veriyor” kısmı daha zor. İkincisi emek istiyor, hatta bazen insanı yoruyor; çünkü aynı sayı, farklı ekiplerde bambaşka şey anlatabiliyor.
Bir kez de hata yaşamıştım. Haziran 2024’te Frankfurt’taki bir düşüneyim… bir demo ortamında API çağrısında beklenmedik biçimde boş phase değerleri gördüm. Sorun aslında auth scope’un eksik verilmesiydi; çözünce veri yerine oturdu… Yanı olay çoğu zaman üründe değil, entegrasyonda çıkıyor. Evet, aynen öyle.
Bir de dürüst olayım: bu metrikler fena değil, ama tek başına yeterli değiller. PR kalitesi, gerçek teslim süresi, geliştirici memnuniyeti ve güvenlik olaylarıyla birlikte okunmazsa resmin yarısı eksik kalır; bak şimdi, sayı var diye her şey anlaşılmış olmuyor.
Nereden başlanmalı?
Denenmek istiyorsanız, ilk işiniz REST API erişimini doğrulamak olsun. Sonra user-level raporda ai_adoption_phase alanını çekin. Ardından enterprise/org düzeyinde totals_by_ai_adoption_phase dağılımına bakın. Peki bunu neden söylüyorum? Kulağa basit geliyor, evet; ama işin asıl yorucu kısmı, o veriyi düzgün bir düzene sokmak.
Eğer kurumunuzda Azure DevOps ya da GitHub tabanlı farklı izleme panelleri varsa, bunları yan yana koyun. Mesela benim Logosoft’taki bazı danışmanlık projelerinde yaptığım şey şuydu: Copilot adoption datasını sprint throughput ve PR review süresiyle birlikte değerlendirdik. Sonuç biraz şaşırttı açıkçası; bazı takımlar çok fazla kod üretiyor gibi görünüyordu ama merge süreleri uzuyordu. Demek ki hız artmıştı, fakat kalite zinciri hâlâ bir yerde takılıyordu.
Bu yüzden ben hep şunu söylüyorum: metrik toplayan kazanmaz, metriği aksiyona çeviren kazanır. Basit ama etkili. Hani şu dashboard’a bakıp “tamamdır” demek var ya, işte o genelde erken sevinç oluyor.
Bak bir de şunu söyleyeyim: enablement planınızı phase’e göre ayarlarsanız, eğitim sunumlarını da kurtarırsınız! Herkese aynı slide set’i göstermek yerine, Phase 1’e kısa pratikler, Phase 2’ye workflow örnekleri, Phase 3’e governance senaryoları vermek daha iyi oturuyor. Ben ilk başta bunun fazla detay olduğunu düşünmüştüm,. Sahada işler öyle yürümüyor; insanlar kendi seviyesine yakın şeyi daha hızlı kapıyor.
Bir de beklediğim kadar iyi olmayan taraf şu: toplulaştırılmış metriklerin yorumlanması için hâlâ deneyimli insan gerekiyor. Yanı sihir yok. Dashboard sizi bir yere kadar yönlendirebilir (hatta bazen yanlış yöne bile çekebilir),. Karar verecek olan yine sizsiniz. Peki neden? Çünkü sayı tek başına konuşmuyor.
Sıkça Sorulan Sorular
Copilot usage metrics API’deki ai_adoption_phase ne işe yarıyor?
Yanı bu alan, kullanıcının Copilot’u hangi olgunluk seviyesinde kullandığını gösteriyor. Sadece “aktif mi değil mi” sorusunun ötesine geçiyor aslında — hangi yüzeylerde etkileşim kurduğunu da anlayabiliyorsunuz. Bence oldukça kullanışlı bir sinyal.
İşte tam da bu noktada devreye giriyor.
Totals_by_ai_adoption_phase neden önemli?
Kurum veya organizasyon seviyesinde faz bazlı özet sunuyor. Mesela hangi grubun code-first kaldığını, hangisinin agent-first ya da multi-agent seviyesine geçtiğini buradan görebiliyorsunuz. Tahmin eder mısınız? Açıkçası büyük organizasyonlar için bu tablo çok şey anlatıyor.
Bu metrikler herkese açık mı?
Hayır. Sadece enterprise administrator’lar ve organization owner yetkisine sahip kişiler kullanabiliyor. REST API erişimi olan hesaplarla çalışıyor.
Küçük şirketlerde bu veriyi nasıl kullanmalı?
Küçük ekiplerde öncelik rollout hızı değil, öğrenme döngüsü olmalı. Tecrübeme göre en mantıklısı önce birkaç takımda phase progression’ı ölçmek, sonra genişlemek. Acele etmeye gerek yok!
Sadece bu metriklere bakmak yeterli mi?
Bence hayır, neredeyse kesinlikle değil. PR kalitesi, teslim süresi, geliştirici memnuniyeti ve güvenlik sinyalleriyle birlikte okunması gerekiyor. Yanı tek başına adoption metriği hani eksik kalıyor — büyük resmî görmek için diğer verilerle birleştirmek şart (inanın bana)
Kaynaklar ve İleri Okuma
GitHub Changelog — Copilot usage metrics API adds cohorts for AI adoption
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.
4 comments