AI Kod İncelemesi ile İnsan İncelemesi: Hangisi Neyi Yakalar

İnsan kod incelemesi, öngörülebilir bir hata sınıfını kaçırır: tek başına bakıldığında düzgün görünen bir query builder içindeki ince SQL injection, kopyalandığı her serviste tekrarlanan aynı hatalı pattern, uzun bir haftanın sonunda atlanan güvenlik kontrolü. İnceleyiciler önlerindeki diff’e odaklanır; bu yüzden en deneyimli mühendis onaylasa bile sistemik ve kod tabanları arası sorunlar gözden kaçar.

AI inceleyiciler tam da bu pattern’ları yakalar, ama iş mantığını ve mimari uyumu kaçırır. İşe yarayan çerçeve, AI’ın insan incelemesinin yerini alıp almayacağı değil; AI pattern tanımayı insan muhakemesiyle nasıl eşleştirip her birinin diğerinin kör noktasını kapatacağıdır. İkisini paralel çalıştırıp bulguları tek noktada birleştirin. Her tarafın ne yakaladığı ve ikisinin nasıl birleştirileceği aşağıda.

AI ve İnsan İncelemesi: Güçlü ve Zayıf Yönler#

İki inceleyici farklı yönlerde hata yapar. Onları eşleştirmeyi değerli kılan da, kurulumu zahmetli kılan da bu.

AI’ın Üstün Olduğu Alanlar#

Kod tabanları arası pattern tanıma en net kazanç. Tüm repository’yi bağlamında tutan bir inceleyici, aynı hatalı veritabanı sorgu pattern’ını onu kopyalayan her serviste işaretleyebilir. Tek seferde tek PR’a bakan insan inceleyiciler ise her örneği tek başına görür ve onaylar; çünkü tek başına bakıldığında sorun görünmez.

Güvenlik açığı tespiti gerçek kaldıraç sağlayan ikinci alan. AI inceleyicilerin tutarlı biçimde yüzeye çıkardığı bulgular:

• Dinamik query builder’lardaki ince SQL injection pattern’ları
• JWT doğrulama mantığındaki authentication bypass açıkları
• Hata mesajlarında kasıtsız PII loglaması
• Infrastructure kodunda güvenli olmayan default konfigürasyonlar

Performans anti-pattern tanımlama insan incelemesinden daha tutarlıdır ve nedeni sıradandır: AI uzun bir haftanın sonunda yorulmaz, deneyimli geliştiricilerin tam da “apaçık” oldukları için atladığı kontrolleri atlamaz.

İnsanların Öne Çıktığı Alanlar#

İş mantığı doğruluğu tamamen insan alanında kalır. AI, belirli bir kullanım durumu için kasıtlı tasarlanmış bir circuit breaker implementasyonunu “bug” olarak işaretleyebilir. Bu tür yanlış pozitifler önemli bir boşluğu gün yüzüne çıkarır: mimari karar dokümante edilmemişse AI’ın şüphe işareti koyması teknik olarak doğrudur. AI, belgelenmemiş niyeti şüpheli kod olarak değerlendirir.

Alana özel bağlam AI’ın en çok zorlandığı yer. Finansal hizmetler uygulaması incelerken insan inceleyiciler, “gereksiz” görünen bazı doğrulamaların aslında compliance için zorunlu olduğunu bilir. AI gereksizlik görür; insanlar yasal zorunluluk görür.

Mimari uyum ise sistem düzeyinde düşünmeyi gerektirir. AI tek tek pattern ihlallerini fark edebilir, ama pattern’ların kendisinin sistem geliştikçe hâlâ mantıklı olup olmadığını insanlar değerlendirir.

İnsan-AI İşbirliği Yapısı#

İşi bu hatlar boyunca bölen bir inceleme pipeline’ı üç aşamadan oluşur:

interface ReviewPipeline {
  preReview: {
    linting: ESLintResults;
    formatting: PrettierResults;
    typeChecking: TypeScriptErrors;
  };
  
