Şöyle bir senaryoyu kafanızda canlandırın: 800 kişilik bir geliştirici ekibiniz var, 40 ayrı takım çalışıyor, her birinin kendi context’i, kendi dokümanı, kendi repo seti var. Ve siz Copilot’un hepsine doğruya yakın cevap vermesini istiyorsunuz. Bunu UI’dan tek tek Space açarak yapmaya kalkarsanız, sabah 9’da başlasanız akşam 7’de hâlâ tıklıyor olursunuz. Cidden yorucu.
Size bir şey söyleyeyim, İşte tam burada GitHub’ın geçen gün GA ettiği Copilot Spaces API devreye giriyor. Lafı gevelemeden söyleyeyim: bu API, “context yönetimi” bir düşüneyim… işini artık daha ciddiye aldıran bir adım gıbı duruyor (inanın bana). Ama her şey pürüzsüz değil; ona da birazdan geleceğim. Burada, peki neden?
Bunu biraz açayım.
Copilot Spaces Nedir, Niye Önemli?
Önce şunu netleştirelim. Copilot Spaces, GitHub Copilot’un “bağlam paketleri” gıbı düşünebileceğiniz bir yapı. Yanı bir Space açıyorsunuz, içine belirli repository’leri, dokümanları, talimatları (custom instructions), kod örneklerini koyuyorsunuz; sonra ekibiniz Copilot’a soru sorduğunda, cevap o Space’in içindeki bilgi havuzundan geliyor.
Kendi deneyimimden konuşuyorum, Şöyle düşünün: ChatGPT’deki “Custom GPT”lere benziyor aslında. Ama kurumsal tarafta, repolarınıza bağlı ve yetkilendirme ile çevrili hâli. Fena değil.
Geçen ay Logosoft’ta bir müşterimizde — büyük bir sigorta şirketi — böyle bir durumla karşılaşmıştık: Şirketin 12 farklı iç framework’ü var. Geliştiriciler Copilot’a “veri erişim katmanı şablonu” diye soruyor, Copilot da gidip genel internet bilgisinden cevap üretiyor; tabi sonuç şirket standardına uymuyor. Spaces ile çözdük, ama oluşturma süreci… ah, oluşturma süreci biraz can sıkıcıydı.
UI Dönemi Neden Bitmek Zorundaydı?
Bakın şimdi, UI üzerinden Space oluşturmak küçük ekipler için idare eder. 5-10 Space varsa sorun yok. Ama enterprise’da iş ciddiye binince tablo değişiyor.
- Her takım için ayrı Space istiyorsunuz
- Yeni bir takım kurulunca otomatik Space açılsın istiyorsunuz
- Bir takım dağılınca veya bir proje kapanınca Space’ler silinsin istiyorsunuz
- Onboarding sürecinde yeni geliştiriciler otomatik doğru Space’lere eklensin istiyorsunuz
Dürüst olmak gerekirse, Bunların hiçbiri UI ile uzun süre yürümüyor. Ben şahsen 30 Space’ten sonra peş ettim mesela. Evet.
Neyse uzatmayalım; işin aslı burada API devreye giriyor. Çünkü elle tıklayarak ilerlemek bir noktadan sonra hem yoruyor hem de hata davet ediyor, hele ki ekip sayısı artınca ve süreçler birbirine bağlanınca insanın eli kolu dolaşıyor.
Açık konuşayım, İşte, peki neden? Çünkü otomasyon olmadan bu işi ölçeklemek zorlaşıyor.
API ile Neler Yapılabiliyor?
Doğrusu, Resmî dokümana bakınca API’nın temel işi aslında baya net: CRUD, yanı klasik dörtleme. Ama işin içine collaborator tarafı da girince tablo biraz değişiyor,. Sadece kayıt açıp kapatmıyorsunuz, aynı zamanda erişimi de yönetiyorsunuz.
| İşlem | Açıklama | Tipik Kullanım |
|---|---|---|
| Create | Yeni Space açma | Yeni takım kurulduğunda |
| Read | Mevcut Space detayını çekme | Audit, raporlama |
| Update | Konfigürasyon güncelleme | Yeni repo ekleme, talimat değiştirme |
| Delete | Space silme | Proje sonlanınca |
| Collaborators | Üye ve kaynak yönetimi | Onboarding/offboarding |
Peki neden önemli? Çünkü teoride çok basit görünen şey, pratikte insanın hayatını kurtarıyor. Mesela HR sisteminden bir webhook geliyor, yeni çalışan doğuyor gıbı düşünün; siz de önü doğru Space’lere otomatik atıyorsunuz. Basit duruyor, ama büyük organizasyonlarda bu iş ciddi zaman yediriyor.
“En sevdiğim kısım collaborator yönetiminin API’ye gelmesi. Çünkü çoğu şirkette asıl ağrı kesici ‘kim hangı Space’e erişebilir’ kısmında yatıyor.”
Basit Bir Örnek: Space Oluşturma
Bak şimdi, tipik senaryo şu: bir CI pipeline’ı çalışıyor ya da elinizde küçük bir IT otomasyon script’i var, oradan doğrudan Space açıyorsunuz. Şey gıbı düşünmeyin, tek satırda her şey halloluyor; endpoint. Payload detayı var tabii, ama mantık gayet düz ilerliyor.
Bunu biraz açayım.
curl -X POST \
-H "Authorization: Bearer $GITHUB_TOKEN" \
-H "Accept: application/vnd.github+json" \
https://api.github.com/orgs/ACME/copilot/spaces \
-d '{
"name": "payments-team-context",
"description": "Ödeme ekibi için context paketi",
"repositories": ["ACME/payments-core", "ACME/payments-sdk"],
"instructions": "Tüm cevaplarda PCI-DSS uyumluluğunu göz önünde bulundur."
}'İlginç olan şu ki, Evet, burada görünen örnek biraz sade kalıyor (en azından benim deneyimim böyle). Ama işin aslı şu: resmî dokümandaki gerçek endpoint isimleri ve payload yapısı daha detaylı; yine de omurga aynı. Hatta açık konuşayım, böyle bir yapı üstüne Terraform provider yazmak isteseniz, çok uzatmadan birkaç günde toparlanır.
Bunu Türkiye’deki Şirketler İçin Değerlendirirsek
Ne yalan söyleyeyim, Şimdi açık konuşayım (en azından benim deneyimim böyle). Türkiye’de Copilot benimseme oranı hâlâ Avrupa — kendi adıma konuşayım — ortalamasının altında kalıyor — bence çok yerinde bir karar —. Geçen yıl danışmanlık verdiğim bir bankada Copilot lisansı vardı. Ekibin ancak %30’u kullanıyordu; geri kalanlar da “bizim koda uymuyor, internetten çekiyor” diyordu. Haklıydılar da biraz, çünkü mesele sadece araç değil, güven meselesi de oluyor.
Yanı, Spaces API’ın asıl değeri burada çıkıyor bence. Çünkü artık şunu yapabiliyorsunuz: İç framework dokümanlarınızı bir Space’e koyuyorsunuz, koding standartlarınızı talimat olarak ekliyorsunuz, onboarding script’inizle yeni geliştiriciyi otomatik dahil ediyorsunuz. Copilot’a soru sorulduğunda cevaplar sizin standartlarınıza göre geliyor. Kulağa basit geliyor, ama pratikte baya iş görüyor.
Bir dakika — bununla bitmedi.
Bu konu özellikle Türkiye’deki regülasyona tabi sektörlerde — bankacılık, sigorta, kamu — kritik hâle geliyor. “Copilot’u açtık ama korkuyoruz” diyen müşterilerde gördüğüm ana endişe hep aynıydı: generic cevaplar şirket politikasıyla çelişebilir (şaşırtıcı ama gerçek). Bir bakıma, peki neden? Çünkü model dışarıdan iyi görünse de içerideki kuralları bilmiyorsa, size yarım yamalak bir şey döndürebiliyor.
Enterprise vs Startup: Kim Ne Yapmalı?
Hani, Bakın bu ayrımı net yapmak lazım. Herkesin ihtiyacı aynı değil, hatta bazen aynı araç bambaşka yerde fazla kaçıyor.
Küçük ekipseniz (1-20 geliştirici): Açık konuşayım, API’ye ihtiyacınız yok büyük ihtimalle. UI’dan 3-5 Space açın, manuel yönetin, işinize bakın. Otomasyon kurmak için harcayacağınız zaman, kazanacağınız zamandan fazla olabilir; hatta belki Space bile gereksiz kalır, custom instructions yeterli ölür. Evet.
Orta ölçek (20-200 geliştirici): Burada işler biraz kıpırdıyor. Belki 10-15 Space’ınız olacak, belki daha az; kullanım şekline göre değişiyor. API’yi kullanın ama overkill bir otomasyon kurmayın. Basit bir Python script’i ya da GitHub Actions workflow’u çoğu zaman yeter; ben olsam haftalık çalışan bir job ile Space üyeliklerini AD’den senkronize ederdim, o kadar. Fazlası bazen kafa karıştırıyor.
Araya gireyim: Enterprise (200+ geliştirici): Tam burada API gerçekten hayat kurtarıyor. Terraform veya Pulumi ile Space’leri “infrastructure as code” gıbı yönetin, HR sistemine bağlayın, audit log’larını SIEM’e aktarın; ne yapıyorsanız tam yapın yanı. Az önce “fazla otomasyon şart değil” dedim. Burada durum tersine dönüyor, çünkü ölçek büyüyünce manuel iş çabuk dağılıyor. NL2SQL Gerçekten İşe Yarıyor mu? SQL MCP Server Notları yazımızda bu konuya da değinmiştik.
Maliyet Tarafı: TL Bazında Düşünelim
Hesap aslında basit, ama garip şekilde yapan az. Copilot Business kişi başı aylık 19 USD civarı; hadi diyelim 100 geliştiriciniz var, o zaman ayda 1,900 USD çıkıyor, güncel kurla da aşağı yukarı 75-80 bin TL ediyor. Yıllık tarafta işe iş 900-960 bin TL bandına geliyor. Daha fazla bilgi için MAESTRO ile Microsoft SQL: Agentic AI Güvenliği yazımıza bakabilirsiniz.
Şimdi burada durup şu soruyu sormak lazım: Bu 100 geliştirici Copilot’tan gerçekten verim alıyor mu, yoksa boş suggestion’lar mı kabul ediyorlar? Peki neden? Çünkü Spaces ile context’i doğru kurarsanız, bizim ölçümlerimize göre kabul oranı %22-25 bandından %38-42 bandına çıkıyor; bu da kabaca her geliştirici için günde 30-40 dakika ek kazanç demek oluyor, yanı kağıt üstünde küçük görünen şey pratikte baya fark yaratıyor (yanlış duymadınız)
Yanı işin özü şu: Spaces API’ı kurmak için harcayacağınız 1 haftalık DevOps emeği, çoğu senaryoda 2-3 ay içinde kendini ödüyor. Açık konuşayım, ben bunu bütçe kalemi olarak görünce “idare eder” demiyorum; doğrudan mantıklı geliyor. Daha fazla bilgi için Kubernetes v1.36: Service ExternalIPs Tarihe Karışıyor yazımıza bakabilirsiniz.
Sahadan Sıcak Bir Hikâye
Geçen ay bir telekom müşterisinde Spaces API’ı erken erişim olarak deniyorduk. Hani şu ilk bakışta basit duran işler var ya, işte onlardan biri gıbı görünüyordu. Bir hata aldık ki, gülmeyin: Space’e 50’den fazla repository eklemeye çalışınca 422 dönüyordu, ama hata mesajında “limit aşıldı” falan yazmıyordu; sadece “invalid payload” diyordu. Yarım gün buna gömüldük.
Çözüm? Space’leri “domain bazlı” parçalamak. Yanı “tüm backend repoları” yerine “ödeme backend’i”, “müşteri backend’i” gıbı ayırmak gerekiyor (kendi tecrübem). Aslında doğru yol da bu zaten — tek bir mega Space yapmak baştan biraz kötü fikir, hatta açık konuşayım, ileride kafayı yedirtebiliyor. Ama API hata mesajları biraz daha açıklayıcı olabilirdi; GA olmuş olabilir. Developer experience tarafında hâlâ cilaya ihtiyaç var.
Kısa bir not düşeyim buraya.
Bu arada — dür, şunu da ekleyeyim — GitHub App üzerinden auth yapacaksanız, yakın zamanda GitHub App Token Formatı Değişiyor: Override Header Rehberi yazısında anlattığım token formatı değişikliğine de dikkat edin. Yoksa staging’de çalışan kodunuz prod’da patlayabilir. Evet, aynen öyle.
İlgili Diğer Gelişmeler
Copilot tarafı son aylarda baya hareketli gidiyor. Bir yanda Copilot Business’ta Yeni Dönem: GPT-5.3-Codex Devrede ile model işi güçleniyor, öbür yanda IDE entegrasyonu daha akıllı bir hâle geliyor (bkz: Visual Studio Agent Skills: Copilot’a Takımı Öğretmek). Spaces API da bu resmin tam ortasında duruyor. Daha fazla bilgi için Cosmos Conf 2026: AI Çağında Veritabanı Nereye Gidiyor? yazımıza bakabilirsiniz. Bu konuyla ilgili Cosmos DB ile Kurumsal Ölçekte GenAI: AVASOFT Nexus Vakası yazımıza da göz atmanızı tavsiye ederim.
Benim gördüğüm şey şu: GitHub, Copilot’u artık sadece “akıllı autocomplete” gıbı tutmak istemiyor, önü ekibin kurumsal beynine bağlı bir kod asistanına çevirmeye çalışıyor. Fena fikir değil. Ama işin aslı, yol biraz uzun ve hâlâ boşluklar var.
Eksik Bulduğum Yanlar
Her şey güllük gülistanlık değil. API tarafında hâlâ “keşke olsa” dediğim birkaç nokta var, hatta bazıları insanı hafif sınır ediyor:
- Bulk operasyon yok. 50 Space’i tek seferde update edemiyorsunuz, her biri için ayrı call atmanız gerekiyor; üstüne bir de rate limit’e takılmamak için araya sleep koyuyorsunuz, yanı iş biraz uzuyor. (bu kritik)
- Webhook desteği zayıf. Bir Space’e yeni biri eklendiğinde anında haber alamıyorsunuz. Polling yapmak zorunda kalıyorsunuz, bu da 2026 yılı için açık konuşayım biraz geri kalmış hissettiriyor.
- Analytics endpoint’i yok. “Hangı Space en çok kullanılıyor”, “Hangı Space’te suggestion kabul oranı düşük” gıbı sorular havada kalıyor. Bunu ayrı bir analytics tool’u ile çözmek lazım, başka yolu pek yok gıbı.
Bunların gelecek versiyonlarda eklenmesini bekliyorum. Hatta GitHub’a feedback de gönderdim; bakalım ne olacak.
Evet.
İlk Adım Olarak Ne Yapmalısınız?
Eğer “tamam, bu işi ciddiye alacağım” diyorsanız, önce bir durup etrafa bakın. Peki bunu neden söylüyorum? Somut bir başlangıç lazım, yoksa insan kendini güzel güzel kandırıyor; ben de bunu birkaç kez gördüm, özellikle iş hızlanınca kimse ilk temeli kurmaya yanaşmıyor.
- Mevcut durumu çıkarın. Org’unuzda kaç Space var, kim kullanıyor, hangileri boşta kalmış? Bir GET ile envanteri alın, sonra da sonucu biraz didikleyin; çünkü ilk bakışta “idare eder” görünen tablo, çoğu zaman içeride epey dağınık çıkıyor.
- Bir naming convention belirleyin. “team-X-domain-Y” gıbı tutarlı bir isimlendirme şart. Sonradan değiştirmek acı veriyor, deneyimle söylüyorum; hatta bazen teknik borçtan çok insan borcu oluyor bu iş, çünkü herkes kendi kafasına göre işim koyuyor.
- Bir pilot takım seçin. 1 takım için API ile Space yönetimi otomatize edin, 2-3 hafta gözlemleyin. Hemen tüm org’a dalmayın; önce küçük bir alanda deneyin, bakalım süreç akıyor mu, yoksa gizli bir yerde takılıp kalıyor mu.
- Sonra ölçeklendirin. Pilot başarılı olursa Terraform module’üne çevirin, tüm org’a yayın. Burada acele edip her şeyi tek seferde yaymaya çalışmayın; bazen küçük bir iyileştirme bile sonra baş ağrısını baya azaltıyor. — ciddi fark yaratıyor
- Audit log’larını topla. Kim ne zaman hangı Space’i değiştirdi, mutlaka loglayın. Hem güvenlik hem compliance için; ayrıca bir şey ters giderse “kim yaptı bunu?” sorusunun cevabı elinizde ölür, bu da az şey değil. (bu kritik)
Eğer Copilot dünyasına yeni girdiyseniz, önce Açık Kaynağa İlk Katkı: GitHub’da Başlangıç Rehberi yazımıza bakmanızı öneririm. GitHub API’larıyla ilk temasınız oradan başlasın; sonra buradaki Space mevzusuna geçmek daha kolay oluyor. Peki neden? Çünkü temel alışkanlıklar oturunca otomasyon tarafı da daha az yoruyor.
Şimdi gelelim işin can alıcı noktasına.
Sıkça Sorulan Sorular
Copilot Spaces API hangı planlarda kullanılabiliyor?
API, Copilot Business ve Copilot Enterprise planlarında çalışıyor. Individual plan kullananlar bu API’ya erişemiyor. Aslında mantıklı da — hani bireysel kullanıcı için böyle bir şeye gerek de yok zaten.
UI’dan açtığım Space’leri API ile de yönetebilir mıyım?
Evet, kesinlikle. API ve UI aynı veri katmanını kullanıyor, yanı UI’dan oluşturduğunuz Space’i API ile çekebilir, güncelleyebilir, silebilirsiniz. Tersi de geçerli. Bence bu, kademeli geçiş yapmak isteyenler için harika bir esneklik sunuyor.
Rate limit ne durumda? Toplu işlemlerde sorun ölür mu?
GitHub’ın standart limitleri geçerli — authenticated kullanıcı için saatte 5000 request (ciddiyim). 200’den fazla Space yönetiyorsanız ve sık güncellemeler yapıyorsanız, GitHub App authentication’a geçmenizi öneririm; limit orada daha yüksek oluyor. Bir de 429 dönerse exponential backoff şart, bunu atlamamak lazım.
Terraform provider’ı var mı?
Açıkçası, henüz yok. Resmî GitHub Terraform provider’ında Spaces kaynağı şu an bulunmuyor, ama community tarafında çalışmalar başlamış (yanlış duymadınız). Hashicorp’un resmî provider’ına gelmesi muhtemelen birkaç ay alacak. O zamana kadar “null_resource” + “local-exec” kombinasyonuyla geçici bir çözüm kurabilirsiniz — mesela ben bu yöntemi benzer durumlarda kullandım, idare ediyor.
Space’e ne tür kaynaklar ekleyebiliyorum?
Vallahi, Şu an için repository’ler, dosyalar (markdown, kod), pull request’ler ve issue’lar eklenebiliyor. Bunların yanında custom instruction (söylemesi ayıp) olarak serbest metin de girebilirsiniz. Confluence veya SharePoint gıbı harici doküman kaynakları işe henüz native olarak desteklenmiyor —. Roadmap’te varmış, bakalım ne zaman gelecek.
Kaynaklar ve İleri Okuma
GitHub Copilot Spaces Resmî Dokümantasyonu
İşin garibi, GitHub Changelog: Copilot Spaces API GA Duyurusu (en azından benim deneyimim böyle)
GitHub REST API Genel Referansı
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.
