Skip to content
← सभी अध्याय

अध्याय 01

मेनिफ़ेस्टो

एक Deep Work Plan (DWP) AI कोडिंग एजेंट्स द्वारा संरचित, स्वायत्त निष्पादन के लिए एक केवल-markdown पद्धति है। यह एक अस्पष्ट लक्ष्य को एक समीक्षा योग्य योजना — एक विनिर्देश — में बदल देती है, जिसे एक एजेंट कॉन्टेक्स्ट खोए या असंगत परिणामों की ओर सुधार किए बिना निष्पादित, रोक, फिर से शुरू और रिपोर्ट कर सकता है।

एजेंट्स के लिए गहन काम

यह नाम उस व्यवहार का वर्णन करता है जो यह उत्पन्न करता है: संज्ञानात्मक रूप से माँग वाले काम पर केंद्रित, निरंतर प्रयास, जो इच्छाशक्ति के बजाय संरचना से बँधा होता है। जो गुण गहन काम को लोगों के लिए मूल्यवान बनाता है — बिना विचलन के एकाग्रता, लंबे समय तक टिकाई गई — वही एक AI कोडिंग एजेंट को घंटों या दिनों तक चलने वाला काम पूरा करने के लिए चाहिए। एक Deep Work Plan वह संरचना प्रदान करती है, और ऐसा करते हुए रिपॉज़िटरी को एक AI-first, एजेंट-संचालन योग्य कोडबेस में बदल देती है।

बिना योजना के एक एजेंट उस ज्ञान-कर्मी की तरह व्यवहार करता है जो कभी समय नहीं रोकता, कभी कुछ नहीं लिखता, और हर व्यवधान पर कॉन्टेक्स्ट बदल देता है। एक Deep Work Plan एजेंट को एक रोके गए कैलेंडर और एक लिखित ब्रीफ़ के समकक्ष देती है: एक सीमित दायरा, एक स्पष्ट क्रम, और प्रगति दर्ज करने का एक टिकाऊ स्थान।

दिशा ही गुणक है

एक AI कोडिंग एजेंट की क्षमता मॉडल पर उतनी निर्भर नहीं करती जितनी उसे दी गई दिशा की गुणवत्ता पर। एक सक्षम मॉडल यदि किसी अस्पष्ट अनुरोध की ओर इंगित हो तो अस्पष्टता को बढ़ाता है; वही मॉडल यदि किसी सटीक विनिर्देश की ओर इंगित हो तो सटीकता को बढ़ाता है। जैसे-जैसे मॉडल बेहतर होते हैं, यह अंतर घटने के बजाय बढ़ता है — अड़चन ऊपर की ओर खिसक जाती है, कोड लिखने से काम को परिभाषित करने तक। प्रासंगिक कौशल अब निष्पादन नहीं रहा; वह दिशा है।

यह इस बात को नए सिरे से परिभाषित करता है कि अच्छे ढंग से प्रत्यायोजन का क्या अर्थ है। अच्छा प्रत्यायोजन किसी एजेंट से काम माँगना नहीं है — यह काम को इतना स्पष्ट रूप से परिभाषित करना है कि उसे सही ढंग से निष्पादित किया जा सके: लक्ष्य, बाधाएँ, वह कॉन्टेक्स्ट जो अन्यथा एजेंट के पास नहीं होता, और वे मानदंड जो तय करते हैं कि वह सफल हुआ या नहीं। अधिकांश मूल्य निष्पादन शुरू होने से पहले ही सृजित हो जाता है।

Deep Work Plan उस ऊपरी काम को एक टिकाऊ, दोहराने योग्य रूप में करने का अनुशासन है। इसके दो स्तंभ अच्छी दिशा के दो हिस्से हैं: एक विनिर्देश बताता है कि “सही” कैसा दिखता है, और एक हार्नेस एजेंट को वहाँ तक पहुँचने का कॉन्टेक्स्ट और उपकरण देता है। मिलकर वे एक मॉडल की कच्ची क्षमता को भरोसेमंद इंजीनियरिंग में बदल देते हैं — घंटों चलने वाले एक कार्य में निरंतर, और सत्रों के बीच बदलते एजेंट्स के पार संरक्षित।

स्वभाव से स्पेक-ड्रिवन

यह पद्धति का पहला स्तंभ है, और “हार्नेस” की तरह इसे भी स्पष्ट रूप से परिभाषित करना उचित है।

