AI ile kod inceleme: insan incelemesinden önce ne yakalanır, ne yakalanmaz?

Bir ekip kod yazmayı AI ile hızlandırdığında yazma süresi kısalır, okuma süresi kısalmaz. PR sayısı artar, PR'lar büyür, review kuyruğu uzar ve ekibin en kıdemli iki kişisi günün yarısını diff okuyarak geçirmeye başlar. Bir süre sonra o iki kişi de yorulur ve 900 satırlık PR'ın altına "LGTM" yazılır. AI ile üretilen kodun kalitesini belirleyen adım tam da burada, en az dikkat harcanan anda atlanmış olur.

Bizim pozisyonumuz şu: AI incelemesi insan incelemesinden önce çalışan bir süzgeçtir ve onun yerini tutmaz. İşi, mekanik katmanı insan PR'ı açmadan önce temizlemektir: yutulan hata, log'a düşen token, eksik test, tutarsız isim. Böylece insanın sınırlı dikkati tasarıma ve niyete kalır. Bu yazıda bir ön incelemenin neyi güvenilir yakaladığını, neyi yakalayamadığını, nasıl kurulduğunu ve ekibin alışkanlıklarını nasıl bozabileceğini anlatıyoruz. Örneklerde hayali bir seyahat rezervasyon uygulaması kullanıyoruz.

Review kuyruğu neden ilk tıkanan yer olur

Kod üretimi paralelleşir: beş geliştirici beş ajanla aynı anda çalışabilir. Review ise seri bir iştir ve modülü gerçekten bilen insan sayısıyla sınırlıdır. Üretim hızı artıp review kapasitesi sabit kaldığında üç şeyden biri olur: PR'lar günlerce bekler, review yüzeyselleşir ya da ekip sessizce "küçük PR'lara bakmasak da olur" kuralını icat eder.

AI ile yazılmış kodun bir özelliği durumu ağırlaştırır: kod düzgün görünür. İsimler tutarlıdır, biçim temizdir, yorum satırları yerindedir. İnsan reviewer'ın yıllar içinde geliştirdiği "bu kod özensiz, dikkatli bakayım" refleksi tetiklenmez. Hatalar kaybolmaz, yalnızca derli toplu bir kılıkta gelir.

Ön incelemenin amacı bu yüzden dardır ve dar kalmalıdır. İnsan reviewer'ın "burada catch hatayı yutuyor" yazmak için harcadığı her dakika, "bu retry neden var" sorusuna harcanmamış bir dakikadır. Birinci tür yorumu makineye bırakıyoruz.

AI reviewer'ın güvenilir yakaladıkları

Bugünkü modeller bir diff'i ve çevresindeki dosyaları okuyup yerel hataları iyi bulur. "Yerel" derken, hatanın kanıtının bir iki dosyanın içinde durduğu durumları kastediyoruz. Şu Kotlin koduna bakın:

class BookingRepository(
    private val api: BookingApi,
    private val cache: BookingCache,
    private val session: SessionHolder,
) {
    suspend fun refreshBookings(): List<Booking> =
        try {
            val fresh = api.fetchBookings()
            cache.replaceAll(fresh)
            fresh
        } catch (e: Exception) {
            Log.w(TAG, "yenileme başarısız, token=${session.authToken}", e)
            cache.readAll()
        }
}

İyi kurulmuş bir ön inceleme bu PR'a şuna benzer iki yorum bırakır:

[önemli] BookingRepository.kt:11
`catch (e: Exception)` CancellationException'ı da yakalıyor. Ekran kapanıp
scope iptal edildiğinde coroutine iptali yutuyor ve cache okumaya devam ediyor.
CancellationException'ı ayrı yakalayıp yeniden fırlatın.

[önemli] BookingRepository.kt:12
Auth token log'a yazılıyor. Kural: REVIEW.md, "Her zaman kontrol et", madde 2.

İkisi de doğru, ikisi de insanın yorgun bir öğleden sonra kaçırabileceği türden. Birincisi Kotlin dokümantasyonunun açıkça uyardığı bir konudur: CancellationException'ı yakalamak iptal yayılımını bozabilir, yakalıyorsanız yeniden fırlatmanız gerekir. Bu kategorideki işlerin listesi uzundur ve hepsinde AI incelemesini insandan daha tutarlı buluyoruz, çünkü sıkılmıyor:

