GPT-5.5 low vs medium vs high vs xhigh: Açık kaynak depolarındaki 26 gerçek görevde görülen akıl yürütme eğrisi

 (reddit.com)
5 puan yazan GN⁺ 8 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • GPT-5.5 Codex, GraphQL-go-tools içindeki 26 gerçek görevde low, medium, high, xhigh ayarlarıyla çalıştırıldığında, muhakeme eforu farkı test geçmeden çok insan yamasıyla anlamsal eşdeğerlik ve kod incelemesinden geçme oranında daha belirgin ortaya çıktı
  • Test geçme sonuçları low 21/26, medium 21/26, high 25/26, xhigh 24/26 oldu; ancak anlamsal eşdeğerlik 4/26 → 11/26 → 18/26 → 23/26 olarak arttı ve kod incelemesinden geçme de 3/26 → 5/26 → 10/26 → 18/26 seviyesine yükseldi
  • high, medium'a kıyasla test geçme, eşdeğerlik ve incelemeden geçme metriklerinin tümünü iyileştirirken ortalama maliyet $3.13'ten $4.49'a, yani 1.43 katına çıktı; bu yüzden bu veri kümesinde en pratik varsayılan ayar gibi görünüyor
  • xhigh, high'a göre eşdeğerlik ve inceleme kalitesini belirgin biçimde artırdı; ancak ortalama maliyet $9.77'ye, ortalama çalışma süresi 753.3 saniyeye yükseldi ve daha fazla test, fixture ve expected-output değişikliği üreterek footprint riskini de artırdı
  • Muhakeme eforunun etkisi görevler arasında tekdüze değildi; bazı durumlarda high, xhigh'ı geçti ya da daha yüksek ayarlar makul görünen ama yanlış uygulamalar üretti; bu yüzden ekiplerin genel benchmark'lar yerine kendi harness'lerinde ve kendi görevlerinde ölçüm yapması gerekiyor

Deneyin amacı ve değerlendirme yöntemi

  • GPT-5.5 Codex, aynı açık kaynak depo görevlerinden oluşan 26 görev üzerinde low, medium, high, xhigh muhakeme eforu ayarlarıyla ayrı ayrı çalıştırıldı; amaç yalnızca test geçmeyi değil, insanlar tarafından merge edilmiş PR'lerle anlamsal eşdeğerlik ve inceleme edilebilirliği de karşılaştırmaktı
  • Hedef depo, Go tabanlı GraphQL-go-tools; her görev gerçek bir merge edilmiş PR veya commit'ten türetildi
  • Her görev, sabit bir depo anlık görüntüsü, değişiklik isteği prompt'u ve Docker konteyneri içinde yama üreten tek bir denemeden oluştu
  • Stet, üretilen yamayı uygulayıp izole edilmiş konteynerde göreve özel testleri çalıştırarak geçip geçmediğini doğruladı
  • Testlerden sonra şu ölçütlerle ek değerlendirme yapıldı
    • Eşdeğerlik: Aday yamanın, orijinal insan yapımı yamayla aynı davranış değişikliğini sağlayıp sağlamadığı
    • Kod incelemesinden geçme: Doğruluk, hata sokma riski, bakım yapılabilirlik ve edge case'ler dikkate alındığında bir incelemeci tarafından kabul edilip edilmeyeceği
    • Footprint riski: İnsan yapımı yamaya kıyasla ajanının fazladan ne kadar koda dokunduğu
    • İşçilik/disiplin rubriği: Açıklık, sadelik, tutarlılık, niyet açıklığı, sağlamlık, talimatlara uyum, kapsam disiplini ve diff minimalliği değerlendirildi
  • Tüm modeller görev başına bir kez, tek seed ile çalıştırıldı
  • LLM hakem modeli GPT-5.4'tü ve hakem yalnızca yamaları ve görevi gördü; hangi modelin veya muhakeme ayarının yamayı ürettiğini görmedi
  • Temsilî örnekler elle de doğrulandı; ancak bu görev seti için ayrı bir insan kalibrasyonu yapılmadığından, tek bir mutlak skordan çok artış-azalış yönüne güvenmek gerekiyor
  • Çalıştırma ayrıntıları
    • Model: GPT-5.5
    • Harness: Codex 0.128.0
    • Veri kümesi: gerçek GraphQL-go-tools görevlerinden 26 örnek
    • Ana metrikler: test geçme, anlamsal eşdeğerlik, kod incelemesinden geçme, footprint riski, işçilik/disiplin için özel değerlendirme, maliyet ve çalışma süresi
  • Etkileşimli grafikler ve görev bazında ayrıntılı analizler https://stet.sh/blog/gpt-55-codex-graphql-reasoning-curve adresinde yer alıyor
  • Aynı değerlendirme, AGENTS.md dosyasını iyileştiren otomatik araştırma döngüsünde de kullanılıyor
    • Ajan, depoya özel AGENTS.md iyileştirme önerileri hazırlıyor; ardından geçmiş görevler Stet ile çalıştırılıyor ve nerelerde iyileşme ya da kötüleşme olduğu bulunarak yineleme yapılıyor