स्पेक-ड्रिवन डेवलपमेंट क्या है। सामान्य प्रॉम्प्ट-संचालित काम में, सत्य का स्रोत एक बातचीत होती है: आप एक एजेंट से कुछ माँगते हैं, वह फ़ाइलें संपादित करता है, और मंशा का एकमात्र रिकॉर्ड एक चैट प्रतिलेख होता है जो दूर खिसक जाता है और कभी दोबारा समीक्षित नहीं होता। स्पेक-ड्रिवन डेवलपमेंट (SDD) इसे उलट देता है। आप पहले लिखते हैं कि क्या सच होना चाहिए — लक्ष्य, दायरा, स्वीकृति मानदंड, वे जाँचें जो सिद्ध करती हैं कि यह पूरा हो गया — और वह लिखित विनिर्देश, न कि बातचीत, सत्य का स्रोत होता है। फिर एजेंट एक-पंक्ति प्रॉम्प्ट से सुधार करने के बजाय स्पेक के विरुद्ध निष्पादन करता है।

DWP इसे कैसे मूर्त रूप देता है। Deep Work Plan में योजना ही विनिर्देश है। एक लक्ष्य एक समीक्षा योग्य योजना बन जाता है; योजना एटॉमिक कार्यों में विघटित होती है; हर कार्य स्पष्ट स्वीकृति मानदंड और सत्यापन-गेट साथ रखता है; और एक पूर्णता प्रोटोकॉल उनके विरुद्ध काम की पुष्टि करता है। योजना → कार्य → गेट → पूर्णता, SDD को ठोस और निष्पादन योग्य बनाया गया रूप है।

यह क्यों मायने रखता है। पहले स्पेक लिखना तीन तरह से प्रतिफल देता है: यह भटकाव घटाता है, क्योंकि एजेंट को अनुरोध की धुँधलाती स्मृति के बजाय बताए गए मानदंडों के विरुद्ध मापा जाता है; यह काम को सत्यापन योग्य बनाता है, क्योंकि हर गेट या तो पास होता है या फ़ेल; और यह काम को फिर से शुरू होने योग्य बनाता है, क्योंकि विनिर्देश किसी भी एकल सत्र या एजेंट से अधिक टिकता है — कोई दूसरा एजेंट कल इसे उठा सकता है और ठीक-ठीक जान सकता है कि “पूरा हुआ” का क्या अर्थ है।

DWP किस तरह भिन्न है। इस विचार के इर्द-गिर्द एक व्यापक स्पेक-ड्रिवन आंदोलन बना है, जिसमें GitHub Spec Kit, Amazon Kiro और Tessl शामिल हैं। वे दृष्टिकोण किसी विशेष उपकरण या प्लेटफ़ॉर्म से बँधे होते हैं। DWP जानबूझकर भिन्न है: यह उपकरण-निरपेक्ष और रिपॉज़िटरी-नेटिव है। विनिर्देश रिपॉज़िटरी में सादे markdown के रूप में रहता है, इसलिए यह किसी विक्रेता के उत्पाद के बजाय कोड के साथ-साथ चलता है — और यह सीधे दूसरे स्तंभ के साथ जुड़ता है, क्योंकि स्पेक स्वयं उस हार्नेस का हिस्सा है जिसे रिपॉज़िटरी साथ रखती है।

रिपॉज़िटरी हार्नेस बन जाती है

यह पद्धति का दूसरा स्तंभ है, और यह एक स्पष्ट परिभाषा का हकदार है — “हार्नेस” एक भारी-भरकम शब्द बन गया है, और अधिकांश उद्योग इसका अर्थ बताए बिना इसका उपयोग करता है।

एक एजेंट हार्नेस क्या है। एक बड़ा भाषा मॉडल, अपने आप में, बस एक टेक्स्ट भविष्यवक्ता है। जो इसे एक भरोसेमंद इंजीनियर में बदलता है वह इसके इर्द-गिर्द लिपटा हर चीज़ है: इसे दिया गया कॉन्टेक्स्ट, वे उपकरण जिन्हें यह बुला सकता है, वह कंट्रोल लूप जो तय करता है कि आगे क्या करना है, वे सुरक्षा-कवच जो गलतियाँ पकड़ते हैं, और वह स्थायी स्थिति जो इसे रुकने और फिर से शुरू होने देती है। वह घेरने वाला ढाँचा ही हार्नेस है। मॉडल इंजन है; हार्नेस वह चेसिस, स्टीयरिंग और ब्रेक हैं जो इंजन को चलाने में सुरक्षित बनाते हैं।

