En iyi Büyük Dil Modellerini (LLM's) 10 yazılım geliştirme görevinde bir ajan tabanlı CLI aracı kullanarak değerlendirdik. Her model için hem API hem de UI katmanlarında ~3.500 otomatik doğrulama adımı çalıştırdık.
A-CODE-LLM Bench sonuçları
Her takma ad 10 görevde 3 kez çalıştırıldı (takma ad başına 30 örnek, yineleme başına 300 hücre). Daha fazla ayrıntı için metodolojiye bakın.
- Sonnet ajan tabanlı kodlamada Opus'tan daha yüksek puan alıyor. Sonnet 5 (0.772) ve Sonnet 4.6 (0.748), Opus 4.8 (0.702) dahil tüm Opus varyantlarını geride bıraktı. Anthropic'in en iyi kodlama modeli amiral gemisi Opus değil, orta seviye Sonnet'tir.
- Sonnet 5'in üstünlüğü görev uzunluğuyla birlikte artıyor. 10 görevli yapı değerlendirmesinde en yüksek backend puanı (0.701) ve 125 araç çağrısıyla zirvede yer alırken, basit temel görevde yalnızca 9 çağrı kullanıyor. Avantaj kısa görevlerde değil, uzun, otonom yapılarda ortaya çıkıyor.
- Frontend puanları yüksek kümeleniyor, bu yüzden sıralamayı backend belirliyor. İlk sekiz modelin tümü frontend'de 0.79 ile 0.96 arasında puan alıyor. Claude Haiku 4.5 çalışan bir frontend'e (0.731) sahip ancak backend puanı 0.277, bu da onu 0.413 ile sınırlandırıyor; GPT 5.5 thinking güçlü bir backend'e (0.620) sahip ancak frontend puanı 0.542.
- Model seviyesi kodlama yeteneğini öngörmez. Orta seviye Sonnet, tüm varyantlarda amiral gemisi Opus'tan daha yüksek puan alıyor; dolayısıyla bir modeli ajan tabanlı çalışma için ayarlamak, boyutundan veya fiyat seviyesinden daha önemlidir.
- Mevcut LLM'ler için zor kısım UI değil, backend mantığıdır. Liderler arasında frontend neredeyse çözülmüş durumda (ilk sekiz 0.79 ile 0.96 arasında) ve sıralama neredeyse tamamen backend tarafından belirleniyor; burada puanlar 0.70'ten 0.23'e kadar yayılıyor.
Maliyet ve başarı karşılaştırması
- Maliyet ve puan ilişkisizdir. En pahalı model olan Opus 4.7, hücre başına $3.08 ile 0.610 puan alırken, $1.33 ile Sonnet 4.6'nın altında kalıyor. Daha fazla harcamak puanı yükseltmiyor.
- Sonnet 4.6 neredeyse aynı puan için Sonnet 5'ten daha ucuza mal oluyor: 0.748 puan $1.33 iken, 0.772 puan $2.23. Ekstra 0.024 puan, hücre başına $0.90 daha fazlaya mal oluyor.
- Her Opus varyantı, daha düşük veya eşit bir puan için Sonnet'ten daha pahalıdır.
- En iyi fiyat-performans: Kimi K2.7 Code, $0.70 ile 0.60 üzerindeki en ucuz modeldir. Gemini 3.5 Flash thinking, $1.30 ile 0.625 puan alarak Sonnet'in fiyatına eşleşirken tüm Opus modellerini geride bırakıyor.
- Fiyat, ajan tabanlı kodlama için bir kalite sinyali değildir. Maliyet, bir modelin bu değerlendirmede sunduğu puanı değil, satıcı konumlandırmasını yansıtır; bu nedenle daha yüksek bir fiyat daha iyi bir ajan tabanlı model anlamına gelmez.
Görev tamamlama süresi ve başarı karşılaştırması
- Tamamlama süresi ve puan ilişkisizdir. En hızlı model olan Grok 4.3, 142 saniyede 0.431 puan alırken; en yavaş model olan Qwen 3.6 Plus, 1.948 saniyede 0.333 puan alıyor.
- Sonnet 5 ilk altı arasında en yavaş olanıdır. 1.763 saniye ile, 0.024 daha fazla puan için Sonnet 4.6'dan (612 saniye) yaklaşık 3 kat daha uzun sürüyor.
- Sonnet 4.6 yüksek puan alanlar arasında en hızlısıdır, Sonnet 5'in süresinin üçte birinde 0.748 puana ulaşıyor.
- 1.600 saniyenin üzerindeki çalışmalar daha zor görevlerden değil, aşırı yinelemeden kaynaklandı: MiniMax M3, her iki Qwen varyantı, GLM 5.1 base ve Deepseek V4 Pro'nun tümü 0.55 altında puan aldı.
- Çalışma süresini iki ilişkisiz neden yönlendirir. Bir model içinde, daha uzun çalışmalar puanı yükselten daha derin yineleme anlamına gelebilir (Sonnet 5). Modeller arasında ise en uzun çalışmalar verimsiz aşırı yinelemeden kaynaklanır (1.600 saniyenin üzerindeki her model 0.55 altında puan aldı). Tek başına süre bu ikisini ayırt edemez.
Görev başına araç çağrıları
- Araç çağrı sayısı bir yetenek ölçüsü değil, davranışsal bir parmak izidir ve farklı harness'lar arasında karşılaştırılamaz. OpenAI'nin
apply_patchözelliği tam dosya düzenlemesini tek bir çağrıda birleştirir, bu nedenle düşük sayılar daha az iş değil, araç tasarımını yansıtır. - Araç çağrı sayısı puanı öngörmez. Sayılar 18 (Grok 4.3) ile 125 (Sonnet 5) arasında değişirken, sayı ve puan arasında hiçbir örüntü yoktur.
- Sonnet 5 tüm modeller arasında en fazla çağrıyı yapıyor (125) ve en yüksek puanı alıyor; Sonnet 4.6 yaklaşık 50 çağrıyla neredeyse aynı puana ulaşıyor. Her ikisi de aralığın zıt uçlarında çalışıyor.
- MiniMax M3 orta sıralarda bir 0.583 puan için 108 çağrı yaptı, yani yüksek sayı tek başına yardımcı olmuyor.
LLM performansı: tek bir başarılı görev üzerinde
Hiçbir model yukarıdaki tam değerlendirmenin her adımını geçemedi. Maliyet ve hızı eşit koşullarda karşılaştırmak için, her modelin tamamlayabileceği basit bir temel görev çalıştırdık: dört CRUD endpoint'i, temel doğrulama, kimlik doğrulama yok ve veritabanı yok.
Maliyet ve kod satırı karşılaştırması
- Basit görevler modelleri ayırt etmez; tam değerlendirmenin var olmasının temel nedeni budur. Temel görevde maliyet, kod uzunluğu ve geçme oranı yakınsar: her model tamamlar, satırlar 40 ile 64 arasında kümelenir ve maliyet sentlere düşer. Model farklılıkları yalnızca uzun, çok dosyalı ajan tabanlı çalışmalarda ortaya çıkar.
- Kod uzunluğu basit görevlerde bir model özelliği değildir (40 ile 64 satır), bir aşırı üretici olan Gemini 3.5 Flash base hariç; bu model 131 satır üreterek en pahalı temel görev haline geldi.
- Sonnet 5 çabayı göreve göre ayarlıyor: temel görevde 9 çağrı, 46 satır, $0.09 iken, tam değerlendirmede 125 çağrı. Sonnet 4.6 temel görevi, tam değerlendirme hücre başına maliyetinin yaklaşık %15'i ile çalıştırdı ($0.20 base, $0.15 thinking). Opus 4.8 de $0.16 ve 6 çağrıya düştü. Token başına ücretler için LLM Fiyatlandırması makalesine bakın.
Tamamlama süresi ve token kullanımı
- Modeller iki hız türüne ayrılır. Uyarlanabilir modeller çabayı zorluğa göre ölçeklendirir (Opus 4.8: temel görevde 34 saniye, değerlendirmede 1.072 saniye); sabit tempolu modeller zorluktan bağımsız olarak yavaş çalışır (MiniMax M3: 475 vs 1.684).
- Aynı görev için çıktı 8 kat aralığında değişir; 787 token'dan (Qwen 3.6 Plus thinking) 6.643 token'a (GPT 5.4 Mini) kadar, dolayısıyla ayrıntıcılık bir görev etkisi değil, istikrarlı bir model eğilimidir.
Ajan tabanlı LLM sistemleri nedir?
Yazılım geliştirmek yinelemelidir: kod yaz, çalıştır, hataları oku, düzelt, tekrarla. Ajan tabanlı yapay zeka sistemleri, LLM'lerin aynı döngüyü izlemesini sağlar. Model, dosya yazabileceği, komut çalıştırabileceği, çıktıları okuyabileceği ve gördüklerine dayanarak değişiklik yapabileceği bir geliştirme ortamında çalışır ve görev tamamlanana kadar devam eder.
Bu önemlidir çünkü gerçek uygulamalar tek dosyadan ibaret değildir. Rotalar ve veritabanı modelleriyle backend'leri, bileşenler ve API çağrılarıyla frontend'leri, yapılandırma dosyaları, bağımlılıklar ve testleri vardır. Bunları birlikte çalışır hale getirmek, ajan tabanlı mimarinin tam olarak sağladığı şey olan yinelemeli test ve iyileştirme gerektirir.
Nasıl çalışır
Model, bir kabuk, dosya sistemi ve çalıştırma çıktısına erişimi olan bir harness içinde yer alır. Bir uygulama geliştirmesi istendiğinde, dosyaları adım adım yazar. Her adımdan sonra harness modele ne olduğunu gösterir: sunucu başladı mı, testler geçti mi, linter hataları işaretledi mi? Bu geri bildirime dayanarak model, sırada ne yazacağına veya düzelteceğine karar verir.
Bu, tek seferlik üretimden temel olarak farklıdır. Tek seferlik kurulumlarda model, çalışıp çalışmadığını doğrulamanın bir yolu olmadan tüm kod tabanını körlemesine üretir. Ajan tabanlı LLM sistemlerinde model, her eylemin sonuçlarını görür ve rotasını düzeltir. Ancak bu yetenek tek başına yeterli değildir. Modelin iş mantığını doğru şekilde uygulamak için hâlâ güçlü muhakemeye ihtiyacı vardır ve performans farklılıkları tam da burada ortaya çıkar.
Ajan tabanlı LLM değerlendirme metodolojisi
Tüm modeller için ajan harness'i olarak Opencode'i kullandık ve bunları OpenRouter üzerinden bağladık; bir istisna hariç: Claude Fable 5, Claude aboneliğindeki Claude Code CLI üzerinde çalıştı. Her hücre, hücre başına varyansı ölçmek ve liderlik tablosunu dengelemek için 3 kez çalıştırıldı. Rezervasyon sistemlerinden etkileşimli panolara kadar uzanan 10 yazılım geliştirme görevinde (T-1'den T-10'a) otonom olarak çalışma yeteneklerini değerlendirdik. Bu görevler, ajanların çok dosyalı projeleri yönetmesini ve işlevsel ürünler sunmasını gerektirir.
Yürütme ve orkestrasyon
Her ajan ve görev temiz bir ortamda başlar. Talimatlar bir TASK.md dosyası olarak sağlanır ve başlatma betikleri için 20 dakikalık bir heartbeat gözlemcisi kullanırız. Bu aşamada çıkış kodlarını, yürütme süresini ve backend ile frontend dosyalarının oluşturulup oluşturulmadığını kaydederiz. Ayrıca girdi, çıktı ve önbelleğe alınmış kategorilerde gerçek zamanlı token kullanımını izleriz.
Backend doğrulaması: Oluşturulan projeleri, standart bir YAML sözleşmesine göre test etmek için yalıtılmış ortamlarda dağıtırız. Doğrulama; mutlu yol senaryolarını, hata yönetimini (400/403/409) ve veri tutarlılığını kapsar.
Sonuçları iki modda test ederiz:
Uyarlanabilir mod, farklı rota adlarıyla bile işlevselliği doğrular; Katı mod ise sözleşmeye tam uyumu gerektirir.
Backend genel puanı hücre başına şu şekilde hesaplanır:
backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)
burada has_backend, hücre bir backend projesi ürettiyse 1, aksi takdirde 0'dır. Uyarlanabilir, davranışsal doğruluğu ölçtüğü için daha yüksek ağırlıklandırılır; katı, sözleşme sapması (yeniden adlandırılmış rotalar, değiştirilmiş durum kodları, yeniden yapılandırılmış yanıt alanları) için bir ceza ekler.
UI ve kullanıcı senaryosu testi
Ön kontroller, render ve kimlik doğrulama dahil olmak üzere gerçek kullanıcı akışlarını simüle etmek için tarayıcı otomasyonu kullanırız. Uygulamanın çökmeden çalıştığından emin olmak için giriş gönderimi ve giriş sonrası davranış gibi işlevsel adımları doğrularız.
UI puanlaması sekiz adımı iki gruba ayırır. Altyapı adımları (backend ön kontrolü, frontend render, giriş formu görünür, giriş gönderimi, giriş 2xx, çalışma zamanı çökmesi yok) uygulamanın çalışıp çalışmadığını ölçer. Davranış adımları (giriş sonrası kimlik sinyali, giriş sonrası davranış sinyali) uygulamanın çalıştıktan sonra amaçlanan işlevini yerine getirip getirmediğini değerlendirir.
ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)
Engellenen davranış adımları davranış paydasından hariç tutulur, böylece uygulama yüklenemediğinde bir hücre çift ceza almaz.
Token hesaplaması
Token sayıları LLM API yanıtından çıkarılır. Yalnızca yeni işlenen token'ları yansıtan etkin girdiyi elde etmek için önbelleğe alınmış girdi token'larını toplam girdi token'larından çıkarırız. Çıktı token'ları asla önbelleğe alınmaz, bu nedenle değişmeden kalır.
Nihai toplama
Nihai değerlendirme puanı, önceki aşamaların sonuçları birleştirilerek hesaplanır: Final Score = (0.7 × backend_overall) + (0.3 × ui_score) API seviyesindeki mantık hataları genellikle frontend'deki herhangi bir başarıyı geçersiz kıldığı için backend'e daha yüksek bir ağırlık atarız.
Görev örneği
Görev 6: Yardım masası bilet sistemi
Görev 6, karmaşık bir müşteri destek ekosistemi geliştirmeye odaklanır. Temel amaç, iş kurallarını ve güvenlik sınırlarını sıkı bir şekilde uygularken müşteriler ve destek temsilcileri arasındaki iletişimi yöneten bir platform oluşturmaktır. Bu görev, bir ajanın tam yığın bir ortamda çok kullanıcılı durum makinelerini, veri yalıtımını ve zincirleme iletişimi yönetme yeteneğini değerlendirir.
Görev, aşağıdaki özelliklere sahip bir yardım masası sistemi oluşturmayı gerektiriyordu:
- Müşteriler (oluşturma/yanıtlama) ve Temsilciler (yönetim/çözüm) için ayrı izinler.
- Geçersiz geçişleri engelleyen ve role özgü eylemleri zorunlu kılan katı bir durum iş akışı.
- Sistem bütünlüğünü korumak için yetkisiz kaynak isteklerinin 403 yerine 404 döndürdüğü gelişmiş veri yalıtımı.
- Kesintisiz temsilci-müşteri etkileşimi için kronolojik bir yanıt sistemi.
- Duyarlı Vite tabanlı bir frontend (React/Vue/Svelte) ile birleştirilmiş bir FastAPI backend'i.
- Anında sistem etkinleştirme için belirli kabuk komutları aracılığıyla tekrarlanabilir kurulum.
Görev 6 belgelerini GitHub'da görüntüleyebilirsiniz.
Bu benchmarkı kaynak gösterin
Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.
@misc{kaleliolu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Ajan Tabanlı Kodlama Değerlendirmesi}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Erişim tarihi: 2 Temmuz 2026}
}341 veri noktasının sonuçları ve zaman damgaları. Bu makalede kullanılan verileri, 2 CSV dosyası ve bir README içeren ZIP dosyası olarak indirin.
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.