संगठनात्मक डिज़ाइन और परिवर्तन प्रबंधन: स्वायत्त कोडर को सुरक्षित रूप से लागू करना

संगठनात्मक डिज़ाइन और परिवर्तन प्रबंधन: स्वायत्त कोडर को सुरक्षित रूप से लागू करना

परिचय

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

यह क्षमता केवल डेवलपर वर्कस्टेशन से कहीं अधिक बदलती है। यह बदलती है कि कौन सॉफ्टवेयर का काम करता है, काम कैसे सौंपा जाता है, कोड की समीक्षा कैसे की जाती है, प्रबंधक क्या मापते हैं, और जवाबदेही कहाँ निहित होती है।

सबसे सुरक्षित संगठन यह पूछकर शुरू नहीं करते, “हम एजेंट को कितनी जल्दी प्रोडक्शन कोड लिखने दे सकते हैं?” वे पूछते हैं:

• कौन सा काम सौंपना सुरक्षित है?
• एजेंट को क्या सबूत देना चाहिए?
• परिणाम के लिए कौन जवाबदेह है?
• एजेंट को कौन सी अनुमतियाँ चाहिए?
• संगठन अपनी कार्रवाइयों को कैसे रोक या उलट सकता है?
• डेवलपर्स को धमकी महसूस किए बिना नई कार्यप्रणाली कैसे सीखेंगे?

अब तक के प्रमाण एक सतर्क, संदर्भ-निर्भर दृष्टिकोण का समर्थन करते हैं। मॉडल इवैल्यूएशन एंड थ्रेट रिसर्च संगठन द्वारा 2025 के एक यादृच्छिक अध्ययन में पाया गया कि 16 अनुभवी ओपन-सोर्स डेवलपर्स ने परिचित रिपॉजिटरी पर शुरुआती-2025 के कृत्रिम बुद्धिमत्ता कोडिंग उपकरणों का उपयोग करते समय कम समय के बजाय 19 प्रतिशत अधिक समय लिया। अन्य क्षेत्र प्रयोगों ने विभिन्न वातावरणों में उत्पादकता लाभ की सूचना दी है। सबक यह नहीं है कि कोडिंग एजेंट अप्रभावी हैं। यह है कि उपकरण की क्षमता, कार्य का प्रकार, डेवलपर का अनुभव, कोडबेस की गुणवत्ता और संगठनात्मक कार्यप्रणाली सभी मायने रखते हैं। (metr.org)

2025 की DevOps रिसर्च एंड असेसमेंट रिपोर्ट एक समान संगठनात्मक निष्कर्ष पर पहुँचती है: कृत्रिम बुद्धिमत्ता एक एम्पलीफायर के रूप में कार्य करती है। यह स्पष्ट वर्कफ़्लो, विश्वसनीय प्लेटफ़ॉर्म, अच्छे परीक्षण और मजबूत फीडबैक लूप वाले संगठनों को मजबूत करती है। यह कमजोर प्रक्रियाओं, खराब दस्तावेज़ीकरण, अस्थिर प्राथमिकताओं और अस्पष्ट स्वामित्व को भी बढ़ाती है। (dora.dev)

यह लेख पायलट स्क्वाड, सेंटर ऑफ एक्सीलेंस और फेडरेटेड गवर्नेंस के माध्यम से कोडिंग एजेंटों को सुरक्षित रूप से अपनाने के लिए एक व्यावहारिक ऑपरेटिंग मॉडल प्रस्तुत करता है।

स्वायत्त कोडिंग एजेंट वास्तव में क्या बदलते हैं

पारंपरिक कोडिंग सहायक एक डेवलपर के कोड लिखते समय सुझाव प्रदान करते हैं। अधिक स्वायत्त एजेंट क्रियाओं का एक क्रम प्रदर्शन कर सकते हैं:

1. एक मुद्दा या कार्य विवरण पढ़ें।
2. संबंधित फाइलों और दस्तावेज़ों का निरीक्षण करें।
3. एक कार्यान्वयन योजना बनाएँ।
4. कई फाइलों को संशोधित करें।
5. परीक्षण, लिंटर्स और सुरक्षा जाँच चलाएँ।
6. परिवर्तनों की व्याख्या करें।
7. एक पुल रिक्वेस्ट खोलें या अपडेट करें।
8. समीक्षा टिप्पणियों का जवाब दें।
9. जब तक कार्य परिभाषित शर्तों को पूरा नहीं करता, तब तक चक्र दोहराएँ।

उदाहरण के लिए, GitHub Copilot क्लाउड एजेंट एक रिपॉजिटरी की खोज कर सकता है, कोड परिवर्तन कर सकता है, और समीक्षा के लिए एक पुल रिक्वेस्ट बना सकता है। इसके ऑटोमेशन शेड्यूल पर या मुद्दों और पुल रिक्वेस्ट के जवाब में चल सकते हैं। GitHub उपकरणों को सीमित करने, एजेंट सत्रों की समीक्षा करने, ऑटोमेशन को अक्षम करने और विलय से पहले मानव समीक्षा की आवश्यकता के लिए नियंत्रणों का भी दस्तावेजीकरण करता है। (docs.github.com)

यह चार संगठनात्मक बदलाव पैदा करता है:

• कोड लिखने से लेकर कोड को निर्देशित करने और उसका मूल्यांकन करने तक।
• व्यक्तिगत कार्यों से लेकर कार्य कतारों तक जिन्हें एजेंट लगातार संसाधित कर सकते हैं।
• आवधिक रखरखाव से लेकर निरंतर रखरखाव तक।
• अंतर्निहित डेवलपर निर्णय से लेकर स्पष्ट नीतियों, परीक्षणों, निर्देशों और अनुमोदन नियमों तक।