• Yutulan ya da yanlış ele alınan hatalar: boş catch, try? ile sessizce kaybolan ödeme hatası, Result'ın yok sayılan failure dalı.
• Bariz güvenlik kokuları: log'a düşen kişisel veri ya da token, koda gömülmüş anahtar, http:// ile giden istek, doğrulanmadan kullanılan deep link parametresi.
• Tutarsızlık: aynı kavrama üç ayrı isim (reservation, booking, order), projedeki kalıptan sapan hata tipi, yarım kalmış yeniden adlandırma.
• Eksik test: yeni bir dal eklenmiş, testte karşılığı yok; test var ama hiçbir şey doğrulamıyor.
• Diff özeti: 40 dosyalık bir PR'ın ne yaptığını, hangi dosyaların mekanik değişiklik, hangilerinin davranış değişikliği olduğunu çıkarmak.

Son madde hafife alınmamalı. İyi bir özet insan reviewer'a nereden başlayacağını söyler. Kötü kullanımı da var, ona insan tarafını anlatırken geleceğiz.

Yakalayamadıkları: bir yanlış alarm, iki kaçırma

Yanlış alarm: bağlam diff'in dışındaysa

// BookingListViewModel+Refresh.swift
extension BookingListViewModel {
    func applyRefreshed(_ bookings: [Booking]) {
        items = bookings.map(BookingRow.init)
        isRefreshing = false
    }
}

Yalnızca diff'i gören bir reviewer buraya kendinden emin bir yorum yazar: "items UI state'i, bu metot arka plandan çağrılabilir, MainActor.run içine alın." Oysa BookingListViewModel başka bir dosyada @MainActor olarak tanımlıdır ve extension bu izolasyonu devralır; yorum yanlıştır. Yazarın bunu çürütmesi beş dakika alır, üçüncü kez olduğunda da AI yorumlarını okumayı bırakır. Yanlış alarmların çoğu bu kalıptadır: iddia makuldür, kanıtı diff'te görünmeyen bir dosyadadır. Çaresi iki parçalıdır: reviewer'ın çevredeki dosyaları okuyabilmesi ve talimat dosyasında "davranış iddiası için tanımın bulunduğu dosya ve satırı göster" kuralı.

Kaçırma: her satırı doğru, bütünü yanlış kod

actor SeatHoldStore {
    private var holds: [FlightID: SeatHold] = [:]
    private let api: any BookingAPI

    init(api: any BookingAPI) { self.api = api }

    func hold(for flight: FlightID) async throws -> SeatHold {
        if let existing = holds[flight], !existing.isExpired {
            return existing
        }
        let fresh = try await api.createHold(for: flight)   // askıya alınma noktası
        holds[flight] = fresh
        return fresh
    }
}

actor kelimesi "eşzamanlılık halledilmiş" hissi verir, AI reviewer'lar da bu hisse sık kapılır. Oysa actor'lar reentrant'tır: SE-0306'nın söylediği gibi actor'a ait state bir await boyunca değişebilir. Detay ekranı ve ödeme ekranı aynı anda hold(for:) çağırırsa ikisi de sözlükte kayıt bulamaz, ikisi de sunucuda koltuk tutar, biri diğerinin üzerine yazar. Kullanıcının adına iki koltuk bloke edilmiştir ve biri kimsenin bilmediği bir yerde süresinin dolmasını bekler. Çözüm, sözlükte süren Task'ı tutup ikinci çağıranı aynı işe bağlamaktır. Bu hatayı bulmak için kodun hangi ekranlardan, hangi zamanlamayla çağrıldığını bilmek gerekir. Modeller bunu bazen yakalar; "bazen" kelimesi bir güvenlik ağı tarifi olamaz.

Yaşam döngüsü hataları aynı ailedendir: process ölünce kaybolan state, ekran kapandıktan sonra tamamlanan istek, arka plana alınınca yarım kalan akış. Kanıt, çalışma zamanındaki sıradadır ve diff'te görünmez.

Kaçırma: bu kod hiç var olmamalıydı

suspend fun confirmBooking(draft: BookingDraft): Booking =
    retry(times = 3, initialDelay = 500.milliseconds) {   // projedeki yardımcı fonksiyon
        api.confirm(draft)                                // POST /bookings
    }

