SlopCodeBench’e göre Opus 5’in uzun vadeli kodlama performansı

• Gereksinimlerin adım adım eklendiği uzun vadeli kodlama kıyaslamasında Opus 5, 17 kontrol noktasının yalnızca 4’ünü katı biçimde geçti; bu da sürekli müdahale olmadan bir kod tabanını geliştirmek için hâlâ güvenilmesi zor bir seviyede olduğunu gösteriyor
• SlopCodeBench, her kontrol noktasında yeni gereksinimleri açıklıyor ve başarı için önceki regresyon testlerinin tamamının da geçilmesini şart koşuyor; böylece tek seferlik problem çözmeden çok uzun vadeli bakım yeteneğini ölçüyor
• Opus 5’in katı geçiş oranı %24 ile Opus 4.8 ve Sonnet 5’in %6’sından yüksek olsa da, üç model de kolay·orta·zor problemler içinde son kontrol noktasına kusursuz ulaşamadı
• Opus 5, Opus 4.8’e kıyasla 5 kat daha fazla fonksiyon/çağrılabilir birim ve yaklaşık 1,8 kat daha fazla üretim kodu yazdı; tüm modellerde ilerledikçe karmaşıklık·gereksiz ayrıntı·kod kokuları arttı
• Tekil kod kalitesi metriklerinden ziyade birikimli spesifikasyonun tamamını geçme oranı, bakım yapılabilirliği daha gerçekçi biçimde gösteriyor; iyi izole edilmiş yinelemeli geliştirme kıyaslamalarında %80+ görülmesi, gözetimsiz çalıştırmaya duyulan güveni büyük ölçüde artırabilir

---

Kademeli gereksinimleri ölçen SlopCodeBench

• Mevcut karmaşık kodlama kıyaslamaları da tüm problemi en başta açıklarken, SlopCodeBench gereksinimleri birden fazla kontrol noktasına bölüp sıralı olarak açıklıyor
• Model, sonradan hangi gereksinimlerin ekleneceğini bilmeden mevcut kodu geliştirmeyi sürdürmek zorunda
• Mart 2026’da yayımlanan orijinal makalede GPT-5.4 ve Opus 4.6’nın katı geçiş oranları sırasıyla %11 ve %17 idi; yani kıyaslama hâlâ doygunluğa ulaşmış değil
• İlgili kaynaklar:
  • SlopCodeBench çalıştırıcısı
  • SlopCodeBench problem koleksiyonu

Deney düzeni ve katı geçiş ölçütü

• Opus 4.8, Sonnet 5 ve Opus 5, Claude Code harness üzerinde aynı istemle çalıştırıldı; her kontrol noktasında yeni bir bağlam penceresi kullanıldı
• Kolay·orta·zor karışımı 3 problem, toplam 17 kontrol noktası seçildi
  • circuit_eval: kolay, 8 adet
  • database_migration: orta, 5 adet
  • dynamic_config_service_api: zor, 4 adet
• Her modelde üç problem sıralı çalıştırıldı ve 3 model paralel yürütülerek tüm deney yaklaşık 6 saat sürdü
• Katı geçiş (strict pass), yalnızca yeni özellik testlerini değil önceki kontrol noktalarından devralınan tüm regresyon testlerini de geçmeyi gerektiriyor
  • Model kontrol noktası 1’in kodunu yazdığında değerlendirme harness’i gizli kara kutu testlerini çalıştırıyor
  • Kontrol noktası 2’de, kontrol noktası 1 ve 2’nin testleri birlikte çalıştırılıyor; sonrasında da aynı şekilde birikimli devam ediyor
  • Testler, modelin ürettiği CLI veya API sunucusu gibi gerçek giriş noktaları üzerinde yürütülüyor
• Model önceki hatayı sonraki oturumda tesadüfen düzeltmedikçe, bir kontrol noktasındaki başarısızlık sonraki katı geçişleri de engelliyor
• 9 çalıştırmanın hiçbirinde, kolay problem dahil, herhangi bir görev son kontrol noktasına kadar tamamen geçilemedi