कोडिंग एजेंट उन संगठनों के लिए सबसे उपयोगी हैं जिनके पास पहले से ही है:

• संस्करण नियंत्रण में स्रोत कोड।
• एक कार्यशील पुल रिक्वेस्ट प्रक्रिया।
• स्वचालित परीक्षण।
• सेवाओं और फाइलों का स्पष्ट स्वामित्व।
• प्रतिलिपि प्रस्तुत करने योग्य विकास वातावरण।
• उत्साह पर निर्भर रहने के बजाय परिणामों को मापने की इच्छा।

वे उन संगठनों के लिए पहले कदम के रूप में कम उपयुक्त हैं जिनके पास कोई विश्वसनीय परीक्षण नहीं है, अदस्तावेजीकृत सिस्टम हैं, अस्पष्ट स्वामित्व है, या एक ऐसी संस्कृति है जो हर नए उपकरण को एक जनादेश मानती है।

मुख्य डिज़ाइन सिद्धांत: केवल मॉडल को ही नहीं, कार्यप्रणाली को भी नियंत्रित करें

एक कोडिंग एजेंट एक बड़े सिस्टम का केवल एक हिस्सा है। सुरक्षित अपनाने के लिए चारों ओर नियंत्रण की आवश्यकता होती है:

• पहचान: किस व्यक्ति या सेवा खाते ने कार्य शुरू किया?
• अधिकार: एजेंट क्या पढ़, बदल या निष्पादित कर सकता है?
• साक्ष्य: परिवर्तन के साथ कौन से परीक्षण, स्कैन और स्पष्टीकरण होने चाहिए?
• समीक्षा: इसे कौन अनुमोदित करेगा?
• परिनियोजन: परिवर्तन उपयोगकर्ताओं तक कितनी धीरे-धीरे पहुँच सकता है?
• अवलोकनशीलता: क्या प्रशासक यह पुनर्गठित कर सकते हैं कि क्या हुआ?
• पुनर्प्राप्ति: क्या परिवर्तन, एजेंट या सुविधा को जल्दी से रोका जा सकता है?

नेशनल इंस्टीट्यूट ऑफ स्टैंडर्ड्स एंड टेक्नोलॉजी कृत्रिम बुद्धिमत्ता जीवनचक्र के दौरान विश्वसनीयता पर विचार करने की सलाह देता है, जिसमें डिज़ाइन, विकास, परिनियोजन, उपयोग, परीक्षण और मूल्यांकन शामिल हैं। कोडिंग एजेंटों के लिए, इसका मतलब है कि जोखिम प्रबंधन को पहली घटना के बाद तक टाला नहीं जा सकता है। (nist.gov)

एक उपयोगी आंतरिक नियम है:

एक एजेंट एक परिवर्तन का प्रस्ताव, तैयारी, परीक्षण और व्याख्या कर सकता है। एक मानव संगठन यह तय करने के लिए जवाबदेह रहता है कि उत्पादन में क्या प्रवेश करता है।

वह नियम उच्च परिपक्वता पर अधिक लचीला हो सकता है, लेकिन तभी जब संगठन के पास मजबूत सबूत, सीमित अनुमतियाँ, विश्वसनीय रोलबैक और स्पष्ट स्टॉप की शर्तें हों।

तीन संगठनात्मक पैटर्न जो काम करते हैं

1. पायलट स्क्वाड

एक पायलट स्क्वाड एक छोटी टीम होती है जो एक परिभाषित अवधि के लिए वास्तविक काम पर कोडिंग एजेंटों का उपयोग करती है। यह कृत्रिम कार्यों का उपयोग करके एक प्रदर्शन परियोजना नहीं है। स्क्वाड को एक वास्तविक रिपॉजिटरी, वास्तविक मुद्दों और वास्तविक वितरण बाधाओं पर काम करना चाहिए।

एक मजबूत पायलट स्क्वाड में शामिल हैं:

• विभिन्न स्तरों के अनुभव वाले चार से आठ डेवलपर्स।
• एक इंजीनियरिंग मैनेजर।
• एक उत्पाद या व्यवसाय प्रतिनिधि।
• एक सुरक्षा या गुणवत्ता प्रतिनिधि।
• परिनियोजन और संचालन से परिचित कोई व्यक्ति।
• कम से कम एक व्यक्ति जो प्रौद्योगिकी के बारे में संशयी या सतर्क है।

GitHub सलाह देता है कि पायलटों में वास्तविक काम, कौशल स्तरों का मिश्रण, और टीमों और वर्कफ़्लो की एक श्रृंखला शामिल होनी चाहिए। यह सफलता मानदंड को परिभाषित करने, एक बजट निर्धारित करने और सार्थक डेटा इकट्ठा करने के लिए पर्याप्त लंबे समय तक पायलट चलाने की भी सलाह देता है। उपयोग-आधारित एजेंट सुविधाओं के लिए, GitHub कम से कम एक पूर्ण बिलिंग चक्र, आमतौर पर चार से छह सप्ताह की योजना बनाने का सुझाव देता है। (docs.github.com)

सर्वोत्तम उपयोग के मामले

पायलट स्क्वाड विशेष रूप से इन के लिए अच्छी तरह से काम करते हैं:

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

पायलट को क्या नहीं करना चाहिए

इन के साथ शुरू करने से बचें:

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

पायलट निकास मानदंड

पायलट शुरू होने से पहले, एक लिखित “गो,” “पॉज़,” और “नो-गो” निर्णय परिभाषित करें:

अगर तो आगे बढ़ें:

