Yapay Zeka Çağında Kod İnceleme — YZ kodu yazdıktan sonra, kim gözden geçirecek?

Önceki yazımda (AI173), “doğrulama”yı kod neredeyse bedava hale geldikten sonra ortaya çıkan üçüncü yeni darboğaz olarak listelemiş ve sonunda “dördüncü bölümde ayrıca ele alacağım” diye not düşmüştüm. İşte bu yazı o sözü tutuyor. Önce sonuç: 2026 ortasına baktığımızda, YZ programlama araçlarının sunduğu en büyük değişken ne lisans sayısı, ne koltuk sayısı, ne de model benchmark skorları — inceleme kapasitesi.

AI Tarafından Üretilen Kodda Güvenlik ve Kalite Açıkları: 2025 Sektör Verileri

CodeRabbit, 2025 sonunda yayımladığı raporda 470 açık kaynak GitHub PR’ını analiz etti. Sonuç şu: YZ katkısıyla üretilen kod, saf insan eli değmiş koddan 1,7 kat daha fazla kusur barındırıyor (PR başına ortalama 10,83’e karşı 6,45; dosya boyutu ve karmaşıklık eşleştirilmeden). Güvenlik açıklarında alt sınıflara göre tablo daha da çarpıcı:

XSS: 2,74×
Hatalı parola işleme: 1,88×
Güvensiz doğrudan nesne referansı (IDOR): 1,91×
Güvensiz deserileştirme: 1,82×
Mantık/doğruluk hataları: 1,75×
Okunabilirlik: 3×+
Biçimlendirme: 2,66×
Hata yönetimi: yaklaşık 2×

Apiiro, Eylül 2025’te Fortune 50 şirketlerinin depolarında yaptığı taramayla (veri aralığı: Aralık 2024 – Haziran 2025) tablonun diğer yüzünü ortaya koydu. YZ üretimi kod, aylık güvenlik bulgularını yaklaşık 1.000’den 10.000’in üzerine taşıyarak 10× artış yarattı. Ayrıntılara inildiğinde:

Yetki yükseltme (privilege escalation) açıkları: %322 artış (mutlak sayı; kod hacmi artışına göre normalleştirildiğinde tahmini %60–80)
Mimari katman tasarım kusurları: %153 artış

Aynı dönemde sözdizimi hataları %76, mantık hataları ise %60 azaldı. Yani YZ, biçimsel kusurları toparlarken güvenlik ve mimari derinlikte ciddi bir borç bırakıyor.

Bu iki veri seti birlikte, özellikle düzenleyici bağlam için kritik bir noktaya işaret ediyor: Apiiro’nun %322’lik yetki yükseltme açığı artışının önemli bir kısmı yetki sınırlarında yoğunlaşıyor — bu sınırlar ise finans ve telekom sektöründe müşteri fonlarına ve müşteri verilerine karşılık geliyor. Yapay zekâ tarafından üretilen kodun büyük bölümü çalışır durumda, ama hata ve güvenlik açıkları orantılı biçimde artıyor; üstelik tehlikeli olanların payı sessizce büyüyor. (Metodoloji notu: CodeRabbit raporu satıcı bakış açısını yansıtır, Apiiro verileri ise üçüncü taraf bir güvenlik satıcısından gelir; bulguların yönü örtüşüyor, ancak rakamlar normalizasyon yöntemi gözetilerek yorumlanmalıdır.)

Bu olgular kurumsal düzeye indiğinde, her biri satın aldığınız araçların anlatısıyla taban tabana zıt iki beklenmedik sonuç tetikliyor.

I. İiki Karşıt Sezgi

Karşıt sezgi 1: Geliştiricinin rolü “kod yazan kişi”den “kod inceleyen kişi”ye dönüşüyor — ama incelemek, yazmaktan daha yorucu.

JetBrains’in Ocak 2026 araştırması (10.000+ geliştirici, 8 dil) geliştiricilerin %90’ının en az bir AI aracı kullandığını ortaya koyuyor; Pragmatic Engineer’ın Şubat 2026 raporunda ise daha çarpıcı bir bulgu var: kıdemli mühendislerin %56’sı mühendislik işlerinin %70’inden fazlasını AI araçlarına dayandırdığını söylüyor (ağır kullanıcıların kendi beyanına dayalı, kod satırı oranı değil). Bu, ara sıra birkaç satır kod yazdıran yardımcı bir araç değil; AI artık varsayılan çalışma biçimi haline geldi. Üretim ilişkileri zorunlu bir taşınma geçirdi: kod yazma işi AI’a kaldı, geliştirici ise zamanının büyük bölümünü okumaya ve değerlendirmeye, yani incelemeye ayırıyor. Başkasının kodunu okumak zaten yazmaktan daha zor ve yavaştır; AI’ın ürettiği tanıdık olmayan kodu okumak, bir de bunu uyumluluk sınırları ve iş kuralları çerçevesinde değerlendirmek, kendi kodunu yazmaktan belirgin biçimde daha yüksek bir bilişsel yük getiriyor. 2025-2026 döneminde geliştiricilerin sürekli dile getirdiği “AI beni daha çok yoruyor” şikâyetinin kökünde bu yatıyor — arka planda METR’ın Şubat 2026 tarihli tersine çevrilen anlatısı var (kıdemli geliştiricilerin AI tarafından %19 yavaşlatıldığı yönündeki erken dönem bulgusu yeni örneklemde kısmen tersine döndü; yeni katılan geliştiriciler hâlâ -%4’te; bütüncül değerlendirme: “inceleme bant genişliği üretim bant genişliğinden daha dar”).

Karşı-sezgisel 2: AI araçları ne kadar güçlüyse, organizasyonun ihtiyacı o kadar daha fazla araç değil, yönetişim.

Yavaşça AI Öğren 173 — Yazma Hızlandı, Darboğaz “İncelemeye” Taşındı

CodeRabbit raporunun 1,7 katlık hata oranı, Apiiro’nun %322’lik yetki yükseltme (privilege escalation) açığı: tek başına bakıldığında birer AI başarısızlığı gibi görünüyor. Ancak Kısıtlar Teorisi (Theory of Constraints — TOC) prizmasından bakıldığında, tablo değişiyor. Araç üretim kapasitesi arttı, fakat sizin inceleme kapasiteniz aynı hızda büyümedi. Bir sistemin çıktısı, en dar kesit tarafından belirlenir. AI “yazma” adımını genişletti; en dar kesit artık “inceleme” oldu. İnceleme bant genişliği artmadığı sürece, AI ne kadar hızlı yazarsa yazsın, biriktirdiğiniz teknik borç o kadar tehlikeli hale gelir. AI173’ün çıkarımı budur: otomasyon darboğazı yok etmez, yalnızca yerini değiştirir.

Bu cümleyi AI destekli yazılım geliştirmeye uyarlarken bir ekleme yapmak gerekir: yazılım geliştirme tek bir doğrusal boru hattının (pipeline) darboğazı değildir; çok sayıda paralel darboğazın dinamik olarak yer değiştirdiği bir yapıdır. TOC, doğrusal üretim hatları için formüle edilmiştir. AI destekli kodlama gibi paralel ve çoklu darboğazlı bir senaryoda en dar kesit “yazma”dan “incelemeye” doğru kayar; ama “inceleme”nin kendi içinde birbirinden bağımsız üç ayrı darboğaz belirir: doğrulama (verification), yönetişim (governance) ve uyumluluk incelemesi (compliance review). Her biri ayrı ayrı yeri dolduruyor.

Bu pratiğin iki katmanlı bir uygulama anlamı var. Birinci katman, otonom ajanları devreye almadan önce dört freni de takmaktır: zorunlu insan code review’ı, otomatik testler (AI kod değiştirdikten sonra mutlaka çalışmalı), güvenlik taraması (insan yazılan kodla aynı standartta) ve kademeli canlıya çıkış (AI’ın yaptığı değişiklikler küçük bir dilimle önce yayına alınır). AI’ın açtığı PR’lar inceleme dışı bırakılamaz. Bu, “AI kod yazsın” hedefini “AI kod yazsın + organizasyon bunu kaldırabilsin” mühendislik problemine taşımanın asgari eşiğidir; dörtlüden biri eksikse kontrolsüz bir yüzey ortaya çıkar. Carlini, Ocak–Şubat 2026’da sıkça alıntılanan bir örnek kayıt altına aldı: Bir Anthropic araştırmacısı, 16 Claude Opus 4.6 ajanını 2 hafta boyunca paralel çalıştırarak, yaklaşık 2000 oturum ve yaklaşık 20.000 dolarlık API maliyetiyle sıfırdan 100.000 satırlık Rust tabanlı bir C derleyicisi yazdırdı; derleyici Linux 6.9 çekirdeğini derleyebiliyor ve GCC torture test’inde %99 başarı elde ediyordu. Vurgulamak gerekir: Bu, kapalı bir alanda yapılmış kontrollü bir deney; Carlini kodu production’a çıkarmadı. “İncelemesiz uç senaryo” olarak okumak anlamlı, “hemen otonom ajanlara geçelim” şablonu olarak okumak yeniden kullanılabilirliği abartır. Code review’ı, otomatik testi, güvenlik taraması ve kademeli yayını olmayan bir organizasyonda bu örneği uygulamak, er ya da geç sorun çıkarır.

Daha Derin Katman: İnceleme Artık Hata Aramak Değil

