AIM-Code Bench: Ajan Tabanlı Kodlama Kıyaslaması

LLM'leri kodlama ajanı altyapıları olmadan değerlendirmek, pratikte nasıl kullanıldıklarını tam olarak yansıtmaz. Gerçek geliştirme aynı zamanda mevcut işi genişletmeyi, yabancı kodu devralmayı ve başkalarının üzerine inşa edebileceği uygulamalar bırakmayı da içerir. Modelleri, gelişen yazılım görevlerinde kodlama ajanı altyapılarıyla birlikte değerlendirmek için AIM-Code Bench'i sunuyoruz. Doğruluğun ötesinde kıyaslama; çalışma zamanı performansını, değişen gereksinimlere uyumu ve ajanların birbirinin kodu üzerine inşa ettiği sonuçları ölçer.

Sonuçlar

Fable 5.1, 1. ve 2. aşamalarda gözlemlenen en düşük gecikmeye sahipti; Opus 5 ise 3. ve 4. aşamalarda öndeydi.

Tablo, milisaniye cinsinden p95 gecikmeyi (95th yüzdelik dilim) gösterir; düşük olması daha iyidir. Her değer, kaydedilen programın on tekrar ölçümünün medyanıdır. Sıralamalar her aşamada tam hassasiyet kullanır. Aynı 4. aşama ölçümleri, devir karşılaştırmasında kendi kodu kontrolleri olarak kullanılır. Yakın sayısal sıralar, performansın ayırt edilebilir olduğu anlamına gelmek zorunda değildir.

Bölüm 1: kendi uygulamalarını geliştirme ve iyileştirme

Her ajan, aşamalar boyunca kodunu ve konuşmasını korudu. Yeni gereksinimler geldikçe görev tanımını güncelledik ve her aşama için ajana 20 dakikaya kadar süre verdik. Prompt'lar sıradan geliştirme işlerini tanımladı ve ajanlardan gerekli davranışı korurken elde edebilecekleri en iyi performansı hedeflemelerini istedi.

Deney on üç model-ürün yapılandırmasını kapsadı: dördü Claude Code içinde, üçü Codex içinde, dördü OpenCode içinde, biri Grok Build içinde ve biri Devin CLI içinde. Çaba, desteklenen yerlerde orta; Kimi K3 ve GLM 5.3 için yüksek; MiniMax M3 için sağlayıcı varsayılanıydı. Dolayısıyla her sonuç, modele ve kodlama ürününe birlikte aittir.

İnsanların yapay zeka kodlama ürünlerini gerçek hayat senaryolarında gerçekte nasıl kullandığını olabildiğince yakından yansıtmaya çalıştık. Birçok kişi modelleri kendi altyapıları içinde kullanır; bu nedenle, mevcut modelleri kendi ilgili altyapıları içinde kullanırken açık ağırlıklı modelleri opencode aracılığıyla kullandık.

Projenin dört aşaması

1–3. aşamalar yığın başına 5.000 işlem kullandı. 4. aşama, aday hizmete ayrılan bir CPU ve 128 MiB bellek ile her biri 1.000 işlem içeren bağımsız HTTP istekleri kullandı.

MiniMax M3'in ölçülen yığın gecikmesi, başlangıç aşamasındaki 37.833 ms'den kapasite aşamasındaki 12.254 ms'ye düştü. Uygulama değişip çıkarma bir gereksinim haline geldikçe bu, gözlemlenen %67,6 azalmadır. Orijinal 4. aşama HTTP uygulaması daha sonra 4th sırada, 3.009 ms ile yer aldı.

Qwen 3.8 Max'in ölçülen yığın gecikmesi, ilk iki aşama arasında 11.638 ms'den 8.023 ms'ye değişti; bu, gözlemlenen %31,1 azalmadır. 3. aşama sonucu 4th sırada yer aldı. Bu eğilimler, tek bir başlangıç sonucunun bir ajan projeyi geliştirmeye devam ettikçe ortaya çıkan değişiklikleri neden gözden kaçırdığını gösterir.

Bu yüzdeler, kontrollü optimizasyon hızlanmalarını değil, kaydedilen eğilimleri tanımlar. Her aşama gerekli davranışı veya iş yükünü değiştirir. Özellikle 4. aşama gecikmesi, 3. aşama gecikmesinden çıkarılamaz: arayüz ve istek başına işlem sayısı farklıdır. Doğrudan bir öncesi/sonrası optimizasyon iddiası, her iki sürümün de aynı geçerli iş yükü altında yeniden oynatılmasını gerektirir.

