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