Araçlar ve Kod Grafı

Araç karşılaştırmaları genelde “hangisi daha iyi kod yazıyor?” sorusuna odaklanıyor. Regüle bir kurumda bu soru önemli, ama tek başına yetmiyor; güvenlik, uyum ve denetimin soruları da cevaplanmalı. Bu bölümde araçlara o sorularla bakıyorum.

İkinci yarıda ise araçların bugün pek iyi yapamadığı bir işi anlatıyorum: Ajanın yaptığı bir değişikliğin, sistemin başka bir yerinde neyi etkileyeceğini önceden görmek. Büyük bir kod tabanında bunu ne ajan biliyor ne de review yapan kişi her zaman hatırlıyor. Bunun için kod grafı kurdum.

Önce sorulacak beş soru

• Veri politikası. Gönderilen kod nerede işleniyor, ne kadar tutuluyor, eğitimde kullanılıyor mu? Ve bunlar sözleşmenin hangi maddesinde yazıyor? “Eğitimde kullanmıyoruz” bir pazarlama cümlesi de olabilir, bir sözleşme maddesi de; ikisi aynı şey değil.
• Kapalı çalışma. Araç yerel bir modele bağlanabiliyor mu? Satıcının modeli sizin veri merkezinizde çalışabiliyor mu? Tamamen kapalı bir ağda çalışabiliyor mu?
• Yönetici kontrolleri. Kurum, kullanıcının yerelde değiştiremeyeceği ayarlar dağıtabiliyor mu? Hangi araçlara ve komutlara izin verildiğini merkezden belirleyebiliyor mu? Kullanım verisini görüyor mu?
• Log. Her istek ve her araç çağrısı kaydediliyor mu? Nerede? Kurum bu kayda erişebiliyor mu?
• Lisans modeli. Koltuk mu, token mı, ikisi birden mi? Teknik bir soru değil, ama altıncı bölümde göreceğimiz gibi kullanım politikasını asıl belirleyen şey bu.

Bu yıl eklenen iki soru

Beş sorunun yeterli olduğunu sanıyordum. 2026 iki soru daha ekletti.

Ajan kendi ayarını aşabiliyor mu? Birinci bölümdeki #56694’te, kullanıcının bildirdiğine göre Claude Code kendisini engelleyen hook whitelist’ini kendisi düzenledi. Codex’te en geniş yetkili mod olan danger-full-access, yönetici requirements.toml ile kapatmazsa geliştiricinin seçimine açık. Cursor’da MCPoison açığı, MCP onayının sunucunun içeriğine değil adına bağlı olduğunu gösterdi; Cursor bunu 1.3 sürümünde düzeltti. Tek tek açıklar kapanıyor, ama soru kalıcı: Ajanın kendi sınırına dokunabildiği her yer bir açık adayı.

Tedarik zinciri ne kadar kontrol altında? Ajanın yüklediği MCP sunucuları, skill’ler ve paketler artık kodun parçası:

• Koi Security, Şubat 2026’da ClawHub’daki 2.857 skill’in 341’inin zararlı olduğunu buldu.
• npm’deki postmark-mcp sunucusu, Eylül 2025’te gönderilen her e-postanın bir kopyasını gizlice üçüncü bir adrese yolluyordu.
• 2026’da beş sınır model üzerinde yapılan bir çalışmada modellerin önerdiği paket adlarının %4,6 ile %6,1’i uydurma çıktı. Beş modelin aynı şekilde uydurduğu 127 paket adından 53’ü hâlâ kayda açık; yani birinin o adla zararlı bir paket yayımlamasını bekliyor.

“Registry dışından yükleme kapatılabiliyor mu?” sorusu bu yüzden artık listede.

Araçlar bu sorularla

Bu tabloyu Ekim 2026’da, satıcıların kendi dokümanlarına bakarak doldurdum. Bu ürünler neredeyse her ay değişiyor; siz okurken birkaç hücre çoktan eskimiş olabilir, o yüzden karar vermeden önce bir kez de siz bakın. Puan da vermedim, çünkü bu sorularda 4 ile 5 arasındaki fark bir şey anlatmıyor: Araç ya yapabiliyor, ya kısmen yapabiliyor, ya hiç yapamıyor. Yeni eklediğim iki soruyu tabloya koymadım; onların cevabı araçtan çok sürüme bağlı.

Tablodan çıkan sonuç basit: Hiçbir araç beş sorunun beşinde birden “evet” değil. Bulut araçları yönetilebiliyor ama kapalı değil; yerel modeller kapalı ama yönetilmiyor. Bunu kabul edince araç seçimi “hangisi?” sorusu olmaktan çıkıp “hangi iş için hangisi?” sorusuna dönüşüyor. Dördüncü ve beşinci bölümlerin konusu bu.

Yerel modeller için bir kalite notu da düşmem lazım, çünkü tabloda görünmüyor. Ekim 2026’da SWE-bench Verified’da sınır modeller %95–96 bandında. Tek bir iş istasyonu GPU’suna sığan en iyi açık modeller ise yaklaşık 20 puan geride; örneğin Qwen3.6-27B %77’de. 400 milyar parametre sınıfındaki açık modeller farkı 10 puana kadar indiriyor, ama onlar da birden fazla veri merkezi GPU’su istiyor. Bu rakamların çoğunun satıcıların kendi beyanı olduğunu da not edeyim.