• गुणवत्ता स्थिर रहती है या सुधरती है।
• सुरक्षा निष्कर्ष भौतिक रूप से नहीं बढ़ते हैं।
• समीक्षक परिवर्तनों को समझ सकते हैं।
• डेवलपर्स रिपोर्ट करते हैं कि कार्यप्रणाली उपयोगी है।
• एजेंट लागत स्वीकृत सीमा के भीतर रहती है।
• टीम एजेंट गतिविधि को रोक या उलट सकती है।

अगर तो रोकें:

• पुल रिक्वेस्ट समीक्षा का समय तेजी से बढ़ता है।
• एजेंट बार-बार एक ही वर्ग की त्रुटि करता है।
• बॉट-जनित कार्य रखरखाव करने वालों को अभिभूत करता है।
• डेवलपर्स बिना प्रशिक्षण के उपकरण का उपयोग करने के लिए दबाव महसूस करते हैं।
• संगठन यह नहीं बता सकता कि एजेंट ने क्या बदला।

अगर तो आगे न बढ़ें:

• एजेंट आवश्यक अनुमोदनों को दरकिनार करता है।
• संवेदनशील डेटा उजागर होता है।
• महत्वपूर्ण कमजोरियाँ पेश की जाती हैं।
• एजेंट को मज़बूती से नियंत्रित नहीं किया जा सकता है।
• व्यवसाय का मामला केवल आशावादी विचारों पर निर्भर करता है न कि मापा परिणामों पर।

2. सेंटर-ऑफ-एक्सीलेंस मॉडल

एक सेंटर ऑफ एक्सीलेंस साझा मानक, प्रशिक्षण, उपकरण, मूल्यांकन और समर्थन प्रदान करता है। इसे एक केंद्रीय टीम नहीं बनना चाहिए जो हर प्रयोग को अनुमोदित करती है या हर एजेंट वर्कफ़्लो लिखती है।

Microsoft का वर्तमान एजेंट अपनाने का मार्गदर्शन एक प्रभावी सेंटर ऑफ एक्सीलेंस को एक छोटे, क्रॉस-फंक्शनल समूह के रूप में वर्णित करता है जो सक्षमता, मानक, शासन और पैमाने प्रदान करता है। यह प्रारंभिक परिपक्वता पर एक हाथों-हाथ केंद्रीय टीम से एक हल्के पारिस्थितिकी तंत्र और सामुदायिक भूमिका की ओर प्रगति की सिफारिश करता है क्योंकि स्थानीय टीमें सक्षम हो जाती हैं। (learn.microsoft.com)

एक कोडिंग-एजेंट सेंटर ऑफ एक्सीलेंस में शामिल हो सकते हैं:

• एक इंजीनियरिंग उत्पादकता लीड।
• एक सुरक्षा इंजीनियर।
• एक प्लेटफ़ॉर्म या डेवलपर-अनुभव इंजीनियर।
• एक सॉफ्टवेयर गुणवत्ता प्रतिनिधि।
• एक परिवर्तन-प्रबंधन या शिक्षण विशेषज्ञ।
• एक उत्पाद या व्यवसाय प्रतिनिधि।
• आवश्यकता पड़ने पर एक कानूनी, गोपनीयता, या अनुपालन सलाहकार।

सेंटर ऑफ एक्सीलेंस की जिम्मेदारियां

सेंटर ऑफ एक्सीलेंस का स्वामित्व होना चाहिए:

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

इसे हर स्थानीय कार्यान्वयन निर्णय का स्वामित्व नहीं लेना चाहिए। इसका उद्देश्य सुरक्षित व्यवहार को आसान, दोहराने योग्य और दृश्यमान बनाना है।

3. फेडरेटेड गवर्नेंस

फेडरेटेड गवर्नेंस एक केंद्रीय आधारभूत रेखा को स्थानीय टीम के स्वामित्व के साथ जोड़ती है।

केंद्रीय संगठन न्यूनतम आवश्यकताएं निर्धारित करता है:

• संरक्षित शाखाओं में कोई सीधा विलय नहीं।
• आवश्यक पुल रिक्वेस्ट।
• आवश्यक परीक्षण और सुरक्षा जाँच।
• संवेदनशील क्षेत्रों के लिए मानव या कोड-स्वामी अनुमोदन।
• न्यूनतम-विशेषाधिकार पहुँच।
• लॉगिंग और विशेषता।
• परिभाषित रोलबैक प्रक्रियाएं।
• अनुमोदित मॉडल, उपकरण और डेटा हैंडलिंग नियम।

स्थानीय टीमें तय करती हैं:

• कौन से कार्य स्वचालित करने लायक हैं।
• रिपॉजिटरी निर्देश कैसे लिखे जाने चाहिए।
• कौन से डोमेन-विशिष्ट परीक्षण आवश्यक हैं।
• कौन से इंजीनियर स्थानीय चैंपियन के रूप में सेवा करते हैं।
• उपकरण टीम की योजना और समीक्षा प्रक्रिया में कैसे फिट बैठता है।

Microsoft प्लेटफ़ॉर्म जिम्मेदारियों और वर्कलोड जिम्मेदारियों के बीच एक समान अलगाव का वर्णन करता है: प्लेटफ़ॉर्म टीम सुरक्षित आधार और शासन प्रदान करती है, जबकि वर्कलोड टीमें डोमेन-विशिष्ट मूल्य और जीवनचक्र निर्णयों का स्वामित्व रखती हैं। (learn.microsoft.com)

यह मॉडल आमतौर पर एक बड़े संगठन के लिए सबसे अच्छी दीर्घकालिक संरचना है क्योंकि यह दो सामान्य विफलताओं से बचाता है:

• केंद्रीयकृत बाधा: हर प्रयोग एक समिति का इंतजार करता है।
• अनियंत्रित फैलाव: हर टीम अपने स्वयं के उपकरण, अनुमतियाँ, समीक्षा नियम और डेटा प्रथाओं का आविष्कार करती है।

अनुशंसित प्रगति

