15 LLM की coding performance बेहतर हुई, बदला सिर्फ harness

• कई 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 हैं

[github88]

मॉडल अजीब है, तो फिर से prompt engineering क्यों..

[cosine20]

हार्नेस और prompt engineering पूरी तरह अलग बातें हैं।

[GN⁺]

Hacker News की राय

• यह लेख मुझे सचमुच बहुत दिलचस्प लगा। मुझे लगता है कि लेखक ने बिल्कुल मूल बात पकड़ी है
  अभी मौजूद मॉडल्स के साथ भी, हम agent harness को कैसे डिज़ाइन करते हैं, इसके आधार पर उन्हें कहीं अधिक प्रभावी बनाया जा सकता है।
  मेरे हिसाब से “AI” को सिर्फ LLM के रूप में नहीं, बल्कि LLM और harness के feedback loop से जुड़े पूरे cybernetic system के रूप में देखना सही है।
  मॉडल और harness एक-दूसरे को मजबूत करते हैं और साथ-साथ विकसित होते हैं, इसलिए दोनों समान रूप से महत्वपूर्ण हैं।
  यह नज़रिया सिर्फ performance improvement तक सीमित नहीं है, बल्कि generative AI को neurosymbolic प्रोजेक्ट के रूप में फिर से समझने में भी मदद करता है

  • मेरे विचार से अभी भी GPT-4 के साथ बहुत कुछ बनाया जा सकता है।
    मैंने वास्तव में 2023 वर्ज़न के GPT-4 से एक coding agent बनाया था।
    पुराने मॉडल्स के साथ काम करने पर चीज़ों को सरल रखना पड़ता है, और इससे समस्या को अलग नज़रिए से देखना पड़ता है।
    उदाहरण के लिए, Python में grep -r def . जैसी सरल semantic compression ज़रूरी हो जाती है।
    Claude Code जैसे टूल में ऐसे सरल hooks जोड़ देने से token बर्बाद किए बिना code structure तुरंत समझा जा सकता है
  • मैं Peen नाम का एक CLI बना रहा हूँ। यह local Ollama models को tools अधिक कुशलता से call करने में मदद करने वाला टूल है।
    सिर्फ कुछ घंटों की prompt tuning और response handling code से ही छोटे local models की output quality हैरान करने वाले स्तर तक बेहतर हो जाती है
    GitHub लिंक
  • Claude Code और OpenAI Codex के harness भी खुद विकसित हो रहे हैं।
    OpenAI ने GPT-5.3-Codex के शुरुआती वर्ज़न से अपने training process को debug किया और deployment manage किया।
    Claude Code रोज़ 20 से ज़्यादा PR पूरी तरह अपने ही code generation से submit कर रहा है
  • वैसे, मेरी लिखने की शैली में “It’s not just X, it’s Y” जैसी संरचना अक्सर आती है, लेकिन यह थकान की वजह से है, LLM ने नहीं लिखा
  • SWE-bench docs देखें तो वहाँ लगभग मनमाने ढंग की context engineering इस्तेमाल होती दिखती है।
    वास्तव में हमें यह भी ठीक से नहीं पता कि कौन-से मॉडल अच्छे context engineering के प्रति संवेदनशील हैं।
    लेकिन इतना तय है कि अभी भी बहुत-से low hanging fruit मौजूद हैं, इस बात से मैं सहमत हूँ

• यह तकनीक दिलचस्प है, लेकिन इसमें ज़रूरत से ज़्यादा बढ़ा-चढ़ाकर बात की गई लगती है।
  लेखक ने अपने बनाए एक सरल find/replace benchmark में 5% सुधार देखा और उसे ऐसे पेश किया जैसे कुल performance 14 points बढ़ गई हो।
  असल में, कुल token efficiency में सुधार शायद 1% से भी कम हो।
  ऊपर से, लेख का अतिनाटकीय लहजा और ChatGPT जैसी शैली भरोसा कम कर देती है

  • अगर फ़ॉर्मैट “replace line 2:f1…” जैसा हो, तो वास्तविक efficiency शायद 20% से कहीं अधिक भी हो सकती है
  • benchmark में token usage 25~50% कम होने की बात है, लेकिन वास्तविक उपयोग के माहौल में उतना असर होगा या नहीं, इस पर शक है

• यह लेख अच्छी तरह दिखाता है कि harness स्तर पर सुधार की कितनी बड़ी गुंजाइश है।
  agents editing, sandboxing, और tool calls के बीच data transfer जैसी चीज़ों में बहुत token बर्बाद करते हैं।
  content-based addressing + line numbering का संयोजन व्यावहारिक भी है और सुंदर भी

  • सबसे बड़ी बर्बादी शायद हर जगह MCP का इस्तेमाल करना हो सकता है।
    शुरुआती development आसान हो जाती है, लेकिन इससे बेवजह बहुत बड़े models call होते हैं, जो अक्षम है
  • मैंने ClaudeCode Superpowers plugin इस्तेमाल किया है, और features अच्छे हैं, लेकिन काफ़ी महँगा पड़ता है।
    CC में /cost कमांड से प्रति session लागत देखी जा सकती है, और ऐसे metrics से plugin efficiency को परखना अच्छा रहेगा
  • दूसरी तरफ, ज़्यादा tokens खर्च करके जटिल समस्याओं को छोटी subproblems में बाँटकर हल करने वाला तरीका भी अपनाया जा सकता है