İkinci katman daha örtük: incelemenin asıl meselesi hata bulmak değil; mimari uyum, uyum düzenlemesi (compliance) sınırları ve iş doğruluğu hakkında karar vermektir. Eski nesil mühendislerin en sık düştüğü tuzak, AI çağının inceleme mantığını geleneksel code review ile aynı sanmaktır. Geleneksel review “bu kod hatalı mı” sorusuna odaklanır. AI çağında review ise sorar: “bu kod bu dosyada, bu projede, bu uyumluluk sınırında var olmalı mı?”

CodeRabbit’ın raporladığı 1,82–2,74× güvenlik açığı artışı, Apiiro’nun ölçtüğü %322 yetki yükseltme (privilege escalation) açığı tam da bu kategoriden: AI yanlış bir şey yazmadı, ama yanlış yere, yanlış izinle, yanlış varsayılan konfigürasyonla yazdı. Bu tür sorunlar IDE içinde çözülmez; review masasında okunup anlaşılmayı bekler.

Endüstride yerleşik prensip şu: GitHub/GitLab branch protection + CODEOWNERS kuralları, “şema / auth / billing / uyumluluk sınırı” değişikliklerini kırmızı bayrakla işaretleyerek çift imza (dual sign-off) gerektiren yönlendirmelere bağlanır. Finans ve telekom operasyonlarında bu çoğunlukla tam bir review yerine backup veto modeliyle çalışır; spot-check oranı risk seviyesine göre kademelenir.

Mimari Karar Kayıtları (ADR), güvenlik ve uyumluluk temeli, iş kurallarının doğruluğu — AI çağında incelemeye gerçekten zaman ayrılması gereken yerler bunlardır.

Bu iki sezgiye aykırı gerçeği üst üste koyduğunuzda tablo netleşir: Yapay zekâ çağında kod inceleme süreci için şirketlerin üç şeyi değiştirmesi gerekiyor — geliştirme yöneticisini inceleme akışına dahil etmek, uyumluluk ve mimari temel çizgilerini PR yönlendirmesine yazmak, başarısızlık oranı gibi yönetişim metriklerini yönetim kurulu raporlamasına taşımak. Bu üç madde doğrudan Çin’in Bankaların İnternet Üzerinden Kredi Verme Yönetim Yöntemleri (《商业银行互联网贷款管理办法》, Çin Merkez Bankası PCBC düzenlemesi) kapsamındaki “model yönetişiminde üç savunma hattı” (iş birimi, BT, uyumluluk ve iç denetim) ilkesine karşılık geliyor; düzenleyici de resmi hemen anlıyor. Aşağıda dört katman halinde açıyorum.

II. Neden “Şimdi”: Doğrulamanın Yeni Darboğaz Oluşunun Mekanizması

AI173’ün üçüncü bölümündeki “Dördüncü bölümde ayrıca ele alınacak” sözünü yerine getirelim. 2026 ortasındaki bu pencerenin özgün tarafı şu: otonom ajanlar (Claude Code, Codex) “deneme” aşamasından “varsayılan kullanım” aşamasına geçiyor; 2026’nın ikinci yarısı öncesinde inceleme yükseltmesini tamamlamamış kurumlar, dördüncü çeyrekteki büyük promosyon trafiği / yıl sonu kod dondurma dönemi / düzenleyicilerin rutin denetim döneminde sorunları toplu olarak yaşayacak. Önce yeni darboğazlar içinde “doğrulama”nın neden en çok hafife alınanı olduğunu, ardından onu iki diğer yeni darboğazla (doğru problemi tanımlama, sistem entegrasyonu) tek bir şemada göstereceğim.

2024 H1
2025 H1
2025 H2
2026 H1
2026 H2

AI kod üretim miktarı 6× İnceleme kapasitesi 1.3×

Boşluk = risk birikimi (hatalar +1.7×, güvenlik açıkları +1.82–2.74×, yetki yükseltme +322%)
Oranlar yön gösterici niteliktedir; JetBrains 2026.1 araştırması, CodeRabbit 2025.12 raporu ve Apiiro 2025.9 raporuna dayanmaktadır

Asıl sorun şu: çoğu AI kodlama tartışması “doğrulamayı” otomatik olarak CI/CD, birim testleri ve lint kontrolleri olarak tanımlıyor. Bu, internet ürünleri dünyasının bakış açısı: kod buluta dağıtılır, birim testleri geçer, CI yeşil olur, merge edilir, üretime alınır. Bu akış internet ürünlerinin temposunda işe yarar; ama telekom, finans, üretim veya e-ticarete taşındığında işe yaramaz. Bu sektörlerde “doğrulama”; algoritma kaydı (ULAK 2023 AI 戦略, Çin’de AI algoritmalarının düzenleyici kaydı), sınıflandırılmış koruma değerlendirmesi (ISO 27001 + BTK 关键基础设施, Çin’in zorunlu siber güvenlik sınıflandırması), veri çıkışı değerlendirmesi (verilerin Çin dışına aktarımı için yapılan düzenleyici inceleme), Change Advisory Board onayı, mutabakat denetimi ve düzenleyici raporlamadır; kodla hiçbir ilgisi yoktur, ancak her biri haftalarca sürer. AI173’te bunun bir görselini çoktan vermiştik (kodlama hızlanır, darboğaz doğrulamadır), burada tekrar etmeyeceğiz. Asıl mesele, orada bırakılan soru işareti: AI’ın ürettiği kod, üretime geçmeden önce kaç aşamalı doğrulamadan geçmelidir?

Yedi aşamadan başlayın: otomatik test + code review + güvenlik taraması + mimari/ADR (Architecture Decision Record) değerlendirmesi + iş kuralları değerlendirmesi + uyum onayı (compliance clearance) + kademeli yayılım (canary/gray release). Her aşama ayrı bir bant genişliği tüketir. Bu yedi aşama bir araya geldiğinde, AI173’teki görselin “öbür yüzü” ortaya çıkar: AI, marjinal maliyetin en düşük olduğu dilimi hızlandırır (GPU süresi, lisans ücretleri); doğrulama ise kurumsal maliyetin en yüksek olduğu dilimi yer bitirir (düzenleme, kayıt, mutabakat).

Underestimated Second Root: Narrowing “Review” Down to “Code Review”

The two principal lineages of code review—Weinberg’s egoless programming from The Psychology of Computer Programming (1971, NASA/academic origins) and IBM’s Fagan Inspections (Fagan, 1976)—rest on the same assumption: code is written line by line, the author knows it best, and afterward another person re-reads it to catch mistakes. AI dismantles that assumption: code is emitted by AI in seconds, the author (AI) does not hand off context, and the reader (the developer) faces an unfamiliar artifact. The old “find the bug” assumption no longer holds. The new review assumption is: Should this code exist in this file at all? Does it bypass existing architectural decisions? Does it land inside or outside our compliance perimeter? Could its default configuration turn into a security vulnerability in production?

Each of those three questions requires someone who understands the business and the architecture and the compliance boundary. Tools only assist. This is what it means to elevate “review” from a lint gate in CI/CD to an engineering governance checkpoint.

Üç Katmanlı İnceleme Modeli: AI ön-İnceleme, İnsan Denetimi, Yönetişim Kuralları

Yukarıdaki analizi uygulanabilir bir yapıya sıkıştıralım. Üç katmanlı model bir ikame ilişkisi değil, üst üste binen (stacking) bir ilişkidir — her PR aynı anda üç katmandan da geçer ve her katman farklı bir sorun sınıfına bakar.

Layer 1 saniye-dakika aralığında çalışır — AI’ın yazdığı her kod satırı önce araçtan geçer. CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot ve Antigravity Review; PR açıldıktan sonra saniyeler-dakikalar içinde yorum üretebilir; lint, güvenlik açıkları, tekrar eden kodlar, adlandırma ve bağımlılık risklerini kapsar. Bu katmanın maliyeti son derece düşüktür (PR sayısı ne kadar artarsa artsın, araçlar aynı abonelik ücretini çeker), kapsama oranı yüksektir (her PR geçer) ve bant genişliğinin tabanını oluşturur. Ancak kör noktaları da gayet net: mimari uyum, uyumluluk sınırları ve iş doğruluğunu çözemez. CodeRabbit raporunun raporlama mantığı “açık sorunların büyük kısmını otomatik olarak eleyelim” şeklindedir, ama geriye kalan örtük riskler (varsayılan yapılandırmalar, yetki sınırları, detaylara gizlenmiş hata işleme yolları) insan gözetimi gerektirir. Bu katman yalnızca tabandır, varış noktası değildir.

Katman 2: Saatler-günler aralığında çalışır

Yüksek riskli değişiklikler (çekirdek modüllere dokunan, veritabanı şemasını değiştiren, kimlik doğrulama/faturalama/uyumluluk modüllerine müdahale eden) mutlaka insan spot-check’inden geçmelidir; bu inceleme mimarlardan, iş sahiplerinden ve güvenlik sorumlularından oluşan küçük bir ekip tarafından yapılır. CodeRabbit’ın raporladığı güvenlik açıklarında 1,82–2,74×, Apiiro’nun raporladığı yetki yükseltme açıklarında %322 iyileşme gösteren vakaların önemli bir kısmı tam da bu katmanda tespit edilir: AI’ın yazdığı kod görünüşte doğru çalışır, ama varsayılan yapılandırmalar, yetki sınırları ve hata yönetimi yolları detaylarda gizlidir. Orta-düşük riskli değişiklikler için örnekleme yeterlidir (iç eğitim müşteri deneyimlerine dayalı olarak %20–30 örnekleme oranı önerilir; bu bir endüstri standardı değildir); her PR’ı tek tek insan gözünden geçirmeye gerek yoktur. Amaç, insan bant genişliğini “her şeyi incelemek”ten “kilit olanları seçmek”e kaydırmaktır.