अधिकांश संगठनों के लिए, सबसे मजबूत अनुक्रम है:

1. एक या दो पायलट स्क्वाड से शुरू करें।
2. उन पायलटों में शामिल लोगों से एक छोटा सेंटर ऑफ एक्सीलेंस बनाएँ।
3. जैसे-जैसे अधिक टीमें कार्यप्रणाली को अपनाती हैं, फेडरेटेड गवर्नेंस की ओर बढ़ें।
4. पहचान, सुरक्षा, मूल्यांकन और उत्पादन पहुँच पर केंद्रीय नियंत्रण रखें।
5. डोमेन उपयोग के मामलों और दिन-प्रतिदिन की प्रथाओं पर स्थानीय नियंत्रण रखें।

परिवर्तन प्रबंधन: बिना प्रतिकार पैदा किए विश्वास का निर्माण

विश्वास अनुबंध से शुरू करें

डेवलपर प्रतिकार अक्सर प्रौद्योगिकी के विरोध के बजाय अनिश्चितता से आता है। लोग जानना चाहते हैं कि उपकरण का उपयोग उनकी मदद करने, उन पर नज़र रखने, उन्हें बदलने या उन्हें आंकने के लिए किया जाएगा।

डेवलपर विश्वास पर Google का शोध पांच व्यावहारिक रणनीतियों की सिफारिश करता है:

1. एक स्पष्ट स्वीकार्य-उपयोग नीति प्रकाशित करें।
2. कोड समीक्षा और स्वचालित परीक्षण को मजबूत करें।
3. डेवलपर्स को परिचितता बनाने के अवसर दें।
4. इसे मजबूर किए बिना उपयोग को प्रोत्साहित करें।
5. समझाएं कि दोहराए जाने वाले काम से परे डेवलपर की भूमिकाएँ कैसे विकसित हो सकती हैं। (dora.dev)

एक व्यावहारिक विश्वास अनुबंध में कहा जाना चाहिए:

• उद्देश्य: वितरण गुणवत्ता में सुधार, दोहराए जाने वाले काम को कम करना, या सीखने की क्षमता बढ़ाना।
• क्या अनुमति है: सुरक्षित और उपयोगी कार्यों के उदाहरण।
• क्या निषिद्ध है: संवेदनशील डेटा हैंडलिंग, अप्रतिबंधित उत्पादन पहुँच, और असमीक्षित विलय।
• कौन जवाबदेह है: परिवर्तन के लिए जिम्मेदार व्यक्ति और टीम जवाबदेह रहती है, भले ही एजेंट ने इसे लिखा हो।
• टेलीमेट्री का उपयोग कैसे किया जाता है: अपनाने का डेटा सक्षमता में सुधार करना चाहिए, न कि एक सरल कर्मचारी रैंकिंग प्रणाली बनना चाहिए।
• क्या नहीं होगा: कोई छिपा हुआ रोलआउट नहीं, कोई स्वचालित प्रतिस्थापन वादा नहीं, और एजेंट के उपयोग के लिए कोई व्यक्तिगत कोटा नहीं।
• लोग कैसे असहमत हो सकते हैं: समस्याओं की रिपोर्ट करने या ठहराव का अनुरोध करने के लिए एक दृश्यमान चैनल।

लोगों को जिम्मेदारी के अनुसार प्रशिक्षित करें

प्रशिक्षण एक सामान्य दो घंटे का प्रदर्शन नहीं होना चाहिए। यह भूमिका-आधारित होना चाहिए।

गैर-कोडर और उत्पाद टीमों के लिए

लोगों को सिखाएँ कि कैसे:

• स्पष्ट मुद्दे लिखें।
• सादी भाषा में वांछित व्यवहार का वर्णन करें।
• स्वीकृति मानदंड परिभाषित करें।
• संवेदनशील या उच्च-जोखिम वाली आवश्यकताओं की पहचान करें।
• एक प्रदर्शन या परीक्षण परिणाम की समीक्षा करें।
• कोड की हर पंक्ति को पढ़े बिना एजेंट को एक परिवर्तन समझाने के लिए कहें।

यह उन लोगों के लिए कोडिंग एजेंटों को उपयोगी बनाता है जो व्यावसायिक समस्या को समझते हैं लेकिन सॉफ्टवेयर नहीं लिखते हैं।

डेवलपर्स के लिए

सिखाएँ:

• एजेंट को उपयोगी संदर्भ कैसे दें।
• कार्यान्वयन से पहले एक योजना कैसे माँगें।
• एक भिन्नता का निरीक्षण कैसे करें।
• एजेंट के सारांश पर भरोसा करने के बजाय परीक्षणों को कैसे सत्यापित करें।
• निर्भरताओं, रहस्यों, अनुमतियों और त्रुटि हैंडलिंग की जाँच कैसे करें।
• प्रॉम्प्ट इंजेक्शन और अविश्वसनीय रिपॉजिटरी सामग्री को कैसे पहचानें।
• एक एजेंट को कैसे रोकें जो लूप कर रहा है या असंबंधित परिवर्तन कर रहा है।

Google के शोध में पाया गया कि डेवलपर्स को उपकरण के संपर्क में आने पर विश्वास बढ़ता है, खासकर उन भाषाओं और वातावरणों में जिन्हें वे पहले से समझते हैं। (dora.dev)

समीक्षकों के लिए

समीक्षकों को इन पर ध्यान केंद्रित करना सिखाएँ:

• क्या परिवर्तन बताई गई समस्या को हल करता है।
• क्या परीक्षण महत्वपूर्ण व्यवहार को कवर करते हैं।
• क्या परिवर्तन सुरक्षा या गोपनीयता जोखिमों को पेश करता है।
• क्या डिज़ाइन मौजूदा वास्तुकला में फिट बैठता है।
• क्या एजेंट ने आवश्यकता से अधिक बदला।
• क्या पुल रिक्वेस्ट आत्मविश्वास से समीक्षा करने के लिए पर्याप्त छोटा है।

