हॉर्नेस इंजीनियरिंग: मॉडल से ज़्यादा महत्वपूर्ण कार्य-परिवेश डिज़ाइन का दौर

यह Addy Osmani द्वारा संकलित “Harness Engineering” पर एक विश्लेषण है। उनका कहना है कि पिछले दो वर्षों में उद्योग का ध्यान लगभग पूरी तरह इस सवाल पर टिका रहा कि “कौन-सा AI मॉडल अधिक स्मार्ट है।” GPT क्या अधिक साफ़ कोड लिखता है, Claude क्या कम hallucination करता है—ऐसी अंतहीन तुलना चलती रही, लेकिन उनका तर्क है कि वास्तविक coding AI का प्रदर्शन अक्सर स्वयं मॉडल से ज़्यादा उस हार्नेस से तय होता है जो मॉडल को घेरे रहता है। हार्नेस से आशय मॉडल को छोड़कर बाकी सब कुछ है: AI को काम कराने वाला system prompt, उपयोग किए जा सकने वाले tools और external servers, context management policy, execution के दौरान अपने-आप दखल देने वाले checks (hooks), सुरक्षित execution space (sandbox), सहायक AI (sub-agent), feedback loop, और काम अटकने पर recovery flow तक। Viv Trivedy ने इस विचार को “AI agent = model + harness” की एक पंक्ति में औपचारिक रूप दिया, और Anthropic engineering team, HumanLayer, Simon Willison जैसे लोग इस प्रवाह को और परिष्कृत कर रहे हैं। Osmani का मानना है कि यह अब अपने आप में एक इंजीनियरिंग discipline बन चुका है.

मुख्य बिंदु इस प्रकार हैं।

• हार्नेस क्या है केवल मॉडल से AI कोई काम पूरा नहीं कर सकता। उसे प्रगति याद रखनी होती है, tools चलाने होते हैं, परिणाम देखकर फिर निर्णय लेना होता है, और जिन कामों से बचना चाहिए उन्हें रोकने वाला code और configuration भी चाहिए। तभी वह “काम करने वाला AI” बनता है। Claude Code, Cursor, Codex, Aider, Cline जैसे उत्पाद सभी हार्नेस हैं, और भीतर का मॉडल समान होने पर भी हमारा अनुभव हार्नेस तय करता है। Simon Willison के शब्दों में, AI agent “लक्ष्य हासिल करने के लिए tools को बार-बार चलाने वाली system” है, और उन tools तथा iteration structure को कैसे डिज़ाइन किया जाता है, यही असली क्षमता है।

• गलती मॉडल की नहीं, configuration की भी हो सकती है जब AI कोई अजीब हरकत करता है, तो engineers अक्सर मॉडल को दोष देते हैं और निष्कर्ष निकालते हैं कि “अगला version आने का इंतज़ार करें।” Harness engineering इस प्रतिक्रिया को अस्वीकार करती है। HumanLayer के शब्दों में, “यह model problem नहीं, skill issue है।” उदाहरण के तौर पर, वही Claude Opus 4.6 मॉडल default harness Claude Code में Terminal Bench 2.0 में निचले स्तर पर रहा, लेकिन एक कस्टम हार्नेस में ले जाने पर शीर्ष स्तर के पास पहुँच गया। Viv की टीम ने सिर्फ हार्नेस बदलकर उसी मॉडल को लगभग 30वें स्थान से 5वें स्थान तक पहुँचा दिया। यानी मॉडल की क्षमता को कई बार हार्नेस ही सीमित कर रहा होता है।

• गलतियों को नियम में बदलने का “ratchet” सिद्धांत AI ने यदि कोई गलती एक बार भी की, तो उसे आकस्मिक दुर्घटना मानकर छोड़ना नहीं चाहिए, बल्कि स्थायी संकेत मानना चाहिए। अगली बार वही गलती न हो, इसके लिए rule document में एक पंक्ति जोड़ें, automatic blocking device लगाएँ, या review के लिए सहायक AI रखें—इस तरह प्रणाली को एक-एक कदम कसते जाएँ। उदाहरण के लिए, अगर AI ने test code को comment out कर दिया, तो अगली version की rule file में यह लिखा जाएगा कि “tests को comment out न करें; उन्हें हटाएँ या ठीक करें,” और pre-commit stage में ऐसे pattern पकड़ने वाला checker जोड़ दिया जाएगा। अच्छे rule document की हर पंक्ति किसी वास्तविक पुरानी विफलता से जुड़ी होनी चाहिए। इसलिए harness engineering कोई तैयार framework उठाकर लगाने का काम नहीं, बल्कि अपने codebase की failure history के आधार पर विकसित होने वाला एक अनुशासन है।

