AI के बाद का सॉफ्टवेयर: Harness युग की शुरुआत

• सॉफ्टवेयर युग का अंत Harness युग की शुरुआत है, और fixed workflow तथा managed DB पर चलने वाला SaaS अब intelligence से लैस AI द्वारा प्रतिस्थापित हो रहा है
• AI शक्तिशाली है, लेकिन एक जंगली घोड़े की तरह अभी काबू में नहीं है; उसकी शक्ति का उपयोग करने के लिए व्यवस्थित नियंत्रण (domestication) ज़रूरी है
• AI agent harness को केंद्र में मौजूद LLM के चारों ओर बने 7 प्रमुख components से परिभाषित किया जाता है, और हर component production-grade reliability तथा performance को निर्धारित करता है
• ऐसे दौर में जब हर कंपनी समान model तक पहुँच सकती है, जीत model की नहीं बल्कि बेहतर harness डिज़ाइन और संचालन करने वालों (best rider) की होगी
• हजारों अलग-अलग markets जिन्हें big labs प्राथमिकता नहीं देते, startups के लिए अवसर बने रहते हैं

---

Harness युग का अर्थ

• AI fixed workflow-आधारित SaaS और managed database को intelligence से replace करते हुए software paradigm को फिर से परिभाषित कर रहा है
• AI की तुलना mustang (जंगली घोड़े) से की गई है: यह शक्तिशाली है, लेकिन खुरदुरा है और सीधे इस्तेमाल नहीं किया जा सकता; इसे काबू में लाने की प्रक्रिया ही harness है
• इस domestication का सार एक ऐसी architecture है जिसमें LLM केंद्र में होता है और उसके आसपास 7 components रेडियल रूप से व्यवस्थित होते हैं

AI agent harness के 7 प्रमुख components

• 1. Context & Memory (संदर्भ और मेमोरी)

  • सामान्य-purpose model के लिए use-case specific bespoke retrieval की ज़रूरत होती है; radiologist के लिए context retrieval system और legal assistant के लिए system एक जैसे नहीं हो सकते
  • short-term memory ("agent 45 सेकंड पहले क्या कर रहा था"), large-scale image retrieval (radiology·image generation), अरबों documents पर keyword search — हर case में अलग system चाहिए
  • retrieval के साथ context database होता है, जो business के वास्तविक संचालन का "recipe book" बनता है
    • लोग अपने दिमाग में लेकर काम पर आने वाली standard operating procedures (SOP) ही वह recipe हैं
    • शुरुआती capture और लोगों/प्रक्रियाओं में बदलाव के साथ उसका evolve होना context DB का मूल है

• 2. Tools & Action (टूल्स और कार्रवाई)

  • tools वे साधन हैं जिनसे agent बाहरी दुनिया पर असर डालता है; अगर context DB की recipe बताती है कि "क्या करना है", तो tools उसे वास्तव में करने वाले ingredients और instruments हैं
  • आधुनिक harness registry के माध्यम से tools को expose करता है, model द्वारा भेजे गए arguments को validate करता है, call dispatch करता है, sensitive actions को approval gate से गुजारता है, और results को agent loop में parse करता है
  • MCP tool connectivity के लिए connective tissue के रूप में उभर रहा है
  • harness की गुणवत्ता इस बात से तय होती है कि कितने tools को सुरक्षित रूप से expose किया जा सकता है और failures को कितनी साफ़-सुथरी तरह संभाला जाता है

• 3. Orchestration & Loop (ऑर्केस्ट्रेशन और लूप)

  • agent loop की संरचना think → act → observe → repeat होती है
  • planning, task decomposition, sub-agents, retries, और stop conditions यह तय करते हैं कि काम कैसे किया जाएगा
  • यह इस्तेमाल के साथ बेहतर होना चाहिए, और हर execution से सीखने वाला closed-loop pattern vendors के बीच differentiation का बिंदु बनता है

• 4. State & Persistence (स्टेट और परसिस्टेंस)

  • बड़े enterprise में, जहाँ कई लोग एक साथ system का उपयोग करते हैं, resilience अनिवार्य है
  • अगर 10-step काम के 7वें step पर harness crash हो जाए, तो उसे शुरू से नहीं बल्कि 8वें step से resume होना चाहिए
  • file system, checkpoints, session threads, और artifact stores काम के loss को रोकने वाले mechanisms हैं

• 5. Sandbox & Compute (सैंडबॉक्स और कंप्यूट)

  • हर agent को स्वतंत्र workspace (sandbox) चाहिए
  • isolated Unix workspace, controlled network egress, और model के बाहर रखे गए credentials security, confidentiality और scale पर speed सुनिश्चित करते हैं

• 6. Observability & Governance (ऑब्ज़र्वेबिलिटी और गवर्नेंस)

  • "जिसे देखा नहीं जा सकता, उस पर भरोसा नहीं किया जा सकता" — हर step का trace, हर tool call की logging, regression test के रूप में evals चलाना, और highest-risk decisions में human-in-the-loop डेमो को production system में बदल देता है
  • Guardrails policy enforcement करते हैं, और Evals customers से पहले regressions पकड़ लेते हैं

• 7. Cost & Workflow Optimization (लागत और workflow optimization)

  • सातवाँ component है architectural judgment
  • कहाँ deterministic बनाम non-deterministic processing करनी है, हर step के लिए सही model (state-of-the-art·mid-sized·small·fine-tuned) चुनना, और knowledge को skill में रखना है या memory में — यह सब इसी का हिस्सा है

नया प्रतिस्पर्धी परिदृश्य

