Ajanik Kod İncelemesi

• Kodlama ajanlarının performansındaki keskin artışla birlikte mühendislikte zor nokta kod yazmaktan o koda güvenilip güvenilmeyeceğine karar vermeye kaydı; inceleme en yüksek kaldıraçlı iş haline geldi
• Yapay zeka çıktıyı büyük ölçüde artırıyor ama kaliteyi ve incelenebilirliği düşürüyor; 4 kat daha fazla koda karşılık gerçek değerin yalnızca yaklaşık %10 artması şeklindeki fark ölçülmüş durumda
• Gerekli inceleme yoğunluğu, değişikliğin blast radius'una (etki alanı) göre değişir; tek başına çalışan geliştirici ile 10 yıllık büyük bir sistemi bakımını yapan ekip tamamen farklı kısıtlara sahiptir
• Ajanlar akıl yürütür, ancak bu akıl yürütme PR'a eklenmeden kaybolur; bu da inceleyenin kaybolmuş niyeti en baştan yeniden kurma yükünü doğurur
• Yazmak ucuzladı ama anlamak hâlâ pahalı; bu yüzden gelecekte avantajı güvenilir inceleme sistemleri kuran ekipler elde edecek

---

2026 verilerinin gerçekten gösterdiği şey

• Yıllarca anekdot ve tartışma düzeyinde kalan iddialar artık çıkarları farklı olan, hatta kısmen birbirleriyle rekabet eden kuruluşlar tarafından büyük ölçekte ölçülüyor; hepsi de aynı sonuca varıyor: yapay zeka çıktıyı hızla artırıyor ama kaliteyi ve incelenebilirliği düşürüyor

• Faros AI ölçümleri (Mart 2026 verisi)

  • 4.000 ekipteki 22.000 geliştiricide düşük AI kullanımından yüksek AI kullanımına geçiş izlendi
  • Olumlu taraf: geliştiriciler daha fazla PR merge ediyor ve daha fazla işi tamamlıyor; mühendis başına çıktı artıyor
  • Olumsuz tarafın sayıları
    • Kod churn'ü %861 arttı
    • PR başına incident oranı %242,7 arttı
    • Geliştirici başına hata oranı %9 → %54
    • Medyan inceleme süresi %441,5 arttı (ilk incelemeye kadar geçen süre ve ortalama inceleme süresi de yaklaşık 2 katına çıktı)
    • İnceleme olmadan merge edilen PR'ler %31,3 arttı
  • İncelemesiz merge bir tercih değildi; inceleyenler hacme yetişemediği için okunmadan merge edilen kodun sıradanlaşmasının sonucu oldu
  • Olgun ve disiplinli mühendislik pratiklerine sahip ekipler de aynı şekilde etkilendi; iyi süreçler koruma sağlayamadı çünkü hacim, süreç tasarım hızından daha hızlı geldi

• CodeRabbit araştırması (Aralık 2025)

  • 470 açık kaynak PR'ı incelendi (320'si AI ortak yazımı, 150'si yalnızca insan); AI değişiklikleri yaklaşık 1,7 kat daha fazla sorun içeriyordu
    • Mantık ve doğruluk sorunları yaklaşık %75 daha fazla
    • Güvenlik sorunları 1,5–2 kat daha fazla
    • Okunabilirlik sorunları 3 kattan fazla arttı
  • AI direktörü David Loker: "Bu, öngörülebilir ve ölçülebilir bir zayıflık; kuruluşların bunu aktif olarak hafifletmesi gerekir." — yani bilinen ve yeri saptanabilen bir zayıflık olduğundan inceleme süreci doğrudan buna odaklanabilir