  aiReview: {
    securityScan: SecurityFindings[];
    performanceAnalysis: PerformanceIssues[];
    architecturePatterns: PatternViolations[];
    complexityMetrics: CyclomaticComplexity;
  };
  
  humanReview: {
    businessLogic: BusinessRequirements;
    domainKnowledge: ContextualDecisions;
    architecturalFit: SystemDesignReview;
    mentorship: LearningOpportunities;
  };
}

Son iki aşamanın sırası, içeriklerinden daha belirleyicidir. AI raporu önce gelirse insan inceleyiciyi makinenin listesine sabitler; kod okumak yerine bulguları doğrulamaya başlar. İnsan önce onaylarsa AI raporu karardan sonra düşer ve kimsenin onu açmak için sebebi kalmaz. İki aşama da aynı diff’ten başlamalı ve bir birleştirme adımında buluşmalıdır.

Kurumsal Context için Prompt Engineering#

Genel AI inceleyiciler az değer katar. Kaldıraç prompt’ta gizlidir; çünkü modelin başka yoldan öğrenemeyeceği alan kurallarını ve kurumsal bağlamı prompt taşır.

Güvenlik incelemesi için örnek bir prompt şablonu:

Bu kodu güvenlik açıkları için incele, özellikle şunlara dikkat et:

Context: PCI-DSS uyumlu işlemler yapan finansal hizmetler uygulaması.

Kontrol edilecek özel pattern'lar:
1. Input validation ve sanitization
2. Authentication token handling  
3. Veritabanı sorgu oluşturma
4. Harici API çağrı güvenliği
5. Data loglama ve PII maruziyeti

Kod tabanımızda kabul edilebilir pattern'lar:
- Internal crypto kütüphanemiz ile custom şifreleme
- ConnectionManager ile veritabanı connection pooling
- RateLimitMiddleware ile API rate limiting

Bu belirlenmiş pattern'lardan sapan veya yeni güvenlik saldırı vektörleri tanıtan her şeyi işaretle.

“Kabul edilebilir pattern’lar” kısmı yükün büyük bölümünü taşır. Bu olmadan inceleyici, bilinçli mimari kararları problem olarak işaretler; geliştiriciler de kısa sürede o kanalı bütünüyle okumayı bırakır.

False Positive Öğrenme Eğrisi#

Ayarlanmamış bir inceleyici ilk haftasında yüzlerce “potansiyel sorun” üretir, ikinci haftada ise kimse onları açmaz. Çoğu rollout’u bitiren başarısızlık biçimi budur ve yalnızca ayar yaparak geri alınamaz: bir kanal bir kez gürültü olarak etiketlendiğinde, sinyal düzelse bile geliştiriciler o kanalı atlamayı sürdürür.

Google’ın statik analiz programı bu toleransa bir sayı koyuyor. “Software Engineering at Google” kitabının 20. bölümü, bir analizörün kod incelemesinde devreye alınabilmesi için etkin false positive oranının %10’un altında kalması gerektiğini anlatıyor; yani geliştirici, kontrolün gerçek bir soruna işaret ettiğini on kezin en az dokuzunda hissetmeli. Buradaki kritik kelime “etkin”. Oran, mutlak doğruya göre değil geliştirici algısına göre ölçülüyor; teknik olarak doğru ama istenmeyen bir bulgu da analizörün hanesine yazılıyor. Aynı bölüm, Tricorder günde 50.000’den fazla kod inceleme değişikliğini tararken genel etkin false positive oranının %5’in hemen altında kaldığını, yazarların aracın otomatik düzeltmelerini günde yaklaşık 3.000 kez uyguladığını aktarıyor. Eşiğin nedeni de açıkça yazılı: düşük false positive oranları, geliştiricilerin bir aracı gerçekten kullanmak istemesi için çoğu zaman kritiktir.