AI reviewer buraya büyük olasılıkla "backoff'a jitter ekleyin" yazar; yerel olarak makul bir öneridir. Asıl soru başka: idempotency anahtarı olmayan bir ödeme isteği yeniden denenmeli mi? Zaman aşımına uğrayan ilk istek sunucuda başarılı olduysa kullanıcı iki bilet almıştır. Bunu söyleyebilmek için backend sözleşmesini ve ürünün ne vaat ettiğini bilmek gerekir.

Kaçırılanların ortak paydası bilginin repoda bulunmamasıdır. Niyet (bu PR hangi problemi çözmeye çalışıyordu, doğru problemi mi çözdü), modüller arası tasarım (bu yardımcı sınıfın bir benzeri başka modülde zaten var, bu bağımlılık yönü yanlış), ürün davranışı (boş liste ekranında ne görünmeli) ve "bu özellik bayrağını üç ay önce kaldırmaya karar vermiştik" türü ekip hafızası. AI reviewer var olan kodu iyileştirmeye yatkındır; var olmaması gerektiğini nadiren söyler.

AI reviewer kodun yazıldığı gibi çalışıp çalışmadığına bakar. Yazılması gerekenin bu olup olmadığına insan bakar.

Talimat dosyası: az kural, net şiddet, susma izni

Varsayılan ayarlarla çalışan bir AI reviewer kibar, uzun ve her şeye değinen yorumlar üretir. İşe yarar hâle getiren şey talimat dosyasıdır. İçinde dört şey olmalı: neyin önemli sayıldığı, neyin hiç raporlanmayacağı, projeye özgü kontroller ve bulgu yoksa susma talimatı.

Bağlam tarafında üç kaynak gerekir. Proje kuralları ve mimari notları, yani ajanların zaten okuduğu kural dosyası; bunu mimari korkuluklar yazısında anlatıyoruz. Diff'in kendisi. Bir de diff'in çevresi: değişen tipin tanımı, çağıranlar, ilgili testler. Yalnızca diff verilen bir model, yukarıdaki @MainActor örneğindeki gibi tahmin yürütür. Repoyu okuyabilen ajan tabanlı bir reviewer bu yüzden diff'i API'ye tek seferde gönderen bir betikten belirgin biçimde daha az yanlış alarm üretir.

Aşağıdaki dosya gerçekçi bir başlangıç noktasıdır:

# Review talimatları

Bu repo bir seyahat rezervasyon uygulamasının iOS (Swift 6) ve Android
(Kotlin) kodunu içerir. Mimari kurallar CLAUDE.md dosyasındadır; önce onu oku.
Yalnızca bu PR'ın değiştirdiği satırları incele. Çevredeki dosyaları bağlam
için oku, onlar hakkında yorum yazma.

## Şiddet seviyeleri

- [önemli]: merge edilirse hatalı davranış, veri kaybı, veri sızıntısı ya da
  çökme üretecek bulgular. Yanlış mantık, yutulan hata, log'a düşen kişisel
  veri ya da token, iptali yutan coroutine, ana thread dışından UI state yazımı.
- [küçük]: isimlendirme tutarsızlığı, eksik test, gereksiz karmaşıklık.
- Üslup, biçim ve import sırası hakkında hiçbir seviyede yorum yazma.

## Raporlama

- Sunucu sözleşmesine ya da ürün davranışına dair varsayımını bulgu olarak
  yazma; özetin sonuna "insan reviewer'a soru" olarak ekle.
- Bir davranış iddiası için kanıt göster: dosya ve satır. İsimden çıkarım yapma.
  İzolasyon, thread ya da scope iddialarında tipin tanımlandığı dosyayı oku.
- Emin değilsen yazma.
- En fazla 3 [küçük] yorum. Fazlası varsa özette sayısını söyle.
- Hiç bulgu yoksa tek satır yaz: "Mekanik katmanda bulgu yok." Övgü, genel
  tavsiye ve diff'in satır satır anlatımı yok.
- PR daha önce incelendiyse yalnızca yeni [önemli] bulguları yaz.

## Raporlama dışı