Bu modelleri günlük işte kullananların ortak görüşü şu: “İş görüyor, ama sınır modellerin seviyesinde değil.” Fark en çok birden fazla dosyaya dokunan refactor’larda ve uzun süren ajan işlerinde açılıyor. Bunun günlük işte ne anlama geldiğini dördüncü bölümde anlatacağım.

Kod grafı: araçların eksik kalan tarafı

Bankacılık ya da sigorta çekirdeği gibi bir sistemi düşünün: onlarca solution, yüzlerce proje, birbirini çağıran servisler, paylaşılan tablolar ve gün sonu süreçleri.

Geliştirici bir metodu değiştiriyor. Ajan o dosyayı, belki o projeyi görüyor. Ama başka bir solution’da o metoda bağlı başka bir metodu ya da gece çalışan bir toplu işi görmüyor. Bağlam penceresi ne kadar büyük olursa olsun görmüyor, çünkü pencereye hangi dosyayı alması gerektiğini bilmiyor.

Kod grafı bu boşluğu dolduruyor: Kodun kendisinden çıkarılmış, solution’lar arası bir bağımlılık grafı.

Nasıl kuruluyor? .NET’te Roslyn kullanıyorum. Derleyici altyapısı semantik model veriyor; yani metin eşleştirmesi değil, gerçek sembol çözümü. Java’da JavaParser ya da derleyici API’si aynı işi görüyor.

• Düğümler: solution, proje, namespace, sınıf, metot, ORM eşlemesinden gelen tablo, toplu iş, HTTP uç noktası, mesaj kuyruğu.
• Kenarlar: çağırır, kalıtım alır, projeye referans verir, tabloyu okur ya da yazar, toplu işi tetikler, uç noktayı sunar.

Grafı nerede tutacağınız sistemin büyüklüğüne bağlı. Küçük bir sistemde ilişkisel veritabanındaki basit bir tablo yetiyor. Solution sayısı onlarcaya, bağlantı sayısı milyonlara çıkınca Neo4j gibi bir graf veritabanı sorguları epey kolaylaştırıyor. Grafı güncel tutmak için de iki şey yapıyorum: Her merge’de sadece değişen kısmı güncelliyorum, gece de baştan kuruyorum ki gün içinde biriken küçük kaymalar temizlensin.

Nasıl kullanılıyor? Grafı bir MCP sunucusu olarak açtım. Böylece hangi araç kullanılırsa kullanılsın, kendi eklentim de, yerel modelle çalışan ajan da, hazır ajanlar da aynı sorulara aynı cevabı alıyor. Sorular şunlar:

• impact(symbol): Bu sembolü değiştirirsem hangi uç noktalar, toplu işler ve tablolar etkilenir?
• callers(symbol, depth): Bunu kim çağırıyor, kaç seviye yukarıya kadar?
• readers(table) / writers(table): Bu tabloyu kim okuyor, kim yazıyor?
• path(a, b): İki sembol arasında bir bağımlılık yolu var mı?
• owner(symbol): Bu kodun sahibi hangi ekip? (repo meta verisinden)
• find_existing(intent): Bu işi yapan bir metot ya da servis zaten var mı? Ajan yazmadan önce sorar, varsa onu kullanır.
• duplicates(block): Bu bloğun beş satırdan uzun kopyaları nerede?
• connectivity(scope): Bin satır başına kaç çağrı var? Düşüyorsa kod birbirine bağlanmıyor, kopyalanıyor demek.

Listenin son üç sorusu, yani find_existing, duplicates ve connectivity, bu yıl ayrı bir önem kazandı. Sebebi GitClear’ın 2026 raporu. 2023–2026 arasındaki 623 milyon değişikliği inceleyen rapor, tam bu üç soruya denk gelen üç şey gösteriyor: Beş satırdan uzun tekrar eden kod blokları %81 artmış; refactor ile taşınan, yani yeniden kullanılan kodun payı 2022’de %21’ken 2026’da %3,8’e düşmüş; fonksiyonlar arası çağrı yoğunluğu %35 azalmış. Kısacası ajanlar var olan kodu yeniden kullanmak yerine kopyalıyor.

Kod bu hızda üretilirken review’da gözle bakmak artık yetmiyor. Sorun sadece kopyayı fark etmek değil. Ajanın yazdığı kodun sistemin neresine dokunduğunu, mevcut mimariyle uyumlu olup olmadığını bir insanın her PR’da kafasında kurması mümkün değil. Günde birkaç PR’ı dikkatle okuyabilirsiniz, onlarcasını okuyamazsınız.

Bu yüzden kontrolü review’dan önceye aldım ve kuralları sertleştirdim. Ajan yazmaya başlamadan önce find_existing ile grafa soruyor; aynı işi yapan bir metot ya da servis varsa onu kullanmak zorunda. Yazdıktan sonra duplicates ve connectivity devreye giriyor: Yeni bir kopya oluşmuşsa ya da kod mevcut yapıya bağlanmak yerine yanına ayrı bir ada gibi eklenmişse, ajan bunu PR açmadan önce düzeltmek zorunda. Böylece ajanın mevcut mimarinin dışına taşması ve kuralların dışında kod yazması daha baştan engelleniyor.

