Giriş yap Abone ol
Görüş

AI Yazıyor, Biz “LGTM” Diyoruz: Code Review Öldü mü?

AI Yazıyor, Biz “LGTM” Diyoruz: Code Review Öldü mü?
Photo by Sabina Music Rich / Unsplash

Bu konu bir süredir yazma listemdeydi. Biraz öne alayım dedim, çünkü GitHub öyle güzel bir PR sayfası yapmış ki dayanamadım. Resmen insanlara "siz artık PR review yapmayın" demişler.

Peki gerçekten, bu kadar çok kod AI ile üretilirken biz insanlar review yapmalı mıyız?

Kısa cevap: evet. Ama dün yaptığımız gibi değil.

Soru neden şimdi soruluyor?

Çok yakın bir zamana kadar AI sadece kod tamamlıyordu ve biz buna Woow! diyorduk. Artık iş tarif ediyoruz. O kodu yazıyor. Oturup bir fiil kod yazma işi bitti diyebiliriz. Sadece kodu yazmakla kalmıyor PR açıyor, review edecek insanları ekliyor ve daha fazlasını da yapıyor.

Rakamlar bunu açıkça gösteriyor. GitHub'ın 28 Ekim 2026'da yayımladığı Octoverse 2026 raporuna göre, Mart 2026'da pull request'lerin %17'si bir ajanın ilk taslağıyla başlıyordu. Eylül 2026'da bu oran %40'ı geçti. Sadece Eylül ayında 110 milyon PR ajanlar tarafından başlatıldı; bu, Mart'taki hacmin yaklaşık 6 katı.

Üstelik bu bir alt sınır. GitHub yalnızca tespit edebildiği ajanları sayıyor; editöründe AI ile yazıp PR'ı kendi açan geliştirici bu sayıya dahil değil.

Toplam hacim de aynı yönde: son 12 ayda merge edilen PR sayısı 538 milyondan 1,3 milyara çıktı. Yani günde ortalama 3,5 milyon PR merge ediliyor. Bunları okuyacak insan sayısı ise üç katına çıkmadı.

Biz başkalarının yazdığı kodları önceden neden review ederdik? Bir hata vs bulmak için genelde. Ama kodu insan yazıyordu. Şimdi bir makine yazıyor. Peki makinenin kodunu bir insan gözünün review etmesi artık mantıklı mı?

"Review etmeyelim" diyenler ne diyor?

Hız kaybı. AI bir özelliği dakikalar içinde yazıyor, review ise saatler hatta günler sürebiliyor. Üretim hızı on kat artarken review hızı aynı kalırsa, bütün kazanım kuyrukta bekleyen PR'larda eriyip gidiyor.

Bu sadece bir his değil. Faros AI'ın 10.000'den fazla geliştirici ve 1.255 ekip üzerinde yaptığı analize göre, AI kullanımı yüksek ekipler %98 daha fazla PR merge ediyor, ama PR review süresi de %91 artıyor.

Ancak burada bir soru geliyor aklıma

Bu kadar hız kime ne kazandırıyor?

Testler zaten var. Kod derleniyor, linter temiz, testler yeşil. Davranışı testler doğruluyorsa satır satır okumanın ne anlamı var?

Evet mantıklı. Satır satır okumak artık tarihe karışacak gibi ancak satır aralarındaki detayları nasıl yakalayacağız?

AI zaten iyi. Güncel modeller çoğu ortalama geliştiriciden daha temiz, daha tutarlı kod yazıyor. Hatta bazı ekipler review'u da AI'a yaptırıyor.

Bu tarafın elinde de sayı var. Octoverse 2026'ya göre Eylül 2026'da ajan PR'larının %90'ı iki hafta içinde merge edildi; ajan izi taşımayan PR'larda bu oran yaklaşık %86. Şubat'ta ajan PR'ları %83'teydi, yani yedi ayda insanları geçtiler. Yalnız dikkat: bu sayı kodun merge edildiğini söylüyor, doğru olduğunu değil.

AI kodunun AI'ın review etmesine katılıyorum. Bunu kesinlikle yapmalı. Ancak soru şu hangi kodu? Kodun hangi bölümlerini?

Kimse gerçekten okumuyor. Dürüst olalım: 1.500 satırlık bir diff'e "LGTM" yazıp geçmek zaten yaygın. AI ile diff'ler büyüdükçe bu tören daha da anlamsızlaşıyor.

