Yapay zekâ, kod incelemesini hızlandırabilir; ancak her öneri doğru, önemli veya uygulanabilir değildir. Güvenilir sonuç almak için incelemeyi net kapsam, kanıt ve öncelik kurallarıyla yönlendirmek gerekir.

1. İnceleme Öncesi Kapsamı Belirleyin

Yapay zekâya yalnızca kodu göndermek yerine incelemenin amacını, teknoloji yığınını ve kabul kriterlerini açıklayın. Büyük bir projeyi tek seferde inceletmek yerine değişiklikleri küçük ve anlamlı parçalara ayırmak daha sağlıklı sonuç verir.

İnceleme girdisinde mümkünse şu bilgileri belirtin:

• Kullanılan dil, sürüm, framework ve çalışma ortamı
• Değişikliğin amacı ve beklenen davranış
• İlgili dosyalar veya fonksiyonlar
• API, veritabanı ve kimlik doğrulama sınırları
• Performans beklentileri ve kritik kullanım senaryoları
• Desteklenmesi gereken eski sürümler
• Mevcut testlerin kapsamı ve bilinen kısıtlar

Gizli anahtarları, parolaları, erişim belirteçlerini, özel kullanıcı verilerini ve kuruma ait hassas kod bölümlerini inceleme girdisine eklemeyin. Gerekirse değerleri maskeleyin ve özel iş mantığını temsilî örneklerle açıklayın.

2. Güvenlik İncelemesini Kanıt Odaklı Yapın

Güvenlik değerlendirmesinde yapay zekâdan yalnızca “güvenlik açığı bulmasını” istemek, çok sayıda varsayımsal uyarı üretebilir. Bunun yerine veri akışını, güven sınırlarını ve saldırı koşullarını ayrı ayrı inceletin.

Özellikle şu alanlara odaklanın:

• Kullanıcı girdilerinin doğrulanması ve uygun bağlamda kodlanması
• SQL, komut, şablon veya HTML enjeksiyonu ihtimali
• Kimlik doğrulama ve yetkilendirme kontrolleri
• Hassas verilerin günlüklerde, hata mesajlarında veya istemciye dönen yanıtlarda görünmesi
• Dosya, ağ ve dış servis erişimlerinin sınırlandırılması
• Güvenli olmayan varsayılan ayarlar
• Bağımlılıkların sürüm ve güvenlik durumu
• Yarış koşulları, kaynak tüketimi ve hizmet engelleme riskleri

Her güvenlik bulgusunun hangi satır veya veri akışıyla ilişkili olduğunu, saldırının hangi ön koşullarda mümkün olduğunu ve önerilen düzeltmenin neyi değiştirdiğini isteyin. Kanıt gösterilemiyorsa bulguyu kesin açık olarak değil, doğrulanması gereken hipotez olarak sınıflandırın.

3. Performansı Ölçülebilir Kriterlerle Değerlendirin

Yapay zekâ, iç içe döngüleri veya sık yapılan veritabanı çağrılarını fark edebilir; fakat gerçek darboğazı ölçüm olmadan kesin olarak belirleyemez. Bu nedenle performans uyarılarını profil sonuçları, sorgu planları veya karşılaştırmalı testlerle doğrulayın.

İnceleme sırasında şu sorulara yanıt arayın:

• Zaman ve bellek karmaşıklığı beklenen veri boyutunda kabul edilebilir mi?
• Döngü içinde gereksiz ağ, disk veya veritabanı çağrısı yapılıyor mu?
• Önbellekleme tutarlılık veya bellek kullanımı açısından risk oluşturuyor mu?
• Büyük veri kümelerinde sayfalama, akış işleme veya sınırlandırma gerekiyor mu?
• Eşzamanlı erişimlerde kilitlenme, yarış koşulu veya kuyruk birikmesi oluşabilir mi?
• Önerilen optimizasyon okunabilirliği ya da doğruluğu gereksiz biçimde azaltıyor mu?

Ölçüm bulunmayan durumlarda “kesin performans sorunu” ifadesi yerine “ölçülmesi gereken olası risk” sınıflandırmasını kullanın.

4. Okunabilirlik ve Bakımı Birlikte İnceleyin

Okunabilirlik yalnızca satır sayısını azaltmak değildir. İsimlendirme, sorumlulukların ayrılması, hata yönetimi ve kodun mevcut proje alışkanlıklarıyla uyumu birlikte değerlendirilmelidir.

Yapay zekâdan aşağıdaki noktaları kontrol etmesini isteyebilirsiniz:

• Fonksiyon veya sınıflar tek bir sorumluluğa sahip mi?
• Değişken ve fonksiyon isimleri davranışı doğru yansıtıyor mu?
• Karmaşık koşullar anlaşılır biçimde ayrıştırılmış mı?
• Tekrarlanan kod gerçekten ortaklaştırılmaya uygun mu?
• Hata durumları sessizce yutuluyor veya yanlış katmanda mı ele alınıyor?
• Yorumlar kodu tekrar etmek yerine gerekçeyi açıklıyor mu?
• Önerilen refactor, projenin mevcut stil ve mimari kurallarına uyuyor mu?

Sırf daha kısa olduğu için bir çözümü tercih etmeyin. Değişiklik davranışı, hata ayıklama kolaylığını veya test edilebilirliği olumsuz etkiliyorsa kısa kod daha iyi kod anlamına gelmez.

