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.
📋 İçindekiler
Şöyle söyleyeyim, Benim 20+ yıllık altyapı ve bulut tecrübemde şunu defalarca gördüm: ölçemediğiniz şeyi büyütemezsiniz. Hele kurumsal yapılarda hiç büyütemezsiniz. Bir araç “aktif kullanıcı sayısı” veriyorsa güzel, ama bu biraz trafikte sadece araç sayısını görmek gibi; hangi şerit dolu, kim yavaş gidiyor, kim şehir içinde takılıyor… onları bilmeden yol yönetimi yapamazsınız. Copilot tarafındaki ai_adoption_phase alanı tam da buna benziyor.
Ha bu arada, bu yazıyı hazırlarken AZ-305. AZ-104 notlarıma da tekrar baktım; çünkü mesele yalnızca ürün özelliği değil, aynı zamanda veri modelleme ve yönetişim meselesi. Enterprise dünyasında küçük görünen bir alan eklenir, sonra bir bakarsınız raporlama stratejinizin omurgası olmuş. Bu sefer de öyle kokuyor.
Cohort mantığı neden önemli?
İşin aslı şu: “aktif kullanıcı” ile “olgun kullanıcı” aynı şey değil. Bir kişi haftada iki kere code completion — en azından ben öyle düşünüyorum — kullanıp kenara çekilebilir; başka biri işe agent mode ile iş akışını neredeyse uçtan uca değiştirir, sonra da kimseye fark ettirmeden bambaşka bir çalışma biçimine geçer. GitHub’ın burada yaptığı şey, kullanıcıyı dört faza ayırıp daha dürüst bir hikâye anlatmak:
Phase 0: hiçbir kohorta girmeyenler.
Phase 1: code first.
Phase 2: agent first.
Phase 3: multi-agent.
Bence bu sınıflandırma fena değil, hatta baya iş görüyor (en azından benim deneyimim böyle). Çünkü enablement ekipleri çoğu zaman yanlış yere bakıyor. Mesela eğitimleri herkese aynı verince sonuç ortalama kalıyor; oysa Phase 1’deki gruba IDE içi hız kazandıran pratikler lazımken, Phase iki (inanın bana). Phase 3 tarafında iş akışı tasarımı gerekiyor. Yanı konu “daha çok kullanım” değil, doğru kullanımın nerede takıldığını anlamak.
Geçen yıl Eylül ayında Ankara’daki bir telekom müşterisinde buna benzer bir tablo görmüştüm. Kullanıcıların yarısı Copilot lisanslıydı ama sadece küçük bir kısmı gerçekten agent tabanlı senaryolara geçmişti. Ekip önce bunu başarısızlık sandı. Halbuki değildi. Sadece yanlış soruyu soruyorlardı. Doğru soru şuydu: “Kim kod yazarken fayda alıyor, kim süreç hızlandırmaya geçti?” Cohort verisi tam burada devreye giriyor,. Sayı var diye olgunluk var sanmayalım.
Dört fazın pratik karşılığı
No cohort olanlar için problem bazen eğitim değildir; lisans verilmiş. Erişim akışı kırılmış olabilir ya da güvenlik politikaları yüzünden özellikler görünmüyordur. Kurumsalda sık olur bu iş… sessiz sedasız ilerler, sonra bir bakarsınız kimse özelliği açamamış.
Code first grubu genelde en kolay genişleyen grup oluyor. Çünkü geliştirici zaten editörün içinde yaşıyor. Ama buradaki risk şu: ekip — kendi adıma konuşayım — kendini iyi sanabilir çünkü acceptance oranları yükselmiştir; halbuki gerçek dönüşüm henüz başlamamıştır. Şimdi, peki neden? Çünkü öneri kabul etmek başka şey, davranış değiştirmek başka şey.
Agent first tarafında işe değişim daha derin oluyor. Burada insanlara sadece kod üretmeyi değil, görev delege etmeyi öğretirsiniz; yanı “ben yapayım” refleksinden biraz çıkmak gerekir (kolay değil tabiî) (ki bu çoğu kişinin gözünden kaçıyor). Bu kısım alışkanlık kırıyor — kabul edelim, herkes ilk başta rahat etmiyor.
Peki neden?
Multi-agent aşaması işe bana göre olgunluğun işareti ama her kurum için hemen hedef olmamalı. Küçük ekipte hızlı deneme — itiraz edebilirsiniz tabi — için güzel; büyük enterprise’da işe önce güvenlik sınırları, onay mekanizmaları ve gözlemlenebilirlik netleşmeli. Az önce “hemen hedef olmasın” dedim ya, aslında tam da bu yüzden acele etmek bazen ters teper.
version alanı boşuna yok. GitHub ürün yüzeyi büyüdükçe sınıflandırma mantığı değişebilsin diye tarihsel bağlam korunuyor.
Totals_by_ai_adoption_phase neyi gösteriyor?
Neyse, şimdi asıl teknik yere gelelim. Yeni totals_by_ai_adoption_phase dizisi, enterprise ve organization seviyesinde faz bazlı metrikleri topluyor; ama burada küçük bir hile var gibi düşünün, toplamı değil ortalamayı öne çıkarıyor. Bu ayrım bence kritik. Çünkü sum metriği sizi kolayca şaşırtabilir; büyük organizasyonda sayı zaten şişiyor, gerçek kullanım kalitesi işe arada kaybolabiliyor.
Metriklerin içinde neler var? Engaged user sayısı var, user-initiated interaction average var, code generation ve acceptance ortalamaları var, satır ekleme-silme ortalamaları var, PR yaratma, merge ve review istatistikleri de geliyor… yanı tablo baya iş görüyor. Ama durun bir saniye — bunlar phase içindeki kullanıcı başına ortalama değerler olarak geliyor, o yüzden tek bir sayıya bakıp “tamamdır” demek pek mantıklı değil.
| Kohort | Neye işaret ediyor? | Bende bıraktığı yorum |
|---|---|---|
| No cohort | Eşik altı veya düşük temas | Erişim mi sorunlu, ilgi mi düşük? Önce önü ayırın. |
| Code first | Editör içi üretkenlik başlangıcı | Eğitimle hızlı büyür ama çabuk tavana vurabilir. |
| Agent first | Süreç delegasyonu başlıyor | Burası gerçek dönüşümün başladığı yer olabilir. |
| Multi-agent | Birkaç yüzeyde aynı anda kullanım | Kurum olgunluğu iyi ama governance şart! |
Şunu söyleyeyim, Açık konuşayım: bazı ekipler bu tabloyu görünce hemen dashboard’a gömüyor ve işin bittiğini sanıyor. Evet, biraz sert söyledim ama gerçek bu. Hayal kırıklığı da genelde burada geliyor çünkü veri tek başına kültür değiştirmiyor; ben bunu Mart 2025’te İzmir’deki bir üretim şirketinde gördüm, rapor vardı. Aksiyon yoktu, haftalık review toplantılarında herkes grafiğe bakıp susuyordu… sonra yine eski alışkanlıklara dönülüyordu. Şaşırdım açıkçası.
Bunu biraz açayım. copilot konusundaki yazımız yazımızda bu konuya da değinmiştik.
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. Bu konuyla ilgili Azure DevOps MCP Server Nisan Güncellemesi: Küçük Dokunuşlar, Büyük Etki yazımıza da göz atmanızı tavsiye ederim.
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. SharePoint Framework 1.23 ve Ötesi: Asıl Mesaj Ne? yazımızda bu konuya da değinmiştik.
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. GitHub Code Quality API: Repo Bazlı Açma-Kapama Dönemi yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Copilot Memory’de Yeni Kontrol Dalgası: Silme, Kapsam ve CLI yazımıza da göz atmanızı tavsiye ederim.
Ş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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
4 comments