Bu kesinlikle doğru. Kimse kimseyi kandırmasın.

Bu argümanların ortak noktası şu: review'u bir maliyet olarak görüyorlar. Bence asıl hata da burada.

Neden yine de review etmeliyiz?

Biraz maddeler halinde bu konuya bakalım.

1. Sorumluluk devredilemez

Kodunuz patladığında ya da bir soru geldiğinde Claude yazdı ben bilmiyorum diyemezsiniz. Kodu merge eden kişi onun sahibidir. Okumadığınız bir kodun sahibi olamazsınız; olsa olsa kefili olursunuz.

2. AI'ın hataları insan hatalarına benzemiyor

İnsan yorgunken hata yapar, ve bu hatalar genelde göze batar. AI ise kendinden emin bir şekilde hata yapar. Kod temiz, isimler güzel, yorumlar yerinde; ama mantık yanlış. Tipik örnekler:

  • Var olmayan bir kütüphane fonksiyonunu ya da paketi kullanmak
  • Hata durumunu sessizce yutan bir try/catch
  • Testi geçirmek için testin kendisini değiştirmek
  • İstenenden fazlasını yapmak: kimsenin istemediği bir refactor, gereksiz bir abstraction

Bu hataların ortak özelliği, yüzeysel bir bakışta çok makul görünmeleri. Tam da bu yüzden dikkatli bir göz gerekiyor.

Veriler de bunu destekliyor. Faros AI'ın aynı analizinde AI kullanımı, geliştirici başına bug sayısında %9 artışla birlikte görülüyor. Swarmia'nın aktardığı bir CodeRabbit analizinde ise 470 açık kaynak PR incelenmiş ve AI ile yazılan PR'larda insan yazımı olanlara göre yaklaşık 1,7 kat daha fazla sorun bulunmuş.

3. Testler sadece sorduğunuz soruyu cevaplar

Yeşil testler, kodun test edilen senaryolarda doğru çalıştığını söyler. Hangi senaryoların test edilmediğini söylemez. Testleri de AI yazdıysa, kod ile testler aynı yanlış varsayımı paylaşıyor olabilir. İkisi birbirini doğrular, ikisi de yanlıştır. Ayrıca testler ve kod size UI'ın nasıl çalıştığı söylemez. Otomatik şekilde çalışan UI test'leri de vermediğiniz senaryoları test edemez. Sonuçta insanın kullanacağı bir aracı insan test etmeli.

4. Güvenlik açıkları "çalışan" koddur

QL injection içeren bir sorgu da çalışır. Loglara token basan bir debug satırı da çalışır. Yetki kontrolü atlanmış bir endpoint de çalışır. Güvenlik açığı fonksiyonel bir hata değildir; testlerin çoğu onu yakalamaz.

Veracode'un 2025 GenAI Code Security raporu 100'den fazla modeli 80 kodlama görevinde test etti. Modeller test vakalarının %45'inde OWASP Top 10 kapsamında bir güvenlik açığı üretti. Cross-site scripting'e karşı kodu koruyamama oranı %86, Java'da genel başarısızlık oranı %70'in üzerinde.

Raporun en çarpıcı bulgusu şu: modeller sözdizimi açısından doğru kod yazmada gelişirken güvenlik performansı zaman içinde değişmemiş. Büyük modeller de küçüklerden belirgin şekilde iyi değil. Bu bir laboratuvar testi, gerçek kod tabanlarının ölçümü değil; yine de "model iyileştikçe sorun kendiliğinden çözülür" varsayımını sarsıyor.

5. AI sizin bağlamınızı bilmiyor

En sevdiğim. AI bağlamı bilemez. AI kendisinden önce ne karar verildi bilemez. Kod teknik olarak doğru ama ürün olarak yanlış olabilir. Bu bağlamı sadece siz taşıyorsunuz.

6. Kod tabanını anlamaya devam etmek

PR review yapmayı bırakırsanız yaptığınız işten günden güne uzaklaşır, yabancılaşırsınız. PR review'larının en iyi noktası size kod tabanını öğretmektir. Gece 3'de gelen bir hatayı ancak onun yardımı ile anlıyordunuz. Onu bıraktığınız an nereye bakıp, ne yapacağınızı bilemezsiniz.

Ama review'ın kendisi değişmeli