Bu katmanın en sık düşülen tuzağı, standartların gevşetilmesidir: ekipler AI PR’larının hızlı ilerlemesi için “yüksek risk” eşiğini sessizce düşürür. Standartları gevşetmek kısa vadede rahatlık sağlar, ama bir kaza geldiğinde iş işten geçmiş olur.

Layer 3 gün-hafta ölçeğinde işler — uyumluluk sınırlarına, düzenleyici raporlamaya, veri transferine, SLA’lara ve ekipler arası mimari değişikliklere dokunan işler bu katmandan geçer: Change Advisory Board (Değişiklik Danışma Kurulu (CAB)) incelemeleri, kayıt başvuruları, koruma seviyesi değerlendirmeleri (Çin’in “ISO 27001 + BTK 关键基础设施” — kısaltması Dengbao, zorunlu siber güvenlik derecelendirmesi) ve düzenleyici iletişim. AI173 tablosundaki “AI’ın kıramadığı” turuncu blok budur; ağır denetime tabi sektörler için en pahalı kalem. AI174’ün yargısı şudur: AI Layer 3’ü üstlenemez, ama Layer 1+2 düzgün yapıldığında düşük riskli değişikliklerin büyük çoğunluğu Layer 3’e ulaşmadan durdurulabilir (iç eğitim müşteri örnekleminde tahminen %80–90’si). Geriye kalan %10–20 yüksek riskli değişiklik Değişiklik Danışma Kurulu (CAB)’a gider; böylece Değişiklik Danışma Kurulu (CAB)’ın bant genişliği şirketin tamamından yalnızca gerçekten yönetime muhtaç değişikliklere odaklanır. Değişiklik Danışma Kurulu (CAB) kuyruk süreleri kısalır, genel teslim ritmi hızlanır — bu, inceleme sürecinin en kolay hafife alınan “yönetişim bant genişliği kazanımı”dır.

Layer 3’teki uyumluluk imzaları kâğıda dökülmelidir. Layer 3 yönlendirmesinin tetiklediği her PR için tam bir iz zinciri tutulmalıdır: PR farkı + inceleme yorumları + iş sahibi + uyumluluk sahibi çift imzası + zaman damgası + model doğrulama raporu eki; saklama süresi finansal hizmetlerde 5 yıl, telekomda 3 yıl (referans: KVKK 6698 §55 — Çin Kişisel Bilgi Koruma Kanunu, Çin Bankacılık ve Sigorta Düzenleme Kurumu’nun 2020/24 sayılı rehberi ve Çin Sanayi ve Bilgi Teknolojileri Bakanlığı’nın algoritma kayıt yönetmeliği). Bu madde düzenleyici iletişim için sert bir delildir, kâğıt üzerinde uyumluluk değil.

4. İnceleme Aracı Seçimi: CodeRabbit Tek Cevap Değil, Ama Şu Anki Fiili Taban Çizgisi

Üç katmanlı modeli araç katmanına indirgeyelim. Bu bölüm yalnızca Katman 1 seçimini ele alıyor — Katman 2 ve 3 büyük ölçüde organizasyon ve süreç meselesi; araçların katkısı sınırlı.

Kritik Tasarımın Üç Bileşimi: Tetikleyici Koşullar Risk Düzeyiyle Kodlanır, Satır Sayısı veya PR Boyutuyla Değil

Pratikte risk düzeyi belirlemesi yapay zekanın kendi öz değerlendirmesine bırakılamaz — yapay zekanın uyumluluk farkındalığı yoktur; “müşteri kimlik numarası alanına dokunmak”ın KVKK (Türkiye) veya GDPR (AB) açısından kırmızı çizgi olduğunu bilmez. Belirlemenin iki unsurdan geçmesi gerekir: PR sahibinin PR şablonunda manuel olarak işaretlediği kontroller (şema değişiyor mu? auth değişiyor mu? billing değişiyor mu? uyumluluk sınırı kayıyor mu?) + CODEOWNERS kurallarıyla çift onay. İşaretlenen sonuca göre PR uygun katmana yönlendirilir:

Düşük riskli PR’lar → Katman 1, otomatik merge (izin verilen dosya yolları dahilinde + hata kesici mekanizması; 30 günlük pencerede otomatik merge’lenen herhangi bir PR üretim olayına yol açarsa otomatik süreç durdurulur ve tamamı manuel review’a geri çekilir).
Orta riskli PR’lar → Katman 2, spot-check.
Yüksek riskli PR’lar → Katman 3, yönetişim süreci.

Bu “riske uyumlu yönlendirme” yaklaşımı, review yükseltmenin en gelişmiş biçimidir.

GitHub Marketplace’in AI kod inceleme kategorisinde kurulum sayısı açısından ilk sırada CodeRabbit yer alıyor (Eylül 2025’te Series B turunda 550 milyon dolar değerlemeye ulaşmış, 2026 Q2 itibarıyla yıllık yinelenen geliri 40 milyon dolar — Sacra verileri). CodeRabbit, “AI inceleme asistanını” PR yorum akışına gömüyor; her yorum tıklanabilir açıklamalar, düzeltme önerileri ve önem derecesi içeriyor; özellikle birim testi kör noktalarında çok etkili. GitHub Actions ile en derin entegrasyona sahip olması, PR sayısına göre kademeli fiyatlandırma sunması ve kurumsal sürümde özel model, beyaz liste ve şirket içi bilgi tabanı desteği sağlaması öne çıkıyor. Yukarıda atıfta bulunulan 1,7× hata ve 1,82–2,74× güvenlik açığı oranları, CodeRabbit raporunun kendi yayımladığı raporlardan geliyor. Çalışma şekli özetle şu: “AI inceleme asistanını” PR yorum akışına yerleştiriyor; her yorumda tıklanabilir açıklama, düzeltme önerisi ve önem seviyesi sunuyor; birim testi kör noktalarında özellikle başarılı. GitHub Actions ile en sıkı entegrasyon onda; PR sayısına göre kademeli fiyatlandırma uyguluyor; kurumsal pakete özel model, beyaz liste ve iç bilgi tabanı eklenebiliyor.

GitHub Copilot Review‘ı tercih etmek için tek bir gerekçe kalıyor: zaten GitHub Enterprise müşterisiyseniz ve yeni bir tedarikçiyle uğraşmak istemiyorsanız. Ancak kuralların derin biçimde özelleştirilememesi yapısal bir zayıflık; zamanla kural kütüphanesi CodeRabbit raporunun gerisinde kalacaktır.

Sourcery, Python ekosistemi içinde tartışmasız en güçlü otomatik kod inceleme aracıdır: PR aşamasında doğrudan yeniden yapılandırma (refactoring) önerileri sunar (hata tespitinin ötesinde, kodu yeniden yazar) ve özellikle tip anotasyonlarının tamamlanması ile teknik borç temizliği konularında son derece etkilidir. Çapraz dil desteği açısından sınırlıdır — TypeScript ve Go için yeterli düzeye yeni ulaşmıştır, diğer dillerde kapsamı oldukça zayıftır.

Cursor BugBot, Cursor editöründeki sohbet bağlamını görebilme yeteneğiyle öne çıkar; yapay zekâ ile yaptığınız tüm konuşmaları analiz ederek üretilen koda yönelik bağlama duyarlı bir inceleme sunar. Cursor dışındaki projelerde kullanılamaz.

Antigravity Review, Google’ın Kasım 2025’te Antigravity platformuna entegre ettiği inceleme yeteneğidir; Gemini 3 modeli ile Google Cloud’un kurumsal uyumluluk altyapısından güç alır. 2026’nın ilk yarısında hızlı bir iterasyon sürecindedir; kural kütüphanesi CodeRabbit kadar geniş değildir ve kurumsal sürümün fiyatlandırma/dağıtım modeli henüz netleşmemiştir.

Seçim kriterlerini şu sıraya göre dizin: kural özelleştirilebilirliği > PR yorum kalitesi > entegrasyon derinliği > fiyat. Layer 1 araçları uzun süre kullanacaksınız; kuralları özelleştiremiyorsanız, aracın kendi güvenlik modeline mahkum olursunuz. PR yorumları zayıfsa (AI inceleme ajanı sadece “burada bir sorun var” deyip nedenini ve nasıl düzeltileceğini söylemiyorsa) geliştirici zamanınız boşa harcanır. Entegrasyon derinliği adaptasyon maliyetini belirler. Fiyat dördüncü sırada ama önemsiz değil; aynı segmentteki araçların fiyat farkı %30’u geçmiyor, oysa ilk üç kriterdeki fark fiyattan çok daha belirgin.