• वांछित व्यवहार से उलटा डिज़ाइन करना Viv द्वारा सुझाया गया सबसे उपयोगी सोचने का तरीका है: “हमें यह व्यवहार चाहिए → तो उसे संभव बनाने वाले harness components कौन-से हैं?” यदि किसी component के बारे में एक पंक्ति में नहीं बताया जा सकता कि वह किस व्यवहार के लिए मौजूद है, तो बेहतर है उसे हटा दिया जाए। उदाहरण के तौर पर, file system और Git लंबे समय तक काम सहेजने और rollback के लिए हैं; bash और code execution किसी भी प्रयोग के लिए general-purpose tools हैं; sandbox ऐसा सुरक्षित execution space है जहाँ गलती होने पर मुख्य system प्रभावित न हो; memory files, web search और MCP tools नया ज्ञान जमा करने के रास्ते हैं; summary compression, tool output separation, और skill features AI की memory limitation बढ़ाने के उपाय हैं; और Ralph loop तथा planner-evaluator separation कई दिनों तक चलने वाले लंबे tasks को अंत तक ले जाने के तरीके हैं।

• context rot की समस्या AI एक बार में पढ़ी जा सकने वाली सामग्री की मात्रा में सीमित है, और जैसे-जैसे वह सीमा भरती है, निर्णय-क्षमता स्पष्ट रूप से गिरती है। इसलिए हार्नेस सीमित context space का बेहतर उपयोग करने वाले उपायों का समूह भी है। पहला, सीमा भरने लगे तो पुराने हिस्सों का समझदारी से summary बनाकर compression किया जाता है। दूसरा, 2,000-पंक्ति वाले log जैसे बड़े outputs में सिर्फ शुरुआत और अंत रखा जाता है और बीच का भाग file में अलग रख दिया जाता है, ताकि ज़रूरत पड़ने पर ही फिर पढ़ा जाए। तीसरा, tools और instructions को शुरुआत से पूरा नहीं दिखाया जाता, बल्कि जिस task में वास्तव में जब ज़रूरत हो तभी “progressive disclosure” के रूप में सामने लाया जाता है। बहुत लंबे tasks में तो कभी-कभी नए window में केवल handoff document लेकर शुरुआत से फिर शुरू किया जाता है। Anthropic का कहना है कि “लंबे tasks में केवल summary compression काफ़ी नहीं होता; कभी-कभी structured handoff document के साथ नए सिरे से शुरू करना पड़ता है।” यह वैसा ही है जैसे किसी नए कर्मचारी को काम सौंपते समय साफ़-सुथरा handover document दिया जाए।

• लंबे tasks को संभालने वाले patterns आज के models की एक कमजोरी यह है कि वे जल्दी काम समाप्त करना चाहते हैं, बड़ी समस्या को छोटे हिस्सों में तोड़ने में कमजोर हैं, और context window बदलते ही flow टूट जाता है। हार्नेस को इन कमजोरियों की भरपाई करनी चाहिए। Ralph loop एक सरल तकनीक है: जब मॉडल काम समाप्त करने की कोशिश करे, तो hook बीच में आकर मूल goal को नए context window में फिर inject कर दे ताकि काम जारी रहे। हर iteration साफ़ स्थिति से शुरू होता है, लेकिन पिछला परिणाम file system के ज़रिए जुड़ा रहता है। दूसरी ओर Anthropic इस बात पर ज़ोर देता है कि “generation” और “evaluation” को अलग-अलग AI को सौंपना चाहिए, क्योंकि AI अपने ही output को जज करते समय अक्सर ज़्यादा उदार होता है। इसके अलावा, task शुरू होने से पहले ही “done” की स्पष्ट परिभाषा तय कर लेने वाला “sprint contract” pattern लक्ष्य के धीरे-धीरे फैलने से बचाने में उपयोगी है।