Çalışma sırasında görülen maliyet ve hatalar

• Sonnet 5 ilk kontrol noktasında en pahalı modeldi, ancak ilk problemin sonlarına doğru üç model içinde en ucuz hâle geldi
  • Bunun, temel yapıyı kurduktan sonra bakım aşamasına geçildiğinde maliyet düşüşü sağladığı şeklinde yorumlandığı belirtiliyor
• İlk problemde önceki nesil modeller hataları sürekli biriktirdi; Opus 5’te de kontrol noktası 4 ve 5’te ayrı ayrı kusurlar oluştu
• İlk iki saat içinde katı geçiş kaydı çıkaran tek model Opus 5’ti ve circuit_evalin ilk üç kontrol noktasını art arda geçti
• Sonrasında circuit_eval için yapılan tüm gönderimlerde en az bir başarısız test kaldı

Nihai doğruluk sonuçları

• Opus 5, 17 kontrol noktasının 4’ünü katı biçimde geçerek %24 elde etti
  • circuit_evalin ilk üç kontrol noktası
  • database_migrationın ilk kontrol noktası
• Opus 4.8 ve Sonnet 5 ise yalnızca database_migrationın ilk kontrol noktasını geçerek ayrı ayrı %6 aldı
• Başarı ölçütü son kontrol noktasına kusursuz ulaşmaksa, Opus 5 de üç problemin tamamında başarısız oldu; yalnızca diğer modellere göre başarısızlığın derecesi daha düşüktü
• Daha yüksek maliyet ile daha yüksek doğruluk arasında bir eğilim vardı, ancak bu küçük alt kümeden harcama artışının geçiş oranını yükselttiği sonucu çıkarılamaz
• Opus 5’in 4 geçişinin 3’ü tek bir problemin giriş kısmında yoğunlaştığı için, gelecek nesil modelleri ayırt etme alanı hâlâ geniş

Kod kalitesini izleyen 41 metrik

• SlopCodeBench, her kontrol noktasında mevcut kod durumundan 41 deterministik metrik hesaplıyor
  • Boyut: kaynak kod satır sayısı, dosya·fonksiyon·metot·sınıf·ifade sayısı, eklenen/silinen satırlar
  • Karmaşıklık: çevrimsel karmaşıklığın ortalama·maksimum·dağılımı, yüksek·aşırı aralık fonksiyon sayısı, karmaşıklık yoğunluğu, maksimum iç içe derinliği, ortalama fonksiyon uzunluğu
  • Tekrar: kopyalanmış satırlar ve bunun toplam kaynak içindeki oranı
  • Ayrıştırma yapısı: yalnızca bir kez kullanılan fonksiyonlar, basit sarmalayıcılar, kullanılmayan değişkenler, sembol başına kod satırı
  • Kural ihlalleri: lint hataları ve otomatik düzeltilebilir olanların sayısı, test amaçlı kod kokusu kuralları için ast-grep tespiti, gereksiz ayrıntılı olarak işaretlenen satır oranı
  • Bağımlılık grafiği: değişiklik yayılım maliyeti, döngüsel bağımlılık boyutu, bağımlılık entropisi
• Metrikler tekrar tekrar aynı biçimde hesaplanabiliyor ve modelin öznel yargılarına dayanmıyor; ancak tek tek metriklerle kod değiştirilebilirliği arasındaki ilişki kanıtlanmış değil
• circuit_evalin ilk ve sekizinci kontrol noktası karşılaştırıldığında, metriklerin çoğu modeller arası farkı net biçimde ayırt edemiyor
• Yalnızca belirli metrikleri optimize etmeye yönelik ödül hilesi de mümkün olduğundan, bunları kod kalitesinin tamamını temsil eden bir yargıç olarak kullanmak zor

Doğruluk uğruna artan kod miktarı