İki karşıt seçim ilkesi: Birincisi, finans, kamu savunması, askeri ve telekomünikasyonun kritik alanlarında özel dağıtım veya self-hosting olmazsa olmaz bir giriş şartıdır. Ama özel dağıtım tek başına bir çözüm değildir; inceleme aracı kodunuzun tamamını görecek (PR diff + repo geçmişi), yani kodu üçüncü taraf bir işleme teslim etmiş oluyorsunuz. Bu da KVKK 6698 §21 kapsamında veri işleme yetkisi veren bir sözleşmeyi zorunlu kılar; salt teknik izolasyon yeterli değildir. İkincisi, AI pre-review ve insan review “ya/ya da” ilişkisi değildir; CodeRabbit + GitHub Copilot Review gibi iki Layer 1 aracın üst üste kullanılması büyük organizasyonlarda standart pratiktir. Kuralları farklıdır, yakaladıkları açık türleri birbirini tamamlar; tek bir aracın kör noktaları her zaman olacaktır.

Beş. Dört sektörde uygulama: Her bir düzenleyici bağlamda inceleme yükseltmesinin farklı biçimleri

Telekom — Paket/Faturalama Değişiklikleri İçin İnceleme Sürecinin Yükseltilmesi. Bir bölgesel operatörün (a regional carrier) AI iç eğitim değerlendirmesinde bana şu çizelgeyi göstermişlerdi: her paket değişikliği kodlamadan canlı yayına kadar 11 aşamadan geçiyor; AI, bunlardan “kodlama” kısmını 2 günden 0,5 güne indirmiş — ama Değişiklik Danışma Kurulu (CAB) (Change Advisory Board), algoritma kaydı (faturalama modellerini ilgilendiren kısım), eşit koruma seviyesi değerlendirmesi (中国ISO 27001 + BTK 关键基础设施 — Çin’in siber güvenlik çok kademeli koruma denetimi, MLPS), veri çıkışı onayı (yurt dışı model kullanımı nedeniyle, Industrial and Information Technology Sector Data Security Management Measures (Trial) kapsamındaki ayrı çıkış negatif listesine göre — standart KVKK 6698 sözleşmesinin ikame edemeyeceği bir süreç), ve mutabakat denetimi adımlarının her biri birkaç günden bir aya kadar süre yutuyor. Algoritma kaydı tek başına, materyal hazırlığından MIIT geri bildirimine kadar tipik olarak 4–6 ay sürüyor — asıl darboğaz olan adım da bu. Toplam teslim süresi neredeyse hiç kıpırdamadı. İnceleme sürecini yükseltmenin yönü şu: Layer 1 araçları, “faturalama/kimlik doğrulama/uyumluluk modüllerine dokunuldu” sinyallerini tanıyabilmeli ve risk seviyesini otomatik olarak yukarı çekmeli; ardından talebi, iş sahibi (business owner) ile uyumluluk sahibinin (compliance owner) birlikte imzaladığı Layer 2’ye yönlendirmeli. Değişiklik Danışma Kurulu (CAB) katmanı ise ancak gerçekten düzenleyici raporlamayı (regulatory reporting) ilgilendiren değişiklikler için ikinci bir gözden geçirme yapmalı. Bu yolun özü, Değişiklik Danışma Kurulu (CAB) bant genişliğini tüm değişikliklerden (acil yamalar dahil) ayda 5.000–8.000 iş kaleminden, gerçekten yönetişime muhtaç olan (yüksek riskli) değişikliklere, yani ayda yalnızca 100–200 iş kalemine indirmek. Yükseltmeden önce darboğaz Değişiklik Danışma Kurulu (CAB)’ydi; yükseltmeden sonra Değişiklik Danışma Kurulu (CAB), tam tersine, en hızlı geçilen aşama haline geldi — çünkü önceki 11 aşamadan 8’i otomasyon/kural tabanlı ön inceleme ile eleniyor.

Telekom sektörünün en gizli acı noktası Değişiklik Danışma Kurulu (CAB) değil — model açıklanabilirliğidir. Faturalama modeli, her faturanın ücret kaynağını açıklayabilmelidir; AI kara kutu modeli devreye girdiğinde, müşteri şikayetleri geldiğinde kaynağa kadar inilebilmelidir. BTK 利用者申立 şikayetlerinin ilk üç senaryosu (numara taşıma, fatura erişilebilirliği, hattın açılıp kapatılması yönetimi) tetiklendiğinde, iş birimi yayına almadan önce grup tüketici koruma ön onayından geçmelidir; bu süreç Change Advisory Board’ın (Değişim Danışma Kurulu) yerine geçemez.

Finans — Kredi Risk Modeli İnceleme Sürecinin Yükseltilmesi. Bankaların temel sistemlerinde, bir risk modelinin canlıya alınmasının gerçek yolu şu sırayı izler: Model Doğrulama Birimi (MDB) (Model Validation Unit / Model Doğrulama Birimi) bağımsız doğrulama → Model Risk Komitesi onayı → İş biriminin düzenleyici kayıt başvurusu → Düzenleyici geri bildirimi → Kayıt onayının ardından canlıya alma. Bu beş adım birbirinin yerine geçemez; belirli bir sıraya tabidir. Yapay zekâ destekli kod yazımının hız kazandırabileceği alanlar son derece dardır (script üretimi, feature engineering kodları, veri ön işleme kodları); ancak yapılan her değişiklik düzenleyici sınırlara temas eder — örneğin etiketlerin (label) değiştirilmesi, Çin’in Ticari Bankaların İnternet Üzerinden Kredi Verme Yönetmeliği (《商业银行互联网贷款管理办法》) Madde 24’ü veBDDK 通知〔2020〕24号文 (CBIRC’nin 2020/24 sayılı düzenleyici belgesi, önemli model değişiklikleri için yeniden kayıt zorunluluğu) kapsamına girer. İnceleme sürecinin yükseltilmesi şu yönleri izlemelidir: Layer 1, “feature/etiket/eşik/model ağırlıkları” değişikliklerini tespit edebilmeli ve yüksek riskli bir rotaya zorunlu olarak yönlendirmelidir. Layer 2‘de kredi risk işini bilen bir sorumlu ile veri uyumluluğundan sorumlu bir kişinin çift imzası gerekir; Model Doğrulama Birimi (MDB) ise iş biriminden ve IT biriminden bağımsız olmalıdır (BDDK 通知〔2020〕24号文 sert bir gerekliliktir). Layer 3 ise model doğrulama + BDDK 規制データ報告 veri raporlaması + BDDK/TCMB 規制データ報告 raporlaması + KVKK 6698 (Kişisel Bilgi Koruma Kanunu) değerlendirmesi + algoritma adalet denetimini (cinsiyet/yaş/coğrafi bölge değişken olarak kullanılmamalıdır) kapsamalıdır.

Gerçek Bir Acı Nokta: Katman 2 Olmadan Araç İşe Yaramaz

Bir joint-stock bank, AI özellik mühendisliği aracını devreye aldıktan sonra model doğrulama kuyruğunun 8 haftadan 12 haftaya çıktığını gördü — Model Validation Unit (Model Doğrulama Birimi (MDB)), AI tarafından üretilen özelliklerin PSI/CSI drift’ini madde madde yeniden incelemek zorunda kaldı, üstelik Model Doğrulama Birimi (MDB) ile veri uyum ekibi arasındaki veri paylaşımında ciddi sürtüşme yaşandı (Model Doğrulama Birimi (MDB) ham özellik dağılımlarını görmek istiyor, ancak veri uyum ekibi, Çin’in Kişisel Bilgi Koruma Kanunu anlamına gelen KVKK 6698’a atıfla, Model Doğrulama Birimi (MDB)’nun müşteri düzeyindeki verilere doğrudan erişmesine izin vermiyor; izlenebilecek tek yol “model doğrulama sandbox’ı + maskelenmiş toplama özellikleri” olarak dar bir koridordan geçiyor). Önce Katman 2’deki insanları kadroya alın, sonra araçtan söz edin. Ne kadar güçlü olursa olsun, işi ve uyumu (compliance) bilen insanların spot-check yapmadığı bir inceleme yükseltmesi havada kalmış bir kule olur.

Not: Bu yazıdaki Katman 2, büyük ölçekli LLM dağıtımlarında önerilen üç katmanlı insan-içinde-döngü (human-in-the-loop) kalıbının orta katmanına karşılık gelir: Katman 1 bireysel geliştirici düzeyinde spot-check yapar; Katman 2 alan uzmanları + risk/uyum ekipleri inceleme, doğrulama ve istişareden sorumludur (bankacılık ve düzenlenmiş sektörler için Model Doğrulama Birimi (MDB), risk komiteleri, model risk yönetimi gibi yapılar); Katman 3 kurumsal düzeydeki yönetişim, denetim ve kurul düzeyinde onayları kapsar.