- SwiftLint, detekt ve ktlint'in zaten yakaladığı her şey.
- Üretilmiş kod: **/Generated/**, *.pb.swift, build/ altı.
- Package.resolved, gradle.lockfile, .xcstrings dosyaları.

## Her zaman kontrol et

1. Ödeme ve rezervasyon isteklerinde hata kullanıcıya gösteriliyor, yutulmuyor.
2. Log satırlarında e-posta, telefon, token, kart bilgisi yok.
3. Feature modülleri birbirini import etmiyor; yalnızca Core ve DesignSystem.
4. Yeni bir public fonksiyonun en az bir testi var.
5. Kotlin: suspend fonksiyonlarda genel Exception yakalanıyorsa
   CancellationException yeniden fırlatılıyor.

Dosyanın adı ve konumu araca göre değişir, içerik değişmez. Anthropic'in yönetilen Code Review ürünü repo kökündeki REVIEW.md dosyasını review talimatı, CLAUDE.md dosyalarını proje bağlamı olarak okur. GitHub Copilot code review .github/copilot-instructions.md dosyasını ve .github/instructions altındaki, applyTo ön bilgisiyle yol bazlı çalışan *.instructions.md dosyalarını kullanır. Kendi workflow'unuzu yazıyorsanız dosyanın adını siz koyarsınız ve prompt'ta gösterirsiniz. Bu dosyayı kısa tutun: her eklenen satır, önemli satırların ağırlığını azaltır.

CI'a bağlamak: PR açılınca çalışan ön inceleme

Kurulum için iki yol var. Birincisi satıcının yönetilen entegrasyonu: Copilot code review'u PR'a reviewer olarak atamak ya da otomatik çalışacak şekilde ayarlamak, Anthropic'in Code Review'unu organizasyon için açmak gibi. Kurulumu kolaydır, kontrolü azdır. İkincisi kendi CI'ınızda bir review ajanı çalıştırmak. Prompt'u, tetikleyicileri ve izinleri siz belirlersiniz. Biz ikincisiyle başlamayı öneriyoruz, çünkü neyin gönderildiğini ve ajanın neye izinli olduğunu workflow dosyasında satır satır görürsünüz.

Aşağıdaki örnek GitHub Actions üzerinde anthropics/claude-code-action@v1 kullanıyor. Girdi adları ve izinler, action'ın Ekim 2026 tarihli dokümantasyonundaki review örneğiyle aynıdır:

name: AI pre-review

on:
  pull_request:
    types: [opened, ready_for_review, synchronize]
    paths:
      - "**/*.swift"
      - "**/*.kt"
      - "**/*.kts"

concurrency:
  group: ai-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    if: ${{ !github.event.pull_request.draft }}
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMARASI: ${{ github.event.pull_request.number }}

            PR branch'i çalışma dizininde hazır. Önce REVIEW.md dosyasını oku
            ve oradaki kurallara harfiyen uy. Değişiklikleri `gh pr diff` ile
            al, gerektiğinde çevredeki dosyaları oku.

            Satıra bağlı bulgular için
            `mcp__github_inline_comment__create_inline_comment` aracını
            (`confirmed: true` ile) kullan. Özeti `gh pr comment` ile tek bir
            yorum olarak yaz. PR'ı onaylama, değişiklik isteme, kod değiştirme.
          claude_args: |
            --max-turns 30
            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)"

Kalıbın satıcıdan bağımsız kısımları şunlar. Taslak PR'lar atlanır, çünkü yazar henüz "bakın" dememiştir. concurrency aynı PR'a art arda gelen push'larda eski çalışmayı iptal eder; aksi hâlde üç review yarışır ve üçü de yorum bırakır. timeout-minutes ve --max-turns maliyete tavan koyar. İzinler dardır: contents: read ile ajan kod değiştiremez, --allowedTools ile yalnızca diff okuyup yorum yazabilir. id-token: write action'ın GitHub App kimlik doğrulaması içindir. Her push'ta çalıştırmak pahalı geliyorsa synchronize'ı kaldırın ve yeniden incelemeyi isteğe bağlayın.

