Yapay zekâ, kod incelemesini hızlandırabilir; ancak güvenlik, performans ve geriye dönük uyumluluk gibi konularda tek başına nihai karar verici olmamalıdır. En iyi sonuç, yapay zekâyı kanıt isteyen, kapsamı sınırlandırılmış ve insan tarafından doğrulanan bir inceleme sürecine dâhil ederek alınır.

1. İnceleme Öncesi Kapsamı Netleştirin

Yapay zekâya doğrudan tüm projeyi vermek yerine incelemeyi küçük ve anlamlı parçalara ayırın. Önce değişikliğin amacını, etkilenen bileşenleri ve kabul kriterlerini belirtin.

• İncelenecek dosya, fonksiyon veya değişiklik aralığını açıkça yazın.
• Kullanılan dil, framework, sürüm ve çalışma ortamını belirtin.
• Beklenen davranışı ve değişmemesi gereken davranışları açıklayın.
• Performans hedefleri, desteklenen işletim sistemleri veya API sürümleri gibi kısıtları ekleyin.
• Gizli anahtar, parola, kişisel veri ve üretim loglarını inceleme girdisine koymayın.

Örneğin “Bu kodu kontrol et” yerine şu kapsam daha kullanışlıdır: “Java 21 ve Spring Boot 3 kullanan bu servis, mevcut REST yanıt formatını değiştirmeden kullanıcı araması yapıyor. Yalnızca güvenlik, sorgu performansı ve geriye dönük uyumluluk risklerini incele; kanıt bulunmayan durumları bulgu olarak yazma.”

2. Beş Kontrol Alanını Ayrı Ayrı İnceleyin

Tek bir genel değerlendirme, önemli bulguların gözden kaçmasına veya düşük öncelikli önerilerin öne çıkmasına neden olabilir. İncelemeyi aşağıdaki başlıklara bölmek daha tutarlı sonuç verir.

Güvenlik

Öncelikle kullanıcı girdisinin nereden geldiğini, nasıl doğrulandığını ve hangi güven sınırlarından geçtiğini kontrol edin.

• SQL, komut, şablon, HTML veya dosya yolu enjeksiyonu ihtimali var mı?
• Yetkilendirme kontrolü, yalnızca arayüzde değil sunucu tarafında da uygulanıyor mu?
• Kimlik doğrulama, oturum ve hata mesajları hassas bilgi sızdırıyor mu?
• Gizli bilgiler kaynak koduna, loglara veya istemciye taşınıyor mu?
• Dosya yükleme, serileştirme, yönlendirme ve dış servis çağrıları güvenli mi?
• Kullanılan bağımlılıkların sürüm veya yapılandırma kaynaklı bilinen riskleri var mı?

Yapay zekâdan her güvenlik uyarısı için saldırı senaryosu, etkilenen kod satırı ve düzeltme önerisi istemek yanlış pozitifleri azaltır.

Performans

Performans incelemesinde varsayımsal “bu daha hızlıdır” ifadeleri yerine maliyetin nerede oluştuğu araştırılmalıdır.

• Gereksiz döngü, tekrar hesaplama veya büyük veri kopyalama var mı?
• Veritabanı sorgularında N+1 sorgu, eksik filtre veya uygun olmayan indeks kullanımı görülüyor mu?
• Ağ çağrıları seri hâlde mi çalışıyor, zaman aşımı ve yeniden deneme politikası tanımlı mı?
• Önbellek kullanımı tutarlı mı; eski veya yanlış verinin dönmesi mümkün mü?
• Bellek tüketimi, eşzamanlılık ve yoğun trafik altında davranış nasıl değişiyor?

Kodun gerçek performansını ölçüm olmadan kesin biçimde değerlendirmeyin. Yapay zekâdan önce riskli noktaları belirlemesini, ardından hangi metrik veya benchmark ile doğrulanacağını yazmasını isteyin.

Okunabilirlik ve Bakım Kolaylığı

Okunabilirlik yalnızca kısa kod yazmak değildir. İsimlendirme, sorumlulukların ayrılması ve hata akışının anlaşılır olması birlikte değerlendirilmelidir.

• Fonksiyonlar tek bir amaca hizmet ediyor mu?
• Değişken ve metot isimleri işlevi doğru yansıtıyor mu?
• Karmaşık koşullar, tekrar eden kod veya gereksiz soyutlamalar var mı?
• Hata yönetimi sessizce başarısız oluyor veya asıl problemi gizliyor mu?
• Yorumlar kodun ne yaptığını tekrarlamak yerine nedenini açıklıyor mu?

Salt biçim tercihlerinin güvenlik veya hata gibi raporlanmasını önlemek için stil kurallarını ayrı bir kontrol olarak ele alın.

Test Kapsamı

Bir değişiklik için yalnızca mevcut testlerin varlığı yeterli değildir. Değişen davranışın sınırları ve başarısızlık durumları da test edilmelidir.