Üretim — MES Proses Değişikliği İnceleme Sürecinin Yükseltilmesi. İmalat sektöründe yapay zekâ ile kod yazmanın çekiciliği büyük (hat entegrasyonu, kalite kontrol modelleri, proses planlama); ancak MES değişiklikleri çoğu zaman güvenlik kilitlerine dokunur, tek bir proses parametresinin değişmesi tüm hattın durmasına yol açabilir. İmalat know-how’ı göründüğünden çok daha derindir: OEE (Genel Ekipman Etkinliği) (Toplam Ekipman Etkinliği) kilitleri, SPC (İstatistiksel Proses Kontrolü) (İstatistiksel Proses Kontrol) kontrol grafikleri, parti izlenebilirliği mantığı, fire/geri besleme akışlarına dokunmak yüksek riskli kabul edilir; salt “proses eşik değerine” bakılarak karar verilemez. İnceleme sürecinin yükseltilmesinin yönü şöyle olmalıdır: Katman 1, “güvenlik kilidi / OEE (Genel Ekipman Etkinliği) / SPC (İstatistiksel Proses Kontrolü) / parti izlenebilirliğine dokunan” değişiklikleri en yüksek risk olarak işaretlemeli ve otomatik birleştirmeye (auto-merge) izin vermemelidir; Katman 2’de proses mühendisi ile güvenlik mühendisinin ortak imzası zorunlu olmalıdır; Katman 3 ise pilot çalıştırma + kademeli yayılımdan (önce tek bir hatta küçük partiler halinde denenmeli, güvenlik kilidi yan etkisi olmadığı doğrulanmalı, sonra genişletilmeli) geçmelidir. Bu alanın darboğazı Katman 2’deki insanda düğümlenir: deneyimli proses mühendisleri kıttır, zamanları üretim tarafından çokça emilir; inceleme sürecini yükseltmek aslında “onların dikkatini günlük kontrollerden yüksek riskli PR’ların yeniden değerlendirmesine kaydırmaktan” ibaret bir kaynak yeniden tahsisidir.

E-ticaret — Promosyon kurallarında code review seviyesinin yükseltilmesi. E-ticarette yapay zekâ ile kod yazmanın sağladığı verimlilik artışı en belirgin biçimde frontend sayfaları, pazarlama kuralları, veri panoları ve öneri algoritmaları gibi alanlarda görülüyor; ancak büyük kampanya dönemlerinde yapılan kod değişiklikleri doğrudan ödeme altyapısına, fraud (risk kontrolü) zincirine ve finansal mutabakat süreçlerine temas ettiğinden, tek bir hata yüz milyonlarca birim para (yuan) cinsinden kayıp anlamına gelebilir. Review yükseltmesinin yönü şöyle: Layer 1, “kampanyayla ilgili modüllere/kuponlara/flash sale’lara/stoğa dokunan” her değişikliği en yüksek risk seviyesi olarak işaretlemeli; Layer 2, iş birimi sahibi ile risk (fraud) sahibinin ortak onayından geçmeli; Layer 3, kanarya (gray) dağıtım + uçtan uca yük testi ile doğrulanmalı. E-ticaretin kendine özgü yanı, kampanyaların belirli zaman pencerelerinde yoğunlaşması: Singles’ Day (11.11), Mid-Year Sale / 618 ve Yeni Yıl Festivali’nin çevresindeki ikişer haftalık dönemlerde review kriterleri her zamankinden daha sıkı olmalı, fakat aynı dönemde review bant genişliği üretim trafiği tarafından en çok sıkıştırılmış halde olur. Bu sektördeki saha pratiği “normal zamanda esnek, savaş zamanında sıkı” prensibidir: kampanya penceresinden bir hafta önce tüm yüksek riskli değişiklikler dondurulur ve yalnızca bug fix kabul edilir; review bant genişliği, dondurulan backlog’u temizlemeye odaklanır, böylece yüksek riskli değişikliklerin kampanya penceresine sızması engellenir.

Dört sektörü inceledikten sonra ortaya çıkan tablo net: inceleme yükseltmesinin asıl meselesi araç satın almak değil, risk yönlendirme mekanizmasını yeniden tasarlamaktır. Her sektörün Katman 2/3 yönlendirme koşulları farklıdır (telekomda Değişiklik Danışma Kurulu (CAB) + algoritma kaydı (Çin’de algoritmik tavsiye sistemleri için zorunlu düzenleyici kayıt) + model açıklanabilirliği, finansta Model Doğrulama Birimi (MDB) (Model Validation Unit / Bağımsız Model Doğrulama Birimi) + model doğrulaması + BDDK 規制データ報告 (otomatik model stres testi çerçevesi) + algoritmik adalet, üretimde pilot çalıştırma + kademeli yayılım (canary/gray) + OEE (Genel Ekipman Etkinliği)/SPC (İstatistiksel Proses Kontrolü) (Toplam Ekipman Etkinliği / İstatistiksel Proses Kontrolü), e-ticarette büyük kampanya dönemlerinde kod dondurma (code freeze/lock)). Ancak Katman 1’deki araç mantığı ortaktır: “yüksek riski tespit et, otomatik etiketle, zorunlu yönlendir.” Araç katmanında bir-iki Katman 1 çözümünü sektörler arası satın almanız gayet mümkündür; süreç katmanı ise sektöre göre mutlaka yeniden tasarlanmalıdır.

VI. Karar Alıcılar İçin Çıkarımlar

Ters yönde öz denetim — ekibiniz AI çıktılarına karşı giderek daha fazla mı yoksa daha az mı güveniyor? AI PR (Pull Request) gözden geçirme süreciniz nasıl işliyor: yüzde yüz manuel inceleme, riske göre örnekleme, ya da sessizce geçirme? Son altı ayda Katman 3 yönlendirmeniz kaç kez tetiklendi? Bunlardan kaçında sorun tespit edildi? Kaçında gerçek bir üretim olayı yakalandı? Yönetim kurulu bu üç rakamı talep ettiğinde elinizde cevap yoksa, yönetişim yapınız yalnızca kağıt üstünde bir uyumluluktur.

Çıkarım 1: İnceleme yükseltmesi teknik bir satın alma değil, organizasyonel yetenek yükseltmesidir. CodeRabbit Pro aylık 24 $/koltuk (Pro Plus 48 $/koltuk; PR oluşturan geliştirici başına fiyatlandırılır); 200 kişilik bir ekip için yıllık yaklaşık 58 bin dolar, kurumsal lisanslarda bunun 3-5 katı. Bu rakamlar, milyon dolarlık Ar-Ge bütçelerinin yanında küçük kalır. Asıl maliyet 2. katmanda insanların tam kadro olması ve 3. katmanda süreçlerin yeniden tasarlanmasıdır. Bunlar bütçeyle satın alınamaz; gereken, organizasyonun değişmeye istekli olması ve kıdemli mühendislerin zamanlarını bu inceleme işlerine ayırmayı kabul etmesidir. İnceleme yükseltmesini bir türlü hayata geçiremeyen ekiplerin neredeyse tamamı, bunu klasik bir BT projesi gibi yönetiyor: lisans dağıt, araç kur, KPI ata. Oysa işi gerçekten ilerletenler, Ar-Ge yöneticileriyle uyum ve uyumluluk sorumlularını aynı masaya oturtup PR yönlendirme kurallarını birlikte tanımlayan ekiplerdir. Bu, yönetimi bir “maliyet kalemi” olmaktan çıkarıp “bant genişliği varlığına” dönüştüren bir bütçe sinyalidir; ancak o zaman bütçe “daha fazla lisans alalım”dan “inceleme bant genişliğini artıralım”a kayar.

İkinci Çıkarım: Otonom ajanlara geçmeden önce AI pre-review mutlaka hazır olmalı. Bu, “motoru konuşmadan önce freni tak” ilkesinin öteki yüzü: Otonom ajanlar (Claude Code, Codex gibi) onlarca dosyayı tek başına değiştirebilir, PR açabilir, shell komutları çalıştırabilir; bu yetenek devreye girmeden önce Layer 1’in “hangi modüle dokunuluyor, hangi sınır geçiliyor” sorusunu algılayıp ilgili katmana yönlendirmesi şart. Olgunluk için önerilen nicel eşik: Layer 1’de otomatik merge geçiş oranı ≥%95, Layer 2’de spot-check kapsama oranı ≥%20, üst üste 3 ay sıfır P0 incident. Carlini’nin 100 bin satırlık Rust tabanlı C derleyicisi örneği sizden uzak değil — otonom ajanlar 2 haftada üretime hazır bir proje teslim edebildiği gibi, review altyapısı olmayan bir organizasyonda 2 haftada 20 bin üretim-riskini biriktirebilir; bir başka daha kıyaslanabilir sektör örneği Stripe’ın “Minions” ajanı — haftada yaklaşık 1.300 PR birleştiriyor, sıfır insan-yazımı kod, yalnızca insan review’ı — yani AI tam otomatik üretim + insan yalnızca-review bu modelin imzası; işte review olgunlaşmasının vardığı nokta budur.

Çıkarım Üç: İnceleme yükseltmesinin “kazancı” ve “kaybı” da bant genişliğiyle birlikte hesaplanmalı.

“İnceleme bant genişliğini” yeniden tanımlayalım — bu yalnızca review masasındaki insan-saat değil, tüm organizasyonun riski tanıma, yönlendirme ve işleme kapasitesinin toplamıdır. CodeRabbit raporunda “açık sorunların büyük kısmını otomatik yakaladığı” ifadesi işin sadece bir parçası; AI’ın gerçekten iyi kullanılıp kullanılamayacağı, kalan örtük risklerin (mimari uyum, uyumluluk sınırları, iş doğruluğu) Katman 2/3’te yeterli insan gücü bulup bulamamasına bağlı.

