176 harness ayarı üzerine yapılan ampirik çalışma, kodlama ajanı tasarım tercihlerinin model gücüne bağlı olduğunu gösteriyor

Yeni bir ampirik makale, kodlama ajanlarını saran iskeleti (scaffolding) inceliyor ve hangi bileşenlerin gerçekten hak edilen yerini kazandığını ölçüyor. 17 Eylül 2026'da arXiv'e gönderilen ve Hacker News'in ana sayfasında öne çıkan çalışma, harness tasarımının — bir modelin etrafını saran planlama, araç kullanımı ve context yönetiminin — uzun vadeli yazılım mühendisliği performansını nasıl şekillendirdiğini soruyor. Çalışmanın çıkış noktası literatürdeki bir boşluk: mevcut değerlendirmeler harness'leri tek parça sistemler olarak ele alma eğiliminde, dolayısıyla bir benchmark puanı tek tek tasarım kararlarına kadar izlenemiyor.

Sabit döngü ve üç değişken parça

Makaleye göre yazarlar, çalıştırma döngüsü sabit tutulurken yalnızca üç bileşenin değiştiği hafif bir kodlama harness'i kurmuş: planlama, action space ve context yönetimi. Dört model SWE-Bench Verified ve Terminal-Bench 2.1 üzerinde değerlendirilmiş; beş context yönetimi stratejisini, dört context penceresi bütçesini ve planlama ile action space'e yönelik hedefli ablation'ları kapsayan 176 eşleştirilmiş ayar ortaya çıkmış. Çevresindeki mekanizma çalışmalardan çalışmaya değişmediği için, sonuçlardaki farklar test edilen bileşene değil de tesadüfi detaylara bağlanamaz.

Context yönetimi çoğunlukla taşma sigortası gibi çalışıyor

Çalışma, context yönetiminin değerinin context penceresi bütçesi daraldıkça arttığını ve bu faydanın çoğunun ajanı temel görevde daha iyi hale getirmekten değil, context taşması kaynaklı başarısızlıkları önlemekten geldiğini buluyor. Cömert bir pencere olduğunda strateji seçiminin önemi çok daha az.

Test edilen beş strateji arasında en verimli olanı, önce deterministik, kural tabanlı kırpma — içeriği model görmeden ayıklama — sonra da LLM tabanlı özetleme uygulanandı. Cazip görünen bir eklenti olan, kırpılan içeriği geri getirilebilir kılıp ajanın ona daha sonra yeniden erişebilmesi, modellerin nadiren kullandığı bir mekanizma ekledi ve doğruluk kazancı sağlamadı. Çıkarılan materyalin geri alınmasını uygulamayı düşünen geliştiriciler için buradaki veri, bu karmaşıklığın kendini amorti etmediğini gösteriyor.

Planlama ve araç kullanımı model gücüne bağlı

Planlama modele göre iki farklı rol oynadı. Daha zayıf modeller için doğruluğu doğrudan yükselten bir destek işlevi gördü. Daha güçlü modellerde ise asıl etkisi maliyeti düşürmek oldu; doğrulukta pek bir hareket olmadı.

Action space sonuçları da aynı mantığı izliyor. Önceden tanımlı araçlar, komut satırı becerileri zayıf modellerin performansını iyileştirdi; ama bash'te zaten akıcı olan modeller çok daha düşük maliyetle yalnızca bash arayüzünde etkili biçimde çalıştı — fark, komut satırı odaklı görevlerde en geniş haliyle ortaya çıktı ve bu, değerlendirmenin Terminal-Bench yarısıyla tutarlı.

Yörüngeler neyi ortaya koyuyor

Yazarlar bu etkileri açıklamak için yalnızca nihai puanlar yerine ajan yörüngelerini analiz etmiş. Context yönetimi, çalıştırma yörüngelerini uzatıyor ama ajanın davranışını ciddi biçimde değiştirmiyor: çalıştırmalar taşmada ölmeden sürüyor. Planlama, yörüngelerin durduğu noktayı değiştiriyor. Action space ise kodun yazıldığı tanecik seviyesini değiştiriyor. Sonuç, benchmark rakamlarının yalnızca istatistiksel değil, mekanik bir açıklaması.

Neden önemli

Kodlama ajanları için harness tasarımı büyük ölçüde geleneklerden ve tekil ekiplerin anekdotlarından yol buldu. Bu makale bu folklorun bir kısmını eşleştirilmiş ölçümlerle değiştiriyor ve vardığı sonuçlar pratik rehberliğe çevriliyor:

• Context yönetimi çabasını context bütçenizle eşleştirin. Pencere ne kadar dar olursa strateji o kadar önemli; basit, aşamalı kırpma artı özetleme, daha ağır mekanizmaları verimlilikte geride bırakıyor.
• Geri getirilebilir çıkarma (elision), modellerinizin bunu kullandığına dair kanıtınız olmadıkça atlayın; bu çalışmada modeller bunu nadiren kullandı ve elde edilecek bir doğruluk da yoktu.
• Planlamayı ve önceden tanımlı araçları modele bağlı tercihler olarak görün: zayıf modeller için faydalı iskelet, güçlü modeller için maliyet kolu ya da gereksiz yük.
• Temeldeki modelin güçlü shell becerileri varsa, yalnızca bash arayüzü meşru ve daha ucuz bir seçenek; özellikle terminal odaklı işlerde.

Somut bulguların ötesinde, sabit döngülü, bileşen değiştirmeli kurulum, gelecekteki harness bileşenlerini değerlendirmek için modüler bir çerçeve sunuyor — fiilen harness'lerin kendisini, yalnızca içinde çalışan modelleri değil, benchmark'a tabi tutmanın bir yolu.