<thinking>यह एक तकनीकी लेख है जो स्वायत्त सॉफ्टवेयर विकास के लिए एक संरचित दृष्टिकोण का वर्णन करता है। मुझे इसे हिंदी में अनुवाद करना है, जिसमें मार्कडाउन फ़ॉर्मेटिंग, ब्रांड नाम, और तकनीकी शब्दों को संरक्षित रखना है।</thinking>
स्वायत्त सॉफ़्टवेयर विकास के बारे में ज़्यादातर चर्चाएँ एजेंटों द्वारा कोड लिखने से शुरू होती हैं। एक एजेंट किसी इश्यू को उठाता है, एक फ़ीचर लागू करता है, और एक पुल रिक्वेस्ट खोलता है। डेमो काम करता है। लोग उत्साहित हो जाते हैं।
इससे पहले कि कोई भी स्वायत्त डिलीवरी विश्वसनीय रूप से काम कर सके, किसी को उस इंजीनियरिंग सिस्टम को डिज़ाइन करना होगा जिसमें स्वायत्तता संचालित होगी। प्रोजेक्ट संरचना, तकनीकी चुनाव, आर्किटेक्चरल सीमाएँ, डिज़ाइन दिशा, इंजीनियरिंग परंपराएँ, सत्यापन तंत्र, विशेषज्ञ भूमिकाएँ, अनुमोदन सीमाएँ। इनमें से कुछ भी समानांतर में अनुमान लगाने वाले स्वतंत्र एजेंटों के संग्रह से उभरना नहीं चाहिए।
मेरा दृष्टिकोण ज़िम्मेदारियों के एक अलग विभाजन से शुरू होता है। मनुष्य इंजीनियरिंग सिस्टम डिज़ाइन करते हैं। विशेषज्ञ एजेंट काम को अंजाम देते हैं। एसिंक्रोनस लूप्स यह तय करते हैं कि वह काम कब होगा और आगे क्या होगा।
उद्देश्य मनुष्यों को सॉफ़्टवेयर विकास से हटाना नहीं है। यह मानवीय भागीदारी को उन निर्णयों पर केंद्रित करना है जिनमें निर्णय, संदर्भ और उत्पाद समझ की आवश्यकता होती है, जबकि एक ऐसा वातावरण बनाना है जहाँ अधिकांश निष्पादन अपने आप जारी रह सके।
ये छह चरण हैं जिनका मैं हर बार पालन करता हूँ जब मैं एक ऐसा प्रोजेक्ट शुरू करता हूँ जो अंततः मेरे देखे बिना चलने वाला होता है।
चरण 1: मानव इंजीनियरिंग सिस्टम डिज़ाइन करता है
जब मैं एक प्रोजेक्ट शुरू करता हूँ, तो मैं किसी स्वायत्त एजेंट से इसकी नींव का आविष्कार करने के लिए नहीं कहता।
मैं पहले महत्वपूर्ण भागों का निर्णय लेता हूँ: रिपॉजिटरी को कैसे व्यवस्थित किया जाना चाहिए, किन तकनीकों का उपयोग करना है, मुख्य आर्किटेक्चरल सीमाएँ कैसे काम करती हैं, डिज़ाइन दिशा क्या है, किन इंजीनियरिंग परंपराओं का पालन किया जाना चाहिए, और स्वायत्तता कहाँ रुकनी चाहिए। ये निर्णय बाद में आने वाली हर चीज़ की नींव बन जाते हैं।
फिर मैं उन्हें रिपॉजिटरी में एनकोड करने के लिए opencode-onboard का उपयोग करता हूँ।
/make-engineer प्रोजेक्ट के लिए आवश्यक विशेषज्ञ AI इंजीनियर बनाता है। फ्रंटएंड, बैकएंड, इंफ्रास्ट्रक्चर, टेस्टिंग, सिक्योरिटी, डेटा, मोबाइल, जो कुछ भी उत्पाद माँगता है। ये अलग-अलग लेबल वाले सामान्य एजेंट नहीं हैं। प्रत्येक की एक परिभाषित विशेषज्ञता, क्षमताओं का एक सेट और इंजीनियरिंग वर्कफ़्लो में एक स्पष्ट स्थान होता है।
/make-architecture ARCHITECTURE.md में तकनीकी संरचना और सीमाओं को कैप्चर करता है। /make-design DESIGN.md में विज़ुअल भाषा, डिज़ाइन टोकन और कंपोनेंट पैटर्न को कैप्चर करता है। /make-guardrails उन सभी निर्णयों को ठोस नियमों में बदल देता है जिनका प्रत्येक एजेंट को पालन करना होता है। आर्किटेक्चरल सीमाएँ, नामकरण परंपराएँ, टेस्टिंग अपेक्षाएँ, कोड शैली, सुरक्षा बाधाएँ, Git प्रथाएँ। वे केवल मूल डेवलपर के पास मौजूद ज्ञान नहीं रह जाते, बल्कि ऑपरेटिंग वातावरण का हिस्सा बन जाते हैं।
रिपॉजिटरी में अंततः केवल दस्तावेज़ीकरण से अधिक होता है। इसमें एक एनकोडेड इंजीनियरिंग संगठन और उसके अंदर काम करने वाले प्रत्येक एजेंट के लिए सत्य का एक साझा स्रोत होता है।
मानव पहले सिस्टम को परिभाषित करता है। तभी स्वायत्त निष्पादन उपयोगी होता है।
चरण 2: इंटरैक्टिव फाउंडेशन स्वायत्तता से पहले आता है
एक बार जब इंजीनियरिंग सिस्टम परिभाषित हो जाता है, तो मैं प्रारंभिक प्रोजेक्ट फाउंडेशन को इंटरैक्टिव रूप से बनाता हूँ।
मैं इस बिंदु पर सामान्यतः /plan-quick और /plan-apply का उपयोग करता हूँ। /plan-quick एक केंद्रित उद्देश्य का विश्लेषण करता है और इसे कार्यों के एक ठोस, क्रमबद्ध अनुक्रम में बदल देता है। यह जानबूझकर पूर्ण स्पेसिफिकेशन वर्कफ़्लो की तुलना में हल्का है। मैं इसका उपयोग तब करता हूँ जब काम स्पष्ट हो और मैं दृश्यता या नियंत्रण खोए बिना तेज़ी से आगे बढ़ना चाहता हूँ। /plan-apply उन कार्यों को लागू करता है और परिणाम को सत्यापित करता है।
इस प्रकार मैं प्रोजेक्ट का मूल इंफ्रास्ट्रक्चर स्थापित करता हूँ। रिपॉजिटरी संरचना, एप्लिकेशन स्केलेटन, डेटाबेस सेटअप, ऑथेंटिकेशन फाउंडेशन, डिज़ाइन सिस्टम, टेस्टिंग इंफ्रास्ट्रक्चर, CI/CD कॉन्फ़िगरेशन, डिप्लॉयमेंट फाउंडेशन।
प्रोजेक्ट के शुरुआती चरणों में ऐसे निर्णय होते हैं जो बाद में बनाई गई हर चीज़ को प्रभावित करते हैं। एक कमज़ोर एब्स्ट्रक्शन, एक असंगत फ़ोल्डर संरचना, एक अस्पष्ट टेस्टिंग रणनीति। इनमें से कोई भी एक बार स्वायत्त एजेंट काम करना शुरू करने के बाद सैकड़ों बार पुनरुत्पादित हो सकता है। मैंने ऐसा होते देखा है। यह सुंदर नहीं है।
इस कारण से, यह चरण तेज़ और AI-सहायता प्राप्त रहता है, लेकिन पर्यवेक्षित रहता है।
उद्देश्य जितनी जल्दी हो सके स्वायत्तता को अधिकतम करना नहीं है। उद्देश्य प्रोजेक्ट को इतना स्थिर, समझने योग्य और पूर्वानुमानित बनाना है कि स्वायत्तता बाद में उसके अंदर सुरक्षित रूप से काम कर सके।
चरण 3: मानवीय भागीदारी एक प्रोजेक्ट नीति बन जाती है
नींव तैयार होने के बाद, मैं तय करता हूँ कि डिलीवरी सिस्टम को कितनी स्वायत्तता होनी चाहिए।
यह मैनुअल डेवलपमेंट और पूर्ण ऑटोमेशन के बीच एक द्विआधारी विकल्प नहीं है। जीवनचक्र में विभिन्न बिंदुओं पर मानवीय भागीदारी मौजूद हो सकती है, और सही कॉन्फ़िगरेशन प्रोजेक्ट पर निर्भर करता है।
एक पूरी तरह से पर्यवेक्षित प्रोजेक्ट में मानव को इश्यू को परिष्कृत करने, कार्यान्वयन योजना को अनुमोदित करने, पुल रिक्वेस्ट की समीक्षा करने, मर्ज को अनुमोदित करने और डिप्लॉयमेंट को अधिकृत करने की आवश्यकता हो सकती है।
एक आंशिक रूप से स्वायत्त प्रोजेक्ट AI को परिष्कृत और कार्यान्वित करने दे सकता है, जबकि मनुष्य अनुत्तरित प्रश्नों को हल करते हैं, महत्वपूर्ण पुल रिक्वेस्ट की समीक्षा करते हैं, या अंतिम मर्ज पर नियंत्रण बनाए रखते हैं।
एक अत्यधिक स्वायत्त प्रोजेक्ट सिस्टम को स्वचालित रूप से परिष्कृत, कार्यान्वित, समीक्षा और मर्ज करने दे सकता है जब आवश्यक गार्डरेल, परीक्षण और गुणवत्ता जाँचें पास हो जाती हैं।
अस्थिर आवश्यकताओं वाले एक नए उत्पाद को एक परिपक्व आंतरिक उपकरण की तुलना में अधिक मानवीय भागीदारी की आवश्यकता होती है। एक विनियमित सिस्टम को स्पष्ट अनुमोदन द्वारों की आवश्यकता होती है जो एक छोटे प्रयोग के लिए अनावश्यक होंगे। और वही प्रोजेक्ट समय के साथ अधिक स्वायत्त हो सकता है क्योंकि इसकी वास्तुकला, परीक्षण और डिलीवरी तंत्र परिपक्व होते हैं।
महत्वपूर्ण बात यह है कि स्वायत्तता को जानबूझकर परिभाषित किया जाता है। इश्यू रिफाइनमेंट, प्रश्न समाधान, योजना अनुमोदन, पुल रिक्वेस्ट समीक्षा, मर्ज अनुमोदन, डिप्लॉयमेंट अनुमोदन। ये आकस्मिक रुकावटें नहीं हैं। ये इंजीनियरिंग सिस्टम में कॉन्फ़िगरेबल गेट हैं।
प्रत्येक प्रोजेक्ट स्वायत्तता का एक अलग स्तर चुनता है, और वे सीमाएँ इसके साथ विकसित होती हैं।
चरण 4: विचार टिकाऊ बैकलॉग आइटम बन जाते हैं
इंटरैक्टिव कंसोल अभी भी वह स्थान है जहाँ मैं विचारों की जाँच करता हूँ।
जब कोई विचार अधूरा होता है, तो मैं /plan-explore का उपयोग करता हूँ। यह एक कार्यान्वयन कमांड नहीं है। यह एक सहयोगी अन्वेषण प्रक्रिया है। एजेंट रिपॉजिटरी की जाँच करता है, प्रासंगिक घटकों का मानचित्रण करता है, मौजूदा पैटर्न की पहचान करता है, धारणाओं को चुनौती देता है, निर्भरताओं का पता लगाता है, जोखिमों पर विचार करता है, और यह निर्धारित करने में मदद करता है कि वास्तव में क्या बनाया जाना चाहिए।
कई विकास समस्याएँ शुरू में कोडिंग कार्यों की तरह दिखती हैं लेकिन वास्तव में समझ की समस्याएँ होती हैं। एक अस्पष्ट विचार को सीधे एक स्वायत्त कार्यान्वयन वर्कफ़्लो में भेजने से आमतौर पर एक अस्पष्ट कार्यान्वयन होता है। अन्वेषण विचार को किसी समाधान के लिए समय से पहले प्रतिबद्ध हुए बिना कार्रवाई योग्य बनने के लिए पर्याप्त संरचना देता है।
एक बार दिशा स्पष्ट हो जाने पर, मैं GitHub, Azure DevOps, या Jira में एक संरचित कार्य आइटम बनाने के लिए /ops-backlog का उपयोग करता हूँ। कार्य आइटम इंटरैक्टिव सोच और एसिंक्रोनस निष्पादन के बीच टिकाऊ हैंडऑफ़ बन जाता है। इसमें वर्कफ़्लो के अगले चरणों के लिए आवश्यक संदर्भ, दायरा, स्वीकृति मानदंड, जोखिम, अनुत्तरित प्रश्न और निर्भरताएँ हो सकती हैं।
इस बिंदु पर बैकलॉग अब केवल एक स्थान नहीं है जहाँ कार्य संग्रहीत किए जाते हैं। यह मनुष्यों, एजेंटों और लूप्स के बीच साझा समन्वय परत बन जाता है।
मनुष्य विचार बनाते हैं, प्रश्नों का उत्तर देते हैं और निर्णय लेते हैं। लूप्स इश्यू स्थितियों का निरीक्षण करते हैं और पात्र कार्य का चयन करते हैं। एजेंट उन्हें निष्पादित करने के लिए आवश्यक संदर्भ के साथ केंद्रित कार्य प्राप्त करते हैं।
बैकलॉग एक इंटरैक्टिव वार्तालाप को टिकाऊ काम में बदल देता है जो उस वार्तालाप के समाप्त होने के बाद भी जारी रहता है।
चरण 5: loop-task एसिंक्रोनस कार्य का समन्वय करता है
एक बार प्रोजेक्ट, इंजीनियर, गार्डरेल, बैकलॉग और अनुमोदन नीति तैयार हो जाने के बाद, मैं एक स्थानीय मशीन या VM के अंदर loop-task को कॉन्फ़िगर करता हूँ।
loop-task बाहरी ऑर्केस्ट्रेशन लूप्स चलाता है। ये लूप्स लगातार बैकलॉग का निरीक्षण करते हैं, पात्र कार्य की पहचान करते हैं, उपयुक्त इंजीनियरिंग वर्कफ़्लो को लागू करते हैं, और प्रत्येक इश्यू की स्थिति को अपडेट करते हैं।
एक रिफाइनमेंट लूप एक नए इश्यू का चयन कर सकता है, उसकी जाँच कर सकता है, उसके स्पेसिफिकेशन में सुधार कर सकता है, और जानकारी गायब होने पर प्रश्न जोड़ सकता है। जब मानवीय निर्णय की आवश्यकता होती है, तो इश्यू प्रतीक्षा स्थिति में चला जाता है। एक व्यक्ति उपलब्ध होने पर उत्तर देता है, और जानकारी दिखाई देने पर लूप फिर से शुरू हो जाता है।
एक बार इश्यू पर्याप्त रूप से स्पष्ट हो जाने पर, यह कार्यान्वयन के लिए तैयार स्थिति में चला जाता है। कार्यान्वयन लूप इसे उठाता है और स्वायत्त इंजीनियरिंग वर्कफ़्लो को लागू करता है।
एक समीक्षा लूप पुल रिक्वेस्ट फीडबैक का निरीक्षण कर सकता है, सुधारों का समन्वय कर सकता है, आवश्यक वर्कफ़्लो को फिर से चला सकता है, और परिवर्तन को वापस स्वीकृति की ओर ले जा सकता है। एक पूर्णता लूप स्वीकृत कार्य को मर्ज कर सकता है, संबंधित इश्यू को बंद कर सकता है, और अगले पात्र आइटम को सिस्टम में प्रवेश करने की अनुमति दे सकता है।
लूप्स को एक-दूसरे के साथ सीधे संवाद करने की आवश्यकता नहीं है। वे टिकाऊ बैकलॉग स्थितियों के माध्यम से समन्वय करते हैं। एक सामान्य इश्यू इस तरह के जीवनचक्र से गुज़रता है:
नया, परिष्कृत किया जा रहा है, उत्तरों की प्रतीक्षा है, कार्यान्वयन के लिए तैयार है, कार्यान्वित किया जा रहा है, पुल रिक्वेस्ट, समीक्षा की जा रही है, हो गया।
मनुष्य प्रक्रिया में तब प्रवेश कर सकते हैं जब प्रोजेक्ट नीति को उनकी आवश्यकता होती है, लेकिन सिस्टम किसी के लगातार टर्मिनल देखने पर निर्भर नहीं करता है। भले ही डेवलपर ऑफ़लाइन हो, VM बैकलॉग की जाँच करता रहता है और पात्र कार्य को आगे बढ़ाता रहता है।
यह लूप इंजीनियरिंग के केंद्र में अंतर है:
एजेंट काम को अंजाम देते हैं। लूप्स तय करते हैं कि काम कब मौजूद है, उसे कब शुरू करना चाहिए, कौन सा वर्कफ़्लो उसे निष्पादित करना चाहिए, और आगे क्या होता है।
चरण 6: /plan-goal एक इश्यू को शुरू से अंत तक निष्पादित करता है
जब कार्यान्वयन लूप को एक इश्यू मिलता है जो तैयार है, तो वह /plan-goal को लागू करता है।
यह कमांड उत्पाद दिशा तय करने या प्रोजेक्ट आर्किटेक्चर का आविष्कार करने के लिए ज़िम्मेदार नहीं है। वे निर्णय पहले ही किए जा चुके हैं और रिपॉजिटरी में एनकोड किए जा चुके हैं। इसकी ज़िम्मेदारी मौजूदा इंजीनियरिंग सिस्टम के भीतर एक पर्याप्त रूप से परिष्कृत कार्य आइटम को निष्पादित करना है।
/plan-goal इश्यू को पढ़ता है, कोडबेस के प्रासंगिक भागों का पता लगाता है, एक OpenSpec प्रस्ताव बनाता है, संरचित कार्य उत्पन्न करता है, स्पेसिफिकेशन या टेस्टिंग अंतराल की पहचान करता है, उपयुक्त विशेषज्ञ इंजीनियरों का चयन करता है, मॉडल टियर निर्दिष्ट करता है, निर्भरताओं की गणना करता है, और कार्यान्वयन कार्य को समानांतर निष्पादन तरंगों में व्यवस्थित करता है।
जो कार्य स्वतंत्र हैं और रिपॉजिटरी के अलग-अलग क्षेत्रों को संशोधित करते हैं, उन्हें एक साथ विभिन्न इंजीनियरों को सौंपा जा सकता है। जो कार्य पिछले काम पर निर्भर करते हैं या समान फ़ाइलों को छूते हैं, उन्हें आवश्यक क्रम में निष्पादित किया जाता है।
लीड एजेंट काम का समन्वय करता है, प्रत्येक परिणाम एकत्र करता है, केंद्रित कमिट बनाता है, परीक्षण, लिंटिंग, टाइप चेक और बिल्ड चलाता है। यह परिवर्तन को शिप करने के बजाय रोक देता है जब सत्यापन सफलतापूर्वक पूरा नहीं किया जा सकता है।
जब कार्यान्वयन मान्य होता है, तो ब्रांच को पुश किया जाता है और आवश्यक संदर्भ और साक्ष्य के साथ एक पुल रिक्वेस्ट बनाई जाती है।
कॉन्फ़िगर की गई प्रोजेक्ट नीति तब तय करती है कि आगे क्या होता है। एक मानव पुल रिक्वेस्ट की समीक्षा कर सकता है। एक अन्य AI सिस्टम समीक्षा कर सकता है। एक अत्यधिक स्वायत्त प्रोजेक्ट स्वचालित रूप से मर्ज कर सकता है जब हर आवश्यक जाँच पास हो जाती है। अन्य प्रोजेक्ट्स में, अंतिम निर्णय स्पष्ट रूप से मानवीय रहता है।
यह सिस्टम में दो ऑर्केस्ट्रेशन परतों को प्रकट करता है। loop-task बाहरी ऑर्केस्ट्रेशन परत है। यह बैकलॉग जीवनचक्र का प्रबंधन करता है और तय करता है कि रिफाइनमेंट, कार्यान्वयन, समीक्षा या पूर्णता कब होनी चाहिए। /plan-goal और अन्य opencode-onboard कमांड आंतरिक इंजीनियरिंग वर्कफ़्लो बनाते हैं। वे समझते हैं कि एक विशिष्ट परिवर्तन का पता कैसे लगाया जाए, योजना कैसे बनाई जाए, असाइन कैसे किया जाए, कार्यान्वित कैसे किया जाए, सत्यापित कैसे किया जाए और डिलीवर कैसे किया जाए।
एक सिस्टम जो वार्तालाप से बचता है
प्रॉम्प्ट-आधारित विकास की एक सीमा यह है कि बहुत अधिक स्थिति एक अस्थायी वार्तालाप के अंदर रहती है।
आर्किटेक्चर को फिर से समझाना पड़ता है। पिछले निर्णय भूल जाते हैं। एक बाधित कार्यान्वयन को फिर से शुरू करना मुश्किल है। एक डेवलपर को प्रत्येक चरण के बाद यह तय करने के लिए मौजूद रहना चाहिए कि एजेंट को क्या करना चाहिए।
यह वर्कफ़्लो उस स्थिति को टिकाऊ सिस्टम में स्थानांतरित करता है। रिपॉजिटरी में आर्किटेक्चर, डिज़ाइन नियम, इंजीनियर और गार्डरेल होते हैं। OpenSpec में नियोजित परिवर्तन और उसके कार्य होते हैं। Git में कार्यान्वयन इतिहास और रिकवरी पॉइंट होते हैं। बैकलॉग में डिलीवरी स्थिति और मानवीय निर्णय होते हैं। स्थानीय मशीन या VM स्थायी वातावरण प्रदान करता है जहाँ लूप्स चलते रहते हैं।
परिणाम एक एकल स्वायत्त एजेंट नहीं है जो एक संपूर्ण सॉफ़्टवेयर संगठन की तरह व्यवहार करने का प्रयास करता है। यह एक समन्वित सिस्टम है जिसमें विभिन्न घटकों की अलग-अलग ज़िम्मेदारियाँ होती हैं।
मनुष्य दिशा, बाधाओं और ज़िम्मेदारी की सीमाओं को परिभाषित करते हैं। विशेषज्ञ एजेंट केंद्रित इंजीनियरिंग कार्य निष्पादित करते हैं। लूप्स एसिंक्रोनस रूप से जीवनचक्र का समन्वय करते हैं। बैकलॉग उन्हें जोड़ता है।
सबसे महत्वपूर्ण परिवर्तन यह नहीं है कि एजेंट अधिक कोड उत्पन्न कर सकते हैं। बड़ा बदलाव पृथक AI इंटरैक्शन से स्थायी इंजीनियरिंग सिस्टम की ओर है।
प्रत्येक कार्य से पहले रिपॉजिटरी को समझाने के बजाय, प्रोजेक्ट अपनी स्वयं की वास्तुकला और गार्डरेल रखता है। एक सामान्य एजेंट से सब कुछ लागू करने के लिए कहने के बजाय, काम विशेषज्ञों को सौंपा जाता है। प्रत्येक चरण के बाद मैन्युअल रूप से यह तय करने के बजाय कि आगे क्या होना चाहिए, लूप्स टिकाऊ वर्कफ़्लो स्थितियों पर प्रतिक्रिया करते हैं। पूरी प्रक्रिया को एक वार्तालाप के अंदर रखने के बजाय, प्रगति इश्यू, स्पेसिफिकेशन, कमिट, पुल रिक्वेस्ट और स्थानीय स्थिति में बनी रहती है।
मानवीय भूमिका गायब नहीं होती है। यह उस वातावरण को डिज़ाइन करने की ओर बढ़ती है जिसमें स्वायत्त निष्पादन को संचालित करने की अनुमति है।
यह वह मॉडल है जिसे मैं वर्तमान में बना रहा हूँ: एक मानव-डिज़ाइन किया गया AI SDLC जहाँ डेवलपर पहले इंजीनियरिंग वातावरण और स्वायत्तता सीमाएँ स्थापित करता है, फिर एसिंक्रोनस लूप्स बैकलॉग-संचालित डिलीवरी जीवनचक्र के माध्यम से विशेषज्ञ एजेंटों का समन्वय करते हैं।
शून्य से अपने आप चलने वाले लूप्स तक। छह चरण, प्रत्येक पिछले एक पर निर्मित, प्रत्येक थोड़ी और स्थिति को वार्तालाप से बाहर और उन सिस्टम में ले जाता है जो भूलते नहीं हैं।
PS: आप loop-task, opencode-onboard और बाकी टूल्स ckgrafico.com पर पा सकते हैं।