Yol boyunca kod ne kadar değişti?

Dört aşama, on üç yapılandırma boyunca doğrulanmış 52 orijinal aşama farkını kapsar. 4. aşama, uygulama boyutundaki ve düzenleme tarzındaki çeşitliliği gösterir:

Bu sayımlar, ajan tarafından yazılan kaynak testlerini ve araçlarını, yorumları ve boş satırları içerir; sağlanan görev/test güncellemeleri ile JSON tanılamaları hariç tutulur. Her aşamanın başlangıç anlık görüntüsünden nihai farkı ölçerler. Büyük değişiklikler faydalı testler veya optimizasyonlar içerebilir; küçük değişiklikler otomatik olarak daha iyi değildir. Bağlantılı diff raporu aşama başına kaynak değişikliklerini içerir.

Bölüm 2: başka bir ajanın uygulamasını devralma

Orijinal eğilimleri ölçtükten sonra iki farklı soru sorduk: Hangi kod, diğer ajanlara faydalı bir başlangıç noktası sağlar ve hangi ajan başka birinin kodunu genişletirken en iyi performansı gösterir?

Kaydedilen 3. aşama uygulamalarından dallandık ve alıcılardan 4. aşamayı gerçekleştirmelerini istedik. On üç yapılandırmanın her biri diğer on iki yapılandırmanın kodunu aldı; böylece 156 sıralı verici–alıcı çifti oluştu. Yeni öz devralma yoktu. Her alıcı, verici kodu ve aynı 4. aşama gereksinimleriyle yeni ve yalıtılmış bir oturuma başladı; altyapıyı veya diğer ajanların oturumlarını göremezdi.

Orijinal 4. aşama gönderimleri, Bölüm 1 ile aynı ölçümleri kullanarak kendi kodu kontrolleri olarak işlev görür. Bu kontroller orijinal konuşma geçmişiyle geliştirilmişken devralmalar yeni başladı. Bu nedenle karşılaştırma, başlangıç kodu ve konuşma etkilerini birleştirir. Bu geçiş, ardıllardan mevcut bir önbelleği istek gecikmesini optimize ederken bir HTTP hizmetine genişletmelerini ister.

Görünüm A: bir vericinin kodunun sağladığı fayda

Her çift için ardılın HTTP gecikmesini, aynı ardılın kendi orijinal 4. aşama gecikmesiyle karşılaştırıyoruz:

successor benefit = (recipient own latency − inherited-code latency) / recipient own latency

Bir vericinin puanı, bu on iki yüzde faydasının medyanıdır. Pozitif değer, ardıllarının genellikle kendi orijinal devamlarından daha düşük gecikme elde ettiği anlamına gelir. Bu, bir başlangıç uygulamasının ne kadar faydalı olduğuna dair performansa dayalı bir bakıştır; belgeleme kalitesini veya anlaşılma kolaylığını doğrudan ölçmez.

Opus 5, +%17,30 ile en büyük medyan ardıl faydasını sağladı; onu +%15,70 ile Opus 5.5 ve +%11,34 ile Fable 5.1 izledi. Bu sonuçlar, miras alınan uygulamanın performansını ve ardılların onu ne kadar kolay genişletebildiğini yansıtabilir. Yüzdeler ölçeği normalleştirir ancak başlangıç kalitesi veya optimizasyon alanı farklarını ortadan kaldırmaz.

Görünüm B: ardıl olarak performans

Her verici için, on iki alıcısının elde ettiği medyan gecikmeyi hesaplıyoruz. O vericinin her alıcısı daha sonra bu ortak referansla karşılaştırılıyor:

successor advantage = (same-donor median latency − recipient latency) / same-donor median latency

Alıcının puanı, on iki verici genelindeki medyan avantajıdır. Pozitif değer, aynı başlangıç kodunun medyan alıcısından genellikle daha hızlı olduğu anlamına gelir. Bu, bir alıcının yalnızca kendi orijinal uygulaması yavaş olduğu için ödüllendirilmesini önler.

GPT-6 Astra, +%2,68 ile bu keşif amaçlı ardıl özetinde öndeydi; onu +%2,33 ile Opus 5 ve +%0,88 ile Grok 4.6 izledi. Astra'nın Opus 5 karşısındaki üstünlüğü, ölçülen belirsizlik içinde ayırt edilebilir değildi. Bu deneyde en güçlü verici olmak ile en güçlü ardıl olmak farklı sonuçlardır.