İki konuya dikkat edin. Birincisi, AI review'u bir merge koşulu yapmayın ve bot'un onayı gerekli onaylardan sayılmasın. Anthropic'in yönetilen ürünü bunu tasarım gereği yapar: bulgular PR'ı onaylamaz ya da bloklamaz, check her zaman nötr sonuçla biter. GitHub da Copilot review'unun insan incelemesiyle tamamlanmasını söyler. İkincisi fork'lar: GitHub, fork'tan gelen pull_request çalışmalarına GITHUB_TOKEN dışındaki secret'ları vermez, yani bu workflow fork PR'larında çalışmaz. Bunu aşmak için pull_request_target'a geçmeyin; GitHub dokümantasyonu o tetikleyicide güvenilmeyen kod çalıştırmanın yazma yetkisine ve secret'lara istenmeyen erişim verebileceği konusunda açıkça uyarır.

Eşdeğerler aynı şekilde kurulur. OpenAI'ın openai/codex-action ve Google'ın google-github-actions/run-gemini-cli action'ları aynı kalıbı kendi CLI'larıyla uygular; GitLab ya da Bitbucket'ta aynı adımlar bir pipeline job'ı olur. Hangisini seçerseniz seçin üç soru aynıdır: talimatı hangi dosyadan okuyor, hangi araçlara izinli, sonucu nereye yazıyor.

Gürültüyü kısmak: az yorum, yeni kod, kanıt şartı

Bir ön incelemeyi kaçırdığı hatalardan çok yazdığı gereksiz yorumlar öldürür. Geliştirici üst üste üç işe yaramaz yorum gördükten sonra dördüncüyü okumaz ve dördüncü, token'ın log'a düştüğünü söyleyen yorumdur.

Uyguladığımız kontroller şunlar:

• Yorum bütçesi. PR başına sınırlı sayıda küçük bulgu, gerisi özette sayı olarak. Önemli bulgulara sınır koymuyoruz; bir PR'da on önemli bulgu varsa sorun bütçe olmaz.
• Yalnızca yeni kod. Reviewer bu PR'ın değiştirdiği satırlar hakkında konuşur. Dokunulan dosyadaki beş yıllık borcu bu PR'ın yazarına fatura etmek, insanların küçük düzeltme PR'ı açmaktan vazgeçmesinin en kısa yoludur.
• Kanıt şartı. Güven eşiğini sayıyla ifade etmek zordur; "iddianı dosya ve satırla göster, gösteremiyorsan yazma" kuralı aynı işi görür ve denetlenebilir.
• Linter ile çakışmama. SwiftLint, detekt ya da ktlint'in yakaladığı bir şeyi modele tekrar ettirmek hem pahalı hem de tutarsızdır. Deterministik olarak kontrol edilebilen her kural linter'a aittir; modele yalnızca yargı gerektiren işler kalır.
• Yeniden incelemede yakınsama. İlk turdan sonra yalnızca yeni önemli bulgular. Aksi hâlde tek satırlık bir düzeltme yedinci turda hâlâ isimlendirme tartışıyor olur.
• Geri bildirim döngüsü. Yanlış ya da gereksiz bulunan her yorum türü, talimat dosyasına bir satır olarak geri döner. Araç yorumlara tepki bırakmayı destekliyorsa kullanın; desteklemiyorsa ayda bir, kapatılmış yorumlardan yirmi tanesini okuyun. Talimat dosyası da kod gibi PR ile değişir ve bir sahibi olur.

Sonuncusu en çok ihmal edilen. İlk hafta ayarlanıp bırakılan bir talimat dosyası, altı ay sonra kimsenin okumadığı yorumlar üreten bir bot demektir.

İnsan tarafı: çapa, tembellik ve imza

Kurulumun teknik kısmı bir öğleden sonra sürer. Zor kısım, ekibin davranışının nasıl değiştiğini izlemektir. Üç bozulma görüyoruz.

Birincisi reviewer'ın AI özetine çapa atmasıdır. Özet "bu PR rezervasyon listesine yenileme ekliyor, risk düşük" diyorsa reviewer diff'i bu cümleyi doğrulamak için okumaya başlar. Özet yazarın niyetini anlatır, kodun gerçekte ne yaptığını garanti etmez. Önerimiz, reviewer'ın önce PR açıklamasını ve diff'i okuması, AI yorumlarına sonra bakması. Bazı ekipler AI özetini açılır bir bölümün içine alıyor; küçük ama işe yarayan bir sürtünme.

