Yerel Model mi, Dış Model mi?

Önceki bölümlerde kodun kurum dışına çıkmadığı bir kurulumu anlattım. Bunu kurarken en sık duyduğum soru şuydu: Kendi sunucularımızda çalışan yerel model, Claude ya da GPT gibi bulut üzerinden kullanılan modellerin ne kadar gerisinde kalıyor?

Biz bu soruya iki modeli de kullanarak cevap aradık. Hassas veri içerebilecek işlerde yalnızca yerel modeli kullandık; gereksinim dokümanı, teknik analiz ve kod bu sınıftaydı. Hassas veri içermeyen işlerde ise dış modelleri kullandık ve kaliteyi en üstte tuttuk.

Ayrımı bir ürüne ya da müşteriye göre değil, işin kendisine göre yaptık. Aynı ürünün içinde bile hassas veri içerebilecek işler de var, içermeyecek işler de. Hangisinin hangisi olduğuna işi en iyi bilen ekip karar verdi; model seçimi bu kararın arkasından geldi.

Fark nerede ortaya çıktı?

İlk denemede kolay yolu seçtik: Dış model için hazırladığımız prompt’ları ve bağlam yapısını olduğu gibi yerel modele verdik. Sonuç hayal kırıklığıydı. Dış modelin rahatça anladığı talimatları yerel model ya yanlış anlıyor ya da eksik yerine getiriyordu. Aynı iş için aldığımız sonuç, dış modelin çok gerisinde kaldı.

Burada durmadık. Prompt’ları yerel modele göre yeniden yazdık, bağlamı güçlendirdik, kod grafından gelen bilgiyi modele daha düzenli taşıdık. Yerel model dış modelin seviyesine gelmedi, ama aradaki fark belirgin biçimde kapandı ve sonuçlar kabul edilebilir bir seviyeye çıktı.

Yazılım geliştirmede de aynısını yaşadık. Dış modelleri rahatça kullanan geliştiriciler yerel modele geçince hem kalite düşüşü hem de aşağıda anlatacağım güven sorunu yaşadı. Kendi eklentimizi yazıp modele giden bağlamı kontrol etmeye ve kod grafını devreye sokmaya başlayınca kod geliştirmedeki kazanç belirgin biçimde arttı.

Benim için asıl ders şu oldu: Aynı model, kendisine göre hazırlanmış bağlam ve prompt’la bambaşka sonuç veriyor. Dış model için kurulmuş bir yapıyı yerel modele olduğu gibi vermek, farkı olduğundan büyük gösteriyor. Farkın nereden geldiğini üç başlıkta topladım.

Birinci sebep: model kalitesi

İlk tahmin “dış model daha zeki” idi. Bu doğru ve küçümsememek lazım. Ekim 2026’da SWE-bench Verified’da Claude ve GPT gibi en güçlü bulut modelleri %95–96 bandında. Tek bir GPU’ya sığan en iyi açık modeller %72–77 arasında; 400 milyar parametre sınıfındaki en büyük açık modeller %80–86’ya çıkıyor.

Bu modelleri gerçekten kullananların anlattıkları tabloyu daha somut çiziyor. Yerel modeller günlük kodlama işinin yaklaşık %70’ini karşılıyor ve tek dosyalı işlerde dış modellere yakın sonuç veriyor. Çok dosyalı işlerde ise belirgin biçimde geride kalıyorlar. Sık duyulan benzetme şu: Yerel model, yakından yönlendirilmesi gereken bir junior; dış model, mimariyi sizinle birlikte düşünen bir senior.

Ama bu farkın nasıl dağıldığı önemli. Test iskeleti, DTO, dönüşüm kodu, dokümantasyon gibi basit işlerde yerel model neredeyse aynı sonucu veriyor. Fark karmaşık muhakemede açılıyor: çok adımlı bir refactor, belirsiz bir gereksinimden tasarım çıkarmak, “neden?” sorusu. Ve bu işler toplam hacmin küçük bir kısmı.

Bu dağılım kararımızı kolaylaştırdı. Hassas işlerin büyük kısmında yerel model yetiyordu. Farkın açıldığı karmaşık işlerde ise yereldeki en büyük modele geçtik ya da işi küçük adımlara bölüp kod grafıyla destekledik. Beşinci bölümde anlatacağım katmanlı kullanım modelinin kökü bu.

İkinci sebep: bağlam ve prompt

Dış modellerin bağlam pencereleri büyük ve cevapları hızlı. Yerelde pencereyi büyüttükçe GPU belleği ve gecikme de büyüyor. Geliştirici de modele daha az bağlam verip daha çok tur atıyor. Her tur zaman demek, her tur da modelin bir şeyi unutma ihtimali.

Buna cevabım model değil mimari oldu. İkinci ve üçüncü bölümde anlattığım bağlam katmanı ve kod grafı, modele küçük ama doğru bağlamı veriyor. Pencere küçük kalsa da içine giren şey isabetli olunca fark daralıyor. Büyük pencere kötü bağlamın telafisi; iyi bağlam ise büyük pencereye olan ihtiyacı azaltıyor.

Prompt’ta da durum aynı. Dış model kısa ve gevşek bir talimattan ne istendiğini çıkarabiliyor. Yerel model ise daha açık, adım adım ve örnekli bir talimat istiyor. Dış model için yazılmış prompt’ları yerel modele olduğu gibi verdiğimizde kaybettiğimiz kalitenin önemli bir kısmını, prompt’ları yeniden yazarak geri aldık.

Üçüncü sebep: güven

