GitHub Copilot Code Review: Lite mı Balanced mı? Hangi PR için hangisi?

GitHub Copilot Code Review artık iki inceleme eforu sunuyor: Lite ve Balanced. GitHub'ın tanımında Lite hızlı ve hedefli bir standart inceleme; Balanced ise daha yüksek reasoning kullanan, daha uzun ve derin bir inceleme.[1][2]

Kısa cevap: metin, stil, küçük UI düzeltmesi ve dar kapsamlı bug fix için Lite ile başla. Yetkilendirme, ödeme, veri taşıma, eşzamanlılık veya birden fazla servise yayılan değişiklikte Balanced seç. PR büyüklüğüne tek başına bakma. Yanlışın etkisi ve değişikliğin kaç sınırı geçtiği daha iyi bir karar ölçüsü.

Lite ve Balanced arasındaki gerçek fark

GitHub'ın ürün dokümanına göre Lite yaygın bug, güvenlik açığı ve stil tutarsızlıklarına odaklanan varsayılan seçenek. Balanced ise karmaşık mantık, güvenlik açısından hassas kod ve servisler arası değişiklikler için daha yüksek reasoning modeline yönlendiriliyor.[1] Bu, seçebildiğin iki model adı değil. Copilot Code Review altında iki analiz derinliği.

Modeli ayrıca seçemiyorsun. GitHub, Code Review'un ayarlanmış bir model, prompt ve sistem davranışı karışımı kullandığını; manuel model değiştirmenin desteklenmediğini söylüyor.[1] Dolayısıyla "Balanced + belirli bir model" diye sabit bir kombinasyon kurmak mümkün değil. Belirli modeli görev bazında seçmek istiyorsan bu, Code Review'dan farklı bir karar katmanı. Copilot model seçim rehberi o katmanı ele alıyor.

Göreve göre seçim tablosu

• README, metin, CSS, küçük görsel düzeltme: Lite.
• Tek modülde açık kabul kriterli bug fix: Lite.
• Mevcut kalıbı izleyen test veya refactor: Lite; diff beklenmedik yere yayılırsa Balanced.
• Kimlik doğrulama, yetkilendirme, ödeme veya kişisel veri: Balanced.
• Şema değişikliği, veri taşıma, eşzamanlılık veya cache invalidation: Balanced.
• Birden fazla servis, paket ya da API sözleşmesini etkileyen PR: Balanced.
• Büyük ama mekanik dosya taşıma: önce Lite; büyüklük tek başına Balanced nedeni değil.
• Küçük ama üretim erişimini değiştiren config: Balanced; satır sayısı düşük riski düşük yapmaz.

Bu tablo benim yönlendirme önerimdir, GitHub'ın başarı benchmarkı değildir. GitHub yalnız kullanım alanlarını tanımlıyor; depon için doğruluk oranı yayımlamıyor.

Lite ne zaman yeterli?

Lite'ın iyi olduğu işte hata yüzeyi dardır ve kontrol yolu açıktır. Tek bileşende metin düzenlemek, mevcut test kalıbına bir vaka eklemek veya sınırı belli bir null kontrolünü düzeltmek buna girer. İnceleme hızlı gelir; GitHub dokümanı, isteklerin genellikle 30 saniyeden kısa sürdüğünü belirtiyor.[2]

Yine de "Lite bulmadı, sorun yok" sonucu çıkmaz. Code Review bazı dosyaları incelemiyor; GitHub örnek olarak dependency management dosyalarını, logları ve SVG'leri sayıyor.[1] PR bunlardan birini değiştiriyorsa ayrı bir insan veya araç kontrolü gerekir.

Balanced ne zaman parasını hak eder?

Yanlışın etkisi yüksekse ya da değişiklik birden fazla sistem sınırını geçiyorsa Balanced daha mantıklı. GitHub da güvenlik hassasiyeti, çok servisli PR'lar ve sıkı kalite standardı olan depolar için Balanced öneriyor.[1]

Balanced'ı "daha büyük PR" düğmesi gibi kullanmazdım. Bin satırlık mekanik rename kolay doğrulanabilir; sekiz satırlık yetki kontrolü ise ciddi risk taşıyabilir. Seçimi diff boyutundan önce şu üç soruya bağla:

1. Yanlış değişiklik hangi kullanıcıya veya veriye zarar verir?
2. Değişiklik kaç servis, paket, şema ya da güven sınırını geçiyor?
3. Test kaçışı olursa üretimde geri alma ne kadar zor?