Ardıllar miras alınan kaynağın üzerine inşa etti mi?

Kaynak değişimini performanstan ayrı olarak raporluyoruz: (added lines + deleted lines) / inherited source lines. Ayrıca miras alınan kaynağın %50'inden fazlasını silen devralmaları sayıyoruz. Bu, sıfırdan yeniden yazmanın kanıtı değil, büyük ölçekli silme oranıdır: yeniden adlandırmalar, yeniden biçimlendirme ve yardımcı kodun kaldırılması eşiği aşabilir.

Seçilen ardılların hiçbiri GPT-6 Astra, Claude Fable 5.1, Claude Opus 5, Claude Opus 5.5 veya Qwen 3.8 Max'ten miras alınan toplam kaynağın yarısından fazlasını silmedi. On ikisinin tamamı Kimi K3, GPT-5.6 Luna, MiniMax M3 ve Claude Sonnet 5 için bu eşiği aştı. Bunlar, bakım yapılabilirlik sıralaması değil; fiziksel satır değişiklikleri hakkındaki gözlemlerdir. Verici programları, yardımcı kod dahil yalnızca 75–668 kaynak satırı içeriyordu ve testleri/araçları dahil etme tercihi silme yüzdelerini etkiler.

Ölçüm yöntemi, yeniden denemeler ve kapsam

Bildirilen her performans puanı, aynı kaydedilmiş programın on tekrarını kullanır. 1–3. aşamalar tekrar başına 40 ölçülen yığın kullandı. 4. aşama ve devir zamanlaması, her aday için bir CPU, 128 MiB bellek ve 64 işlem/iş parçacığı sınırıyla; 60 saniye boyunca saniyede 20 istek hızında, tekrar başına 1.200 HTTP isteği kullandı.

Programları, özel bir Intel i7-7700 Linux sunucusunda seri olarak ölçtük. Sürücü ve aday; kullanılmayan kardeş iş parçacıkları, sabit 2 GHz CPU politikası ve devre dışı turbo ile ayrı fiziksel çekirdeklerde çalıştı.

Seçilen 156 devralma gönderiminin tamamı ve 52 orijinal aşama derlemesinin tamamı her tekrarı geçti. Eksiksiz değerlendirme, on üç kendi kodu kontrolü dahil 2.080 ölçüm içerir. Ham yanıtları kontrol ettik, p95 gecikmesini yeniden hesapladık, kaynak karmalarını ve kaynak sınırlarını doğruladık ve planlanan her ölçümü sakladık.

%95 aralıklarını, programlar genelinde aynı örneklenen turları kullanarak on ölçüm turunun 10.000 yeniden örneklemesinden hesaplıyoruz. Fark aralığı sıfır içerdiğinde bir karşılaştırma çözümsüzdür. Bu keşif amaçlı aralıklar çoklu karşılaştırmalar için düzeltilmemiştir. Daha hızlı ardıl sayıları, ölçülen puanları karşılaştırır ve istatistiksel olarak ayırt edilebilir farklar anlamına gelmez.

13 orijinal 4. aşama derlemesi ve 156 devralma genelinde, ölçülen 2.028.000 HTTP yanıtının tamamı doğruydu. Maksimum gönderim gecikmesi 0.607 ms idi. Her tekrar, p95 gönderim gecikmesinin 0.05 ms'nin altında ve maksimum gecikmenin 1 ms'nin altında olması sürücü sınırlarını karşıladı. Gecikme, gecikme süresine dahil edilmeye devam eder.

Yayınlanan seçim ek denemeleri içerir. GLM 5.3 ve Qwen 3.8 Max, ilk 3. aşama başarısızlıklarından sonra ikinci eksiksiz orijinal eğilimlerini kullanır. Tamamlanmış dört devralma pilot derlemesi yeniden kullanıldı, on beş Claude çifti altyapı kurtarma denemesi aldı ve yedi başarısız devralma, orijinal vericilerinden bir yeni kodlama denemesi aldı. Yedi kodlama yeniden denemesinin tamamı geçti. Yeni denemeler sonuçtan bağımsız olarak seçildi; önceki denemeler arşivli kalır. Bu sonuçlar, ilk deneme güvenilirliğini değil, seçilen derlemeleri karşılaştırır.

Değerlendirici, aday başarısızlıklarını altyapı açısından geçersiz ölçümlerden ayırır. HTTP doğruluğu; isteklerin en az %99'ünün sunulmasını, doğru ısınmaları ve yanlış yanıt olmamasını gerektirir. Sıralamaya giren her derlemenin on geçerli tekrarı olmalıdır. Zamanlama değerlendirmesi sırasında hiçbir kod değişmedi.