Geri bildirim kanalı eşik kadar somut. İnceleyiciler bir bulguyu “Not useful” olarak işaretleyebiliyor ve bu tıklamalar, taranan 50.000 değişikliğe karşılık günde yaklaşık 250 bulguya düşüyor. Her tıklama tek bir kurala işaret ediyor; sinyali eyleme dönüştürülebilir kılan da bu.

Elinde veri olan satıcılar da aynı takası yapıyor. GitHub, Copilot kod incelemesinin incelemelerin %29’unda hiç yorum bırakmadığını, daha güçlü bir akıl yürütme modeline geçmenin olumlu geri bildirim oranını %6 artırırken inceleme gecikmesini %16 yükselttiğini bildiriyor. İkisi de isabet takasının bir sürüm kararına yazılmış hali.

Reddedilen bulgular tek tip değil ve ayrıştırmak neyi düzelteceğinizi değiştiriyor. Agent yorumlarını inceleyen arXiv çalışması, çözüme bağlanmamış 470 yorumu örnekleyip on kategoriye ayırıyor; en büyük ikisi “Incorrect Suggestion” (67) ve “Intentional Design Decision” (55). Birincisi prompt veya kural değişikliği ister. İkincisi dokümantasyon ister; çünkü inceleyici kodu doğru okumuş, yalnızca istisnanın bilinçli olduğunu bilmemiştir.

Bir sayı sınıfına ise güvenmemek gerekir: sentetik benchmark’lardan gelen satıcı bazlı isabet skorları. OWASP Benchmark projesi hiçbir ticari araç için sonuç yayımlamadığını açıkça belirtiyor, dolayısıyla ona atfedilen satıcı bazlı rakamlar başka bir yerden geliyor. Proje ayrıca test senaryolarının gerçek uygulamalardan belirgin biçimde daha basit olduğunu, gerçek uygulamaları başarıyla analiz etmenin çok daha zor olduğunu da söylüyor. Sahada ölçülmüş bir etkin false positive oranı, benchmark skorundan daha değerlidir.

Bu yüzden ayarın hedefi isabettir. Daha az sorun yakalayıp yakaladıklarında haklı çıkan bir inceleyici, daha çok sorun bulup hepsini gürültüye gömen bir inceleyiciden iyidir. Pratikte şuna benzer:

1. Muhafazakâr başla: sınırları net olan, iyi tanımlanmış güvenlik ve performans pattern’larıyla başla
2. Geri bildirim döngüsü kur: hangi bulguların kabul, hangilerinin reddedildiğini toplamda değil kural bazında izle
3. Reddedilenler üzerinden ilerle: kabul edilmekten çok reddedilen bir kuralın savunulmadan önce prompt’unun yeniden yazılması gerekir
4. Hiç tetiklenmeyen kuralları kaldır: hem token harcarlar hem de dikkati dağıtırlar

Entegrasyon Stratejileri#

Hiçbir şeyi bağlamadan önce bilinmesi gereken birkaç entegrasyon biçimi var.

GitHub Actions Entegrasyonu#

name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: AI security review
        id: review
        # modeli çağıran ve findings çıktısı üreten yerel composite action
        uses: ./.github/actions/ai-security-review
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          context-file: .github/review-context.json

      - name: Comment PR with findings
        uses: actions/github-script@v7
        env:
          FINDINGS: ${{ steps.review.outputs.findings }}
        with:
          script: |
            const findings = JSON.parse(process.env.FINDINGS);
            if (findings.length === 0) return;
            const body = findings
              .map((f) => `- **${f.severity}** \`${f.file}:${f.line}\` ${f.message}`)
              .join('\n');
            await github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `### AI review findings\n\n${body}`
            });

permissions bloğu genellikle unutulan kısım. pull-requests: write olmadan yorum adımı, fork’tan gelen ilk PR’da hata verir.

Araç Karşılaştırması#

Bu araçlar arasında seçim yaparken fiyatlandırma modeli etiket fiyatından daha belirleyicidir. Koltuklar bir taban kurar; inceleme işinin sayaçla ölçüldüğü her yerde değişken kısım kodun ne kadar değiştiğini takip eder.