हार्नेस इंजीनियरिंग क्या है। अधिकांश टीमें उस ढाँचे को परोक्ष रूप से बनाती हैं, किसी एकल उपकरण के भीतर — एक विशेष IDE, एक एजेंट उत्पाद, या एक विशेष-निर्मित फ़्रेमवर्क — इसलिए यह केवल वहीं काम करता है और उपकरण बदलते ही गायब हो जाता है। हार्नेस इंजीनियरिंग उस ढाँचे को जानबूझकर, एक प्रथम-श्रेणी आर्टिफ़ैक्ट के रूप में डिज़ाइन करने का अनुशासन है। Deep Work Plan इस बात पर एक दृढ़ रुख अपनाता है कि इसे कहाँ रहना चाहिए: किसी उपकरण में नहीं, बल्कि रिपॉज़िटरी में ही।

रिपॉज़िटरी सही स्थान क्यों है। जब हार्नेस रिपॉज़िटरी में रहता है, तो यह कोड के साथ-साथ चलता है, रिपॉज़िटरी खोलने वाला हर एजेंट इसे विरासत में पाता है, और यह किसी भी अन्य कोड की तरह संस्करण-नियंत्रित, समीक्षित और बेहतर किया जाता है। DWP हार्नेस के हर हिस्से को एक ठोस, टिकाऊ आर्टिफ़ैक्ट के रूप में स्थापित करता है:

हार्नेस तत्व यह क्या प्रदान करता है DWP इसे आपकी रिपॉज़िटरी में कहाँ रखता है
कॉन्टेक्स्ट एजेंट को क्या जानना चाहिए AGENTS.md, docs/, और प्रति-मॉड्यूल READMEs
उपकरण एजेंट क्या कर सकता है .agents/ स्किल्स, एजेंट्स, और dwp-* कमांड्स
कंट्रोल लूप काम कैसे आगे बढ़ता है Deep Work Plan: योजना → एटॉमिक कार्य → गेट → पूर्णता
सुरक्षा-कवच इसे सही क्या रखता है स्पष्ट स्वीकृति मानदंड और सत्यापन-गेट
स्थिति यह व्यवधान से कैसे बचती है gitignored .dwp/ योजनाएँ, ड्राफ़्ट और प्रगति लॉग

क्योंकि हर तत्व किसी उपकरण की सुविधा के बजाय रिपॉज़िटरी की एक फ़ाइल है, हार्नेस निर्माण से ही पोर्टेबल है। यही वह एक-पंक्ति दावा है जिस पर शेष पद्धति टिकी है: रिपॉज़िटरी स्वयं हार्नेस बन जाती है, ताकि कोई भी एजेंट किसी भी रिपॉज़िटरी को संचालित कर सके — बिना किसी विशेष प्रति-उपकरण फ़्रेमवर्क के।

संरचित स्वायत्त निष्पादन क्यों मायने रखता है

आधुनिक AI कोडिंग एजेंट सक्षम हैं पर बिना दिशा के। किसी एक को एक गैर-तुच्छ कार्य की ओर इंगित करें और वह तुरंत फ़ाइलें संपादित करना शुरू कर देता है, यह भूल जाता है कि उसने क्या बदला, और ऐसा काम तैयार करता है जिसकी समीक्षा कठिन और जिसे फिर से शुरू करना असंभव है।

DWP एक हल्की संरचना लागू करता है जो हर विफलता को सीधे संबोधित करती है:

  • समीक्षा योग्य कार्य — काम क्रमिक इकाइयों में विघटित होता है, हर एक स्पष्ट दायरे और स्वीकृति मानदंडों के साथ।
  • स्थायी स्थिति — प्रगति लिख दी जाती है ताकि काम व्यवधान से बचे और सत्रों तथा एजेंट्स के पार फिर से शुरू हो सके।
  • मानकीकृत दस्तावेज़ीकरण — मनुष्य और एजेंट एक समान प्रारूप के माध्यम से एक साझा मानसिक मॉडल रखते हैं।
  • एजेंट पोर्टेबिलिटी — यह पद्धति पतले अडैप्टर के माध्यम से किसी भी एजेंट के साथ काम करती है, पुनः-कार्यान्वयन के माध्यम से नहीं।

ऊपर से नीचे तक Markdown

DWP संरचना परिभाषित करता है, सॉफ़्टवेयर नहीं। कोई रनटाइम स्थापित नहीं करना, कोई निर्भरता-वृक्ष नहीं, और कोई लॉक-इन नहीं। योजना, कार्य और चालू लॉग सभी सादे markdown हैं जिन्हें कोई भी एजेंट पढ़ सकता है, कोई भी व्यक्ति समीक्षित कर सकता है, और कोई भी संस्करण-नियंत्रण प्रणाली स्वच्छता से ट्रैक कर सकती है। परिणाम ऐसा निष्पादन है जिसे आप पढ़, ऑडिट और भरोसा कर सकते हैं।