• harness का महत्व ज़्यादातर लोगों की सोच से कहीं बड़ा है।
  उदाहरण के लिए, Opus का CORE benchmark score अपने harness से Claude Code में बदलते ही लगभग दोगुना हो गया
  संबंधित लिंक

  • Pi terminal agent के निर्माता Mario की ब्लॉग पोस्ट में भी
    बताया गया है कि TerminalBench का सर्वोच्च score Terminus 2 harness की वजह से था
  • इसलिए हमें harness को स्वतंत्र रूप से बदल पाने या खुद बनाने की सुविधा होनी चाहिए।
    सिर्फ $20 मासिक subscription की वजह से किसी खास harness से बँध जाना तर्कसंगत नहीं है

• मैंने tilth नाम का एक टूल बनाया है, जो hash-based read/edit तरीका लागू करता है।
  यह npm और cargo पर install किया जा सकता है और Claude Code या Cursor जैसे editors के साथ integrate होता है
  GitHub लिंक
  इसका लक्ष्य LLM को tools अधिक कुशलता से इस्तेमाल करने देना और token wastage कम करना है

  • यह Markdown पर भी लागू किया जाए तो अच्छा होगा। section-level addressing जोड़ने से versions के बीच stability बढ़ेगी
  • grep के साथ benchmark comparison भी दिलचस्प होगा

• मैंने इसी तरह का तरीका स्वतंत्र रूप से सोचा था, लेकिन abstraction dependency की वजह से छोड़ दिया।
  उसकी जगह मैंने Damerau-Levenshtein distance का इस्तेमाल करके edit similarity निकाली, और एक threshold से ऊपर होने पर modification pass होने दिया।
  इससे मॉडल को replace किए जाने वाले source tokens स्पष्ट रूप से output करने पड़ते हैं, जिससे accuracy बढ़ती है
  कोड उदाहरण
  असली बात यह है कि error message ठोस होना चाहिए — “Content mismatch. Reread the file” जैसी recovery instructions वाली error handling महत्वपूर्ण है।
  यह तरीका 4B models पर भी अच्छी तरह काम करता है, और जिन models में tool calls का support नहीं है, उनके लिए system prompt injection hack का उपयोग किया जाता है
  संबंधित कोड

• पुराने मॉडल्स से भी काफ़ी सटीक नतीजे मिल सकते थे।
  असली कुंजी थी मॉडल को “सही तरीके से संभालना”।
  यह लेख संकेत देता है कि अगर मॉडल सिर्फ text नहीं, बल्कि source code की structural representation (AST) को सीधे संभाल सके, तो और बड़े परिणाम मिल सकते हैं।
  उदाहरण के लिए OpenRewrite ऐसा Lossless Semantic Tree इस्तेमाल करता है जिसमें code का type, formatting, और dependency information सब शामिल होता है।
  अगर मॉडल ऐसी संरचना का उपयोग करे, तो बेवजह tokens खर्च किए बिना बहुत सटीक edits किए जा सकते हैं।
  आखिरकार, “Vim vs Emacs” बहस का जवाब “IntelliJ” क्यों होता है, यह भी वही बात है — structural information एक शक्तिशाली हथियार है।
  अगर मॉडल code, docs, और syntax/semantic trees को साथ में सीखें, तो वह सचमुच का neurosymbolic coding model बन सकता है

• Emacs के gptel के साथ LLM पर प्रयोग करते हुए मैंने पाया कि LLM Unix patch tool से code edit करने में अच्छे नहीं हैं।
  इसलिए मैंने Emacs के tree-sitter का उपयोग करके gptel के लिए खुद टूल बनाए।
  tree_sitter_list_nodes, tree_sitter_update_nodes जैसे commands से AST nodes को सीधे edit करवाया, और यह पूरी तरह काम कर गया

  • यह दिलचस्प है, क्या आप वह code साझा कर सकते हैं?

• Codex का apply_patch वास्तव में constrained sampling schema का उपयोग करता है।
  संबंधित कोड
  लेखक को इसका पता नहीं था और उसने साधारण तुलना की, इसलिए अधिक यथार्थवादी benchmark इस schema को enabled रखकर किया जाना चाहिए

• इस लेख के उद्धरणों में एक हिस्सा खास तौर पर याद रह गया
  “मॉडल समस्या को समझ नहीं रहा, बात यह नहीं है; representation अस्थिर है। landing gear की समस्या के लिए pilot को दोष मत दो।”
  “मॉडल moat है, harness bridge है।”
  “शानदार demo और भरोसेमंद tool के बीच का फ़र्क जादू नहीं, बल्कि उबाऊ लेकिन बेहद सटीक engineering है।”

  • पूरी तरह सहमत। यह सिर्फ़ सलाह नहीं, बल्कि लेखक की सोच को जीवंत बना देने वाली तकनीकी कलाकृति जैसी लगती है
  • मेरी पसंदीदा पंक्ति है: “वह ख़तरा नहीं है। मुफ़्त R&D है।”