Genel metrikler ve yorum

  • Genel metrikler, muhakeme eforu arttıkça farkın test geçmeden çok anlamsal eşdeğerlik ve incelemeden geçme oranında büyüdüğünü gösteriyor
  • Temel sonuçlar
    • Test geçme: low 21/26, medium 21/26, high 25/26, xhigh 24/26
    • İnsan yamasıyla eşdeğerlik: low 4/26, medium 11/26, high 18/26, xhigh 23/26
    • Kod incelemesinden geçme: low 3/26, medium 5/26, high 10/26, xhigh 18/26
    • İşçilik/disiplin ortalaması: low 2.311, medium 2.604, high 2.736, xhigh 3.071
    • Görev başına ortalama maliyet: low $2.65, medium $3.13, high $4.49, xhigh $9.77
    • Ortalama ajan çalışma süresi: low 286.9 saniye, medium 411.0 saniye, high 579.0 saniye, xhigh 753.3 saniye
  • low ve medium, test geçmede 21/26 ile aynı sonucu verdi; ancak eşdeğerlik 4/26'dan 11/26'ya, incelemeden geçme ise 3/26'dan 5/26'ya yükseldi
  • high, medium'a kıyasla test geçmeyi +15.4 yüzde puan, eşdeğerliği +26.9 yüzde puan ve incelemeden geçmeyi +19.2 yüzde puan artırarak pratik açıdan en belirgin iyileşmeyi sundu
  • xhigh, high'a kıyasla test geçmede -3.8 yüzde puan geride kaldı; ancak eşdeğerlikte +19.2 yüzde puan, incelemeden geçmede ise +30.8 yüzde puan artış sağladı
  • Muhakeme eforu yalnızca test geçme oranını değiştirmiyor; Codex'in ürettiği yama türünü de değiştiriyor gibi görünüyor
  • Kamusal benchmark'lar çoğu zaman görevin ikili olarak başarıp başarmadığını yanıtlıyor; oysa gerçek yazılım mühendisliğinde bir yamanın merge edilebilir ve sonrasında bakımının yapılabilir olması da önemli
  • Terminal-Bench ağırlıkla zorlu kodlama problemlerine odaklanıyor, SWE-bench verified'da modelin yanıtı zaten görmüş olma ihtimali var ve SWE-bench Pro faydalı olsa da daha genel nitelikte kalıyor
  • Bu deneyin asıl odağı, “ajan benim kod tabanımda insanların merge ettiği türde bir değişiklik yaptı mı?” ve “bu yamaya sonrasında sahip çıkmak ister miyim?” soruları