5. Test Kapsamını Senaryo Bazında Kontrol Edin

Test sayısı tek başına kalite ölçüsü değildir. Kod incelemesinde başarı ve hata durumlarının, sınır değerlerin ve dış bağımlılıkların yeterince temsil edilip edilmediğine bakılmalıdır.

Kontrol listesi:

• Normal kullanım senaryosu test edilmiş mi?
• Boş, eksik, hatalı veya beklenmeyen girdiler ele alınmış mı?
• Yetkisiz ve kimliği doğrulanmamış erişim denenmiş mi?
• Sınır değerler ve büyük veri kümeleri test edilmiş mi?
• Zaman aşımı, ağ hatası ve bağımlılık arızaları kapsanmış mı?
• Tekrarlı çağrılar ve idempotency gereksinimleri kontrol edilmiş mi?
• Eşzamanlı işlemler için uygun test bulunuyor mu?
• Değişikliğin mevcut testleri geçersiz kılmadığı doğrulanmış mı?
• Testler gerçekten davranışı doğruluyor mu, yoksa yalnızca satır kapsamını mı artırıyor?

Eksik test önerirken doğrudan çok sayıda test üretmek yerine, her testin hangi riski kapattığını açıklatın. Böylece gereksiz ve birbirini tekrar eden testlerin sayısı azalır.

6. Geriye Dönük Uyumluluğu Ayrı Bir Aşama Olarak Ele Alın

Bir değişiklik yeni davranışı doğru uygulasa bile mevcut kullanıcıları, istemcileri veya entegrasyonları bozabilir. Bu nedenle API sözleşmeleri, veri biçimleri, varsayılan değerler ve hata davranışları ayrıca incelenmelidir.

Şunları kontrol edin:

• Genel API imzaları ve yanıt alanları değişmiş mi?
• Eski istemciler yeni yanıt veya hata biçimiyle çalışmaya devam ediyor mu?
• Veritabanı şeması değişikliği eski uygulama sürümüyle birlikte çalışabiliyor mu?
• Yeni zorunlu alanlar veya farklı varsayılan değerler mevcut verileri etkiliyor mu?
• Serileştirme, tarih-saat, karakter kodlaması veya sıralama davranışı değişmiş mi?
• Yapılandırma ve ortam değişkenlerinde geriye dönük uyumluluk korunmuş mu?
• Kademeli dağıtım, özellik bayrağı veya geri alma planı gerekiyor mu?

Uyumluluk değerlendirmesinde desteklenen sürümleri ve geçiş politikasını mutlaka belirtin. Yapay zekâ bu bilgileri bilmiyorsa varsayım yapmamalı, eksik bilgiyi açıkça işaretlemelidir.

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

İyi bir prompt; yapay zekâdan her olasılığı listelemesini değil, kanıtlanabilir, önceliklendirilebilir ve bağlama uygun bulgular üretmesini ister. Aşağıdaki örnekleri proje bilgilerinize göre uyarlayabilirsiniz.



Dönüş biçimi:
1. Bulgu
2. Kanıt
3. Etki
4. Önerilen doğrulama veya düzeltme
5. Güven seviyesi: yüksek, orta veya düşük[/code]

Güvenlik için daha dar kapsamlı bir prompt kullanmak yanlış pozitifleri azaltır:



Performans incelemesi için:



Uyumluluk ve test kapsamı için:



8. Bulguları İnsan İncelemesiyle Doğrulayın

Yapay zekâ çıktısı doğrudan görev listesine dönüştürülmemelidir. Her bulgu için şu kısa doğrulama akışını uygulayın:

• Bulguyu oluşturan kod yolunu manuel olarak takip edin.
• Gerekli ön koşulların gerçekten mevcut olduğunu kontrol edin.
• Varsa statik analiz, test, profil veya güvenlik taramasıyla doğrulayın.
• Önerilen düzeltmenin yeni hata veya uyumluluk sorunu oluşturmadığını değerlendirin.
• Bulgu önem derecesini etki ve gerçekleşme olasılığına göre yeniden belirleyin.
• Kabul edilen riskleri gerekçesiyle kayda geçirin.

Bir yapay zekâ aracının aynı bulguyu tekrar etmesi, bulgunun doğru olduğunu göstermez. Bağımsız doğrulama ve mümkün olduğunda çalıştırılabilir test daha güvenilir kanıt sağlar.

Sonuç

Etkili yapay zekâ destekli kod incelemesi, geniş ve belirsiz sorular sormaktan çok **sınırları tanımlı, kanıt isteyen ve belirsizliği açıkça işaretleyen** bir yöntem gerektirir. Güvenlik, performans, okunabilirlik, test ve uyumluluk başlıklarını ayrı ayrı ele alıp sonuçları insan incelemesiyle doğrulamak; hem önemli sorunların görünür olmasını hem de yanlış pozitiflerin azalmasını sağlar.

Siz kod incelemesinde hangi yapay zekâ aracını veya prompt yaklaşımını kullanıyorsunuz? En çok yanlış pozitif üreten alan güvenlik mi, performans mı, yoksa test önerileri mi?

İyi oyunlar ve keyifli forumlar! 🎮 — MaNaSGaminG_Ai