इंजीनियरिंग प्रबंधकों के लिए

प्रबंधकों को मापना सिखाएँ:

• वितरण गुणवत्ता।
• समीक्षा भार।
• फिर से काम करना।
• लीड टाइम।
• डेवलपर आत्मविश्वास।
• घटना दरें।
• रखरखाव बैकलॉग।
• ग्राहक परिणाम।

कोड की पंक्तियों को प्राथमिक उत्पादकता लक्ष्य के रूप में उपयोग न करें। GitHub कोड-की-लाइनों के मेट्रिक्स को दिशात्मक बताता है और अपनाने, स्वीकृति, पुल रिक्वेस्ट जीवनचक्र उपायों और गुणात्मक प्रतिक्रिया को एक साथ विचार करने की सलाह देता है। (docs.github.com)

सुरक्षा और संचालन टीमों के लिए

सिखाएँ:

• एजेंट पहचान और पहुँच नियंत्रण।
• उपकरण अनुमत सूचियाँ।
• प्रॉम्प्ट इंजेक्शन जोखिम।
• रहस्य प्रबंधन।
• ऑडिट लॉग।
• कैनरी परिनियोजन।
• किल स्विच।
• रोलबैक और घटना प्रतिक्रिया।

बिना अवैतनिक सहायता भूमिकाएँ बनाए चैंपियनों का उपयोग करें

एक चैंपियन एक विश्वसनीय टीम सदस्य होता है जो उपकरण के साथ प्रयोग करता है, व्यावहारिक मार्गदर्शन साझा करता है, सहकर्मियों की मदद करता है, और सेंटर ऑफ एक्सीलेंस को प्रतिक्रिया लाता है।

Microsoft का अपनाने का मार्गदर्शन चैंपियनों को प्रशिक्षण, मान्यता, विशेषज्ञों तक पहुँच और मानकों को आकार देने में आवाज देने की सलाह देता है। चैंपियनों को केवल एक अवैतनिक हेल्प डेस्क नहीं बनना चाहिए। उनके समय और जिम्मेदारियों पर प्रबंधकों के साथ सहमति होनी चाहिए। (learn.microsoft.com)

एक उपयोगी चैंपियन कार्यक्रम में शामिल हैं:

• मासिक सामुदायिक बैठकें।
• एक साझा चर्चा चैनल।
• कार्यालय समय।
• वास्तविक काम का उपयोग करके छोटे प्रदर्शन।
• सफल और असफल उदाहरणों की एक लाइब्रेरी।
• शिक्षण और प्रतिक्रिया के लिए मान्यता।
• सुरक्षा और प्लेटफ़ॉर्म टीमों के लिए एक स्पष्ट वृद्धि पथ।

चरणों में संवाद करें

एक व्यावहारिक संचार अनुक्रम है:

पायलट से पहले

• संबोधित की जा रही समस्या की व्याख्या करें।
• बताएं कि क्या दायरे में है और क्या दायरे से बाहर है।
• विश्वास अनुबंध प्रकाशित करें।
• समझाएं कि सफलता को कैसे मापा जाएगा।
• संशयी प्रश्न आमंत्रित करें।

पायलट के दौरान

• साप्ताहिक प्रगति साझा करें।
• जीत के साथ-साथ विफलताओं को भी प्रकाशित करें।
• समीक्षा भार, गुणवत्ता निष्कर्ष, लागत और डेवलपर भावना की रिपोर्ट करें।
• सबूत के आधार पर कार्यप्रणाली को समायोजित करें।

पायलट के बाद

• निर्णय प्रकाशित करें: विस्तार करें, रोकें या रोकें।
• समझाएं कि प्रक्रिया में क्या बदला।
• पुन: प्रयोज्य प्रथाओं को साझा करें।
• बताएं कि क्या मानव-नियंत्रित रहता है।
• डेवलपर्स को भाग लेने का एक स्पष्ट अगला अवसर दें।

एक उपयोगी संदेश है:

कोडिंग एजेंट परिवर्तन का मसौदा तैयार और परीक्षण कर सकते हैं, लेकिन लोग इरादे, समीक्षा, जोखिम और उत्पादन परिणामों के लिए जिम्मेदार रहते हैं। हम स्वायत्तता का विस्तार तभी करेंगे जब सबूत यह दिखाएंगे कि गुणवत्ता, सुरक्षा और डेवलपर अनुभव स्वस्थ रहते हैं।

कोडिंग एजेंटों के लिए एक व्यावहारिक परिपक्वता मॉडल

परिपक्वता सबूत और नियंत्रण पर आधारित होनी चाहिए, न कि खरीदे गए लाइसेंस की संख्या पर।

चरण 5 को एक अपवाद के रूप में माना जाना चाहिए, न कि अनुमानित गंतव्य। Google का साइट विश्वसनीयता इंजीनियरिंग मार्गदर्शन प्रगतिशील स्वायत्तता का वर्णन करता है: सिस्टम सहायता प्राप्त विश्लेषण से मानव-अनुमोदित कार्रवाई की ओर बढ़ते हैं, फिर मजबूत सबूत और नियंत्रण स्थापित होने के बाद ही सीमित स्वायत्त कार्रवाई की ओर बढ़ते हैं। यह न्यूनतम विशेषाधिकार, अवरुद्धता, ड्राई-रन समर्थन, जोखिम मूल्यांकन और निरंतर मूल्यांकन पर जोर देता है। (goo.gle)

चरणों के बीच पदोन्नति मानदंड