low'dan medium'a: sezgisel yaklaşımından alan modellemeye geçiş

  • low ve medium, test geçmede ikisi de 21/26 olduğundan, yalnızca testlere bakıldığında berabere görünüyordu
  • Ancak medium ile anlamsal eşdeğerlik 4/26'dan 11/26'ya çıktı ve işçilik/disiplin ortalaması da 2.311'den 2.604'e yükseldi
  • Bu aralıkta yalnızca testleri ölçmek, muhakeme eforu farkının büyük kısmını kaçırmak anlamına geliyor
  • low, testi geçen yamalarda bile bazen sezgisel kurallara veya kısmi uygulamalara takılı kalırken, medium depo yapısını ve alanın anlamını daha iyi modelleme yönüne kaydı
  • PR #1297 örneği
    • Görev, GraphQL Federation içinde nullable external @requires bağımlılıklarının doğrulanmasıyla ilgiliydi
    • Nullable required alan hata ile birlikte null dönerse, kirlenmiş bu entity downstream fetch bağımlılığına aktarılmamalı
    • Görevin özü basitçe bir doğrulama dalı eklemek değil, federation veri bağımlılığına dair incelikli kuralları modellemekti
    • low testi geçti; ancak required-field/error eşleşmesini sezgisel biçimde ele aldı ve yapılandırılmış nullable @requires metadata'sını kaçırdığı için eşdeğer sayılmadı ve incelemeden de geçemedi
    • medium, kirlenmiş nesneleri izleyip downstream fetch girdilerini filtreleyerek eşdeğerlik ve inceleme ölçütlerini geçti; işçilik/disiplin kalitesi de 1.350'den 3.225'e çıktı
    • high ve xhigh da benzer kalite bandında kaldığından, bu görev esas olarak low'dan medium'a geçişteki iyileşmeyi gösteriyor

high: pratik varsayılan ayara en yakın nokta

  • high, medium'a kıyasla test geçme, anlamsal eşdeğerlik ve inceleme geçişini birlikte iyileştirirken, maliyet artışı büyük olsa da aşırı olmayan bir düzeyde kalıyor
  • high ve medium karşılaştırması
    • Test geçme: 21/26'dan 25/26'ya yükseliyor
    • Eşdeğerlik: 11/26'dan 18/26'ya yükseliyor
    • Kod incelemesinden geçme: 5/26'dan 10/26'ya yükseliyor
    • Ortalama footprint riski: 0.268'den 0.314'e yükseliyor
    • Üretim/disiplin ortalaması: 2.604'ten 2.736'ya yükseliyor
    • Ortalama görev maliyeti: $3.13'ten $4.49'a çıkıyor, 1.43 kat
    • Ortalama çalışma süresi: 411.0 saniyeden 579.0 saniyeye çıkıyor
  • high, ek token'ların gerçek kazanca dönüştüğü nokta gibi görünüyor ve entegrasyon ayrıntılarını doğru tutturma oranı yükseliyor
  • PR #1209 örneği
    • Bu görevde gRPC datasource'un yanıt JSON'unda GraphQL alias'ı dikkate alması, referans verilen protobuf message type'ı önceden doğrulaması ve union/interface mutation yolu için eşleme kapsamını güncellemesi gerekiyor
    • low ve medium testleri geçti ama eşdeğer değildi ve incelemeyi de geçemedi
    • medium, alias serileştirmesi ve eksik message doğrulamasını büyük ölçüde ele aldı, ancak createUser mutation eşleme güncellemesini kaçırdı ve JSONPath üzerine response-key semantiğini fazla yükledi
    • high, açık bir response-key/alias işleme mekanizması getirdi ve alias'ı planlama ile JSON marshaling boyunca taşıyarak ilk sıkı geçişi sağladı
    • high'ın özel kalite puanı 3.625'e çıktı; yani sadece daha fazla kod eklemedi, entegrasyon yükümlülüklerini tam isabetle karşıladı
    • xhigh da geçti, ancak görev düzeyi yorumlamayı iyileştirmedi; yeniden üretilmiş özet ölçütüne göre ajan çalışma süresi de high'ın 314.0s süresinden uzun olan 790.7s oldu
  • PR #1155 örneği
    • Bu görev, repeated scalar field desteği, null/invalid message panic'inden kaçınma, gRPC status code aktarımı, datasource devre dışı bırakma ve dynamic client desteğini içeren bir gRPC datasource sağlamlaştırma işi
    • low ve medium testleri geçti ama eşdeğer değildi
    • medium dayanıklılığı artırdı, ancak invalid repeated field'ı empty array olarak serileştirdi, aliased-root planning davranışını kaçırdı ve dynamic-client yaşam döngüsü riskini açık bıraktı
    • high ise daha güvenli nil/invalid işleme, status-code aktarımı, disabled-datasource davranışı ve dynamic client-provider kapsamıyla eşdeğerlik ve inceleme geçişi sağladı
    • Bu görevde xhigh testleri geçmesine rağmen disabled datasource semantiğini ve invalid-list davranışını yanlış ele aldığı için eşdeğer olmayıp incelemeyi de geçemedi; yani tersine dönüş yaşandı