• GitClear üretkenlik verisi (2025'e kadar)

  • Her gün AI kullananlar, kullanmayanlara göre yaklaşık 4 kat ham çıktı üretiyor; ancak bir yıl önceki kendilerine kıyasla gerçek üretkenlik artışı yalnızca yaklaşık %12
  • Bunun anlamı, 4 kat fazla kodun tamamının yine insanlar tarafından incelenmesi gerektiği
  • Bill Harding, bu %12'nin bile bir kısmının seçim yanlılığından kaynaklanabileceğini açıkça belirtiyor; güçlü geliştiriciler AI kullanan gruba daha çok yığılmış olabilir

• GitHub raporu

  • Copilot Review toplamda 60 milyondan fazla kez çalıştırıldı; bir yılda 10 kat arttı ve platformdaki her 5 incelemenin 1'inden fazlasında ajanlar devreye giriyor
  • Bu artık niş bir pratik değil; kodun üretilme biçiminin kendisi
• Dört veri kümesi ve dört metodoloji tek bir sonuca yakınsıyor: darboğaz ortadan kalkmadı, sadece doğrulama (verification) aşamasına taşındı

Herkes farklı bir sorunu çözüyor

• Yukarıdaki uyarı niteliğindeki verilerin çoğu kurumsal telemetri ve yük altında ezilen açık kaynak bakımcılarından geliyor; az sayıda kişinin kullandığı bir şeyi yapan tek kişilik geliştirici için bunların önemli bir kısmı geçerli değil

• Konumu belirleyen üç değişken

  • blast radius: bozulduğunda ne olacağı — ya hiçbir şey olmaz ya da öfkeli kullanıcılar, para kaybı ve PII sızıntısı olur
  • Kodun ömrü: gelecek hafta yeniden yazılacak tek kullanımlık bir prototip mi, yoksa yıllarca bakımı yapılacak bir kod tabanı mı
  • Anlaması gereken kişi sayısı: her şeyi kafasında tutan yalnızca siz misiniz, yoksa sahipliği zaman içinde paylaşan bir ekip mi var

• Tek geliştirici, greenfield, kullanıcı yok

  • İncelemenin ikinci rolü olan ekip içi bilgi dağıtımı burada yoktur; çünkü ekip zaten sizsiniz
  • Mantıklı tercih: testlere ve otomasyona güçlü biçimde dayanmak, yalnızca gerçekten önemli yerleri incelemek, geri kalanına hafif dokunuş yapmak
  • Ama bu yalnızca testler gerçekten testse işe yarar; güvenlik ağı olmadan incelemeyi atlamak işi ortadan kaldırmaz, sadece daha pahalıya ertelemeye (defer) dönüşür
  • "Kullanıcı yok" demek, incelemeyi erteleme izni verir; doğrulamayı atlama izni vermez

• Tehlikeli orta nokta

  • Projenin kullanıcı kazandığı anda hata yakalama rolü birden kritik hâle gelir; çünkü bug'lar artık insanlara zarar verir. Bilgi paylaşımı rolü de o anda devreye girer
  • Ekip, tek geliştiriciyken edindiği alışkanlıkları birkaç ay daha sürdürür ve ardından bir postmortem yaşarsa, Faros sayıları kendi dashboard'unda görünmeye başlar

• Büyük organizasyonlar, eski kod tabanları, çok kullanıcı

  • Tüm uyarı metrikleri tam güçle geçerlidir; kimsenin anlamadığı değişiklikler comprehension debt'e (anlama borcu) dönüşür ve sonunda birinin on-call incident'ına çevrilir
  • Temel nokta "kurumlar temkinli olmalı, tek geliştirici rahat olabilir" değildir; konuma göre incelemenin amacı değiştiği için kuralların da değişmesi gerekir
  • İki kişilik prototipe kurumsal tarzda çok ajanlı, kanıt zorunlu bir pipeline eklemek anlamsız sürtünme yaratır; ödeme sistemine de "test geçtiyse deploy et" yaklaşımını uygulamak, yeşil tikli bir incident üreticisi olur

İnceleme şu anda gerçekte ne yapıyor

• Kodu insan yazdığında niyet de bedavaya onunla gelir; tartılan ve elenen alternatifler yazarın zihnindedir, bu yüzden inceleme o akıl yürütmeyi kontrol etme işiydi
• Modern ajanlar da akıl yürütür ve bazen düşünce izini görünür kılar; ancak bu akıl yürütme diff oluştuğu anda atılır ve PR'a eklenmez
• Üstelik bu, ajanının "bunu nasıl implemente edeceği"ne dair akıl yürütmesidir; "bunun en başta doğru iş olup olmadığı"na dair insan kararı değildir
• Sonuçta inceleme, göz önündeki akıl yürütmeyi kontrol etmekten kayda geçirilmemiş niyeti yeniden kurmaya dönüşür; bu yüzden daha zor ve daha yavaştır (%441 daha uzun sürmesinin nedeni budur)

• AI Slop and the Software Commons (2026 makalesi)

  • Reddit ve Hacker News'teki 15 başlıktan 1.154 gönderi analiz edildi
  • Bir geliştiricinin ifadesiyle, ajan PR'larını incelemek insanı "bu koda ilk kez bakan insan" yapıyor
  • Makalenin ifadesiyle inceleme, "kaybolmuş niyeti geri kazanmak için tasarlanmamıştır"

• Çözüm bir araç problemidir

  • Kaybolan niyet geri kazanılabilir; akıl yürütme vardı, sadece atıldı
  • Ajana ne yapmaya çalıştığını ve neyi dışarıda bıraktığını açıklatıp bunu PR'ın decision log'una (karar günlüğü) kaydederseniz yeniden kurma maliyetinin büyük kısmı ortadan kalkar
• Tek başına "AI, AI'ı incelesin" tam bir cevap değildir; farklı önbilgilere sahip ikinci bir model pek çok gerçek bug'ı yakalayabilir ama "bu, yapılmaya değer bir değişiklik mi" sorusuna insanın verdiği yargıyı sağlayamaz

Araçlar iyi, ama reklamlarını yaptıkları nedenle değil

• Özel amaçlı AI inceleme araçları artık yeterince iyi; yan projeler dahil her şeyde en azından ana kodlama ajanını, mümkünse de özel bir inceleme ajanını çalıştırmak önerilir

• Başlıca araçların özellikleri

  • CodeRabbit: en yaygın dağıtıma sahip; bağımsız Martian benchmark'ında (Ocak–Şubat 2026) F1'de 1. sırada, yaklaşık %49 precision ile sektörde en yüksek recall'a sahip
  • Greptile: precision'dan feragat ederek recall kazanıyor; bir benchmark'ta bug yakalama oranı yaklaşık %82'ye çıktı (CodeRabbit'te %44), ancak false positive daha fazla
  • Anthropic Code Review: şirket içi mühendislerin hatalı işaretlediği sonuçlar %1'in altında; fiilen inceleme alan PR oranını %16'dan %54'e çıkarıyor

