Yerel Yapay Zekâ ile Yazılım Geliştirme: 7 LLM Modeli Testi

Yerel Yapay Zekâ ile Yazılım Geliştirme: Ollama ve Kilo Code Üzerinde 7 LLM Modelini Test Ettim

Alt başlık: 96 GB RAM ve RTX 4090 Laptop GPU ile gerçek bir Laravel projesinde Qwen, Nemotron ve Gemma modellerinin hızını, kaynak kod analizi yeteneklerini ve teknik doğruluğunu karşılaştırdım.

Yazar: Burhan Aksoy
Yayın tarihi: 25 Ekim 2026
Kategori: Yapay Zekâ / Yazılım Geliştirme

Giriş

Yapay zekâ destekli yazılım geliştirme araçları giderek yaygınlaşıyor. Ancak bu araçların önemli bir bölümü bulut tabanlı API servislerine, token kredilerine veya abonelik modellerine dayanıyor.

Ben ise farklı bir yaklaşımı denemek istedim:

Tamamen kendi bilgisayarımda çalışan, ücretli LLM API hizmetlerine ihtiyaç duymayan ve gerçek bir yazılım projesini geliştirebilen bir yapay zekâ ortamı oluşturmak.

Bu amaçla Ollama, Visual Studio Code ve Kilo Code kullanarak yerel bir geliştirme ortamı hazırladım.

Testleri örnek bir uygulama üzerinde değil, geliştirmekte olduğum IT Engineering Knowledge Hub projesinde gerçekleştirdim.

Bu proje, burhanaksoy.com üzerinde yayımlanması planlanan Laravel tabanlı bir teknik bilgi ve içerik yönetim platformu. Active Directory, Exchange Server, SCCM, VMware, Hyper-V, Windows Server ve benzeri kurumsal BT teknolojileri üzerine içerikler yayımlamak için geliştiriliyor.

Ancak geliştirme sürecinde önemli bir soruyla karşılaştım:

Hangi yerel yapay zekâ modeli, gerçek kaynak kodu daha doğru anlayabiliyor ve yazılım geliştirme sürecinde daha güvenilir sonuçlar üretiyor?

Bu soruya yanıt bulmak için yedi farklı modeli test ettim.

1. Test Ortamı ve Donanım

Testleri Windows üzerinde çalışan kendi bilgisayarımda gerçekleştirdim.

Kilo Code'u Ollama'nın yerel OpenAI-compatible API arayüzüne bağladım:

http://127.0.0.1:11434/v1

Bu mimaride model çıkarımı yerel bilgisayarda gerçekleşiyor. Testler sırasında ücretli bir bulut LLM API'si kullanmam gerekmedi.

Bununla birlikte yerel çalışmanın ücretsiz API kullanımından farklı bir maliyeti var: donanım, elektrik tüketimi, RAM, VRAM, disk alanı ve zaman.

Özellikle büyük modellerde bu kaynakların verimli kullanılması kritik önem taşıyor.

2. Testin Amacı

Model karşılaştırmasında yalnızca cevap üretme hızını ölçmek istemedim.

Asıl hedefim modellerin aşağıdaki yeteneklerini değerlendirmekti:

• Gerçek Laravel projesini ve ilgili dosyaları okuyabilmeleri
• Mevcut kaynak kodu doğru yorumlamaları
• Hatalı veya güncelliğini kaybetmiş teknik raporları sorgulamaları
• Gerçek hataları varsayımlardan ayırmaları
• Kod satırlarına dayanan teknik bulgular üretmeleri
• Mümkün olan en küçük düzeltmeyi önermeleri
• Salt-okunur analiz talimatına uymaları
• Donanım kaynaklarını verimli kullanmaları

Bunun için projede kayıtlı BUG-0052 TinyMCE editör başlatma sorunu önemli bir değerlendirme konusu oldu.

Önceki geliştirme notlarında hatanın HTML standards mode, TinyMCE GPL lisansı, JavaScript başlatma sırası veya tarayıcı konsol hatalarıyla ilişkili olabileceği belirtiliyordu.