xhigh: varsayılandan çok kalite moduna yakın

  • xhigh, high'a göre anlamsal ve inceleme kalitesini artırdı, ancak ayarı yükseltince her şeyin otomatik olarak daha iyi olduğu bir tablo yok
  • xhigh ve high karşılaştırması
    • Test geçme: 25/26'dan 24/26'ya düşüyor
    • Eşdeğerlik: 18/26'dan 23/26'e yükseliyor
    • Kod incelemesinden geçme: 10/26'dan 18/26'ya yükseliyor
    • Ortalama footprint riski: 0.314'ten 0.365'e yükseliyor
    • Üretim/disiplin ortalaması: 2.736'dan 3.071'e yükseliyor
    • Ortalama görev maliyeti: $4.49'dan $9.77'ye çıkıyor, 2.18 kat
    • Ortalama çalışma süresi: 579.0 saniyeden 753.3 saniyeye çıkıyor
  • xhigh daha fazla zemini kapsama, insan niyetine daha iyi uyma ve daha eksiksiz değişiklikler üretme eğiliminde, ancak çok daha fazla token kullanıyor
  • İnceleme rubriğinde xhigh'ın ortalaması 3.365, medyanı 3.500; bu değerler high'ın ortalama 2.817 ve medyan 2.750 değerlerinden daha yüksek
  • Medyanın da ortalamadan yüksek olması, xhigh iyileşmesinin yalnızca bir iki olağanüstü patch'in ortalamayı yukarı çekmesinden kaynaklanmadığını gösteriyor
  • xhigh anlamsal olarak daha eksiksiz, ancak insan tarafından yazılmış patch'lere kıyasla daha fazla koda dokunduğu için footprint riski de artıyor
  • xhigh'ın 26 görevde eklediği satırların toplamı 13,144; bunun 5,918 satırı uygulama kodu, 7,226 satırı ise test·fixture·expected-output dosyaları
  • high ile karşılaştırıldığında xhigh 2,631 satır daha fazla ekledi ve bunun 2,436 satırı test·fixture·expected-output dosyalarında yer alıyor
  • Footprint artışı sadece devasa production code yazmasından kaynaklanmıyor; xhigh'ın daha fazla doğrulama ve fixture kapsamı üretmesinin de büyük etkisi var
  • Ancak test, fixture ve expected-output değişiklikleri de inceleme ve bakım gerektiren gerçek bir yüzey alanı oluşturuyor
  • PR #1076 örneği
    • Bu görev, paylaşılan mutex race condition'dan kaçınmak için subscription işlemeyi yeniden yapılandırıyor
    • Gereksinimler arasında subscription başına serileştirilmiş write, subscription başına heartbeat kontrolü, race detector kapsamı ve WebSocket close semantics düzeltmesi bulunuyor
    • medium testleri geçti ama eşdeğer değildi ve incelemeyi de geçemedi
    • high, eşdeğerlik ve talimata uyumu sağladı, ancak yeni worker queue küresel subscription event loop'unu engelleyebiliyor, shutdown takılı kalan worker yüzünden durabiliyor, hung update sınırsız kalıyor ve client düzeyindeki unsubscribe hâlâ internal subscription'ı atladığı için incelemeyi geçemedi
    • xhigh ilk sıkı geçişi sağladı ve özel kalite puanını 3.475'e yükseltti
    • Bu görev, concurrency ağırlıklı işlerde xhigh'ın inceleme riskini temizlemek için satın alınan bir kalite modu gibi çalıştığının en iyi örneği
  • PR #1308 örneği
    • Bu görev GraphQL @oneOf input object özelliğini uyguluyor
    • Built-in directive eklenmesi, introspection'da görünür olması, operation literal ve runtime variable doğrulaması ile undefined-variable source location iyileştirmesi gerekiyor
    • medium ve high testleri geçti, ancak runtime variable, nullable variable, provided-null payload ve introspection shape ile ilgili kritik @oneOf semantiğini kaçırdıkları için eşdeğer değildi ve incelemeyi de geçemedi
    • xhigh ilk sıkı geçişi sağladı ve dayanıklılıkta 3.7, talimata uyumda 4.0, özel kalitede 3.525 aldı
    • Fark, yüzeysel bir ciladan değil, birden çok sistem parçasına yayılan edge case kapsamından kaynaklanıyor
  • PR #1240 örneği
    • Bu görev, GraphQL AST field-selection merging ile inline-fragment selection merging işlemlerini tek bir normalization walk içinde birleştiriyor
    • low ve high sıkı geçiş sağlamıştı
    • xhigh, anlamsal değerlendirme ölçütüne göre eşdeğerdi, ancak prioritized subpass'i koruduğu, AbstractFieldNormalizer sırasını değiştirdiği ve eski field-merge registration'ı bıraktığı için incelemeyi geçemedi
    • Daha yüksek akıl yürütme ayarları da daha sofistike ve ikna edici refactoring üretebilirken, testlerin ve gözden geçirenlerin önem verdiği tam çalışma davranışını kaçırabiliyor