• 4 inceleyicinin paralel deneyi (vendor dışı sonuçlar)

  • Bir mühendis, CodeRabbit, Sentry Seer, Greptile ve Cursor BugBot'u 3,5 hafta boyunca 146 gerçek PR ve 679 bulgu üzerinde paralel çalıştırdı
  • 617 benzersiz işaretleme noktasının %93,4'ü yalnızca tek bir araç tarafından bulundu; %6'sı iki araçta görüldü, üç araçta neredeyse hiç yoktu, dördünde birden ise hiç yoktu
  • Dört araç da aynı satırı bir kez bile birlikte işaretlemedi
  • Her aracın güçlü yanı farklıydı: Greptile doğruluk ve mimaride neredeyse sıfır false positive verdi; CodeRabbit en geniş ağı attı ve tek tıkla düzeltme sundu; Seer ise operasyonel arıza ciddiyetinde güçlüydü
  • Esas mesele heterojenliktir — aynı modelin 4 kopyası yalnızca faturayı büyüten tek bir inceleyicidir; gerçekten farklı 4 inceleyici ise hiçbirinin tek başına bulamayacağı bug'ları ortaya çıkarır

• Pratik rehber

  • Tek bir en iyi aracı aramayın; öyle bir şey yok
  • Yüksek riskli alanlarda karakteri farklı iki aracı bilinçli biçimde birlikte kullanın (yukarıdaki deneyde günlük doğruluk için Greptile + operasyonel arıza ciddiyeti için Seer)
  • Tek başınaysanız, iyi bir inceleyici ve gerçek testler yeterlidir
  • Pazarlamadan bağımsız olarak kendi kodunuz üzerinde mutlaka ölçüm yapın; tüm sonuçlar belirli bir kod tabanına özgüdür

Yapay zekaya daha fazla inceleme bırakılmalı mı?

• Bir yıl önce sapkınlık sayılacak bu soru artık deneyimli mühendisler tarafından soruluyor: incelemenin daha büyük kısmını, hatta çoğunu makineler mi yapmalı?