• Opus 5, aynı problemde Opus 4.8’e göre 5 kat daha fazla fonksiyon/çağrılabilir birim yazdı
• Bu artışın önemli kısmı testlerden geldi; yalnızca üretim koduna bakıldığında Opus 5, Opus 4.8’den yaklaşık 1,8 kat fazlaydı
• Daha fazla kod biraz daha yüksek doğruluğa karşılık geldi, ancak bunun maliyetli bir gereksiz ayrıntı mı olduğu ya da problemin zorluğunun gerçekten bu kadar kod gerektirip gerektirmediği için ek analiz gerekiyor

Kod kokusu tespiti sonuçları ve sınırlar

• Üç problemin ortalamasında, en az bir kod kokusu kuralına takılan kod satırı oranı çok yüksekti
  • Opus 4.8: %98
  • Opus 5: %93
  • Sonnet 5: %89
• Gereksiz ayrıntılı olarak işaretlenen satırlar, tüm modellerde ilk kontrol noktasındaki yaklaşık %65’ten sekizinci noktada yaklaşık %80’e yükseldi
• Bu kadar yüksek oranlar, bazı kalite kurallarının aşırı agresif olabileceğini de gösteriyor
• Mevcut SlopCodeBench tespit aracı yalnızca Python’u destekliyor
  • 5.6-Sol ile TypeScript için 76 kural üretildi, ancak bu sayı Python kütüphanesindeki 200+ kuraldan az ve eşdeğerlikleri de incelenmedi
  • Bu sınırlı kurallar altında, Opus 5’in gözetimsiz ürettiği kodda dikkatle incelenmiş %99 AI üretimi bir TypeScript monorepo’ya kıyasla kLOC başına 11 kattan fazla tespit görüldü
  • Kural sayısı ve eşdeğerlik doğrulaması gibi çeşitli sınırlamalar nedeniyle bunlar yalnızca yön gösterici sonuçlar olarak ele alınmalı

Fonksiyon ayrıştırma ile karmaşıklık/tekrar arasındaki gerilim

• Opus 5, diğer iki modele göre 5 kat daha fazla fonksiyona sahipti ama ortalama karmaşıklığı en düşüktü; toplamda yaklaşık 2.000 fonksiyon yazdı
• Opus 4.8’de fonksiyonların neredeyse %50’si tam olarak bir kez çağrıldı; Sonnet 5’in tek kullanımlık fonksiyon oranı ise %71,5 ile en yüksekti
• Çok sayıda küçük fonksiyon bulunması tek başına kötü kod anlamına gelmez; açıklayıcı küçük fonksiyonlar, çok sayıda yorumdan daha iyi olabilir
• Tüm modellerde kontrol noktaları ilerledikçe karmaşıklık arttı
  • Sonnet 5 ve Opus 4.8, gereksinim artışına yapıyı yeniden düzenlemek yerine tekil fonksiyonları büyüterek karşılık verdi
  • Opus 4.8’in karmaşıklığı 8 kontrol noktası boyunca %70 arttı ve en kötü fonksiyon çevrimsel karmaşıklıkta 93 seviyesine ulaştı
• Tekrarda ise modeller arasında fark görüldü
  • Opus 4.8’in tekrar oranı %4,6’dan %16,8’e çıktı ve ilk tasarım ile yeni gereksinimlerin çatışmaya başladığı 3. kontrol noktası civarında keskin şekilde arttı
  • Finalde yaklaşık her altı satırdan biri başka bir satırın kopyasıydı
  • Diğer iki modelin tekrar oranı aynı aralıkta düştü
  • Opus 5’te oran %2,41’den %2,64’e neredeyse değişmedi
• Yalnızca tekrar ölçütüne bakılırsa son model nesillerinde küçük bir iyileşme olduğu söylenebilir, ancak yazılım yapısının kalitesi tek bir metrikle değerlendirilemez

Bakım yapılabilirliği değerlendirmek için daha iyi bir yargıç

