AI ile yazılan kodu nasıl gözden geçirmeli? Kalite kuralları ve kabul ölçütleri

Kısa cevap: AI ile yazılan kodu gözden geçirmek, hata aramaktan çıkıp niyet doğrulamaya dönüşmek zorunda. Üretilen kod neredeyse her zaman derleniyor, biçimi düzgün, okununca makul geliyor. Arıza başka yerde birikiyor: elinizde zaten duran fonksiyonu çağırmak yerine benzerini yeniden yazan kopyalar, beklenmeyen girdiyi sessizce yutan hata blokları, sınır durumlarını atlayan mantık ve hiç var olmayan paketlere verilen import satırları. Bunların hiçbirini derleyici yakalamaz. Yakalayabilecek tek şey, kabul ölçütleri yazılı hale getirilmiş bir gözden geçirme süreci ve testlerin gerçekten kapı olarak çalıştığı bir dağıtım hattıdır.

Hız arttı, istikrar bozuldu

Google'ın DORA ekibinin 2025 raporu, sektör çalışanlarının yüzde 90'ının işinde AI kullandığını ve yüzde 80'den fazlasının verimliliğinin arttığına inandığını söylüyor. Aynı raporda iki bulgu yan yana duruyor: AI kullanımının artışı teslim hızıyla olumlu, teslim istikrarıyla olumsuz ilişkili. Daha çok değişiklik daha hızlı yayına çıkıyor, aynı zamanda daha çok değişiklik geri dönüyor. Değişiklik başarısızlık oranı ve yeniden çalışma yükü yukarı gidiyor.

DORA'nın kendi özeti şu: AI bir yükselticidir. Ekibinizi düzeltmez, hâlihazırda ne varsa onu büyütür. Test otomasyonu zayıf, sürüm kontrolü dağınık, gözden geçirmesi göstermelik olan bir ekipte AI kusuru daha hızlı üretir. Aynı raporda geliştiricilerin yüzde 30'u AI'nın ürettiği koda az güvendiğini ya da hiç güvenmediğini belirtiyor. Bu güvensizlik boşuna değil, ama kullanımı da yavaşlatmıyor. İkisi bir arada olduğunda ortaya çıkan şey, kimsenin tam olarak sahiplenmediği kod.

Kalite sinyalleri hangi yöne gidiyor

GitClear, 2023 ile 2026 arasındaki 623 milyon kod değişikliğini inceleyip sekiz kalite sinyalini izledi. Tablo tek yöne bakıyor. Beş satır ve üzeri tekrar eden kod blokları yüzde 81 arttı. Taşınan satırlar, yani gerçekten yeniden düzenlenen kod, yüzde 70 düştü. Yeni commitlerin var olan fonksiyonları çağırma sıklığı yüzde 35 azaldı. Hatayı bastıran yapıların yoğunluğu yüzde 47 arttı; buraya boş yakalama blokları, güvenli gezinme operatörleri ve gövdesi doldurulmamış metotlar giriyor. Bir yıldan uzun süre dokunulmamış kodu temizleyen değişiklikler yüzde 74 geriledi.

Bu bir korelasyon, nedensellik kanıtı değil. Yine de mekanizma tahmin edilebilir. Bir model sizin depoya bakmadan, en fazla açık dosyalar ve birkaç yüz satırlık bağlamla çalışır. Sizin formatCurrency yardımcınızın üç klasör ötede durduğunu bilmez, bu yüzden yeni bir tane yazar. Sizin hata sınıflarınızın nasıl loglandığını bilmez, bu yüzden hatayı yakalar ve yutar. Sonuç yanlış değil, çalışıyor. Sadece kod tabanınızın ortak yapısını her seferinde biraz daha eritiyor. Bu birikimin adı teknik borç ve bu sefer faizi eskisinden hızlı işliyor.

En pahalı hata türü: neredeyse doğru

Stack Overflow'un 2025 geliştirici anketinde kullanıcıların yüzde 84'ü AI araçlarını kullanıyor ya da kullanmayı planlıyor, ama doğruluğuna güvendiğini söyleyenler yüzde 29'da kalıyor. Yüzde 46 güvenmediğini söylüyor. En büyük tek şikâyet, katılımcıların yüzde 66'sında aynı: "neredeyse doğru ama tam değil" çözümler. Yüzde 45'i AI'nın ürettiği kodu ayıklamanın daha uzun sürdüğünü bildiriyor.

Bu, gözden geçirme açısından önemli bir ayrım. Bariz yanlış kod ucuzdur; ilk testte ya da ilk okumada düşer. Pahalı olan, doğru gibi duran koddur. Yanlış varsayımı doğru sözdizimiyle, düzgün isimlendirmeyle ve inandırıcı bir yorum satırıyla birlikte getirir. Gözden geçiren kişi kodun biçimine bakar, biçim temizdir, onay verir. METR'in Temmuz 2025'te yayımladığı kontrollü deney bu kör noktayı ölçtü: deneyimli açık kaynak geliştiricileri AI kullanmalarına izin verilen görevlerde yüzde 19 daha yavaş bitirdi, ama sonradan ortalama yüzde 20 hızlandıklarını tahmin ettiler. METR bu sonucu artık tarihsel olarak etiketliyor, çünkü araçlar o günden bu yana değişti. Yönü değişmeyen bulgu ise algı ile ölçüm arasındaki fark. Hız hissi bir metrik değildir.

