Yapay zeka çağında kod incelemesi

• Yapay zeka kod incelemesini ortadan kaldırmadı; aksine ispat yükümlülüğünü daha net hale getirdi
• Değişiklikler, manuel doğrulama veya otomatik testler gibi kanıtlar eklenerek dağıtılmalı; ardından inceleme yoluyla risk, niyet ve sorumluluk anlaşılmalıdır
• Bireysel geliştiriciler yapay zekanın hızına yetişmek için otomasyona dayanırken, ekipler inceleme yoluyla ortak bağlam ve sorumluluk oluşturur
• Bir PR’da çalıştığına dair kanıt yoksa bu hızlı dağıtım değil, yalnızca işi aşağı akışa taşımak demektir; yalnızca doğrulama sistemine sahip geliştiriciler yapay zekayla yüksek hızlı geliştirmede başarılı olur
• Kod incelemesindeki darboğaz, kod yazmaktan çalıştığını kanıtlama sürecine kaydı; yapay zeka mekanik işleri hızlandırsa da sorumluluk insanlarda kalmalıdır

Yapay zeka çağında kod incelemesinin değişimi

• 2026 başı itibarıyla kıdemli geliştiricilerin %30’undan fazlası çoğunlukla yapay zeka tarafından üretilmiş kodu dağıtıyor; yapay zeka özellik taslağı çıkarmada başarılı olsa da mantık, güvenlik ve edge case’lerde mantık hatalarında %75 artış gibi zafiyetler ortaya çıkarıyor
• Tek başına çalışan geliştiriciler çıkarım hızı (inference speed) ile hızlı dağıtım yapıyor ve test paketini bir güvenlik ağı olarak kullanıyor; ekipler ise bağlam ve mevzuata uyum için insan incelemesini koruyor
• Doğru yapıldığında her ikisi de yapay zekayı bir hızlandırıcı olarak kullanır, ancak kimin, neyi, ne zaman doğruladığına göre fark ortaya çıkar
• Kodun gerçekten çalıştığını bizzat doğrulamadıysanız, o kod gerçekten çalışıyor sayılmaz
  • Yapay zeka bu kuralı sadece güçlendirir; onu geçersiz kılmaz

Geliştiricilerin yapay zekayı incelemede kullanma biçimleri

• Ad-hoc LLM kontrolü: Commit’ten önce diff’i Claude, Gemini veya GPT’ye yapıştırıp hata ya da stil sorunlarını hızlıca kontrol etme
• IDE entegrasyonu: Cursor, Claude Code, Gemini CLI gibi araçlarla kodlama sırasında satır içi öneriler ve refactoring kullanma
• PR botları ve tarayıcılar: GitHub Copilot veya özel ajanlarla PR içindeki potansiyel sorunları otomatik işaretleme, Snyk gibi statik ve dinamik analiz araçlarıyla güvenlik taramasını birlikte yürütme
• Otomatik test döngüsü: Yapay zekayla test üretip çalıştırma ve %70+ coverage’ı merge koşulu olarak belirleme
• Çoklu model incelemesi: Kodu birden fazla LLM ile inceleyerek modele özgü önyargıları yakalama (ör. Claude ile üretim, güvenlik odaklı modelle denetim)

Tek geliştirici vs ekip: karşılaştırma

• Tek geliştirici
  • İnceleme odağı: otomatik testler + sınırlı spot kontroller
  • Hız tavizi: çıkarım süresi, yinelemeli döngülerle sorun düzeltme
  • Temel araç: agentic testing (ör. Claude Code döngüsü)
  • İlke: Kendin kanıtla (Prove it yourself)
• Ekip
  • İnceleme odağı: bağlamı ve güvenliği insan muhakemesiyle değerlendirme
  • Hız tavizi: inceleme darboğazını önlemek için PR’ları küçük tutma
  • Temel araç: bot + politika kombinasyonu (ör. yapay zeka üretimi PR etiketleme)
  • İlke: Çalıştığına dair kanıtı ekiple paylaş (Share the Proof)

Tek geliştirici: “çıkarım hızı” ile dağıtım

