A-CODE-LLM Bench: Ajansal Kodlama Kıyaslaması
En iyi Büyük Dil Modellerini (LLM'leri) 10 yazılım geliştirme görevinde ajan bir CLI aracı kullanarak kıyasladık. Her modelde 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, 40 takma ad genelinde iterasyon başına 400 hücre). Daha fazla ayrıntı için metodoloji bölümüne bakın.
- Orta seviye Sonnet, amiral gemisi Opus'tan daha iyi performans gösteriyor. Her iki Sonnet sürümü de Opus 4.8 (0.702) dahil her Opus'tan daha yüksek puan alıyor. Anthropic'in en pahalı katmanı en iyi kodlayıcısı değil.
- Zirve artık yalnızca Anthropic'e ait değil: Grok 4.5 (0.732) her Opus varyantını geride bırakıyor. OpenAI'nin yeni amiral gemisi GPT 5.6 Sol, şirketin en iyi skorunu (0.615) elde ediyor, hâlâ Sonnet 5'in 0.157 altında ve yüksek hesaplamalı pro varyantları çoğunlukla kendi temel modellerinin 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ı. GPT 5.3 Codex, OpenAI'nin kod odaklı varyantı, 0.572 puan alarak orta sıralarda ve OpenAI'nin 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.
- Genel bir model olan Kimi K3, açık ağırlıklı modellerde liderliği Moonshot'ın kendi kod uzmanından alıyor: 0.725, genel sıralamada altıncı, K2.7 Code'un 0.114 üzerinde. 0.632'lik backend puanı, tüm Opus ve GPT takma adlarının üzerinde beşinci sırada yer alıyor.
- Thinking Machines'in ilk modeli Inkling, açık ağırlıklı katılımcılar arasında üçüncü olarak 0.575 ile giriş yapıyor. 0.747'lik frontend puanı tüm GPT 5.6 takma adlarını geride bırakıyor; 0.501'lik backend puanı ise sıralamasını sınırlıyor.
- Hiçbir model backend konusunda güvenilir değil: tavan 0.701 (Sonnet 5), dolayısıyla kazanan bile iş mantığı ve sözleşme kontrollerinin yaklaşık üçte birinde başarısız oluyor. Grok 4.5, Temmuz eklemeleri arasında 0.663 ile en yakına geliyor. Liderler arasında frontend neredeyse çözülmüş durumda (0.79 ile 0.96 arası), bu yüzden backend açık bir problem ve sıralamayı belirliyor. Claude Haiku 4.5 iyi render alıyor (0.731), ancak 0.277'lik backend puanı onu 0.413'te tutuyor.
- GPT'nin zayıf noktası frontend. GPT 5.4 ve 5.5, backend'de Opus 4.8 ile eşleşiyor (yaklaşık 0.6) ancak frontend'de 0.53 ila 0.55 puan alıyor; GPT 5.6 ailesi bunu 0.63 ila 0.71'e çıkarıyor, yine de Sonnet hattının 0.91 üzeri puanlarının oldukça altında.
Maliyet & başarı karşılaştırması
- Amiral gemisi fiyatlı modeller en kötü değere sahip. Opus 4.7 en pahalısı ($3.08/hücre) ve 0.610 puan alarak $1.33 değerindeki Sonnet 4.6'nın altında kalıyor.
- Zirve, küçük bir kazanç için yüksek bir prim talep ediyor: Sonnet 5, Sonnet 4.6'dan 0.024 daha yüksek puan alıyor ancak hücre başına maliyeti %70 daha fazla.
- Grok 4.5 yeni en iyi değer: 0.732, kazanandan 0.040 geride, Sonnet 5'in $2.23'ına kıyasla hücre başına $0.46. GPT 5.6 ailesinde fiyat hiçbir şey kazandırmıyor: 0.543 ile 0.615 arası puanlar için hücre başına $0.18 (Luna) ile $2.76 (Sol Pro) arasında değişiyor, en ucuz takma ad en pahalıdan daha yüksek puan alıyor.
- Kimi K3, altıncı sıradaki puanını orta seviye bir fiyata alıyor: hücre başına $1.47, Sonnet 4.6'nın $1.33'ına yakın ancak puanda 0.007 daha yüksek ve Sonnet 5'in $2.23'ının oldukça altında. Inkling, liste fiyatıyla 0.575 için hücre başına $1.64 tutuyor, daha düşük bir puan için Sonnet 4.6'nın üzerinde.
Görev tamamlama süresi & 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, 0.024 daha fazla puan için Sonnet 4.6'nın 3 katı; Sonnet 4.6, aynı skoru neredeyse üçte biri sürede veriyor.
- Uzun çalışma genellikle takılmış bir modeli işaret eder, kapsamlı olanı değil: en düşük puanı alanlar, her iki Qwen varyantı, GLM 5.1 temel modeli ve Deepseek V4 Pro, 0.45'in altında puanlar için aşırı yinelemeden dolayı 1.700 saniyenin üzerinde çalıştı.
- Grok 4.3 hızlıydı çünkü erken pes etti: 0.431 için 142 saniye ve 18 araç çağrısı. Grok 4.5 hızı koruyor ve pes etmeyi bırakıyor: 0.732 için görev başına yaklaşık 9 dakika, Sonnet 5'in süresinin üçte birinden az.
- Kimi K3 tam ters köşede oturuyor: üst düzey puan, en kötü hız. Altıncı sıradaki 0.725 için görev başına ortalama 55 dakika sürüyor, alandaki en yavaşı ve kabaca Sonnet 5'in iki katı. Doğruluğu gerçek, ancak üst sıralara girmenin en az pratik yolu.
Görev başına araç çağrısı
- Araç çağrı sayısı, karşılaştırabileceğiniz ne yeteneği ne de çabayı ölçer. Sonnet 5 en çok çağrıyı (125) yaptı ve en yüksek puanı aldı; MiniMax M3, orta sıralarda bir 0.583 için 108 çağrı yaptı; Grok 4.5, 40 çağrı ile 0.732 puana ulaştı; OpenAI'nin düşük 16 ila 36 çağrısı, apply_patch'in tüm dosyayı tek bir çağrıda toplamasından kaynaklanıyor. Sol Pro ve Terra Pro, temel modellerinden dörtte bir ila üçte bir daha az araç çağırıyor ve daha az puan alıyor: daha fazla akıl yürütme, daha az uygulama. Ajanları araç hacmine göre sıralamayın.
- İki yol aynı puana ulaşıyor: Sonnet 5 yoğun şekilde yineleme yapıyor (125 çağrı), Sonnet 4.6 çok az (yaklaşık 50), aralarında 0.024 fark var.
LLM performansı tek bir başarılı görevde
Hiçbir model yukarıdaki tam kıyaslamanın her adımını 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 uç noktası, temel doğrulama, kimlik doğrulaması ve veritabanı yok.
Maliyet & kod satırı karşılaştırması
- Basit görevler modelleri sıralayamaz, bu yüzden oyuncak değerlendirmeler yanıltır. Her modelin geçtiği temel görevde, kod 40 ila 64 satıra yakınsar ve maliyet sentlere düşer; farklılıklar yalnızca uzun, çok dosyalı işlerde ortaya çıkar.
- "Hızlı ve hafif" katman burada en pahalısıydı: Gemini 3.5 Flash temel modeli, basit görev için alandakinin iki ila üç katı olan 131 satır kod yazarak kendi konumlandırmasının aksine en pahalı temel model oldu.
- Sonnet 5'in yoğun yinelemesi alışkanlık değil, görev odaklı: burada 9 çağrı ve $0.09, kıyaslamada ise 125 çağrı.
Daha fazla bilgi için LLM Fiyatlandırması makalesine bakın.
Tamamlama süresi & token kullanımı
- Maliyet öngörülebilirliği modelleri ikiye ayırıyor. Uyarlanabilir modeller yalnızca gerektiğinde harcama yapıyor (Opus 4.8: temel görev 34sn, kıyaslama 1.072sn); sabit tempolu modeller basit işlerde bile yavaş ve maliyetli çalışıyor (MiniMax M3: 475 vs 1.684sn).
- Çıktı uzunluğu, aynı görev için neredeyse 10 kat değişen (787 ila 7.508 token) sabit bir model özelliğidir ve doğrudan maliyeti etkiler.
Ajan LLM sistemleri nedir?
Yazılım geliştirmek yinelemelidir: kod yaz, çalıştır, hataları oku, düzelt, tekrarla. Ajan 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şiklikler 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 olan backend'leri, bileşenleri ve API çağrıları olan frontend'leri, yapılandırma dosyaları, bağımlılıkları ve testleri vardır. Bunları birlikte çalıştırmak, yinelemeli test ve iyileştirme gerektirir ki bu da ajan mimarisinin tam olarak sağladığı şeydir.
Nası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ı aşamalı olarak yazar. Her adımdan sonra, koşum takımı modele ne olduğunu gösterir: sunucu başladı mı, testler geçti mi, denetleyici hataları işaretledi mi? Bu geri bildirime dayanarak, model daha sonra ne yazacağına veya düzelteceğine karar verir.
Bu, tek seferlik üretimden temelden farklıdır. Tek seferlik kurulumlarda, model tüm kod tabanını körü körüne üretir ve çalışıp çalışmadığını doğrulamanın bir yolu yoktur. Ajan LLM sistemlerinde, model her eylemin sonuçlarını görür ve rota düzeltmesi yapar. Ancak bu yetenek tek başına yeterli değildir. Modelin iş mantığını doğru bir şekilde uygulamak için hâlâ güçlü bir akıl yürütmeye ihtiyacı vardır ve performans farklılıklarının gerçekten ortaya çıktığı yer burasıdır.
Tercih edilen kaynak olarak ekleAjan LLM kıyaslama metodolojisi
Tüm modeller için ajan koşum takımı olarak Opencode kullandık ve iki istisna dışında bunları OpenRouter üzerinden bağladık: Claude Fable 5, Claude aboneliğinde Claude Code CLI üzerinde çalıştı ve Inkling, model OpenRouter'da mevcut olmadığı için Thinking Machines'in kendi OpenAI uyumlu API'si üzerinden çalıştı. Hücre başına varyansı ölçmek ve lider tablosunu dengelemek için her hücre 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 çalışma yeteneklerini değerlendirdik. Bu görevler, ajanların çok dosyalı projeleri yönetmesini ve işlevsel ürünler sunması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ı olan API varsayılan ayarlarında Opencode 1.15.13 üzerinde çalıştı; OpenAI'nin Sol için lansman sayıları daha yüksek hesaplama modları kullanır.1 Dört Sol Pro hücresi ve bir Terra Pro hücresi, model hataları yerine tekrarlanan sessiz API akış hatalarıyla sona erdi ve başarısız olarak puanlandı.
Kimi K3 ve Inkling, API varsayılan ayarlarında Temmuz 18'de eklendi; Inkling, 0.9 olan varsayılan düşünme çabasında çalıştı. Inkling'in maliyet sütunu, Thinking Machines'in milyon giriş token'ı başına $3.74 ve milyon çıkış token'ı başına $9.36 liste fiyatlarını kullanır; sağlayıcı, sınırlı süreli lansman indirimi kapsamında bunun yaklaşık yarısını faturalandırdı.2 Her iki model de, Kimi K3'ün token akışı yapılandırma sırasında kısa duvarı aşacak kadar yavaş olduğu için daha önceki 45 dakika yerine hücre başına 150 dakikalık bir duvarla çalıştı; tamamlama süresi zaman çizelgesinde ayrı olarak rapor edilmiştir. Kimi K3'ün paylaşılan üst akış kapasitesi, çalıştırma penceresi sırasında sık sık hız sınırı ve zaman aşımı hataları döndürdü; etkilenen hücreler aynı duvara karşı bir kez yeniden çalıştırıldı, aynı politika yukarıdaki Sol Pro ve Terra Pro akış hatalarına da uygulandı.
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 kalp atışı 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 giriş, çıkış ve önbelleğe alınmış kategoriler arasında gerçek zamanlı token kullanımını izleriz.
Backend doğrulaması: Oluşturulan projeleri kurallı bir YAML sözleşmesine göre test etmek için yalıtılmış ortamlara 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.
Genel backend puanı hücre başına şu şekilde hesaplanır:
backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)
burada hücre bir backend projesi ürettiyse has_backend 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ı puanlama, sözleşmeden sapma (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, oluşturma 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ışmasını sağlamak için oturum açma gönderimi ve oturum açma 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 oluşturma, oturum açma formu görünür, oturum açma gönderimi, oturum açma 2xx, çalışma zamanı hatası yok) uygulamanın çalışıp çalışmadığını ölçer. Davranış adımları (oturum açma sonrası kimlik doğrulama sinyali, oturum açma 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 çifte cezalandırılmaz.
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 toplam giriş token'larından önbelleğe alınmış giriş token'larını çıkarırız. Çıkış token'ları asla önbelleğe alınmaz, bu nedenle 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 düzeyindeki 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 veriyoruz.
Görev örneği
Görev 6: Yardım masası talep 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 sağlayan bir platform oluşturmaktır. Bu görev, bir ajanın tam yığın bir ortamda çok kullanıcılı durum makinelerini, veri izolasyonunu 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 (talep oluşturma/yanıtlama) ve Temsilciler (yönetim/çözüm) için ayrı izinler.
- Yasadışı geçişleri önleyen ve role özgü eylemleri zorunlu kılan katı bir durum iş akışı.
- Yetkisiz kaynak taleplerinin sistem bütünlüğünü korumak için 403 yerine 404 döndürdüğü gelişmiş veri izolasyonu.
- Kesintisiz temsilci-müşteri etkileşimi için kronolojik bir yanıt sistemi.
- Duyarlı, Vite destekli bir frontend (React/Vue/Svelte) ile birleştirilmiş bir FastAPI backend.
- 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{kalelioglu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Ajansal Kodlama Kıyaslaması}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Erişim tarihi: 12 Ağustos 2026}
}429 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.
Referans Linkleri
Cem'in çalışmaları Business Insider, Forbes, Washington Post gibi önde gelen küresel yayınlar, Deloitte, HPE gibi küresel firmalar, Dünya Ekonomik Forumu gibi STK'lar ve Avrupa Komisyonu gibi uluslarüstü kuruluşlar tarafından alıntılanmıştır.
Cem, kariyeri boyunca teknoloji danışmanı, teknoloji alıcısı ve teknoloji girişimcisi olarak görev yapmıştır. On yıldan fazla bir süre McKinsey & Company ve Altman Solon'da işletmelere teknoloji kararlarında danışmanlık yapmıştır. Ayrıca dijitalleşme üzerine bir McKinsey raporu yayımlamıştır.
CEO'ya rapor verirken bir telekomünikasyon şirketinin teknoloji stratejisini ve satın alımını yönetmiştir. Ayrıca, 2 yıl içinde 0'dan 7 haneli yıllık yinelenen gelire ve 9 haneli değerlemeye ulaşan derin teknoloji şirketi Hypatos'un ticari büyümesini yönetmiştir. Cem'in Hypatos'taki çalışmaları TechCrunch ve Business Insider gibi önde gelen teknoloji yayınları tarafından ele alınmıştır.
Cem, uluslararası teknoloji konferanslarında düzenli olarak konuşma yapmaktadır. Boğaziçi Üniversitesi'nden bilgisayar mühendisi olarak mezun olmuş ve Columbia Business School'dan MBA derecesine sahiptir.
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.