15 LLM’nin kodlama performansını iyileştirdik; değişen tek şey harness oldu

 (blog.can.ac)
35 puan yazan GN⁺ 2026-02-13 | 3 yorum | WhatsApp'ta paylaş
  • Birden fazla LLM aynı koşullarda test edildiğinde, yalnızca kod düzenleme aracı değiştirilse bile performansın ciddi biçimde arttığı görüldü
  • Mevcut Patch·Replace yöntemi yerine, her kod satırına hash etiketi ekleyen ‘Hashline’ formatı uygulanarak düzenleme doğruluğu artırıldı
  • Hashline, 16 modelin 14’ünde mevcut yöntemlerden daha yüksek doğruluk gösterdi; ayrıca ortalama %20~30 token tasarrufu sağladığı da doğrulandı
  • Özellikle Grok Code Fast 1 modelinde başarı oranı %6,7’den %68,3’e fırladı; yalnızca basit bir harness değişikliğiyle 10 kat iyileşme elde edildi
  • Araştırma, modelin kendisinden çok ‘harness’in gerçek performanstaki darboğaz olduğunu gösterirken, açık kaynak ekosisteminde iş birliği gereğini vurguluyor

Kod düzenleme benchmark’ına genel bakış

  • Deney, Patch, Replace, Hashline olmak üzere üç farklı düzenleme formatını karşılaştıracak şekilde yürütüldü
    • 16 model üzerinde aynı kod düzeltme görevleri uygulandı
    • Her model, React kod tabanında rastgele seçilmiş dosyalardaki hataları düzeltme yöntemiyle test edildi
  • Hashline formatı, 14 modelde Patch’ten daha iyi sonuç verdi ve ortalama olarak %20~30 token tasarrufu sağladı
    • En büyük iyileşme Grok Code Fast 1 modelinde görüldü; başarı oranı %6,7’den %68,3’e çıktı (+61,6 puan)
    • Gemini 3 Flash 5,0 puan, Claude Sonnet 4.5 ise 1,6 puan iyileşti

Harness sorunu

  • Mevcut tartışmalar çoğunlukla “hangi model kodlamada en iyisi” sorusuna odaklansa da, gerçek darboğaz model değil harness
    • Harness, giriş token’larını yöneten ve model çıktısı ile çalışma alanı değişikliklerini birbirine bağlayan temel arayüzdür
    • Başarısızlıkların çoğu modelden değil, harness’in yapısal sınırlamalarından kaynaklanıyor
  • Yazar, açık kaynak kodlama ajanı Pi’yi fork’layarak oluşturduğu kişisel proje oh-my-pi üzerinden yaklaşık 1.300 commit yaparak iyileştirme denemeleri gerçekleştirdi
    • Bu ortam modelden bağımsız olup, deneylerde yalnızca harness’i değişken olarak tutmaya olanak sağlıyor

Mevcut düzenleme araçlarının sınırları

  • Codex’in apply_patch yöntemi, OpenAI’ye özgü bir diff formatı kullandığı için diğer modellerde yüksek hata oranına yol açıyor
    • Örnek: Grok 4’te patch başarısızlık oranı %50,7, GLM-4.7’de ise %46,2
  • Claude Code’un str_replace yöntemi, dizgilerin birebir eşleşmesini gerektirdiğinden boşluk veya girinti farkları yüzünden hatalara neden oluyor
    • GitHub’da çok sayıda “String to replace not found in file” hatası rapor edildi
  • Cursor, birleştirme işlemini yönetmek için ayrı bir 70B model eğitiyor; ancak 400 satırın altındaki dosyalarda tam yeniden yazımın (full rewrite) daha iyi sonuç verdiği görüldü
  • JetBrains’in Diff-XYZ ve EDIT-Bench araştırmaları da düzenleme formatına göre performansın büyük ölçüde değiştiğini doğruladı

