GitHub Copilot’ta “Auto” seçeneği artık tek bir otomatik mod değil. GitHub, 14 Eylül 2026’da otomatik model seçimine üç tercih katmanı ekledi: Efficiency (Verimlilik), Balance (Denge) ve Intelligence (Zekâ). Bu adlar ilk bakışta “ucuz, normal ve güçlü” sıralaması gibi görünebilir. Gerçekte katman, kullanılabilecek model listesini değiştirmiyor; Copilot’un her istemde maliyet, kalite ve yanıt süresine nasıl ağırlık vereceğini belirliyor.

Türkiye’de döviz cinsinden yazılım giderini izleyen ekipler için ayrım önemli. En yüksek kaliteyi seçmek her görevde en pahalı modelin kullanılacağı anlamına gelmediği gibi, Verimlilik de her zaman en ucuz sonucu garanti etmiyor. GitHub’a göre ücretlendirme, seçilen katmana değil Auto’nun gerçekten yönlendirdiği modele göre yapılıyor. Bu nedenle doğru soru “Hangi katman daha iyi?” değil, “Bizim görev karışımımızda hangi katman doğrulanmış sonucu daha düşük toplam maliyetle üretiyor?” olmalı.

Üç katman gerçekten neyi değiştiriyor?

Verimlilik, hızlı ve açık görevlerde maliyeti öne çıkarıyor. Var olan fonksiyona açıklama eklemek, basit bir testi üretmek veya küçük bir yeniden adlandırma yapmak buna uygun örnekler. Denge, maliyet, kalite ve gecikmeyi birlikte değerlendiriyor; günlük geliştirme işlerinin çoğu için başlangıç noktası olabilir. Zekâ ise karmaşık görevlerde kaliteyi öne alıyor. Yine de basit bir istem, Zekâ katmanında bile küçük bir modele yönlendirilebilir.

GitHub’ın açıklamasındaki kritik ayrıntı şu: Her üç katman da aynı kullanılabilir model havuzunu kullanıyor. Kurumsal yönetici politikasıyla engellenen, abonelikte bulunmayan veya veri yerleşimi kuralına uymayan modeller Auto havuzuna girmiyor. Yani katman seçimi, kuruluş politikasını aşan gizli bir model kapısı değil.

Türkiye’de ekip bütçesi için nasıl okunmalı?

GitHub, ücretli planlarda Auto ile oluşan model maliyetinde yüzde 10 indirim uygulandığını belirtiyor. Ancak bu indirim tek başına toplam faturanın düşeceğini kanıtlamaz. Daha pahalı bir model seçilen uzun bir oturum, indirimli olsa da kısa ve basit bir oturumdan daha fazla tüketebilir. Ayrıca kur, vergi ve kurumun GitHub sözleşmesi gibi yerel kalemler ürün duyurusunun dışında kalır.

Bu nedenle ekip raporunda yalnız istem sayısını izlemek yanıltıcıdır. Görevin bittiği kabul edilmeden önce testlerin geçmesi, kod incelemesinde yeniden çalışma çıkmaması ve güvenlik denetiminin tamamlanması gerekir. Yüksek yetenekli modellerde değerlendirme sınırlarını ayrıca ele alan AI güvenlik sınırları rehberi, kalite tercihini risk kontrolüyle birlikte düşünmek için kullanılabilir.

30 görevlik karşılaştırma testi

1. Görevleri üç sınıfa ayırın

On basit, on orta ve on karmaşık görev seçin. Basit gruba dokümantasyon ve küçük test; orta gruba sınırlı hata düzeltme; karmaşık gruba birden fazla dosyayı etkileyen değişiklik koyun. Aynı görevi üç katmanda art arda çalıştırmak yerine benzer zorluktaki görevleri rastgele dağıtın. Böylece önceki yanıtın kullanıcıyı yönlendirmesi gibi öğrenme etkileri azalır.

2. Modeli ve sonucu ayrı kaydedin

GitHub Docs’a göre kullanılan model, Copilot yanıtında görülebilir; arayüze göre yanıtın üzerinde, terminalde veya model seçicinin yanında gösterilir. Her görev için katman, seçilen model, ilk yararlı yanıta kadar süre, ek istem sayısı ve son test durumunu kaydedin. Gizli anahtar, müşteri verisi veya özel depo içeriğini deney tablosuna kopyalamayın.

3. “Tamamlandı” ölçütünü önceden yazın

Bir yanıtın akıcı görünmesi başarı sayılmaz. Birim testleri, linter, tip denetimi ve insan incelemesi geçmeden görevi tamamlandı işaretlemeyin. Güvenlikle ilgili değişikliklerde negatif test ekleyin: Yetkisiz istek gerçekten reddediliyor mu, hata mesajı hassas veri sızdırıyor mu?

Kontrol listesi: Katman seçimi doğru mu?

  • Karşılaştırmada en az 30 benzer görev var mı?
  • Her görevde Auto’nun seçtiği model kaydedildi mi?
  • Maliyet, yanıt sayısıyla değil tamamlanan iş başına ölçüldü mü?
  • Test, güvenlik ve kod inceleme sonuçları hesaba katıldı mı?
  • Kurumsal model politikalarının havuzu daraltıp daraltmadığı kontrol edildi mi?
  • Basit ve karmaşık görevler için farklı varsayılanlar düşünüldü mü?

Hangi katmanla başlanmalı?

Genel amaçlı ekip için Denge makul bir başlangıç noktasıdır; fakat bu bir ürün garantisi değil, ölçülmesi gereken editoryal bir öneridir. Çok sayıda küçük bakım işi yapan ekip Verimlilikten, karmaşık mimari ve hata ayıklama işi yapan ekip ise Zekâdan daha fazla yarar görebilir. En sağlıklı yaklaşım, iki haftalık sabit bir örneklemden sonra tamamlanan görev başına maliyet ve hata oranını birlikte değerlendirmektir.

Sonucu bozan üç yaygın hata

İlk hata, farklı zorluktaki görevleri karşılaştırmaktır. Verimlilik katmanına yalnız küçük işler, Zekâ katmanına yalnız zor işler verilirse maliyet farkının nedeni katman mı görev mi anlaşılmaz. İkinci hata, başarılı görünen ilk kodu kabul etmektir. Testten dönüp üç kez düzeltilen ucuz yanıt, ilk seferde geçen pahalı yanıttan daha maliyetli olabilir. Üçüncü hata ise aynı geliştiricinin tercihlerini sonuç sanmaktır. En az iki incelemeci kullanın ve mümkünse hangi katmanın çalıştığını inceleme sırasında gizleyin.

Haftalık raporda dört sayı yeterlidir: tamamlanan görev, insan düzeltme süresi, başarısız test sayısı ve seçilen modelin tüketimi. Bu tabloya kod satırı veya sohbet uzunluğu eklenebilir; fakat bunlar tek başına değer ölçüsü değildir. Karar eşiğini baştan yazın: Örneğin kalite farkı yoksa düşük maliyetli katman, kritik hata oranı artıyorsa daha güçlü katman seçilsin.

Kaynaklar: GitHub Changelog, 14 Eylül 2026 ve GitHub Docs: Copilot otomatik model seçimi.