35 poin oleh GN⁺ 2026-02-13 | 3 komentar | Bagikan ke WhatsApp
  • Hasil pengujian beberapa LLM dalam kondisi yang sama menunjukkan bahwa performa dapat meningkat besar hanya dengan mengganti alat pengeditan kode
  • Alih-alih metode Patch·Replace yang ada, penelitian ini menerapkan format ‘Hashline’ yang memberi tag hash pada setiap baris kode untuk meningkatkan akurasi penyuntingan
  • Hashline menunjukkan akurasi lebih tinggi daripada metode lama pada 14 dari 16 model, sekaligus menghemat rata-rata 20~30% token
  • Khususnya, model Grok Code Fast 1 melonjak dari tingkat keberhasilan 6.7% menjadi 68.3%, peningkatan 10 kali lipat hanya lewat perubahan harness sederhana
  • Riset ini menunjukkan bahwa bottleneck performa nyata bukan pada model itu sendiri, melainkan pada ‘harness’, serta menekankan perlunya kolaborasi dalam ekosistem open source

Ikhtisar benchmark pengeditan kode

  • Eksperimen dilakukan dengan membandingkan tiga format pengeditan: Patch, Replace, dan Hashline
    • Sebanyak 16 model menjalankan tugas perbaikan kode yang sama
    • Setiap model diuji dengan memperbaiki bug pada file yang dipilih secara acak dari codebase React
  • Format Hashline menunjukkan hasil lebih baik daripada Patch pada 14 model, sambil rata-rata menghemat 20~30% token
    • Peningkatan terbesar terjadi pada model Grok Code Fast 1, dengan tingkat keberhasilan naik dari 6.7% menjadi 68.3% (+61.6pp)
    • Gemini 3 Flash naik 5.0pp, Claude Sonnet 4.5 naik 1.6pp

Masalah harness

  • Diskusi saat ini banyak berfokus pada “model mana yang paling jago coding”, tetapi bottleneck sebenarnya adalah harness, bukan model
    • Harness adalah antarmuka inti yang mengelola token input dan menghubungkan output model dengan perubahan workspace
    • Sebagian besar kegagalan terjadi bukan karena model, melainkan karena keterbatasan struktural harness
  • Penulis mencoba melakukan perbaikan lewat proyek pribadi oh-my-pi, hasil fork dari agen coding open source Pi, dengan sekitar 1.300 commit
    • Lingkungan ini independen terhadap model, sehingga eksperimen dapat dilakukan dengan hanya menjadikan harness sebagai variabel

Keterbatasan alat pengeditan lama

  • Metode Codex apply_patch memakai format diff khusus OpenAI, sehingga tingkat kegagalannya tinggi pada model lain
    • Contoh: tingkat kegagalan patch pada Grok 4 sebesar 50.7%, GLM-4.7 sebesar 46.2%
  • Metode Claude Code str_replace mengharuskan kecocokan string yang sempurna, sehingga perbedaan spasi atau indentasi dapat memicu error
    • Error “String to replace not found in file” banyak dilaporkan di GitHub
  • Cursor melatih model 70B terpisah untuk menangani merge, tetapi pada file di bawah 400 baris, penulisan ulang penuh (full rewrite) memberi hasil lebih baik
  • Riset Diff-XYZ dari JetBrains dan EDIT-Bench juga mengonfirmasi bahwa performa sangat dipengaruhi oleh format pengeditan

Cara kerja Hashline

  • Setiap baris kode diberi hash konten sepanjang 2~3 karakter agar model dapat menentukan target edit secara jelas
    • Contoh: 22:f1| return "world";
    • Model kemudian meminta revisi berdasarkan hash, seperti “replace line 2:f1”
  • Jika file berubah dan hash tidak lagi cocok, edit akan ditolak untuk mencegah kerusakan
  • Dengan cara ini model tidak perlu mereproduksi isi lama, sehingga error terkait spasi dan indentasi berkurang dan penyuntingan menjadi lebih stabil

Hasil benchmark

  • Pengujian terdiri dari 180 tugas perbaikan bug, diulang 3 kali, dengan 4 alat (read, edit, write, etc.)
  • Hasil akhirnya, format Patch hampir selalu menjadi yang terburuk di semua model, sementara Hashline setara atau lebih baik daripada Replace
    • Semakin lemah modelnya, semakin besar peningkatannya
    • Grok 4 Fast menurunkan token output sebesar 61%, MiniMax meningkat lebih dari dua kali lipat
  • Kenaikan tingkat keberhasilan Gemini sebesar +8% lebih besar daripada peningkatan yang biasanya didapat dari upgrade model biasa, dan dicapai tanpa pelatihan tambahan