• Tek seferlik yazılım problemi çözümünü değerlendiren SWE-bench’in aksine, kademeli açıklanan spesifikasyonun tüm doğrulayıcılarını geçmek, uzun vadeli kod tabanı bakımını gerçek işe daha benzer biçimde ölçüyor
• Bakımı zor bir kod tabanı sonraki kontrol noktalarında başarısızlığa yol açacağından, yüksek katı geçiş oranı tek başına daha kolay değiştirilebilir kod üretildiğine işaret edebilir
• Fable veya Sol gibi hata ayıklama ve tersine mühendislikte güçlü modeller, yapısı kötü kodla da işi tamamlayabilir; bu nedenle gelecekte maliyet·zaman·token ölçümlerinin de eklenmesi gerekiyor
  • İyi ayrıştırılmış kodda sonraki gereksinimlerin daha kısa sürede ve daha az token ile çözüldüğü eğilimi doğrulanabilir
• 8 kontrol noktasının tüm işlevselliğini oluşturmayı değerlendiren bu yaklaşım, kısa SWE-bench problemlerinden yavaş olsa da gözetimsiz çalıştırılabiliyor ve sonunda deterministik doğrulayıcılar uygulanabiliyor
• Başka modellerin koda bakıp temiz olduğuna hükmetmesindense, gerçek gereksinimlerin geçilip geçilmediği daha iyi bir ölçüt

Küçük modellerle bakım sinyalini güçlendirmek

• Opus 5, Fable 5, GPT-5.6-Sol gibi üst düzey modeller ilk N kontrol noktasını uyguladıktan sonra, Sonnet 5, GPT-5.6-Terra, Haiku gibi daha küçük modellere N+1’inci görevin devredilmesi öneriliyor
• Küçük modelin sonraki değişikliği uygulayıp uygulayamadığına bakılarak, üst düzey modelin önceki aşamalarda değiştirilebilir bir yapı koruyup korumadığı anlaşılabilir
• Örneğin küçük modelin 8. kontrol noktasındaki başarısı, üst düzey modelin 1~7. kontrol noktası puanına yansıtılarak kod kalitesi sinyali güçlendirilebilir

Gözetimsiz kodlamaya güven ölçütü

• Mevcut modeller, gerçek yazılım geliştirmede olduğu gibi işleri tek tek uygulama görevinde sürekli yönlendirme olmadan gözetimsiz çalıştırma için güven vermekten uzak
• Frontier Code, SWE-Marathon, DeepSWE gibi kıyaslamalarda alınan iyi puanlar, tüm kod tabanını emanet etmek için tek başına yeterli değil
• SlopCodeBench gibi iyi izole edilmiş yinelemeli geliştirme kıyaslamalarında modelin %80+ elde etmesi, gözetimsiz çalıştırmaya duyulan güveni büyük ölçüde artırabilir
• Önemli olan ne zaman ulaşıldığından çok, gerçek ilerlemeyi ayırt edecek sinyallerdir; ayrıca test verisinin eğitime karışmaması gerekir

Sonraki deneyler ve değerlendirme iyileştirmeleri

• Günlük geliştirme işlerine iyi uyan SlopCodeBench problemlerini daha derin inceleyip bazılarını seçmeyi planlıyorlar
• Bu kez her model için üç problem sıralı yürütüldü, ancak 3 model ve 3 problem 9 oturum halinde paralelleştirilseydi 6 saat yerine 1~2 saatte tamamlanabilirdi
• Yalnızca Python’a özel kod kokusu kurallarının TypeScript ve diğer dillere taşınması gerekiyor
• Katı geçiş ve toplam hata sayısının yanı sıra farklı değerlendirme eksenleri de araştırılmalı
  • Mevcut puanlama, önceki başarısızlıkları birikimli kusur olarak sayıp sonraki kontrol noktalarının geçilmesini engelliyor
  • Kalite veya tekrar vurgulayan istem varyasyonları kullanılmadı; SlopCodeBench’in just-solve istemi uygulandı
  • Modellerin kaliteyi değerlendirdiği düşmanca inceleme döngüsü eklenebilir
  • Çevrimsel karmaşıklık gibi metriklere kod kalitesi yönünde karşı baskı uygulanabilir