Snyk Code

• IDE içinde ve pull request üzerinde çalışan özel bir SAST aracı; katman başına kaç kod testi alacağınız sınırlı
• Daha önce görmediği alana özel pattern’larda zorlanır
• Fiyatlandırma modeli: koltuk bazlı; çalışan sayısına göre değil katkı veren geliştirici başına sayılır
• En iyi: compliance gereksinimleri olan güvenlik odaklı takımlar için

Amazon Q Developer kod incelemesi

• Kural tabanlı detector’lar ve üretken inceleme birlikte; SAST, secret tespiti, IaC hatalı yapılandırması ve üçüncü parti bağımlılıkları kapsar
• AWS araç zincirine ve desteklenen IDE’lere bağlı; AWS, otomatik incelemeler için 200 KB kaynak kod, dosya veya proje incelemeleri için 50 MB üst sınır belgeliyor
• Fiyatlandırma modeli: kullanıcı başına abonelik katmanı
• En iyi: hâlihazırda AWS araç zincirinde olan takımlar için. Öncülü CodeGuru Reviewer artık yeni repository ilişkilendirmesi kabul etmiyor

Custom LLM entegrasyonu

• En esneği; prompt sizin elinizde olduğu için kendi pattern’larınıza göre şekillenir
• Ciddi kurulum ve sürekli bakım ister
• Fiyatlandırma modeli: token başına, yani maliyet kişi sayısını değil diff hacmini takip eder
• En iyi: kodlanmaya değecek kadar özgün alan kuralları olan takımlar için

Genellikle doğru cevap hibrittir: güvenlik baseline’ı için özel bir SAST aracı, artı hiçbir satıcının bilmediği mimari ve performans pattern’ları için custom prompt’lar.

Maliyet Yapısı#

Koltuk ücreti bir taban belirler. Tüketim onun üstüne biner ve inceleme işini sayaçla ölçen araçlarda tüketim, takımın kaç kişi olduğunu değil kodun ne kadar değiştiğini takip eder.

GitHub, Copilot’u 1 Haziran 2026’da kullanım bazlı faturalandırmaya geçirdi. Duyuruda Pro ayda $10, Pro+ $39, Business kullanıcı başına ayda $19, Enterprise kullanıcı başına ayda $39 olarak listeleniyor ve her plan kendi fiyatı kadar aylık AI kredisi taşıyor. Bu tutarın üstü, her model için listelenen API fiyatları üzerinden input, output ve cache’lenmiş token tüketimiyle ölçülüyor. GitHub kendi ürününü de aynı hattan ikiye ayırdı: kod tamamlama ve sıradaki düzenleme önerileri sabit tarafta kalıp kredi harcamıyor, kod incelemesi ise kredinin yanında GitHub Actions dakikası da tüketiyor.

Değişkenlik, inceleme başına tahminlerde ortaya çıkıyor. GitHub’ın Copilot kod incelemesi dokümantasyonu tek bir incelemeyi lite efor ayarında $0,05 ile $1, balanced ayarında $0,25 ile $5 arası AI kredisi olarak veriyor. İkisi de Actions dakikalarını dışarıda bırakıyor ve maliyetin pull request boyutuyla ve repository custom instruction’larıyla birlikte arttığı belirtiliyor. Tek bir ayarın içinde yirmi kat fark var.

Copilot Business’ta yirmi geliştirici ayda 20 × $19 = $380 tutar ve bu koltuklar $380 kredi taşır. Ayda dört yüz pull request, balanced aralığın alt ucunda 400 × $0,25 = $100 eder ve havuzun içinde kalır. Aynı dört yüz PR üst uçta 400 × $5 = $2.000 eder; Actions dakikaları ve hesaptaki diğer kredi tüketimleri hariç yaklaşık $1.620 aşım olarak faturalanır. İki ay arasında kişi sayısı da koltuk ücreti de değişmedi. Değişen, diff hacmiydi. GitHub ayrıca kullanıcı veya kurum bütçesi tükendiğinde incelemelerin tümden durduğunu belgeliyor; bu da bütçeyi bir maliyet ayarı olduğu kadar erişilebilirlik ayarı yapıyor.