Modellerden bu olasılıkları mevcut kaynak kodla karşılaştırmalarını istedim.

3. Kullandığım Gerçek Test Promptu

BUG-0052 odaklı testte kullandığım promptu aşağıda aynen paylaşıyorum.

Mevcut Laravel projesindeki BUG-0052 TinyMCE hatasını analiz et.

Önce AGENTS.md, PROJECT_RULES.md, MODEL_DEVIR_RAPORU.md, PROJECT_HANDOFF.md ve BUG_TRACKER.md dosyalarını oku.

Ardından TinyMCE'nin neden başlatılamadığını kaynak kod üzerinden araştır.

Özellikle şu ihtimalleri değerlendir:

• HTML DOCTYPE eksikliği
• TinyMCE GPL lisans yapılandırması
• JavaScript başlatma sırası
• Tarayıcı konsol hataları

Bana şu bilgileri raporla:

1. Gerçek kök neden veya henüz doğrulanmamış olasılıklar
2. Hatanın bulunduğu dosyalar ve ilgili kodlar
3. Önerilen en küçük düzeltme
4. Düzeltmenin nasıl test edileceği

Henüz kod değiştirme. Yalnızca inceleme yap.

Bütün açıklamaların Türkçe olsun. Kanıt bulamadığın bir sorunu kesin neden olarak gösterme.

Bu promptta özellikle iki kurala önem verdim:

Birincisi: Model, önceki ajanların teşhislerini doğru kabul etmeden kaynak kodu incelemeliydi.

İkincisi: Kanıt bulamadığı bir ihtimali kesin kök neden olarak raporlamamalıydı.

Metodoloji hakkında önemli not

Çalışma sırasında farklı oturumlarda daha geniş mimari analiz promptları da kullanıldı. Bu nedenle aşağıdaki yedi modelin tüm süreleri ve raporları, tamamen aynı prompt ve ayarlarla yürütülmüş tek bir kontrollü benchmark olarak değerlendirilmemelidir.

Bu çalışma, kendi geliştirme ortamımda elde ettiğim pratik model karşılaştırmasıdır.

Ölçülen sürelerin tamamına modelin yüklenmesi ve ilk yanıtı üretmesi için geçen süre de dahildir.

4. Test Edilen Yedi Model

Karşılaştırmada aşağıdaki modelleri kullandım:

Burada özellikle farklı boyutlarda modelleri denemek istedim.

Çünkü büyük bir modelin daha fazla parametreye sahip olması, gerçek projelerde mutlaka daha doğru sonuç vereceği anlamına gelmiyor.

5. Performans Sonuçları

Testlerde ölçtüğüm toplam süreler şöyleydi:

Bu tablonun en önemli sonucu, hız ile teknik doğruluğun aynı şey olmamasıydı.

Gemma en hızlı tamamlanan model oldu. Ancak raporu, daha ayrıntılı analiz yapan bazı modellere kıyasla daha yüzeysel kaldı.

Qwen3.6 yaklaşık beş dakikada oldukça somut teknik bulgular üretti.

Nemotron Super ise 30 dakika çalışmasına rağmen kaynak kodla çelişen kritik bir teşhis sundu.

Bu durum, yalnızca model boyutuna veya analiz süresine göre seçim yapmanın yanlış olabileceğini gösterdi.

6. En Kritik Bulgu: TinyMCE DOCTYPE Hatası

Karşılaştırmanın en öğretici bölümü BUG-0052 incelemesiydi.

TinyMCE, düzgün çalışabilmek için tarayıcının standards mode kullanmasını gerektirebiliyor.

Önceki geliştirme raporlarında sorunun DOCTYPE eksikliğinden kaynaklanabileceği belirtilmişti.

Nemotron Super 120B, yaklaşık 30 dakika süren analizinin sonunda şu sonuca ulaştı:

“Gerçek kök neden DOCTYPE eksikliği.”