Üretim·disiplin, maliyet, sınırlamalar ve sonuç

  • Üretim·disiplin özel değerlendirmesi de inceleme rubriğine benzer şekilde, akıl yürütme çabası arttıkça genel olarak yükseliyor
  • all-custom puanı, xhigh için ortalama 3.071, medyan 3.087 ile high’ın ortalama 2.736, medyan 2.688 değerinden daha yüksek
  • Hem üretim hem de disiplinde medyan da daha yüksek olduğu için, xhigh’ın yalnızca bazı sıra dışı örnekler üretmediği, genel yama kalitesini de yükselttiği şeklinde yorumlanabilir
  • Ortalama/medyan göstergeleri
    • Craft aggregate: low 2.327 / 2.338, medium 2.618 / 2.525, high 2.781 / 2.787, xhigh 3.126 / 3.100
    • Discipline aggregate: low 2.295 / 2.325, medium 2.590 / 2.588, high 2.691 / 2.688, xhigh 3.015 / 3.013
    • All custom graders: low 2.311 / 2.338, medium 2.604 / 2.550, high 2.736 / 2.688, xhigh 3.071 / 3.087
  • Ayrıntılı yorum
    • low’da sağlamlık ve talimata uyum zayıf
    • medium, testten geçen toplam miktarı artırmadan bu alanı anlamlı biçimde iyileştiriyor
    • high, pratik doğruluk ve sağlamlığı iyileştiriyor
    • xhigh, kapsam ve diff disiplini dahil neredeyse tüm boyutları iyileştiriyor
  • Maliyet ve süre
    • low: ortalama maliyet $2.65, medyan $1.91, ortalama çalışma süresi 286.9s, medyan 294.6s
    • medium: ortalama maliyet $3.13, medyan $2.87, ortalama çalışma süresi 411.0s, medyan 371.8s
    • high: ortalama maliyet $4.49, medyan $3.99, ortalama çalışma süresi 579.0s, medyan 572.9s
    • xhigh: ortalama maliyet $9.77, medyan $6.39, ortalama çalışma süresi 753.3s, medyan 732.7s
  • Maliyet, low’da ve özellikle xhigh’da çarpık dağılım gösteriyor; xhigh ortalama maliyeti birkaç pahalı görevin etkisiyle yükseliyor
  • xhigh, medyan ölçüte göre de high’dan daha pahalı ve daha yavaş
  • high, medium’a kıyasla görev başına yaklaşık 1.43 kat daha maliyetli; xhigh ise high’a kıyasla yaklaşık 2.18 kat daha maliyetli
  • Sınırlamalar
    • Görev başına yalnızca tek bir seed kullanıldı
    • Yalnızca 26 gerçek GraphQL-go-tools görevi dahil edildi
    • LLM değerlendiricisi GPT-5.4’tü; yamaları ve görevleri görüyor ama label’ları görmüyor
    • Bu görev seti için grader calibration yok
    • Bunlar istatistiksel olarak anlamlı, evrensel sonuçlar ya da başka depolara doğrudan taşınabilecek sonuçlar olarak görülemez
  • İlgili karşılaştırmalar
    • Voratiq’in gerçek görev leaderboard sıralaması da farklı bir metodoloji kullanmasına rağmen benzer bir yön gösteriyor
    • Voratiq’te GPT-5.5 xhigh 1994, GPT-5.5 high ise 1807; bu da +187 puan, +10.3% artış anlamına geliyor
    • Maliyet $4.23e karşı $2.52 ile +67.9%, süre ise 11.9me karşı 7.8m ile +52.6%
    • Stet deneyinde high → xhigh geçişi, eşdeğerlikte +19.2%p, göreli olarak +27.8%, kod incelemesini geçmede +30.8%p, göreli olarak +80.0% ile daha büyük göründü; üretim/disiplin aggregate ise +12.2% ile benzerdi
    • Voratiq, sürmekte olan işler için preference/selection tarzı bir leaderboard; bu deney ise tek bir 26 görevlik depo dilimi olduğu için doğrudan karşılaştırılamaz
  • Pratik sonuç
    • xhigh; belirsiz, birden fazla alana yayılan, eşzamanlılık merkezli veya inceleme riski yüksek işler için uygun
    • high, bu veri setinde varsayılan günlük kullanım ayarı olarak en pratik seçenek gibi görünüyor
    • medium ve altı ayarlar, maliyetin daha önemli olduğu ve işin rutin ya da iyi tanımlanmış olduğu durumlara uygun
    • Akıl yürütme çabasının etkisi görevden göreve pürüzsüz ya da tekdüze değil; high’ın xhigh’ı geçtiği ya da daha yüksek ayarın makul görünüp yanlış uygulama ürettiği tersine dönüşler de var
    • Ekipler, küresel benchmark varsayılanlarını kopyalamak yerine kendi harness’leri ve kendi görevleri üzerinde ölçüm yapmalı
  • Açıklamalar
    • Stet.sh geliştiriliyor ve deneyler bu yerel değerlendirme aracıyla yürütüldü
    • Ürün sürümünde kodlama ajanı, AGENTS.md iyileştirmeleri gibi aday değişiklikler oluşturuyor ve Stet ile geçmiş depo görevleri üzerinde değerlendiriliyor
    • Kodlama ajanlarını yoğun kullanan ekipler, high vs xhigh, Codex vs Claude Code, AGENTS.md güncellemeleri ve hangi görevlerin delege edilmesinin güvenli olduğu gibi somut kararlarla karşı karşıyaysa, depo bazlı denemeleri birlikte yürütecek ekipler aranıyor
    • Stet, LLM aboneliği kullanarak tamamen yerelde çalışıyor; bekleme listesi https://www.stet.sh/private adresinde

