- कई LLMs को समान शर्तों पर टेस्ट करने पर पाया गया कि सिर्फ code editing tool बदलने से performance में बड़ा सुधार हुआ
- मौजूदा Patch·Replace method की जगह हर code line पर hash tag देने वाला ‘Hashline’ format लागू कर edit accuracy बढ़ाई गई
- Hashline ने 16 में से 14 models में पुराने तरीकों से बेहतर accuracy दिखाई, और औसतन 20~30% token बचत भी देखी गई
- खासकर Grok Code Fast 1 model की success rate 6.7% से 68.3% तक उछली, यानी सिर्फ harness बदलने से 10 गुना सुधार हुआ
- यह research दिखाती है कि model खुद से ज़्यादा ‘harness’ ही वास्तविक performance bottleneck हो सकता है, और open source ecosystem में collaboration की ज़रूरत पर ज़ोर देती है
code editing benchmark का overview
- experiment में Patch, Replace, Hashline इन तीन editing formats की तुलना की गई
- 16 models पर एक ही code-fixing tasks चलाए गए
- हर model को React codebase में random चुनी गई files के bugs ठीक करने के तरीके से टेस्ट किया गया
- Hashline format ने 14 models में Patch से बेहतर नतीजे दिखाए और औसतन 20~30% tokens बचाए
- सबसे बड़ा सुधार Grok Code Fast 1 में दिखा, जहाँ success rate 6.7% से 68.3% तक बढ़ी (+61.6pp)
- Gemini 3 Flash में 5.0pp, Claude Sonnet 4.5 में 1.6pp सुधार हुआ
harness समस्या
- अभी की ज़्यादातर चर्चा इस पर केंद्रित है कि “कौन-सा model coding सबसे अच्छा करता है”, लेकिन असली bottleneck model नहीं, harness है
- harness input tokens को manage करता है और model output को workspace changes से जोड़ने वाला core interface है
- ज़्यादातर failures model की वजह से नहीं, बल्कि harness की structural limits की वजह से होते हैं
- लेखक ने open source coding agent Pi को fork करके बने अपने personal project oh-my-pi के जरिए लगभग 1,300 commits करते हुए सुधार की कोशिश की
- यह environment model-independent है और इसमें सिर्फ harness को variable रखकर experiment किया जा सकता है
मौजूदा editing tools की सीमाएँ
- Codex का
apply_patch तरीका OpenAI-specific diff format इस्तेमाल करता है, इसलिए दूसरे models में failure rate ऊँची रहती है
- उदाहरण: Grok 4 की patch failure rate 50.7%, GLM-4.7 की 46.2%
- Claude Code का
str_replace तरीका strings के perfect match पर निर्भर करता है, इसलिए whitespace या indentation के फर्क से errors आते हैं
- GitHub पर “String to replace not found in file” error की कई reports मिली हैं
- Cursor merging संभालने के लिए अलग 70B model train करता है, लेकिन 400 lines से छोटी files में full rewrite ज़्यादा अच्छे results देता है
- JetBrains के Diff-XYZ, EDIT-Bench research में भी यह पुष्टि हुई कि editing format के अनुसार performance काफ़ी बदलती है
Hashline तरीके का सिद्धांत
- हर code line को 2~3 characters लंबे content hash दिए जाते हैं, ताकि model edit target को साफ़-साफ़ identify कर सके
- उदाहरण:
22:f1| return "world";
- model “replace line 2:f1” की तरह hash के आधार पर edit request करता है
- अगर file बदलने से hash mismatch हो जाए, तो edit reject कर दी जाती है ताकि corruption न हो
- इस तरीके में model को पुरानी content दोबारा reproduce नहीं करनी पड़ती, इसलिए whitespace·indentation errors घटते हैं और edit ज़्यादा stable होती है
benchmark results
- test में 180 bug-fixing tasks, 3 repeats, और 4 tools (read, edit, write, etc.) शामिल थे
- नतीजतन Patch format लगभग सभी models में सबसे खराब रहा, जबकि Hashline Replace के बराबर या उससे बेहतर रहा
- model जितना कमजोर, सुधार उतना बड़ा
- Grok 4 Fast में output tokens 61% घटे, MiniMax में performance दो गुने से ज़्यादा बेहतर हुई
- Gemini की success rate +8% का सुधार आम model upgrade से भी बड़ा है, और यह बिना अतिरिक्त training के हासिल हुआ
vendor policies और open source ecosystem
- Anthropic ने open source coding agent OpenCode के लिए Claude Code access block कर दिया
- वजह “private API reverse engineering” बताई गई, लेकिन इसका अर्थ यह निकाला गया कि “सिर्फ अपना harness इस्तेमाल करो”
- Google ने लेखक का account block करके Gemini access रोक दिया
- यह Hashline लागू होने के बाद Gemini 3 Flash की performance 78.3% तक बढ़ने वाले benchmark के तुरंत बाद हुआ
- लेखक का कहना है कि ऐसे कदम model improvement के अवसरों को रोकने वाली backward move हैं
- harness optimization किसी एक model नहीं, बल्कि सभी models की quality बढ़ाने वाली public research है
- “model moat है, harness bridge है” कहकर लेखक ज़ोर देता है कि closed approach ecosystem की growth को बाधित करती है
निष्कर्ष
- harness समस्या एक measurable factor है जो वास्तविक performance पर सीधे असर डालता है
- सिर्फ format बदलने से भी model upgrade के बराबर सुधार मिल सकता है
- आगे की दिशा एकल कंपनी के बंद सुधार नहीं, बल्कि community-based open collaboration होनी चाहिए
- सारा code, benchmark, और execution results GitHub repository oh-my-pi में public हैं
अभी कोई टिप्पणी नहीं है.