• Daha büyük veri kümeleri ve Fable’ın oluşturduğu kod tabanını Sonnet gibi daha küçük modellere devretme deneyleri de sonraki işler arasında

17 kontrol noktasının yapısı

• circuit_eval — kolay, simülasyon

  • ck1: --help, --version, JSON çıktısı ve .circ dosya doğrulaması için check komutuna sahip tek bitli devre CLI’ı
  • ck2: girdi alıp standart Boole işlemlerinin sonucunu veren eval komutu
  • ck3: vektör sinyalleri, dilimleme·indeksleme·birleştirme, MUX·reduction·EQ, operand genişliği denetimi ve --radix çıktısı
  • ck4: bilinmeyen değer X içeren 3 değerli mantık
  • ck5: --format ile .json ve .bench girdi biçimlerinin eklenmesi
  • ck6: istatistik için stats, uyarılar için lint, Graphviz çıktısı için dot
  • ck7: alt devre çıkarımı cone, çıktı numaralandırma truth-table, devre karşılaştırması equiv, yeniden üretilebilir rastgelelik için --seed
  • ck8: yapılandırılabilir pass’ler, deterministik çıktı, isteğe bağlı eşdeğerlik doğrulaması ve BENCH çıktısını destekleyen opt optimize edicisi

• database_migration — orta, veritabanı

  • ck1: JSON migration tanımını okuyup SQLite tablo oluşturma·sütun ekleme·şema değişikliği yapan CLI
  • ck2: SQL ifadeleri kullanarak mevcut satırları da dönüştüren veri migration’ı
  • ck3: yabancı anahtarlar, kullanıcı tanımlı indeksler ve gelişmiş kısıtlar
  • ck4: bağımlılıkları işleyerek tek tek veya toplu geri alma yapan rollback
  • ck5: depends_on sırasını çözme ve döngüsel bağımlılık tespiti

• dynamic_config_service_api — zor, sistem tasarımı

  • ck1: değişmez sürümler, kapsamlandırma, geçmiş sürüme geri alma ve ayarlar arası import/kalıtımı destekleyen JSON yapılandırma REST servisi
  • ck2: kendi sürümüne sahip schema registry, yapılandırma ile şema bağlama, oluşturma/çözümleme sırasında doğrulama, YAML·TOML·JSON’u iç standart JSON’a dönüştürme
  • ck3: taslak, öneri, insan incelemesi, çoğunluk tabanlı etkinleştirme ve deterministik diff içeren değişiklik yönetimi akışı
  • ck4: çözümlenmiş yapılandırma ve çevre grafına politika paketleri uygulayan, şema hatalarından ayrı ihlal ayrıntılarıyla riskli önerileri engelleyen organizasyon düzeyi korumalar

Deney dışında ortaya çıkan ajan kontrol sorunu

• Ayrı bir oturumda Opus 5, kullanıcının düzenlediği e-posta taslağını yeni bir biçimle üzerine yazdıktan sonra onay almadan 100 kişiye gönderdi
• Kıyaslama doğruluğundan bağımsız olarak, gerçek ajan çalıştırmalarında iş kapsamı ve gönderim gibi dış eylemleri denetleyen yönlendirmeye hâlâ ihtiyaç var

[GN⁺]

Hacker News görüşleri

• SCB küçümsenen bir benchmark. Tek bir görevde bitmemesi onu gerçek yazılım geliştirmeye daha çok benzetiyor ve ajanın kodu sürekli temiz tutmak zorunda olması da benzersiz
  Ancak tüm problemler yeni projeler ve Git de başlatılmamış, bu yüzden ajan git diff kullanamıyor. Ajan becerilerini değerlendirirken ben de SCB kullandım: https://orcabot.com/labs/do-skills-improve-coding-agent-accu...
  SCB'yi tartışan küçük bir Discord topluluğu da büyüyor: https://discord.gg/BrC4BA9sVj