İlgili okumalar

1 yorum

 
GN⁺ 8 시간 전
Reddit görüşleri
  • Bu karşılaştırma iyi olmuş; 5.4 ile karşılaştırmayı da görmek isterim
    Şu ana kadarki hissiyatıma göre 5.5, ek maliyetini karşılayacak kadar değerli değil. 5.4-high, 5.5'in çoğu akıl yürütme seviyesinden daha iyi iş çıkarıyor, maliyeti yarı yarıya ve gerçek süre de çok daha kısa. 5.5-medium işi sonuna kadar tamamlayamadı, 5.5-high ise aşırı mühendislik yapıp bug ve regresyon üretti
  • Ciddi işlerin çoğu için high uygun görünüyor
    Bunun üzerindeki seviyelerde elde edilen iyileşme, maliyete kıyasla azalan getiri noktasına yakın
  • Pro hesapta ana lider olarak 5.5 xHigh Codex Terminal CLI, yardımcı lider olarak da Codex Desktop App 5.5 xhigh çalıştırıyorum
    İkisine de tehlikeli düzeyde tam erişim verip aynı projede çalıştırıyorum. Her birine ortalama 6 tane 5.5 alt ajan bağlıyorum; CLI ya da uygulama bu alt ajanların hangi seviyede olacağına karar veriyor. Karışık geliyor ama CLI çoğunlukla 5.5 Medium bağlıyor
    CLI'da yönetici yetkileri var ve GitHub, Supabase, Vercel, Clerk, Linear, Symphony gibi şeylerle push, merge, PR ve deploy işlemlerini sadece CLI yapıyor. Benim manuel olarak yaptığım iş 0, P0/P1/P2 issue da 0. GitHub, Vercel ve Supabase'in hepsi yeşil, issue yok, kod ve ürün temiz, tek bir referans görselle frontend şaşırtıcı derecede iyi çıkıyor
    Dezavantajı ise bir günde haftalık limitin %30'unu yakabilmesi
    • Bu deneyi gördükten sonra bazı görevlerde xhigh denedim; oldukça etkili ama token'ı deli gibi tüketiyor
      Şimdilik tekrar high'a döndüm
  • 5.5 xhigh ile ilgili en büyük şikayetim, sormadan doğrudan kendi kendine işi ilerletmesi
    Bu sayede sanki ömrümden birkaç yıl ve epey token tasarruf etmişim gibi hissediyorum
    • Genelde high kullanıyorum, o da aynı şekilde davranıyor
      agents.md içine hangi ifadeyi koyarsam kendi kafasına göre varsayım yapmayacağını hâlâ arıyorum. Bazen bir konuda kodlama talimatı vermeden önce daha fazla bilgi gerektiği için soru soruyorum ama cevap vermek yerine doğrudan kodlamaya başlıyor. Bitirdikten sonra yanıtın içine sorunun cevabını da ekliyor ama söylediklerime dikkat etse de, soru soruyorsam bunun henüz kodlamaya başlama anlamına gelmediğini anlamıyor gibi
  • Aynı PR üzerinde birden fazla kez çalıştırıp çalıştırmadığınızı merak ediyorum
    Modelin çalıştırmadan çalıştırmaya ne kadar değişkenlik gösterdiğini bilmek isterim. Yukarıdaki örnekte high daha iyi kod yazmış olsa bile, eğer çalıştırmalar arası değişkenlik büyükse xhigh kullanmak daha mantıklı olabilir
    Ayrıca deney olarak, bir çalıştırmanın ardından ortaya çıkan sonuca geri bildirim verip, insanın yaptığı düzeltmelerle karşılaştırarak AGENTS.md, skills, rules vb. dosyaları güncelletmek ve sonra fresh session'da high/xhigh ile yeniden çalıştırmak da iyi olurdu. Bunu birkaç kez tekrarlayıp iyileştirdikten sonra tüm efor seviyelerinde tekrar denerseniz, AGENTS.md ile skills/rules'u düzgün sıkılaştırarak genel çıktı kalitesini yükseltmek mümkün olabilir
    • Her varyantı birden fazla kez çalıştırmadım. Ana neden maliyet ve token kısıtları. Cüzdanım sonsuz değil ama takip çalışması için iyi bir fikir
      AGENTS.md optimizasyonu fikri gerçekten çok hoşuma gitti; hatta deneyleri yürütmek için yaptığım Stet'e bunu denettim. Codex'i birkaç görevde çalıştırıp puanları ve başarısızlık kalıplarını gördükten sonra AGENTS.md'yi değiştirip yeniden çalıştırmasını sağladım; her şeyi tamamen otonom biçimde yürüttü. AGENTS.md için otomatik araştırma gibi çalışıyor ve veri temelli iyileştirme önerilerini AGENTS.md'ye işleyip geri dönmesini izlemek oldukça ilginç
  • Artık fiyat enflasyonu için bir CPI endeksi de lazım. Aylık CPI neredeyse %100 gibi hissettiriyor