• hooks की भूमिका “AI से ऐसा करने को कहना” और “system का उसे मजबूर करना” दो अलग बातें हैं। Hook इस अंतर को भरने वाला automation mechanism है, जो tool चलाने से पहले, file बदलने के बाद, commit से पहले, या session शुरू होते समय दखल देता है। जैसे हर code change पर अपने-आप syntax check, lint, test चलाना; rm -rf या git push --force जैसे खतरनाक commands रोकना; या PR भेजने से पहले human approval अनिवार्य करना। सिद्धांत है: “success शांत रहे, failure शोर करे।” Check पास हो जाए तो AI को कुछ न बताया जाए; fail हो तो वही error message flow में inject कर दिया जाए ताकि वह खुद सुधार करे। यह सामान्य समय में लगभग बिना लागत का, लेकिन समस्या आने पर बेहद सटीक मदद देने वाला ढाँचा है।

• rule document और tool selection छोटे व स्पष्ट हों project root में रखा AGENTS.md वह सबसे प्रभावशाली configuration file है जो हर turn system prompt में जाती है। HumanLayer सलाह देता है कि इसे 60 पंक्तियों से कम रखा जाए। दस्तावेज़ लंबा होने पर हर पंक्ति का प्रभाव हल्का पड़ता है, इसलिए इसे सामान्य style guide नहीं बल्कि पायलट की checklist की तरह केवल आवश्यक बिंदुओं तक सीमित रखना चाहिए। Tools पर भी यही लागू होता है: नाम, विवरण और schema हर request के साथ prompt में शामिल होते हैं, इसलिए लगभग समान 50 tools की तुलना में अच्छी तरह संवारे गए 10 tools बेहतर हैं। HumanLayer सुरक्षा की ओर भी इशारा करता है। Tool description खुद AI द्वारा पढ़ा जाने वाला text है, इसलिए बिना सत्यापित external MCP server जोड़ना AI को किसी और के लिखे निर्देश चुपके से inject करने का रास्ता बन सकता है।

ध्यान देने योग्य फायदे।

• मेहनत किस जगह लगानी है, यह स्पष्ट होता है benchmark data दिखाता है कि मॉडल बदले बिना भी व्यवहार में बड़ा सुधार लाने की जगह हार्नेस है। यानी “अगले मॉडल का इंतज़ार करें” जैसी अस्पष्ट उम्मीद के बजाय अभी सुधारने लायक ठोस क्षेत्र सामने आता है।
• know-how जमा होने वाली संरचना ratchet approach की वजह से एक बार सीखी गई सीख team asset बन जाती है। लोग बदल जाएँ, तब भी rule documents और hooks बने रहते हैं और अगले व्यक्ति को सुरक्षित रखते हैं।
• तैयार हार्नेस का उदय (HaaS) Viv जिस प्रवाह को “Harness-as-a-Service” कहते हैं, वह तेज़ी से स्थापित हो रहा है। Claude Agent SDK, Codex SDK, OpenAI Agent SDK जैसे products task loop, tools, context management, hooks और sandbox को पहले से पैक करके देते हैं, जिससे सब कुछ शून्य से बनाने के बजाय अपनी domain knowledge पर ध्यान दिया जा सकता है।

कुछ भारी पड़ने वाले पहलू भी हैं।

• संभालने के क्षेत्र बहुत व्यापक हैं instructions, tools, safe execution space, automatic checks, log observation—इन सबकी ज़िम्मेदारी खुद लेनी पड़ती है। मुख्य बात यह है कि यह क्षेत्र model provider अपने-आप संभाल नहीं देता।
• मॉडल और हार्नेस के coupling का जोखिम आज के models अक्सर किसी खास हार्नेस के भीतर post-training से गुजरते हैं, इसलिए उन्हें किसी दूसरे हार्नेस में ले जाने पर प्रदर्शन अचानक गिर सकता है। सिर्फ tool का नाम या argument format बदलने से भी परिणाम बदल सकते हैं। आदर्श रूप से एक सामान्य model को tool names से प्रभावित नहीं होना चाहिए, लेकिन co-training जैसी संरचना के कारण एक तरह का overfitting पैदा हो जाता है।
• external tools से सुरक्षा जोखिम MCP server में tool descriptions सीधे AI को पढ़ने के लिए मिलती हैं, इसलिए जैसे ही बिना सत्यापन वाले tools जोड़े जाते हैं, उपयोगकर्ता के कुछ लिखने से पहले ही बाहरी text AI के व्यवहार को प्रभावित करने लगता है।

अलग पहचान देने वाले दृष्टिकोण।

