GitHub Copilot Enterprise: Spaces ve Usage Metrics API’sine Rehber

GitHub Copilot Enterprise Nedir?

GitHub Copilot Enterprise, GitHub’ın Copilot plan hiyerarşisinin en üstünde yer alır.

GitHub Copilot Business veya Pro+ ile karşılaştırıldığında Enterprise, yönetişim, kurumsal bağlam ve ölçüm yeteneklerine daha ağır vurgu yapar. Bireysel geliştiriciler veya küçük ekiplerden ziyade, büyük mühendislik ortamlarında faaliyet gösteren şirketler için tasarlanmıştır.

Uygulamada en çok önem taşıyan iki yetenek şunlardır:

1. Spaces ile özel kurumsal bağlam
2. Usage Metrics API ile kuruluş genelinde telemetri

Bu iki özellik, Copilot’ı “akıllı otomatik tamamlama”dan, içsel bir yapay zeka mühendislik platformuna daha yakın bir şeye dönüştürür.

GitHub Copilot Enterprise’dan en fazla değeri elde eden şirketler onu dahili altyapının kilit bir bileşeni olarak görür. Kurumsal bağlamı dikkatle yapılandırır, benimsemeyi sürekli ölçer ve varsayımlar yerine kullanım verilerine dayalı olarak politikaları ayarlarlar.

GitHub ekosistemine daha geniş bir bakış için GitHub Ürünlerine Giriş rehberimizi okumanızı öneririm.

Enterprise, Business ve Pro+’tan nasıl farklıdır

GitHub Copilot Enterprise, Business aboneliğini aşağıdaki ek özelliklerle genişletir:

• Kurum düzeyinde kullanım metrikleri
• Genişletilmiş yönetişim kontrolleri
• Kuruluş genelinde politika kalıtımı
• Daha büyük premium istek tahsisleri (Business katmanındaki 300’e karşı 1.000)
• Ek model erişimi ve yönetimi

Enterprise, Copilot Enterprise aboneliğine ek olarak GitHub Enterprise Cloud gerektirir. Bu, kullanıcı başına ek maliyet getirir; bu nedenle kuruluşunuzun gerçekten yönetişim, telemetri ve kurumsal düzeyde yönetim gereksinimi olduğundan emin olun.

Not: Business aboneleri Usage Metrics API’ye organizasyon düzeyinde erişir (/orgs/{org}/…). Enterprise aboneleri ayrıca tüm organizasyonları tek bir görünümde kapsayan, kurum genelindeki toplulaştırılmış raporlara (/enterprises/{enterprise}/…) erişir.

GitHub Copilot Enterprise kimler için

GitHub Copilot Enterprise, halihazırda olgun GitHub ortamları işleten kuruluşları hedefler.

Tipik Enterprise müşterileri şunları içerir:

• Büyük mühendislik organizasyonları
• Düzenlemeye tabi sektörler
• Çoklu ekipli platform mühendisliği grupları
• Dahili geliştirme standartları olan şirketler
• Merkezi yönetişim gerektiren kuruluşlar

Bunun Copilot’ın performansını doğrudan iyileştirmediğini unutmayın. Bu ayrımın önemli olduğunu düşünüyorum çünkü birçok ekip başlangıçta fazla satın alım yapıyor. Enterprise’ın “daha iyi Copilot” anlamına geldiğini varsayıyorlar; oysa gerçekte Enterprise çoğunlukla yönetişim ve ölçüm araçları ekler.

Copilot Spaces: Kuruluşunuz için Özel Bağlam

Copilot Spaces, genelleştirilmiş yapay zeka kod asistanlarının en büyük zayıflıklarından birini çözer.

Kutu açılışında Copilot, genel programlama bilgisini makul düzeyde anlar. Ancak iç API’lerinizi, mimari kararlarınızı, kodlama kurallarınızı, dağıtım iş akışlarınızı veya işe alım dökümantasyonunuzu kendiliğinden anlamaz.

Spaces, Copilot’ın konuşmalar ve kod yardımı sırasında başvurabileceği, seçilmiş bir kurumsal bağlam sağlar.

Pratikte Spaces, Copilot’ın şu tür soruları yanıtlamasına yardımcı olur:

• “API işleyicilerini dahili olarak nasıl yapılandırıyoruz?”
• “Platform ekibimizin önerdiği kimlik doğrulama kütüphanesi hangisi?”
• “Bu mikro hizmet hangi dağıtım iş akışını kullanmalı?”
• “Backend ekibimizin benimsediği adlandırma kuralları neler?”

