Codex Benzeri Bir AI Geliştirme Deneyimi Yerel Modellerle Kurulabilir mi?

Bir yerel model sohbet ekranında iyi kod örnekleri ürettiğinde, dosyaları okuyup test çalıştıran ve değişiklik yapan bir geliştirme deneyiminin de kendiliğinden oluşacağı düşünülebiliyor. Denemede model güçlüydü, fakat masaüstü araç terminal çağrısını doğru yönetmiyor, çalışma dizinini ayırmıyor ve uzun görevlerde bağlamı kaybediyordu. Eksik parça model değil, agent sisteminin geri kalan katmanlarıydı.

17-20 Temmuz 2026 arasında Ollama, yönlendirilmiş API seçenekleri ve çeşitli masaüstü geliştirme arayüzlerini değerlendirirken modeli, agent runtime’ı, editörü ve araç izinlerini ayrı test ettik. Hedef, sınırsız komut çalıştıran bir otomasyon değildi. Geliştiricinin kontrolünü koruyan, değişiklikleri görünür kılan ve yerel modelin sınırlarını dürüstçe yöneten güvenli bir yardımcı deneyimiydi.

Sorunun ortaya çıkışı

Kullanıcı beklentisi doğal dille görev vermek, agent’ın depo yapısını anlaması, ilgili dosyaları değiştirmesi ve test sonucunu yorumlamasıydı. İlk kurulum yalnızca sohbet arayüzünü farklı bir LLM uç noktasına bağlamıştı. Model cevap üretiyor, ancak dosya araçları ve terminal protokolü uygulama tarafından sağlanmadığı için gerçek çalışma alanında işlem yapamıyordu. “Model desteklemiyor” teşhisi bu nedenle eksikti.

Başka bir istemci araç çağırabiliyor fakat modelin beklediği şema ile runtime’ın sunduğu şema uyuşmuyordu. Komut sonucunun kesilmesi, dosya kodlaması ve bağlam sınırı da kaliteyi etkiliyordu. Aynı model iki arayüzde farklı başarı gösterdi. Bu gözlem, değerlendirmeyi yalnızca benchmark puanından çıkarıp uçtan uca görev tamamlama ve güvenlik davranışına taşımamızı sağladı.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım tool calling etiketi olan her modelin bütün agent’larla uyumlu çalışacağıydı. Araç şeması, sohbet şablonu, durdurma belirteçleri ve yapılandırılmış çıktı davranışı farklı olabilir. İkinci varsayım büyük context window değerinin tüm depoyu güvenilir biçimde anlamaya yeteceğiydi. Gereksiz dosyalar bağlamı doldurur, ilgili bilgi gürültü içinde kaybolur ve maliyet ya da bellek tüketimi artar.

Başarı, birkaç etkileyici kod önerisiyle ölçülüyordu. Agent’ın yanlış dosyayı değiştirmesi, testi hiç çalıştırmadan tamamlandı demesi veya komut hatasını görmezden gelmesi değerlendirmede yer almıyordu. Ayrıca tam disk ve terminal erişiminin kullanım kolaylığı sağladığı varsayıldı. Oysa model hatası, kötü niyetli depo içeriği veya yanlış anlaşılmış talep bu geniş yetkiyi operasyonel riske dönüştürebilir.

Teknik analiz

Mimariyi dört parçaya ayırdık: LLM backend metin ve araç kararını üretir; agent runtime döngüyü, bağlamı ve araç sonuçlarını yönetir; IDE veya masaüstü arayüzü farkları gösterir ve onay alır; sandbox ise dosya, süreç ve ağ sınırını uygular. Bunlara model yönlendirme, sır saklama ve gözlem katmanı eklendi. Her arızanın hangi sınırda oluştuğu kayıtlarla incelendi.

