Kazanimlar:
- AI'yı kategori ve şiddet etiketli bir ilk inceleme süzgeci olarak kullanabilme
- Bulguları doğrula/yanlış pozitif/uygula diye insan aklıyla süzebilme
- İş kuralı, mimari ve güvenlik-kritik kararlarda insan onayının zorunluluğunu uygulayabilme
Kod inceleme (code review), bir geliştiricinin yazdığı değişikliğin, birleştirilmeden önce başka biri tarafından gözden geçirilmesidir. İyi bir inceleme; hataları erken yakalar, bilgi paylaşır ve kod tabanını tutarlı tutar. Ama incelemeler yorucudur, dikkat dağınıklığına açıktır ve zaman baskısı altında yüzeyselleşir. Yapay zeka burada iki yönlü bir yardımcıdır: hem incelemeye sunduğunuz kendi kodunuzu önden temizlemenizi, hem de başkasının PR'ını (pull request) daha keskin gözle incelemenizi sağlar.
Kritik ayrım şudur: AI, incelemeyi hızlandırır ve zenginleştirir, ama onaylama sorumluluğunu devralamaz. "AI baktı, temiz" cümlesi bir onay değildir. Nihai "birleştir" kararı, kodu ve bağlamı bilen bir mühendisindir.
AI'nın İncelemede İyi ve Kötü Olduğu Şeyler
İyi olduğu yerler: Null/boş kontrol eksikleri, kaynak sızıntıları (açık kalan dosya/bağlantı), yakalanmayan istisnalar, açıkça yanlış koşullar (>= yerine >), yeniden adlandırma önerileri, okunabilirlik, eksik kenar durum, basit güvenlik kokuları (SQL string birleştirme gibi), tekrar eden kod tespiti.
Zayıf olduğu yerler: Sizin iş kuralınıza aykırı ama sözdizimsel olarak doğru mantık, mimari uygunluk, performansın gerçek darboğazı, eşzamanlılık (concurrency) hataları gibi bağlam ve zamanlama gerektiren derin kusurlar. AI ayrıca yanlış pozitif (aslında sorun olmayan şeyi sorun sanma) ve yanlış negatif (gerçek hatayı kaçırma) üretir. Bu yüzden çıktısı bir "dikkat listesi"dir, kesin hüküm değil.
Dikkat: AI'nın "sorun yok" demesi, kodun doğru olduğunu kanıtlamaz. Yanlış negatifler sessizdir; en tehlikeli hatalar, incelemede hiç bahsi geçmeyenlerdir.
Sistematik İnceleme Adımları
- Bağlamı verin. Değişikliğin amacını, ilgili issue'yu ve varsa kabul kriterini prompt'a ekleyin. Amaçsız inceleme, amaçsız yorum üretir.
- Kategorilere ayırın. Modelden bulguları "hata / güvenlik / performans / okunabilirlik / stil" olarak sınıflandırmasını isteyin; böylece kritik olanı gürültüden ayırırsınız.
- Şiddet (severity) etiketi isteyin. Her bulguya "yüksek/orta/düşük" verdirin ve "neden" ile "önerilen düzeltme"yi ekletin.
- Kendi gözünüzle süzün. Her bulguyu değerlendirin: gerçek mi (doğrula), yanlış pozitif mi (gerekçesini yaz), atlanmış bir şey var mı (kendi bilginizle ekle).
- Kritik yolları elle doğrulayın. Para, kimlik, yetki ve veri silme içeren yolları AI'ya güvenmeden bizzat okuyun ve gerekiyorsa çalıştırın.
Üç Mini Vaka
Vaka 1 — Sessiz null hatası yakalandı. Bir ekip, 380 satırlık bir PR'ı AI'ya önden incelettirdi. Model, bir harici servis yanıtının null gelebileceği ama koda bunun için kontrol konmadığı bir yolu işaretledi. İnsan incelemeci bu yolu doğrulayıp bir null kontrolü ekledi; benzer bir hata bir önceki çeyrekte üretimde 2 saatlik kesintiye yol açmıştı.
Vaka 2 — Yanlış pozitif eleme. AI, bir döngüde "olası performans sorunu" işaretledi. İnceleyen kişi, döngünün en fazla 5 elemanla çalıştığını (bir enum üzerinde döndüğünü) bildiğinden bunu yanlış pozitif olarak gerekçesiyle kapattı. Bağlamı bilmeyen model uyardı; bağlamı bilen insan doğru kararı verdi.
Vaka 3 — İş kuralı hatasını AI kaçırdı. Bir indirim hesabı, kampanya kuralına göre en fazla %30 olmalıyken kod %50'ye izin veriyordu. Sözdizimsel olarak kusursuz olan bu mantık hatasını AI hiç fark etmedi; çünkü kuralı bilmiyordu. Hata, kabul kriterini bilen ürün sahibinin gözden geçirmesinde yakalandı. Ders: iş kuralı doğrulaması insanın işidir.
Dört Kopyalanabilir Şablon
Amaç odaklı, kategorili inceleme:
Rol: Titiz bir kod incelemecisi.Değişikliğin amacı: {{amaç / issue}}Bu diff'i incele. Bulguları şu kategorilerle ver: [Hata] [Güvenlik][Performans] [Okunabilirlik] [Stil]. Her bulgu için: dosya:satır, şiddet(yüksek/orta/düşük), neden, önerilen düzeltme. Emin olmadıklarını "olası" diyeişaretle. İş kurallarını bilmiyorsun; kural gerektiren yerleri bana sor.{{diff}}
Kendi kodunu incelemeye hazırlamak:
Bu değişikliği PR açmadan önce gözden geçir. Şunları ara: eksik null/hatakontrolü, kaynak sızıntısı, kenar durum, gizli/sabit değer (secret), testedilmemiş dal. Bulunanları öncelik sırasıyla listele; her biri için 1 satırdüzeltme öner.{{kod}}
Kenar durum avı:
Bu fonksiyonun kırılabileceği girdi ve durumları listele: boş, null, çok büyük,negatif, eşzamanlı çağrı, ağ hatası, kısmi veri. Her durum için beklenendavranışı ve mevcut kodun ne yapacağını yaz.{{fonksiyon}}
Güvenlik kokusu taraması (ön eleme):
Bu kodda yaygın güvenlik kokularını ara: SQL/komut birleştirme, doğrulanmamışgirdi, sabit gömülü sır, güvensiz deserialize, yetki kontrolü eksikliği.Bulguları "kesin / olası / bilgi" diye ayır. Bu bir ön tarama; kesin hüküm değil.{{kod}}
Zayıf prompt / Güçlü prompt
Zayıf: "Bu PR'da hata var mı?"
Güçlü: "Amaç: sepet toplamına kupon indirimi eklemek (indirim en fazla %30 olmalı — bu kuralı sen doğrulayamazsın, yalnızca kodun bir üst sınır uygulayıp uygulamadığını söyle). Diff'i incele; bulguları kategori + şiddet + önerilen düzeltmeyle ver, emin olmadıklarını 'olası' işaretle. [diff]"
Güçlü sürüm amacı, iş kuralını ve AI'nın sınırını açıkça belirtir; böylece hem işe yarar bulgular gelir hem de modelin bilmediği alan net kalır.
Bulgu tipi
AI güvenilirliği
İnsanın rolü
Null/hata kontrolü eksik
Yüksek
Doğrula ve uygula
Okunabilirlik/stil
Yüksek
Tercihe göre seç
Basit güvenlik kokusu
Orta
Kesinleştir, araçla tara
İş kuralı uyumu
Düşük
Tamamen insanda
Eşzamanlılık/mimari
Düşük
Uzman incelemesi şart
AI İnceleme, İnsan İncelemenin Yerine Geçmez
AI incelemesini bir "ilk süzgeç" olarak konumlandırın: ucuz, hızlı, yorulmaz bir ön geçiş. Bu süzgeç, insan incelemecinin dikkatini önemsiz ayrıntılardan (bir boşluk, bir isim) kurtarıp gerçekten düşünme gerektiren yerlere — iş kuralı, mimari, güvenlik sonucu — yöneltir. Ama birleştirme onayı, ekip içinde hesap verebilir bir insanın imzasıdır. Güvenlik-kritik değişikliklerde en az bir yetkin mühendisin bağımsız incelemesi zorunludur.
İpucu: AI'nın ürettiği bulgu listesini bir "yapılacaklar" gibi değil, bir "kontrol edilecekler" gibi okuyun. Her maddeyi ya doğrulayıp uygulayın ya da neden geçtiğinizi tek cümleyle not edin; bu iz, incelemeyi denetlenebilir kılar.
Sık yapılan hatalar
- "AI baktı, temiz" demek. Yanlış negatifler yüzünden bu, sahte bir güven duygusudur.
- Bağlam vermemek. Amaç ve kabul kriteri olmadan model yalnızca yüzeysel stil yorumları üretir.
- Yanlış pozitifleri körü körüne uygulamak. Modelin her uyarısını düzeltmek, çalışan kodu bozabilir.
- İş kuralını modele sormak. Model kuralı bilmez; onu doğrulama işi insanındır.
- Şiddet ayrımı yapmamak. Kritik bir güvenlik bulgusuyla bir isim önerisini aynı torbaya koymak, önemliyi gölgeler.
Özetle
AI, kod incelemede yorulmayan bir ilk süzgeçtir: null/hata eksiklerini, kenar durumları ve basit güvenlik kokularını iyi yakalar; ama iş kuralı, mimari ve eşzamanlılık gibi bağlam gerektiren kusurlarda zayıftır ve hem yanlış pozitif hem yanlış negatif üretir. Bulguları kategori ve şiddetle isteyin, her birini insan aklıyla süzün, kritik yolları elle doğrulayın. Onay, her zaman hesap verebilir bir mühendisin imzasıdır.
Uygulama görevi
Gerçek veya yakın zamanlı bir PR/diff seçin. Önce "amaç odaklı, kategorili inceleme" şablonuyla AI'ya incelettirin. Gelen bulguları bir tabloya dökün ve her biri için karar verin: gerçek (doğruladım), yanlış pozitif (gerekçem şu), ya da uygulanacak. Sonra kendi gözünüzle bir tur atıp AI'nın kaçırdığı en az bir şey (özellikle bir iş kuralı veya kenar durum) bulmaya çalışın ve bunu not edin.
Kontrol listesi
- [ ] AI incelemesini onay değil, ilk süzgeç olarak kullanıyorum.
- [ ] İnceleme prompt'una amaç ve kabul kriterini ekliyorum.
- [ ] Bulguları kategori ve şiddetle isteyip gürültüden ayırıyorum.
- [ ] Her bulguyu doğrula/yanlış pozitif/uygula diye bilinçli süzüyorum.
- [ ] İş kuralı ve mimari uygunluğu insan olarak ben denetliyorum.
- [ ] Güvenlik-kritik değişikliklerde yetkin bir mühendis onayını zorunlu tutuyorum.