अप्रत्याशित प्रतिभा को कैसे घेरें

• एक ही अनुरोध पर अलग-अलग परिणाम देने वाले AI उत्पादों में बार-बार होने वाली त्रुटियों को कम करने के लिए निर्देश बढ़ाने के बजाय उन्हें ऐसे deterministic code से नियंत्रित करना चाहिए जिसे मॉडल तोड़ न सके
• नियंत्रण संरचना चार परतों में बंटी होती है: मॉडल, harness, दस्तावेज़, और hook; इनमें केवल hook ही खास परिस्थितियों में स्वतंत्र रूप से काम करते हुए नियम लागू कर सकता है
• जिन कार्यों की शुद्धता को code से परखा जा सकता है, उनमें गारंटी दी जा सकती है; लेकिन सूक्ष्म विश्लेषणात्मक त्रुटियों जैसे निर्णय-आधारित काम फिर से मॉडल पर निर्भर हो जाते हैं, इसलिए मॉडल बेहतर होने पर भी verification gap खत्म नहीं होता
• AI उत्पादों को ऐसे harness engineering की ज़रूरत होती है जो यह अलग करे कि क्या मॉडल के निर्णय पर छोड़ा जाए और क्या code से सुनिश्चित किया जाए; नियंत्रण कम हो तो गलत जवाब मिलते हैं और बहुत ज़्यादा हो तो वह महंगा सामान्य software बन जाता है
• अगर हर कोई वही मॉडल किराए पर ले सकता है, तो किसी उत्पाद के लिए जमा किए गए मानक, code, data, और integration environment से बना wrapping layer (wrapper) ही बचाव योग्य प्रतिस्पर्धी बढ़त बनता है, और Cursor की बढ़त इसका उदाहरण है

---

दस्तावेज़ के नियमों को code में बदलना

• Claude Code जिस फ़ाइल को हर session में पढ़ता है, उसमें किसी खास व्यवहार को मना करने पर भी वह कभी-कभी सामग्री को समझकर और उससे सहमत होकर वही व्यवहार दोहरा देता है
• जब नियमों को ऐसे code में बदला गया जो शर्त पूरी होते ही command को रोक दे, तो मॉडल के निर्णय से अलग निषिद्ध व्यवहार रुक गया
• The Verification Tax में जिस AI output review cost की बात है, उसे बाद की समीक्षा बढ़ाने के बजाय upstream engineering से कम किया जा सकता है
• केवल एक व्यक्ति और व्यक्तिगत tools से बनी न्यूनतम नियंत्रण संरचना भी उसी तरह की समस्या रखती है जिसे बड़े AI उत्पादों को सुलझाना पड़ता है
• विफलता के प्रकारों को hook के प्रकारों से जोड़ने और हर परत की मापी जा सकने वाली सीमा को व्यवस्थित करने वाली व्यावहारिक गाइड अलग X पोस्ट में देखी जा सकती है

नियंत्रण की चार परतें

• नियंत्रण क्षमता नीचे से ऊपर की ओर मज़बूत होती जाने वाली चार परतों से बनी है
  • मॉडल: Claude Opus 4.8 या GPT-5.5 जैसे अच्छे मॉडल भी एक ही अनुरोध पर अलग जवाब दे सकते हैं, और कोई भी निर्देश इस गुण को पूरी तरह समाप्त नहीं कर सकता
  • harness: Claude Code, Codex, OpenClaw जैसे सिस्टम मॉडल को चलाते हैं और तय करते हैं कि मॉडल क्या देखेगा, लेकिन वे केवल बड़ी दिशा ही दे सकते हैं
  • दस्तावेज़: CLAUDE.md और AGENTS.md में पसंद, project context, नियम, और जमा हुए सुधार रखे जाते हैं, लेकिन मॉडल इन्हें दूसरी जानकारी के साथ मिलाकर निर्णय लेता है, इसलिए वह इन्हें न भी माने
  • hook: खास स्थितियों की निगरानी करने वाला और स्वतंत्र रूप से चलने वाला code, जो मॉडल की सहमति से अलग निषिद्ध command को रोक देता है