Beklemediğim, ama belki de en büyüğü olan sebep bu. Geliştiriciler dış modele daha çok güveniyor; çünkü onu zaten dışarıda kullanıyorlar ve arkasında bilinen bir marka var. Yerel modele ise “kurum içi, kesin daha kötüdür” önyargısıyla yaklaşıyorlar. Daha az deniyorlar, ilk hatada bırakıyorlar.

Aynı iş, aynı kalite, farklı kullanım yoğunluğu. Ölçümde bu bir verim farkı gibi görünüyor, ama aslında bir güven farkı.

Çözümü de teknik değil. Yerel modelin iyi yaptığı işleri gösteren örnekler, eşli çalışma oturumları ve bootcamp’ler. Birkaç ay sonra kullanım dengelenince ölçülen fark da küçülüyor.

Sektör verisi de aynı yeri gösteriyor. Sonar’ın Ocak 2026’da 1.100’den fazla geliştiriciyle yaptığı ankette katılımcıların %96’sı AI çıktısına tam güvenmediğini söylüyor; ama yalnızca %48’i commit etmeden önce her zaman kontrol ediyor. Ve %35’i AI araçlarını iş hesabı yerine kişisel hesabıyla kullanıyor.

Bu son rakam, yerel model tartışmasının gizli tarafı. Sadece yerel modele izin veren bir kurumda, yerel model yetersiz bulunursa geliştirici kişisel hesabıyla dış modele gidebiliyor ve kodu da yanında götürüyor. Bu yüzden yerel modelin benimsenmesi bizim için bir güvenlik meselesiydi: Yerel model iş görmezse, yasak kâğıt üzerinde kalıyor.

Hangi iş hangi modelde

Üç sebebi birleştirince karar üç soruyla veriliyor ve soruların sırası önemli.

1. Hassasiyet, eleyen soru: İş kurumun hassas verisine dokunuyor mu? Kod, müşteri verisi, gereksinim ve iç dokümanlar bizde bu sınıftaydı. Dokunuyorsa dış model tartışma dışı; iş ne olursa olsun yerel. Dokunmuyorsa dış model bir aday.
2. İş türü, seçen soru: Basit bir üretim mi, karmaşık bir muhakeme mi? Basitse küçük model yeter. Karmaşıksa büyük model; hassas işte yereldeki en büyüğü, hassas olmayan işte dış model.
3. Gecikme, ayarlayan soru: Satır satır tamamlama mı bekleniyor? Küçük ve hızlı yerel model. Bir doküman mı bekleniyor? Büyük model, bir dakika beklemek sorun değil.

Bu üç soru bir dakikada cevaplanıyor ve “hangi model?” sorusunu bir politikaya dönüştürüyor. Aşağıda yaygın iş türlerine uygulanmış hali var: bir sütunda hassas veri içerebilecek işler, diğerinde içermeyecek işler.

Tablonun tek ilkesi şu: Sınır aracın cinsine göre değil, verinin cinsine göre çiziliyor.

Sınırın bulanıklaştığı yer

Kodun ve müşteri verisinin hassas olduğu herkesin kabul ettiği bir şey. Tartışma, kod olmayan ama kodun dışında da kalmayan bilgide başlıyor.

Gereksinim dokümanı kod değil. Ama müşterinin ürününü, iş kurallarını ve yakında çıkacak özellikleri anlatıyor. İyi bir teknik analiz ise mevcut sistemde neyin etkilendiğini de söylüyor; bu bilgi kod grafından geliyor: sınıf adları, metot imzaları, tablo adları, toplu işler. Bu bir kod değil, ama kodun haritası. Bir kurumun tablo ve servis adları dışarı çıktığında sistemin iskeleti de çıkmış oluyor.

Biz ikisini de hassas saydık ve yerelde tuttuk. Kurumunuz bunları daha gevşek sınıflandırabilir; ama bu kararı bilinçli verin, “kod değil” diye varsayılan olarak değil.

Kurum bu farkı kabul etmeli mi?

Bu artık yönetimin sorusu. Yerel model demek, en iyi modelin gerisinde kalmayı kabul etmek demek. Ama hassas verinin dışarı çıkamadığı bir kurumda zaten başka seçenek yok. O yüzden soru “farkı kabul etmek” değil, “farkı küçültmek”.

Üç sebepten ikisi, bağlam ve güven, model değişmeden kapanıyor. Üçüncüsü, yani karmaşık muhakeme için, 2026’da yeni ama henüz dar bir kapı açılıyor: satıcının modelinin kurumun kendi veri merkezinde çalışması. Bu seçenek bugün sınırlı ve pahalı. Ama karmaşık işlerin azınlıkta olduğunu bilince, o azınlık için pahalı bir modeli içeride çalıştırmak hesaplanabilir bir karara dönüşüyor.

2024’ün ikilemi “yerel mi, dış mı?” idi. 2026’nın sorusu ise başka: Hangi iş için hangi model kullanılacak, o model nerede çalışacak ve ona göre nasıl optimize edilecek? Bizim tecrübemizde farkın önemli bir kısmı modelden değil, bu son sorudan geldi.

Sıradaki bölüm kural kitabı: Bu tabloyu kim uyguluyor, limitler nasıl konuyor, bir araç yetmediğinde ne oluyor? Örnek bir politika dosyasıyla.

Kaynaklar: BenchLM, SWE-bench Verified (8 Ekim 2026); Tom Tunguz, yerel kodlama modelleri (16 Haziran 2026); byteiota, yerel modeller ve Claude karşılaştırması (16 Haziran 2026); Sonar, State of Code geliştirici anketi (8 Ocak 2026).