İnceleme yükseltmesinde en sık düşülen başarısızlık kalıbı, AI’ın PR’lerini otomatik merge etmesine izin vermektir: “AI’ın verimliliğini daha bariz göstermek” adına Katman 1 kurallarını sessizce gevşetmek, Katman 2’yi %5 örnekleme oranına çekmek ve Katman 3’ü fiilen işlevsiz bırakmak. Kısa vadede rakamlar parlak görünür, uzun vadede kaza oranı artar — AI hızlı yazar + review gevşetilir, teknik borç orantılı şekilde büyür. CodeRabbit raporunun 1,7× hata ve Apiiro’nun %322 yetki yükseltmesi şeklindeki çift yüksek uyarısı, işte bu tür gevşetmenin toplam bedelidir; tek bir noktadaki kayıp değil. İnceleme bant genişliği, PR hacmiyle aynı oranda genişletilmelidir; orantısızlık kontrolden çıkmak demektir.

30 Günlük Uygulama Listesi (“Pazartesi hangi toplantıyı açacağım, hangi dosyayı değiştireceğim” düzeyinde detay):

1. Hafta: Mevcut PR yönlendirme kurallarını envanterleyin ve “şema / auth / billing / uyumluluk” olmak üzere dört kategoriye göre kırmızıyla işaretleyin; son 90 gündeki Katman 3 tetiklenme sayısını ve ortalama kuyruk süresini çıkararak temel metrik (baseline) olarak belirleyin.
2. Hafta: Katman 1 araçlarından birini (CodeRabbit veya GitHub Copilot Review arasından) seçin ve “on-prem dağıtım” zorunluluğuna uymayanları eleyin; kuralları yapılandırın; PR şablonuna risk seviyesi için manuel işaretleme alanı ekleyin.
3. Hafta: Katman 2 için iş sahiplerinin (business owner) ve uyumluluk sahiplerinin (compliance owner) listesini oluşturun, spot-check örnekleme oranını tanımlayın (önerilen: %20–30); CODEOWNERS dosyasını modüllere göre sahipleriyle eksiksiz biçimde düzenleyin.
4. Hafta: Aşağıdaki 5 metriği PMO haftalık raporuna taşıyın: ortalama PR inceleme süresi, değişiklik hata oranı, inceleme sonrası kaçırılan defect oranı, Katman 2/3 ortalama kuyruk süresi, Katman 3 yönlendirmesinin tetiklediği uyumluluk olayı sayısı. Eş zamanlı olarak otonom ajan giriş eşiği olarak şu kriterleri belirleyin: Katman 1 geçiş oranı ≥%95, Katman 2 spot-check kapsama oranı ≥%20, üst üste 3 ay P0 incident olmaması.

Destekleyici metrikleri de devreye almak gerekir: ortalama PR inceleme süresi, değişiklik hata oranı, inceleme sonrası kaçırılan defect oranı, Katman 2/3 ortalama kuyruk süresi, Katman 3 yönlendirmesinin tetiklediği uyumluluk olayları, model doğrulama kuyruk süresi. AI173’ün sonunda bir gözleme yer verilmişti: büyük şirketlerin birçoğu üst yönetime AI programlama ROI’sini “kaç geliştirici kapsadıkları” ya da “kaç seat satın aldıkları” üzerinden raporluyor; oysa bu yaklaşım gerçek darboğazların hepsini gizliyor. Bu metrikleri yönetim kurulu raporlamasına taşıdığınızda (seat sayısı ve kod satırı yerine), bütçe “daha fazla lisans al” kalıbından “inceleme kapasitesini güçlendir” kalıba kayar.

Gölge AI yönetimi de eş zamanlı yürütülmeli. UpGuard’ın 2025 raporuna göre küresel ölçekte çalışanların yaklaşık %80’i IT’nin onaylamadığı üretken AI araçlarını kullandığını kabul ediyor — bu durum yalnızca geliştiricilerle sınırlı değil. İş birimlerinin IT’yi devre dışı bırakarak kendi başına ChatGPT’ye kod yazdırması, uyumluluk sorumlularının şu sıra en çok uykusunu kaçıran konu. Yönetişim yükseltmesini gölge AI yönetimiyle birlikte yürütmemek, “beyan edilmiş silahları” denetleyip “beyan edilmemiş silahları” görmezden gelmekle aynı şey.

Geçerli Olmadığı Senaryolar: Ekibiniz 50 kişiden azsa, yoğun düzenlemeye tabi bir sektörde değilseniz, otonom ajanlarla çalışmıyorsanız veya aylık PR hacminiz 100’ün altındaysa, bu yazıdaki değerlendirmelerin en az %60’ı size doğrudan uygulanabilir değil — yapıyı harfi harfine uygulamaya çalışmayın; Layer 1 araç + kritik spot-check olmak üzere iki katmanla ilerlemeniz yeterli.

Sıradaki Adım

Bir sonraki yazı (AI175) araç katmanını ele alıyor: 2026’da AI araçları savaşı çoktan bitti, ama kazananları kullanıp kullanamayacağınız bambaşka bir mesele. İki taht sahibi (Claude Code / Codex), satın alma alışkanlıklarının taşıdığı Copilot ve start bloğundaki Antigravity arasındaki rekabet ile “yönetişim kapasitesinin kimin hangi kademede kullanabileceğini belirlemesi” meselesi. AI174 değerlendirme yükseltmesinin yapısını, AI175 ise araç seçiminin yapısını veriyor; ikisini art arda okuduğunuzda “AI kod yazdıktan sonra organizasyonun bunu nasıl karşılayacağı”nın bütün resmini elde edersiniz.

Bu yazıyı bitirdikten sonra AI173’ün üçüncü bölümünü (yeni darboğazın tespiti) + AI175’in ilgili bölümünü (yönetişim kapasitesi ile araç kapasitesinin eşleşmesi) peş peşe okumanızı öneririm — üç kritik tespit üç yazıya dağılmış durumda.

Bu Değerlendirmeleri Şirketinize Nasıl Uygularsınız?

Yavaş Yavaş Öğren AI 026: AI Programlama Araçlarının Kurumsal Devreye Alımı – Teşhis Girişi, Üç Katmanlı Model ve Pilot Kapsamı

AI programlama araçları kuruma girdikten sonra, gerçekte çözülmesi gereken somut sorunlar genellikle şunlardır: Mevcut code review süreci AI’ın ürettiği hacmi kaldırabilir mi, Layer 2’deki insanlar ne düzeyde yapılandırılmalı (PR hacmi / modül sayısı / FTE oranı üzerinden hesaplanır), Layer 3’teki Change Advisory Board (Değişiklik Danışma Kurulu (CAB)) / kayıt süreci yeniden tasarlanmalı mı, pilot hangi metriklerle doğrulanmalı.

Teşhis Girişi: Önce ekibinizin 5 rakamına bakın – PR ortalama review süresi, değişiklik başarısızlık oranı, review sonrası kaçırılan defect oranı, Layer 2/3 ortalama kuyruk süresi, Layer 3 routing’in tetiklediği uyumluluk olay sayısı. Bu rakamlardan biri çıkmıyorsa, AI pre-review aracını devreye almaya hazır değilsiniz.

Şu anda üç işbirliği modeli sunuyorum:

Kurum İçi Eğitim: Şirketinizin gerçek projeleriyle birleştirilmiş şekilde, AI review üç katmanlı modelinin devreye alınması, Layer 1 araç seçimi (CodeRabbit / GitHub Copilot Review vb.; özel dağıtım + kuralların özelleştirilebilirliği + entegrasyon derinliği + fiyat olmak üzere dört boyutlu değerlendirme), Layer 2/3 süreç yeniden tasarımı ve buna eşlik eden metrik sistemi. Teslimatlar = ① Ekip mevcut durum puanı (review bant genişliği doygunluğu) ② Üç katmanlı model devreye alma yol haritası (3-6 ay) ③ Layer 1 araç seçim karar ağacı ④ Metrik panosu taslağı. 3 gün ≈ ¥90K.

undefined

Third-Party Review (per engagement): Serving as the Party A external consultant, I will conduct an independent assessment of Party B’s “AI Review Implementation Report,” delivering an evaluation memo and a remediation checklist covering: three-layer model coverage, completeness of the metrics system, alignment with the Change Advisory Board (CAB) workflow, and a regulatory compliance risk scan benchmarked against Law No. 5809 + USOM notification regime, the Data Security Law, GDPR, NIS2, SOC 2, and HIPAA. ¥40,000 per engagement.

These three aren’t siloed—internal training establishes the baseline, hands-on coaching stabilizes the ramp curve, and third-party reviews provide the safety net for the board and regulators.

注

Undefined.

The footnote marks the equivalence mappings between the “ISO 27001 + BTK Critical Infrastructure” framework and corresponding constructs across other jurisdictions: the EU’s NIS2/DORA regimes, the United States’ FedRAMP program, and Japan’s ISMS scheme. Material divergences exist among these three in terms of assessment granularity, re-evaluation cadence, and audit trail requirements, and the table above does not enumerate those distinctions — they will be treated in a separate write-up.

Danışmanlık: Belirli bir karara odaklanır — örneğin CodeRabbit raporunun devreye alınıp alınmayacağının değerlendirilmesi, üç katmanlı inceleme modelinin yüksek denetimli ortamlarda (finansta Model Doğrulama Birimi (MDB) bağımsızlığı + denetim izi / telekomda algoritma kaydı + BTK 利用者申立 şikâyet süreci) nasıl uygulanacağı veya mevcut Change Advisory Board (Değişiklik Danışma Kurulu (CAB)) ritminin AI PR’ları için nasıl yeniden yönlendirileceği. Karar temasına göre fiyatlandırılır (5-15 saatlik danışmanlık paketi), teslim edilenler = karar tutanağı + uygulama kontrol listesi + 1 haftalık takip. Saat başına ¥5K.