Model, aşağıdaki satırın resources/views/admin/layouts/app.blade.php dosyasına eklenmesini önerdi:

<!DOCTYPE html>

Ancak kaynak kodu bağımsız olarak kontrol ettiğimde ilgili dosyanın zaten şu şekilde başladığını gördüm:

<!DOCTYPE html>
<html>
<head>

Yani modelin önerdiği düzeltme mevcut kodda zaten uygulanmıştı.

Bu nedenle DOCTYPE eksikliği teşhisi, incelenen kaynak dosyanın mevcut hâliyle çelişiyordu.

Burada dikkat edilmesi gereken bir ayrıntı daha var: Blade dosyasında DOCTYPE bulunması, tarayıcıya gönderilen her HTML yanıtının mutlaka standards mode'da işlendiğini tek başına kanıtlamaz.

Gerçek tarayıcı çıktısının ve document.compatMode değerinin ayrıca kontrol edilmesi gerekir.

Ancak kaynak dosyada açıkça mevcut olan bir satırı eksik göstermek, teknik analiz açısından önemli bir hatadır.

Çıkardığım ders: Yapay zekâ modelinin önceki raporlara güvenmesi değil, mevcut kaynak kodu doğrulaması gerekir.

7. TinyMCE GPL Lisansı ve Görsel Yükleme Yapılandırması

İnceleme sırasında TinyMCE lisans yapılandırması da değerlendirildi.

Projede kullanılan TinyMCE başlatma kodunda şu ayar zaten mevcuttu:

license_key: 'GPL'

Ayrıca görsel yükleme tarafında images_upload_handler kullanılıyordu.

Bazı model raporlarında lisans anahtarının eksik olduğu veya images_upload_url kullanımının sorun oluşturduğu yönünde iddialar yer aldı.

Ancak incelenen posts oluşturma ve düzenleme dosyalarında bu iddiaları destekleyen bir durum bulunmuyordu.

Burada önemli olan, bir yapılandırmanın yalnızca var olup olmadığını kontrol etmek değil; kullanılan TinyMCE sürümü, lisans koşulları ve uygulama davranışıyla uyumunu da değerlendirmektir.

Örneğin images_upload_handler kullanılması tek başına görsel yüklemenin sorunsuz çalıştığını kanıtlamaz.

Bunun için gerçek yükleme işleminin ve sunucu yanıtlarının test edilmesi gerekir.

8. Qwen3.6 Cline 128K Neden Öne Çıktı?

Qwen3.6 Cline 128K, testlerde en dikkat çekici sonuçlardan birini verdi.

Yaklaşık beş dakikalık analizde yalnızca BUG-0052 üzerine yorum yapmakla kalmadı, projenin farklı modüllerinde kaynak koddan doğrulanabilen sorunlar tespit etti.

Bozuk HTML ve Blade yapıları

Bazı yönetim paneli formlarında hatalı HTML etiketleri ve bozulmuş alan isimleri bulunuyordu.

Örneğin vaka çalışmaları ve script düzenleme ekranlarında sorunlu işaretleme yapıları tespit edildi.

Bu tür hatalar tarayıcıdaki DOM yapısını bozabilir ve JavaScript bileşenlerinin beklenmedik davranmasına neden olabilir.

Tamamlanmamış Tiptap geçişi

Projede bazı sayfalarda TinyMCE kullanılırken bazı sayfalarda eski Tiptap editörüne ait JavaScript kodları bulunuyordu.

Bu durum, editör altyapısının modüller arasında tam olarak standartlaştırılmadığını gösteriyordu.

Eski editör kodlarının temizlenmesi bakım kolaylığı açısından önemliydi.

Ancak bu kodların BUG-0052'nin doğrudan nedeni olduğu henüz kanıtlanmış değildi.

Route model binding tutarsızlığı

Post düzenleme formunda ID kullanımı ile slug tabanlı route model binding davranışı arasında uyumsuzluk oluşturabilecek bir yapı tespit edildi.