Gözden geçirmede fiilen neye bakılır

Kabul ölçütlerini yazın ve gözden geçirme şablonuna koyun. Aşağıdakiler AI ile üretilmiş bir değişiklikte en sık kaçan yerler:

• Yeniden kullanım. Bu fonksiyonun benzeri depoda zaten var mı? Aramadan onay verilmesin. Duplikasyon artışının tek çaresi bu soru.
• Hata yolu. Yakalanan hata gerçekten ele alınıyor mu, yoksa sadece susturuluyor mu? Boş yakalama bloğu ve gövdesi doldurulmamış metot reddedilir.
• Sınır durumları. Boş liste, null, sıfır, negatif değer, çok büyük girdi, eşzamanlı ikinci istek. Model mutlu yolu yazar; kenarları soran gözden geçirendir.
• Testin kendisi. AI'nın yazdığı test sıklıkla uygulamanın aynasıdır ya da yalnızca mock'a bakar. Testi bozup çalıştırın; kırmızıya dönmüyorsa test yok demektir.
• Veri erişimi. Döngü içinde sorgu, eksik indeks, gereksiz tam tablo taraması. Bu kalıplar ölçekte ortaya çıkar, gözden geçirmede ucuza yakalanır.
• Sır ve yapılandırma. Örnek anahtarlar, gömülü bağlantı dizeleri, sabitlenmiş uç nokta adresleri. Bu konu için sır yönetimi notumuz daha ayrıntılı.
• Bağımlılıklar. Yeni bir paket eklenmişse: var mı, bakımı sürüyor mu, lisansı uygun mu, gerçekten gerekli mi?

Son madde göründüğünden daha ciddi bir konu.

Var olmayan paket sorunu

On altı farklı dil modeliyle üretilen 576 bin kod örneği üzerinde yapılan akademik çalışma, önerilen paketlerin yüzde 19,7'sinin hiç var olmadığını buldu. Yaklaşık her beş öneriden biri, kulağa doğru gelen ama kayıtta karşılığı olmayan bir isim. Saldırganlar bunu fark etti ve modellerin tekrar tekrar uydurduğu isimleri kendileri kayda geçirmeye başladı. Bu tekniğin adı slopsquatting. Kurulum komutunu kopyalayan geliştirici, boş bir isim yerine saldırganın paketini indirir.

Savunma karmaşık değil ama otomatik olmak zorunda. Kilit dosyası olmadan kurulum yapılmasın. Yeni bağımlılık ekleme kararı gözden geçirmeden geçsin. Dahili bir kayıt vekili (registry proxy) kullanıyorsanız izin listesi tanımlayın. CI hattında bağımlılık denetimi ve bilinen zafiyet taraması çalışsın. Bir paket adını AI önerdiği için değil, kayıtta gerçekten yaşadığını ve bakımının sürdüğünü gördüğünüz için kurun. Konunun tamamı yazılım tedarik zinciri güvenliği başlığının altına giriyor.

Kuralları depoya yazın, her seferinde tekrar etmeyin

DORA'nın raporunda AI'dan fazla verim alan ekiplerin ortak özelliklerinden biri şu: dahili kod tabanı ve dahili veri, araçların erişebileceği yerde duruyor. Pratik karşılığı, kuralları depoya yazmak. Kullandığınız araç ne olursa olsun (birçoğu artık depo kökünde bir talimat dosyası okuyor) orada şunlar yazılı olsun: hangi yardımcı modüller var ve nerede duruyor, hata nasıl loglanıyor, hangi test çerçevesi kullanılıyor, hangi kalıplar yasak, yeni bağımlılık eklemenin kuralı ne. Model her seferinde sıfırdan tahmin etmek zorunda kalmadığında, sizin fonksiyonunuzun kopyasını yazma eğilimi belirgin biçimde azalıyor.

Bir de şu ayrım var: kuralı düz yazıyla anlatmak ile makineyle uygulatmak aynı şey değil. Bir wiki sayfasındaki paragrafa hem insanlar hem araçlar aynı oranda uyar, yani pek uymaz. Linter kuralı, biçimlendirici, tip denetimi ve mimari sınır kontrolü ise tartışmasız çalışır. Yasaklamak istediğiniz her kalıbı önce lint kuralına çevirmeye çalışın; çevrilemeyenler gözden geçirme şablonuna kalsın. Bu ikisi kısaldıkça gözden geçiren kişi biçimle uğraşmayı bırakıp mantığa bakabiliyor.

Parça büyürse gözden geçirme sahte olur

