हार्नेस इंजीनियरिंग: मॉडल से ज़्यादा अहम है वर्क एनवायरनमेंट डिज़ाइन का दौर

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

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

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

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

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

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

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

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

• hook की भूमिका “AI से कह देना कि ऐसा करो” और “system का उसे मजबूर करना कि ऐसा ही हो” — ये दो अलग बातें हैं। Hook इस अंतर को भरने वाला automation mechanism है, जो tool चलाने से पहले, file बदलने के बाद, commit से पहले, या session शुरू होने पर बीच में आकर काम करता है। जैसे हर code edit के बाद अपने-आप syntax check·linter·tests चलाना, rm -rf या git push --force जैसे खतरनाक commands रोकना, या PR भेजने से पहले human approval लेना। सिद्धांत है: “success quietly, failure loudly.” Check पास हो जाए तो AI को कुछ बताया नहीं जाता; fail होने पर वही error message flow में inject हो जाता है ताकि AI उसे खुद ठीक करे। यह सामान्य स्थिति में लगभग बिना लागत के चलता है, और समस्या आने पर ठीक उसी क्षण मदद करता है।

• rules document और tool selection छोटे और स्पष्ट हों project root में रखा AGENTS.md हर turn system prompt में जाने वाली सबसे प्रभावशाली settings file है। HumanLayer सलाह देता है कि इसे 60 lines से कम रखा जाए। दस्तावेज़ जितना लंबा होगा, हर line का प्रभाव उतना हल्का होगा; इसलिए इसे सामान्य style guide की तरह नहीं, बल्कि pilot checklist की तरह रखें जिसमें सिर्फ ज़रूरी बातें हों। Tools के साथ भी यही बात लागू होती है: क्योंकि name, description, और schema हर request में prompt का हिस्सा बनते हैं, इसलिए 50 मिलते-जुलते tools से बेहतर 10 अच्छे tools हैं। HumanLayer security angle भी बताता है। Tool description वही text है जिसे AI पढ़ता है, इसलिए unverified external MCP servers जोड़ना ऐसा रास्ता बन सकता है जिससे किसी और के लिखे instructions चुपके से AI में inject हो जाएँ।

फायदे वाले पक्ष इस प्रकार हैं।

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

कुछ बोझिल पक्ष भी हैं।

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

अलग नज़रिए वाले बिंदु इस प्रकार हैं।

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

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

[kimjoin2]

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

[jimmy2056]

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

[akapwhd]

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

[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

[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 पसंद नहीं है, उसके लिए माफ़ी). बेशक, इस परिघटना को समझने की दिशा में किया गया यह एक अच्छा प्रयास लगता है.