Spaces neleri destekler

Spaces, daha eski Knowledge Bases sisteminden daha geniş bir kurumsal içerik yelpazesini destekler.

Desteklenen içerik türleri şunlardır:

• Kod dosyaları
• Markdown dokümantasyonu
• JSON dosyaları
• Yüklenen dosyalar
• Görseller
• GitHub Issues
• Pull request’ler

Her içerik türü farklı biçimde katkı sağlar.

Kod dosyaları, Copilot’ın uygulama kalıplarını anlamasına yardımcı olur. Markdown dosyaları mimari açıklamalar ve onboarding rehberliği sunar. Pull request’ler inceleme tartışmalarını ve geçmiş mühendislik kararlarını ortaya koyar. Bu kombinasyon, Copilot’a kuruluşunuzun geliştirme uygulamaları hakkında daha iyi farkındalık kazandırır.

İnce ama önemli bir nokta: Spaces, GitHub’a eklenmiş basit vektör veritabanları değildir. Kurumsal ortamlara yönelik paylaşım kontrolleri ve kurumsal yönetişim iş akışlarını içerirler.

Knowledge Bases’in kullanımdan kaldırılması

GitHub, eski Copilot Knowledge Bases özelliğini 1 Kasım 2025’te kullanım dışı bıraktı.

Spaces, Knowledge Bases’in yerini şu özelliklerle aldı:

• Daha geniş içerik desteği
• Daha iyi paylaşım kontrolleri
• Geliştirilmiş yönetim
• Daha esnek organizasyon düzeyi yönetim

Hâlâ Knowledge Bases’e atıfta bulunan güncel olmayan dokümantasyon ve blog yazıları bulabilirsiniz. Eski eğitimleri takip ederken dikkatli olun; çünkü 2025’ten 2026’ya geçiş döneminde birçok uç nokta ve iş akışı değişti.

Copilot Spaces Oluşturma ve Yapılandırma

Yönetim açısından bakıldığında, Copilot Spaces oluşturmak oldukça basittir. Zorluk, bunları ekipler genelinde onlarca veya yüzlercesini yönetmekte ortaya çıkar.

Erken seçtiğiniz yapı genellikle kalıcı olur. Sahiplik kuralları baştan belirlenmediği için, kuruluşların Spaces içinde farkında olmadan “dokümantasyon yayılması” yarattığına çok kez şahit oldum.

Herkes bir Copilot Space oluşturabilir; o hâlde kişisel repomuzda bir tane oluşturarak deneyelim. Bu adımlar Enterprise düzeyinde de benzerdir, yalnızca birkaç sayfa farklıdır.

Bir Space ayarlama

Bir Space oluşturma genel olarak şu iş akışını izler:

1. Enterprise yönetim alanınızda Copilot Spaces sayfasına gidin
2. Yeni bir Space oluşturun

3. Depoları ve içerik kaynaklarını seçin; MCP’ler ve diğer kullanışlı araçlar dahil

4. Kaynak ekleme işlemi, sağ taraftaki “+ Add sources” düğmesine tıklanarak yapılabilir

5. Bu aşamada alanı paylaşmayı seçebilir veya paylaşım ayarlarını yapılandırabilirsiniz

6. Copilot’ın sohbet etkileşimleri sırasında içeriğe başvurabildiğini doğrulayın

Kurumsal kullanıcılar için bir not: Yöneticiniz kişisel Spaces paylaşımını kapatabilir. Bu nedenle kendi hesabınızı kullanıyorsanız, işletmenin depolarını kullanmayan bir Copilot Space’i paylaşma yeteneğinizi etkileyebilir.

Kurulumdan sonra yöneticiler, pratik istemlerle Space’i test etmelidir.

Örneğin:

How does our authentication middleware handle token refresh logic?

Ya da:

Show me an example of how our backend services structure database migrations.

Copilot doğru yanıt veremiyorsa, sorun genellikle şunlardan biridir:

• Eksik depolar
• Zayıf dokümantasyon kalitesi
• Hatalı izinler
• Yetersiz indeksleme süresi

Paylaşım ve erişim kontrolleri

Spaces iki ana görünürlük modelini destekler:

• Bireysel Spaces
• Organizasyon genelinde Spaces