• model-centric चर्चा से दूरी “और स्मार्ट GPT” का इंतज़ार करने के बजाय यह दृष्टिकोण बताता है कि अभी उपलब्ध मॉडल से सीमा तक पहुँचने के लिए कौन-से इंजीनियरिंग तरीके अपनाए जाएँ। इसमें यह निदान है कि आज दिखाई देने वाली AI की अधिकांश सीमाएँ वास्तव में harness gap हैं, न कि केवल model gap।
• हार्नेस गायब नहीं होता, बस अपनी जगह बदलता है मॉडल बेहतर होते हैं तो कुछ harness components अनावश्यक हो जाते हैं। उदाहरण के लिए, Opus 4.6 ने Claude Sonnet 4.5 में दिखने वाली उस आम घबराहट को काफ़ी हद तक हटा दिया कि “context लगभग खत्म होने वाला है, जल्दी निष्कर्ष निकालना होगा,” और इससे पहले इस्तेमाल होने वाले कई safety crutches बेकार code बन गए। लेकिन जैसे ही मॉडल नए क्षेत्रों तक पहुँचते हैं, नई कमजोरियाँ सामने आती हैं, और उन्हें भरने के लिए नए harness फिर चाहिए होते हैं। Anthropic का यह कथन यहाँ उपयुक्त लगता है: “हार्नेस का हर component इस धारणा को समेटे होता है कि मॉडल अपने-आप क्या नहीं कर सकता।”
• मॉडल और हार्नेस के बीच learning loop Viv द्वारा रेखांकित एक और प्रवाह यह है कि harness design और model training के बीच feedback loop बनता है। हार्नेस में उपयोगी patterns खोजे जाते हैं, वे standardize होते हैं, अगली पीढ़ी के models उन्हीं patterns के आधार पर train होते हैं, और फिर उन्हीं models पर नए harness patterns बनते हैं। इसलिए निष्कर्ष यह निकलता है कि “अच्छा हार्नेस” वह नहीं जो model के training setup जैसा हो, बल्कि वह है जिसे अपने काम के मुताबिक दोबारा तराशा गया हो।
• उद्योग का एक जैसी आकृति की ओर अभिसरण Claude Code, Cursor, Codex, Aider, Cline जैसे coding AI भीतर अलग-अलग models रखते हैं, लेकिन हार्नेस का आकार धीरे-धीरे मिलता-जुलता होता जा रहा है। मॉडल अलग हैं, लेकिन हार्नेस समान होते जा रहे हैं—यह इस बात का संकेत है कि यह क्षेत्र किस स्थिर रूप की ओर बढ़ रहा है।

Osmani का लेख यह दृष्टिकोण सामने रखता है कि coding AI की प्रतिस्पर्धात्मक क्षमता model selection से अधिक उसके आसपास के harness design पर निर्भर करती है, और हार्नेस कोई एक बार सेट करके छोड़ देने वाली configuration file नहीं, बल्कि failure history के आधार पर लगातार अपडेट होने वाला जीवित system है। मॉडल बेहतर होने से हार्नेस समाप्त नहीं होता; बल्कि समस्या की परत ऊपर खिसकती है और नया हार्नेस उस जगह को भरता है। Viv के उद्धृत शब्दों में, “अच्छा agent बनाना iteration की कला है, और first version न हो तो iteration भी नहीं होती।” इसका अर्थ यह है कि अंततः यह क्षेत्र इस बात की प्रतिस्पर्धा है कि कौन जल्दी शुरू करता है और किसकी refinement cycle अधिक तेज़ है। निष्कर्ष यही है कि engineers को अपना समय हर बार चर्चित मॉडल बदलने में नहीं, बल्कि अपने काम के अनुरूप हार्नेस को लगातार सुधारते हुए मॉडल की वास्तविक सीमा को एक-एक स्तर ऊपर उठाने में लगाना चाहिए।

[kimjoin2]

लगता है कि बस मार्केटिंग के शब्द ही बहुत ज़्यादा बढ़ते जा रहे हैं।

[dongho42]

लेकिन जब prompt में A करो, B मत करो जैसा कहा जाता है, तो अगर वह इसे सच में बहुत अच्छी तरह समझे तभी ऐसा approach कारगर लगेगा। AI server की स्थिति के हिसाब से अगर prompt को probabilistic तरीके से follow किया जाता है, तो क्या ऐसा approach फिर भी प्रभावी होगा?

[dongho42]