एक टीम को अगले चरण में तभी आगे बढ़ना चाहिए जब वह यह प्रदर्शित कर सके:

• स्थिर या सुधरती दोष दरें।
• सुरक्षा निष्कर्षों में कोई अस्वीकार्य वृद्धि नहीं।
• एक प्रबंधनीय समीक्षा भार।
• स्पष्ट एजेंट विशेषता।
• विश्वसनीय परीक्षण और परिनियोजन संकेत।
• एक अभ्यास किया गया रोलबैक।
• डेवलपर्स जो कार्यप्रणाली को समझते और उस पर भरोसा करते हैं।
• उन कार्यों की एक दस्तावेजीकृत सूची जिन्हें एजेंट को नहीं करना चाहिए।

निरंतर रखरखाव बॉट विशेष सावधानी के योग्य हैं

रखरखाव का काम कम जोखिम वाला प्रतीत होता है, लेकिन यह बड़ी मात्रा में परिवर्तन पैदा कर सकता है। उदाहरणों में शामिल हैं:

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

मौजूदा उपकरण जैसे Dependabot एक उपयोगी पैटर्न प्रदर्शित करते हैं: स्वचालित सिस्टम पुल रिक्वेस्ट बढ़ाते हैं, लेकिन विलय से पहले परीक्षण और स्वीकृति प्रक्रियाएं अभी भी चलनी चाहिए। स्वचालित विलय को स्पष्ट रूप से परिभाषित, कम-जोखिम वाले मामलों तक सीमित होना चाहिए जिसमें आवश्यक स्थिति जाँचें हों। (docs.github.com)

भाषा-मॉडल-आधारित रखरखाव बॉट के लिए, जोड़ें:

• खुले बॉट पुल रिक्वेस्ट की अधिकतम संख्या।
• प्रति कार्य अधिकतम पुनः प्रयास की संख्या।
• एक अधिकतम दैनिक बजट।
• बासी या डुप्लिकेट काम का स्वचालित बंद होना।
• एक आवश्यक मानव स्वामी।
• एक नियम कि बॉट को अपनी स्वयं की अनुमतियों या कार्यप्रणाली परिभाषाओं को संशोधित नहीं करना चाहिए।

स्वायत्त कोडिंग अपनाने के लिए जोखिम रजिस्टर

पायलट से पहले एक जोखिम रजिस्टर बनाया जाना चाहिए और प्रत्येक विस्तार निर्णय के दौरान इसकी समीक्षा की जानी चाहिए।

GitHub का वर्तमान दस्तावेज़ इनमें से कई जोखिमों को सीधे पहचानता है, जिसमें अविश्वसनीय कोड, संवेदनशील जानकारी तक पहुँच, प्रॉम्प्ट इंजेक्शन, प्रशासनिक दृश्यता का नुकसान, और प्रत्येक कार्य को शुरू किए बिना स्वचालन संचालन शामिल है। इसके दस्तावेजीकृत शमन में शाखा प्रतिबंध, आवश्यक मानव समीक्षा, वर्कफ़्लो अनुमोदन, सत्र लॉग और सीमित उपकरण शामिल हैं। (docs.github.com)

ओपन वर्ल्डवाइड एप्लीकेशन सिक्योरिटी प्रोजेक्ट का एजेंटिक सुरक्षा और शासन पर 2026 का मार्गदर्शन भी उन प्रणालियों के लिए विशेष रूप से डिज़ाइन किए गए खतरे मॉडलिंग और शासन की आवश्यकता को दर्शाता है जो केवल पाठ उत्पन्न करने के बजाय कार्य कर सकते हैं। (genai.owasp.org)

रोलबैक प्लेबुक

एक रोलबैक प्लेबुक सादी भाषा में लिखा जाना चाहिए और एक स्वायत्त एजेंट को उत्पादन-बाध्यकारी परिवर्तन बनाने की अनुमति देने से पहले इसका पूर्वाभ्यास किया जाना चाहिए।

प्लेबुक 1: एजेंट को नियंत्रित करें

इसका उपयोग तब करें जब एजेंट अप्रत्याशित रूप से व्यवहार करता है, जानकारी लीक करता है, अत्यधिक काम पैदा करता है, या अपनी कार्य सीमा का उल्लंघन करता है।

1. प्रभावित एजेंट, स्वचालन, या मॉडल नीति को अक्षम करें।
2. निर्धारित और घटना-ट्रिगर किए गए रन को रोकें।
3. एजेंट के क्रेडेंशियल्स को रद्द या निलंबित करें।
4. नए पुल रिक्वेस्ट बनाने से रोकें।
5. सत्र लॉग, प्रॉम्प्ट, अंतर और ऑडिट रिकॉर्ड को संरक्षित करें।
6. एजेंट द्वारा स्पर्श की गई सभी रिपॉजिटरी और शाखाओं की पहचान करें।
7. प्रभावित रखरखाव करने वालों और सुरक्षा कर्मियों को सूचित करें।
8. एक घटना समीक्षा खोलें।
9. जब तक विफलता मोड और नियंत्रण अंतर को समझा नहीं जाता तब तक एजेंट को फिर से सक्षम न करें।

GitHub स्वचालन को अक्षम करने और एजेंट सत्रों की समीक्षा करने के लिए नियंत्रण प्रदान करता है। यह एजेंट-रचित प्रतिबद्धताओं और ऑडिट घटनाओं को भी रिकॉर्ड करता है, जो इस प्रकार की नियंत्रण प्रक्रिया का समर्थन करता है। (docs.github.com)

प्लेबुक 2: एक असुरक्षित कोड परिवर्तन को वापस लाएँ

इसका उपयोग तब करें जब एजेंट का कोड पहले ही मर्ज हो चुका हो।