Bir işletmenin üyeleri, bireysel alanlarını daha büyük kurumsal ayarlar tarafından yönetilen şekilde tutabilir. Enterprise yöneticileri ayrıca önizleme ve özellik kullanılabilirliği politikalarını merkezi olarak yönetebilir. 

Özel Spaces, deneysel ekipler veya hassas iç girişimler için iyi çalışır. Organizasyon genelinde Spaces ise mühendislik standartları, onboarding dokümantasyonu veya şirket çapında çerçeveler için mantıklıdır.

Sık gördüğüm bir hata aşırı merkezileştirmedir. Tek, devasa bir şirket geneli Space gürültülü hale gelir ve Copilot’ın etkin biçimde kullanması zorlaşır.

Spaces’i ekibe veya alana göre düzenlemek

Evrensel olarak doğru bir organizasyon yapısı yoktur.

Yaygın kalıplar arasında ekip başına bir alan, ürün alanı başına bir alan veya paylaşılan standart alanlar bulunur. Her biri farklı kapsam taşır ve temelde aynı ayarlar alanını farklı şekilde kullanır.

Ekip başına bir Space

Mühendislik gruplarının nispeten bağımsız çalıştığı durumlarda kullanışlıdır.

Örnekler:

• Platform mühendisliği
• Veri mühendisliği
• Mobil geliştirme

Ürün alanı başına bir Space

Departmanlar yerine ürünler etrafında yapılandırılmış kuruluşlar için uygundur.

Örnekler:

• Ödemeler
• Analitik
• Altyapı
• Müşteri platformu

Paylaşılan standartlar Space’i

Birçok kuruluş aşağıdakiler için ayrı bir paylaşılan Alan tutar:

• Güvenlik yönergeleri
• Kodlama kuralları
• Dağıtım iş akışları
• Mimari standartlar

Uygulamada, hibrit yaklaşımlar genellikle en iyi sonucu verir. Her ekip kendi alanına sahip olurken, daha büyük standart alanlar ekipler arasında paylaşılabilir.

Copilot Usage Metrics API

Spaces bağlam sorununu çözer. Usage Metrics API ise ölçüm sorununu çözer. GitHub’ın 2026 API konsolidasyonu sırasında kullanımdan kaldırdığı birkaç eski telemetri sisteminin yerini aldı. 

Net ölçümler olmadan, kuruluşlar Copilot benimsemesinin başarı durumuna hızla dair görünürlüğünü kaybeder. Liderlik, yatırımın geliştirici iş akışlarını iyileştirdiğine dair kanıt ister; yalnızca bir abonelik kaleminin daha eklenmediğine.

Pano Şubat 2026’da genel kullanıma sunuldu ve kurumsal hesabınız üzerinden Erişim: AI Controls → Copilot → Metrics → Insights sekmesindeki Copilot usage metrics yoluyla erişilebilir.

github.blog’dan Copilot Kullanım Metrikleri Panosu örneği

API neyi ölçer

Usage Metrics API, çeşitli operasyonel telemetri kategorilerini ortaya çıkarır.

Yaygın metrikler şunları içerir:

• Aktif kullanıcılar
• Önerilen kod satırları vs Kabul edilen kod satırları
• IDE kullanım kalıpları
• Model kullanımı
• Aracı etkileşimleri
• Dil dökümleri

Bu, kuruluşlara basit koltuk sayılarından çok daha nüanslı bir tablo sunar.

100 atanmış koltuğu olan ancak yalnızca 15 aktif kullanıcısı bulunan bir ekibin benimseme profili, tutarlı günlük kullanım ve yüksek kabul oranlarına sahip bir ekipten çok farklıdır.

2026 API geçişi

GitHub, 2025’ten 2026’ya geçiş döneminde (Nisan 2026 itibarıyla tamamen kullanımdan kaldırılan) birden çok önceki telemetri API’sini (Kullanıcı düzeyi Özellik Etkileşim Metrikleri API’si, Doğrudan Veri Erişimi API’si, Copilot Metrics API) sonlandırdı.

Bunlar şunları içeriyordu:

• Eski Metrics API
• Feature Engagement API’leri
• Direct Data Access API’leri

Şubat 2026’dan beri mevcut olan daha yeni Usage Metrics uç noktaları, bu raporlama sistemlerini daha birleşik bir modele konsolide etti ve kırıcı değişiklikler durumunda bu API’lerin sürümlenmesini içeriyor.