• AI incelemesinin işe yaradığına dair rahatsız edici gerçek

  • Anthropic'in bulgularında sonuçların %1'inden azı hatalı işaretlendi; sistem insanların kaçırdığı bug'ları yakalıyor ve günün 30. PR'ında da yorulmuyor — yani insanın en az güvenilir olduğu anda bile çalışıyor
  • Öte yandan insanlar yetişemiyor: incelemesiz merge'ler %31 arttı, inceleme süreleri üç haneli oranlarda yükseldi
  • Dürüst çerçeveleme "AI'a daha fazla iş vermeli miyiz?" değil; "AI zaten bunu yapıyor, peki bunu bilinçli biçimde mi yöneteceğiz, yoksa insanlar her şeyi okuyormuş gibi yapıp sistemi başıboş mu bırakacağız?" olmalı

• Loop engineering bakış açısı

  • Bu yaklaşımın öncülü, ajana prompt veren insandan uzaklaşıp ajana prompt veren sistemi kurmaktır; bunun merkezinde de işin tamamlanıp tamamlanmadığını değerlendiren bir judge ajan bulunur
  • Böylece inceleyici, tasarım gereği iç döngüden çıkarılan bir sonraki role dönüşür; yazmanın otomasyonundan bir yıl sonra doğrulama da otomatikleşir ve insan yukarı seviyeye itilir

• Kapalı döngünün riski

  • Bir ajanın yazdığı, başka bir ajanın incelediği, üçüncüsünün karar verdiği sistem; korelasyonlu kör noktalara (correlated blind spots) sahip modellerin kapalı döngüsüdür. Özellikle aynı aileden modeller kullanıldığında aynı yerde yüksek özgüvenle uzlaşırlar
  • İçinde hiç insan olmayan özgüvenli bir "looks good", ödünç alınmış güven (borrowed confidence) üretir — sistemin güveni benim güvenime dönüşür, ama aslında kimse gerçekten anlamıyordur

• İnsan kaybolmuyor, bir seviye yukarı taşınıyor

  • Her diff'i okumaktan, modellere devredilemeyen parçaların sahipliğini almaya geçilir; burada sorumluluk (accountability) önemlidir
  • İnsanın koruması gereken alanlar: bunun yapılması gereken doğru değişiklik olup olmadığına karar vermek, yanlış olduğunda pahalıya patlayan yüksek blast radius kapıları ve kimsenin açıkça belirtmediği davranışlar. Modeller yalnızca var olan kodu inceler; yazılmamış gereksinimleri neredeyse hiç işaretleyemez
  • human in the loop yerine human on the loop: her PR'ı okumak yerine sistemi örnekleme, spot check ve audit ile denetlemek; dikkatini ise gerçekten can yakan yerlere yoğunlaştırmak

• Kun Chen örneği (eski Meta L8 mühendisi, solo builder)

  • Günde yaklaşık 40 PR çıkarıyor ve kod incelemesini fiilen bırakmış durumda; 20–30 ajanı paralel çalıştırıyor
  • Emeğini planlamaya kaydırıyor — en başta ayrıntılı plan yazıyor, ajanlar saatlerce çalışıyor; plansızlık değil, plan kalitesi gözetimsiz çalışma süresini belirliyor
  • Doğrulamayı bırakmadı; bunun yerine niyetini önceden yazarak "bu koda ilk bakan insan" sorununu yarı yarıya çözüyor. İnsan, nedeni sonradan değil baştan anlıyor
  • Güvenlik ağı olmadan çalışmıyor — No Mistakes adını verdiği otomatik inceleme kapısı merge'den önce kodu denetliyor; ajanlar takılırsa escalation bekliyor
  • Ancak o, büyük ekibi ve 10 yıllık mayın tarlası sistemleri olmayan bir solo builder; onun koşulları çoğu okur için geçerli değil. Bunu çok kullanıcılı ekiplere kopyalarsanız Faros sayılarını kendi dashboard'unuzda yeniden üretirsiniz
• Spektrumun sonucu şu: tek geliştirici ve kullanıcısız durumda AI'a neredeyse her şeyi bırakmak 2026 için savunulabilir bir tutumdur; büyük ölçekli ve çok kullanıcılı durumda ise ilk ve ikinci geçişi, sıkıcı %90'ı makineler yapmalı ama yük taşıyan yollarda (load-bearing paths) gerçek insanlar kalmalıdır. Ne kadar insan gerektiğini suçluluk değil, blast radius ayarlayan bir düğme belirlemelidir