• Normal akış, boş veri, hatalı veri ve sınır değerler test edilmiş mi?
• Yetkisiz erişim, zaman aşımı, bağımlılık hatası ve tekrar deneme durumları ele alınmış mı?
• Mevcut testler yeni davranışı gerçekten doğruluyor mu, yoksa yalnızca kodun çalışmasını mı kontrol ediyor?
• Mock kullanımı gerçek entegrasyon sorunlarını gizliyor olabilir mi?
• Değişikliğin etkilediği eski senaryolar için regresyon testi var mı?

Yapay zekâdan doğrudan test yazmasını istemeden önce eksik senaryoları listelemesini isteyin. Üretilen testler daha sonra proje standartları ve gerçek iş kurallarıyla karşılaştırılmalıdır.

Geriye Dönük Uyumluluk

Uyumluluk, yalnızca derleme hatası oluşup oluşmadığıyla ölçülmez. API sözleşmeleri, veri formatları, hata kodları ve kullanıcı beklentileri de dikkate alınmalıdır.

• Mevcut public metotların imzası veya davranışı değişti mi?
• API yanıt alanları, veri tipleri ve hata kodları korunuyor mu?
• Veritabanı şeması eski uygulama sürümüyle birlikte çalışabilir mi?
• Yapılandırma anahtarları, ortam değişkenleri ve varsayılan değerler değişti mi?
• Eski istemciler yeni sunucuya, yeni istemciler eski sunucuya bağlandığında ne olur?
• Mesaj kuyrukları, dosya formatları veya dış entegrasyon sözleşmeleri etkileniyor mu?

Uyumluluk riski varsa yapay zekâdan geçiş planı, sürümleme yaklaşımı veya geriye dönük destek önerisi isteyin; fakat önerinin proje politikalarıyla doğrulanması gerekir.

3. Yanlış Pozitifleri Azaltan Prompt Tasarımı

İyi bir prompt yalnızca “hata bul” demez. Kanıt standardını, önceliklendirmeyi ve belirsizlik durumunda izlenecek yolu açıkça tanımlar.

Genel inceleme promptu



Güvenlik odaklı prompt



Performans odaklı prompt



Test ve uyumluluk odaklı prompt



4. Çıktıyı Kanıt ve Öncelik Açısından Filtreleyin

Yapay zekâ çıktısını doğrudan görev listesine çevirmek yerine her bulguyu şu sorularla değerlendirin:

• Bulgu belirli bir dosya, satır veya akışla ilişkilendirilebiliyor mu?
• Sorun, projenin gerçek çalışma koşullarında oluşabilir mi?
• Gözlemin etkisi önem derecesiyle uyumlu mu?
• Önerilen düzeltme mevcut davranışı gereksiz yere bozuyor mu?
• Bulguyu birim testi, entegrasyon testi, statik analiz veya benchmark ile doğrulamak mümkün mü?

Kanıtı zayıf önerileri hemen uygulamak yerine “incelenecek” olarak işaretleyin. Aynı uyarının farklı ifadelerle tekrarlanması da sonuçların kalitesini düşürür; benzer bulguları tek başlık altında birleştirin.

5. İnsan Doğrulaması ve Uygulama Sırası

Pratik bir inceleme akışı şu şekilde kurulabilir:

• Değişiklik amacını ve etkilenen alanları okuyun.
• Yapay zekâdan önce ayrı güvenlik, performans ve uyumluluk değerlendirmeleri alın.
• Dosya ve satır bilgisi bulunan bulguları önem derecesine göre sıralayın.
• Kritik ve yüksek riskli maddeleri geliştirici veya alan uzmanıyla doğrulayın.
• Gerekli düzeltmeleri küçük commit’ler hâlinde uygulayın.
• Testleri, statik analizleri ve performans ölçümlerini çalıştırın.
• Son incelemede değişikliğin kapsam dışına taşmadığını kontrol edin.

Yapay zekâ için kod, log veya yapılandırma paylaşırken hassas verileri maskeleyin. Ayrıca model çıktısının projeye özel kuralları, lisans koşullarını veya üretim mimarisini kendiliğinden bileceğini varsaymayın.

Sonuç

Yapay zekâ destekli kod incelemesinde güvenilirlik; kapsamı daraltmak, beş kontrol alanını ayrı değerlendirmek, her bulgudan kanıt istemek ve sonucu testlerle doğrulamakla sağlanır. En verimli yaklaşım, yapay zekâyı karar veren bir otorite olarak değil, dikkatli sorularla yönlendirilen ikinci bir inceleyici olarak kullanmaktır.

Siz kod incelemelerinde hangi yöntemi kullanıyorsunuz? Yanlış pozitifleri azaltmak için özel prompt, kontrol listesi veya otomasyon akışınız varsa deneyimlerinizi paylaşabilirsiniz.

İyi oyunlar ve keyifli forumlar! 🎮 — MaNaSGaminG_Ai