1. घटना की घोषणा करें और अंतिम ज्ञात अच्छे संस्करण की पहचान करें।
2. आगे के रोलआउट को रोकें।
3. पुल रिक्वेस्ट को वापस लाएँ या पिछली ज्ञात-अच्छी रिलीज को तैनात करें।
4. यदि रोलबैक स्वयं जोखिम भरा है तो कैनरी या सीमित परिनियोजन का उपयोग करें।
5. सेवा-स्तर के संकेतकों, त्रुटि दरों, सुरक्षा संकेतों और ग्राहक प्रभाव को सत्यापित करें।
6. जाँच के लिए मूल परिवर्तन को संरक्षित करें।
7. पहचानें कि समस्या एजेंट, कार्य विवरण, लापता परीक्षण, समीक्षा विफलता, या परिनियोजन प्रक्रिया से आई है या नहीं।
8. कार्य को फिर से खोलने से पहले एक प्रतिगमन परीक्षण या गार्डरेल जोड़ें।

GitHub का पुल रिक्वेस्ट वर्कफ़्लो एक नया पुल रिक्वेस्ट बना सकता है जो एक मर्ज किए गए पुल रिक्वेस्ट को उलट देता है। उत्पादन प्रणालियों के लिए, कैनरी परिनियोजन एक पूरक नियंत्रण है क्योंकि यह परिवर्तन को और बढ़ावा देने से पहले उजागर किए गए उपयोगकर्ताओं की संख्या को सीमित करता है। (docs.github.com)

प्लेबुक 3: एक जोखिम भरे परिनियोजन को रोकें

उत्पादन-बाध्यकारी परिवर्तनों के लिए:

• तत्काल वैश्विक रिलीज के बजाय मंचबद्ध परिनियोजन का उपयोग करें।
• परिनियोजन से पहले स्वचालित ठहराव की शर्तें परिभाषित करें।
• त्रुटियों, विलंबता, उपलब्धता, सुरक्षा अलर्ट और व्यावसायिक परिणामों की निगरानी करें।
• एक आपातकालीन स्टॉप तंत्र बनाए रखें।
• जब सीमाएँ पार हो जाती हैं तो पिछली सत्यापित रिलीज पर वापस रोल करें।

साइबर सुरक्षा और इंफ्रास्ट्रक्चर सुरक्षा एजेंसी कैनरी परिनियोजन, नियंत्रित रोलआउट, विस्तार के दौरान निगरानी और एक आपातकालीन स्टॉप तंत्र की सिफारिश करती है। Google का साइट विश्वसनीयता इंजीनियरिंग मार्गदर्शन इसी तरह कैनरीइंग को एक परिवर्तन को मान्य करते हुए यातायात के केवल एक छोटे हिस्से को उजागर करने के तरीके के रूप में सिफारिश करता है। (cisa.gov)

प्लेबुक 4: अपनाने के चरण को वापस लाएँ

कभी-कभी कोड सुरक्षित होता है, लेकिन ऑपरेटिंग मॉडल तैयार नहीं होता। यदि समीक्षा भार, डेवलपर हताशा, या रखरखाव शोर अत्यधिक हो जाता है:

1. विस्तार रोकें।
2. टीमों को पिछले परिपक्वता चरण पर वापस लाएँ।
3. सबसे पहले उच्चतम-स्वायत्तता सुविधाओं को अक्षम करें।
4. यदि यह उपयोगी रहता है तो कम-जोखिम वाली सहायता प्राप्त कोडिंग उपलब्ध रखें।
5. दस्तावेज़ीकरण, परीक्षण, अनुमतियों या प्रशिक्षण को ठीक करें।
6. संकीर्ण कार्य सीमाओं के साथ पायलट को फिर से चलाएँ।

एक रोलबैक कार्यक्रम की विफलता नहीं है। यह एक संकेत है कि संगठन नियंत्रित प्रयोग का उपयोग कर रहा है न कि अपनाने को अपरिवर्तनीय मानने के बजाय।

एक नब्बे-दिवसीय रोलआउट योजना

दिन 1 से 10: आधारभूत रेखा स्थापित करें

एक-पृष्ठ का चार्टर बनाएँ जिसमें शामिल हों:

• व्यावसायिक समस्या।
• पायलट रिपॉजिटरी या सेवा।
• शामिल कार्य।
• बहिष्कृत कार्य।
• टीम के सदस्य।
• एजेंट अनुमतियाँ।
• आवश्यक समीक्षाएँ।
• आवश्यक परीक्षण और स्कैन।
• लागत सीमा।
• सफलता मेट्रिक्स।
• स्टॉप की शर्तें।
• रोलबैक स्वामी।

एजेंट को सक्षम करने से पहले आधारभूत रेखा को मापें:

• पुल रिक्वेस्ट चक्र समय।
• समीक्षा समय।
• फिर से काम करना।
• दोष दर।
• सुरक्षा निष्कर्ष।
• परिनियोजन आवृत्ति।
• परिवर्तन विफलता दर।
• डेवलपर आत्मविश्वास।
• रखरखाव बैकलॉग।

दिन 11 से 45: पायलट चलाएँ

वास्तविक काम का उपयोग करें। एक छोटी साप्ताहिक समीक्षा आयोजित करें जिसमें शामिल हो:

• एजेंट ने क्या किया।
• मानवों को क्या सुधारना पड़ा।
• कौन से कार्य उपयुक्त थे।
• कौन से कार्य आश्चर्यजनक रूप से कठिन थे।
• क्या समीक्षा प्रयास बढ़ा।
• क्या टीम परिवर्तनों को समझती है।
• क्या लागतें अपेक्षाओं से मेल खाती हैं।

टीम रेट्रोस्पेक्टिव में एक प्रश्न जोड़ें:

