A-CODE-LLM Bench: Ajan Bazlı Kodlama Kıyaslaması
En iyi Büyük Dil Modellerini (LLM'leri) ajan bazlı bir CLI aracı kullanarak 10 yazılım geliştirme görevi üzerinde kıyasladık. Model başına 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örev boyunca 3 kez çalıştırıldı (takma ad başına 30 örnek, yineleme başına 380 hücre 38 takma ad için). Daha fazla bilgi için metodolojiye bakın.
- Orta seviye Sonnet, amiral gemisi Opus'u geçiyor. Her iki Sonnet sürümü, Opus 4.8 (0.702) dahil olmak üzere tüm Opus modellerinden daha yüksek puan alıyor. Anthropic’ın en pahalı kademesi en iyi kodlayıcısı değil.
- Zirve artık yalnızca Anthropic değil: Grok 4.5 (0.732), tüm Opus türevlerini geçiyor. OpenAI’nın yeni amiral gemisi GPT 5.6 Sol, şirketin en iyi puanını elde ediyor (0.615); hâlâ Sonnet 5'in 0.157 altında ve daha yüksek hesaplamalı pro türevleri çoğunlukla kendi temellerinin altında kalıyor (Sol Pro 0.543, Terra Pro 0.568; yalnızca Luna Pro iyileşiyor, 0.603 vs 0.579).
- Kod uzmanları kodlama kıyaslamasını kazanamadı. OpenAI’nın kod odaklı sürümü GPT 5.3 Codex, 0.572 puan alarak orta sıralarda ve OpenAI’nın kendi genel GPT 5.4 Mini'sinin (0.594) altında kalıyor. Moonshot'ın Kimi K2.7 Code modeli 0.611 ile daha güçlü bir uzman.
- Hiçbir model arka uçta güvenilir değil: tavan 0.701 (Sonnet 5), yani birinci bile iş mantığı ve sözleşme kontrollerinin yaklaşık üçte birinde başarısız oluyor. Temmuz eklemeleri arasında Grok 4.5, 0.663 ile en yakına geliyor. Ön uç liderler arasında neredeyse çözülmüş (0.79 ile 0.96 arasında), bu yüzden arka uç açık sorundur ve sıralamayı belirler. Claude Haiku 4.5 iyi iş çıkarıyor (0.731), ancak 0.277'lik arka uç puanı onu 0.413'te tutuyor.
- GPT'nin zayıf noktası ön uçtur. GPT 5.4 ve 5.5, arka uçta Opus 4.8 ile eşleşiyor (yaklaşık 0.6) ancak ön uçta 0.53 ile 0.55 arasında puan alıyor; GPT 5.6 ailesi bunu 0.63 ile 0.71 arasına taşıyor, hâlâ Sonnet serisinin 0.91+ seviyesinin çok altında.
Maliyet ve başarı karşılaştırması
- Amiral gemisi fiyatlı modeller en kötü değeri sunuyor. Opus 4.7 en pahalısı ($3.08/hücre) ve 0.610 puan alıyor, bu da $1.33'lik Sonnet 4.6'nın altında.
- Zirve, küçük bir kazanç için büyük bir prim ödüyor: Sonnet 5, hücre başına 70% daha fazla maliyetle Sonnet 4.6'dan 0.024 daha yüksek puan alıyor.
- Grok 4.5 yeni en iyi değer: 0.732 puanla, kazanana 0.040 farkla yaklaşıyor, hücre başına $0.46 maliyetle, Sonnet 5'in $2.23'ine kıyasla. GPT 5.6 ailesinde fiyat bir şey satın almıyor: 0.543 ile 0.615 arasındaki puanlar için hücre başına $0.18 (Luna) ile $2.76 (Sol Pro) arasında, en ucuz takma ad en pahalı olandan daha yüksek puan alıyor.
Görev tamamlanma süresi ve başarı karşılaştırması
- En yüksek puan en yavaşlar arasında. Sonnet 5, görev başına yaklaşık 30 dakika sürüyor, bu da 0.024 daha fazla puan için Sonnet 4.6'nın 3x katı; Sonnet 4.6, aynı puanın neredeyse aynısını üçte bir sürede veriyor.
- Uzun bir çalışma genellikle sıkışmış bir modeli gösterir, kapsamlı bir modeli değil: en düşük puan alanlar, her iki Qwen türevi, GLM 5.1 temel ve Deepseek V4 Pro, aşırı yineleme nedeniyle 0.45'in altındaki puanlar için 1,700 saniyeden fazla çalıştı.
- Grok 4.3 hızlıydı çünkü erkenden bıraktı: 0.431 için 142 saniye ve 18 araç çağrısı. Grok 4.5 hızı koruyor ve bırakmayı bırakıyor: görev başına yaklaşık 9 dakika, Sonnet 5'in süresinin üçte birinden az, 0.732 için.
Görev başına araç çağrıları
- Araç çağrı sayısı ne yeteneği ne de karşılaştırılabilir çabayı ölçer. Sonnet 5 en çok çağrıyı yaptı (125) ve en yüksek puanı aldı; MiniMax M3 orta sıra bir 0.583 için 108 çağrı yaptı; Grok 4.5 40 çağrıyla 0.732'ye ulaştı; OpenAI'nin düşük 16 ila 36 çağrısı, tüm bir dosyayı tek bir çağrıya sığdıran apply_patch'ten geliyor. Sol Pro ve Terra Pro, tabanlarına göre dörtte bir ila üçte bir daha az araç çağırıyor ve daha düşük puan alıyor: daha fazla akıl yürütme, daha az uygulama. Ajanları araç hacmine göre sıralamayın.
- Aynı puana iki yol ulaşıyor: Sonnet 5 yoğun yineleme yapıyor (125 çağrı), Sonnet 4.6 zar zor (yaklaşık 50), 0.024 farkla.
LLM'nin tek bir başarılı görevdeki performansı
Yukarıdaki tam kıyaslamanın her adımını hiçbir model geçemedi. Maliyet ve hızı eşit şartlarda karşılaştırmak için, her modelin tamamlayabileceği basit bir temel görev çalıştırdık: dört CRUD endpoint, temel doğrulama, kimlik doğrulama yok ve veritabanı yok.
Maliyet ve kod satırı karşılaştırması
- Basit görevler modelleri sıralayamaz, bu yüzden oyuncak değerlendirmeler yanıltıcıdır. Her modelin geçtiği temelde, kod 40 ila 64 satır aralığına yakınsıyor ve maliyet sentlere düşüyor; farklılıklar yalnızca uzun, çok dosyalı işlerde ortaya çıkıyor.
- “Hızlı ve hafif” kademe burada en pahalısıydı: Gemini 3.5 Flash temel, önemsiz görev için 131 satır yazdı; bu, alanın iki ila üç katı olup kendi konumlandırmasına aykırı olarak onu en pahalı temel haline getirdi.
- Sonnet 5'in yoğun yinelemesi göreve bağlıdır, bir alışkanlık değil: burada 9 çağrı ve $0.09, kıyaslamada 125 çağrıya karşılık.
Daha fazla bilgi için LLM Fiyatlandırma makalesine bakın.
Tamamlanma süresi ve token kullanımı
- Maliyet öngörülebilirliği modelleri ikiye ayırır. Uyarlanabilir modeller yalnızca gerektiğinde harcama yapar (Opus 4.8: temel 34s, kıyaslama 1,072s); sabit hızlı modeller önemsiz işlerde bile yavaş ve maliyetli çalışır (MiniMax M3: 475 vs 1,684s).
- Çıktı uzunluğu sabit bir model özelliğidir, aynı görev için neredeyse 10x değişir (787 ila 7,508 token) ve doğrudan maliyete yansır.
Ajan bazlı LLM sistemleri nelerdir?
Yazılım geliştirme yinelemelidir: kod yaz, çalıştır, hataları oku, düzelt, tekrarla. Ajan bazlı 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ı modelleri içeren arka uçlar, bileşenler ve API çağrıları içeren ön uçlar, yapılandırma dosyaları, bağımlılıklar ve testler bulunur. Bunların birlikte çalışmasını sağlamak, tam olarak ajan mimarisinin sağladığı yinelemeli test ve iyileştirme gerektirir.
Tercih edilen kaynak olarak ekleNasıl çalışır
Model, kabuk, dosya sistemi ve yürütme çıktısına erişimi olan bir koşum takımı içinde yer alır. Bir uygulama oluşturması istendiğinde, dosyaları kademeli olarak yazar. Her adımdan sonra, koşum takımı modele ne olduğunu gösterir: sunucu başladı mı, testler geçti mi, linter hataları işaretledi mi? Bu geri bildirime dayanarak, model ne yazacağına veya düzelteceğine karar verir.
Bu, tek seferlik üretimden temelde farklıdır. Tek seferlik kurulumlarda, model tüm kod tabanını körü körüne üretir ve çalıştığını doğrulamanın bir yolu yoktur. Ajan bazlı LLM sistemlerinde, model her eylemin sonuçlarını görür ve rotayı düzeltir. Ancak bu yetenek tek başına yeterli değildir. Modelin, iş mantığını doğru bir şekilde uygulamak için hâlâ güçlü akıl yürütmeye ihtiyacı vardır; performans farklılıklarının asıl ortaya çıktığı yer burasıdır.
Ajan bazlı LLM kıyaslama metodolojisi
Tüm modeller için ajan koşum takımı olarak Opencode'i kullandık ve onları OpenRouter aracılığıyla bağladık; bir istisna dışında: Claude Fable 5, Claude aboneliğinde Claude Code CLI üzerinde çalıştı. Hücre başına varyansı ölçmek ve lider tablosunu istikrarlı hale getirmek için her hücre 3 kez çalıştırıldı. Rezervasyon sistemlerinden etkileşimli gösterge panolarına kadar çeşitli 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önetmelerini ve işlevsel ürünler sunmalarını gerektirir. Temmuz 2026'da eklenen yedi takma ad (Grok 4.5 ve GPT 5.6 ailesi: Sol, Terra, Luna, her biri temel ve pro modunda) buradaki her modelle aynı şekilde, API varsayılan ayarlarında Opencode 1.15.13 üzerinde çalıştı; OpenAI'nin Sol için lansman rakamları daha yüksek hesaplama modlarını kullanır.1 Dört Sol Pro hücresi ve bir Terra Pro hücresi, model hataları yerine tekrarlanan sessiz API akışı başarısızlıklarıyla sonuçlandı ve başarısız olarak puanlandı.
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 kalp atışı izleyicisi kullanırız. Bu aşamada, çıkış kodlarını, yürütme süresini ve arka uç ile ön uç dosyalarının oluşturulup oluşturulmadığını kaydederiz. Ayrıca giriş, çıkış ve önbelleğe alınmış kategoriler arasında gerçek zamanlı token kullanımını da izleriz.
Arka uç doğrulaması: Oluşturulan projeleri, kanonik 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 işlemeyi (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 olarak uyulmasını gerektirir.
Hücre başına arka uç genel puanı şu şekilde hesaplanır:
backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)
burada has_backend hücre bir arka uç projesi ürettiğinde 1, aksi takdirde 0'dır. Uyarlanabilir daha yüksek ağırlıklandırılır çünkü davranışsal doğruluğu ölçer; 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
Tarayıcı otomasyonunu kullanarak ön uçuşlar, işleme ve kimlik doğrulama dahil olmak üzere gerçek kullanıcı akışlarını simüle ederiz. Uygulamanın çökmeden çalıştığından emin olmak için oturum açma gönderimi ve oturum sonrası davranış gibi işlevsel adımları doğrularuz.
UI puanlaması sekiz adımı iki gruba ayırır. Altyapı adımları (arka uç ön uçuşu, ön uç işleme, oturum açma formu görünür, oturum açma gönderimi, oturum açma 2xx, çalışma zamanı çökmesi yok) uygulamanın hiç çalışıp çalışmadığını ölçer. Davranış adımları (oturum sonrası kimlik doğrulama sinyali, oturum 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 çıkarılır, böylece uygulama yüklenemediğinde bir hücre çift cezalandırılmaz.
Token hesaplaması
Token sayıları, LLM API yanıtından çıkarılır. Yalnızca yeni işlenen token'leri yansıtan etkin girdiyi elde etmek için önbelleğe alınmış girdi token'lerini toplam girdi token'lerinden çıkarırız. Çıktı token'leri asla önbelleğe alınmaz, bu yüzden değişmeden kalırlar.
Nihai toplama
Nihai kıyaslama 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 ön uçtaki herhangi bir başarıyı geçersiz kıldığı için arka uca daha yüksek ağırlık veririz.
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 ajanları arasındaki iletişimi yöneten bir platform oluşturmaktır. Bu görev, bir ajanın tam yığın ortamında çok kullanıcılı durum makinelerini, veri yalıtımını ve iş parçacıklı 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 Ajanlar (yönetim/çözüm) için farklı izinler.
- Yasa dışı 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 404 döndürdüğü, 403 yerine gelişmiş veri yalıtımı.
- Kesintisiz ajan-müşteri etkileşimi için kronolojik bir yanıt sistemi.
- Duyarlı bir Vite destekli ön uç (React/Vue/Svelte) ile birleşik bir FastAPI arka ucu.
- Anında sistem etkinleştirme için belirli kabuk komutları aracılığıyla yeniden üretilebilir 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 Bazlı Kodlama Kıyaslaması}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Erişim tarihi: 10 Temmuz 2026}
}418 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.