Kıyaslama: Dört Büyük Yapay Zekâ Kod İnceleme Modeli Aynı Tek Satırlık Güvenlik Hatasını Göremedi

Kıyaslamanın test etmeyi amaçladığı şey

Yapay zekâ kod inceleyicilerine yönelik değerlendirmelerin çoğu modele bir ipucu verir: güvenlikle ilgili bir dosya ya da güvenlik açıklarından bahseden bir prompt. Kudzai Murimi tarafından 30 Eylül 2026'da dev.to'da yayımlanan bir kıyaslama ise tam tersine gidiyor. Sorduğu soru şu: Yapay zekâ inceleyicisi, kimse ona güvenlik hatası aramasını söylemediğinde böyle bir hatayı fark eder mi?

Gönderiye göre test malzemesi on refactoring işleminden oluşuyor — rutin, zararsız temizlikler olarak okunacak şekilde tasarlanmış kod değişiklikleri — ve her biri bir güvenlik sorununu gözler önünde saklıyor. Bu değişiklikler inceleyici rolündeki dört modelin önüne getirildi: Claude Sonnet 5, GPT-5.5, Gemini 3.7 Flash ve DeepSeek-R1. Güvenlikten bahseden bir cümle, kontrol listesi ya da özel talimat yok; sadece bu modellerin gerçek pipeline'larda sürekli aldığı türden sıradan bir inceleme talebi.

Ana sonuç

Dört model de aynı tek satırlık hatayı işaretlemeyi başaramadı. Murimi'nin öne çıkardığı bulgu bu ve ilginç olan yarısı, yapay zekâ inceleyicilerinin başarısız olabilmesi değil, farklı ailelerden dört modelin aynı satırda takılması.

Tek bir üreticinin kör noktası tek bir modelin tuhaflığı olarak görmezden gelinebilir. Claude, GPT, Gemini ve DeepSeek'in paylaştığı bir kaçırma ise yapısal bir şeye işaret ediyor: Mevcut modellerin, diğer farkları ne olursa olsun, zarar bir refactoring kıyafetiyle geldiğinde istikrarlı biçimde geçirdiği bir hata kategorisi.

Kıyaslamanın kamuya açık özeti bu ana sonucu taşıyor. Kalan dokuz refactoring işlemine ilişkin vaka bazında bir döküm, gönderinin akış girdisinde görünen materyalin parçası değildi; bu nedenle buradaki raporlama özetin belirttikleriyle sınırlı kaldı.

Gerçek hikâye korelasyonlu başarısızlık

Mühendislik ekipleri için pratik önem korelasyonda yatıyor. Dört bağımsız inceleyicinin birbiriyle ilgisiz zayıflıkları olsaydı, onları üst üste koymak gerçek bir fazlallık sağlardı: bir modelin kaçırdığı hataları bir diğeri yakalardı. Aynı girdi üzerinde birlikte başarısız olunca, birden fazla model çalıştırmak göründüğünden çok daha az güvenlik satın alıyor.

Gönderi nedenler hakkında spekülasyon yapmıyor ama makul açıklamalardan biri, bu modellerin örtüşen verilerle eğitilmesi ve "temiz" bir değişikliğin nasıl göründüğü konusunda benzer içgüdülere sahip olması. İdiomatik okunan tek satırlık bir düzenleme — insan bir gözlemcinin de kayarak geçeceği türden bir satır — muhtemelen incelenmeye değer bir karar noktası olarak hiç kayda geçmiyor. Başarısızlık biçimi insanunkine benziyor: organik ya da istatistiksel olsun, inceleyiciler olağandışı görünenleri mercek altına alma eğiliminde.

Akılda tutulmaya değer uyarılar

Bu, hakemli bir çalışma değil, küçük ve tek yazarlı bir kıyaslama. On vaka, bir kaçırmanın mümkün olduğunu göstermeye yeter ama ne sıklıkla gerçekleştiğini ölçmeye yetmez. Özet, kullanılan kesin prompt'ları, çıktıların nasıl değerlendirildiğini ya da kaçırılan satırın hangi güvenlik açığı sınıfına ait olduğunu anlatmıyor ve sonuçlar bağımsız olarak tekrarlanmış değil. Bunların hiçbiri bulguyu işe yaramaz kılmıyor — sonuç, bu araçların günlük kullanımdaki davranışıyla tutarlı — ama bu bir veri noktası, bir hata oranı değil.

Neden önemli

Yapay zekâ ile kod incelemesi yenilikten altyapıya kayıyor ve birçok ekip artık bir pull request üzerinde temiz geçen yapay zekâ onayını bir tür yeşil ışık olarak görüyor. Bu kıyaslama, o yeşil ışığın ne anlama geldiğini ve ne anlama gelmediğini hatırlatıyor: kendisine sorulan şeyi güvenilir biçimde yakalayan bir inceleyici, sorulmayanı fark eden bir inceleyiciyle aynı şey değil.

Hayatta kalma ihtimali en yüksek hatalar, sıkıcı görünen değişiklikler aracılığıyla sokulanlar — tam da insan ilgisi en az alan değişiklikler. Birkaç pratik sonuç çıkıyor:

• Yapay zekâ incelemesini insan incelemesinin tamamlayıcısı olarak görün, özellikle güvenliğe duyarlı kod yollarında onun yerine geçen bir kapı olarak değil.
• Belirleyici araçları devrede tutun — statik analiz, linter'lar, secret tarayıcıları, bağımlılık denetimleri — çünkü bu kontroller mekanik olarak çalışır ve bir modelin bağlamı fark etmesine bağlı değildir.
• Yapay zekâ inceleyicilerine açık bir güvenlik kontrol listesiyle prompt veriyorsanız, kıyaslamanın öncülünü hatırlayın: gerçek hatalar hangi kategoriye ait olduklarını duyurmaz.
• Refactoring pull request'lerine özellik işleriyle aynı titizliği gösterin. "Sadece bir temizlik" ifadesi, tam olarak test vakalarının istismar ettiği örtü.

Daha geniş ders güven kalibrasyonuyla ilgili. Model aileleri arasındaki korelasyonlu kör noktalar, ikinci ya da üçüncü bir yapay zekâ inceleyicisi eklemenin ekiplerin içgüdüsel olarak varsaydığından daha zayıf bir sigorta olduğu anlamına geliyor ve geride bırakılan boşluk, tam da insan inceleyicilerin gevşediği yerde en geniş oluyor.