GitHub Copilot kod incelemesi artık pull request'leri onaylayabiliyor; görev ayrılığı endişeleri büyüyor

Bir dev.to mühendislik yazısında öne çıkarılan bir changelog kaydına göre GitHub, Copilot kod incelemesini yalnızca yorum bırakmak yerine pull request'leri resmen onaylayabilecek şekilde genişletti. Bu yetenek bir sürüm notunda küçük görünebilir, ancak yapay zeka çıktısını tavsiye alanından kodun yayınlanıp yayınlanmayacağına karar veren denetim mekanizmalarının içine taşıyor.

Yorumdan merge kontrolüne

Üretim sistemlerinden sorumlu mühendislere seslenen dev.to yazarı, iki fiil arasında keskin bir çizgi çekiyor. İnceleme yorumu bir öneridir; onay ise branch protection'a, zorunlu inceleme sayılarına, denetim kayıtlarına, deployment kapılarına ve paket yayınlamaya katılır. Bir Copilot onayı zorunlu bir incelemeye sayılabildiği anda araç bir triage sinyali olmaktan çıkıp ekiplerin merge düğmesinin çevresine kurduğu sınırın parçası haline geliyor. Yazar, Copilot'a sıradan bir inceleyiciymiş gibi davranmanın bu değişimi küçümsediğini savunuyor ve onu, süreçteki diğer her katılımcı gibi yönetilmesi gereken yeni bir merge ilkel bileşeni olarak tanımlıyor.

Makine onayının kabul edilebileceği yerler

Yazı yapay zeka incelemesine karşı bir argüman değil. Yazar onu linter'lar, statik analiz ve iyi bir test çıktısına benzetiyor: insanlar dikkatini harcamadan önce bariz sorunları yakalamada faydalı. Yapay zeka onaylarının sayılabileceği makul adaylar arasında üretilmiş dokümantasyon, test-fixture güncellemeleri, yalnızca biçimlendirme içeren değişiklikler ve derleyici, testler ile sahiplik kurallarının zaten güçlü kanıt sunduğu mekanik refactor'lar yer alıyor. Şart şu: yapay zeka onayı bir kanıt parçası olarak hizmet etmeli, asla bir merge'un tek temeli olmamalı.

Başarısızlık senaryosu

Yazarın çizdiği tehlikeli senaryo şöyle: bir agent bir değişiklik yazıyor, benzer bir agent onu inceliyor, CI ya test paketi zayıf olduğu ya da diff, testleri çalıştıran workflow'u düzenlediği için geçiyor, onay sayılıyor ve kod bağımsız inceleme görünümüyle merge ediliyor. Yazar bunu "otomasyon aklama" (automation laundering) olarak adlandırıyor. Önerilen ilk politika, Copilot onaylarının merge kurallarını karşılamaması gereken hassas yollara ilişkin bir denylist: deployment workflow'ları, kimlik doğrulama ve yetkilendirme kodu, ödeme ve faturalandırma mantığı, para hareketi ve mutabakat, secret yönetimi, CI ve sürüm otomasyonu, bağımlılık manifest'leri ve lockfile'lar, infrastructure as code, paket yayınlama yapılandırması, olay müdahale araçları ve güvenlik taraması politikası. Copilot bu alanlarda hâlâ yorum yapıp açıklama sunabilir; sadece onayı veren taraf olamaz.

Bağlam dışı bırakmalar onay politikasının parçası oluyor

Yazıya göre GitHub ayrıca Copilot uygulaması ve CLI için içerik dışı bırakmaları (content exclusions) genel kullanıma sundu; yazar bunu hassas dosyaları agent bağlamından uzak tutmak açısından iyi bir şey olarak görüyor. Ama bu yeni bir yükümlülük doğuruyor: ilgili dosyaları okumasına izin verilmemiş bir inceleyicinin onayı daha zayıf bir kanıttır. Yazar, politika dosyalarını veya entegrasyon testlerini açması yasakken bir kimlik doğrulama refactor'unu onaylayan insan örneğini veriyor. Argümana göre onay politikası yalnızca hangi dosyaların değiştiğini değil, onaylayan kişinin hangi dosyaları inceleme yetkisi olduğunu da kaydetmeli.

CI otomatik olarak bağımsız değil

Yazıya göre Copilot onaylarını yeşil bir CI koşusuna bağlamak gerekli ama yeterli değil. CI, yalnızca pull request onu sınırlaması amaçlanan kontrolleri ucuz yoldan etkileyemediğinde bağımsız kanıt sayılır; örnek olarak workflow dosyalarına, yeniden kullanılabilir workflow referanslarına, derleme betiklerine, bağımlılık kurulumuna, test seçimine veya artifact yayınlamaya yapılan düzenlemeler verilebilir. Yazar, GitHub Actions sorunları için daha hassas CodeQL tespiti, daha net yeniden kullanılabilir workflow kimlik bağlamı, güvenilmeyen tetikleyiciler için en az ayrıcalıklı izinler ve salt-okunur cache token'ları gibi ilgili GitHub değişikliklerini doğru model olarak gösteriyor: otomasyonun güven sınırları var ve yapay zeka onayları bunların üzerinde değil, bunları miras almalı.

Yazarın pazarlıksız diye adlandırdığı kural

Bir agent, aynı sınıftan bir agent'ın öncelikli olarak yazdığı bir pull request'i onaylayamaz; yani agent'in değişikliği planladığı, dosyaları düzenlediği, testleri yazdığı ve PR'ı açtığı durumda. Yazar, bunun geliştiricilerin bütün gün kullandığı sıradan otomatik tamamlama veya sohbet yardımıyla ilgili olmadığını açıklıyor.

Neden önemli

Zorunlu incelemeler bir hesap verebilirlik mekanizmasıdır: bir değişikliği kimin incelediğini, riski kabul edecek bağlama kimin sahip olduğunu ve yazardan kimin bağımsız olduğunu kaydederler. Bir yapay zeka onayı bu kuralları karşılayabildiği anda, bu kuralların kodladığı sorumluluğu da devralır. Bu yeteneği etkinleştiren ekipler, makine onaylarının nerede geçerli olacağına varsayılanla değil politika ile karar vermeli: hangi yollar yalnızca insana kalacak, agent yazımı değişikliklerin her zaman insan inceleyicisi gerektirecek mi ve yapay zeka onaylayıcısı onayladığı kodu gerçekten okuyabilmiş mi. Aksi halde, kaydırmalı incelemelerin yükünü kaldırmak, bu incelemelerin var olduğu bağımsız denetimi de ortadan kaldırır.