Bu, yapılandırma başına bir proje ve seçilmiş bir eğilimdir. Dört aşama ilişkilidir ve 156 devralma çifti vericileri ve alıcıları paylaşır. Aralıklar bu sunucudaki tekrar değişkenliğini tanımlar; başka görevleri, makineleri veya bağımsız kodlama çalıştırmalarını kapsamaz. Bulgular; genel bir kodlama yeteneği, kod kavrayışı veya üretim bakım yapılabilirliği sıralamasından ziyade bu iş yükleri altındaki bu yapıtları tanımlar.

Kıyaslamalarımızı ve veri odaklı içgörülerimizi kaçırmayın. Düğme Google'ı açar; AIMultiple'ı seçmeniz, Google arama sonuçlarında AIMultiple'ı daha sık görmek istediğinizi onaylar.

Tercih edilen kaynak olarak ekle

Sırada ne var?

Sonraki deneyler daha fazla proje ve bağımsız kodlama eğilimi ekleyecek, sunulan yük tavanına ulaşan aşamaların zorluğunu artıracak ve aynı iş yükü altında geçerli öncesi/sonrası sürümleri ölçecektir. Yeni oturumda öz devam kontrolleri, konuşma geçmişinin etkilerini başka bir ajanın koduyla başlamaktan ayırmaya yardımcı olacaktır.

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{alper2026,
  author = {Alper, Şevval},
  title  = {{AIM-Code Bench: Ajan Tabanlı Kodlama Kıyaslaması}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/agentic-llm}},
  note   = {AIMultiple. Erişim tarihi: 22 Eylül 2026}
}

Değişiklik günlüğü

13 güncelleme

Tümü13Genel9Metodoloji4

2026

1. 23 Tem

   Kimi K3 ve Inkling model sonuçları karşılaştırma tablosuna eklendi.

2. 23 Tem

   Kimi K3 ve Inkling, ajan kodlama karşılaştırmasına eklendi.

3. 10 Tem

   Kodlama karşılaştırmasına Grok 4.5 ve GPT 5.6 model ailesi eklendi.

4. 10 Tem

   Karşılaştırmaya yedi model eklendi: Grok 4.5 ve GPT-5.6 ailesi (Sol, Terra, Luna).

5. 2 Tem

   Eklendi: Backend puanlama bölümüne kod uzmanı modeller GPT 5.3 Codex ve Kimi K2.7 Code karşılaştırması.

6. 1 Tem

   Claude Sonnet 5, 0.772 genel puanla kıyaslama liderlik tablosuna eklendi.

7. 15 Haz

   Kimi K2.7 Code ve Claude Fable 5, kıyaslama sonuçlarına ve maliyet karşılaştırması bölümlerine eklendi.

8. 15 Haz

   Test düzeneği metodolojisi güncellendi: Claude Fable 5, OpenRouter üzerinden Opencode yerine Claude Code CLI aboneliğinde çalıştırıldı.

9. 3 Haz

   Karşılaştırma tablosuna ve maliyet karşılaştırmalarına Claude Opus 4.8, Gemini 3.5 Flash ve MiniMax M3 eklendi.

10. 20 May

    Kıyaslanan model listesi ve tüm başarı, maliyet ve gecikme sonuçları yeni değerlerle değiştirildi.

11. 20 May

    Ajan koşum ortamı olarak Aider yerine opencode kullanıldı ve varyansı ölçmek için hücre başına üç çalıştırma eklendi.

12. 3 Nis

    Kıyaslama sonuçları özetinde Gemini 3 Pro, Gemini 3.1 Pro Preview ile değiştirildi.

13. 24 Şub

    Agentic LLM kıyaslama sonuçlarına Gemini 3.1 Pro Preview eklendi.

Şevval Alper

Yapay Zeka Araştırmacısı

Takip Et

Şevval, AIMultiple'da bir yapay zeka araştırmacısıdır. Kaotik sistemler kullanarak sözde rastgele sayı üretimi konusunda daha önce araştırma deneyimine sahiptir.
Şevval, yapay zeka kodlama araçları, yapay zeka ajanları ve kuantum teknolojilerine odaklanmaktadır.

Tam Profili Görüntüle

Yorum yapan ilk kişi olun

E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.

Ad

E-posta Adresi

Yorum

0/450

Yorumu Gönder