Koltuk bazlı araçlar da faturayı kişi sayısıyla düz çarpımdan çok etkin katkıya göre çıkarıyor. Snyk’in plan sayfası Team’i katkı veren geliştirici başına aylık $25’ten, Ignite’ı katkı veren geliştirici başına yıllık $1.260’tan başlatıyor; katkı veren geliştiriciyi de son 90 günde Snyk’in izlediği bir private repository’ye commit atmış kişi olarak tanımlıyor, public repository katkıları sayılmıyor. Kırk mühendisin bulunduğu ve bu pencerede yirmi beşinin izlenen private repository’lere dokunduğu bir kurumda Team katmanı kırk koltuktan değil 25 × $25 = $625’ten başlar. Amazon Q Developer’ın fiyat sayfası Pro katmanını kullanıcı başına ayda $19 olarak listeliyor; kod dönüşümü hakkı kullanıcı başına ayda 4.000 satır olarak AWS ödeyen hesap düzeyinde havuzlanıyor, aşım ise gönderilen satır başına $0,003.

Kendiniz kurduğunuz bir inceleyici token başına öder; hem aritmetik hem de elinizdeki kollar açıktır. Anthropic’in fiyat sayfası Claude Sonnet 5’i milyon input token başına $2 ve milyon output token başına $10, Claude Opus 5’i $5 ve $25, Claude Haiku 4.5’i $1 ve $5 olarak listeliyor. Sonnet 5’e 40.000 token diff ve bağlam gönderip 2.000 token geri alan bir inceleme girişte $0,08, çıkışta $0,02, yani $0,10 tutar; dört yüz inceleme $40 eder. Bu rakamı üç kol oynatır: prompt cache okumaları temel input fiyatının 0,1 katı, cache yazımları beş dakikalık pencerede 1,25 katı ve bir saatlik pencerede 2 katı, Batch API ise input ve output’un ikisinden de %50 indirim sağlıyor.

Kendi kurduğunuz inceleyicide ucuz olan kısım token maliyetidir. Takımları asıl şaşırtan kurulumdur:

• Mimari bağlamın ve kabul edilebilir pattern’ların prompt’lara veya kural konfigürasyonuna kodlanması
• İnceleyicinin CI’a bağlanması, bulguların insanların zaten okuduğu PR’da görünmesi
• Sinyal oturana kadar false positive’lerin her gün triyaj edilmesi
• Takıma, aracın neyde yetkili neyde yetkisiz olduğunun öğretilmesi

Bunların hiçbiri tek seferlik iş değil. Kod tabanı değiştikçe prompt’lar ve kural setleri de kayar; bakımı bir linter konfigürasyonu gibi bütçeleyin. Sayaçla ölçen araçlarda bu kayma iki kez faturalanır: GitHub, repository custom instruction’larını inceleme başına maliyeti artıran etkenler arasında sayıyor, yani isabeti yükseltmek için eklediğiniz bağlam tekrar eden bir kaleme dönüşüyor.

AI Hatalarından Dersler#

Bu hatalar öğreticidir; çünkü genellikle eksik koda değil eksik dokümantasyona işaret ederler:

Bir güvenlik denetiminde, AI, custom authentication middleware’ı standart OAuth pattern’larına uymadığı için “potansiyel olarak güvensiz” diye işaretledi. Bu bulgu, custom çözümün hâlâ gerekçeli olup olmadığı veya sektör standartlarına geçilip geçilmemesi konusunda değerli bir tartışma başlattı. AI anlık açık konusunda yanılmış olsa da risk konusunda yanılmıyordu.

