“एन्ट्रॉपी पर विजय” का भाग

AI-जनरेटेड कोड के साथ मेरी अधिकांश समस्याएं विश्वास से संबंधित हैं। क्या मुझे उस व्यक्ति पर भरोसा है जिसने यह टिकट लिखा? क्या मुझे उस इंजीनियर पर भरोसा है जिसने यह PR खोला, जिसने टिकट को समझा और कोडिंग एजेंट को इसे ठीक से लागू करने के लिए निर्देशित किया? क्या मुझे कोडिंग एजेंट के कार्यान्वयन पर भरोसा है? क्या मुझे अपने टेस्ट सूट पर भरोसा है कि यह प्रोडक्शन में जाने से पहले रिग्रेशन को पकड़ लेगा? क्या मुझे अपने CI/CD पर भरोसा है कि यह हमारे परिवर्तनों को ठीक से बिल्ड, टेस्ट और डेप्लॉय करेगा? क्या मुझे अपने ऑब्जर्वेबिलिटी सेटअप पर भरोसा है कि यह हमें अलर्ट करेगा जब AI-जनरेटेड कोड प्रोडक्शन को तोड़ देगा? क्या मुझे AI SRE (साइट विश्वसनीयता इंजीनियर) पर भरोसा है कि यह समस्या का ठीक से निदान करेगा और हमें इसे कम करने में मदद करेगा? क्या मुझे Git Hub पर भरोसा है कि जब हमें इसकी सबसे ज्यादा जरूरत होगी तो इसका कोई इंसिडेंट नहीं होगा? विश्वास कमाना मुश्किल है और खोना आसान। इसलिए मुझे लगता है कि इंजीनियरिंग टीम के भीतर विश्वास की संस्कृति को बढ़ावा देना महत्वपूर्ण है। आपको इंजीनियरों पर भरोसा करना चाहिए कि वे सही काम करेंगे।

जवाबदेही को प्रोत्साहित करना

मुझे यह स्पष्ट रूप से संप्रेषित करना उपयोगी लगता है: “आप जो शिप करते हैं उसके लिए आप जवाबदेह हैं। अगर यह प्रोडक्शन को तोड़ता है और आपने PR लिखा है, तो आपको इसे ठीक करने के लिए वहां मौजूद रहना चाहिए।”

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

यहां कुछ अभ्यास हैं जो मुझे इस कोडिंग के नए युग में इंजीनियरिंग जवाबदेही को सुविधाजनक बनाने के लिए उपयोगी लगे हैं:

कोडिंग दिशानिर्देश

एक स्पष्ट प्रौद्योगिकी रणनीति रखें: अपने कोडबेस के लिए क्या मायने रखता है यह तय करने के लिए कुछ समय लें और स्पष्ट दिशानिर्देशों में निवेश करें। मनुष्यों और कोडिंग एजेंटों दोनों के लिए। भले ही मनुष्य दिशानिर्देश न पढ़ें, उनके कोडिंग एजेंट पढ़ेंगे, और उनका पालन करेंगे (ज्यादातर)।

डिटरमिनिस्टिक टूलिंग

कोड गुणवत्ता सुनिश्चित करने के लिए डिटरमिनिस्टिक टूलिंग का भारी उपयोग करें। टाइप्ड भाषाएं, लिंटर्स, डेड कोड डिटेक्शन, सुरक्षा स्कैन, CI/CD, और इसी तरह। इन सभी टूल्स का अस्तित्व कोडिंग एजेंटों से पहले था और ये हमें स्लॉप के खिलाफ लड़ाई में मदद करते हैं। (विशिष्ट सिफारिशों के लिए एक फॉलो-अप पोस्ट के लिए बने रहें!)

छोटे PRs को लागू करें

इंजीनियरों को अनरिव्यूएबल PRs को अस्वीकार करने के लिए सशक्त बनाएं। यदि संभव हो, तो इस मानदंड को संहिताबद्ध करें ताकि किसी भी अनरिव्यूएबल PR को तुरंत अस्वीकार कर दिया जाए। बेशक, अपवादों के लिए जगह छोड़ना सुनिश्चित करें।

टेस्ट के मालिक बनें

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

उत्पाद में स्वाद

एक सुसंगत उत्पाद दृष्टि रखने के लिए उत्पाद के साथ मिलकर काम करें। AI के साथ पागल हो जाना और जो भी फीचर दिमाग में आए उसे लागू करना बहुत आसान है। सुनिश्चित करें कि आप केवल उपयोगी फीचर्स लागू करते हैं जो वास्तव में उपयोगकर्ताओं को मूल्य प्रदान करते हैं!

प्रोटोटाइप

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

परिणाम पर ध्यान केंद्रित करें

परिणाम के बारे में व्यावहारिक बनें। कभी-कभी कोड परिणाम नहीं होता। परिणाम एक रिपोर्ट होती है, या एक टूल जो आपको कुछ और पूरा करने में मदद करता है। ऐसे मामलों के लिए कोड की गुणवत्ता उतनी प्रासंगिक नहीं है जब तक परिणाम उपयोगी है।