Hashline yönteminin mantığı

  • Her kod satırına 2~3 karakter uzunluğunda bir içerik hash’i eklenerek modelin düzenlenecek hedefi açık biçimde belirtmesi sağlanıyor
    • Örnek: 22:f1| return "world";
    • Model, “replace line 2:f1” gibi hash’i temel alan düzenleme isteği gönderiyor
  • Dosya değişmiş ve hash uyuşmazlığı oluşmuşsa düzenleme reddediliyor, böylece bozulma önleniyor
  • Bu yöntem, modelin mevcut içeriği yeniden üretmesini gerektirmediği için boşluk ve girinti hatalarını azaltıyor, daha istikrarlı düzenleme sağlıyor

Benchmark sonuçları

  • Testler 180 hata düzeltme görevi, 3 tekrar ve 4 araçtan (read, edit, write vb.) oluştu
  • Sonuç olarak Patch formatı neredeyse tüm modellerde en kötü seçenek oldu, Hashline ise Replace ile eşdeğer ya da daha iyi performans gösterdi
    • Model ne kadar zayıfsa iyileşme marjı o kadar büyüktü
    • Grok 4 Fast’ta çıktı token’ları %61 azaldı, MiniMax ise iki katın üzerinde iyileşti
  • Gemini’nin başarı oranındaki +%8’lik artış, ek eğitim olmadan elde edilmesi bakımından sıradan bir model yükseltmesinden daha büyük bir iyileşme anlamına geliyor

Tedarikçi politikaları ve açık kaynak ekosistemi

  • Anthropic, açık kaynak kodlama ajanı OpenCode’un Claude Code erişimini engelledi
    • Gerekçe “özel API’nin tersine mühendisliği” olsa da, sonuçta bu adım “yalnızca kendi harness’inizi kullanın” mesajı olarak yorumlandı
  • Google, yazarın hesabını engelleyerek Gemini erişimini kesti
    • Bu, Hashline uygulanmasının ardından Gemini 3 Flash performansının %78,3’e çıktığını gösteren benchmark’ın hemen sonrasında gerçekleşti
  • Yazar, bu tür adımların model geliştirme fırsatlarını engelleyen geriye dönük hamleler olduğunu savunuyor
    • Harness optimizasyonu, belirli bir modele değil tüm modellere kalite artışı sağlayan kamusal bir araştırma niteliği taşıyor
    • “Model hendekse, harness köprüdür” ifadesiyle, kapalı yaklaşımın ekosistem gelişimini engellediği vurgulanıyor

Sonuç

  • Harness sorununun, ölçülebilir ve gerçek performansı doğrudan etkileyen bir etken olduğu doğrulandı
  • Yalnızca basit bir format değişikliğiyle bile model yükseltmesine yakın bir iyileşme elde edilebiliyor
  • Gelecekteki gelişim yönü, tek bir şirketin kapalı iyileştirmeleri değil, topluluk temelli açık iş birliği olmalı
  • Tüm kodlar, benchmark’lar ve çalıştırma sonuçları GitHub deposu oh-my-pi üzerinde açık olarak paylaşılıyor

İlgili okumalar

3 yorum

 
github88 2026-02-15

Model tuhaf, peki neden yine prompt engineering..
 
cosine20 27 일 전

Harness ile prompt engineering tamamen farklı şeylerdir.
 