Bir performans incelemesinde, AI kötüye kullanımı önlemek için kasıtlı olarak yavaş bırakılmış bir veritabanı sorgusunu optimize etmeyi önerdi. Takip eden tartışma, kasıtlı performans trade-off’larının hiç dokümante edilmediğini ortaya koydu.

Onboarding sırasında, stil ve yapı hakkında tutarlı yorum yapan bir inceleyici mentorluğun tekrar eden yarısını üstlenir. İnsan inceleyiciler de yorumlarını her yeni gelene aynı kuralları anlatmaya değil, tasarım sorularına ayırır.

Etkinlik ve Takım Sağlığı Metrikleri#

İzlemeye değer iki metrik ailesi var ve takımlar genellikle ikincisini unutuyor.

Etkinlik:

• Bulgu kategorisi başına true positive oranı; güvenlik ve performans ayrı tutulmalı, harmanlanmış tek sayı hangi kuralın gürültülü olduğunu gizler
• İşaretlemeden düzeltmeye geçen süre; aynı ölçüyü insanların bulduğu sorunlarla karşılaştırın
• AI ve insan bulgularının kategori örtüşmesi; ikisi birbirine yakınsıyorsa inceleyicilerden biri gereksizdir

Takım sağlığı:

• AI yorumlarının sessizce kapatılmak yerine çözüme bağlanma oranı
• Bir PR’ın ilk insan incelemesi için beklediği süre
• Junior geliştiricilerin, inceleyicinin açıklamalarını kendi inceleme yorumlarında tekrarlayıp tekrarlamadığı

Etkinlik listesindeki üç ölçüm için yayımlanmış bir referans değer yok; onları kurup kendi baseline’ınızla karşılaştırmanız gerekir. Takım sağlığı tarafında ise sahadan ölçülmüş sayılar var.

Çözüme bağlanma oranı, araçtan araca çoğu rollout planının varsaydığından daha fazla değişiyor. “Go Home Copilot, You’re Drunk” başlıklı çalışma (arXiv:2607.21997), 341 Python repository’sindeki 54.713 agent yorumunu inceleyip çözüme bağlanma oranını Copilot için %72,9, Cursor için %67,2, Codex için %54,8 veriyor; aynı metrikte on sekiz puanlık bir fark. Yorumun iki özelliği ihtimali belirgin biçimde değiştiriyor: satır içi kod önerisi taşıyan yorumlar %75,5 oranında çözüme bağlanırken öneri taşımayanlarda oran %64,5’te kalıyor, çözüme bağlananlar da ortalama 616,6 karakterle bağlanmayanların 807,1 karakterinden kısa. Katkı verenlerin ilk beşte birini oluşturan çekirdek geliştiriciler ise Copilot yorumlarının %78,1’ini çözüme bağlamış.

Satıcı tarafındaki sayılar aynı yöne, farklı ölçekte işaret ediyor. GitHub, Nisan 2025’teki lansmandan bu yana 60 milyon Copilot kod incelemesi yapıldığını, bunu 12.000’den fazla kuruluşun kullandığını ve platformdaki her beş kod incelemesinden birinden fazlasının artık bu yolla yapıldığını bildiriyor. Aynı yazıya göre Copilot incelemelerin %71’inde işlem yapılabilir geri bildirim üretiyor ve inceleme başına ortalama 5,1 yorum bırakıyor.

Kanıtın rahatsız edici hale geldiği yer ikinci takım sağlığı metriği. EASE 2026’da sunulan ve insanların AI üretimi pull request’leri nasıl incelediğini ölçen çalışma (arXiv:2605.02273), agent tarafından açılmış 33.596 pull request’i inceledi; bunların %84,0’ü ya hiç kayıtlı inceleme almadı ya da yalnızca başka agent’lar tarafından incelendi, herhangi bir insan katılımı olanların payı %15,9’da kaldı. Aynı repository’lerin içinde yalnızca insanların yaptığı inceleme, insan yazımı pull request’lerde %25,21 iken AI üretimi olanlarda %8,08’e düşüyor. İnsan yorumlarının niteliği de değişiyor: AI pull request’lerindeki insan yorumlarının %25,92’si bir agent’ı yönlendiren talimatken, insan yazımı olanlarda bu oran %1,63. Eşleşmenin insan yarısı inceldiğini duyurmaz; birleşme oranı sağlıklı görünürken inceleme bileşiminin kayması olarak ortaya çıkar.