Bu önemlidir çünkü birçok eski blog yazısı ve GitHub örneği hâlâ kullanım dışı uç noktalara atıfta bulunur. Usage Metrics API ile çalışırken otomasyon oluşturmadan önce dokümantasyonu GitHub’ın en güncel API referanslarına karşı her zaman doğrulayın.

Usage Metrics API Sorgulama

Artık kullanım metrikleri API’sinin amacını anladığımıza göre, bunu pratikte nasıl kullanacağımızı konuşalım.

Kimlik doğrulama ve izinler

GitHub Copilot Usage Metrics uç noktaları genellikle Kişisel Erişim Jetonunuz (PAT) için birkaç izni ayarlamanızı gerektirir. Bu, klasik PAT veya ince taneli PAT üzerinden yapılabilir.

• Klasik PAT’ler için, işletme yöneticinizin size şu izinleri vermesi gerekir: manage_billing:copilot ve read:org. 

• İnce taneli erişim jetonları için, Enterprise Copilot metrics enterprise permissions (read) izin kümesiyle GitHub uygulaması kullanıcı erişim jetonunu veya kurulum erişim jetonunu kullandığınızdan emin olmanız gerekir.

Genellikle gereksiz izin maruziyetini azalttıkları için ince taneli jetonların kullanılması tercih edilir.

Organizasyon düzeyi uç noktalar

En yaygın iki organizasyon düzeyi rapor şunlardır:

• organization-1-day

• organization-28-day

Bir günlük organizasyon düzeyi rapor

Bir günlük rapor, operasyonel izleme ve kısa vadeli trend analizi için iyi çalışır. Geçmiş veriler 10 Ekim 2025’e kadar geriye dönük olarak mevcuttur ve mevcut tarihten itibaren bir yıla kadar erişilebilir.

Aşağıdaki curl komutu, bir günlük rapor metrik API’sini çağırır ve kullanım raporları için indirme bağlantılarını içeren bir JSON yanıtı döndürür. Taşıyıcı kimlik doğrulaması için YOUR_TOKEN değerini eklediğinizden ve rapor için istediğiniz belirli günü YYYY-MM-DD biçiminde DAY olarak seçtiğinizden emin olmanız gerekir.

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

download_links içindeki URL’ler imzalı ve zaman sınırlıdır; bu, alımdan kısa bir süre sonra sona erdikleri anlamına gelir. İş akışınız, indirme URL’sini almalı ve dosyayı aynı çalıştırmada hemen çekmelidir; bu URL’leri daha sonra kullanmak üzere saklayamazsınız.

Aldığınız yanıtta yalnızca download_links ve report_day bulunabilir; ancak tam olası şema şöyledir:

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

28 günlük organizasyon düzeyi rapor

28 günlük rapor, daha geniş benimseme kalıplarını ve daha uzun vadeli kullanım değişimlerini belirlemeye yardımcı olur. Komutlar çok benzerdir; yalnızca 28 günlük API’yi kullanmak için küçük bir değişiklik yapılır.

Örnek istek:

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

Benzer bir yanıt alırsınız; ancak response_start_day ve response_end_day bulunur.

Organizasyon düzeyi rapor yapısı

Hem bir günlük hem de 28 günlük organizasyonel raporlar için JSON raporları aşağıdakine benzer görünebilir:

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

Gördüğünüz gibi bu, belirli bir organizasyondaki kullanıcıların, ekiplerinin ve ekip etiketlerinin yüksek düzeyde bir görünümünü sunar. 

Kullanıcı düzeyi uç noktalar

Kullanıcı düzeyi raporlar daha ayrıntılı benimseme görünürlüğü sağlar. Bu, bireylerin Copilot’ı nasıl kullandığını oldukça yüksek düzeyde anlayabileceğiniz anlamına gelir.

Yaygın uç noktalar şunlardır:

• users-1-day

• users-28-day

• user-teams-1-day

Bu raporlar yöneticilerin şunları belirlemesine yardımcı olur:

• Çok aktif kullanıcılar
• Düşük benimseme gösteren ekipler
• Eğitim fırsatları
• Departman düzeyinde kullanım eğilimleri

Bu istekler, organizasyon düzeyi bir günlük ve 28 günlük raporlara çok benzer; yalnızca farklı bir API’ye işaret ederler.

Bir günlük kullanıcı düzeyi rapor

Örnek users-1-day API çağrısı:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

28 günlük kullanıcı düzeyi rapor