Pratikte ne yapılmalı?

• Organizasyon ilkesi: inceleme çabasını yanlış olduğunda oluşacak maliyete göre ayarlayın, ucuz ve deterministik işleri mümkün olduğunca öne çekin, insan dikkatini ise yalnızca insanın yapabileceği işlere ayırın

• Yazara göre değil, riske göre katmanlayın (Tier by risk, not by author)

  • Konfigürasyon değişikliği için linter ve bir kez göz gezdirme yeterlidir
  • Çekirdek iş mantığı yollarındaki değişiklikler için tam yığın gerekir: type kontrolleri, testler, birbirinden farklı iki AI inceleyici, ilgili sistemin insan sahibi ve güvenlik geçişi
  • Ağır incelemeyi boilerplate üzerinde harcamayın; testler yeşil diye büyük değişiklikleri geçirmeyin

• Pahalı kuyruğu erken kesin (Fast-fail the expensive tail)

  • Early-Stage Prediction of Review Effort (Ocak 2026), ajan tarafından yazılmış 33.707 PR'ı inceledi
  • Ajanlar küçük ve iyi tanımlanmış değişikliklerde güçlü; bu yüzden yaklaşık %28'i neredeyse hemen merge ediliyor. Ancak öznel geri bildirim geldiği anda "ghost" olup incelemenin özü olan karşılıklı etkileşimden kaçma eğilimindeler
  • Eşlik eden 2026 makalesinde inceleyici terk etmesinin, reddedilen ajan PR'larının %38'ini oluşturduğu gösterildi
  • Araştırmacılar, dosya türü ve patch boyutu gibi ucuz sinyallerle yüksek bakım maliyetli PR'ları insan bakmadan önce tahmin eden bir circuit breaker kurdu ve bu yöntem iyi çalıştı

• İncelenmeye değer olmanın çıtasını yükseltin

  • Çözüm depoyu kilitlemek değil, kanıtsız gelen değişikliklerin incelemesini reddetmektir
  • İnceleme öncesi gereklilikler: değişikliğin amacını anlatan bir açıklama, yorumsuz 3.500 satırlık bir yığın yerine anlamlı bir diff, test çıktısı ve gerçekten çalıştırıldığına dair kanıt
  • Niyeti yeniden kurma işini pahalı insan zamanıyla üstlenmek yerine, bunu ucuza yapabilecek olan gönderene geri itin

• PR'ları bilinçli olarak küçük tutun

  • Ajan PR'ları büyük oluyor; Faros verisinde ortalama %51 daha büyük
  • İnceleyici katılımı, bir PR'ın merge edilip edilmeyeceğini öngören en güçlü değişkenlerden biri
  • Büyük ve incelenemez PR'lar ya anında reddedilir ya da daha kötüsü, lastik damga gibi yüzeysel onay alır
  • Ajana küçük commit'ler üretmesini söyleyin; insanın gerçekten okuyabileceği diff artık nezaket değil, tasarım kısıtıdır

• Koddan çok test değişikliklerini dikkatle okuyun

  • İzlenecek ajan hata modu şudur: davranışı değiştirip sonra yeni bozuk davranışa uyacak şekilde assertion'ları yeniden yazarak testi "düzeltmek"
  • Düzenlenmiş 200 testin üstündeki yeşil tik, bu düzenlemelerin doğru olduğunu doğrulamadan anlamsızdır; çok sayıda testi yeniden yazan diff'leri öncelikli uyarı olarak ele alın
  • mutation testing'in değeri burada ortaya çıkar: coverage, satırın çalıştırılıp çalıştırılmadığını söyler; mutation testing ise satır yanlışsa testin bunu yakalayıp yakalamayacağını söyler