Sektör geneli benzer şeyi anket ölçeğinde söylüyor. DORA’nın yaklaşık 5.000 teknoloji profesyoneline dayanan 2025 State of AI-assisted Software Development raporunda katılımcıların %90’ı işinde AI kullandığını, %80’den fazlası verimliliğinin arttığını söylüyor; buna karşılık %30’u AI üretimi koda ya çok az güveniyor ya da hiç güvenmiyor. Teslimat bulguları ikiye ayrılıyor: AI benimsemesiyle throughput ve ürün performansı arasında olumlu, teslimat kararlılığıyla arasında süregelen olumsuz bir ilişki var. 2024 raporunda throughput da kararlılık da olumsuz taraftaydı; yani bir yıl içinde iki sinyalden biri yön değiştirdi, diğeri yerinde kaldı. Bu ölçekte bir araştırma programının iki cevabından birini değiştirmesi, işine gelen aileyi değil ikisini birden izlemek için yeterli gerekçe. DORA’nın kendi özeti de bu yönde: AI bir takımı düzeltmez, orada zaten var olanı büyütür.

Öncü gösterge, reddedilme oranıdır. Geliştiriciler AI yorumlarını okumayı bıraktığı anda diğer sayılar gerçek bir şeyi tarif etmez hale gelir.

Önce Halledilmesi Gerekenler#

Dokümantasyonla başla. İnceleyici devreye alınmadan önce mimari kararların ve kodlama standartlarının makine okunabilir biçimde var olması gerekir. AI yalnızca okuyabildiğini uygulayabilir; örtük bilgi prompt’a taşınırken yok olur. Bu aynı zamanda yukarıdaki false positive sorununun en ucuz çözümüdür: bulguların çoğu, inceleyicinin dokümante edilmemiş bir istisnayı doğru biçimde fark etmesinden ibarettir.

Takım dinamiğini planla. Senior geliştiriciler rollout’u kendi yerlerinin alınmasına doğru bir adım olarak okuyabilir; junior geliştiriciler ise kendi yargılarına güvenmeden önce inceleyicinin onayına bağımlı hale gelebilir. İkisi de çözülebilir, ama yalnızca birileri aracın ne için olduğunu ve neyi karara bağlamadığını açıkça söylerse.

Bu Ayrım Nerede Geçerli#

İki inceleyiciyi paralel çalıştırmak, pattern’lar servisler arasında tekrarlanıyorsa ve tek bir insan her PR’ı görmüyorsa karşılığını verir. Tüm düzenin dayandığı koşul budur; birleştirme adımı da iki bulgu setinin buluşmak zorunda olduğu yerdir.

Bu çizginin altında karşılığını vermez. Tek servis üzerinde çalışan üç kişilik bir takım kod tabanları arası görüşü zaten kafasında taşır ve ayar işi, bulguların getirisinden pahalıya gelir. Alan kuralları yalnızca insanların kafasında yaşıyorsa da karşılığını vermez; inceleyici her bilinçli istisnayı işaretler, bütçe de onunla tartışmaya gider. Önce kuralları yazın, ya da inceleyiciyi genel güvenlik ve performans pattern’larıyla sınırlayıp gerisini insanlara bırakın.

Kaynaklar#