Bu tür tutarsızlıklar bazı güncelleme işlemlerinde 404 hatalarına neden olabilir.

Bu bulgular, Qwen3.6'nın kaynak kodu yalnızca özetlemek yerine gerçek teknik problemleri tespit edebildiğini gösterdi.

Bununla birlikte bu test, modelin söz konusu hataları başarıyla düzelttiğini henüz göstermiyordu.

9. Qwen3.5 122B Modelinin Sonuçları

Qwen3.5 122B-A10B modelinin yaklaşık 81 GB disk boyutu vardı.

Analizini 13 dakika 10 saniyede tamamladı.

Bu modelin en olumlu tarafı, önceki ajanların bazı yanlış teşhislerini sorgulamasıydı.

Özellikle şu noktaları doğru tespit etti:

• DOCTYPE mevcut.
• GPL lisans yapılandırması mevcut.
• Posts dosyalarında images_upload_handler kullanılıyor.
• Playwright testlerinde hatalı veya şüpheli selector'lar bulunuyor.

Ancak Qwen3.6'nın bulduğu bazı bozuk Blade ve JavaScript yapılarını aynı kapsamda raporlamadı.

Ayrıca büyük model boyutu nedeniyle bellek tüketimi yüksekti.

Bu nedenle günlük geliştirmede ana model olarak değil, daha kapsamlı ikinci görüş gereken durumlarda kullanılabilecek bir alternatif olarak değerlendirdim.

10. Nemotron Lightning ve Nemotron Super Karşılaştırması

NVIDIA Nemotron ailesinden iki farklı modeli denedim.

Nemotron 3.5 Lightning, analizini 5 dakika 15 saniyede tamamladı.

Nemotron 3 Super 120B ise 30 dakikada tamamladı.

Super modelinin çalışması sırasında sistem belleği yaklaşık 88 GB seviyesine ulaştı.

96 GB RAM bulunan bilgisayarda bu, yaklaşık %92 bellek kullanımına karşılık geliyor.

Test sırasında CPU ve GPU kullanımını da izledim. Ancak anlık ekran görüntüleri, modelin bütün çalışma süresindeki CPU/GPU dağılımını kesin olarak göstermiyor.

Super'ın temel dezavantajı yalnızca yavaş olması değildi.

Asıl sorun, 30 dakikalık analiz sonunda mevcut kaynak kodla çelişen DOCTYPE teşhisini kesin sonuç olarak sunmasıydı.

Bu testte Lightning, hız ve pratik kullanılabilirlik açısından daha dengeli bir seçenek oldu.

11. Yapay Zekâ Ajanlarında Talimatlara Uyum

Karşılaştırmada dikkatimi çeken bir diğer konu, modellerin verilen sınırları ne kadar koruyabildiğiydi.

Analiz aşamasında temel kuralım şuydu:

Kod değiştirilmemeli, test çalıştırılmamalı ve herhangi bir düzeltme onay alınmadan uygulanmamalı.

Ancak Qwen3-Coder-Next Q8 denemelerinden birinde, açık talimata rağmen testlerin çalıştırıldığı görüldü.

Kilo Code arayüzünde dosya değişiklikleri de görüntülendi. Bununla birlikte arayüzde görülen tüm değişikliklerin doğrudan bu model tarafından oluşturulduğunu kesin olarak doğrulamak mümkün değildi.

Bu deneyim önemli bir güvenlik ve operasyon dersi ortaya koydu:

Bir yapay zekâ modelinin yerel çalışması, dosya sisteminde yaptığı işlemlerin otomatik olarak güvenli olduğu anlamına gelmez.

Bu nedenle geliştirme sürecinde Git kullanımı, değişiklik incelemesi, araç izinlerinin sınırlandırılması ve kritik işlemlerden önce onay alınması önem taşıyor.

12. Modellerin Genel Değerlendirmesi

Testler sonunda modelleri yalnızca sürelerine göre değil, kaynak kod analizi ve talimatlara uyum açısından da değerlendirdim.

