कोडेक्स और मल्टी-एजेंट वर्कफ़्लो: नियंत्रण खोए बिना एजेंटों के साथ काम करें
· 8 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
पहली बार जब कोई कोडिंग एजेंट वास्तव में आपके लिए बग ठीक करता है, तो प्रतिक्रिया लगभग हमेशा एक जैसी होती है: उत्साह और संदेह का मिश्रण। अच्छा, निश्चित। लेकिन फिर आप अंतर को देखते हैं और खुद से पूछते हैं: "ठीक है, लेकिन उसने वास्तव में क्या छुआ? क्या मैं उस पर भरोसा कर सकता हूं? क्या वह कल फिर से उसी तरह से ऐसा करेगा?"
मुझे लगता है कि दिलचस्प हिस्सा यहीं से शुरू होता है। तब नहीं जब एजेंट कोई फ़ंक्शन लिखता है, बल्कि जब वह काम के पूरे हिस्से को लेने में सक्षम हो जाता है: रिपॉजिटरी पढ़ें, पैच बनाएं, परीक्षण चलाएं, पीआर खोलें, समीक्षा टिप्पणी के बाद वापस आएं। कोडेक्स ठीक उसी दिशा में आगे बढ़ रहा है: पृष्ठभूमि कार्य, अलग वर्कट्री, एकीकृत ब्राउज़र, ऑटोमेशन, प्लगइन्स, मेमोरी और अधिक स्पष्ट अनुमति नियंत्रण।
मुद्दा ऐसे भविष्य की कल्पना करने का नहीं है जहां अब कोई भी कोड नहीं पढ़ेगा। यह एक भयानक भविष्य होगा, साथ ही काफी अनुभवहीन भी। मुद्दा यह पता लगाना है कि उन एजेंटों के साथ कैसे काम किया जाए जो उन्हें सब कुछ करने दिए बिना भी बहुत कुछ कर सकते हैं।
आदत का बदलाव
पारंपरिक स्वतः पूर्णता के साथ आप हमेशा गाड़ी चला रहे थे। एआई ने एक लाइन सुझाई, आपने फैसला कर लिया। हालाँकि, एक एजेंट के साथ रिश्ता बदल जाता है: आप उसे एक लक्ष्य देते हैं और वह अपने दम पर कई कदम उठाता है।
यह शक्तिशाली है, लेकिन यह समस्या को बदल देता है। प्रश्न अब केवल "क्या मॉडल प्रोग्राम कर सकता है?" नहीं है। प्रश्न बन जाता है:
- क्या मैंने उसे पर्याप्त छोटा दायरा दिया?
- क्या आप जानते हैं रिजल्ट कैसे चेक करें?
- क्या मैं एक अलग वातावरण में काम कर रहा हूँ?
- क्या अंतिम समीक्षा अभी भी मानवीय और सावधान है?
एक स्वस्थ वर्कफ़्लो किसी जादू की छड़ी से अधिक इस तरह दिखता है:
यह "एजेंट सब कुछ बनाता है" की तुलना में कम रोमांटिक लगता है, लेकिन यह बहुत बेहतर काम करता है। और यह भी है कि जो टीमें इंसानों के साथ अच्छी हैं वे कैसे काम करती हैं: स्पष्ट कार्य, त्वरित प्रतिक्रिया, स्पष्ट जवाबदेही।
अच्छा संकेत लगभग एक अच्छा टिकट है
सबसे खतरनाक संकेत अस्पष्ट लेकिन आश्वस्त संकेत है: "चालान पृष्ठ को ठीक करें", "वास्तुकला में सुधार करें", "ऑथ मॉड्यूल को साफ करें"। ये ऐसे अनुरोध हैं जो उपयोगी लगते हैं और भारी मतभेद पैदा करते हैं। लेकिन फिर आप स्वयं को पुरातत्व करते हुए पाते हैं।
एक सहायक संकेत अधिक उबाऊ है. उदाहरण के लिए: इनवॉइस पृष्ठ के लिए CSV निर्यात लागू करें, यह जानते हुए कि तालिका app/(dashboard)/invoices/page.tsx में है, क्वेरीज़ src/server/invoices.ts में हैं और app/(dashboard)/reports में पहले से ही एक समान पैटर्न है।
फिर स्पष्ट बाधाएँ जोड़ें: डेटाबेस स्कीमा न बदलें, यदि छोटी उपयोगिता पर्याप्त है तो निर्भरताएँ न जोड़ें, मौजूदा यूआई शैली रखें। और सत्यापन के साथ बंद करें: npm test -- invoices और npm run build।
इस प्रकार का संक्षिप्त विवरण "एआई को बेहतर ढंग से समझाने" के लिए नहीं है। यह सबसे पहले आपको यह स्पष्ट करने का काम करता है कि आप क्या सौंप रहे हैं। यदि आप इसे ठोस रूप से नहीं लिख सकते हैं, तो शायद कार्य अभी एजेंट के लिए तैयार नहीं है।
तीन नौकरियाँ जो मैं स्वेच्छा से सौंपता हूँ
पहला दोहराव वाला लेकिन सत्यापन योग्य कार्य है: परीक्षण जोड़ना, कॉल को एक नए आंतरिक एपीआई में स्थानांतरित करना, आयात अपडेट करना, अप्रचलित घटकों को बदलना, टाइपस्क्रिप्ट त्रुटियों को ठीक करना। यहां एजेंट घंटों बचा सकता है और जोखिम नियंत्रणीय है।
दूसरा खोजपूर्ण कार्य है: "पता लगाएं कि इस कुल की गणना कहां की गई है", "मुझे समझाएं कि यह परीक्षण नाजुक क्यों है", "बग को पुन: उत्पन्न करें और मुझे बताएं कि कौन सी फ़ाइलें प्रभावित होती हैं"। यहां तक कि जब यह तुरंत कोई पैच तैयार नहीं करता है, तब भी यह उपयोगी टोह ले सकता है।
तीसरा आवर्ती रखरखाव कार्य है: छोटे निर्भरता अद्यतन, पुराने फ़ीचर फ़्लैग की सफ़ाई, अवरुद्ध पीआर का सारांश, भूले हुए TODO की जाँच। यह ग्लैमरस नहीं है, लेकिन यह बिल्कुल उस तरह का काम है जो ढेर हो जाता है।
तीन नौकरियाँ जिन्हें मैं मानव रखता हूँ
उत्पाद संबंधी निर्णय मानवीय बने रहते हैं। यदि कोई परिवर्तन उपयोगकर्ता के भुगतान करने के तरीके को बदलता है, डेटा हटाता है, कीमतें देखता है, या अनुमति को समझता है, तो मुझे एक जिम्मेदार व्यक्ति चाहिए।
सुरक्षा सीमाएँ भी मानवीय ध्यान देने योग्य हैं: प्राधिकरण, भूमिकाएँ, टोकन, संवेदनशील डेटा लॉगिंग, डेटाबेस माइग्रेशन। एक एजेंट कार्यान्वयन में मदद कर सकता है, लेकिन उसे एकमात्र निर्णय लेने वाला नहीं होना चाहिए।
अंत में, मैं वह सब कुछ रखता हूं जिसके लिए वास्तुशिल्पीय स्वाद की मानवीय आवश्यकता होती है। एक एजेंट एक रिफैक्टर का प्रस्ताव कर सकता है, लेकिन यह समझना कि क्या एक अमूर्तता वास्तव में आवश्यक है या क्या हम सिर्फ एक गैर-मौजूद समस्या को ठीक कर रहे हैं, एक काम बना हुआ है।
समीक्षा वैकल्पिक नहीं है
जब कोई एजेंट अच्छा होता है, तो प्रलोभन सीआई के हरे रंग पर भरोसा करने का होता है। यह समझ में आता है। यह तब भी होता है जब समस्याएं शुरू होती हैं।
मैं हमेशा कम से कम पाँच चीज़ें देखता हूँ:
- क्या पैच केवल अनुरोधित कार्य को हल करता है?
- क्या उसने ऐसी फ़ाइलें छुईं जिनका इससे कोई लेना-देना नहीं था?
- क्या परीक्षण नवीन व्यवहार या केवल सुखद अवसर को कवर करते हैं?
- क्या कोड स्थानीय पैटर्न का पालन करता है?
- क्या त्रुटियों को प्रोजेक्ट के बाकी हिस्सों की तरह ही नियंत्रित किया जाता है?
जब कुछ गलत होता है, तो प्रतिक्रिया विशिष्ट होनी चाहिए। "इसे ठीक करो" आलसी है। बेहतर: यह उपयोगिता parseMoney को src/lib/money.ts में डुप्लिकेट करती है; उस फ़ंक्शन का पुन: उपयोग करें, EUR मामले के लिए एक परीक्षण जोड़ें और बिलिंग मॉड्यूल के सार्वजनिक एपीआई को न बदलें।
एजेंट छोटी, सत्यापन योग्य टिप्पणियों पर बेहतर प्रतिक्रिया देते हैं। दिलचस्प बात यह है कि लोग भी ऐसा ही करते हैं।
प्रयास के लायक रेलिंग
यदि कोई एजेंट फ़ाइलें पढ़ सकता है, कोड लिख सकता है और कमांड निष्पादित कर सकता है, तो इसे एक शक्तिशाली प्रक्रिया के रूप में माना जाना चाहिए। व्यामोह की कोई आवश्यकता नहीं है, आपको स्वच्छता की आवश्यकता है।
अलग-अलग वर्कट्री या शाखाओं का उपयोग करें। तो आप अंतर की तुलना कर सकते हैं, असफल प्रयोगों को फेंक सकते हैं, और जो आप कर रहे थे उसके साथ एजेंट के काम को नहीं मिला सकते हैं।
अनुमतियाँ सीमित करें. rg, git diff, npm test और npm run build जैसे कमांड काफी मुफ़्त हो सकते हैं। तैनाती, डेटाबेस माइग्रेशन, रहस्यों तक पहुंच और विनाशकारी आदेश स्पष्ट रहने चाहिए।
जब आपको इसकी आवश्यकता न हो तो नेटवर्क एक्सेस कम करें। कई कार्यों के लिए, आधिकारिक दस्तावेज़ीकरण, पैकेज रजिस्ट्री और विशिष्ट आंतरिक सेवाएँ पर्याप्त हैं। कम सतह क्षेत्र, कम आश्चर्य।
गतिविधियों को ट्रैक करें. जब कोई पैच समीक्षा के लिए आता है, तो आपको संकेतों, निष्पादित आदेशों, उत्तीर्ण परीक्षणों और संशोधित फ़ाइलों को फिर से बनाने में सक्षम होना चाहिए। नौकरशाही बनाने के लिए नहीं, बल्कि यह समझने में सक्षम होने के लिए कि अगर कुछ गलत हुआ तो क्या हुआ।
एक टीम के रूप में शुरुआत करने का आसान तरीका
यदि मुझे एजेंटों को एक छोटी टीम में शामिल करना होता, तो मैं बड़ी क्रांतियों के बिना शुरुआत करता।
मैं स्पष्ट दायरे वाले मुद्दों के लिए agent-ready लेबल बनाऊंगा। मैं संदर्भ, बाधाओं और सत्यापन आदेशों के साथ एक टेम्पलेट जोड़ूंगा। मैं छोटे पीआर के लिए कहूंगा, आदर्श रूप से कुछ सौ पंक्तियों के अंतर्गत। दृश्यमान परिवर्तनों के लिए मुझे परीक्षण या स्क्रीनशॉट की आवश्यकता होगी। और सबसे बढ़कर मैं इस मर्ज के लिए एक व्यक्ति को जिम्मेदार रखूंगा।
दो सप्ताह के बाद मैं डेटा देखूंगा: कौन से कार्यों में वास्तव में तेजी आई, कौन सी समीक्षाएँ भारी थीं, कौन से संकेत भ्रमित करने वाले थे, कोडबेस के कौन से हिस्से सौंपने के लिए बहुत नाजुक हैं।
यह "आज से हम एजेंटों के साथ सब कुछ करेंगे" की तुलना में कम शानदार दृष्टिकोण है, लेकिन यह वह तरीका है जो आपको बिना पछतावे के तीसरे सप्ताह तक पहुंचने की अनुमति देता है।
सबसे मानवीय हिस्सा
मजेदार बात यह है कि जितने अधिक स्वायत्त एजेंट बनते हैं, क्लासिक कौशल फिर से उतने ही महत्वपूर्ण हो जाते हैं: एक अच्छा टिकट लिखना, छोटी कटौती करना, परीक्षण बनाना, अंतर पढ़ना, ट्रेड-ऑफ संचार करना। एजेंट उन लोगों को गति देता है जो पहले से ही अच्छी तरह से काम करना जानते हैं। यह उन लोगों की अराजकता को भी बढ़ाता है जो बुरी तरह से प्रतिनिधि करते हैं।
तो नहीं, मैं मल्टी-एजेंट वर्कफ़्लो को इंजीनियरिंग करना बंद करने के शॉर्टकट के रूप में नहीं देखता। मैं उन्हें उन हिस्सों में अधिक ऊर्जा स्थानांतरित करने के तरीके के रूप में देखता हूं जो मायने रखते हैं: यह तय करना कि क्या बनाना है, यह सुनिश्चित करना कि यह काम करता है, सिस्टम को समझने योग्य बनाए रखना।
एजेंट महान अतुल्यकालिक सहयोगी बन सकते हैं। लेकिन एक अतुल्यकालिक सहयोगी को उपयोगी होने के लिए संदर्भ, सीमाओं और समीक्षा की आवश्यकता होती है। सिर्फ दूसरों की तरह।