• इन चार परतों में केवल सबसे ऊपर की hook परत ही बिना मोलभाव के काम करती है
  • hook में बदले गए नियमों को मॉडल bypass नहीं कर सकता, इसलिए बार-बार होने वाली त्रुटियाँ गायब हो जाती हैं और इंसानों की समीक्षा का दायरा भी कम होता है

वह निर्णय क्षेत्र जिसे code से गारंटी नहीं दी जा सकती

• नियंत्रण की सतह को कम किया जा सकता है, लेकिन पूरी तरह बंद नहीं किया जा सकता
  • “इस command को execute मत करो” जैसी शर्त को code से जाँचा जा सकता है
  • “विश्लेषण सूक्ष्म रूप से गलत दिशा में न बह जाए” जैसी शर्त के लिए निर्णय चाहिए, और इसे जाँचने वाला दूसरा मॉडल भी फिर से अप्रत्याशित होता है
• जो सिस्टम वास्तव में output को साबित कर सकते हैं, वे इंसान द्वारा पहले से लिखे गए मानकों और परिणामों की code से तुलना करते हैं, और वे केवल उन क्षेत्रों में काम करते हैं जहाँ सही उत्तर को ठीक-ठीक परिभाषित किया जा सकता है
• मॉडल upgrade होने पर भी निर्णय की समस्या खत्म नहीं होती, इसलिए मॉडल को घेरने वाली नियंत्रण परतें आगे भी ज़रूरी रहेंगी

• औपचारिक specification पर आधारित गारंटी

  • SEVerA यह गारंटी दे सकता है कि agent output औपचारिक contract को पूरा करता है, लेकिन contract को पहले से formal logic में लिखना पड़ता है, और यह केवल उन्हीं क्षेत्रों में लागू होता है जहाँ ऐसी जाँच संभव है
  • VeriGuard LLM agent में verified safety जोड़ता है, लेकिन उपयोगकर्ता की manual verification फिर भी ज़रूरी रहती है
  • उपयोगकर्ता के इरादे को औपचारिक नियमों में अनुवाद करने का चरण खुद अप्रत्याशित है
  • व्यावहारिक गारंटी आखिरकार इंसान द्वारा लिखी गई specification पर आधारित fixed checks पर निर्भर करती है
  • “self-improving agent” बने हुए परिणामों का मूल्यांकन करके बाद के व्यवहार को बेहतर बनाते हैं, लेकिन यह किसी एक खास output को सही साबित करने वाली विधि से अलग है

probabilistic engine को deterministic software से घेरना

• पारंपरिक software testing उस तरीके से विकसित हुई जिसमें इच्छित output और एक सही उत्तर तय करके पूर्वानुमेय code की जाँच की जाती है
• AI-native उत्पादों के केंद्र में ऐसा probabilistic engine होता है जो एक ही prompt पर अलग परिणाम देता है, इसलिए पुराने testing model की बुनियादी धारणा टूट जाती है
• Hamel Husain के अनुसार, दशकों से बनी software testing discipline एक सही उत्तर मानकर चलती है, लेकिन AI में वही सही उत्तर गायब हो जाता है
• कई डेवलपर इस दिशा में पहुँच रहे हैं कि अप्रत्याशित engine को बनाए रखा जाए, लेकिन उसे ऐसे deterministic code से घेरा जाए जो हर बार एक जैसा काम करे
  • Dex Horthy का 12-factor agents अच्छे agent को “ज़्यादातर software से बना” system बताता है
  • Anthropic का building effective agents सलाह देता है कि काम को “predefined code path” से चलाया जाए और “programmatic checks” जोड़े जाएँ