• Tek geliştiriciler, yapay zeka üretimi kodun “hissine güvenme” eğiliminde; yalnızca kritik kısımları kontrol edip sorunları testlerle yakalayarak özellikleri hızlıca dağıtıyorlar
• Kodlama ajanlarını, büyük ölçekli refactoring’i tek başına halledebilen güçlü bir stajyer gibi görme eğilimindeler
• Peter Steinberger’in sözü: “Artık çok fazla kod okumuyorum. Akışı izliyorum ve bazen sadece kritik kısımları kontrol ediyorum”
• Geliştirmedeki darboğaz, yazı yazmak değil çıkarım süresine (AI çıktısını bekleme) kaydı
• Dikkat edilmesi gereken nokta: Güçlü testler yoksa hissedilen hız artışı ortadan kalkar
  • İncelemeyi atlamak işi ortadan kaldırmak değil, sonraya ertelemek demektir
  • Yapay zekaya dayalı yüksek hızlı geliştirmede başarının anahtarı körü körüne güven değil, bir doğrulama sistemi kurmaktır
• Sorumlu tek geliştiriciler, kapsamlı otomatik testleri güvenlik ağı olarak kullanır ve coverage için %70+ hedefi koyar
• Dilden bağımsız ve veri odaklı testler belirleyici rol oynar
  • Testler yeterliyse ajan, dilden bağımsız olarak uygulama üretip düzeltebilir ve doğrulanabilir
  • Proje başlangıcında AI, spec.md taslağını oluşturur; onaydan sonra yazma → test etme → düzeltme döngüsü tekrarlanır
• Tek geliştiriciler de son aşamada manuel test ve eleştirel muhakeme uygular
  • Uygulamayı bizzat çalıştırır, arayüzde tıklar ve özelliği kullanır
  • Risk yüksekse daha fazla kod okur ve ek doğrulama yapar
  • Hızlı geliştirseler bile dağınık kodu fark eder etmez temizlerler
• Temel ilke: geliştiricinin görevi “çalıştığını bizzat kanıtladığı kodu teslim etmektir”

Ekipler: yapay zeka inceleme darboğazını yer değiştiriyor

• Ekip ortamında yapay zeka kod incelemesinin güçlü bir yardımcısıdır, ancak kalite, güvenlik ve bakım yapılabilirlik için gerekli insan muhakemesinin yerini alamaz
• Birden fazla mühendisin birlikte çalıştığı ortamlarda hataların maliyeti ve kodun ömrü çok daha önemli unsurlardır
• Birçok ekip, AI inceleme botlarını PR’ın ilk aşamalarında kullanıyor; ancak nihai onay hâlâ insanlardan isteniyor
• Graphite’tan Greg Foster’ın sözü: “AI ajanlarının gerçek insan mühendislerin PR onayının yerini alacağı bir dünya olmayacak”
• En büyük pratik sorun, AI inceleyicilerin stil sorunlarını kaçırması değil; AI’ın kod hacmini artırarak inceleme yükünü insanlara aktarması
  • AI benimsenmesinin yayılmasıyla PR boyutu yaklaşık %18 arttı
  • PR başına incident sayısı yaklaşık %24 arttı
  • Değişiklik başarısızlık oranı yaklaşık %30 arttı
• Çıktı üretim hızı doğrulama kapasitesini aştığında, inceleme süreci tüm geliştirme akışının hız sınırlayıcı unsuru haline gelir
• Foster’ın sözü: “Bir insan meslektaşın okuyamadığı veya anlayamadığı kodu dağıtmak büyük bir risktir”
• Ekip ortamında AI çok miktarda çıktı ürettiği için, kademeli geliştirme yaklaşımı gereklidir ve ajan çıktıları incelenebilir commit birimlerine bölünmelidir
• İnsanların verdiği nihai onay ortadan kalkmaz; bunun yerine AI’ın kaçırdığı alanlara odaklanacak şekilde evrilir
  (yol haritası uyumu, AI’ın kavrayamadığı kurumsal ve örgütsel bağlam)

Güvenlik: yapay zekanın öngörülebilir zafiyetleri

• Güvenlik, insan muhakemesinin mutlak biçimde gerekli olduğu bir alandır
• AI tarafından üretilen kodun yaklaşık %45’inde güvenlik açığı bulunuyor
• Mantık hatası oranı, insanlar tarafından yazılmış koda kıyasla 1,75 kat daha yüksek
• XSS zafiyetleri 2,74 kat daha sık görülüyor
• Kodun kendisindeki sorunlara ek olarak, ajan tabanlı araçlar ve AI entegre IDE’ler yeni saldırı yolları oluşturuyor
  • Prompt injection, veri sızıntısı, RCE zafiyetleri
• AI saldırı yüzeyini genişlettikçe, hibrit yaklaşım etkili oluyor
  • AI sorunları işaretler, insan nihai doğrulamayı yapar
