Yapay zekâ destekli kod incelemesinde en tehlikeli an, bir yorumun yazılması değil kapanmasıdır. GitHub, 11 Eylül 2026’da Copilot code review için önemli bir davranış değişikliği duyurdu: daha sonraki bir commit uyarının temelindeki sorunu giderirse Copilot, yeniden inceleme sırasında kendi yorumunu otomatik olarak çözümlenmiş sayabiliyor. Aynı güncellemeyle öneri uygulandığında daha anlamlı commit mesajları üretiliyor; inceleme ajanı da kodu doğrulamak için daha geniş bir kabuk aracı kümesi kullanıyor.

Bu yenilik yorum kalabalığını azaltabilir. Fakat “çözümlendi” etiketi, insan gözüyle onaylanmış bir güvenlik garantisi değildir. GitHub’ın kendi belgesine göre kod incelemesi farklı dillerde çalışsa da bazı dosyalar kapsam dışındadır; bağımlılık dosyaları, günlük dosyaları ve SVG’ler incelenmez. Ayrıca ajan yetenekleri çalışmasa bile inceleme üretilebilir, yalnız ek bağlam ve araç kullanımı devre dışı kalır. Dolayısıyla doğru soru “Copilot yorumu kapattı mı?” değil, “kapanan yorumun gerekçesi gerçekten ortadan kalktı mı?” olmalıdır.

11 Eylül güncellemesi tam olarak ne değiştirdi?

Yorumlar yeniden incelemede otomatik kapanabiliyor

Bir geliştirici yeni commit gönderdiğinde ve bu commit Copilot’ın önceki yorumunda işaret ettiği sorunu giderdiğinde, ilgili tartışma yeniden inceleme sırasında otomatik olarak çözümlenebiliyor. GitHub, giderilmeyen geri bildirimin açık kalacağını söylüyor. Bu, büyük pull request’lerde artık geçerli olmayan uyarıları elle kapatma yükünü azaltır; aynı zamanda ekibin açık yorum listesini “kalan işler” görünümüne yaklaştırır.

İnceleme yalnız dosya okumakla yetinmiyor

GitHub’ın duyurusuna göre Copilot SDK içindeki kabuk araçları; derleme komutları çalıştırma, test koşturma ve hedefli betikleri yürütme gibi ek doğrulamalar için kullanılabiliyor. Bu araçlar Copilot ajan güvenlik duvarının arkasında çalışıyor. Lite inceleme düzeyinde tek bir ajan yerine farklı bakışları birleştiren ajan topluluğu kullanılıyor.

Şirketin deneylerinde giderilen yorumların ortalama sayısı yüksek önem düzeyinde yüzde 47, orta düzeyde yüzde 31 ve düşük düzeyde yüzde 11 artarken inceleme maliyeti yaklaşık yüzde 8 azalmış. Bunlar GitHub’ın kendi deney sonuçlarıdır; her depo, dil ve ekipte aynı sonucu garanti eden bağımsız bir ölçüm değildir.

Otomatik kapanan yorumu nasıl sınarsınız?

1. Bilerek küçük ve ölçülebilir bir hata seçin

Üretim koduna yapay açık eklemeyin. Ayrı bir deneme dalında, örneğin sınır koşulunda başarısız olan güvenli bir birim testi veya eksik null kontrolü oluşturun. Pull request açıklamasına beklenen davranışı yazın. Copilot’ın yorumunun dosya, satır ve risk gerekçesini doğru tanımlayıp tanımlamadığını not edin.

2. En küçük düzeltmeyi gönderin

Yalnız işaret edilen sorunu gideren tek bir commit gönderin. Yeniden incelemeden sonra yorum otomatik kapandıysa diff’i açın ve üç kanıt arayın: başarısız test artık geçiyor mu, yeni bir yan etki oluşmuş mu ve yorumda tarif edilen koşul gerçekten kapsanıyor mu? Commit mesajının güzel görünmesi bu üç kontrolün yerine geçmez.

3. Negatif kontrol kullanın

İkinci bir denemede hatayı çözmeyen, yalnız değişken adını değiştiren bir commit gönderin. Yorumun açık kalması gerekir. Sistem bu durumda da yorumun çözüldüğünü düşünüyorsa otomatik kapanmayı ekip için güvenilir sinyal kabul etmeyin; insan onayını zorunlu bırakın ve örneği GitHub’a geri bildirin.

4. Kapsam dışı dosyaları listeleyin

GitHub Docs; package.json gibi bağımlılık yönetimi dosyalarını, kilit dosyalarını, logları ve SVG’leri kapsam dışı örnekler arasında sayıyor. Bir pull request bu dosyalarda kritik değişiklik taşıyorsa “Copilot yorum bırakmadı” sonucunu “sorun yok” diye okumayın. İnsan incelemeciyi veya ayrı güvenlik aracını sahip olarak atayın.

Türkiye’deki küçük ekip için kabul ölçütü

Beş gerçek pull request seçin ve iki hafta boyunca dört sayı tutun: Copilot’ın açtığı yorum, geliştiricinin giderdiği yorum, yanlış kapanan yorum ve insan incelemesinin sonradan bulduğu önemli sorun. Saatlik maliyeti TL ile hesaplayan ekipler için kazanım, yalnız kapanan yorum sayısı değildir; yeniden açılan iş ve üretim hatası azalmıyorsa otomasyon süre kazandırmıyor olabilir.

Ölçümü, daha önce ele aldığımız AI ajanı verimlilik testindeki “çıktı sayısı yerine doğrulanmış sonuç” yaklaşımıyla birleştirin. Ayrıca sır veya erişim anahtarı içeren değişikliklerde kod incelemesini tek savunma hattı yapmayın; anahtarı iptal etme ve kullanım kayıtlarını inceleme ayrı süreçlerdir.

Uygulanabilir kontrol listesi

  • Denemeyi üretimden ayrı bir dalda ve geri alınabilir örnekle yapın.
  • Bir pozitif, bir negatif kontrol hazırlayın.
  • Otomatik kapanan her yorum için diff, test ve yan etki kanıtını inceleyin.
  • Kapsam dışı dosyaları pull request şablonunda açıkça işaretleyin.
  • Güvenlik hassas değişikliklerde insan onayını zorunlu tutun.
  • GitHub’ın deney sayılarını kendi depo verinizle doğrulamadan hedef kabul etmeyin.

Sonuç: temiz liste, temiz kod demek değildir

Copilot’ın kendi yorumlarını doğru zamanda kapatması, inceleme ekranındaki gürültüyü azaltan yararlı bir ilerleme. Kabuk araçları ve birden fazla ajanın birleşimi de daha güçlü kanıt üretme potansiyeli taşıyor. Yine de otomatik çözüm, sorumluluğu makineye devretmez. En güvenli kullanım; küçük bir kabul testi, negatif kontrol ve insanın doğruladığı merge kapısıyla başlar.

Kaynaklar: GitHub Changelog, 11 Eylül 2026; GitHub Docs, Copilot code review.