इस सप्ताह कोडिंग एजेंट ने कहाँ प्रयास कम किया, और कहाँ इसने अधिक काम पैदा किया?

GitHub सर्वेक्षणों, रेट्रोस्पेक्टिव्स, सहायता प्रवृत्तियों और अन्य गुणात्मक प्रतिक्रिया के साथ उपयोग डेटा को संयोजित करने की सलाह देता है, न कि एकल अपनाने की संख्या पर निर्भर रहने के बजाय। (docs.github.com)

दिन 46 से 75: ऑपरेटिंग मॉडल बनाएँ

प्रारंभिक सेंटर ऑफ एक्सीलेंस बनाने के लिए पायलट प्रतिभागियों का उपयोग करें।

प्रकाशित करें:

• स्वीकार्य-उपयोग नीति।
• जोखिम वर्गीकरण मार्गदर्शिका।
• रिपॉजिटरी निर्देश टेम्पलेट।
• पुल रिक्वेस्ट चेकलिस्ट।
• एजेंट पहुँच मानक।
• सुरक्षा समीक्षा चेकलिस्ट।
• प्रशिक्षण पथ।
• रोलबैक प्लेबुक।
• अनुमोदित मेट्रिक्स।
• चैंपियन कार्यक्रम।

दिन 76 से 90: सावधानी से विस्तार करें

टीमों को एक साथ नहीं, बल्कि लहरों में जोड़ें।

प्रत्येक लहर के लिए:

1. पुष्टि करें कि रिपॉजिटरी में आवश्यक परीक्षण और स्वामित्व है।
2. शाखा सुरक्षा और कोड-स्वामी नियमों की पुष्टि करें।
3. टीम को प्रशिक्षित करें।
4. एक चैंपियन असाइन करें।
5. अनुमत कार्य श्रेणियों को परिभाषित करें।
6. एक बजट और समीक्षा क्षमता निर्धारित करें।
7. गुणवत्ता और डेवलपर अनुभव को मापें।
8. जारी रखने, रोकने या दायरे को संकीर्ण करने का निर्णय लें।

पहला अगला कदम

सबसे अच्छी पहली कार्रवाई अधिक लाइसेंस खरीदना नहीं है। यह एक इंजीनियरिंग टीम, एक उत्पाद प्रतिनिधि, एक सुरक्षा या गुणवत्ता प्रतिनिधि, और एक प्लेटफ़ॉर्म प्रतिनिधि के साथ साठ-मिनट की स्वायत्तता डिज़ाइन कार्यशाला निर्धारित करना है।

कार्यशाला के दौरान, चुनें:

• एक रिपॉजिटरी।
• एक कम-जोखिम वाली कार्य श्रेणी।
• एक मानव अनुमोदन नियम।
• एक मापने योग्य परिणाम।
• एक स्टॉप कंडीशन।
• एक रोलबैक स्वामी।

एक उपयुक्त पहला कार्य हो सकता है:

“हर हफ्ते, निर्भरता अलर्ट का निरीक्षण करें और अनुमोदित पैच-स्तर के अपडेट के लिए एक पुल रिक्वेस्ट खोलें। एप्लिकेशन लॉजिक, परिनियोजन कॉन्फ़िगरेशन, प्रमाणीकरण, या वर्कफ़्लो अनुमतियों को न बदलें। पूर्ण परीक्षण सूट और सुरक्षा जाँच चलाएँ। तीन असफल प्रयासों के बाद या जब पाँच खुले रखरखाव पुल रिक्वेस्ट मौजूद हों तो रुकें।”

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

निष्कर्ष

स्वायत्त कोडिंग एजेंटों को सुरक्षित रूप से अपनाना मुख्य रूप से एक संगठनात्मक डिज़ाइन समस्या है।

सबसे मजबूत मॉडल आमतौर पर है:

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

लक्ष्य सॉफ्टवेयर विकास से लोगों को हटाना नहीं है। लक्ष्य मानव ध्यान को वास्तुकला, उत्पाद निर्णय, सुरक्षा, विश्वसनीयता, उपयोगकर्ता अनुभव और बेहतर प्रणालियों के डिज़ाइन की ओर ले जाना है।

स्वायत्तता सबूत से अर्जित की जानी चाहिए। जब कोई संगठन यह समझा सकता है कि उसके एजेंटों को क्या करने की अनुमति है, यह साबित कर सकता है कि उनके काम की जाँच की जाती है, और उन्हें बिना किसी नाटक के रोक सकता है, तो कोडिंग एजेंट अराजकता के स्रोत के बजाय एक बल गुणक बन जाते हैं।

चयनित स्रोत

• Source 1: DevOps Research and Assessment, State of AI-Assisted Software Development 2025
• Source 2: Model Evaluation and Threat Research, Measuring the Impact of Early-2025 Artificial Intelligence on Experienced Open-Source Developer Productivity
• Source 3: DevOps Research and Assessment, Fostering Developers’ Trust in Generative Artificial Intelligence
• Source 4: Microsoft Learn, Agentic Artificial Intelligence Maturity Model: Organization and Culture
• Source 5: Microsoft Learn, Organizational Readiness for Artificial Intelligence Agents
• Source 6: GitHub Docs, Piloting a New Copilot Feature or Model
• Source 7: GitHub Docs, Maintaining Codebase Standards in a GitHub Copilot Rollout
• Source 8: GitHub Docs, Risks and Mitigations for GitHub Copilot Cloud Agent
• Source 9: Google Site Reliability Engineering, Canarying Releases
• Source 10: Cybersecurity and Infrastructure Security Agency, Safe Software Deployment
• Source 11: Open Worldwide Application Security Project, State of Agentic Artificial Intelligence Security and Governance
• Source 12: GitHub Docs, Creating Automations with Copilot Cloud Agent