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