• Kural: Kimlik doğrulama, ödeme, secret veya güvenilmeyen girdilerle çalışan kodlarda
  AI’ı hızlı bir stajyer gibi ele alın ve merge öncesinde insan kaynaklı tehdit modellemesi incelemesi ile güvenlik aracı taramasını zorunlu kılın

İnceleme yoluyla bilgi aktarımı

• Kod incelemesi, ekibin sistem bağlamını paylaşmasının temel yollarından biridir
• Kodu AI yazmış olabilir; ama kimse açıklayamıyorsa on-call maliyeti artar
• Tam olarak anlaşılmayan AI üretimi kodu göndermek, ekibin dayanıklılığını oluşturan bilgi aktarım mekanizmasını çökertir
• Yazar kodun neden çalıştığını açıklayamıyorsa, on-call mühendisi sabah 2’de hata ayıklama yapamaz
• Bir OCaml maintainer’ın 13.000 satırlık AI üretimi PR’ı reddetmesi buna örnek
  • Kod kalitesi mutlaka kötü değildi, ancak bu ölçekteki değişikliği inceleyecek inceleme bant genişliği yoktu
  • AI üretimi kod incelemesi, insan yazımı koda göre daha büyük bilişsel yük gerektiriyor
• Ders: AI çok miktarda kod üretebilir, ancak ekipler inceleme darboğazını önlemek için değişiklik boyutunu yönetmelidir

AI inceleme araçları nasıl kullanılmalı

• AI inceleme araçlarıyla ilgili kullanıcı deneyimi keskin biçimde ikiye ayrılıyor
• Olumlu tarafı: Bazı örneklerde null pointer exception, eksik test coverage’ı ve antipattern’ler gibi hataların %95’inden fazlası yakalanabiliyor
• Olumsuz tarafı: Bazı geliştiriciler AI inceleme yorumlarını değersiz, genel geçer gözlemlerden oluşan “metin gürültüsü” olarak görüyor
• Ders: AI inceleme araçları dikkatli yapılandırma gerektirir
  • Hassasiyeti ayarlama, yararsız yorum türlerini kapatma, net opt-in ve opt-out politikaları oluşturma
• Doğru yapılandırıldığında AI inceleyiciler kolay sorunların %70–80’ini yakalayabilir; insanlar da mimari ve iş mantığına odaklanabilir
• Birçok ekip, AI tek seferde devasa değişiklikler üretebilse bile küçük ve üst üste inşa edilebilir PR’ları teşvik ediyor
• Değişiklikler sık commit edilmeli ve her değişiklik açık mesajlarla kendi içinde tamamlanmış bir birim olarak ayrı commit/PR şeklinde yönetilmeli
• Ekipler, insan sorumluluğuna dair net sınırları korur
• AI’ın katkı düzeyi ne olursa olsun nihai sorumluluk insana aittir
• IBM eğitim özdeyişi: “Bilgisayar asla sorumluluk alamaz. Sorumluluk, döngünün içindeki insana aittir.”

PR sözleşmesi: yazarın inceleyiciye karşı yükümlülüğü

• İster tek başına ister ekip halinde çalışılsın, ortaklaşa öne çıkan en iyi uygulama, AI üretimi kodu doğrulama gerektiren faydalı bir taslak olarak görmek
• En başarılı ekiplerin ortak kullandığı basit bir çerçeve var

• PR sözleşmesinin bileşenleri

  1/. What/Why: Değişikliğin niyeti ve nedeni 1–2 cümlede açıklanır
  2/. Çalıştığına dair kanıt: Geçen test sonuçları ve manuel doğrulama adımları (ekran görüntüsü, loglar)
  3/. Risk + AI’ın rolü: Değişikliğin risk seviyesi ve AI’ın hangi kısmı ürettiğinin belirtilmesi (ör. ödeme özelliği yüksek risklidir)
  4/. İnceleme odağı: İnsan incelemesi gerektiren 1–2 alanın belirtilmesi (ör. mimari)
• Bu bir bürokrasi değil; inceleyicinin zamanına saygı göstermek ve yazarın sorumluluğunu netleştirmek için bir mekanizmadır
• Bunu yazamıyorsanız, bir başkasından onay isteyecek kadar kendi değişikliğinizi yeterince anlamıyorsunuz demektir

Temel ilkeler

