Yapay zekânın yazdığı kod nasıl incelenir?

Kodlama ajanlarıyla kod arttı, inceleme uzadı

Bu dört sayı tek bir çalışmadan geliyor. Harvard Üniversitesi’nden iki araştırmacı, bir mühendislik analitiği platformunun verisiyle 718 firmayı Ocak 2021’den Mart 2026’ya kadar izledi (çalışmanın Ağustos 2026 sürümü). Kodlama ajanı, bir görevi alıp birden çok dosyada kod yazan, testleri çalıştıran ve iş bitene kadar yineleyen araçtır. Bu araçlara geçen firmalarda eklenen kod satırı %30, commit %20, pull request %23 arttı.

Tamamlanan iş aynı hızla artmadı: kapatılan iş kayıtlarındaki artış küçük ve istatistiksel olarak anlamlı değil. Farkı aynı çalışma açıklıyor. Bir pull request’in açılmasından merge edilmesine kadar geçen süre %49 uzadı, değişiklik istenen pull request’lerin payı neredeyse iki katına çıktı, pull request başına inceleme yorumu %35 arttı. Yazarların sonucu: darboğaz kod incelemesidir.

Başka ölçümler aynı yeri gösteriyor. LinearB’nin 2026 raporunda (8,1 milyondan fazla pull request) yapay zekânın ürettiği pull request’ler incelenmeye başlamadan önce 4,6 kat daha uzun bekliyor, ele alınınca iki kat hızlı inceleniyor. Sonar’ın 1.100’den fazla geliştiriciyle yaptığı ankette katılımcıların %96’sı yapay zekânın ürettiği kodun doğruluğuna tam güvenmiyor; commit’ten önce her zaman kontrol ettiğini söyleyenler %48.

Biz, pull request inceleyen bir araç olan diffox’u yapıyoruz; aşağıdaki liste o işten ve kendi depomuzun kurallarından çıktı, bir araç olmadan elle uygulanabilir.

Yapay zekânın yazdığı kod her satırda aynı güvenle konuşur

Bir iş arkadaşınızın kodunu incelerken yazarı tanırsınız: neyi iyi bildiğini, nerede acele ettiğini tahmin eder, emin olmadığınız yeri sorarsınız. Yazar bir dil modeli olduğunda bunların hiçbiri yoktur.

JetBrains Research’ün Ekim 2026’da yayımladığı çalışma sorunu böyle tarif ediyor. Model, ürettiği her satırı aynı güvenle sunar; kimlik doğrulama mantığının kolay, veritabanı migration’ının zor olduğunu gösteren bir işaret yoktur. Her satırı okumak, ajanların ürettiği değişiklik büyüdükçe ölçeklenmez. Araştırmacılara göre mesele diff’i okumak değil, güven kalibrasyonudur: inceleme emeğini her parçanın riskiyle orantılı dağıtabilmek. Çalışma 17 uygulayıcıyla yapılan dört atölyeye ve 43 yazılımcının katıldığı bir ankete dayanıyor.

Alışılmış uyarı işaretleri de çalışmaz. İnsan yazımı kodda dağınık bir fonksiyon ya da yarım kalmış bir yorum size “buraya dikkat” der. Yapay zekânın yazdığı kod genellikle derlenir, adları düzgündür, yorumu ve testi yanındadır. Sonar’ın anketinde geliştiricilerin %53’ü, yapay zekânın teknik borca olumsuz etkileri arasında tam bunu sayıyor: doğru görünen ama güvenilir olmayan kod.

Kod inceleme kontrol listesi nasıl olmalı?

Liste bir sıra önerir. İlk iki soru koda girmeden cevaplanmaya başlar ve nereye bakılacağını söyler; üçüncüsü kanıtı sınar; son ikisi ayrı birer okuma ister. JetBrains çalışmasının önerdiği yön de aynıdır: önce genel bakış, sonra dosyalar, en son satırlar.