İkincisi yazarın kendi kodunu okumayı bırakmasıdır. "Nasılsa bot bakacak" düşüncesiyle açılan PR, üstelik kodun bir kısmını yazarı da yazmadıysa, kimsenin baştan sona okumadığı bir PR'dır. Kuralımız: PR'ı açan kişi, AI incelemesini kendi makinesinde çalıştırmış ve bulguları kapatmış olarak gelir. CI'daki çalışma ikinci süzgeçtir.

Üçüncüsü hesap verebilirliktir. "AI incelemesi geçti" cümlesi bir onay olamaz. Merge edilen koddan yazar ve onaylayan insan sorumludur; bot'un imzası yoktur, olmamalıdır da. Bunu yazılı hâle getirin: ekibin AI kullanım politikasında bir cümle yeter.

İnsan reviewer'ın hâlâ bakması gerekenleri kısa bir listede topluyoruz. Google'ın mühendislik pratikleri rehberi review'da ilk bakılacak şeyin tasarım olduğunu söyler; liste o yüzden oradan başlıyor.

• Bu değişiklik doğru problemi mi çözüyor, PR açıklamasındaki niyetle kod örtüşüyor mu?
• Bu kod var olmalı mı? Aynısı başka bir modülde var mı, daha basit bir yolu var mı?
• Modül sınırları ve bağımlılık yönü tasarıma uyuyor mu?
• Eşzamanlılık ve yaşam döngüsü: await boyunca değişebilen state, iptal, process death, arka plana geçiş.
• Ürün davranışı: hata, boş ve yükleniyor durumları, geri tuşu, çevrimdışı.
• Testler doğru şeyi mi sınıyor, yoksa yalnızca var mı?
• AI'ın "insan reviewer'a soru" olarak bıraktığı varsayımların cevabı ne?

Kod dışarı gidiyor: ne gidiyor, nerede duruyor, kim görüyor

Bir review ajanı çalıştığında model sağlayıcısına şunlar gider: prompt ve talimat dosyaları, diff, ajanın okuduğu her dosyanın içeriği, çalıştırdığı komutların çıktısı, PR başlığı ve açıklaması. Yukarıdaki kurulumda repo runner'a çekilir ve ajan hangi dosyayı açarsa o dosya API isteğinin parçası olur. "Yalnızca diff gidiyor" varsayımı ajan tabanlı bir reviewer için yanlıştır.

Nerede durduğu sözleşmenize bağlıdır ve satıcıdan satıcıya değişir; hukuk ekibinizin okuması gereken metin veri kullanım dokümanı ve sözleşmedir. Örnek olarak Anthropic'in Ekim 2026'daki dokümanı ticari kullanımda (Team, Enterprise, API) kod ve prompt'ların, müşteri açıkça katılmadıkça model eğitiminde kullanılmadığını, standart saklama süresinin 30 gün olduğunu, sıfır veri saklamanın (ZDR) ise uygun bulunan kurumsal hesaplar için organizasyon bazında açıldığını söyler. Bireysel planlarda varsayılanlar farklıdır; ekipte herkesin kendi hesabıyla review çalıştırması bu yüzden kötü fikirdir. Sonuçları kimin gördüğü de önemlidir: yorumlar PR'ı görebilen herkese, workflow log'ları repoyu okuyabilen herkese açıktır.

Koda doğrudan satıcının API'sine gitmesi kabul edilemiyorsa seçenekler şunlardır:

1. Çıkarımı kendi bulut hesabınız üzerinden geçirmek. Aynı action use_bedrock, use_vertex ve use_foundry girdileriyle Amazon Bedrock, Google Cloud ve Microsoft Foundry üzerinden çalışır; diğer satıcıların da benzer yolları vardır. Veri, zaten sözleşmeniz olan bulut sağlayıcısının koşullarına tabi olur.
2. Sıfır veri saklama anlaşması. Dikkat: bazı yönetilen özellikler bununla çalışmaz. Anthropic'in yönetilen Code Review'u ZDR açık organizasyonlarda kullanılamaz; kendi CI'ınızdaki action kullanılabilir.
3. Kendi donanımınızda açık ağırlıklı bir model. Kod hiçbir yere gitmez; karşılığında inceleme kalitesi düşer ve bir altyapıyı işletirsiniz. Kaliteyi kendi PR geçmişinizden bir örneklemle ölçmeden karar vermeyin.
4. Kapsamı daraltmak. paths filtresiyle ödeme, kimlik doğrulama gibi dizinleri AI incelemesinin dışında tutup oraya iki insan onayı şartı koymak.