• Vaat değil kanıt isteyin: Temel ölçütü “çalışan kod” yapın; AI ajanından kod ürettikten sonra çalıştırmasını veya unit test çalıştırmasını isteyin, loglar, ekran görüntüleri ve sonuçlar gibi kanıtları kontrol edin; yeni test veya çalışan demo olmadan PR açmayın
• AI’ı nihai hakem değil, ilk inceleyici olarak kullanın: AI inceleme çıktısını tavsiye olarak ele alın; bir AI kodu yazar, başka bir AI gözden geçirir, insan ise düzeltme yönünü belirler; AI incelemesini imla denetimi seviyesinde kullanın, editör olarak değil
• İnsan incelemesi AI’ın kaçırdığı yerlere odaklansın: Güvenlik açığı eklenip eklenmediği, mevcut kodun tekrar edilmesi (AI’ın yaygın kusuru), yaklaşımın bakım yapılabilirliği gibi alanlarda AI kolay sorunları eler, zor yargıları insanlar verir
• Kademeli geliştirme uygulayın: İşleri küçük parçalara bölerek AI’ın üretmesini, insanların da incelemesini kolaylaştırın; açık mesajlı küçük commit’leri kontrol noktası olarak kullanın; açıklayamadığınız kodu asla commit etmeyin
• Yüksek test standardını koruyun: Kodlama ajanlarını etkili kullanan geliştiriciler güçlü test pratiklerini sürdürür; AI’dan test taslağı isteyerek insanların gözden kaçırabileceği edge case testleri ürettirir

Gelecek görünümü: darboğaz yer değiştiriyor

• AI, kod incelemesini satır düzeyinde bekçilikten üst düzey kalite kontrolüne taşıyor; ancak insan muhakemesi hâlâ güvenlik açısından vazgeçilmez
• Bu, iş akışının evrimidir; kod incelemesinin ortadan kalkması değil
• Kod incelemesinin kapsamı artık yalnızca kod diff’ini değil, AI ile yazar arasındaki konuşmaları veya planları da içerebilir
• İnsan inceleyicinin rolü giderek editör ya da mimara benziyor; önemli kararlara odaklanıyor ve rutin kontrollerde otomasyona güveniyor
• Tek geliştiriciler için önümüzdeki yol heyecan verici; ama yeni araçlar artsa da akıllı geliştiriciler hâlâ “güven ama doğrula” yaklaşımını koruyacak
• Büyük ekiplerde AI yönetişiminin güçlenmesi bekleniyor
  • AI katkılarına ilişkin politikalar resmileşecek ve çalışanların bizzat incelediğine dair onay istenecek
  • “AI kod denetçisi” gibi roller ortaya çıkacak
  • Kurumsal platformlar, çoklu depo bağlamını ve özel politika uygulamalarını daha iyi destekleyecek şekilde evrilecek
• Temel ilke değişmiyor: Kod incelemesi, yazılımın gereksinimleri karşıladığını, güvenli, sağlam ve bakım yapılabilir olduğunu garanti eder
• AI bu temeli değiştirmez; yalnızca oraya ulaşma biçimini değiştirir
• Geliştirmedeki darboğaz, kod yazmaktan çalıştığını kanıtlama sürecine kayıyor
• AI çağının iyi kod inceleyicileri bu değişimi benimser; AI’ın mekanik işleri hızlandırmasına izin verirken sorumluluk çizgisini korur
• AI süreci hızlandırabilir (accelerate), ancak sorumluluğun terk edilmesine (abdicate) yol açmamalıdır
• Mühendisler giderek “vibe yerine kanıtı (proof over vibes)” daha çok önemseyecek
• Kod incelemesi ortadan kalkmadı; daha stratejik bir role dönüşüyor
• İster sabah 2’de dağıtım yapan tek geliştirici olun, ister kritik sistem değişikliklerini onaylayan bir ekip lideri; ortak gerçek şu: AI’ın ürettiği sonuçların nihai sorumluluğu insana aittir
• AI’ı benimseyin, ama çalışmayı yeniden kontrol etme alışkanlığını koruyun

[tested]

https://www.coderabbit.ai/
CodeRabbit kullanan var mı? Fiyatı epey yüksek ama o kadar parasını hak edip etmediğinden emin değilim.

[developerjhp]

Aşağıdaki Chrome uzantısını kullanırsanız, GitHub PR diff’i temelinde GPT’den rahatça inceleme alabilirsiniz~!
https://github.com/developerjhp/Diffinity

[crawler]

Bunu kendiniz yaptıysanız, sanırım Show GN'de paylaşmanız daha iyi olurdu.

Daha 5 ay öncesine kadar Show GN'ye gayet güzel paylaşıyordunuz; neden yoruma reklam yapıyorsunuz TT...