Kebijakan vendor dan ekosistem open source

  • Anthropic memblokir akses Claude Code dari agen coding open source OpenCode
    • Alasannya adalah “reverse engineering API privat”, tetapi hasilnya ditafsirkan sebagai sinyal “gunakan hanya harness milik kami”
  • Google memblokir akun penulis dan menghentikan akses ke Gemini
    • Ini terjadi tepat setelah benchmark yang menunjukkan performa Gemini 3 Flash naik menjadi 78.3% dengan Hashline
  • Penulis menilai langkah seperti ini sebagai tindakan regresif yang menghalangi peluang peningkatan model
    • Optimalisasi harness adalah riset publik yang meningkatkan kualitas semua model, bukan hanya model tertentu
    • Dengan ungkapan “model adalah moat, harness adalah jembatan”, penulis menekankan bahwa pendekatan tertutup justru menghambat perkembangan ekosistem

Kesimpulan

  • Masalah harness terbukti sebagai faktor yang dapat diukur dan berdampak langsung pada performa nyata
  • Perubahan format yang sederhana saja bisa menghasilkan peningkatan yang sebanding dengan upgrade model
  • Arah perkembangan ke depan seharusnya bukan perbaikan tertutup oleh satu perusahaan, melainkan kolaborasi terbuka berbasis komunitas
  • Semua kode, benchmark, dan hasil eksekusi dipublikasikan di repositori GitHub oh-my-pi

3 komentar

 
github88 2026-02-15

Modelnya aneh, kenapa harus prompt engineering lagi..

 
cosine20 19 hari lalu