• इसका परिणाम software में एक नई competitive dynamic के रूप में सामने आता है, जो हर category पर समान रूप से लागू नहीं होती
• major labs (प्रमुख AI research labs) जिन markets को प्राथमिकता देते हैं, वहाँ तेज़ execution और model पर direct control से लाभ मिलता है
• लेकिन इसके अलावा हजारों अलग-अलग niche markets startups के लिए खुले हुए हैं
• ऐसे दौर में जब हर कंपनी एक ही model का उपयोग कर सकती है, "सबसे बेहतर सवार (best riders)" जीतेंगे — यानी harness design और operations capability ही मुख्य प्रतिस्पर्धी ताकत होगी

[junghan0611]

pi बहुत हल्का है, इसलिए मैं इसे एजेंट टूल के तौर पर अक्सर इस्तेमाल करता हूँ। इसके अलावा Claude Code और Gemini को भी कनेक्ट करने के लिए मैंने pi-shell-acp बनाया है और उसे अच्छी तरह इस्तेमाल कर रहा हूँ। मैं कई skills बनाकर इस्तेमाल करता हूँ, और जितना ज़्यादा आज़माया, उतना लगा कि अपनी ज़रूरत के हिसाब से कस्टमाइज़ करना बेहतर है। Claude Code, Codex वगैरह को सीधे इस्तेमाल करते समय मैं YOLO mode में built-in tools लगभग pi स्तर तक सब बंद कर देता हूँ। नई फ़ीचर आते ही उन्हें तुरंत off कर देता हूँ, जैसे खिलौना हथौड़े से ठोककर जड़ देना।

[runai]

मैंने अपनी तरफ़ से की गई सभी Harness सेटिंग्स हटा दी हैं।
मॉडल जितना आगे विकसित होता है, Harness उतना ही उसके प्रदर्शन को सीमित करने वाले कारक की तरह काम करता है।
अधपकी Harness सेटिंग्स उल्टा और भी ख़राब परिणाम पैदा करती हैं।
जो Harness सेटिंग्स पहले से 4.7 या उससे नीचे मौजूद थीं, उनका 4.8 में अब कोई मतलब नहीं रह गया है,
और GPT 5.5 में भी वे बस रुकावट ही बनती हैं.

[hanje3765]

मुख्य पाठ में उल्लेख किए गए harness के घटक ऐसे नहीं हैं जिन्हें सिर्फ़ LLM intelligence बढ़ जाने से हल किया जा सके।

अगर आप उस दौर के harness की बात कर रहे हैं जब उसकी परिभाषा अस्पष्ट थी, तो ऐसा हो सकता है, लेकिन अगर बात मुख्य पाठ में बताए गए harness की है, तो यह आगे भी लगातार प्रबंधन की ज़रूरत वाला क्षेत्र लगता है।

[runai]

यह इंटेलिजेंस की समस्या से ज़्यादा यह है कि मॉडल इंटेलिजेंस से अलग orchestration, tools वगैरह के उपयोग की क्षमता भी साथ-साथ बढ़ा रहे हैं। अभी तक orchestration का क्षेत्र Harness के मुख्य हिस्सों में से एक था, लेकिन अब वह भी सपोर्ट हो चुका है। तो फिर, इस समय अगर homemade orchestration और official orchestration दोनों मौजूद हों, तो किसका इस्तेमाल करना सही होगा?

[kaydash]

सहमत हूँ। हमें मिलकर responsive development करना चाहिए।

[emptybynature]

OpenAI की वेबसाइट पर आधिकारिक रूप से प्रकाशित harnessing पर एक पोस्ट है। इसमें OpenAI के भीतर harnessing का कैसे इस्तेमाल किया गया, उससे जुड़े अनुभव और टिप्स साझा किए गए हैं। मतलब, OpenAI भी अपने आंतरिक प्रोजेक्ट्स में harnessing का उपयोग करता है। harnessing स्पष्ट रूप से ज़रूरी है और अंतिम implementation की quality पर इसका सीधा असर पड़ता है। सबसे बढ़कर, उसी quality का परिणाम हासिल करने में लगने वाले tokens को यह आधा तक कम कर सकता है। performance और cost दोनों को संभाला जा सकता है, तो इसे न इस्तेमाल करने की कोई वजह नहीं है।

[runai]

Opus 4.8 में ultracode effort जोड़ा गया है, और यह पहले developers के हस्तनिर्मित harness mode जो काम करता था उसे उससे बेहतर तरीके से हल करता है। इसलिए मुझे लगता है कि इस समय आप जो harness mode इस्तेमाल कर रहे हैं, उसमें orchestration वाला हिस्सा हटा देना बेहतर होगा।

[gulbi135]

सहमत हूँ। मैंने भी 4.7 के लिए हाथ से बनाई गई orchestration या लंबी-चौड़ी planning forcing को 4.8 में रुकावट मानकर हटा दिया था.
लेकिन कई लाख लाइनों वाले, वर्षों से maintain किए जा रहे codebase में harness की असली value orchestration में नहीं, बल्कि उस layer में है जिसे ultracode replace नहीं कर सकता (knowledge graph, domain convention, validation invariant). इसलिए उस context layer को बनाए रखते हुए, सिर्फ़ वास्तव में independent हिस्सों को workflow के ज़रिए parallelize किया.
उल्टा, अगर नया project हो तो मुझे लगता है कि बिना harness के ultracode ही सही है. आखिरकार यह "हटाएँ बनाम रखें" का मामला नहीं, बल्कि codebase की उम्र और coupling पर निर्भर करने वाला सवाल लगता है.

[runai]

हाँ। यह सही बात है। orchestration वाले हिस्से को हटाने के बाद भी उसमें अब भी मूल्य है।