Birebir Koçluk / Özel İstişare Grubu: “Gelişimine ciddi yatırım yapmaya hazır” başkan yardımcısı / direktör / kıdemli mühendis düzeyindeki kişiler için — AI kodlama araçlarını zaten kullanıyorsunuz; inceleme kalitesini yükseltme, ekip yönetişimi ve departmanlar arası müzakere yargısını kendi organizasyonunuzda içselleştirmek istiyorsunuz. 6 ayda 12 oturum, temaya göre fiyatlandırma, teslim edilenler = koçluk görüşme notları + aşamalı aksiyon retrospektifleri. ¥180K-360K.

Yönetici Brifingleri ve Sektör Konuşmaları: AI ile kod inceleme, organizasyonel yönetişim, kurumsal AI dönüşümü ve yazılım mühendisliğindeki değişim eksenlerinde. Yarım gün / tam gün, organizatörün ihtiyacına göre.

Bu makaleler genel çerçeveler sunar. Somut uygulamalar, her şirketin veri sınırları, düzenleyici gereksinimleri, mühendislik olgunluğu ve mevcut inceleme süreçleri gözetilerek yeniden tasarlanmalıdır. İşbirliği için coach@iaiuse.com adresinden iletişime geçilebilir.

Ek okuma: «Marka Metodolojisi v1.0» (Learn AI Slowly 187), kurumsal AI dönüşümü için 7 adımlık çerçeveyi sistematik biçimde tanıtıyor.

Bu Seri Hakkında

“AI Çağında Yazılım Mühendisliğinin Dönüşümü”, telekom, finans, üretim ve e-ticaret gibi sektörlerdeki CIO, CDO, CTO ve dijital dönüşüm liderlerine yönelik araştırma serisidir. Seri, AI kodlama araçlarının yazılım teslim süreçlerini, organizasyon yapılarını, yönetişim mekanizmalarını ve yönetim ölçütlerini nasıl etkilediğini ele alıyor.

Bu yayının arkasında aslında küçük bir ekip var — ben ve uzun süredir birlikte çalıştığım 1-2 meslektaşım; AI kodlama araçları araştırması, organizasyon yönetişimi vaka çalışmaları ve koçluk görüşmeleri üzerinde ayrı ayrı çalışıyoruz. Metinlerde “kurumlarla birlikte yürüdüğümüz” çoğu proje, hep birlikte teslim ettiğimiz işler.

Seri, akademik makaleleri, üretici dokümanlarını ve sektör raporlarını sürekli takip ediyor; araştırma kaynak havuzu 200’ün üzerinde birikmiş durumda ve kilit yargılar için kanıt düzeyi belirtiliyor — doğrulanmış gerçekler, üretici iddiaları, sektör gözlemleri ve yazar çıkarımları olabildiğince ayırt ediliyor.

Neredeyse 8 yıllık büyük ölçekli kurumsal danışmanlık ve iş analizi deneyimim var; IBM’de çalıştım, telekom, finans, sigorta ve üretim sektörlerinde projelere katıldım. Sonrasında operatör ürünleri, internet ürünleri ve AI uygulama geliştirme sahalarında, iş analizi, ürün tasarımı ve ekipler arası uygulama konularında çalışmaya devam ettim.

Bu serideki inceleme yükseltmeleri, organizasyonel yönetişim ve süreç yeniden tasarımı konusundaki değerlendirmeler, bu uygulamalardan ve kamuya açık araştırma ile sektör vakalarının çapraz doğrulanmasından gelmektedir. Somut projelere değinen bölümlerdeki içerik anonimleştirilmiştir; bazı sektör senaryoları, tipik sorunların çıkarımına dayanmaktadır; ilgili kaynaklar yazının sonundaki referanslarda belirtilmiştir.

参考来源（逐条出处 + 证据层级 + 立场标注）

CodeRabbit State of AI vs Human Code Generation Raporu (2025.12.17, birincil kaynak, tedarikçi bakış açısı): Dosya boyutu/karmaşıklığına göre eşleştirilmemiş 470 açık kaynak GitHub PR’ını (yapay zekâ ile yazılanlar, insan eli değenler) analiz ediyor. Toplam hata sayısı 1,7× (her PR için ortalama 10,83’e karşı 6,45); güvenlik açıkları alt kategorilerde 1,57–2,74× — XSS 2,74×, hatalı parola yönetimi 1,88×, güvensiz doğrudan nesne referansı 1,91×, güvensiz serileştirme kaldırma (deserialization) 1,82×; mantık/doğruluk 1,75× (%75 yüksek risk), kod kalitesi 1,64×, performans 1,42×, okunabilirlik 3×+, biçimlendirme 2,66×, hata yönetimi ~2×, aşırı G/Ç (I/O) ~8×. CodeRabbit’ın kendi araştırması; tedarikçi bakış açısı taşıyor, örneklem ve metodoloji ise kamuya açık. https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report / The Register, 17.12.2025 tarihli haber.
Apiiro 2025.9.4 (satıcı bakış açısı): Fortune 50 şirketlerinin kod depolarında yapılan taramalar (veri dönemi Aralık 2024 – Haziran 2025). Yapay zekâ ile üretilen kodda aylık güvenlik bulgusu sayısı yaklaşık 1.000’den 10.000’in üzerine fırladı (mutlak sayıda 10×); yetki yükseltme açıkları +%322 (mutlak sayı), mimari katman tasarım kusurları +%153; kod hacmindeki artışa göre normalleştirildiğinde yaklaşık %60–80’lik bir yükseliş tahmin ediliyor. Sözdizimi hataları %76, mantık hataları %60 azaldı. The Register, Cloud Security Alliance Labs ve SiliconANGLE tarafından haberleştirildi.
JetBrains AI Pulse Survey 2026.1 (birincil kaynak): 10.000’den fazla profesyonel geliştirici, 8 dilde. Geliştiricilerin %90’ı en az bir yapay zekâ aracı kullanıyor; %70’i 2–4 araç kullanıyor. https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/
Pragmatic Engineer Bülteni (Şubat 2026, birincil kaynak): Yaklaşık 906 katılımcı, 150.000 okuyucı tabanı; kıdemli mühendislerin %56’sı mühendislik işlerinin %70’inden fazlasını yapay zeka araçlarına dayandırdığını belirtiyor (kendi beyanlarına dayalı ağır kullanım oranı, kod satırı yüzdesi değil); Claude Code %46 ile en çok tercih edilen araç (Cursor %19, Copilot %9’a karşı); 10.000 çalışanın altındaki şirketlerin %75’i Claude Code’u, 10.000 çalışanın üstündekilerin %56’sı ise Copilot’u seçiyor. https://newsletter.pragmaticengineer.com/p/ai-tooling-2026
GitHub Octoverse 2024 / 2025 (birincil kaynak): Octoverse 2025 raporu, Copilot coding agent’ın Mayıs–Eylül 2025 arasındaki beş aylık dönemde 1 milyondan fazla PR’ın yazarı (author) olduğunu ortaya koyuyor; yeni geliştiricilerin %80’i ilk hafta içinde Copilot kullanıyor. “%40–60 PR katılım oranı” sektör tahminidir, doğrudan Octoverse verisinden değildir. GitHub Engineering Blog ve The New Stack tarafından derlenmiştir.
Stripe Minions (Mart 2026, birincil kaynak): Stripe’ın “Minions” agent’ı haftada yaklaşık 1.300 PR birleştiriyor; sıfır insan yazılımlı kod (yalnızca insan review’sı) — AI’ın tamamen otonom üretimi + insanın yalnızca review yapması bu modelin ayırt edici özelliği. 500+ MCP tools, AWS EC2 devbox, Block Goose dallanma stratejisi. https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents / InfoQ Mart 2026 raporu.
Anthropic Skills Sistemi (2026.1, birincil kaynak, satıcı perspektifi): Anthropic, Skills tasarım dokümanını kamuya açık hale getirdi—çekirdek fikir görev yeteneklerinin modülerleştirilmesi (modular folders that teach Claude specific tasks; skill dosyaları ve progressive context loading yaklaşımıyla tasarlanmıştır) ve PR yönlendirmesiyle doğrudan bir ilgisi yoktur. Sektörde PR risk yönlendirmesi daha çok GitHub/GitLab tarafındaki branch protection ve CODEOWNERS kuralları üzerinden yapılır—yani PR’lar dosya yoluna veya atanmış kod sahiplerine (Codeowner) göre yönlendirilir. Kaynak: Anthropic Engineering Blog.
Carlini / Anthropic (Ocak–Şubat 2026, birinci düzey, birincil araştırma): Anthropic araştırmacısı Nicholas Carlini, 16 Claude Opus 4.6 ajanını iki hafta boyunca paralel çalıştırarak (~2000 oturum, yaklaşık 20.000 dolarlık API maliyetiyle) sıfırdan 100.000 satırlık Rust tabanlı bir C derleyicisi yazdırdı; derleyici Linux 6.9’u (x86/ARM/RISC-V) GCC torture testinin yüzde 99’unu geçerek derleyebildi. Bu çalışma kapalı alanda yürütülen bir araştırma olup üretime taşınmamıştır ve herhangi bir kod review (inceleme) mekanizması içermemektedir. The Register (9 Şubat 2026) ve Ars Technica (Şubat 2026) kaynaklarında yer almıştır.
METR 2026.2 Güncelleme Çalışması (Birincil kaynak, doğrulanması gerekiyor): Erken aşamadaki araştırma, 16 kıdemli geliştirici, 246 gerçek dünya görevi, Cursor Pro + Claude 3.5/3.7 Sonnet kullanılmış; AI %19 yavaşlamaya yol açmış (%95 güven aralığı %2-%39), geliştiriciler ise kendi performanslarını %20 daha hızlı algılamış. 2026.2 takip çalışmasında tablo tersine dönmüş (yeni katılan geliştiricilerde -%, kıdemli geliştiricilerin bir kısmında kısmi tersine dönüş); metriklerin METR orijinal raporuyla çapraz kontrol edilmesi gerekiyor. https://metr.org/blog/2026-02-24-uplift-update
Microsoft FY26 Frontier Suite / EY Vakası (birincil, satıcı perspektifi): EY, Microsoft 365 Copilot’u 150.000 çalışanına konuşlandırdı; %15 üretkenlik artışı elde etti (kişi başı haftalık 14 saate denk geliyor, bu süre müşteri teslimatına ve öğrenmeye yönlendirildi); sonrasında 400.000’den fazla çalışana yayıldı. Microsoft Power Platform + Copilot Studio üzerinde hayata geçirilen finansal operasyon senaryosunda uçtan uca lead time %95 hızlandı, operasyonel maliyetler %37 düştü (yalnızca finansal operasyon senaryosuna ait, şirket geneline genellenemez). Kaynak: Microsoft Customer Story 25760 / FY26 yatırımcı sayfası.
Atos Agent 365 Dağıtımı (Haziran 2026, birincil kaynak, satıcı bakış açısı): Atos, Microsoft 365 Copilot’ı 54 ülkedeki 56.000 çalışanına konuşlandırdı ve 19.000 dahili AI ajanını yönetmek için Agent 365’i kullanıyor. Atos’un kendi ifadesiyle, “yönetişim ve güvenlik, agentic AI’nin ilk geçiş kapısıdır.” Microsoft News, 9 Haziran 2026 / CDO Magazine.
Anthropic Claude Code / OpenAI Codex Otonom Ajan Yetenekleri (birincil kaynak, satıcı bakış açısı): Claude Code onlarca dosyayı kendi başına düzenleyebilir, shell komutları çalıştırabilir, Git’i yönetebilir ve PR gönderebilir; Codex ise birkaç alt ajanı izole kopyalarda paralel olarak çalıştırıp sonuçları birleştirebilir. Anthropic / OpenAI mühendislik dokümanları.
CodeRabbit Şirket Temel Göstergeleri (2025–2026, birinci elden): GitHub Marketplace yapay zekâ destekli kod inceleme araçları pazarında açık ara birinci sırada; Eylül 2025’teki Series B turunun değerlemesi yaklaşık 550 milyon dolar; ARR 2025–2026 döneminde neredeyse 10 kat büyüyerek yaklaşık 40 milyon dolara ulaştı (2026 Q2, Sacra verileri); Pro 24 dolar/koltuk/ay, Pro Plus ise 48 dolar/koltuk/ay (PR oluşturan geliştirici başına faturalandırılır). Sacra / Reuters / TechCrunch gibi birden fazla kaynak üzerinden doğrulanmıştır. https://sacra.com/c/coderabbit
GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review (birincil kaynak, satıcı bakış açısı): Her bir Layer 1 inceleme aracının resmi dokümantasyonu ve ürün sayfaları; ele alınan kapsam boyutları, kuralların özelleştirilebilirliği ve entegrasyon derinliği açısından karşılaştırılabilir. Antigravity, 18 Kasım 2025’te GA sürümüne çıkmış olup VentureBeat / PCMag tarafından haberleştirilmiştir.

