[Kod İncelemesi] AI Çağında Kod İnceleme — AI Kodu Yazdıktan Sonra Kim İnceler? AI Çağında Yazılım Mühendisliğinde Dönüşüm — Yavaşça AI Öğren 174
YZ Çağında Kod İncelemesi — YZ Kodu Yazdıktan Sonra, Kim İnceleyecek?
Bir önceki yazıda (AI173) “doğrulama”yı kodun neredeyse bedava hale gelmesinden sonraki üçüncü yeni darboğaz olarak listelemiş, sonuna “dördüncü bölüm ayrıca ele alınacak” diye not düşmüştüm. İşte bu yazı o sözü tutuyor. Önce sonucu vereyim: 2026 ortasına geriye dönüp bakıldığında, YZ kodlama araçlarının ortaya çıkardığı en büyük değişken ne lisans sayısı, ne koltuk sayısı, ne de model benchmark skorları — inceleme kapasitesidir.
CodeRabbit’in 2025 sonu raporu, 470 açık kaynak GitHub PR’ını analiz ederek çarpıcı bir sonuca ulaştı: YZ destekli kod üretiminde ortaya çıkan hatalar, tamamen insan eliyle yazılan kodunkinden 1,7 kat daha fazla (dosya boyutu/karmaşıklığına göre eşleştirme yapılmamış, PR başına ortalama 10,83’e karşı 6,45). Güvenlik açıklarına alt kategorilere inildiğinde tablo daha da ağırlaşıyor: XSS 2,74×, hatalı parola yönetimi 1,88×, güvensiz doğrudan nesne referansları (IDOR) 1,91×, güvensiz serileştirme/serileştirme kaldırma 1,82×. Mantık/doğruluk hataları 1,75×, okunabilirlik 3× üzeri, biçimlendirme 2,66×, hata yönetimi ise neredeyse 2× artış gösteriyor.
Apiiro ise Eylül 2025’te Fortune 50 şirketlerinin kod depolarını tarayarak (veriler Aralık 2024 – Haziran 2025 dönemini kapsıyor) meselenin bir başka yüzünü ortaya koydu: YZ tarafından üretilen kod sayesinde aylık güvenlik bulgusu sayısı yaklaşık 1.000’den 10.000’in üzerine fırladı (10× artış). Yetki yükseltme (privilege escalation) açıkları %322 artarken, mimari katmandaki tasarım kusurları %153 yükseldi. (Yetki yükseltmesindeki %322 mutlak bir sayıma dayanıyor; kod hacmindeki büyümeye göre normalize edildiğinde gerçek artışın kabaca %60–80 aralığında olduğu tahmin ediliyor.) Aynı dönemde sözdizimi hataları %76, mantıksal bug’lar ise %60 azaldı.
Şu iki veri kümesi birlikte özellikle düzenleyici bağlamda kritik olan bir noktaya işaret ediyor: Apiiro’nun %322 yetki yükseltme (privilege escalation) açığı verisinin önemli bir kısmı yetki sınırlarında yoğunlaşıyor — yetki sınırları ise finans ve telekom sektörlerinde doğrudan müşteri fonları ve müşteri verileri anlamına geliyor. Yapay zekayla üretilen kodun büyük kısmı çalışıyor, ancak hata ve güvenlik açıkları orantılı şekilde artıyor; üstelik tehlikeli olanlar sessizce büyüyor. (Metodoloji notu: CodeRabbit raporu satıcı kaynaklı, Apiiro verileri ise üçüncü taraf bir güvenlik satıcısından geliyor; sonuçların yönü örtüşüyor ancak normalizasyon yöntemi gözetilerek okunmalı.)
Bu olgu işletmelere indirgendiğinde, satın aldığınız araçların pazarlama anlatısının tam tersine çalışan iki karşı-sezgisel sonuç tetikleniyor.
Bir: İki Karşı-Sezgisel Sonuç
Karşı-sezgisel 1: Geliştiricinin rolü “kod yazan kişi”den “kod inceleyen kişi”ye evrildi — ve incelemek, yazmaktan daha yorucu.
Sonuç: Yapay zeka “yazma” işlemini genişlettikçe, geliştirici zamanının daha büyük kısmını “okuma + değerlendirme”ye harcıyor — tanımadığı kodu okumak + uyumluluk sınırlarını yargılamak + iş kurallarını doğrulamak. Bilişsel yük, kendi kodunu yazmaktan belirgin biçimde daha ağır. Kıdemli mühendislerin %56’sı işlerinin %70’inden fazlasını yapay zekaya dayandırıyor (Pragmatic 2026.2); yeni çalışma biçimi artık varsayılan.
JetBrains’in Ocak 2026 araştırması (10.000’den fazla geliştirici, 8 dil) geliştiricilerin %90’ının en az bir AI aracı kullandığını söylüyor; aynı sektördeki bir diğer çalışma olan Pragmatic Engineer’ın Şubat 2026 araştırmasında ise çok daha uyarıcı bir satır var: kıdemli mühendislerin %56’sı mühendislik işlerinin %70’inden fazlasına AI araçlarına bağımlı olduklarını belirtiyor (ağır kullanıcıların öz değerlendirmesi; kod satırı oranı değil). Bu, ara sıra AI’la birkaç satır yazmak değil; AI’ın artık varsayılan çalışma biçimi hâline gelmesi demek. Üretim ilişkileri bir kez daha yerinden edilmiş durumda: kod yazma işi AI’a devredilirken, geliştirici daha çok zamanını okumaya ve değerlendirmeye, yani code review’a ayırıyor. Başkasının kodunu okumak zaten yazmaktan daha zor ve yavaştır; AI’ın ürettiği yabancı kodu okumak, bir de bunu uyumluluk sınırları ve iş kuralları çerçevesinde değerlendirmek, kendi kodunu yazmaktan belirgin biçimde daha ağır bir bilişsel yük getiriyor. 2025-2026 döneminde geliştiricilerin “AI beni daha çok yoruyor” şeklindeki süregelen şikâyetinin asıl kökü de bu — arka planda, METR’ın Şubat 2026 tarihli çalışmasındaki tersine dönen anlatı yatıyor (kıdemli geliştiricilerin başlangıçta AI yüzünden %19 yavaşladığı sonucu, yeni örneklemde kısmen tersine dönmüştür; yeni katılan geliştiriciler için hâlâ -%4; bütüncül değerlendirme: “inceleme kapasitesi, üretim kapasitesinden daha dar”).
Sezgisel beklentinin tersi 2: AI araçları güçlendikçe, kurumların ihtiyacı daha fazla araç değil, yönetişimdir.
CodeRabbit’ın 1,7x hata oranı, Apiiro’nun %322 yetki yükseltme açığı — tek başına bakıldığında yapay zekânın başarısızlığı gibi görünüyor. Ama kısıtlar teorisi (Theory of Constraints, TOC) merceğinden bakınca tablo değişiyor: araçların üretim kapasitesi arttı, sizin denetim kapasiteniz ise aynı hızda büyümedi. Bir sistemin çıktısını en dar boğaz belirler. Yapay zekâ “yazma”yı genişletti; en dar halka artık “denetleme” oldu. Denetim bant genişliği yükselmediği sürece, yapay zekâ ne kadar hızlı yazarsa yazsın, kurumun biriktirdiği teknik borç o kadar tehlikeli olur. AI173’ün vardığı yargı bu: otomasyon darboğazı ortadan kaldırmaz, sadece yerini değiştirir.
Bu cümleyi yapay zekâ destekli yazılım geliştirmeye (AI-assisted coding) uygularken bir ekleme yapmak gerekiyor: yazılım geliştirme tek bir üretim hattı darboğazı değildir; birden fazla paralel darboğazın dinamik olarak yer değiştirdiği bir sistemdir. TOC, üretim hattı senaryosunda geçerlidir; yapay zekâ ile yazılım geliştirme gibi paralel ve çoklu darboğazlı senaryolarda en dar halka “yazma”dan “denetleme”ye kayar, ama “denetleme”nin kendisi de üç ayrı halkaya ayrılır — doğrulama (verification), yönetişim (governance) ve uyumluluk denetimi (compliance review) — ve her biri bağımsız bir darboğaz oluşturur.
Bu ilkenin pratik anlamı iki katmanlıdır. İlk katman, otonom agent’lara geçmeden önce dört freni birden takmaktır: zorunlu insan code review’ı, otomatik test (AI kod değiştirdikten sonra mutlaka çalışmalı), güvenlik taraması (insan yazılmış kodla aynı standartta) ve kanarya yayılım (AI’ın değişiklikleri küçük bir oranla önce yayına alınır). AI’ın PR’ı review’dan muaf olamaz. Bu, “AI kod yazıyor”u “AI kod yazıyor + organizasyon sonuçları kucaklıyor” mühendislik problemine genişletmenin en düşük eşiğidir; biri eksikse kontrol kaybedilen yüzeyler ortaya çıkar. Carlini, Ocak–Şubat 2026’da sıkça atıf yapılan bir örnek kayıt altına aldı: bir Anthropic araştırmacısı, 16 Claude Opus 4.6 agent’ını 2 hafta boyunca paralel çalıştırdı; yaklaşık 2000 session ve yaklaşık 20.000 dolarlık API maliyetiyle, sıfırdan 100.000 satırlık Rust tabanlı bir C derleyicisi yazdı. Bu derleyici Linux 6.9 çekirdeğini derleyebiliyor ve GCC torture test’ini %99 oranında geçiyor. Vurgulamak gerekir: Bu, kapalı bir alanda yapılmış kontrollü bir deneydir; Carlini kodu üretime çıkarmadı. “Review’sız uç nokta karşılaştırması” olarak anlamlı, ama “hemen otonom agent’lara geçelim” şeklinde bir şablon olarak kullanılırsa yeniden uygulanabilirliği olduğundan yüksek gösterilir. Code review’ı, otomatik testi, güvenlik taraması ve kanarya yayılımı olmayan bir organizasyona koyarsanız, er ya da geç işler sarpa sarar.
İkinci katman daha örtük: incelemenin asıl meselesi bug bulmak değil, mimari uyumu, uyumluluk sınırlarını ve iş doğruluğunu değerlendirmektir. Eski nesil mühendislerin en sık düştüğü tuzak, yapay zekâ çağının incelemesini geleneksel code review ile aynı kefeye koymaktır. Geleneksel review “bu kod parçası hatalı mı” diye bakar; yapay zekâ çağında review “bu kod bu dosyada, bu projede, bu uyumluluk sınırında var olmalı mı” diye bakar. CodeRabbit’in güvenlik açığı için verdiği 1,82–2,74× oranı, Apiiro’nun %322 yetki yükseltme açığı oranı tam da bu kategoriden: yapay zekâ kodu yanlış yazmadı ama yanlış yere, yanlış yetkiyle, yanlış varsayılan yapılandırmayla yazdı. Bu tür sorunlar IDE içinde çözülmez; review masasında okunup anlaşılmalıdır. Mühendislik dünyasında daha yaygın yaklaşım, GitHub/GitLab’in branch protection ve CODEOWNERS kurallarını “schema / auth / billing / uyumluluk sınırı değişikliği” ekseninde kırmızıya boyayıp çift sign-off rotasına bağlamaktır (finans ve telekom operasyonlarında genellikle tam review değil backup veto uygulanır; spot-check oranı risk seviyesine göre oynar). Mimari karar kayıtları (ADR), güvenlik ve uyumluluk taban çizgisi, iş kurallarının doğruluğu — yapay zekâ çağında incelemeye gerçekten zaman ayrılması gereken yer tam da burasıdır.
İşte bu iki karşı-sezgisel gerçeği üst üste koyduğunuzda tablo netleşiyor: Yapay zekâ çağında kod inceleme (code review) için şirketlerin üç şeyi yeniden düzenlemesi gerekir — mühendislik yöneticisini inceleme sürecine dahil etmek, uyum (compliance) ve mimari temel çizgilerini PR yönlendirmesine (routing) yazmak, başarısızlık oranı gibi yönetişim metriklerini yönetim kurulu raporlamasına taşımak. Bu üç madde, doğrudan Çin’de “Ticari Bankaların İnternet Üzerinden Kredi Verme Yönetmeliği”nde (“商业银行互联网贷款管理办法”) istenen “Üç Savunma Hattı Model Yönetişimi” ile (iş birimi, BT, uyum denetimi) örtüşüyor; düzenleyici bakan gözünde hemen anlaşılır. Aşağıda dört katman halinde açıyorum.
II. Neden “Şimdi”: Doğrulamanın Yeni Darboğaz Olma Mekanizması
Sonuç: 2026 H2 öncesinde inceleme yükseltmesini yerine getirmemiş kurumlar, Q4 büyük kampanya penceresinde / yıl sonu dondurma döneminde / düzenleyicinin rutin denetimlerinde toplu şekilde patlayacak — üç katmanlı model lüks değil, asgari eşiktir.
AI173’ün üçüncü bölümündeki “dördüncü bölümde ayrıntılı anlatılacak” vaadini yerine getirelim. 2026 ortası penceresinin özgüllüğü şu: otonom ajanlar (Claude Code, Codex) “deneme” aşamasından “varsayılan kullanım”a geçiyor; H2 öncesinde inceleme yükseltmesini yerine getirmemiş kurumlar, Q4 büyük kampanya penceresinde / yıl sonu dondurma döneminde / düzenleyicinin rutin denetimlerinde toplu şekilde patlayacak. Önce yeni darboğazda “doğrulama”nın neden en derin biçimde hafife alındığını anlatayım, sonra onu diğer iki yeni darboğazla (doğru soruyu tanımlamak, sistem entegrasyonu) tek bir şemada yan yana koyayım.
Asıl kök sorun, çoğu AI kodlama tartışmasının “doğrulama”yı otomatik olarak CI/CD, birim testi çalıştırmak ve lint geçirmek olarak varsayması. Bu, internet ürünlerinin dünyası: kod buluta dağıtılır, birim testleri tamamen yeşildir, CI geçer, merge edilir ve üretime alınır. Bu akış, internet ürünlerinin temposunda işe yarar; telekomünikasyon, finans, imalat ve e-ticarete doğrudan taşınamaz: bu sektörlerde “doğrulama” algoritma kaydı, güvenlik değerlendirmesi (等保测评 – Çin’in “Multi-Level Protection Scheme” siber güvenlik denetimi), veri çıkışı değerlendirmesi, CAB değişiklik onayı, mutabakat denetimi ve düzenleyici raporlamadır; kodla hiçbir ilgisi yoktur, ama her biri birkaç hafta yer. AI173 zaten bir şema sunmuştu (kodlama hızlanıyor, darboğaz doğrulamada); burada tekrarlamayacağız. Asıl mesele, arkasında bıraktığı soru: AI’nın ürettiği kod, üretime girmeden önce kaç doğrulamadan geçmelidir?
Yedi ile başlanır: otomatik test + code review + güvenlik taraması + mimari/ADR değerlendirmesi + iş kuralı değerlendirmesi + uyum (compliance) onayı + kademeli dağıtım. Her biri ayrı bir bant genişliği tüketir. Bu yedi katman bir araya geldiğinde, AI173’teki şemanın “öbür yüzü”nü oluşturur — AI, marjinal maliyeti en düşük dilimi hızlandırır (GPU süresi, lisans ücretleri), doğrulama ise kurumsal maliyeti en yüksek dilimi (düzenleme, kayıt, mutabakat) yer.
İkinci ve hafife alınan kök sebep: “inceleme”nin yalnızca “code review”ye indirgenmesidir. Code review’nin iki ana kaynağı — Weinberg’in 1971’deki The Psychology of Computer Programming adlı eserinde ortaya attığı egoless programming (NASA/akademik kökenli) ve IBM’den Fagan’ın 1976’daki Fagan Inspections’ı (IBM’in sistematik çıktısı) — aynı varsayıma dayanır: kod satır satır yazılır, onu yazan kişi en iyi anlar, yazıldıktan sonra bir başkası okuyup hataları yakalar. AI bu varsayımı yerle bir etti: kod AI tarafından birkaç saniyede üretilir, üreten taraf (AI) bağlamı iletmez, okuyan taraf (geliştirici) ise kendisine yabancı bir ürünle karşılaşır. Eski “hata yakalama” varsayımı geçersiz kaldı. Yeni inceleme varsayımı şu sorulara odaklanıyor — Bu kod bu dosyada gerçekten var olmalı mı? Mevcut mimari kararları atlatır mı? Üzerine düştüğü uyumluluk sınırının içinde mi dışında mı? Varsayılan yapılandırması üretim ortamında bir güvenlik açığına dönüşür mü?
Bu üç sorunun her biri, iş mantığını + mimariyi + uyumluluğu bilen birinin yanıtlamasını gerektirir; araçlar yalnızca destek rolü üstlenir. Bu, “incelemeyi” CI/CD’deki bir lint kontrol noktasından mühendislik yönetişiminin ayrı bir katmanına taşımak demektir.
Üçüncü Bölüm: Üç Katmanlı İnceleme Modeli — AI Ön İncelemesi, İnsan Denetimi, Yönetişim Kuralları
Sonuç: İnceleme yükseltmesi bir araç meselesi değil, bir yönlendirme (routing) meselesidir — PR’ları risk seviyesine göre Katman 1 (otomatik) / Katman 2 (insan spot-check) / Katman 3 (yönetişim onayı) katmanlarına yönlendirin. Üç katman üst üste biner, her katman kendi işine bakar; araç/süreç/yönetişim ayrı ayrı ilerler.
Yukarıdaki analizi uygulanabilir bir yapıya sıkıştıralım. Üç katmanlı model ikame ilişkisi değil, üst üste binme (stack) ilişkisidir — her PR aynı anda üç katmandan geçer ve her katman farklı bir sorun sınıfına bakar.
Katman 1: Saniye-Dakika Döngüsünde Çalışan Araç Katmanı
Bu katman, AI tarafından üretilen her satır kodun bir araçtan geçmesiyle çalışır. CodeRabbit, GitHub Copilot Review, Sourcery, Cursor BugBot ve Antigravity Review gibi çözümlerin her biri, bir pull request oluşturulduktan sonraki birkaç saniye ile birkaç dakika arasında geri bildirim üretebilir. Bu geri bildirimler lint kontrollerini, güvenlik açıklarını, kod tekrarını, adlandırma sorunlarını ve bağımlılık risklerini kapsar. Katmanın maliyeti son derece düşüktür — PR sayısı artsa da tüm bu araçlar sabit bir abonelik ücretiyle çalışır — ve kapsama oranı yüksektir, çünkü her PR bu süreçten geçer. Bant genişliğinin temelini bu katman oluşturur.
Öte yandan, katmanın kör noktaları da gayet net: mimari uyum, uyumluluk sınırları ve iş mantığı doğruluğu konularında çözüm sunamaz. CodeRabbit kendi raporlarında “açıkça görülen sorunların büyük bölümünü otomatik olarak yakalıyoruz” ifadesini kullanır; ancak varsayılan yapılandırmalar, yetki sınırları ve istisna işleme yolları gibi detaylara gizlenmiş örtük riskler insan gözüne ihtiyaç duyar. Bu katman yalnızca bir temeldir, varış noktası değil.
Sürecin Nerede Kırıldığı
Zincirin bir sonraki halkası olan Layer 2, yani insan review süreci, bütçe açısından asıl darboğazın yaşandığı yerdir.
Katman 2: Saatler-Günler İçinde Çalışır
Yüksek riskli değişiklikler — çekirdek modüllere dokunanlar, veritabanı şemasını değiştirenler, kimlik doğrulama/faturalandırma/uğumluluk modüllerine müdahale edenler — mutlaka insan spot-check’inden geçmeli. Bu incelemeyi mimarlar, iş sahipleri ve güvenlik sorumlularından oluşan küçük bir ekip yapar.
CodeRabbit’ın raporladığı 1,82–2,74× güvenlik açığı artışı ve Apiiro’nun raporladığı %322 yetki yükseltme açığı artışının önemli bir kısmı tam da bu katmanda yakalanmalıdır: AI’ın ürettiği kod görünüşte doğru çalışır, testleri geçer; ama varsayılan yapılandırmalar, yetki sınırları ve hata yönetimi yolları detaylarda gizlidir.
Orta ve düşük riskli değişiklikler örnekleme ile ilerler (iç eğitim müşteri deneyimlerinden edindiğimiz değer, sektör standardı değildir — %20-%30 örnekleme oranı önerilir). Her PR’ı insan gözünden geçirmek şart değil. Amaç, insan bant genişliğini “her şeyi incelemek”ten “kilit olanları seçmek”e taşımaktır.
Bu katmanın en sık düşülen tuzağı gevşemedir: ekip, AI tarafından üretilen PR’ları hızlıca kapatabilmek için “yüksek risk” tanımını sessizce genişletir. Standartları gevşetmek kısa vadede rahatlık sağlar; kaza geldiğinde ise sonuçları ağır olur.
Katman 3: Aylar ve Haftalar — Uyum ve Düzenleyici Sınıra Dokunan Değişiklikler
Katman 3, uyumluluk sınırlarına, düzenleyici raporlamaya, veri sınır ötesi aktarımına, SLA’lara ve ekipler arası mimari değişikliklere temas eden işler için çalışır: Change Advisory Board (CAB) değişiklik danışma kurulu, kayıt incelemeleri, 等保测评 Đěng Bǎo Cè Píng (Çin’deki zorunlu bilgi sistemi güvenlik koruma değerlendirmesi), düzenleyici iletişim. AI173’teki diyagramda “AI’ın ilerleyemediği” turuncu bloktur ve sıkı düzenlenen sektörlerde en pahalı maliyet kalemidir.
AI174’ün değerlendirmesi şudur: AI Katman 3’ün altına giremez, ama Katman 1+2 iyi yapılırsa düşük riskli değişikliklerin büyük çoğunluğu Katman 3’e ulaşmadan filtrelenebilir (iç eğitim müşteri örneklemine göre tahmini %80–90). Geriye kalan %10–20’lik yüksek riskli değişiklikler CAB’den geçer; böylece CAB’nin bant genişliği şirket genelinden yalnızca gerçekten yönetime ihtiyaç duyan değişikliklere yönlendirilmiş olur. CAB kuyruk süreleri kısalır, genel teslim ritmi hızlanır; bu, değerlendirme yükseltmesinin en kolay gözden kaçan “yönetişim bant genişliği kazancı”dır.
Katman 3 Uyum İmzalarının Kağıda Dökülmesi Gerekir
Her Katman 3 yönlendirmesi tetiklediği PR’de eksiksiz bir denetim izi korunmalıdır: PR diff’i + değerlendirme yorumları + iş sahibi + uyumluluk sahibi çift imza + zaman damgası + model doğrulama raporu eki. Saklama süresi finansal hizmetler için 5 yıl, telekom için 3 yıldır (referans: PIPL §55 + Çin Bankacılık ve Sigorta Düzenleme Komisyonu 2020/9 sayılı Yönetmelik + Çin Sanayi ve Bilgi Teknolojileri Bakanlığı algoritma kayıt yönetmeliği). Bu kayıt, düzenleyici iletişimde somut delil işlevi görür — kâğıt üstünde uyumluluk değil.
Sayfa No: Yavaş Yavaş Öğren AI
AI Kod İnceleme Katmanları: Üç Katmanlı Risk-Adaptif Yönlendirme
Üç katmanın üst üste binmesinin kilit tasarımı: tetikleme koşulları risk seviyesine göre kodlanır, kod satırı sayısına veya PR boyutuna göre değil. Pratikte, risk seviyesi belirleme AI’ın kendi değerlendirmesine dayandırılamaz — AI’ın uyumluluk bilinci yoktur, “müşteri kimlik numarası alanına dokunmak”ın PIPL kırmızı çizgisi olduğunu bilmez; PR şablonunda PR’ı açan kişinin manuel olarak işaretlemesi (şema değişikliği mi? auth değişikliği mi? faturalama değişikliği mi? uyumluluk sınırı değişikliği mi?) + CODEOWNERS kurallarıyla çift onay gerekir. İşaretleme sonucuna göre ilgili katmana yönlendirilir: düşük riskli PR’lar Katman 1’e otomatik merge yapar (allow-list yolları içinde + hata sigorta mekanizması; 30 gün içinde herhangi bir otomatik merge PR’ı üretim kazasına yol açarsa duraklar ve tüm inceleme süreci manuele döner), orta risk Katman 2 spot-check’e, yüksek risk Katman 3 yönetişim sürecine gider. Bu “risk-adaptif yönlendirme”, inceleme yükseltmenin en üst formudur.
Dört. İnceleme Aracı Seçimi: CodeRabbit Tek Cevap Değil, Ama Şu Anki Fiili Taban Çizgisi
Sonuç: Seçim boyutları şu sıraya göre dizilir: “kural özelleştirilebilirliği > PR yorum kalitesi > entegrasyon derinliği > fiyat”; finans / kamu / savunma / telekomünikasyonun çekirdek alanları için private deployment veya self-hosted şart, ama private deployment son değil — PIPL §21 veri işleme yetkilendirme sözleşmesiyle birlikte gelmeli.
Katmanları araç seviyesine 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çlere bağlı; araçların katkısı sınırlı.
GitHub Marketplace’in AI kod inceleme kategorisinde kurulum sayısında zirvede olan CodeRabbit (Sacra verilerine göre Eylül 2025’te Series B turunda 550 milyon dolar değerlemeye ulaşmış, 2026 Q2 itibarıyla ARR $40M) — “AI inceleme uzmanını” PR yorum akışına yerleştiriyor; her yorum tıklanabilir açıklamalar, düzeltme önerileri ve önem derecesi içeriyor; birim testi kör noktalarında özellikle etkili. GitHub Actions entegrasyonu en derin olan araçlardan biri; PR sayısına göre kademeli fiyatlandırma sunuyor. Kurumsal sürüme özel model, beyaz liste ve dahili bilgi tabanı gibi özellikler eklenebiliyor.
GitHub Copilot Review için tek geçerli tercih sebebi şu olabilir: zaten GitHub Enterprise kullanıyor olmanız ve yeni bir tedarikçiyle uğraşmak istememeniz. Kuralların derinlemesine özelleştirilememesi gibi yapısal bir kısıtı var; zaman ilerledikçe kural kütüphanesi CodeRabbit’in gerisinde kalacaktır.
Sourcery, Python ekosisteminin tartışmasız en güçlü otomatik kod inceleme aracıdır: PR aşamasında doğrudan yeniden yapılandırma önerileri sunar (hata tespitinin ötesinde, kodu yeniden yazar), tür açıklamalarının tamamlanması ve teknik borcun temizlenmesinde son derece etkilidir. Ancak çok dilli ekipler için yetersiz kalır — TypeScript ve Go desteği yeni yeni yetişiyor, diğer dillerde kapsamı oldukça sığ.
Cursor BugBot, Cursor editörü içindeki diyalog bağlamını görebilme becerisiyle öne çıkar; yapay zekâ ile olan sohbetlerinizi de görebildiği için üretilen koda yönelik bağlama duyarlı bir inceleme yapar. Cursor dışındaki projelerde kullanılamaz.
Antigravity Review, Google’ın Kasım 2025’te Antigravity platformuna entegre ettiği inceleme özelliğidir; Gemini 3 modeli ile Google Cloud’ın kurumsal uyumluluk altyapısına yaslanır. 2026’nın ilk yarısında hızlı bir iterasyon sürecindedir, kural kütüphanesi CodeRabbit kadar derin değildir ve kurumsal sürümün fiyatlandırma/dağıtım modeli henüz netleşmemiştir.
Beş Sektörde Uygulama: Her Denetim Ortamında İnceleme Yükseltmesinin Farklı Görünümleri
[Seri: Yavaşça Öğren AI 005]
Seçim Kriterleri Bu Sırayla Değerlendirilmeli
Seçim boyutlarını şu sıraya koyun: Kural özelleştirilebilirliği > PR yorum kalitesi > entegrasyon derinliği > fiyat. Katman 1 araçlarını uzun süre kullanacaksınız; kuralları özelleştiremezseniz, aracın kendi iç güvenlik modeline kilitlenmiş olursunuz. PR yorumları zayıf olduğunda (yapay zekâ gözden geçiren sadece “burada bir şey yanlış görünüyor” der, neyin yanlış olduğunu ya da nasıl düzeltileceğini söylemezse) bu geliştiricinin vaktini boşa harcamaktır. Entegrasyon derinliği, kullanıma başlama maliyetini belirler. Fiyat dördüncü sırada gelir; bu, önemsiz olduğu anlamına gelmez. Aynı segmentteki araçlar arasındaki fiyat farkı %30’u bulmaz; ilk üç boyuttaki fark, fiyat farkından daha belirleyicidir.
Seçim Karşıtı İki Yaygın Bilgi:
Birincisi, finans, devlet daireleri, savunma sanayii ve telekomünikasyonun temel alanlarında özel dağıtım (private deployment) veya self-hosted çözüm, pazara giriş biletidir. Ancak özel dağıtım son nokta değildir. İnceleme aracı kodunuzun tamamına erişir (PR diff + depo geçmişi); bu, kodu üçüncü bir tarafa işletmeye teslim etmekle eşdeğerdir. Bu nedenle üçüncü taraf veri işleme sözleşmesi zorunludur (Çin PIPL §21 kapsamındaki veri işleme yetkilendirmesi). Teknik izolasyon tek başına yetmez; yasal çerçeve de devreye girmelidir. AB’de faaliyet gösteren kuruluşlar için paralel düzenleme GDPR Madde 28’dir (veri işleyen sözleşmeleri). Bu tür dağıtımlar ayrıca yerel denetim kayıtları ve residency gereksinimleriyle uyumlu olmalıdır; Türkiye bağlamında KVKK (Kişisel Verilerin Korunması Kanunu) Madde 12 uyarınca veri güvenliği yükümlülükleri ve ilgili SEBIŞ/SEGBİS denetimleri de devreye girer.
İkincisi, yapay zekâ ön incelemesi ile insan incelemesi “ya-ya da” ilişkisi içinde değildir. CodeRabbit + GitHub Copilot Code Review gibi “iki Katman 1 aracının üst üste kullanılması”, büyük ölçekli kuruluşlarda yaygın bir pratiktir. Bu araçların kuralları farklıdır, yakaladıkları açık türleri birbirini tamamlar; tek bir araç her zaman kör noktalar bırakır.
Beş Sektörde Uygulama: Her Denetim Ortamında İnceleme Yükseltmesinin Farklı Görünümleri
Bu bölüm, aynı inceleme mimarisinin dört farklı düzenleyici ortamda nasıl farklı şekillerde somutlaştığını gösteriyor. Yapı aynı kalır; kısıtlar değişir.
Sonuç: Araç katmanı (Layer 1) sektörler arasında ortaktır; süreç katmanları (Layer 2/3) sektüre göre yeniden tasarlanmalıdır — telekom için ekipman güvenlik değerlendirmesi, finans için üç hat savunma modeliyle model yönetişimi + bağımsız MVU, üretim için MES + tedarik zinciri izlenebilirliği, e-ticaret için kampanya dönemleri + risk sınıflandırması.
Telekomünikasyon — Tarifeleme/Faturalandırma Değişikliklerinin İnceleme Yükseltmesi. Bir bölgesel operatörün yapay zekâ iç eğitim değerlendirmesinde bana bir şema göstermişlerdi: her tarife değişikliği kodlamadan canlıya geçişe kadar 11 ayrı kontrol noktasından geçmek zorundaydı. YZ, bunlardan yalnızca “kodlama” aşamasını 2 günden 0,5 güne indirdi; ancak CAB, algoritma kaydı (faturalandırma modellerini ilgilendiren), 等保 sertifikasyonu (Çin’in siber güvenlik seviye koruma değerlendirmesi), veri çıkışı onayı (yurtdışı modeller kullanıldığından, PIPL standart sözleşmesinin yerine geçmeyen, Sanayi ve Bilişim Teknolojileri Bakanlığı’nın «工业和信息化领域数据安全管理办法（试行）» kapsamındaki negatif liste prosedürü uygulanıyor) ve mutabakat denetimi gibi 5 aşamanın her biri birkaç günden bir aya kadar zaman yiyordu. Algoritma kaydı tek başına, dosya hazırlığından Sanayi ve Bilişim Teknolojileri Bakanlığı’nın geri dönüşüne kadar tipik olarak 4-6 ay sürüyor — yani asıl darboğaz tam olarak burası. Genel teslim süresi neredeyse hiç kıpıramadı. İnceleme sürecinin yükseltilmesindeki yön şu: Layer 1 araçları, “faturalandırma/kimlik doğrulama/uyumluluk modüllerine dokunuldu” durumunu mutlaka algılayabilmeli ve risk seviyesini otomatik olarak yukarı çekmeli; ardından talep, iş sahibi ve uyumluluk sahibinin ortak imzasına yönlendirilmeli. CAB katmanı ise yalnızca düzenleyici raporlamayı fiilen etkileyen değişikliklerde ikinci bir gözden geçirme yapmalı. Bu yolun özü, CAB’nin işlem kapasitesini tüm değişiklikler (acil yamalar dahil) için ayda 5.000-8.000 talepten, gerçekten yönetime ihtiyaç duyan (yüksek riskli) ayda 100-200 talebe indirmek. Yükseltme öncesinde inceleme darboğazı CAB idi; yükseltme sonrasında CAB tam tersine en hızlı aşama haline geldi, çünkü önceki 11 aşamadan 8’i otomasyon ve kural tabanlı ön kontrollerle elenmiş oldu.
Telekomünikasyon sektörünün en gizli acı noktası CAB (Change Advisory Board — Değişiklik Danışma Kurulu) değil, model açıklanabilirliğidir. Faturalama modelleri her bir fatura kalemindeki tarife kaynağını açıklayabilmelidir; kara kutu (black-box) bir yapay zekâ modeli devreye alındığında, müşteri şikâyetleri gelir gelmez kaynağına inmek gerekir. 12300 tüketici şikâyet hattının en sık karşılaşılan üç senaryosu (numara taşınabilirliği, fatura ulaşılabilirliği ve hat açma/kapama yönetimi) tetiklendiğinde, ilgili özellik canlıya çıkmadan önce grup düzeyinde tüketici koruma (consumer protection) ön onayından geçmek zorundadır; bu, CAB’ın üstlenebileceği bir rol değildir.
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: MVU (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ı sonrası canlıya alma. Bu beş adımın bir sıralaması vardır, paralel yürütülemez. Yapay zekânın kod yazımında hız kazandırabileceği alanlar oldukça dar kapsamlıdır (script üretimi, özellik mühendisliği kodları, veri ön işleme kodları); ancak yapılan her değişiklik düzenleyici sınırlara dokunur. Etiketlerde yapılan bir değişiklik, Çin’deki Ticari Bankaların İnternet Kredisi Yönetim Yönetmeliği (《商业银行互联网贷款管理办法》) Madde 24 ve CBIRC 2020/9 sayılı Yönetmeliği’ndeki “önemli model değişikliklerinin yeniden kayıt altına alınması” gerekliliğine karşılık gelir. İnceleme sürecinin yükseltilmesinde izlenmesi gereken yön: Katman 1 mutlaka “özellik/etiket/eşik/model ağırlıkları değiştirildi” durumunu tespit edebilmeli ve yüksek riskli yönlendirmeyi zorunlu kılmalıdır. Katman 2‘de iş mantığına hâkim bir kredi risk yöneticisi ile veri uyum yöneticisinin çift imzası bulunmalı; ayrıca MVU, iş biriminden ve BT biriminden bağımsız olmalıdır (CBIRC 2020/9 sayılı Yönetmelik bunu açıkça zorunlu tutar). Katman 3 ise model doğrulama, EAST veri raporlaması, 1104 raporlaması, Kişisel Bilgilerin Korunması Kanunu (PIPL) değerlendirmesi ve algoritma adalet denetiminden (cinsiyet/yaş/coğrafya değişken olarak kullanılmamalıdır) geçmelidir.
Gerçek bir acı noktası: Bir anonim ortaklı bankası, AI özellik mühendisliği aracını devreye aldıktan sonra model doğrulama kuyruğu 8 haftadan 12 haftaya çıktı — MVU (Model Validation Unit), AI tarafından üretilen özelliklerin PSI (Population Stability Index) / CSI (Characteristic Stability Index) kaymalarını tek tek incelemek zorunda kaldı, üstelik MVU ile veri uyumluluk ekibi arasındaki veri paylaşımı ciddi sürtüşme yarattı. MVU ham özellik dağılımlarını görmek istiyordu; ancak veri uyumluluk ekibi, PIPL (Kişisel Bilgilerin Korunması Kanunu, Çin’in GDPR muadili) gereği MVU’nun müşteri düzeyindeki verilere doğrudan erişmesine izin vermedi. Tüm süreç “model doğrulama sandbox’ı + maskelenmiş toplulaştırılmış özellikler” adlı dar bir yoldan geçmek zorundaydı. Önce Layer 2 kadrosunu tamamlayın, sonra araçtan bahsedin. Araç ne kadar güçlü olursa olsun, işi ve uyumluluğu bilen insanlar tarafından spot-check yapılmadan yürütülen bir review süreci, havada kalan bir kuleden ibaret kalır.
Üretim — MES Proses Değişikliklerinde İnceleme Yükseltmesi. İmalat sektöründe yapay zekâ ile kod üretmek büyük cazibe taşıyor (hat entegrasyonu, kalite kontrol modelleri, proses planlama); fakat MES (Manufacturing Execution System – Üretim Yürütme Sistemi) değişiklikleri çoğunlukla güvenlik kilitlerine dokunduğundan, tek bir proses parametresinin değiştirilmesi tüm hattın durmasına yol açabilir. Üretim know-how’ı göründüğünden çok daha derindir: OEE (Overall Equipment Effectiveness – Toplam Ekipman Etkinliği) kilitleri, SPC (Statistical Process Control – İstatistiksel Proses Kontrol) kontrol grafikleri, parti izlenebilirliği, iade/tamamlama akışlarına müdahale etmek başlı başına yüksek riskli kategorilerdir; salt “proses eşiği”ne bakıp karar vermek yetmez. İnceleme yükseltmesinin yönü şöyle olmalı: Katman 1’de “güvenlik kilidi / OEE / SPC / parti izlenebilirliğine dokunan” değişiklikler en yüksek risk olarak işaretlenmeli ve otomatik birleştirmeye (auto merge) kapatılmalı; Katman 2’de proses mühendisi ile güvenlik mühendisinin ortak imzası zorunlu olmalı; Katman 3’te ise deneme çalışması ve kademeli yayılım uygulanmalı (önce tek bir hatta küçük partiler halinde denenmeli, güvenlik kilidi açısından yan etki görülmediği doğrulanmalı, sonra genişletilmeli). Bu sektörde darboğaz Katman 2’deki insanda düğümleniyor: deneyimli proses mühendisleri zaten kıt bir kaynak ve zamanlarının büyük bölümü üretim tarafından emiliyor; yapılan şey aslında bir kaynak yeniden tahsisi — onların dikkatini rutin sahadan yüksek riskli PR incelemelerine kaydırmak.
E-ticaret — Büyük kampanya kuralları için review sürecinin yükseltilmesi. E-ticarette AI ile kod yazmanın sağladığı verimlilik artışı en belirgin biçimde frontend sayfaları, kampanya 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 işlem, risk kontrolü ve finansal mutabakat zincirlerine dokunduğundan tek bir hata yüz milyonlarca dolarlık kayba yol açabilir. Review sürecini yükseltmenin yönü şöyle: Katman 1’de “büyük kampanyayla ilgili modülleri / kuponları / flash sale’leri / envanteri etkileyen” değişiklikler en yüksek risk seviyesi olarak işaretlenmeli; Katman 2’de iş birimi sahibi ile risk kontrol sahibi birlikte onay vermeli; Katman 3’te ise kanarya yayılımı ve uçtan uca yük testi uygulanmalı. E-ticaretin özgül yanı, kampanyaların belirli zaman pencerelerinde yoğunlaşması: Singles’ Day, 618 ve Bahar Festivali gibi dönemlerin iki hafta öncesi ve sonrasında review standartları her zamankinden daha sıkı olur, oysa review kapasitesi üretim baskısı nedeniyle en çok bu dönemde sıkışır. Bu sektördeki saha pratiği “normal zamanda gevşek, savaş zamanında sıkı” prensibidir — büyük kampanya penceresinden bir hafta önce tüm yüksek riskli değişiklikler dondurulur ve yalnızca bug fix kabul edilir; review kapasitesi, dondurulan backlog’u temizlemeye odaklanır, böylece yüksek riskli değişikliklerin kampanya penceresine sızması önlenir.
Dört sektörü inceleyince tablo net: inceleme yükseltmenin özü yeni araç almak değil, risk yönlendirmeyi yeniden tasarlamak. Her sektörün Katman 2/3 yönlendirme koşulları farklı (telekomda CAB + algoritma kaydı + model açıklanabilirliği, finansta MVU bağımsızlığı + model doğrulama + EAST + algoritma adaleti, üretimde pilot çalıştırma + kademeli geçiş + OEE/SPC, e-ticarette büyük kampanya kilidi), ama Katman 1 araçlarının mantığı ortak kullanılabilir: hepsi “yüksek riski tanımla, otomatik etiketle, zorunlu yönlendir.” Araç katmanında birkaç Katman 1 çözümünü sektörler arası kullanmak gayet mümkün; süreç katmanı ise sektöre göre mutlaka yeniden tasarlanmalı.
VI. Karar vericilere çıkarımlar
Tersine öz-denetim — ekibiniz AI çıktılarına giderek daha fazla mı güveniyor, yoksa giderek daha mı az? AI PR (pull request) sürecinizi nasıl review ediyorsunuz — %100 hepsini mi, riske göre örnekleme mi, yoksa sessizce geçiriyor musunuz? Son 6 ayda Katman 3 yönlendirmeniz kaç kez tetiklendi? Bunlardan kaçında sorun, kaçında ise gerçek bir olay yakalandı? Yönetim kurulu bu üç rakamı istediğinde masaya yatıramıyorsanız, “yönetişiminiz” kağıt üzerinde bir uyumluluktan ibarettir.
Çıkarım 1: İnceleme yükseltmesi bir teknoloji satın alımı değil, organizasyonel kapasite yükseltmesidir. CodeRabbit Pro aylık 24 $/koltuk (PR oluşturan geliştirici başına; Pro Plus 48 $/koltuk), 200 kişilik bir ekip için yıllık yaklaşık 58 bin dolar eder; kurumsal lisans bunun 3-5 katına çıkar. Milyon dolar seviyesindeki Ar-Ge bütçeleri düşünüldüğünde bu, küçük bir kalemdir. Asıl maliyet Katman 2’de insan kaynağının tamamlanması ve Katman 3’te süreçlerin yeniden tasarlanmasıdır. Bunlar bütçeyle satın alınamaz; gereken şey organizasyonun değişime yatkınlığı ve kıdemli mühendislerin incelemelere zaman ayırma isteğidir. İnceleme yükseltmesini bir türlü ilerletemeyen ekiplerin tamamı sorunu bir BT projesi gibi yönetir: lisans dağıt, araç kur, KPI belirle. Oysa ilerletenler, Ar-Ge yöneticileriyle uyum ve compliance sorumlularını aynı masaya oturtup PR yönlendirme kurallarını birlikte tanımlar. Bu, yönetimi bir maliyet merkezinden bant genişliği varlığına taşıyan bir bütçe sinyalidir — ancak o zaman bütçe “daha fazla lisans al” satırından “inceleme bant genişliğini artır” satırına kayar.
Çıkarım İki: Otonom ajanlara geçmeden önce AI ön-inceleme (pre-review) mutlaka hazır olmalı. Bu, “motoru konuşmadan önce freni tak” ilkesinin diğer yüzü: Otonom ajanlar (Claude Code, Codex gibi) onlarca dosyayı kendileri değiştirebilir, PR açabilir, shell komutları çalıştırabilir; bu yetenekler devreye girmeden önce Layer 1’in “hangi modüle dokunuluyor, hangi sınır geçiliyor” sorusunu tespit edip ilgili katmana yönlendirmesi zorunlu. Olgunluk için önerilen nicel ölçüt: Layer 1 otomatik merge geçiş oranı ≥%95, Layer 2 örnekleme kapsama oranı ≥%20, aralıksız 3 ay sıfır P0 olay. Carlini’nin 100 bin satırlık Rust tabanlı C derleyicisi örneği sizden çok uzak değil — otonom bir ajan 2 hafta içinde üretim kalitesinde bir proje teslim edebildiği gibi, inceleme altyapısı olmayan bir organizasyon da 2 hafta içinde 20 bin üretim-kalitesinde risk biriktirebilir. Daha doğrudan karşılaştırılabilir bir sektör örneği ise Stripe’ın “Minions” ajanı: haftada yaklaşık 1.300 PR birleştiriyor, sıfır insan-yazımı kod, yalnızca insan review’ı — yapay zekânın tam otomatik üretimine karşılık insan tarafında yalnızca inceleme yapılması bu modelin ayırt edici özelliği; inceleme mekanizmasının yükseltildiğinin tam karşılığı 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 sayısı değil, kurumun riski tanıma, yönlendirme ve işleme kapasitesinin toplamıdır. CodeRabbit raporundaki “açık sorunların büyük kısmını otomatik olarak engelleme” ifadesi işin yalnızca bir parçası; AI’ı etkili kullanmak, kalan örtülü risklerin (mimari uyum, uyumluluk sınırları, iş doğruluğu) Katman 2/3’te yeterli insan gücüne ulaşıp ulaşamamasına bağlı.
İnceleme yükseltmesinde en sık düşülen hata, AI’ın PR’larını otomatik merge etmesine izin vermektir: “AI’ın verimliliğini daha belirgin 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 güzelleşir, uzun vadede kaza oranı artar — AI hızlı yazar + review gevşetilir, teknik borç orantılı şekilde büyür. CodeRabbit’in 1,7× kusur ve Apiiro’nun %322 yetki yükseltmesi şeklindeki çift yüksek uyarısı, bu tür gevşetmenin bütünsel bedelidir; tek bir noktadaki bir başarısızlıkla sınırlı değildir. İnceleme bant genişliği, PR hacmiyle orantılı olarak genişlemelidir; orantısızlık kontrolden çıkmak demektir.
30 Günlük Uygulama Listesi (“Pazartesi hangi toplantıyı açalım, hangi dosyayı değiştirelim” düzeyinde taneciklik):
1. Hafta: Mevcut PR yönlendirme kurallarını envanterleyin ve “şema / auth / billing / uyumluluk” şeklinde dört kategoriye göre kırmızıyla işaretleyin; son 90 gündeki Katman 3 tetiklenme sayısı ve ortalama kuyruk süresini çıkararak temel çizgiyi oluşturun.
2. Hafta: Katman 1 araçlarını devreye alın (CodeRabbit / GitHub Copilot Review arasından seçim yapın, “şirket içi dağıtım (on-prem)” zorunluluğuna göre eleyin), kuralları yapılandırın; PR şablonuna manuel risk seviyesi işaretleme seçeneği ekleyin.
3. Hafta: Katman 2 iş sahibi + uyumluluk sahibi listesini oluşturun, spot-check örnekleme oranını tanımlayın (önerilen %20–30); CODEOWNERS dosyasını modül sahiplerine göre eksiksiz doldurun.
4. Hafta: Ortalama PR inceleme süresi, değişiklik başarısızlık oranı, inceleme sonrası kaçırılan hata oranı, Katman 2/3 ortalama kuyruk süresi ve Katman 3 yönlendirmesinin tetiklediği uyumluluk olayı sayısı olmak üzere bu 5 metriği PMO haftalık raporuna taşıyın; eş zamanlı olarak Katman 1 geçiş oranı ≥%95, Katman 2 spot-check kapsama oranı ≥%20 ve ardışık 3 ay sıfır P0 olay şartlarını otonom ajan kabul eşiği olarak belirleyin.
Eşlik eden metrikleri de devreye alın: PR ortalama inceleme süresi, değişiklik hata oranı, inceleme sonrası kaçırılan defect oranı, Layer 2/3 ortalama kuyruk süresi, Layer 3 yönlendirmesinin tetiklediği uyumluluk olayı sayısı ve model doğrulama kuyruk süresi. AI173’ün sonunda paylaşılan bir gözlemi tekrar hatırlatalım: birçok büyük şirket, üst yönetime AI programlama ROI’sini “kaç geliştiriciyi kapsadığı” veya “kaç seat satın alındığı” üzerinden raporluyor — yani asıl darboğazların hepsini gizliyorlar. Bu metrikleri yönetim kurulu raporlamasına taşıdığınızda (seat sayısı ve yazılan kod satırı yerine), bütçe “daha fazla lisans alalım”dan “inceleme kapasitesini artıralım”a kayar.
Gölge AI yönetimi de paralel şekilde yürütülmeli. UpGuard’ın 2025 raporuna göre küresel ölçekte çalışanların yaklaşık %80’i IT onayı olmadan generative AI araçları kullanıyor — sadece geliştiriciler değil. İş birimlerinin IT’yi devre dışı bırakıp kendi başlarına ChatGPT ile kod yazması, uyumluluk sorumlularının bugün en çok uğraştığı konu. Yönetim altyapısını güçlendirip gölge AI yönetimini arkada bırakmak, “beyan edilmiş silahları” denetlerken “beyan edilmemiş silahları” görmezden gelmek anlamına gelir.
Geçerli Olmayan Senaryolar: Ekibiniz 50 kişinin altındaysa, yüksek düzenlemeye tabi bir sektörde değilseniz, otonom ajanlarla çalışmıyorsanız veya PR hacminiz ayda 100’ün altındaysa, bu yazıdaki değerlendirmelerin en az %60’ı size doğrudan uygulanamaz — yapıyı birebir kopyalamaya çalışmayın; Layer 1 araçları + spot-check katmanıyla yetinin.
Sıradaki Adım
Sıradaki yazı (AI175), araç katmanını ele alıyor: 2026’da yapay zeka araçları savaşı çoktan bitti, ama kazananları kullanıp kullanamayacağınız apayrı bir mesele. İki taht sahibi (Claude Code / Codex), satın alma alışkanlıklarının taşıdığı Copilot ve start çizgisindeki Antigravity arasındaki rekabet söz konusu; aynı zamanda “yönetişim kapasitesi, kimin hangi seviyede kullanabileceğini belirliyor” meselesi de var. AI174 size değerlendirme yükseltmenin yapısını veriyor, AI175 araç seçiminin yapısını veriyor; iki yazıyı birlikte okuduğunuzda “yapay zeka kod yazdıktan sonra organizasyonun bunu nasıl karşılayacağı”nın bütün haritasını elde edersiniz.
Bu yazıyı bitirdikten sonra, AI173’ün üçüncü bölümünü (yeni darboğazın tespiti) + AI175’in “Dört Büyük Araç” bölümünü (yönetişim kapasitesinin araç kapasitesiyle 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?
Kurumsal Yapay Zekâ Programlama Araçları: Gerçek Sorunlar ve Tanı Süreci
Kurumsal dünyada yapay zekâ programlama araçları benimsendiğinde, gerçekte çözülmesi gereken somut sorunlar genellikle şu birkaç noktada düğümlenir: Mevcut kod inceleme (code review) süreci, yapay zekânın ürettiği çıktı hacmini kaldırabilir mi? Katman 2 insan kaynağı ne düzeyde olmalı (PR sayısına, modül sayısına veya FTE oranına göre hesaplanır)? Katman 3’teki CAB ve uyum süreçleri (compliance workflow) yeniden tasarlanmalı mı? Pilot çalışmada hangi metriklerle kabul testi yapılmalı?
Tanı Giriş Noktası: Önce ekibinizin beş temel metriğine bakın — ortalama PR inceleme süresi, değişiklik hata oranı (change failure rate), inceleme sonrası kaçırılan hata oranı, Katman 2/3 ortalama kuyruk süresi, Katman 3 yönlendirme kaynaklı uyum ihlali sayısı. Bu beş metrikten herhangi birini çıkaramıyorsanız, AI ön inceleme aracına henüz hazır değilsiniz demektir.
Sunulan Üç İş Birliği Modeli
Kurumsal İç Eğitim: Şirketinizin gerçek projelerini temel alarak, yapay zekâ destekli inceleme üç katmanlı modelinin sahada uygulanması, Katman 1 araç seçimi (CodeRabbit, GitHub Copilot Review gibi adaylar; özel dağıtım, kural özelleştirme esnekliği, entegrasyon derinliği ve maliyet olmak üzere dört boyutta değerlendirilir), Katman 2/3 süreç yeniden tasarımı ve bunlara eşlik eden metrik sisteminin kurulumu birlikte yürütülür.
Teslimat Kapsamı:
- Ekip mevcut durum skorlaması (inceleme kapasitesi doygunluk analizi)
- Üç katmanlı model için 3-6 aylık uygulama yol haritası
- Katman 1 araç seçimi karar ağacı
- Metrik panosu (dashboard) taslak tasarımı
Süre ve Yatırım: 3 gün ≈ ¥90.000.
Danışmanlık (Odaklanmış Kapsam): Tek bir net karara odaklanır — örneğin CodeRabbit’in organizasyona dahil edilip edilemeyeceğinin değerlendirilmesi, yüksek düzenleme denetimine tabii sektörlerde üç katmanlı inceleme modelinin nasıl uygulanacağı (finansta MVU bağımsızlığı ve denetim izi zorunluluğu, telekomda algoritma kaydı ve 12300 şikâyet hattı entegrasyonu), mevcut Change Advisory Board (CAB) ritminin AI pull request’leri için nasıl yeniden yönlendirileceği. Karar temasına göre paketlenir (5–15 saatlik danışmanlık paketi), teslim kapsamı: karar tutanağı, uygulama kontrol listesi ve 1 haftalık takip görüşmesi. ¥5K/saat.
Birebir Koçluk / Kişisel Yönetim Kurulu: “Kendi gelişimine ciddi yatırım yapmak isteyen” başkan yardımcısı, direktör ve kıdemli mühendislere yöneliktir — AI kodlama araçlarını zaten kullanıyorsunuz; inceleme kalitesini yükseltmek, ekip yönetişimi ve kurum içi departmanlar arası dengeleri yönetmek için gereken sağduyunun organizasyonunuza yerleşmesini istiyorsunuz. 12 seans / 6 ay, temaya göre fiyatlandırma; teslim kapsamı: koçluk görüşme tutanakları ve aşamalı aksiyon geriye dönük değerlendirmesi. ¥180K–360K.
Yönetim Toplantıları ve Sektör Konuşmaları: AI destekli kod inceleme, organizasyonel yönetişim, kurumsal AI dönüşümü ve yazılım mühendisliğindeki değişim etrafında şekillenir. Yarım gün / tam gün, ev sahibi kuruluşun ihtiyacına göre uyarlanır.
Yazıda paylaşılan çerçeveler genel bir yol gösterici niteliktedir. Sahada uygulamada, kurumun veri sınırları, düzenleyici yükümlülükleri, mühendislik olgunluk seviyesi ve mevcut inceleme süreçleri özelinde yeniden tasarlanması gerekir. İş birliği için coach@iaiuse.com üzerinden iletişime geçilebilir.
Notlar (çevirmen tarafından, kaynak metne sadık kalmak amacıyla): Algoritma kaydı (算法备案) ve 12300 şikâyet hattı, Çin telekom düzenleyici çerçevesine (工信部) özgü kavramlardır. Eşdeğerleri için bölgesel düzenleyicilerin (ör. FCC, Ofcom, BNetzA, MIC, TRAI) ilgili şikâyet/uyumluluk mekanizmalarıyla eşleştirilmesi gerekir.
İlgili Okuma: «Tabela Metodolojisi v1.0» (Yavaşça AI Öğren 187), kurumsal AI dönüşümüne yönelik 7 adımlı çerçeveyi sistematik biçimde ele alır.
Bu Seri Hakkında
“AI Çağında Yazılım Mühendisliğinde Dönüşüm” serisi, telekomünikasyon, finans, üretim ve e-ticaret gibi sektörlerdeki CIO, CDO, CTO ve dijital dönüşüm liderlerine yönelik araştırma odaklı bir çalışmadır; AI kodlama araçlarının yazılım teslim süreçleri, organizasyonel yapılar, yönetişim mekanizmaları ve yönetim metrikleri üzerindeki etkisini tartışır.
Bu yayının arkasında küçük bir ekip var—ben ve 1-2 uzun süreli iş ortağım; AI kodlama araçları araştırması, organizasyonel yönetişim vaka analizi ve koçluk görüşmeleri bu iş bölümü içinde yürütülüyor. “Kurumlarla birlikte yürüdüğümüz” projelerin çoğu, hepimizin ortak teslim ettiği çalışmalardır.
Seri, akademik makaleleri, satıcı yayınlarını ve sektör raporlarını sürekli takip eder; araştırma veri tabanında 200’den fazla kaynak birikmiştir ve temel yargılar için kanıt düzeyi etiketlenerek doğrulanmış gerçekler, satıcı iddiaları, sektör gözlemleri ve yazar çıkarımları mümkün olduğunca ayrıştırılır.
Yaklaşık 8 yıllık büyük ölçekli kurumsal danışmanlık ve iş analitiği deneyimim var; IBM’de çalıştım ve telekomünikasyon, 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, gereksinim analizi, ürün tasarımı ve ekipler arası uygulama alanlarında çalışmaya devam ettim.
Bu serideki inceleme yükseltmeleri, organizasyonel yönetişim ve süreç yeniden tasarımına ilişkin değerlendirmeler, söz konusu uygulamalardan ve bunların açık araştırma ile sektör vakalarıyla çapraz doğrulanmasından elde edilmiştir. Spesifik projelere atıfta bulunan içerik anonimleştirilmiştir; bazı sektör senaryoları tipik problem çıkarımları niteliğindedir ve ilgili kaynaklar yazının sonundaki referanslarda belirtilmiştir.
Kaynak referanslar (kaynak + kanıt düzeyi + duruş notu)
Kaynaklar (Madde Madde Atıf + Kanıt Düzeyi + Pozisyon Etiketi)
CodeRabbit Yapay Zeka ve İnsan Kod Üretimi Karşılaştırma Raporu (2025.12.17, birincil kaynak, satıcı bakış açısı): 470 açık kaynak GitHub PR’ını (dosya boyutu/karmaşıklığına göre eşleştirilmemiş AI vs insan karşılaştırmasıyla) inceliyor. Toplam hata sayısı 1,7× (PR başına ortalama 10,83’e karşı 6,45); güvenlik açıkları alt kategorilere göre 1,57–2,74× — XSS 2,74×, hatalı parola işleme 1,88×, güvensiz doğrudan nesne referansı (IDOR) 1,91×, güvensiz ters serileştirme 1,82×; mantık/doğruluk 1,75× (%75 yüksek ciddiyet), kod kalitesi 1,64×, performans 1,42×, okunabilirlik 3×+, biçimlendirme 2,66×, hata yönetimi ~2×, aşırı I/O ~8×. CodeRabbit’ın kendi araştırması, satıcı bakış açısı; örneklem ve metedoloji kamuya açık. https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report / The Register 2025.12.17 haberi.
Apiiro 2025.9.4 (Satıcı Perspektifi): Fortune 50 şirketlerinin kod depoları üzerinde yapılan tarama (veri dönemi: Aralık 2024 – Haziran 2026). Yapay zekâ tarafından üretilen kodda aylık güvenlik bulgusu sayısı yaklaşık 1.000’den 10.000’in üzerine fırladı (mutlak sayıda 10 kat); yetki yükseltme açıklarında %322 (mutlak sayı), mimari katmandaki tasarım kusurlarında %153 artış görüldü. Üretilen kod hacmine göre normalleştirildiğinde tahmini artış yaklaşık %60–80 aralığına iniyor. Sözdizimi hataları %76, mantıksal hatalar ise %60 azaldı. The Register, Cloud Security Alliance Labs ve SiliconANGLE tarafından haberleştirildi.
JetBrains AI Pulse Survey 2026.1 (Birinci Kaynak): 10.000’den fazla profesyonel geliştirici, 8 dil. 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ıdan oluşan, 150.000 okuyucuya ulaşan bir anket; kıdemli mühendislerin %56’sı, mühendislik işlerinin %70’inden fazlasını AI araçlarına dayandırdıklarını belirtiyor (yoğun kullanım kendi beyanına dayanıyor, kod satırı oranı değil); Claude Code %46 ile en çok tercih edilen araç (Cursor %19, Copilot %9’a karşı); 10.000 çalışanın altındaki şirketlerde %75 Claude Code tercih edilirken, 10.000 üstünde %56 Copilot tercih ediliyor. https://newsletter.pragmaticengineer.com/p/ai-tooling-2026
GitHub Octoverse 2024 / 2025 (birincil kaynak): Octoverse 2025 raporu, Copilot coding agent’ın 2025 Mayıs–Eylül arasındaki beş aylık dönemde 1 milyondan fazla PR’ın yazarı olduğunu ortaya koyuyor; yeni geliştiricilerin %80’i ilk hafta içinde Copilot kullanıyor. “PR katılımında %40-60” oranı sektör tahminidir, Octoverse verisi değildir. GitHub Engineering Blog ve The New Stack tarafından derlenmiştir.
Stripe Minions (2026.3, birincil kaynak): Stripe’ın “Minions” agent’ı haftada yaklaşık 1.300 PR birleştiriyor; sıfır insan yazımı (yalnızca insan review’ı) — tam otomatik AI üretimi + salt review yapan insan, bu modelin ayırt edici özelliği. 500+ MCP tool, AWS EC2 devbox, Block Goose branch stratejisi. https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents / InfoQ 2026.3.20 haberi.
Anthropic Skills mimarisi (2026.1, birincil kaynak, satıcı perspektifi): Anthropic, Skills tasarım dokümanını kamuya açıkladı — özü görev yeteneklerinin modülerleştirilmesi (modular folders that teach Claude specific tasks; skill dosyaları + progressive context loading yaklaşımıyla tasarlanmış) ve PR yönlendirmesiyle ilgisi yoktur. Endüstride daha yaygın olan PR risk yönlendirmesi, GitHub/GitLab tarafındaki branch protection + CODEOWNERS kurallarıyla sağlanır — yani PR’lar dosya yoluna ve Codeowner’a göre yönlendirilir. Anthropic Engineering Blog.
Carlini / Anthropic (Ocak–Şubat 2026, Birincil kaynak, birinci düzey araştırma): Anthropic araştırmacısı Nicholas Carlini, 16 adet Claude Opus 4.6 ajanını paralel olarak yaklaşık iki hafta boyunca (~2.000 oturum, ~20.000 dolar API maliyeti) çalıştırarak sıfırdan Rust tabanlı 100.000 satırlık bir C derleyicisi yazdırdı; derleyici Linux 6.9’u (x86/ARM/RISC-V) derleyebiliyor ve GCC torture testinde %99 geçiyor. Çalışma kapalı bir alanda yürütülen araştırma niteliğinde; üretime taşınmadı ve review mekanizması içermiyor. The Register 9 Şubat 2026 ve Ars Technica Şubat 2026 haberleriyle gündeme geldi.
METR 2026.2 güncelleme araştırması (birincil kaynak, doğrulanmalı): Erken dönem çalışmada 16 kıdemli geliştirici, 246 gerçek dünya görevi, Cursor Pro + Claude 3.5/3.7 Sonnet kullanılmış; AI kullanımı işleri %19 yavaşlatmış (%95 GA: %2–%39), katılımcılar ise kendilerini %20 daha hızlı hissetmiş. 2026.2 takip çalışmasında anlatı kısmen tersine dönmüş (yeni katılımcılarda -%4, kıdemlilerde kısmi reversal); tam rakamların METR orijinal raporuna karşı çapraz doğrulanması gerekiyor. https://metr.org/blog/2026-02-24-uplift-update
Microsoft FY26 Frontier Suite / EY Vakası (birincil kaynak, satıcı bakış açısı): EY, Microsoft 365 Copilot’ı 150.000 çalışanına konuşlandırdı; %15 üretkenlik artışı elde etti (çalışan başına haftalık 14 saate denk geliyor; bu süre müşteri teslimatı ve öğrenmeye yeniden yönlendirildi). Ardından çalışan tabanını 400.000’in üzerine genişletti. Microsoft Power Platform + Copilot Studio üzerinde uçtan uca hayata geçirilen finansal operasyon senaryosunda lead time %95 hızlandı, operasyonel maliyet %37 düştü (yalnızca finansal operasyon senaryosuna ait; tüm şirket için 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’u 54 ülkede 56.000 çalışanına konuşlandırdı ve 19.000 dahili yapay zeka ajanını yönetmek için Agent 365’i kullanıyor. Atos, “yönetişim ve güvenlik, ajan bazlı yapay zekanın (agentic AI) ilk geçiş kapısıdır” diye kendisi ifade ediyor. 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üzenleyebiliyor, shell komutları çalıştırabiliyor, Git’i yönetebiliyor ve PR (Pull Request) açabiliyor; Codex ise birden fazla alt ajanı izole kopyalar üzerinde paralel olarak çalıştırıp sonuçları birleştirebiliyor. Anthropic / OpenAI mühendislik dokümanları.
CodeRabbit Şirket Görünümü (2025–2026, Birincil Kaynak): GitHub Marketplace AI inceleme araçları pazarında ilk sıralarda; Eylül 2025’te Series B turunda yaklaşık 550 milyon dolar değerleme; ARR 2025–2026’da yaklaşık 10 kat artarak 40 milyon dolara ulaştı (2026 Q2, Sacra verileri); Pro 24 $/koltuk/ay, Pro Plus 48 $/koltuk/ay (PR oluşturan geliştirici başına). Sacra / Reuters / TechCrunch çoklu kaynak. https://sacra.com/c/coderabbit
GitHub Copilot Review / Sourcery / Cursor BugBot / Antigravity Review (Birincil kaynak, satıcı bakış açısı): Her Layer 1 inceleme aracının resmi dokümanları ve ürün sayfaları; karşılaştırılabilir kapsam boyutları, kural özelleştirme esnekliği ve entegrasyon derinliği. Antigravity, 18 Kasım 2025’te GA yayınlandı (VentureBeat / PCMag haberleri).
Kod incelemesinin kökeni (birincil): İki ana kaynak — ① Weinberg, 1971’de yayımladığı The Psychology of Computer Programming ile “egoless programming” kavramını ortaya attı (yazarın kendisi NASA Goddard Space Flight Center’da çalışıyordu ve Nebraska Üniversitesi’nde öğretim üyesiydi, IBM geçmişi yoktur); ② IBM Fagan Inspections, Michael Fagan tarafından 1976’da IBM bünyesinde sistematize edildi (Fagan’ın kendisi IBM çalışanıydı). Bu iki gelenek paralel biçimde evrildi. Bu, AI çağı incelemelerini geleneksel review ile karşılaştırmak için tarihsel bir referans noktasıdır.
Finansal düzenleme referansı (birincil kaynak): 《商业银行互联网贷款管理暂行办法》(Ticari Bankaların İnternet Üzerinden Kredi Yönetimine İlişkin Geçici Yöntemler) — Çin Bankacılık ve Sigorta Düzenleme Komisyonu (CBIRC) Yönetmeliği 2020 Sayı 9, Madde 39–42 (risk modeli yönetimi) — model yönetişiminde üç savunma hattı (iş birimi, BT, uyum ve iç denetim) + Model Doğrulama Birimi’nin (MVU) bağımsızlığı + önemli model değişikliklerinin yeniden kayıt altına alınması; EAST (denetim analiz sistemi) aylık raporlama + 1104 raporlaması; Çin Merkez Bankası tarafından bireysel kredi geçmişi (个人征信) ile algoritma adillik denetimi (cinsiyet/yaş/coğrafi değişken kısıtlamaları).
Telekomünikasyon Düzenleme Referansları (birincil kaynak): MIIT (Sanayi ve Bakanlığı Bakanlığı) algoritma kayıt yönetimi yönetmelikleri (faturalama ve finansal işlem algoritmaları için çift denetim); MLPS (Multi-Level Protection Scheme / Çok Düzeyli Koruma Şeması) denetimi – Seviye 2 için 30 iş günü, Seviye 3 için 45 iş günü; 12300 şikâyet hattının ilk üş konusu (numara taşıma, fatura ulaşılabilirliği, hattın açılıp kapatılması yönetimi); “Sanayi ve Bilişim Alanında Veri Güvenliği Yönetimi Yönetmelikleri (Deneme)” kapsamındaki veri çıkışı negatif listesi.
PIPL Veri İşleme Devri (birincil kaynak): Kişisel Bilgilerin Korunması Kanunu (Personal Information Protection Law — Çin’in GDPR muadili veri koruma yasası) Madde 21 + Madde 55 — üçüncü taraf işleme sözleşmesi zorunluluğu ve 3–5 yıllık denetim izi saklama süresi (sektöre göre değişir).
Stack Overflow 2025 Geliştirici Araştırması (birincil kaynak): 49.000’den fazla geliştirici katılımı. Yapay zekâ çıktısının doğruluğuna güvenen geliştirici oranı 2024’teki %40’tan 2025’te %29’a düştü (11 puanlık düşüş); aynı zamanda geliştiricilerin %46’sı yapay zekâ çıktısına karşı aktif güvensizlik bildirdi (2024’teki %31’in üzerinde). Code churn (yapay zekâ üretimi kodun kısa sürede elden geçirilme ya da 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 çapta ç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ükseltmelerini gölge AI yönetişimiyle birlikte ele almamak, uyumluluk açısından kör nokta yaratır. https://www.upguard.com/resources/the-state-of-shadow-ai
Yazarın kendi vakaları (anonimleştirilmiş): ① Bir bölgesel telekom operatöründe AI iç eğitimi (2024 Q4, 11 kontrol noktasının retrospectif analizi, anonimleştirilmiş) ② Bir anonim orta ölçekli bankada kredi risk değerlendirme süreci yükseltme tartışması (2025 H1, anonimleştirilmiş) ③ Büyük bir imalat şirketinde MES üretim süreç değişikliği değerlendirme akışının yeniden tasarımı (2025 H2, anonimleştirilmiş) ④ Önde gelen bir e-ticaret platformunda büyük kampanya (mega sale) kilitleme uygulaması (2025 Singles’ Day / 11.11, anonimleştirilmiş).
Vaka anonimleştirme notu: Bu yazıda bahsedilen telekom, finans, imalat ve e-ticaret vakaları, yazarın telekom odaklı AI iç eğitimi ve dijital dönüşüm ekiplerini izleme deneyimlerinden türetilmiş olup anonimleştirilmiştir; sektöre özgü uygulama paragrafları belirli bir müşteri danışmanlığının sonucu değil, tipik sorun senaryolarının çıkarımı niteliğindedir. Herhangi bir atıf için lütfen anonimleştirildiğini belirtin.
buymeacoffee