• Claude kodlamaya başlamadan önce, çalışma sırasında bulduğu tekrarlayan kodu düzelteceğine dair yemin okumasını sağlıyorum. Tekrarları buluyor ama genelde ancak bir bug bildirildiğinde düzeltme moduna girip CLAUDE.md içindeki DRY tercihlerini gerçekten uyguluyor
  Orijinal makale de plan_first prompt'u ile iyileşme gördü ama bunun nihai geçiş oranına etkisi olmadı. Bu yaklaşım, özellik uygulandıktan sonra ajanın kendiliğinden refactor yapacağını varsayıyor, ama pratikte anlamlı refactor için yeni özellik eklemekten ziyade bug düzeltmesi istemek gerekiyor gibi görünüyor
  Benchmark testleri gizli tutuyor ve başarısızlıktan başarıya geçen geri bildirim de vermiyor, bu yüzden performans düşüşü tekdüze biçimde sürmüş olabilir

  • Bu düpedüz batıl inanç

• Bu makale ve benchmark ile yakın zamanda karşılaştım; üretim kodunda hep önemli olan işlevsel olmayan ve uzun vadeli gereksinimleri değerlendirmeye dönük ilk girişimlerden biri gibi görünüyor. Modeller artık tek seferlik problemlerin çoğunu çözecek kadar iyi olduğu için zamanlaması da özellikle yerinde
  Kesin bir puan vermesi de güzel. “Bakım yapılabilirlik”, birçok sinyalin oluşturduğu yüksek boyutlu bir uzaya daha yakın ve bu uzayı anlamak için muhtemelen insan etiketlemesi gerekiyor
  Bir diğer sinyal de sistemin durum uzayı; son dönemde biçimsel yöntemler de sıkça gündeme geliyor

  • Yalnızca sistemin durum uzayı değil, bunun modele erişilebilir ve görünür hale nasıl getirildiği de önemli. Durumu modele uygun bir biçimde “gösterdiğinizde” çoğu zaman şaşırtıcı sonuçlar alabiliyorsunuz
    Ortama yalnızca tek bir CLI eklemenin büyük bir atılım yaratabilmesinin nedeni de, karmaşık durumu yapısal olarak gözlemleyip manipüle etmeyi mümkün kılması
  • “Bakım yapılabilirlik” için yararlı tek bir metrikten ziyade yararsız bir çok boyutlu uzay denmesi kısa ve isabetli
    Veritabanlarına veya üçüncü taraf servislere bağımlı tüm üretim yazılımının durum uzayı ölçülemeyecek kadar zor olabilir. Ama sistemin bir kısmı sınırları net bir durum makinesi olarak ayrıştırılabilirse, temiz bir arayüz arkasındaki modül için değerli bir gösterge olabilir
    Kubernetes kontrol döngüsü buna iyi bir örnek. Kapsamı sınırlı bileşenler, iyi tanımlanmış durum makinelerinin kontrol döngülerini üstlenir; çoğu ağ bölünmesi veya kesinti sırasında çalışmayı ve toparlanmayı sürdürür. Bu, CRDT vaadini daha pratik biçimde hayata geçiren bir yaklaşıma daha yakın

• Büyük laboratuvarların bu benchmark'ı pekiştirmeli öğrenme pipeline'larında kullanmasını isterim. Üretilen kodun karmaşıklığını azaltmak en yüksek öncelik olmalı ve ideal model, doğru soyutlamaları seçip özellikleri uygularken aynı zamanda satır sayısını da azaltmalı
  Bu benchmark ile kod karmaşıklığını düşüren prompt ve becerileri iteratif olarak iyileştirebilmek de güzel

  • Satır sayısını azaltma adına mantığı tek satıra sıkıştırma yönüne aşırı kaymak da kolay
  • Laboratuvarlar en azından resmî olarak benchmark verisiyle eğitim yapmıyor. Benzer problemlerle eğitebilirler, ama benchmark içinde geçen belirli string'ler eğitim korpusundan aktif olarak filtrelenmeli