Harness dan prompt engineering adalah hal yang sama sekali berbeda.

 
GN⁺ 2026-02-13
Pendapat Hacker News
  • Saya membaca tulisan ini dengan sangat tertarik. Menurut saya, penulis tepat mengenai inti masalahnya.
    Bahkan dengan model yang sudah ada sekarang, masih banyak ruang untuk membuatnya jauh lebih efisien tergantung bagaimana kita merancang agent harness.
    Saya rasa lebih tepat melihat “AI” bukan sekadar LLM itu sendiri, melainkan sebagai seluruh sistem sibernetik tempat LLM dan harness terhubung dalam loop umpan balik.
    Model dan harness saling memperkuat dan berevolusi bersama, jadi keduanya sama pentingnya.
    Sudut pandang ini bukan hanya meningkatkan performa, tetapi juga membantu menafsirkan ulang AI generatif sebagai proyek neurosymbolic

    • Menurut saya, bahkan sekarang pun kita sudah bisa membangun banyak hal hanya dengan GPT-4.
      Saya benar-benar membuat coding agent dengan GPT-4 versi 2023.
      Bekerja dengan model lama justru memaksa kita menjaga kesederhanaan, sehingga masalah terlihat dari sudut berbeda.
      Misalnya, di Python, semantic compression sederhana seperti grep -r def . itu esensial.
      Jika hook sesederhana ini ditambahkan ke alat seperti Claude Code, struktur kode bisa langsung dipahami tanpa membuang token
    • Saya sedang membuat CLI bernama Peen. Ini alat yang membantu model Ollama lokal memanggil tool dengan efisien.
      Hanya dengan beberapa jam prompt tuning dan kode pemrosesan respons, kualitas keluaran model lokal kecil bisa meningkat secara mengejutkan
      Tautan GitHub
    • Harness milik Claude Code dan OpenAI Codex juga terus berkembang dengan sendirinya.
      OpenAI memakai versi awal GPT-5.3-Codex untuk men-debug proses pelatihan internalnya dan mengelola deployment.
      Claude Code mengirim lebih dari 20 PR per hari semuanya dari generasi kode internalnya sendiri
    • Sebagai catatan, gaya tulisan saya sering memakai struktur seperti “It’s not just X, it’s Y”, tapi itu karena saya lelah, bukan karena ditulis LLM
    • Jika melihat dokumentasi SWE-bench, mereka memakai context engineering yang nyaris arbitrer.
      Kita bahkan belum benar-benar tahu model mana yang sensitif terhadap context engineering yang baik.
      Tapi saya jelas setuju bahwa masih banyak low hanging fruit
  • Teknik ini menarik, tetapi terasa dibesar-besarkan.
    Penulis melihat peningkatan 5% pada benchmark find/replace sederhana buatannya, lalu berbicara seolah performa keseluruhan naik 14 poin.
    Kenyataannya, kemungkinan peningkatannya kurang dari 1% dalam efisiensi token total.
    Selain itu, nada berlebihan dalam tulisan dan gaya khas ChatGPT justru menurunkan kepercayaan

    • Jika formatnya seperti “replace line 2:f1…”, saya rasa efisiensi nyata bisa jauh lebih tinggi dari 20%
    • Di benchmark memang disebut pemakaian token turun 25~50%, tetapi saya ragu dampaknya sebesar itu di lingkungan penggunaan nyata
  • Tulisan ini menunjukkan dengan baik betapa besar ruang perbaikan di level harness.
    Agent membuang banyak token dalam pengeditan, sandbox, dan pemindahan data antar pemanggilan tool.
    Kombinasi content-addressing + line numbering terasa praktis dan indah

    • Pemborosan terbesar mungkin justru memakai MCP di mana-mana.
      Pengembangan awal jadi mudah, tetapi tidak efisien karena memaksa pemanggilan model yang tidak perlu besar
    • Saya pernah mencoba plugin ClaudeCode Superpowers; fiturnya bagus, tetapi biayanya mahal.
      Di CC, biaya per sesi bisa dilihat lewat perintah /cost, jadi metrik seperti ini bagus untuk mengevaluasi efisiensi plugin
    • Sebaliknya, ada juga pendekatan memakai lebih banyak token untuk memecah masalah kompleks menjadi submasalah kecil lalu menyelesaikannya
  • Pentingnya harness jauh lebih besar daripada yang dibayangkan kebanyakan orang.
    Misalnya, skor benchmark CORE milik Opus hampir menjadi dua kali lipat hanya dengan mengganti harness internalnya ke Claude Code
    Tautan terkait

    • Dalam postingan blog oleh Mario, pembuat Pi terminal agent,
      juga dijelaskan bahwa skor tertinggi TerminalBench dicapai berkat harness Terminus 2
    • Karena itu, kita harus bisa mengganti harness dengan bebas atau membuatnya sendiri.
      Tidak masuk akal terikat pada harness tertentu hanya karena langganan 20 dolar per bulan
  • Saya membuat alat bernama tilth yang menerapkan metode baca/edit berbasis hash.
    Bisa diinstal lewat npm dan cargo, serta terintegrasi dengan editor seperti Claude Code atau Cursor
    Tautan GitHub
    Tujuannya adalah membantu LLM memakai tool lebih efisien dan mengurangi pemborosan token

    • Sepertinya akan bagus juga jika diterapkan ke Markdown. Addressing per bagian akan meningkatkan stabilitas antarversi
    • Benchmark perbandingan dengan grep juga terdengar menarik
  • Saya sempat merancang metode serupa secara independen, tetapi menyerah karena ketergantungan pada abstraksi.
    Sebagai gantinya, saya memakai jarak Damerau-Levenshtein untuk menghitung kemiripan edit, dan jika melewati ambang tertentu, perubahan dianggap lolos.
    Dengan cara ini, model dipaksa mengeluarkan token sumber yang akan diganti secara eksplisit, sehingga akurasinya naik
    Contoh kode
    Intinya, pesan error harus spesifik — penanganan error yang menyertakan instruksi pemulihan seperti “Content mismatch. Reread the file” itu penting.
    Pendekatan ini bekerja baik bahkan pada model 4B, dan untuk model yang tidak mendukung tool call, diatasi dengan hack injeksi system prompt
    Kode terkait

  • Bahkan dengan model lama pun, hasil yang cukup akurat bisa diperoleh.
    Kuncinya adalah “memperlakukan model dengan benar”.
    Tulisan ini menyiratkan bahwa hasil yang lebih besar mungkin dicapai jika model bisa langsung menangani representasi struktural source code (AST), bukan sekadar teks.
    Misalnya, OpenRewrite memakai Lossless Semantic Tree yang mencakup tipe kode, format, dan informasi dependensi.
    Jika model bisa memanfaatkan struktur seperti ini, perubahan yang sangat akurat dapat dilakukan tanpa pemborosan token yang tidak perlu.
    Pada akhirnya, ini sama seperti alasan jawaban dari perdebatan “Vim vs Emacs” adalah “IntelliJ” — informasi struktural adalah senjata yang kuat.
    Jika model belajar bersama kode, dokumentasi, dan pohon sintaks/semantik, itu akan menjadi model coding neurosymbolic yang sesungguhnya

  • Saat bereksperimen dengan LLM lewat gptel di Emacs, saya menemukan bahwa LLM tidak pandai memodifikasi kode dengan tool patch Unix.
    Karena itu, saya memanfaatkan tree-sitter di Emacs dan membuat sendiri tool untuk gptel.
    Dengan perintah seperti tree_sitter_list_nodes dan tree_sitter_update_nodes, saya membuatnya langsung memodifikasi node AST, dan hasilnya bekerja sempurna

    • Menarik, saya penasaran apakah kodenya bisa dibagikan
  • apply_patch di Codex sebenarnya memakai skema sampling terbatas.
    Kode terkait
    Penulis melakukan perbandingan sederhana tanpa mengetahui hal ini, jadi benchmark yang lebih realistis seharusnya dilakukan dengan skema tersebut dalam keadaan aktif

  • Ada bagian kutipan dari tulisan ini yang terasa sangat berkesan
    “Bukan modelnya yang tidak memahami masalah, melainkan representasinya yang tidak stabil. Jangan salahkan pilot untuk masalah roda pendaratan.”
    “Model adalah moat, harness adalah bridge.”
    “Perbedaan antara demo keren dan tool yang andal bukanlah sihir, melainkan rekayasa yang membosankan tetapi presisi.”

    • Sangat setuju. Ini bukan sekadar nasihat sederhana, melainkan terasa seperti karya seni teknis yang menggambarkan cara berpikir penulis dengan hidup
    • Kalimat favorit saya adalah “Itu bukan ancaman. Itu R&D gratis.”