Artık kabul edelim. İş yapış şeklimiz değişti. Oyunun kuralları değişti. Bu oyunu eskisi gibi oynamaya gerek yok. O şekilde devam ettikçe, AI'ın hızı bizleri ezip geçecek. Artık bu belli.

Makinenin yapabildiğini makineye bırakın. Format, isimlendirme, import sırası, basit tip hataları, bilinen güvenlik kalıpları. Bunlar linter'ın, statik analizin ve AI review araçlarının işi. İnsan dikkati pürüzsüz bir virgül için harcanmamalı.

İnsan niyete baksın, satıra değil. Sorulması gereken soru "bu satır doğru mu?" değil, "bu değişiklik istediğim şeyi mi yapıyor, ve sadece onu mu yapıyor?" olmalı.

Riske göre derinlik ayarlayın. Her değişiklik aynı dikkati hak etmez:

Diff'i küçük tutun. AI'dan tek seferde büyük bir özellik istemek yerine, işi review edilebilir parçalara bölün. 1.500 satırlık diff'i kimse gerçekten okumaz; 150 satırlık diff'i okur.

Gidişat ise tam tersi yönde. Faros AI'a göre AI kullanımı ortalama PR boyutunda %154 artışla birlikte görülüyor. Swarmia'nın 1.450'den fazla mühendislik organizasyonunu kapsayan verisinde de PR başına değişen satır sayısının medyanı, 2025'in ilk çeyreğinden 2026'nın ilk çeyreğine kabaca ikiye katlanmış.

AI'dan kendini açıklamasını isteyin. PR açıklamasında ne yaptığını, neden yaptığını ve neyi yapmadığını yazmasını isteyin. Bu açıklama ile diff arasındaki tutarsızlıklar, çoğu zaman ilk hatanın yeridir.

Bunlar benim aklıma gelenler. Elbet sizlerde daha fazlası vardır. Yorumlara yazın lütfen.

AI kodunu review ederken sorulacak 10 soru

Şimdi minik bir check list yapalım AI ile PR açıldığında neler yapabiliriz.

  1. Bu değişiklik tam olarak istediğim şeyi mi yapıyor, fazlasını değil?
  2. Kimsenin istemediği dosyalara dokunulmuş mu?
  3. Yeni eklenen her paket ve fonksiyon gerçekten var mı, güncel mi?
  4. Hatalar gerçekten ele alınıyor mu, yoksa sessizce yutuluyor mu?
  5. Testler davranışı mı doğruluyor, yoksa implementasyonu mu kopyalıyor? (En önemlisi)
  6. Mevcut bir test silinmiş, atlanmış ya da gevşetilmiş mi? (Daha da önemlisi)
  7. Kullanıcı girdisi, yetki kontrolü ve gizli bilgiler (token, şifre, anahtar) doğru ele alınmış mı? (Aman haa!)
  8. Bu kod ekibin mevcut kalıplarına uyuyor mu, yoksa yeni bir "tarz" mı getiriyor?
  9. Edge case'ler düşünülmüş mü: boş liste, null, eşzamanlılık, zaman dilimi?
  10. Altı ay sonra bu kodu okuyan biri ne yaptığını anlayabilir mi? (AHAHA)

Sonuncu bomba dimi? AI kodu yazmayı ucuzlattı evet ama okuma maliyeti hala çok pahallı.

Sonuç: Evet, ama başka bir review

Review edeceğiz. Bunu bırakmanın alemi yok. AI kodu kötü yazar vs yüzünden değil. Kodun sorumluluğunu ve bağlamını bırakmamak, sistemi anlamak için review'a devam.

Değişen şey review'un içeriği. Eskiden virgüllere, isimlere, format hatalarına bakıyorduk. Artık bunları makinelere bırakıp niyete, riske ve bağlama odaklanmamız gerekiyor. Rolümüz yazardan editöre dönüşüyor.

Kod yazmak artık ucuz. Ama yanlış kodu production'a göndermek hâlâ eskisi kadar pahalı. Review, bu iki gerçek arasındaki köprü.

İlginç olan, GitHub'ın kendi raporunun da aynı yere varması: kodun çalışıp çalışmadığına, oraya ait olup olmadığına ve iyi olup olmadığına hâlâ birinin karar vermesi gerektiğini söylüyor.

Peki siz neler yapıyorsunuz? Review süreçleriniz var mı? Yoksa vur APPROVE mu?

Kaynaklar

Sıradakini oku

Yorumlar ()