Türkçe Çeviri

Code review’ın kökenleri (1. seviye): İki ana akış öne çıkar: ① Gerald Weinberg, 1971 tarihli The Psychology of Computer Programming kitabında “egoless programming” (egodan arınmış programlama) kavramını ortaya koymuştur; Weinberg o dönemde NASA Goddard Space Flight Center’da çalışıyor ve aynı zamanda University of Nebraska’da öğretim görevlisiydi; IBM bağlantısı yoktur. ② IBM Fagan Inspections, Michael Fagan tarafından 1976’da IBM bünyesinde sistematize edilmiştir. Fagan’ın kendisi IBM çalışanıydı. Bu iki gelenek paralel biçimde evrilmiştir. AI çağındaki inceleme süreçlerini geleneksel review ile kıyaslarken başvurulan tarihsel referans budur.
Finansal düzenleme referansı (birincil kaynak): Çin’de Ticari Bankaların İnternet Üzerinden Kredi Verme Yönetim Yönetmeliği Madde 24 ve CBIRC（中国BDDK, Çin Bankacılık ve Sigorta Düzenleme Komisyonu） tarafından yayımlanan 2020 tarihli 24 numaralı belge (Ticari Bankaların İnternet Üzerinden Kredi İşlemleri Risk Yönetimi商业银行互联网贷款业务风险管理) — model yönetişiminde üç savunma hattı (iş birimi, BT, uyum ve iç denetim) + Model Doğrulama Birimi (MDB) (Model Validation Unit, Bağımsız Model Doğrulama Birimi) + önemli model değişikliklerinde yeniden kayıt zorunluluğu; BDDK 規制データ報告 (bankacılık denetim analiz sistemi) aylık raporlama + BDDK/TCMB 規制データ報告 raporlaması; Çin Halk Bankası bireysel kredi sicili ve algoritma adalet denetimi (cinsiyet, yaş, coğrafi değişken kısıtlamaları). AB düzenleyicileri için eşdeğer çerçeveler: GDPR (kişisel veri işleme) + NIS2 Direktifi (ağ ve bilgi sistemi güvenliği) + DORA (Dijital Operasyonel Dayanıklılık); ABD’de SR 11-7 rehberi ve SS1/17 model risk yönetimi prensipleri.
Telekomünikasyon düzenleme referansı (birincil kaynak): MIIT (Çin Sanayi ve Bilişim Teknolojileri Bakanlığı) algoritma kayıt yönetmeliği (faturalama/finansal iş algoritmaları için çift düzenleme); MLPS (Multi-Level Protection Scheme — Çin’in siber güvenlik kademeli koruma sistemi, 2. seviye 30 iş günü / 3. seviye 45 iş günü); BTK 利用者申立 şikayet hattının ilk 3 konusu (numara taşıma, fatura erişilebilirliği, hat açma/kapama yönetimi); Sanayi ve Bilişim Teknolojileri Alanında Veri Güvenliği Yönetim Yönetmeliği (Deneme Uygulama) veri çıkışı negatif listesi.
KVKK 6698 veri işleme yetkilendirme (birincil kaynak): Kişisel Bilgi Koruma Yasası (KVKK 6698) Madde 21 + Madde 55 — üçüncü taraf işleme sözleşmesi + 3–5 yıllık denetim kaydı saklama süresi (sektöre göre değişir).
Stack Overflow 2025 Geliştirici Araştırması (birincil kaynak): 49.000+ geliştiriciyle yapılan anket. AI doğruluğuna güvenen geliştirici oranı 2024’teki %40’tan 2025’te %29’a düştü (11 yüzde puanı azalma); aynı zamanda geliştiricilerin %46’sı AI çıktılarına karşı aktif olarak güvensizlik bildiriyor (2024’teki %31’in üzerinde). Code churn (AI ile üretilen kodun kısa süre içinde elden geçirilme veya silinme oranı) 2020’deki %3,1’den 2024’te %5,7’ye yükseldi. https://survey.stackoverflow.co/2025/
Gölge AI (UpGuard 2025, İkincil kaynak): Küresel çalışanların %80’i onaylanmamış üretken AI araçları kullanıyor (yalnızca geliştiriciler değil); güvenlik sorumlularının %68’i yetkilendirilmemiş AI kullanımını kabul ediyor. Yönetişim yükseltmelerinin gölge AI yönetişimiyle birlikte yürümemesi bir uyum kör noktasıdır. https://www.upguard.com/resources/the-state-of-shadow-ai
Yazarın kendi vakaları (anonimleştirilmiş): ① Bölgesel bir operatörün (regional carrier) AI iç eğitimi (2024 Q4, 11 kontrol noktasının değerlendirmesi, anonimleştirilmiş) ② Bir joint-stock bankanın kredi risk değerlendirme sürecinin yükseltilmesine ilişkin görüşmeler (2025 H1, anonimleştirilmiş) ③ Büyük bir imalat işletmesinin MES proses değişikliği değerlendirme akışının yeniden tasarımı (2025 H2, anonimleştirilmiş) ④ Önde gelen bir e-ticaret platformunun büyük kampanya dönemindeki lock operasyonu (2025 Double 11, anonimleştirilmiş).
Vaka anonimleştirme notu: Bu yazıda bahsedilen operatör, finans, imalat ve e-ticaret vakaları, yazarın operatör odaklı AI iç eğitimleri ve dijitalleşme ekiplerini izleme deneyimlerine dayanmakta olup anonimleştirilmiştir; sektöre özgü uygulama paragrafları, belirli bir müşteri danışmanlığının sonucu değil, tipik senaryoların çıkarımı niteliğindedir. Herhangi bir alıntı için anonimleştirme bilgisinin belirtilmesi rica olunur.