Temsilî görev setinde tek dosya düzeltmesi, çok dosyalı yeniden düzenleme, test hatası analizi ve yalnızca inceleme görevleri kullanıldı. Başarı; doğru değişiklik, gereksiz dosya sayısı, test sonucu, kullanıcı onayı ve geri alınabilirlik ile ölçüldü. Modelin hızına ek olarak ilk planın kalitesi, araç çağrısı doğruluğu ve hatadan toparlanma değerlendirildi. Gizli anahtar içeren gerçek depolar test kapsamına alınmadı.

# Agent için örnek güvenli çalışma yaklaşımı
# 1. Temiz ve ayrı bir çalışma dalı oluşturun.
git switch -c ai-deneme

# 2. Değişiklikleri çalıştırmadan önce inceleyin.
git diff --check
git diff

# 3. Yalnızca projenin tanımlı test komutunu kullanıcı onayıyla çalıştırın.
# Agent'a yönetici yetkisi veya çalışma alanı dışı yazma izni vermeyin.

Uygulanan çözüm veya önerilen mimari

Yerel Ollama backend’i güvenilir bir agent runtime’a bağlandı ve çalışma alanı proje diziniyle sınırlandı. Varsayılan mod salt okuma ve planlama oldu; dosya değişikliği açık yetki, terminal komutları ise komut sınıfına göre onay istedi. Değişiklikler ayrı dalda ve diff üzerinden gösterildi. Test sonucu alınmadan agent’ın tamamlandı iddiası kabul edilmedi; başarısız test kullanıcıya eksiksiz raporlandı.

Model profilleri görev türüne göre ayrıldı. Hızlı gezinme ve küçük düzenlemeler yerel modelde, kapasiteyi aşan görevler ise veri sınıfı uygunsa önceden onaylı uzak sağlayıcıda çalıştırılabildi. Yönlendirme kararı kullanıcıya görünür tutuldu. Sistem istemleri, araç şemaları ve model sürümleri yapılandırma olarak versiyonlandı; böylece davranış değişikliği izlenebilir hale geldi.

Alternatifler ve karar gerekçesi

IDE eklentileri geliştiricinin mevcut akışına yakın ve fark incelemesinde güçlüdür; bağımsız masaüstü agent’lar daha geniş görev akışı sunabilir. Komut satırı agent’ları otomasyona uygundur fakat izinlerin görünürlüğü kullanıcı deneyimine bağlıdır. Seçim model puanından önce ekibin editör standardı, onay ihtiyacı, platform desteği ve günlük yönetim gereksinimine göre yapılmalıdır.

Tam yerel çözüm kodun ortamdan çıkmamasını kolaylaştırır, ancak küçük modeller karmaşık görevlerde daha fazla yönlendirme isteyebilir. Uzak API yüksek kapasite sağlayabilir; veri işleme, anahtar güvenliği, kota ve maliyet yönetimi gerektirir. Hibrit seçenek esnektir fakat yanlış yönlendirme riski taşır. Bu nedenle depo veya dosya sınıfına bağlı açık politika, kullanıcı göstergesi ve varsayılan yerel tercih benimsendi.

Güvenlik ve operasyonel riskler

Agent’ın okuduğu depo içeriği güvenilir komut değildir. Dokümana veya kaynak dosyaya yerleştirilmiş yönlendirmeler modeli yetki genişletmeye ikna edebilir; runtime sistem politikası bunları veri olarak ele almalıdır. Gizli dosyalar, kimlik depoları ve çalışma alanı dışındaki dizinler varsayılan olarak erişim dışı bırakılmalı; ağ çıkışı sadece görev için gerekli, onaylı hedeflerle sınırlandırılmalıdır.

Otomatik değişiklikler lisans, güvenlik, iş mantığı ve bağımlılık riski taşır. Kod incelemesi, statik analiz ve testler insan sorumluluğunun yerini almaz. Agent kayıtlarında kaynak kodun veya sırların gereksiz kopyaları tutulmamalıdır. Model, eklenti ve araç güncellemeleri davranışı değiştirebildiğinden kontrollü yayımlanmalı; olay halinde oturum, değişiklik ve onay izi incelenebilir olmalıdır.

Çıkarılan Dersler

Kontrol Listesi