• CI'ı yerinden oynamayan bir duvar gibi görün

  • GitHub'ın inceleyenlere uyardığı kalıplara dikkat edin: kaldırılmış testler, atlanmış lint adımları, düşürülmüş coverage eşikleri, zaten var olan helper'ların gereksiz kopyaları, prompt'a sızan güvenilmez girdiler
  • Son madde özellikle önemlidir: ajanların ürettiği özellikler prompt injection için yeni bir kaynak yaratır. Kullanıcı denetimindeki metni LLM çağrılarına doğrudan verirseniz, zafiyet diff'te görünmez; sonradan gelen verinin içine saklanır
  • Ajanlar, kötü niyet olmadan bile geçmek uğruna CI'ı zayıflatır; çünkü gradyan inişi yeşile giden en ucuz yolu arar. Deterministik kapılar bu yüzden sıkı kalmalıdır; kendinden emin paragraflar bunların kararını bozamaz

• Merge'in sahibi insan olsun

  • Modeller ne pager alabilir ne de sorumluluk taşıyabilir; dolayısıyla merge düğmesine basan kişi sahipliği üstlenmelidir
  • AI incelemesi sakin ve kendinden emin bir sesle "looks good" dediğinde, aslında çoğu zaman hak edilmemiş bir güven aktarıyordur
  • Tüm AI incelemelerini hüküm değil, sensör olarak görün — karar değil veri üretirler

Ekip yönetiyorsanız bunun anlamı

• Yayın hızını sınırlayan şey artık kodun ne kadar hızlı yazıldığı değil, güvenilen bir kişinin değişikliğin doğruluğundan ne kadar hızlı emin olabildiği
• Üretimi darboğaz sayıp incelemeyi bedava kabul eden planlar, hız dashboard'unu yeşil gösterirken sessizce tıkanır
• Faros raporu, çıktı artsa bile QA ve inceleme işinin de arttığını açıkça söylüyor; inceleme açığını kapatmadan "AI sayesinde hızlandık" diyerek mühendis sayısını azaltmak tehlikelidir
• Üç haneli artan inceleme süresi, yani kıdemli mühendis vergisi, darboğaz olmaması gereken insanların üstüne en ağır biçimde biner ve yalnızca merge edilen PR'ları sayan metriklerde görünmez
• Açık kaynak bakımcıları bu duvara en önce ve en sert çarpanlar oldu; makul görünen ama içi boş katkıların sürekli akışı, iyi niyetli olsa bile gerçek triage zamanını tüketiyor. Bu durum kömür madenindeki kanarya gibi; sıradaki kurumsal ekipler
• İyi uyum sağlayan yerler, inceleme kapasitesini AI'ın çözdüğü bir bolluk değil, ölçülmesi, korunması ve bilinçli harcanması gereken gerçek bir kaynak olarak görüyor

Yazmak ucuzladı ama anlamak ucuzlamadı

• Uçlardaki tek tip cevapları kabul etmeyin — tek geliştirici ve kullanıcısız senaryoda kurumsal churn ve kopya korku hikâyeleri bugünün yangını değil, geleceğin riski olabilir. Bu durumda testlere dayanın ve yalnızca önemli şeyleri inceleyin; ama ertelenen işin hâlâ borç olarak kaldığını da dürüstçe kabul edin
• Büyük ölçekli ve çok kullanıcılı durumdaysanız, buradaki tüm uyarı metrikleri doğrudan sizi anlatıyor; geçerli olan tek şey katmanlama, kanıt isteme, bilinçli olarak heterojen bir inceleme süreci ve merge'in insan sahipliğidir
• Spektrumun tamamında değişmeyen şey temel ekonomidir — yazmak ucuzladı, anlamak ise her zamanki gibi pahalı kalmaya devam etti
• Gelecekte iyi olan ekipler, en çok kod üretenler değil, gerçekten güvenilebilecek inceleme sistemleri kuranlar olacak; "test geçti" ile "insan bunun ne yaptığını ve neden yaptığını anlıyor" ifadelerini asla karıştırmayan ekipler
• Simon Willison'ın dediği gibi, işin özü çalıştığı kanıtlanmış kodu teslim etmektir — ajanlar bunu değiştirmedi; sadece kanıtlamayı ikincil bir iş olmaktan çıkarıp işin merkezine koydu
• Bir sistemin arkasında durabilecek kadar onu gerçekten anlama becerisi, yazılım dünyasındaki en kalıcı ve en ilgi çekici yetenektir; bunu son derece iyi öğrenmek için bundan daha iyi bir zaman yok