पहले मैं prompt में साफ़-साफ़ लिखता था कि A करो, फिर भी एक तय संभावना के साथ वह बार-बार नहीं मानता था, इसलिए मैंने mrkdwn bold से ज़ोर देकर देखना, दो बार लिखकर देखना, English में लिखकर देखना, शुरुआत और अंत को जोड़कर लिखना, XML में लिखकर देखना—ऐसे न जाने क्या-क्या करके देखा, लेकिन वह फिर भी एक तय संभावना के साथ prompt को नज़रअंदाज़ करता रहा...

[kurthong]

मुझे भी उस Osmani वाली बात जैसा सब कुछ ठूंसकर ऐप बनाते समय यही बात सामने आई, इसलिए थोड़ा जल्दबाज़ी में कह रहा हूँ,
लेकिन Osmani भी सिर्फ़ बातों तक सीमित रहने के बजाय
अगर उसने Google Anti-Gravity में अपनी कही हुई बातों को शामिल कराया होता तो शायद बेहतर नहीं होता?
Kapasi भी ऐसा ही है, अब बस बनाने का सोचते ही नहीं और सिर्फ़ एक लेख फेंककर खत्म कर देने वाला रवैया है, इस पर तो बस कहना पड़ेगा: पता नहीं!

https://github.com/hang-in/tunaFlow

[tangokorea]

मॉडल और harness में कौन बेहतर है, इस नज़रिए से एक कदम पीछे हटकर, अगर हम यह देखें कि किस मॉडल के लिए कौन-सा harness ज़्यादा उपयुक्त है, तो कैसा रहेगा?

[jimmy2056]

मॉडल अच्छा हो तो Harness डिज़ाइन का बोझ भी कम हो जाता है।

[akapwhd]

ऐसी चीज़ें लागू कर भी दें तो असल coding करते वक्त ये बहुत मददगार नहीं लगतीं... शायद इसलिए क्योंकि यह codex plan रखकर agent चलाने जितनी ही कठिनाई वाला development है haha

[blackfabric]

3 पंक्तियों में सारांश

• मॉडल से ज्यादा सिस्टम (harness) सफलता या विफलता तय करता है: AI का प्रदर्शन GPT या Claude जैसे मॉडल से अधिक, उसके आसपास बने prompt, tools, sandbox, feedback loop आदि यानी 'harness' कहलाने वाले कार्य-पर्यावरण के डिज़ाइन पर निर्भर करता है।
• गलतियों को नियम में बदलने का 'Ratchet' सिद्धांत: AI की गलती को साधारण चूक मानकर छोड़ने के बजाय, उसे तुरंत नियम दस्तावेज़ (जैसे AGENTS.md) या hook में शामिल करना चाहिए, ताकि समय के साथ सिस्टम और मजबूत होता जाए।
• समस्या मॉडल की नहीं, configuration (Skill) की है: कई बार AI का खराब प्रदर्शन उसकी बुद्धिमत्ता की कमी नहीं, बल्कि harness डिज़ाइन की कमजोरी के कारण होता है; इसलिए इच्छित परिणाम से उलटी दिशा में सोचकर आवश्यक घटकों और constraints को डिज़ाइन करने वाला engineering approach अनिवार्य है।

[yungoun]

लेकिन Harness को पिछले हफ़्ते तक तो खूब बेचा जा रहा था, इस हफ़्ते से फिर शांत है.. शायद Anthropic की गड़बड़ी और Codex 5.5 के शानदार होने की वजह से........

[click]

SDD जैसी चीज़ों का hype तो काफ़ी पहले ही खत्म हो चुका था, अब लगता है बारी harness की है।
हैरानी वाली बात यह है कि harness में एक हिस्सा ऐसा है जो साफ़ तौर पर training data में नहीं था, फिर भी model ने harness जैसी अवधारणा को बहुत जल्दी समझ लिया।
शायद इसलिए कि उसने पहले से मौजूद शब्द के अर्थ को उसी तरह इस्तेमाल किया; मैंने इसका ज़िक्र भी नहीं किया था, लेकिन वह खुद ही harness को update करते हैं जैसी बातें कहने लगा।

[kurthong]

यह तो एक ऐसे वरिष्ठ डेवलपर के लेख का विश्लेषण तक किया गया है जो बिना खास सार वाली बातों को भी काफ़ी भरोसेमंद ढंग से पेश करता है (व्यक्तिगत रूप से मुझे Google पसंद नहीं है, उसके लिए माफ़ी). बेशक, इस परिघटना को समझने की दिशा में किया गया यह एक अच्छा प्रयास लगता है.