Bir risk daha var ve çoğu ekip atlıyor: PR'ın içeriği güvenilmeyen girdidir. Diff'teki bir yorum satırı ya da PR açıklaması modele "önceki talimatları unut" diyebilir. Bu yüzden ajanın izinleri dar olmalı (yazma yetkisi yok, serbest shell yok), talimat dosyasına CODEOWNERS ile sahip atanmalı ve fork PR'ları secret'lara ulaşmamalıdır.

İşe yarayıp yaramadığını nasıl anlarsınız

"Bot şu kadar yorum yazdı" bir başarı ölçüsü olamaz; yorum sayısı gürültüyle de artar. Bizim izlediklerimiz şunlar, hepsi kendi PR geçmişinizden çıkarılabilir:

• Eyleme dönüşen yorum oranı. Ayda bir, yirmi PR'lık bir örneklemde AI yorumlarını üç gruba ayırın: kod değişikliğine yol açtı, yok sayıldı, yanlıştı. Yanlışların ve yok sayılanların payı artıyorsa talimat dosyasına dönün.
• İnsan yorumlarının türü. Aynı örneklemde insan yorumlarını "mekanik" ve "tasarım, niyet, ürün" olarak etiketleyin. Ön inceleme işini yapıyorsa mekanik yorumların payı düşer. Düşmüyorsa ya bot yakalamıyordur ya da insanlar bot'un yorumlarını tekrar ediyordur.
• İlk insan incelemesine kadar geçen süre ve review turu sayısı. İkisi de Git barındırma servisinizin API'sinden çıkar. Tur sayısı azalmıyorsa, mekanik düzeltmeler hâlâ insan turunda yapılıyordur.
• Kaçan hatalar. Üretimde çıkan her hata için tek soru: bunu hangi katman yakalamalıydı? Linter, test, AI incelemesi, insan incelemesi. AI katmanına yazılanlar talimat dosyasına kontrol olarak eklenir; insan katmanına yazılanlar reviewer listesine.

Bu ölçümleri daha geniş bir çerçeveye oturtmak isterseniz AI verimliliğini ölçmek yazısına bakın.

Nerede durmalı: iki üç kişilik, günde birkaç PR açan bir ekipte CI'a bağlı bir ön inceleme çoğu zaman fazladır. Yazarın PR açmadan önce aynı incelemeyi kendi makinesinde çalıştırması yeter. CI entegrasyonu, review kuyruğu gerçekten beklemeye başladığında ve ekipte "PR'ı açan önce kendi baksın" kuralını elle uygulamak zorlaştığında karşılığını verir.

Kontrol listesi

• AI incelemesi insan incelemesinden önce çalışıyor; bot'un çıktısı gerekli onaylardan sayılmıyor ve merge'i bloklamıyor.
• Repoda bir review talimat dosyası var: şiddet seviyeleri, raporlama dışı liste, projeye özgü kontroller, "bulgu yoksa tek satır" kuralı.
• Talimat dosyasının bir sahibi var (CODEOWNERS) ve PR ile değişiyor.
• Reviewer diff'in çevresindeki dosyaları da okuyabiliyor; davranış iddiaları için dosya ve satır kanıtı isteniyor.
• Linter'ların yakaladığı her şey AI incelemesinin kapsamı dışında.
• Küçük bulgular için yorum bütçesi var; yeniden incelemede yalnızca yeni önemli bulgular yazılıyor.
• Workflow taslak PR'ları atlıyor, eski çalışmaları iptal ediyor, zaman ve tur sınırı taşıyor.
• Ajanın izinleri dar: içerik salt okunur, araç listesi açıkça yazılmış, fork PR'ları secret'lara ulaşamıyor.
• Sağlayıcıya ne gittiği, ne kadar saklandığı ve eğitimde kullanılıp kullanılmadığı yazılı; hassas dizinler için karar verilmiş.
• Yazar PR açmadan önce incelemeyi kendi makinesinde çalıştırıyor.
• İnsan reviewer listesi (niyet, var olmalı mı, sınırlar, eşzamanlılık, ürün davranışı) PR şablonunda duruyor.
• Ayda bir yirmi PR'lık örneklemle eyleme dönüşen yorum oranına ve insan yorumlarının türüne bakılıyor.