• Claude Code में शर्त जाँचने का तरीका चुना जा सकता है
  • अगर code स्वतंत्र रूप से pass या fail तय करे, तो गारंटी मिलती है
  • अगर मॉडल तय करे कि शर्त पूरी हुई या नहीं, तो केवल उसका निर्णय मिलता है

• Claude Code के Skills और /goal

  • Skills structured procedures हैं जिन्हें agent बुला सकता है, लेकिन उन्हें execute करना है या नहीं यह मॉडल तय करता है और वह बीच में भटक भी सकता है, इसलिए यह दस्तावेज़ परत में आता है
  • /goal काम को तब तक जारी रखता है जब तक घोषित शर्तें पूरी न हों, इसलिए यह enforcement layer के काफ़ी करीब है
  • लेकिन हर turn के बाद एक छोटा और तेज़ मॉडल यह तय करता है कि शर्त पूरी हुई या नहीं, इसलिए वह भी दूसरे मॉडलों की तरह गलत निर्णय दे सकता है
  • /goal Stop hook को लपेटने वाली सुविधा है, जबकि सीधे लिखे गए Stop hook में script मॉडल की जगह स्वतंत्र रूप से pass या fail तय कर सकती है
  • Claude Code दस्तावेज़ deterministic checks के लिए script और निर्णय-आधारित checks के लिए मॉडल के उपयोग के बीच साफ़ अंतर करता है

जब व्यक्तिगत सेटिंग संगठन के पैमाने तक फैलती है

• व्यक्तिगत environment में agent अगर एक नियम अनदेखा भी कर दे, तो उसका असर कुछ मिनट बर्बाद होने तक सीमित रहता है, और महत्वपूर्ण मामलों को व्यक्तिगत hook से रोका जा सकता है
• वही agent इस्तेमाल करने वाली 200 लोगों की कंपनी में हर सदस्य के पास व्यक्तिगत hook नहीं होता, और नियम एक साझा फ़ाइल में रखे जा सकते हैं
• अगर साझा नियम एक बार अनदेखा हो जाए, तो वही समस्या उन सभी जगहों पर दिख सकती है जहाँ वह फ़ाइल चलती है, और संगठन की सुरक्षा का स्तर सबसे ढीले लिखे नियम पर निर्भर हो जाता है
• नियंत्रण संरचना व्यक्तिगत setup जैसी ही रहती है, लेकिन पैमाना बढ़ने पर त्रुटि की लागत बदल जाती है

क्या गारंटी दें और क्या खुला छोड़ें

• Every की agent-native architecture guide functionality को लिखे गए code के रूप में नहीं, बल्कि “loop के भीतर काम करने वाले agent द्वारा हासिल किए गए, वर्णित परिणाम” के रूप में परिभाषित करती है
• यह तरीका मॉडल को तात्कालिक ढंग से काम करने देता है और उत्पाद को परिणाम-केंद्रित बनाता है, लेकिन जहाँ नियंत्रण चाहिए वहाँ फिर code पर लौटता है
  • बार-बार या महत्वपूर्ण रास्तों यानी hot path को code में बदलने की सलाह दी जाती है
  • यह भी माना जाता है कि कुछ कामों में ऐसी verification चाहिए जिसे agent के निर्णय पर नहीं छोड़ा जा सकता
• मॉडल-केंद्रित product design और control-केंद्रित engineering एक-दूसरे के उलट दिखते हैं, लेकिन दोनों एक ही architecture को अलग सिरों से देखते हैं
• वास्तविक design में यह तय करना पड़ता है कि उत्पाद के किस हिस्से को कितनी हद तक code से स्थिर किया जाए
  • अगर बहुत कम स्थिर किया जाए, तो जहाँ गारंटी चाहिए वहाँ भी मॉडल तात्कालिक निर्णय लेकर ग्राहक को आत्मविश्वास से भरा गलत जवाब दे सकता है
  • अगर बहुत ज़्यादा स्थिर किया जाए, तो वह सभी रास्तों के लिए code लिखे गए सामान्य software में बदल जाएगा, और मॉडल केवल पुराने code का काम धीमे और महंगे ढंग से करेगा