Grafın bir review aracı olmaktan çıkıp ajanın çalışma aracına dönüştüğü yer burası. Benim de en çok emek verdiğim kısım bu oldu.

Ne kazandırdı? İki şey; biri beklediğim, biri değil.

Beklediğim kazanç etki analizindeydi. Önceden bir değişikliğin neyi etkileyeceğini bulmak için sistemi iyi bilen birine sormak, sonra kodda tek tek arama yapmak gerekiyordu; bu da bazen saatler sürüyordu. Grafla bu iş tek bir sorguya indi. Daha önemlisi, liste daha eksiksiz çıkmaya başladı. Sistemi ne kadar iyi bilirse bilsin, kimse bütün bağlantıları aklında tutamıyor; graf ise unutmuyor.

Beklemediğim, review’un karakterinin değişmesi oldu. Ajan “bu değişiklik güvenli” dediğinde kimse ona güvenmek zorunda kalmadı; impact sorgusunun verdiği liste review’un girdisi oldu. Birinci bölümde “bağımsız kontrol” dediğim şey, yani modelin ikna gücünden bağımsız ve her seferinde aynı sonucu veren bir kapı, pratikte buydu.

Ne yürümedi? İlk denemede grafı gereğinden ayrıntılı kurdum; her özelliği, her alanı ayrı bir düğüm yaptım. Sorgular yavaşladı, bakımı zorlaştı. Sonunda metot ve servis seviyesinde durmanın yettiğini gördüm. Alan seviyesinde bir ayrıntı gerektiğinde onu derleyiciden o anda sormak, her şeyi grafta tutmaktan çok daha ucuz.

Bu yaklaşım dile de bağlı değil. Derleyicinin semantik modelini verdiği her dilde aynı graf kurulabiliyor. Ben de bu grafı birden fazla dili kapsayacak şekilde geliştirdim; nasıl çalıştığını ayrı bir dizide anlatacağım. Neden “graf olmadan otonom ajan olmaz” dediğimi ise sekizinci bölümde.

Satıcıya sorulacak on bir soru

Bunları yazılı sorun. Sözlü “evet”ler, sözleşmede “kısmen” olarak çıkabiliyor.

1. Kod ve prompt’lar ne kadar saklanıyor? Sıfır saklama mümkün mü?
2. Eğitimde kullanılmayacağı sözleşmenin hangi maddesinde yazıyor? Alt yükleniciler için de geçerli mi?
3. Model hangi bölgede çalışıyor? Bölgeyi seçebiliyor muyuz?
4. Araç bizim geçidimize ya da modelimize yönlendirilebiliyor mu? O zaman hangi özellikler kapanıyor?
5. Modeliniz bizim veri merkezimizde çalışabiliyor mu? Genel kullanımda mı, önizlemede mi?
6. Hangi ayarlar merkezden kilitlenebiliyor? Kilit sunucuda mı uygulanıyor, istemcide mi?
7. Dosya yazma, komut ve MCP çağrıları merkezden kısıtlanabiliyor mu? Sadece onaylı MCP sunucularına izin verilebiliyor mu?
8. Ajanın ağ erişimi nasıl sınırlanıyor? Ajan kendi izin ayarlarını değiştirebiliyor mu?
9. Loglar hangi formatta, nasıl aktarılıyor, kaç gün saklanıyor?
10. Fiyatlama koltuk mu, kullanım mı? Kurum bazında harcama tavanı konabiliyor mu?
11. Sözleşme bittiğinde verilerimiz ve loglarımız nasıl iade ediliyor ya da siliniyor?

Dördüncüye “yönlendirilemiyor” cevabı gelirse, diğerlerinin cevabı ne olursa olsun altıncı bölümde anlatacağım geçidi kuramıyorsunuz demektir.

Sıradaki bölüm: yerel model mi, dış model mi? Aradaki farkın üç sebebi ve hangi işin hangi modele gittiği.

Kaynaklar: Claude Code issue #56694 (Mayıs 2026); OpenAI Codex yönetimli yapılandırma (requirements.toml) dokümantasyonu; Tenable (CurXecute ve MCPoison, CVE-2025-54135/54136; Cursor 1.3'te düzeltildi); The Hacker News ve Koi Security (ClawHub, 2 Şubat 2026); Semgrep ve Security Boulevard (postmark-mcp, Eylül 2025); arXiv 2605.17062 (paket adı halüsinasyonu, 2026); GitHub Blog (Copilot kullanım bazlı faturalandırma, 27 Nisan 2026); OpenAI Help Center (Codex rate card, Nisan 2026); GitHub Docs (Copilot on GHES, bağlantısız ortam önizlemesi); OpenAI (Dell ortaklığı, 18 Mayıs 2026); BenchLM, SWE-bench Verified (8 Ekim 2026); GitClear, The Maintainability Gap (2026).