Örnek users-28-day API çağrısı:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

Bir günlük kullanıcı-ekipleri düzeyi rapor

user-teams-1-day uç noktası da mevcuttur ve her kullanıcıyı ekip üyelikleriyle eşler. Kendisinde kullanım metrikleri yoktur; amacı, kullanıcı başına veriyi ekip bazında toplamak istediğinizde bir birleştirme anahtarı görevi görmektir.

Kullanıcı düzeyi rapor yapısı

Bu raporların içindeki detay seviyesi çok daha yüksektir; çünkü belirli bir kullanıcının kullanım verilerine işaret ederler:

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

Bu metrikler, ekip düzeyinde benimseme sinyalleri olarak en değerlisidir. Kabul oranları ve kullanım sayıları operasyonel sinyallerdir; geliştirici kalitesi ölçümleri değildir.

Görebileceğiniz tüm potansiyel metrikler için en güncel ölçülen metrikler adına GitHub kullanım metrikleri veri dokümantasyonunu ziyaret edin.

Kullanıcı düzeyi raporlar CLI etkileşim verilerini içerir. Ekipleriniz Copilot’ı komut satırı üzerinden kullanıyorsa, GitHub Copilot CLI Eğitimi kurulum ve yaygın iş akışlarını kapsar.

Bir Copilot Raporlama İş Akışı Oluşturma

API’yi elle çağırmak, denemeler ve şemayı anlamak için faydalıdır. Eyleme dönüştürülebilir olması için otomatik bir iş akışı oluşturmak daha iyidir.

Copilot Enterprise’dan en çok değer elde eden ekipler genellikle kullanım telemetrisini dahili mühendislik metrikleriyle birleştiren hafif raporlama boru hatları kurarlar.

ROI’yi kanıtlamak için temel metrikler

Her Copilot metriği eşit derecede önemli değildir. En faydalı metrikler genellikle şunlardır:

• Aktif kullanıcı büyümesi
• Kabul oranı eğilimleri
• Önerilen ve elde tutulan kod karşılaştırması
• PR çevrim süresi iyileşmeleri
• IDE etkileşim sıklığı

GitHub şu kıyasları yayınladı:

• Görev tamamlama süresinde %55 hızlanma
• %88 kod tutma oranları

Bu rakamlar önemli verimlilik artışlarına işaret eder. Sonuçlarınız ekip ve iş akışına göre değişecektir; Usage Metrics API’nin var olma nedeni tam da budur. Bir backend altyapı ekibi, bir frontend prototipleme ekibinden farklı şekilde Copilot ile etkileşir.

Ham veriden ekip panosuna

Hafif bir raporlama iş akışı genellikle şu şekilde görünür:

1. Zamanlanmış API çağrısı
2. Yanıtların bir veritabanı veya e-tabloya kaydedilmesi
3. Verinin raporlama tablolarına dönüştürülmesi
4. Mevcut bir BI platformunda metriklerin görselleştirilmesi

Yığının kendisinden çok tutarlılık önemlidir.

Zamanlanmış Python betikleri ve CSV dışa aktarımlarıyla oluşturulan basit bir iş akışı bile faydalı operasyonel görünürlük sağlayabilir.

Örnek mimari:

GitHub API

  ↓

Zamanlanmış Python Betiği

  ↓

PostgreSQL / CSV / E-tablo

  ↓

Power BI / Tableau / Looker

Son Düşünceler

GitHub Copilot Enterprise, aslında yapay zekâya hazır kod için altyapınızı oluşturmaya yöneliktir. Spaces, Copilot’ı gerçek mühendislik ortamlarında daha faydalı kılan kurumsal bağlamı sağlar. Usage Metrics API ise benimsemenin başarılı olup olmadığını anlamak için gereken telemetriyi sunar.

Copilot Enterprise ile en güçlü sonuçları elde eden kuruluşlar benzer bir deseni paylaşma eğilimindedir:

• Dahili bağlamı özenle küratörlüğünü yaparlar
• Benimsemeyi sürekli izlerler
• Copilot yönetişimini ciddiye alırlar
• Verimlilik artışını varsaymak yerine sonuçları ölçerler

Bu zihniyet, yalnızca koltuk atamaktan çok daha fazla önem taşır.

Copilot ve yapay zekâ becerilerinizi derinleştirmek isterseniz, Software Development with GitHub Copilot kursumuzu veya tam AI for Software Engineering beceri yolunu öneririm.