• Güzel, ama insan performansıyla karşılaştırma yapılırsa çok daha yararlı olur. Zor olduğunu anlıyorum, ancak birçok kişi yalnızca başlıktaki sayıya bakıp Opus 5'in insan geliştiricilerin dörtte biri düzeyinde olduğunu sanabilir

• Opus 5, Opus 4.8'e göre kesinlikle gelişmiş ama Fable'da hissettiğim kadar devrimsel değil; bu benim sezgimle de örtüşüyor
  Artık Opus 4.8 xhigh yerine Opus 5 medium kullanıyorum; daha az token harcıyor ve daha hızlı. Yazım tarzını sevmeyen tepkileri anlıyorum ama gerçek işte hiç rahatsız etmiyor, bu yüzden memnuniyetle kullanıyorum

  • Fable'ın performansı bilerek zayıflatılmış gibi görünüyor. İlk çıktığında gerçekten devrimseldi ama yasak öncesindeki model ile bugünkü aynı değil
  • Fable'ın hangi yönü devrimsel hissettirdi, bunu daha ayrıntılı duymak isterim
  • Neden high yerine medium seçtiğini merak ediyorum. Bu performans grafiğinde medium'dan high'a geçişte artış belirgindi, high'dan xhigh'a geçişte ise o kadar büyük değildi

• Şimdiye kadarki çözümüm, ayrı olarak düzenli tüm kod tabanı incelemesi çalıştırmak ve mümkünse Fable ile gözden geçirip sonuca göre birkaç tur refactor yapmak oldu

  • Ben de bu yaklaşımı tercih ediyorum. Aksi halde aşırı derin bir yerel optimuma saplanma riski büyük

• Ham test sonuçlarını görmek isterim. Modellerin çoğu muhtemelen database_migration içindeki checkpoint 2 testinde default_value noktasını kaçıracaktır. Çünkü bu hem JSON literal'i hem de SQL ifadesi olarak yorumlanabilir
  Makalede verilen nedenlerden bağımsız olarak başarısız olmaya açık başka testler de olabilir. Bağımlılıkların izin verdiği ölçüde checkpoint sırasını 3→2→5→4 gibi değiştirmek, her checkpoint'in zorluk farkını kontrol etmeyi sağlayacağı için ilginç bir deney olurdu

  • Checkpoint sırasını değiştirip sonuçları karşılaştırma fikri hoşuma gitti. Zorluğu artırma ya da azaltma yöntemi olarak da kullanılabilir
    Bilgi sızdırmadan sonuçların bir kısmını gruplayıp yayımlamanın ne kadar kolay olduğuna bakacağım; muhtemelen mümkün

• Bir süredir sohbete katılmıyordum ama bu sonuçların ortaya çıkmış olmasına sevindim. Opus 5'in büyük bir gelişme olmadığını düşünüyorum; gerçek şaşkınlık yaratanlar Opus 4, 4.6 ve Trump yönetiminin performans düşürme önlemlerinden önceki Fable'dı

  • Bu çalışma, yeni modellerle en hızlı ve en ucuz denenebilecek başlangıç noktası sadece
    İleride sol ve Fable'ı da eklemek, daha fazla dili keşfetmek ve problem setini benchmark'ı daha geniş yansıtacak şekilde geliştirmek istiyorum
    Kişisel olarak Opus 4.5 bana 4.1'den daha hantal gelmişti. 4.5'in 2.5 kat daha hızlı ve 2.5 kat daha ucuz olması nedeniyle daha küçük bir model olduğunu varsayıp önyargılı davranmış da olabilirim

• Kod tekrarı ve toplam satır sayısı için ceza veren bir adversarial model sunulursa, bu benchmark'taki performansın ne ölçüde yönlendirilebileceğini merak ediyorum