AI'nın en gerçek etkisi kod üretme maliyetini düşürmesi. Sekiz yüz satırlık bir değişiklik artık bir öğleden sonra işi. Gözden geçirenin dikkati aynı hızda ölçeklenmiyor. Büyük yığınlarda insan gözü hızla yüzeye kayar: isimlendirme, biçim, belirgin kopyalar. Mantık kontrol edilmez, çünkü kontrol edilemez.

Kural basit. Bir istek tek amaç taşısın, tercihen üç yüz satırın altında kalsın. Üretilen kodu gönderen kişi ne yaptığını anlatabiliyor olsun; anlatamıyorsa birleştirilmez. Bu kulağa katı geliyor, pratikte tek gerçek filtre. Küçük parçalar aynı zamanda sıfır kesintili yayına alma için de şart, çünkü geri alınabilir birim küçüldükçe risk küçülür.

Testler süs değil, kapı

DORA'nın bulgusunun pratik karşılığı şu: hız artışını istikrar kaybına dönüştürmeyen tek mekanizma otomatik doğrulama. Üretim hacmi ikiye katlanırken doğrulama kapasitesi aynı kalırsa fark üretime sızar. Bu yüzden AI kullanımını artırmaya karar veren ekibin ilk yatırımı araç lisansı değil, test otomasyonu olmalı.

Dikkat edilecek nokta, kapsama oranının aldatıcı hale gelmesi. AI test yazmakta hızlıdır ve yazdığı testler kapsama sayısını rahatça şişirir. Kapsama, kodun çalıştırıldığını gösterir; doğru davrandığını göstermez. Kritik modüllerde mutasyon testi gibi bir teknikle testlerin gerçekten hata yakaladığını doğrulamak, tek başına oran takip etmekten daha bilgi verici. Bir de şu alışkanlık: yeni bir hata çıktığında önce onu yakalayan testi yazın, sonra düzeltin. Aynı hata iki kez gelmez.

İmzayı kim atıyor

Bu artık teknik değil, yönetişim sorusu ve büyük projeler cevabı yazmaya başladı. Linux çekirdeği 23 Aralık 2025'te Documentation/process/coding-assistants.rst dosyasını ağaca aldı. Kurallar net: AI ajanları Signed-off-by satırı ekleyemez, çünkü Developer Certificate of Origin'i yalnızca insan onaylayabilir. AI katkısı Assisted-by etiketiyle, kullanılan ajan ve model sürümü belirtilerek açıklanır. Gönderen insan üretilen kodu gözden geçirmek, lisans uygunluğunu doğrulamak ve katkının tam sorumluluğunu almakla yükümlü.

QEMU projesi daha katı bir yerde durdu ve AI ürettiğine inanılan katkıları reddediyor. Gerekçe telif: eğitim verisinin lisans durumu belirsiz olduğu için katkı sahibi DCO maddelerini dürüstçe onaylayamıyor. Araştırma, statik analiz ya da hata ayıklama için AI kullanmak serbest; çıktının kodun içine girmesi değil. Diğer uçta curl var: sahte güvenlik bildirimleri o kadar arttı ki proje 31 Ocak 2026'da yedi yıllık ödül programını kapattı. Bildirimlerin yaklaşık beşte biri AI üretimiydi ve doğrulanan zafiyet oranı yüzde beşin altına inmişti.

Sizin şirketiniz çekirdek de değil, QEMU da değil. Ama aynı üç soruya cevap vermek zorunda: AI hangi iş türlerinde kullanılabilir, kullanıldığında nerede beyan edilir, ve birleşen kodun sorumlusu kim. Bu tek sayfalık bir politika ve yazmak bir öğleden sonra sürüyor. Yazılmadığında ortaya çıkan şey, kimsenin okumadığı ve kimsenin sahiplenmediği bir kod tabanı.

Hissetmeyin, ölçün

Dört sinyal yeterli başlangıç. Değişiklik başarısızlık oranı: yayına çıkan değişikliklerin kaçı geri alma ya da acil düzeltme gerektiriyor? İki hafta içinde yeniden yazılan kod oranı: bu ay yazılan satırların ne kadarı iki hafta içinde değişti veya silindi? Duplikasyon eğilimi: tekrar eden blok sayısı çeyreklik bazda artıyor mu? Gözden geçirme süresi ve parça boyutu: ortalama istek kaç satır ve ne kadar bekliyor?

Bu dördü ekibinizin AI'yı hızlanmak için mi, borç biriktirmek için mi kullandığını gösterir. Kurulumu yoksa önce izlenebilirlik ve hata bütçesi tarafını oturtmak gerekir, çünkü ölçmediğiniz bir şeyin yönünü tartışmak fikir alışverişinden öte gitmez.

Somut ilk adım: bir depo seçin, bir ay boyunca yukarıdaki dört sinyali kaydedin, gözden geçirme şablonuna yeniden kullanım ve hata yolu maddelerini ekleyin, bağımlılık denetimini CI hattına koyun. AI kullanımını kısmanız gerekmiyor. Kabul çıtasını, üretim hızının artmasıyla birlikte yükseltmeniz gerekiyor. Kod tabanınızın hangi sinyalde nerede durduğundan emin değilseniz, bakmamız için bize yazın.