• OpenAI टीम जिस harness engineering की बात करती है, वह उत्पाद के हर बिंदु पर मॉडल-आधारित निर्णय और code-आधारित गारंटी के बीच इरादतन अनुपात तय करने का काम है

मॉडल से ज़्यादा लंबे समय तक जमा होने वाली wrapping layer

• मॉडल ऐसा स्तर है जिसे हर कोई किराए पर ले सकता है, और model lab के schedule के अनुसार वह एक साथ सभी उपयोगकर्ताओं के लिए बेहतर होता है, इसलिए इसकी रक्षा करना सबसे कठिन है
• कोई प्रतिस्पर्धी भले पूरे code repository को पढ़ ले, फिर भी वह यह जमा हुआ निर्णय हासिल नहीं कर लेता कि किसी खास workflow में क्या गारंटी देनी है और क्या खुला छोड़ना है
• ऐसे निर्णय उन परतों में लागू होते हैं जिन्हें मॉडल तोड़ नहीं सकता, और वे उत्पाद-विशिष्ट नियंत्रण संरचना के साथ लगातार जमा होते रहते हैं
• मॉडल के आसपास का code, मानक, data, और workflow integration environment मिलकर दीर्घकालिक competitive advantage बनाते हैं

Cursor ने जो नियंत्रण परत जमा की

• AI coding tool Cursor ने अपना सामान्य-उद्देश्य मॉडल नहीं बनाया; वह Claude, GPT, Gemini, और Grok के बीच अनुरोध route करता है और मॉडलों को किराए पर मिलने वाली commodity की तरह लेता है
• Anthropic का Claude Code बेहतर मॉडल तक पहले पहुँच जाए, तब भी वह Cursor की जगह नहीं ले सकता
• Cursor की revenue पिछले साल नवंबर के लगभग 1 billion dollars से बढ़कर जून में लगभग 4 billion dollars हो गई
• SpaceX ने अप्रैल में सुरक्षित किए गए option को पिछले हफ्ते exercise करके Cursor को 60 billion dollars में खरीदने पर सहमति की, और यह venture-backed startup acquisitions में अब तक का सबसे बड़ा सौदा है
• Cursor ने जो जमा किया है, वह बेहतर general-purpose model नहीं बल्कि उत्पाद को घेरे रहने वाली परत है
  • पूरे repository को sync करके searchable रखने वाला codebase index
  • रोज़ाना होने वाले सैकड़ों मिलियन edits से यह सीखने वाला अपना autocomplete model कि डेवलपर कौन से सुझाव स्वीकार या अस्वीकार करते हैं
  • Fortune 500 कंपनियों के अधिकांश हिस्से में जमी हुई enterprise integration environment
• मॉडल कंपनियों के पास बेहतर मॉडल हो सकते हैं, लेकिन वे editor, index, और डेवलपर की usage habits के मालिक नहीं होते

AI-native उत्पादों की टिकाऊपन तय करने वाला सवाल

• Cursor की तरह नियंत्रण परत बनाने के उदाहरण दुर्लभ हैं, और AI को काम में लगाने वाले अधिकतर लोगों ने ऐसी wrapping layer या तो बनाई नहीं है या उसके अस्तित्व को पहचाना नहीं है
• कंपनी के पैमाने पर यह परत कैसे बनाई जाती है, यही उस AI-native उत्पाद को अलग करती है जो वास्तविक उपयोग झेल सकता है, बनिस्बत उस प्रभावशाली demo के जो किसी किराए के मॉडल पर खड़ा है
• अगर foundation model मुफ़्त भी हो जाएँ, तो आखिर क्या बचता है—यही सवाल किसी उत्पाद की sustainable asset को तय करता है