Liste bu yazı için derlendi. Dayandığı kaynaklar: GitHub’ın “Review AI-generated code” rehberi, Google’ın kod inceleme rehberi ve kendi depomuzda uyguladığımız kurallar.

Açıklama, yorum ve dosya listesi koddan önce okunur

İlk soru için pull request’in açıklamasını bir iddia listesi gibi okuyun. “Başarısız isteği üç kez yeniden dener” yazıyorsa diff’te üç denemeyi bulun. Yorumları da böyle okuyun: yorum, kodun yaptığını değil yapması gerekeni anlatıyor olabilir. Bir örnek:

def fetch_prices(symbols):
    """Fiyatları getirir; ağ hatasında üç kez yeniden dener."""
    try:
        return client.get_prices(symbols)
    except Exception:
        return []

Bu fonksiyon derlenir ve sorunsuz durumu sınayan testi geçer. İki sorunu var. Docstring üç deneme söylüyor, kod bir kez deniyor. Hata da yutuluyor: servis çökmüş olsa bile çağıran boş bir liste alır ve bunu “fiyat yok” diye okur.

İkinci soru için koda girmeden dosya listesine bakın. Görev bir uç noktaya alan eklemekse, ilgisiz bir modülün neden değiştiğini açıklama söylemelidir. Sonra silinen satırları okuyun: eklenen satır dikkat çeker, silinen bir doğrulama ya da log satırı çekmez. Silinen her davranış için ona hâlâ bağlı bir yer kalıp kalmadığını arayın.

Üçüncü kontrol hatanın izlediği yoldur. Kendi depomuzda tuttuğumuz kural şudur: yakalanan hata çağırana ulaşmalıdır. Geniş bir except, varsayılan değere dönen bir yedek yol ya da yok sayılan bir dönüş değeri hatayı düzeltmez; görünmez yapar.

Geçen test, sınayan test demek değildir

Kodlama ajanı testleri kendisi çalıştırır ve geçene kadar yineler. Bu yüzden bir ajanın pull request’inde “testler geçiyor” başlangıç koşuludur, tek başına kanıt değildir. Google’ın kod inceleme rehberi aynı şeyi sorar: kod bozulduğunda testler gerçekten kırılacak mı? Bir örnek:

def test_discount_is_applied():
    order = make_order(total=100)
    apply_discount(order, code="WELCOME10")
    assert order is not None

Bu test, indirim hiç uygulanmasa da geçer. Adı indirimi söylüyor; doğrulaması yalnızca siparişin var olduğunu sınıyor. Düzeltmesi tek satırdır: assert order.total == 90.

İlk kontrolün adı mutasyon doğrulamasıdır: düzeltmeyi geri alır, testin kırıldığını görürsünüz. İkinci kontrolde bir ayrım işe yarar: arama, doğrulama değildir. “Hata mesajı çıktıda yok” diyen bir test, mesaj hiç üretilmediğinde de geçer; aramanın bulabildiğini gösteren bir karşı örnek ister.

Test verisi de aynı sorunun parçasıdır. Elle uydurulmuş bir örnek, yazarın veriyi nasıl hayal ettiğini sınar. Örneği gerçek bir kayıttan alın ya da gerçek bir kayıtla karşılaştırın.

Derlenen kod güvenli kod değildir; güvenlik ayrıca okunur

Veracode’un Temmuz 2026 raporuna göre, güvenlik yönlendirmesi verilmeden üretilen kod neredeyse her zaman derleniyor, ama güvenlik testlerini geçme oranı 100’den fazla modelde ortalama %56. Oran dile göre değişiyor: Python’da %63, Java’da %30. Rapor modelleri yalın hâlleriyle sınıyor; çevresinde araç, koruma ya da insan incelemesi olan bir ajanı değil. Sonuç yine de açık: güvenlik ayrı bir okuma ister.