Bu değerlendirmede Qwen3.6 Cline 128K, analiz kalitesi ve tamamlanma süresi arasında en iyi dengeyi sağladı.

Ancak burada önemli bir sınırlama bulunuyor: İncelenen projenin önceki geliştirme aşamalarında da yapay zekâ ajanları kullanıldı.

Dolayısıyla mevcut hataların tespit edilmesi, aynı modellerin başlangıçta bu hataları üretmeyeceğini kanıtlamıyor.

Gerçek geliştirme kalitesini ölçmek için modellerin yaptığı kod değişikliklerini ve test sonuçlarını ayrıca değerlendirmek gerekiyor.

13. Hangi Modelleri Kullanma Kararı Aldım?

Testlerin ardından geliştirme ortamımı sadeleştirdim.

Kullanım için dört model bıraktım:

Diğer modelleri günlük geliştirme ortamımdan çıkarmaya karar verdim.

Böylece farklı görevler için sürekli model değiştirmek yerine, daha kontrollü ve öngörülebilir bir çalışma düzeni oluşturmayı hedefledim.

14. Sonraki Aşama: Gerçek Kod Geliştirme

Bu karşılaştırma sonrasında model araştırma aşamasını tamamlayıp gerçek geliştirme sürecine geçme kararı aldım.

Ana geliştirme modeli olarak Qwen3.6 Cline 128K ile devam edeceğim.

İlk hedefim BUG-0052 TinyMCE sorununun gerçek kök nedenini doğrulamak.

Bu süreçte şu yöntemi uygulamayı planlıyorum:

1. Mevcut kaynak kod ve Git durumunu kayıt altına almak
2. Tarayıcı konsol hatalarını ve gerçek HTML çıktısını incelemek
3. Kanıtlanan kök neden için en küçük düzeltmeyi uygulamak
4. PHPUnit ve Playwright testlerini çalıştırmak
5. Değiştirilen dosyaları ve test sonuçlarını kontrol etmek
6. Gerekirse Nemotron Lightning ile bağımsız kod incelemesi yapmak

Bundan sonraki aşamada modelin ürettiği raporun uzunluğundan çok, gerçekten çalışan, güvenli ve sürdürülebilir kod üretip üretmediğini değerlendireceğim.

15. Sonuç: En Büyük Model, En İyi Model Değil

Yedi farklı yerel yapay zekâ modelini test ettikten sonra ulaştığım en önemli sonuç şu oldu:

Yazılım geliştirmede model seçimi yalnızca parametre sayısına, model dosyasının boyutuna veya cevap hızına göre yapılmamalı.

Bir modelin mevcut kodu doğru okuması, hatalı varsayımları fark etmesi, teknik iddialarını kanıtlaması ve verilen talimatlara uyması çok daha önemli.

Özellikle Nemotron Super örneği, büyük modellerin de kaynak kodla çelişen sonuçlar üretebildiğini gösterdi.

Qwen3.6 Cline 128K ise daha kısa sürede doğrulanabilir teknik bulgular üreterek benim geliştirme ortamım için en uygun aday oldu.

Bununla birlikte bu çalışma bir analiz karşılaştırmasıydı. Modellerin gerçek kod yazma, hata düzeltme ve test başarısı sonraki geliştirme aşamasında ayrıca değerlendirilecek.

Son söz: Yapay zekâ yazılım geliştirmeyi hızlandırabilir; ancak doğru sonuç için kaynak kod doğrulaması, Git disiplini, testler ve insan denetimi hâlâ vazgeçilmez.

Burhan Aksoy
IT Engineering Knowledge Hub
https://burhanaksoy.com

Bu makale kişisel geliştirme ortamımda gerçekleştirdiğim deneyleri ve gözlemleri aktarmaktadır. Sonuçlar kullanılan donanım, model kuantizasyonu, context ayarları, ajan davranışı ve proje durumuna göre değişebilir.