Sorulardan biri kötü bir cevaba gidiyorsa Balanced ile başlamak, sonradan ikinci inceleme istemekten daha temiz olabilir.

Maliyet farkı ne kadar?

GitHub'ın tahminine göre tek inceleme Lite'ta 0,05-1 ABD doları, Balanced'da 0,25-5 ABD doları değerinde AI credit tüketiyor. PR boyutu ve repository talimatları tüketimi artırabiliyor; GitHub Actions dakikaları bu aralıklara dahil değil.[1] Bunlar GitHub'ın ürün tahminleri, sabit fiyat garantisi değil.

Her push'ta otomatik yeniden inceleme açıksa küçük iterasyonlar da yeni tüketim üretir. GitHub, her incelemenin AI credit kullandığını ve agentic bağlam toplama için ayrıca Actions dakikası oluşabileceğini belirtiyor.[1] Solo bir depoda makul varsayılan şu olabilir: rutin PR'larda otomatik Lite, riskli PR'da elle Balanced, merge öncesi yalnız ciddi değişiklik olduysa yeniden inceleme.

Otomatik mi, manuel mi?

GitHub'ın yaşam döngüsü rehberi manuel incelemeyi yüksek bağlamlı veya seçici kullanım için; otomatik incelemeyi ise geniş ve tutarlı kapsama isteyen ekipler için öneriyor.[4] Yeni push'larda otomatik tekrar, sık değişen PR'larda güncel geri bildirim sağlıyor; fakat her küçük push'ta maliyet ve yorum gürültüsü de büyüyebilir.

Solo builder için pratik kural:

• Her PR açılışında Lite çalıştır.
• Risk etiketi taşıyan PR'larda ilk incelemeyi Balanced yap.
• Yalnız mantık veya güvenlik davranışı değiştiyse yeniden incele.
• Format, yorum veya merge conflict düzeltmesi için otomatik tekrar isteme.

GitHub, tekrar incelemede daha önce kapatılmış bazı yorumların yinelenebileceği uyarısını da yapıyor.[2] Bu yüzden "her push'ta review" seçeneğini alışkanlıkla değil, PR akışına göre aç.

Talimat dosyası, effort seviyesinden daha fazla fark yaratabilir

Balanced kötü bağlamı sihirli biçimde düzeltmez. GitHub Code Review; `.github/copilot-instructions.md`, path-specific instruction dosyaları, `AGENTS.md` ve bazı diğer ajan talimat dosyalarından yararlanabiliyor.[1][2] İnceleme kriterlerini kısa ve ölçülebilir yaz: değiştirilmemesi gereken sözleşmeler, zorunlu testler, güvenlik sınırları ve bilinen mimari istisnalar.

Önce AGENTS.md, CLAUDE.md ve GEMINI.md seçim rehberindeki kalıcı bağlam ayrımını kur. Sonra effort seviyesini yükselt. Belirsiz kuralları Balanced'a vermek, daha uzun ama yine yanlış yorum üretebilir.

Yorumları nasıl doğrulamalısın?

GitHub, yeni overview görünümünde bulguları açık, son incelemeden beri çözülmüş ve daha önce kaçırılmış olarak grupluyor; her bulguda önem seviyesi ve ilgili yoruma bağlantı gösteriyor.[3] Bu görünüm takip işini kolaylaştırır, fakat Copilot yorumunu kanıt yapmaz.

Her önemli bulgu için şu sırayı kullan:

1. Yorumun işaret ettiği satırı değil, ilgili çağrı zincirini oku.
2. Bulguyu yeniden üreten test veya statik analiz kontrolü çalıştır.
3. Önerilen yamayı toplu kabul etmeden diff'i incele.
4. Düzeltmeden sonra davranış değiştiyse yeniden inceleme iste.
5. Son kararı insan review ve CI sonucuyla ver.

Daha ayrıntılı kapanış sırası için kodlama ajanı çıktısını doğrulama kontrol listesine geç. Buradaki Lite-Balanced seçimi o doğrulamayı azaltmıyor; yalnız ilk inceleme bütçesini nereye ayıracağını belirliyor.

GPT-5.6 seçimiyle karıştırma

Code Review effort seviyesi ile model seçimi aynı düğme değil. Sol, Terra ve Luna arasında hız, maliyet ve derinlik kararı arıyorsan GPT-5.6 Sol-Terra-Luna ana rehberi doğru başlangıç. Bu yazı o karşılaştırmayı tekrarlamıyor; PR incelemesinde Lite mı Balanced mı sorusunu cevaplıyor.