Bu okumada üç yere bakın. Dışarıdan gelen girdi bir sorguya, kabuk komutuna ya da dosya yoluna süzülmeden ulaşıyor mu. Yeni uç nokta, yanındakilerle aynı yetki kontrolünü taşıyor mu; koda ya da loga sır yazılmış mı. Son olarak her yeni bağımlılığı tek tek açın.

USENIX Security 2025’e kabul edilen bir çalışma, 16 modelle üretilen 576.000 kod örneğinde, önerilen paketlerin ticari modellerde ortalama en az %5,2’sinin, açık kaynak modellerde %21,7’sinin gerçekte var olmadığını buldu. GitHub’ın rehberi bu yüzden önerilen bağımlılığın var olup olmadığına, bakımının sürüp sürmediğine ve lisansına bakmayı öneriyor.

Deponun yazılı kuralları incelemenin ölçüsüdür

Beşinci soru kodun doğru olup olmadığını değil, bu depoya ait olup olmadığını sorar. Kurallarınız bir dosyada yazılıysa (AGENTS.md, CLAUDE.md ya da CONTRIBUTING.md) incelemede o dosyayı açık tutun ve değişikliği ona karşı okuyun.

Öteki iki kontrolün birincisi tekrardır: depoda aynı işi yapan bir yardımcı varken yenisi yazılmış olabilir. Sonar’ın anketinde geliştiricilerin %40’ı gereksiz ve tekrarlı kodu da olumsuz etkiler arasında sayıyor. Yeni bir yardımcı fonksiyon gördüğünüzde depoda aynısını arayın.

İkincisi, bir işlemin iki yarısının aynı değerden türemesidir. Bir fonksiyon geçerliliği bir listeden denetleyip işlemi başka bir listeden yapıyorsa ya da saati iki ayrı yerde iki kez okuyorsa, iki yarı tek tek doğru görünür; hata aralarındaki ilişkidedir. Kendi kuralımız: değer bir kez çözülür, iki yarıya da o verilir.

Liste, küçük pull request’le ve riske göre dikkatle uygulanabilir

On beş kontrolü bin satırlık bir pull request’e uygulamak zordur. Google’ın rehberi yaklaşık 100 satırı makul, 1.000 satırı çoğu zaman fazla büyük sayar ve incelemeciye bir değişikliği yalnızca boyutu yüzünden geri çevirme hakkı tanır. Harvard çalışması, kodlama ajanından sonra pull request boyutunda anlamlı bir değişiklik bulmadı; baz ortalaması pull request başına yaklaşık 1.168 eklenen satırdı. Ajandan tek işi yapan, küçük pull request’ler istemek incelemenin ilk adımıdır.

Küçük bir pull request’te de her dosya aynı dikkati istemez. JetBrains çalışmasının önerdiği sıra, tek satır okumadan önce dosyaları riske göre ayırmaktır.

Listenin bir kısmı araca bırakılabilir, bir kısmı bırakılamaz:

• Araca bırakın. Derleme, testler, linter, statik analiz, sır taraması, bağımlılık ve lisans denetimi.
• Araç işaretlesin, siz karar verin. Yorumla kod arasındaki çelişki, yutulan hata, boş test, kural dosyasına aykırı satır. Bulunanın gerçekten hata olup olmadığına bağlamı bilen karar verir.
• Sizde kalsın. Değişikliğin doğru sorunu çözüp çözmediği, tasarımın depoya uyup uymadığı ve merge kararı.

diffox bu üç basamağın ikincisinde durur. Pull request’i, her biri tek bir şeyi arayan uzman ajanlara okutur; listenin dört maddesi yorumlarda dört ajanın adıyla görünür: kodun yapmadığını söyleyen yorum için Broken Promise Agent, yutulan hata için Silent Failure Agent, kod ne yaparsa yapsın geçen test için Empty Test Agent, kural dosyanıza aykırı satır için House Rules Agent. diffox merge’i engellemez; merge kararı ekibinizindir (nasıl çalıştığı ayrı bir yazıda).