• Snyk planları ve fiyatlandırması (yeni sekmede açılır) - Katkı veren geliştirici başına katman katman fiyatlar, her katmana bağlı test limitleri ve kimin katkı veren geliştirici sayılacağını belirleyen 90 günlük commit kuralı
• Snyk Code (yeni sekmede açılır) - Snyk’in SAST ürününün IDE ve pull request entegrasyonunu ve düzeltme önerilerini anlatan ürün sayfası
• Amazon Q Developer fiyatlandırması (yeni sekmede açılır) - Free ve Pro katman limitleri, kullanıcı başına abonelik ücreti ve satır bazlı hakların aşımdan önce ödeyen hesap düzeyinde nasıl havuzlandığı
• Amazon Q Developer ile kod incelemesi (yeni sekmede açılır) - Q Developer kod incelemelerinin detector türlerini, desteklenen dilleri ve otomatik, dosya ve proje incelemelerindeki boyut sınırlarını anlatan AWS dokümantasyonu
• Amazon CodeGuru Reviewer kullanılabilirlik değişikliği (yeni sekmede açılır) - Yeni repository ilişkilendirmelerinin kabul edilmediğini ve Amazon Q Developer’a geçiş yolunu duyuran AWS bildirimi
• GitHub Copilot kullanım bazlı faturalandırmaya geçiyor (yeni sekmede açılır) - Plan fiyatları ve her planın içerdiği AI kredisi tutarı; hangi Copilot özelliklerinin sabit abonelik yerine bu kredilerden sayaçla düştüğü
• Copilot kod incelemesi (yeni sekmede açılır) - GitHub’ın efor ayarına göre inceleme başına tahmini kredi maliyeti, maliyeti yükselten etkenler, atlanan dosya türleri ve bütçe bittiğinde ne olduğu
• 60 milyon Copilot kod incelemesi ve sayılmaya devam ediyor (yeni sekmede açılır) - GitHub’ın benimseme verileri: inceleme başına yorum sayısı, inceleyicinin ne sıklıkla sessiz kaldığı ve daha iyi geri bildirim için kabul edilen gecikme artışı
• Anthropic API fiyatlandırması (yeni sekmede açılır) - Model bazında milyon token başına input ve output ücretleri; kendi kurduğunuz bir inceleyicinin faturasını değiştiren prompt cache çarpanları ve Batch API indirimi
• “Go Home Copilot, You’re Drunk”: Agent Üretimi Kod İnceleme Yorumlarına Geliştirici Tepkileri (yeni sekmede açılır) - 341 repository’deki 54.713 yorum üzerinden üç inceleme agent’ının çözüme bağlanma oranları, bir yorumun dikkate alınma ihtimalini artıran özellikler ve geri kalanların neden bırakıldığına dair kategori dökümü
• These Aren’t the Reviews You’re Looking For: İnsanlar AI Üretimi Pull Request’leri Nasıl İnceliyor (yeni sekmede açılır) - AI’ın açtığı pull request’lerin gerçekte ne kadar insan incelemesi aldığını ve yazar bir agent olduğunda insan yorumlarının nasıl değiştiğini ölçen EASE 2026 çalışması
• DORA, State of AI-assisted Software Development 2025 (yeni sekmede açılır) - AI benimsemesi, üretilen koda duyulan güven ve AI kullanımının teslimat throughput’u ile teslimat kararlılığı arasında ayrışan ilişkisine dair anket bulguları
• DORA, Accelerate State of DevOps Report 2024 (yeni sekmede açılır) - Bir önceki yılın AI benimsemesi, verimlilik ve teslimat sonuçları bulguları; iki teslimat sinyalinden hangisinin yön değiştirdiğini görmek için
• Software Engineering at Google, Bölüm 20: Statik Analiz (yeni sekmede açılır) - Google’ın bir kontrolün kod incelemesinde yorum bırakabilmesi için aradığı etkin false positive eşiği, araçlarının ölçekte ulaştığı oran ve ikisinin arkasındaki bulgu bazlı geri bildirim mekanizması
• OWASP Benchmark Projesi (yeni sekmede açılır) - Projenin ticari araçlar için sonuç yayımlamadığını kendi ifadesiyle belirttiği sayfa ve sentetik test senaryolarının gerçek uygulamalardan ne kadar uzak olduğuna dair uyarıları