Yapay zekâ ile kod inceleme

Yapay zekâ kod inceleme araçları

Yapay zekâ kod inceleme araçları iki kampa ayrılır: diff'i kod tabanınıza karşı okuyup üzerine akıl yürüten gerçek bir inceleyici ve desen eşleştirip pull request'i gürültüye boğan, yapay zekâ etiketi takmış bir linter. Önemli olan seçim markası değil; aracın değişikliği anlaması mı yoksa yalnızca taraması mı olduğudur, çünkü gürültülü bir inceleyici ekibinizi her yorumunu görmezden gelmeye alıştırır.

Yapay zekâ kod inceleme araçları iki türe ayrılır ve etiket size hangisine baktığınızı söylemez. Gerçek olanı, diff’i kod tabanınızın bağlamında okur ve değişikliğin sağlam olup olmadığı üzerine akıl yürütür; oyuncak olanı desen kuralları çalıştırır, çıktıya bir “yapay zekâ” etiketi yapıştırır ve pull request başına kırk düşük-değerli yorum bırakır. Önemli olan seçim kutunun üzerindeki marka değil; aracın değişikliği anlaması mı yoksa yalnızca taraması mı olduğudur, çünkü boş yere alarm veren bir inceleyici ekibinize söylediği her şeyi savmayı öğretir.

Gerçek bir yapay zekâ kod inceleme aracını gürültülü olandan ne ayırır?

Sinyal-gürültü oranı; bu da aracın akıl mı yürüttüğüne yoksa desen mi eşleştirdiğine dayanır. Gerçek bir inceleyici çevredeki kodu okur, fonksiyonun niyetini anlar ve bu diff’te gerçekten önemli olan üç şeye yorum yapar. Gürültülü olanı ise bağlamsız jenerik kurallar uygular: seksen karakteri aşan her satırı işaretler, kullanmadığınız bir adlandırma kuralından şikayet eder ve dokunulmamış bir dosyada aynı stil takıntısını yeniden gündeme getirir. Belirti, savma oranıdır; geliştiriciler yorumları okumadan refleksle kapatıyorsa araç çoktan başarısız olmuştur, çünkü yanlış pozitifin maliyeti yorumun kendisi değil, ekibin bir sonraki gerçek yoruma artık vermediği güvendir. Tuttuğumuz disiplin şudur: bir inceleme yorumu okuyucunun dikkatini hak etmek zorundadır; buna saygı duymayan bir araç, logolu gürültüdür.

Bir yapay zekâ kod inceleme aracı gerçekte neyi denetlemeli?

Bir insan inceleyicinin sürdürmekte en kötü olduğu katmanı: tutarlılık, kapsama ve güvenlik ön-taraması. Somut olarak dört şey ağırlığını taşır. Birincisi, kural sapması; bu değişiklik kod tabanının geri kalanının zaten yaptığı şekle uyuyor mu. İkincisi, eksik hata yolları; uzun bir diff’te bir insanın göz gezdirip geçtiği null, başarısız fetch, ele alınmamış reddetme. Üçüncüsü, test boşlukları; yeni dal bir test aldı mı, yoksa kapsama sessizce düştü mü. Dördüncüsü, güvenlik kokusu; sabit kodlanmış bir secret, parametrelenmemiş bir sorgu, doğrulanmamış bir girdi, bir insanın bağlamda değerlendirmesi için yüzeye çıkarılır. Yapmaması gereken şey, mimari veya ürün niyeti hakkında hüküm vermektir; kendi tasarım görüşüyle birleştirmeleri otomatik bloklayan bir araç, incelemenin insana ait olan kısmının sınırını aşar.

Yapay zekâ incelemesinin pull request’i boğmasını nasıl önlersiniz?

Daha az ama daha yüksek-güvenli yoruma ayarlayarak ve kabul döngüsünde bir insan tutarak. Pratik kollar şunlardır: güven eşiğini yükseltin ki araç yalnızca makul ölçüde emin olduğunda konuşsun, tüm dosyayı yeniden incelemek yerine onu değişen satırlara sınırlayın ve bir duvar yerine kısa bir özet artı önemli olan birkaç satır içi yorum bırakmasına izin verin. İlke, herhangi bir yapay zekâ ile yürüyen sürece uyguladığımızın aynısıdır: her yorum ayrı, reddedilebilir bir birimdir ve neye göre hareket edileceğine bir insan karar verir; böylece araç incelemeyi gasp etmek yerine bilgilendirir. Beş keskin yorum bırakan bir inceleyici okunur; elli bırakan susturulur ve susturulmuş bir inceleyici hiç olmamasından daha kötüdür, çünkü yanlış bir kapsama hissi verir.

Benimsemeden önce bir yapay zekâ kod inceleme aracını nasıl değerlendirirsiniz?

Onu bir hafta boyunca gerçek pull request’lerde çalıştırın ve özellik listesini değil iki sayıyı ölçün. Birincisi, savma oranı; yorumlarının ne kadarına geliştiriciler göre hareket etti, ne kadarını okumadan kapattı; kabaca yarısının altında işlem gören bir araç gürültü üretiyordur. İkincisi, yakalama; bir insan inceleyicinin gözden kaçıracağı bir şeyi yüzeye çıkardı mı, onu çalıştırmanın asıl sebebi. Bunun ötesinde, kod tabanınızı koruyan sınırları kontrol edin: kodunuzu gizli mi okuyor yoksa üzerinde eğitim mi yapıyor, bir insan onu her zaman geçersiz kılabiliyor mu ve sınırının kendi tarafında mı kalıyor; mekanik bulgular evet, birleştirmeleri otomatik onaylamak hayır. Araç benimsemeyi, herhangi bir üretim değişikliği gibi ele alırız: her birleştirmenin yoluna oturmadan önce gerçek işte yerini hak ettiğini kanıtlasın.

Bu, inceleme tablosunun bir yarısıdır, yani araçlar. Onu ekibinizin zaten kullandığı platforma bağlamak için GitHub’da yapay zekâ ile kod inceleme sayfasına bakın; daha geniş model için yapay zekâ ile kod inceleme sayfasından başlayın. Aynı mühendislik pod’u bu inceleme disiplini gömülü hâlde yürür: Web / Mühendislik Ekibi kiti.