GN⁺ 2026-02-13
Hacker News görüşleri

  • Bu yazıyı gerçekten ilgi çekici buldum. Yazarın tam olarak meseleye parmak bastığını düşünüyorum
    Hâlihazırda mevcut modeller bile, ajan harness’ini nasıl tasarladığımıza bağlı olarak çok daha verimli hâle getirilebilir.
    Bence “AI”a sadece LLM’in kendisi olarak değil, LLM ile harness’in bir geri bildirim döngüsüyle bağlandığı bütün sibernetik sistem olarak bakmak daha doğru.
    Model ve harness birbirini güçlendirip birlikte evrilen bir yapı olduğundan, ikisi de eşit derecede önemli.
    Bu bakış açısı, yalnızca performans artışını değil, üretken yapay zekayı nörosembolik (neurosymbolic) bir proje olarak yeniden yorumlamayı da mümkün kılıyor

    • Bence şu anda bile GPT-4 ile yeterince çok şey inşa edilebilir.
      Ben gerçekten 2023 sürümü GPT-4 ile bir kodlama ajanı yaptım.
      Eski modellerle çalışınca sadeliği korumak zorunda kalıyorsunuz, bu da soruna farklı bakmanızı sağlıyor.
      Örneğin Python’da grep -r def . gibi basit bir semantic compression vazgeçilmez.
      Claude Code gibi araçlara böyle basit bir hook eklenirse, token israfı olmadan kod yapısı hemen kavranabilir
    • Peen adlı bir CLI geliştiriyorum. Yerel Ollama modellerinin araçları verimli çağırmasına yardımcı olan bir araç.
      Sadece birkaç saatlik prompt tuning ve yanıt işleme koduyla bile küçük yerel modellerin çıktı kalitesi şaşırtıcı biçimde iyileşiyor
      GitHub bağlantısı
    • Claude Code ve OpenAI Codex’in harness’leri de kendi kendilerini geliştiriyor.
      OpenAI, kendi eğitim sürecinde hata ayıklamak ve dağıtımı yönetmek için GPT-5.3-Codex’in erken bir sürümünü kullandı.
      Claude Code ise günde 20’den fazla PR’ı tamamen kendi ürettiği kodla gönderiyor
    • Bu arada, yazı tarzımda sık geçen “It’s not just X, it’s Y” gibi kalıplar yorgunluktan kaynaklanıyor; bunu LLM yazmadı
    • SWE-bench belgelerine bakarsanız, neredeyse rastgele sayılabilecek bir context engineering kullanılıyor.
      Hatta hangi modelin iyi context engineering’e duyarlı olduğunu bile pek bilmiyoruz.
      Ama yine de ortada bolca kolay kazanım (low hanging fruit) olduğu konusunda kesinlikle katılıyorum

  • Bu teknik ilginç ama abartılıyor gibi geliyor.
    Yazar, kendi yaptığı basit bir find/replace benchmark’ında %5 iyileşme görüp bunu sanki genel performans 14 puan artmış gibi anlatıyor.
    Gerçekte toplam token verimliliğinde %1’den az bir iyileşme olması daha olası.
    Üstelik yazının abartılı tonu ve ChatGPT’ye özgü üslubu güveni azaltıyor

    • “replace line 2:f1…” gibi bir format kullanılsa, gerçek verimlilik %20’den çok daha yüksek olabilir gibi geliyor
    • Benchmark’ta token kullanımının %25~50 azaldığı söyleniyor ama gerçek kullanım ortamında bunun o kadar etkili olup olmayacağı şüpheli

  • Bu yazı, harness seviyesinde ne kadar büyük bir iyileştirme alanı olduğunu iyi gösteriyor.
    Ajanlar; düzenleme, sandbox ve araç çağrıları arasında veri aktarımı gibi işlerde çok fazla token harcıyor.
    İçerik tabanlı adresleme + satır numaralandırma birleşimi hem pratik hem de zarif

    • En büyük israf, MCP’yi her yerde kullanmak olabilir.
      İlk geliştirmeyi kolaylaştırıyor ama gereksiz yere devasa modeller çağrılmasına yol açarak verimsizlik yaratıyor
    • ClaudeCode Superpowers eklentisini denedim; işlevleri iyi ama maliyeti yüksek.
      CC’de oturum başına maliyeti /cost komutuyla görebiliyorsunuz; eklenti verimliliğini böyle metriklerle değerlendirmek iyi olur
    • Tersine, daha fazla token harcayıp karmaşık problemleri küçük alt problemlere bölerek çözme yaklaşımı da mümkün

  • Harness’in önemi, çoğu insanın düşündüğünden çok daha büyük.
    Örneğin Opus’un CORE benchmark puanı, kendi harness’inden Claude Code’a geçince neredeyse iki katına çıktı
    ilgili bağlantı

    • Pi terminal ajanının yaratıcısı Mario’nun blog yazısında da
      TerminalBench’teki en yüksek skorun Terminus 2 harness’i sayesinde elde edildiği anlatılıyor
    • Bu yüzden harness’i özgürce değiştirebilmeli ya da kendimiz yapabilmeliyiz.
      Aylık 20 dolarlık abonelik yüzünden belirli bir harness’e kilitlenmek mantıksız

  • tilth adlı bir araç geliştirerek hash tabanlı okuma/düzenleme yöntemini hayata geçirdim.
    npm ve cargo üzerinden kurulabiliyor, ayrıca Claude Code veya Cursor gibi editörlerle entegre oluyor
    GitHub bağlantısı
    Amaç, LLM’lerin araçları daha verimli kullanmasını ve token israfını azaltmasını sağlamak

    • Markdown’a da uygulanabilirse iyi olur. Bölüm düzeyinde adresleme eklenirse sürümler arasında kararlılık artar
    • grep ile benchmark karşılaştırması yapmak da ilginç olabilir

  • Ben de benzer bir yöntemi bağımsız olarak düşündüm ama soyutlama bağımlılığı yüzünden vazgeçtim.
    Onun yerine Damerau-Levenshtein mesafesi kullanarak düzenleme benzerliğini hesaplıyor, belli bir eşik üzerindeyse değişikliğin geçmesine izin veriyorum.
    Bu sayede modelin değiştirilecek kaynak token’ları açıkça üretmesi gerekiyor ve doğruluk artıyor
    kod örneği
    Asıl nokta, hata mesajlarının somut olması — “Content mismatch. Reread the file” gibi kurtarma talimatı içeren hata işleme önemli.
    Bu yöntem 4B modellerde de iyi çalışıyor; tool call desteklemeyen modeller içinse system prompt enjeksiyonu hack’i kullanıyorum
    ilgili kod

  • Eski modellerle de oldukça isabetli sonuçlar almak mümkündü.
    Önemli olan, modeli “doğru şekilde ele almak” idi.
    Bu yazı, model yalnızca metinle değil de kaynak kodun yapısal temsiliyle (AST) doğrudan çalışabilse çok daha büyük sonuçlar alınabileceğini ima ediyor.
    Örneğin OpenRewrite; kodun tip, biçimlendirme ve bağımlılık bilgilerini bütünüyle içeren bir Lossless Semantic Tree kullanıyor.
    Model böyle bir yapıyı kullanabilirse, gereksiz token israfı olmadan çok hassas değişiklikler yapılabilir.
    Sonuçta bu, “Vim vs Emacs” tartışmasının cevabının neden “IntelliJ” olduğuyla aynı mesele — yapısal bilgi güçlü bir silah.
    Eğer model kodu, belgeleri ve sözdizimsel/anlamsal ağaçları birlikte öğrenirse, gerçek bir nörosembolik kodlama modeli olur

  • Emacs’in gptel’i ile LLM denemeleri yaparken, LLM’lerin Unix patch aracıyla kod düzenleme işinde pek başarılı olmadığını fark ettim.
    Bunun üzerine Emacs’in tree-sitter yapısını kullanarak gptel için kendi aracımı yazdım.
    tree_sitter_list_nodes, tree_sitter_update_nodes gibi komutlarla AST düğümlerini doğrudan düzenlettim ve kusursuz çalıştı

    • İlginçmiş, o kodu paylaşman mümkün mü diye merak ettim

  • Codex’in apply_patch aracı aslında kısıtlı bir sampling şeması kullanıyor.
    ilgili kod
    Yazar bunu bilmeden basit bir karşılaştırma yaptığı için, daha gerçekçi bir benchmark bu şema etkinleştirilmişken yapılmalı

  • Bu yazıdaki alıntılar arasında özellikle etkileyici bulduğum bir bölüm var
    “Sorun, modelin problemi anlamaması değil; temsili kararsız olması. İniş takımı sorununu pilota yüklemeyin.”
    “Model hendekse (moat), harness köprüdür (bridge).”
    “Harika bir demo ile güvenilir bir araç arasındaki fark sihir değil, sıkıcı ama incelikli mühendisliktir.”

    • Kesinlikle katılıyorum. Bu sadece iyi tavsiye değil, yazarın düşünme biçimini canlı biçimde gösteren bir teknik sanat eseri gibi
    • Benim en sevdiğim cümle şu: “Bu bir tehdit değil. Ücretsiz Ar-Ge.”