मेरी पिछली पोस्ट में, मैंने आपको दिखाया था कि क्यों वेरिफिकेशन (सत्यापन) वह नींव है जिस पर मैं एजेंटों के साथ सब कुछ करता हूँ, और अपने खुद के वेरिफिकेशन स्किल्स कैसे बनाना शुरू करें। मुख्य सबक यह था कि अगर कोई एजेंट अपने काम को सत्यापित नहीं कर सकता, तो बाकी सब कुछ बेकार है। आप ही बाधा बने रहते हैं, और आपका पूरा दिन अपने एजेंटों की देखभाल करने में बीत जाएगा।
https://x.com/poteto/status/2094457600259842065
लेकिन एक बार जब वेरिफिकेशन काम करने लगे, तो अगला सवाल यह है: आप वास्तव में कैसे पता लगाते हैं कि क्या बनाना है?
https://x.ai/bot/plugin/9717366
इस पोस्ट में, मैं आपको बताने जा रहा हूँ कि मैं pstack के साथ कैसे रिसर्च, प्लानिंग, प्रोटोटाइपिंग और आर्किटेक्चर करता हूँ। यह वही सटीक वर्कफ़्लो है जो मुझे कोड की गुणवत्ता को असाधारण रूप से उच्च रखते हुए एक महीने में हज़ारों PRs को प्रोडक्शन में भेजने की अनुमति देता है।
अगस्त के महीने का अंत प्रोडक्शन में 2,462 PRs के साथ
अपने से ज़्यादा बुद्धिमान किसी की निगरानी करने की कला
2024 के पुराने दिनों में, सिस्टम में कोई भी बदलाव करने के लिए, आपको पहले यह समझने के लिए उसका पर्याप्त हिस्सा पढ़ना होता था कि क्या चल रहा है। कोडबेस के आकार और जटिलता के आधार पर, इसमें आपको घंटों से लेकर दिनों और महीनों तक का समय लग सकता था। एक छोटे से बदलाव के साथ, आप शायद एक छोटे सबसिस्टम की स्थानीय समझ से काम चला सकते थे। हालाँकि, अगर आप कोर को रीफैक्टर कर रहे थे, तो आपको शायद यह जानने के लिए पूरे सिस्टम का एक मेंटल मॉडल चाहिए होता था कि रीफैक्टर को सही और प्रभावी ढंग से कैसे किया जाए।
एजेंट स्पष्ट रूप से इस बाधा को दूर करते हैं। आप बस अपने एजेंट को प्रॉम्प्ट करके सिस्टम में बहुत आसानी से बदलाव कर सकते हैं, और वह इसे करेगा, भले ही आप कोड के बारे में कितना भी जानते हों या नहीं। लेकिन कोड और उपयोगकर्ता अनुभव की गुणवत्ता को उच्च बनाए रखना अभी भी मुश्किल है, खासकर यदि आप पहले से ही डोमेन विशेषज्ञ नहीं हैं जो जानता है कि क्या देखना और पूछना है।
भले ही फ्रंटियर मॉडल बहुत सक्षम हो गए हैं, फिर भी 2 विफलता मोड हैं जिन्हें मैं लगातार देखता हूँ:
- वे आपके इरादे को पूरी तरह से समझने में असमर्थ हैं क्योंकि वे कम/खराब तरीके से निर्दिष्ट हैं।
- उनके पास काम को सही ढंग से करने के तरीके के बारे में पर्याप्त संदर्भ नहीं है।
ये दोनों समस्याएँ आपस में जुड़ी हुई हैं। एजेंटों का अच्छी तरह से उपयोग करना इस बात पर निर्भर करता है कि आप एजेंट के कॉन्टेक्स्ट विंडो को उच्च गुणवत्ता वाले संदर्भ से कितनी अच्छी तरह भर पाते हैं। आप निश्चित रूप से ऐसा किए बिना भी काम करने वाला कोड लिख सकते हैं, लेकिन मैंने पाया है कि परिणाम और गुणवत्ता बहुत बेहतर होते हैं जब मैंने अपने एजेंटों को उच्च गुणवत्ता वाला काम करने के लिए आवश्यक सब कुछ प्रदान करने का काम किया हो।
अपने शब्दों में
फ्रंटियर मॉडल बहुत सक्षम कोडर हैं। जबकि पुराने मॉडलों के साथ मैंने बहुत विशेष रूप से प्रॉम्प्ट किया होगा कि मैं उनसे क्या करवाना चाहता हूँ, लगभग उन्हें माइक्रोमैनेज करते हुए, नवीनतम मॉडल आपसे या मुझसे बेहतर कोड लिखने में सक्षम हैं। इसलिए मैं एजेंट को यह बताने के बीच एक अच्छा संतुलन बनाना चाहता हूँ कि मैं उससे क्या हासिल करवाना चाहता हूँ, जबकि उसे उन तरीकों से हल करने की स्वतंत्रता देना चाहता हूँ जिनके बारे में मैंने शायद नहीं सोचा होगा।
यह आपसे ज़्यादा बुद्धिमान किसी की निगरानी करने की कला है, एक ऐसे कोडबेस पर जिसे आपने खुद नहीं लिखा है, और जहाँ मनुष्य अब कोडबेस के पूरे मेंटल मॉडल को अपने दिमाग में फिट नहीं कर सकते हैं।
एक तकनीक जो मुझे उपयोग करना पसंद है वह है अप्रत्यक्ष प्रॉम्प्ट। एजेंट को यह बताने के बजाय कि मैं वास्तव में क्या चाहता हूँ, मैं इसे एजेंट से निकालने की कोशिश करता हूँ - उसके अपने शब्दों में।
उदाहरण के लिए, जब कोई Slack में कोई समस्या रिपोर्ट करता है, तो मैं अक्सर एजेंट से कहता हूँ कि वह थ्रेड पढ़े और कुछ और करने से पहले समस्या को अपने शब्दों में फिर से बताए।
उदाहरण के लिए, मैं कह सकता हूँ:
/poteto-mode इस स्लैक थ्रेड को पढ़ो। अपने शब्दों में और सरल भाषा में बताओ कि तुम्हें क्या लगता है कि अंतर्निहित समस्या क्या है
यह तीन काम करता है:
पहला, यह एजेंट को एक शोरगुल वाली बातचीत को एक संरचित समस्या विवरण में संपीड़ित करने के लिए मजबूर करता है। दूसरा, यह मुझे तुरंत गलतफहमियों को पकड़ने देता है। यदि एजेंट थ्रेड में किसी गलत संकेत पर ध्यान केंद्रित करता है, तो मैं कोई कोड लिखना शुरू करने से पहले इसे जल्दी से ठीक कर सकता हूँ।
और तीसरा, मैंने अपनी खुद की धारणाओं और परिकल्पनाओं को बताकर संभावित रूप से इसे गलत रास्ते पर नहीं ले जाया है जो गलत हो सकती हैं या एजेंट अन्यथा जो हासिल कर सकता था उसे सीमित कर सकती हैं।
एक मेंटल मॉडल बनाना
एजेंट से अपने आप को इस तरह से फिर से बताने के लिए कहना जिसे आप समझ सकें, अपने से ज़्यादा बुद्धिमान किसी के साथ काम करने का एक महत्वपूर्ण हिस्सा है। यही /teach के लिए प्रेरणा थी, एक स्किल जो आपके एजेंट को चीजों को आपको सहज तरीके से समझाने में मदद करती है। मैं इसका उपयोग तब करता हूँ जब मुझे यह सुनिश्चित करने की आवश्यकता होती है कि मेरा एजेंट कुछ ऐसा कर रहा है जो मुझे समझ में आता है।
हुड के नीचे, /teach /how और /why को कॉल करता है।
/how रनटाइम मैकेनिक्स का पता लगाता है। जब आप /how पूछते हैं, तो एजेंट सबसिस्टम की जटिलता का आकलन करता है। यदि सबसिस्टम कई निर्देशिकाओं या सेवाओं में फैला हुआ है, तो यह Grok जैसे तेज़, कुशल मॉडल पर समानांतर एक्सप्लोरर एजेंटों को स्पॉन करता है।
/how वर्चुअलाइजेशन कैसे लागू किया जाता है?
/why प्रेरणा और इरादे की जाँच करता है। कोड आपको बताता है कि क्या होता है। यह शायद ही कभी आपको बताता है कि किसी ने इसे उस तरह से क्यों लिखा। जब आप /why चलाते हैं, तो pstack समानांतर में कई स्रोतों पर ऐतिहासिक साक्ष्यों की जाँच करता है: Git हिस्ट्री और PR रिव्यू कमेंट्स, Linear टिकट्स, Notion डिज़ाइन डॉक्स, Slack बातचीत, Datadog मॉनिटर्स, Sentry एरर, कोड लिनिएज, और एनालिटिक्स वेयरहाउस इवेंट्स।
/why हम अभी भी node.js के पुराने वर्जन पर क्यों अटके हैं?
मैं /teach का उपयोग तब करता हूँ जब मैं चाहता हूँ कि एजेंट कुछ फिर से बताए ताकि मैं उसके काम को बेहतर ढंग से समझ और भरोसा कर सकूँ।
/teach मुझे सिखाओ कि तुमने इसे इस तरह क्यों लागू किया न कि <दूसरे तरीके> से। तुमने कौन से ट्रेडऑफ़ किए और क्यों?
व्यवहार में, मैंने यह भी पाया है कि /teach स्किल द्वारा किया गया शोध न केवल मनुष्यों के लिए, बल्कि एजेंटों के लिए भी उपयोगी है। नवीनतम फ्रंटियर मॉडलों के साथ भी, (यह हार्नेस की गुणवत्ता पर भी निर्भर करता है), सामान्य तौर पर मैं पाता हूँ कि वे अक्सर डेटा के साथ इसका समर्थन किए बिना या यह समझने के लिए आवश्यक कोड को वास्तव में पढ़े बिना आत्मविश्वास से बातें बताते हैं कि यह कैसे काम करता है। इसलिए आपको यह सिखाने का यह कार्य कि यह क्या करने जा रहा है और क्यों, अंततः एजेंट की भी मदद करता है।
इतिहास से सीखना
मेरी कई परियोजनाएँ कई वार्तालापों में फैली हुई हैं। उदाहरण के लिए, कुछ महीने पहले मैं Cursor में लोगों द्वारा रिपोर्ट किए जा रहे वर्चुअलाइजेशन बग और प्रदर्शन समस्याओं को ठीक करने पर काम कर रहा था। मैंने महसूस किया कि हर बार जब मैं एक नई चैट शुरू करता था, तो मुझे मूल रूप से उस समृद्ध संदर्भ को फिर से बनाना शुरू करना पड़ता था जो मेरे एजेंट के पास पहले था जब वह एक समान समस्या का समाधान कर रहा था।
मैंने जो महसूस किया वह यह है कि आपके पिछले ट्रांसक्रिप्ट अक्सर समृद्ध संदर्भ के लिए एक सोने की खान होते हैं। pstack चैट हिस्ट्री से आपका हालिया संदर्भ खींचने के लिए /recall स्किल के साथ आता है, ताकि ताज़ा एजेंटों के पास भी एक अच्छी स्थिति में वापस आने के लिए आवश्यक सही संदर्भ हो।
/recall मैंने कल वर्चुअलाइजेशन पर जो काम किया था और फिर स्लैक पर इस बग रिपोर्ट को पढ़ो
/teach, /recall, /how, और /why का उपयोग करना ही वह तरीका है जिससे मैं कोडबेस के अपने स्वयं के मेंटल मॉडल को अपडेट रखता हूँ, एक ऐसे रूप में संपीड़ित करता हूँ जिसे मैं आसानी से समझ और याद रख सकता हूँ। और, यह एजेंटों की भी मदद करता है!
पीछे की ओर काम करना
एक बार जब आप समस्या को समझ जाते हैं, तो आप समाधान कैसे निर्दिष्ट करते हैं?
मेरी राय में, अधिकांश हार्नेस जिनमें प्लान मोड होते हैं, वे कार्यान्वयन विवरणों को अधिक निर्दिष्ट करते हैं और बाकी सब कुछ कम निर्दिष्ट करते हैं। यही कारण है कि pstack में, मैंने मज़ाक में कहा था कि "मुझे योजना बनाने में विश्वास नहीं है"। सच्चाई यह है कि मैं योजना बनाता हूँ, लेकिन मैं कोड के माध्यम से ऐसा करता हूँ।
कुछ प्रकार के कामों के लिए, जैसे साझा कोड या पैकेज बनाना जिनका उपयोग अन्य लोग करेंगे, मैं रीडमी-संचालित विकास में एक बड़ा विश्वास रखता हूँ। यदि आप इससे परिचित नहीं हैं, तो यह विकास की एक तकनीक है जो पुराने दिनों में लोकप्रिय थी, जहाँ आप पहले अपनी रीडमी तैयार करके शुरू करते हैं। इसने आपको अपनी डेवलपर अनुभव वाली टोपी पहनने के लिए मजबूर किया, जहाँ आप एक काल्पनिक उपयोगकर्ता के लिए API का वर्णन करके शुरू करते हैं, और कार्यान्वयन और आर्किटेक्चर की ओर पीछे की ओर काम करते हैं।
उदाहरण के लिए, जब मैं Dune, डेस्कटॉप ऐप्स के लिए हमारा इन-हाउस क्लाइंट फ्रेमवर्क बना रहा था, तो मैंने पहले इसके लिए एक ट्यूटोरियल लिखकर शुरू किया, ताकि मैं समझ सकूँ कि इसके साथ एक ऐप बनाना कैसा होगा। या कम से कम मैंने कोशिश की। एजेंट से कुछ अच्छा या पढ़ने योग्य बनवाना वास्तव में एक संघर्ष था। इसलिए मुझे पहले अपने चाकू को तेज करने में कुछ समय बिताना पड़ा, /technical-writing स्किल बनाकर।
/technical-writing स्किल के बिना रीडमी का पहला ड्राफ्ट पढ़ने में दर्दनाक था क्योंकि इसने अलग-अलग लक्ष्यों को मिला दिया। इसने एक ही दस्तावेज़ में एक ट्यूटोरियल, एक हाउ-टू गाइड, एक आर्किटेक्चरल स्पष्टीकरण और एक API संदर्भ होने की कोशिश की, जो आपके सामान्य AI स्लोप और मैनर्ड प्रोज़ के साथ लिखा गया था।
/technical-writing Diátaxis फ्रेमवर्क का उपयोग करके दस्तावेज़ीकरण को चार अलग-अलग मोड में अलग करता है:
- ट्यूटोरियल: करके सीखना। एक पाठ जो एक नए व्यक्ति को कुछ दृश्यमान बनाने के लिए चरणों की एक श्रृंखला के माध्यम से ले जाता है।
- हाउ-टू गाइड: एक अनुभवी उपयोगकर्ता के लिए एक विशिष्ट, वास्तविक दुनिया की समस्या को हल करने के चरण।
- संदर्भ: मशीनरी, API और कॉन्फ़िगरेशन फ़्लैग का शुष्क, पूर्ण, आधिकारिक तकनीकी विवरण।
- स्पष्टीकरण: उच्च-स्तरीय चर्चा जो पृष्ठभूमि, डिज़ाइन विकल्पों और ट्रेडऑफ़ को स्पष्ट और प्रकाशित करती है।
यह /unslop का भी उपयोग करता है, इसलिए यह बहुत ही पठनीय दस्तावेज़ तैयार करता है।
इस तरह से एक योजना लिखना बहुत मददगार है क्योंकि यह आपके एजेंटों को एक ठोस लक्ष्य और उद्देश्य भी देता है जिसके विरुद्ध वह अपने काम की जाँच कर सकता है। और निश्चित रूप से, यह समझना भी बहुत आसान है कि एजेंट वास्तव में क्या बनाने जा रहा है।
pstack के कई स्किल्स डिज़ाइन चरण में यहाँ संयुक्त होते हैं। उदाहरण के लिए:
(1) /recall पिछले 7 दिनों में वर्चुअलाइजेशन बग और प्रदर्शन समस्याओं को ठीक करने का मेरा काम। /how और /why का उपयोग करके समझो कि हमारा वर्तमान वर्चुअलाइजेशन कार्यान्वयन कैसे काम करता है।
(2) फिर /poteto-mode प्लानिंग और /technical-writing का उपयोग करके एक नया वर्चुअलाइजेशन इंजन बनाओ जो फ्लिकरिंग और जिटरिंग को पूरी तरह से खत्म कर दे। चलो एक ट्यूटोरियल लिखकर शुरू करते हैं कि मैं एक React ऐप को वर्चुअलाइज़ करने के लिए इस नए पैकेज का उपयोग कैसे करूँगा
(3) योजना लिखने के बाद, /teach मुझे सिखाओ और मुझे साबित करो कि यह नया दृष्टिकोण हमारे वर्तमान इंजन से बेहतर क्यों है
यहाँ तकनीक वास्तव में दिलचस्प और समृद्ध संदर्भ निकालने के बारे में है जो आपके एजेंटों को समस्या को उसी तरह देखने की क्षमता देता है जैसे आप देखते हैं - न कि केवल एक छोटे से टुकड़े के रूप में:
- प्रॉम्प्ट का पहला भाग मेरे ऐप में वर्चुअलाइजेशन कैसे लागू किया जाता है, इस बारे में प्रासंगिक पिछले और वर्तमान संदर्भ को याद करता है।
- दूसरा भाग एजेंट को उस संदर्भ का उपयोग करने के लिए मार्गदर्शित करता है, जैसे कि उसने पहले जिन बगों को ठीक किया है, ताकि एक नया डिज़ाइन तैयार किया जा सके जो उन समस्याओं को पूरी तरह से समाप्त कर दे।
- अंतिम भाग आपके एजेंट से यह साबित करने के लिए कह रहा है कि यह नया पैकेज बेहतर है। यहीं पर वेरिफिकेशन स्किल्स जैसे उच्च गुणवत्ता वाले टूल का होना महत्वपूर्ण है।
सौ बार मापो, एक बार काटो
योजना बनाते समय, मैं जो दो सबसे आम गलतियाँ देखता हूँ वे हैं:
- एजेंट के पहले डिज़ाइन को स्वीकार करना।
- अनुभवजन्य साक्ष्य के बिना योजना को अधिक पकाना।
जब मनुष्य कोड लिखते थे, तो हम अक्सर डिज़ाइन दस्तावेज़ों पर एक-दूसरे के साथ सहयोग करते थे। ये ऐसे दस्तावेज़ थे जो उच्च-स्तरीय आर्किटेक्चर, विचार किए गए विकल्पों, ट्रेडऑफ़ और किसी भी असामान्य कार्यान्वयन नोट्स के बारे में बात करते थे। एक निर्धारित डिज़ाइन पर पहुँचने से पहले इन दस्तावेज़ों के कई पुनरावृत्तियों से गुजरना बहुत आम था।
एजेंटों के साथ, जबकि हम डिज़ाइन दस्तावेज़ की औपचारिकता को छोड़ सकते हैं, मैं अक्सर एजेंट द्वारा आपको वापस दी गई पहली चीज़ को स्वीकार करने की गलती देखता हूँ। pstack के साथ, हम इसके बजाय समानांतर एजेंटों का उपयोग करके, "दो बार मापो, एक बार काटो" दृष्टिकोण को इसकी सीमा तक ले जा सकते हैं।
हम ऐसा प्रोटोटाइपिंग प्लेबुक का उपयोग करके करते हैं।
pstack में, प्लेबुक स्किल्स नहीं हैं, बल्कि /poteto-mode के अंदर संदर्भ फ़ाइलें हैं। ये प्लेबुक आप जिस प्रकार के कार्य पर काम कर रहे हैं, उसके आधार पर सशर्त रूप से लोड की जाती हैं (टोकन दक्षता के लिए)। इन 23 प्लेबुक (0.15.0 तक) में से प्रत्येक में एक वर्कफ़्लो होता है जिसका उपयोग मैं तब करता हूँ जब मैं कोई कार्य कर रहा होता हूँ।
स्किल्स के विपरीत, प्लेबुक स्वचालित रूप से /poteto-mode के भाग के रूप में एजेंट द्वारा उपयोग की जाती हैं। उदाहरण के लिए:
/poteto-mode नए ड्रॉपडाउन मेनू के लिए कुछ विकल्पों का प्रोटोटाइप बनाओ /poteto-mode इस बग को ठीक करो /poteto-mode इस स्किल बदलाव का मूल्यांकन करो
प्रोटोटाइपिंग मेरी पसंदीदा pstack प्लेबुक में से एक है। यह आपको एक लक्ष्य के लिए कई प्रयास देता है और एजेंट को सबसे अच्छे विकल्प के बारे में तर्क करने में मदद करता है। यह न केवल विज़ुअल प्रोटोटाइपिंग के लिए, बल्कि सुविधाओं, बग फिक्स आदि के लिए विभिन्न समाधानों का प्रोटोटाइप बनाने के लिए भी उपयोगी है।
/poteto-mode <फीचर अनुरोध> के लिए कुछ विकल्पों का प्रोटोटाइप बनाओ। /control-app* का उपयोग करो और मेरे द्वारा समीक्षा करने और चुनने के लिए वीडियो/स्क्रीनशॉट लो
\ नोट: /control-app वह वेरिफिकेशन स्किल है जिसे हमने [भाग 1]([https://x.com/poteto/status/2094457600259842065](https://x.com/poteto/status/2094457600259842065)) में बनाया था
विज़ुअल परिवर्तनों का प्रोटोटाइप बनाते समय, एजेंट आपके ऐप में या एक स्क्रैच निर्देशिका में डिस्पोजेबल स्केच बनाता है। यदि यह किसी UI इंटरैक्शन का परीक्षण कर रहा है, तो यह एक साधारण स्विचर के पीछे दो या तीन विविधताएँ रखता है। फिर यह /control-app स्किल के साथ इंटरैक्शन को चलाता है, प्रत्येक वेरिएंट के स्क्रीनशॉट लेता है, और वास्तविक समय या लेआउट को मापता है।
प्रोटोटाइपिंग योजना बना रही है, लेकिन कोड के साथ। यह एजेंटों को समस्या स्थान का पता लगाने की स्वतंत्रता देता है, और उन्हें आपको किसी ऐसी चीज़ से आश्चर्यचकित करने का मौका देता है जिसके बारे में आपने खुद नहीं सोचा होगा। प्रोटोटाइप एजेंटों को मेरे इनपुट की प्रतीक्षा करने के बजाय अनुभवजन्य साक्ष्य के साथ अपने स्वयं के प्रश्नों का उत्तर देने की अनुमति देते हैं।
बड़े बदलावों की आर्किटेक्चरिंग
एजेंटिक युग में एक इंजीनियर के रूप में, अपना समय आर्किटेक्चर पर, सही डेटा संरचनाओं को चुनने पर, और यह सोचने पर बिताना अधिक महत्वपूर्ण है कि मैं जो सिस्टम बनाता हूँ वे एक साथ कैसे काम करेंगे। मेरे एजेंट कार्यान्वयन विवरण भरते हैं।
एक और उपयोगी स्किल जो pstack के साथ आती है वह है /architect। यह डिज़ाइन को अलग-अलग, अनुशासित चरणों में संरचित करता है:
- समस्या को आधार बनाओ। एजेंट मौजूदा स्वामित्व और बाधाओं का एक सटीक मेंटल मॉडल बनाने के लिए प्रभावित सिस्टम पर /how और /why चलाता है।
- स्केच बनाओ। एजेंट एक आर्किटेक्चर एरिना में प्रवेश करता है। यह समानांतर में स्वतंत्र उम्मीदवार रनर स्पॉन करता है, अक्सर विभिन्न मॉडल परिवारों में। प्रत्येक रनर को ग्राउंडिंग ब्रीफिंग प्राप्त होती है और एक पूर्ण डिज़ाइन पैकेज तैयार करता है: कॉलर का उपयोग स्केच, कोर टाइप परिभाषाएँ, सार्वजनिक फ़ंक्शन हस्ताक्षर, और एक संक्षिप्त तर्क। ये आमतौर पर केवल टाइप हस्ताक्षरों को स्केच करके किए जाते हैं, जो इस बात से प्राप्त होते हैं कि हम कॉल साइट्स को कैसा दिखाना चाहते हैं। प्रत्येक रनर को इंटरफ़ेस गहराई का मूल्यांकन करना चाहिए, कमजोर मॉडलों पर विफलता मोड की जाँच करनी चाहिए, और डिज़ाइन रेड फ़्लैग्स की हमारी सूची के विरुद्ध स्क्रीन करनी चाहिए।
- क्रॉस-जज और संश्लेषित करो। मुख्य एजेंट से भिन्न मॉडल का उपयोग करने वाला एक क्रॉस-जज एजेंट एक सख्त रूब्रिक के विरुद्ध उम्मीदवारों का मूल्यांकन करता है।
- स्केच के विरुद्ध कार्यान्वित करो। एजेंट स्केच के प्लेसहोल्डर बॉडी को वास्तविक तर्क से बदल देता है। यदि एजेंट कार्यान्वयन के दौरान पाता है कि किसी फ़ंक्शन को अप्रत्याशित पैरामीटर या अतिरिक्त स्थिति की आवश्यकता है, तो वह विसंगति को सतह पर लाता है।
- जब डिज़ाइन गलत हो तो उसे खत्म करो। यदि कार्यान्वयन के दौरान हम पाते हैं कि स्केच गलत थे, तो एजेंट यह सब फेंक देता है और फिर से शुरू करता है।
यहाँ बिंदु एजेंट को एक स्व-निहित मिनी-लूप देना है जहाँ वह विभिन्न मॉडल परिवारों के कई प्रतिस्पर्धी डिज़ाइनों को एक इष्टतम दृष्टिकोण में संश्लेषित कर सकता है, और कठोर होने का ध्यान रख सकता है और अपने डिज़ाइन को फेंकने से नहीं डरता अगर यह पता चलता है कि वह जो आर्किटेक्चर लेकर आया है वह अनुभवजन्य प्रमाण के आधार पर गलत है। यदि एक ही वर्कअराउंड असंबंधित कॉल साइट्स पर दिखाई देता है, या यदि प्रकारों को 𝚊𝚗𝚢 या फ़ोर्स्ड कास्ट जैसे एस्केप हैच की आवश्यकता होती है, तो यह अनुभवजन्य प्रमाण है कि आर्किटेक्चर गलत है।
/architect इस नए <फीचर अनुरोध> को
यहाँ बड़ा सबक यह है कि /poteto-mode प्रोटोटाइपिंग और /architect का उपयोग करके कोड के साथ योजना बनाना कहीं अधिक प्रभावी है।
यही कारण है कि मैं अमूर्त योजनाओं की प्रतिकूल समीक्षा करने की जहमत कभी नहीं उठाता। एजेंट सैद्धांतिक जोखिमों को भ्रमित करना शुरू कर देते हैं, और उन समस्याओं से बचाने के लिए जटिल एज केस का आविष्कार करते हैं जो कभी नहीं होंगी। अपनी योजनाओं को तब न पकाएँ जब वे अभी भी अमूर्त हों: एजेंट को प्रोटोटाइपिंग और अपने काम को सत्यापित करके अपने दम पर खुले प्रश्नों का उत्तर देने दें।
ठीक है, लेकिन मैं वास्तव में एक प्लानिंग डॉक चाहता हूँ
जबकि pstack एक प्लानिंग स्किल के साथ नहीं आता है, यह एक मल्टी-फ़ेज़ प्लानिंग प्लेबुक के साथ आता है। मैं आमतौर पर इसका उपयोग एजेंट द्वारा एक डिज़ाइन तैयार करने के बाद करता हूँ जिससे मैं खुश हूँ, एक सामरिक निष्पादन योजना बनाने के तरीके के रूप में।
/poteto-mode इस डिज़ाइन को एक योजना में बदलो
योजना में प्रत्येक कार्य प्रमाण और सत्यापन के आसपास संरचित है। प्लेबुक एजेंटों को बताती है कि अकेले परीक्षण पर्याप्त सत्यापन नहीं हैं। यह तभी सत्यापित होता है जब उसने वास्तव में कोड चलाया हो और सत्यापित किया हो कि यह काम करता है।
प्रत्येक योजना की जाँच एक स्वचालित स्क्रिप्ट द्वारा की जाती है जो इसकी संरचना और स्वरूपण को मान्य करती है। एक बार स्वीकृत होने के बाद, योजना आइटम दर आइटम निष्पादित होती है। प्रत्येक PR छोटा, आत्म-निहित और आसानी से समीक्षा योग्य होता है।
वास्तव में बड़ी परियोजनाओं के लिए (जैसे कि जिसमें मुझे पूरा एक सप्ताह लग सकता है), मैं कभी-कभी योजनाओं को अस्थायी रूप से कोडबेस में प्रतिबद्ध करने का निर्णय ले सकता हूँ ताकि अन्य एजेंट प्रगति पर काम से अवगत हों। लेकिन मैं आमतौर पर उन्हें हटा देता हूँ जब मैं कर लेता हूँ ताकि मैं कोडबेस को भ्रम की स्थिति में न छोड़ूँ। मुझे योजनाओं को स्थायी रूप से रखना मूल्यवान नहीं लगता।
व्यवहार में वर्कफ़्लो
यह देखने के लिए कि ये सभी टुकड़े एक साथ कैसे फिट होते हैं, आइए हम तीन ठोस उदाहरणों पर चलते हैं कि मैं इन वर्कफ़्लो को कैसे प्रॉम्प्ट करता हूँ।
उदाहरण 1: एक अस्पष्ट बग पर शोध करना
जब प्रोडक्शन में कोई समस्या दिखाई देती है और मूल कारण स्पष्ट नहीं होता है:
/poteto-mode जाँच करो कि बैकग्राउंड वर्कर समय-समय पर टाइमआउट त्रुटियों के साथ क्यों विफल होते हैं। मुझे एक विवरण दो कि हम क्या जानते हैं, आपने किस डेटा का उपयोग किया, और आपकी सबसे अच्छी परिकल्पनाएँ।
एजेंट कोड का पता लगाता है, समानांतर में मेट्रिक्स और ऐतिहासिक कमिट की जाँच करता है, और आपको अपने सबसे अच्छे शिक्षित अनुमान देता है कि समस्या कहाँ हो सकती है।
उदाहरण 2: एक नई सेवा सीमा डिज़ाइन करना
एक नया सबसिस्टम पेश करते समय जिस पर अन्य मॉड्यूल निर्भर होंगे:
/poteto-mode हमें बाहरी वेबहुक के लिए रेट लिमिटिंग जोड़ने की आवश्यकता है। पहले /architect इसका, और प्रोटोटाइप के साथ किसी भी खुले प्रश्न का उत्तर दो। आगे बढ़ने से पहले मुझे समीक्षा करने दो।
एजेंट मौजूदा वेबहुक आर्किटेक्चर को आधार बनाता है, कई मॉडलों में प्रतिस्पर्धी डिज़ाइन रनर स्पॉन करता है, डिस्पोजेबल प्रोटोटाइप के साथ बेंचमार्क करता है, और एक साफ, सत्यापित इंटरफ़ेस तैयार करता है।
उदाहरण 3: एक मल्टी-PR माइग्रेशन निष्पादित करना
कई फ़ाइलों में एक जटिल रीफैक्टर निष्पादित करते समय:
/poteto-mode हमारी पूरी UI लाइब्रेरी को StyleX में माइग्रेट करने की एक योजना बनाओ। माइग्रेशन को छोटे, सत्यापन योग्य PRs में तोड़ो। प्रत्येक PR में अपने विज़ुअल रिग्रेशन टेस्ट और लाइव वेरिफिकेशन चरण होने चाहिए। मैं चाहता हूँ कि अंतिम परिणाम मूल की तुलना में 100% समान हो - बग सहित
एजेंट काम को स्वतंत्र चरणों में तोड़ता है, एक ऑडिटेबल चेकलिस्ट लिखता है, और प्रत्येक इकाई को तैयार करता है ताकि इसे सुरक्षित रूप से बनाया, सत्यापित और लैंड किया जा सके।
उदाहरण 4: लोग Slack पर जो रिपोर्ट करते हैं उसे ठीक करना
यदि आपने मुझे कभी हमारे किसी मुद्दे या फीडबैक चैनल में Slack पर देखा है, तो आपने शायद ये क्लासिक्स देखे होंगे:
# थ्रेड में पहले से ही पर्याप्त संदर्भ है
/poteto-mode कर दो
/poteto-mode /control-app के साथ इसे रिप्रोड्यूस करो। यदि यह मेन पर रिप्रो होता है, तो इसे ठीक करो और मुझे प्रमाण के रूप में एक वीडियो दिखाओ
मैंने यहाँ जिन कई स्किल्स के बारे में बात की है, वे पहले से ही /poteto-mode द्वारा स्वचालित रूप से उपयोग की जाती हैं, इसलिए अधिकांश समय आप बस /poteto-mode का उपयोग कर सकते हैं और अपने जीवन के साथ आगे बढ़ सकते हैं!
योजना बनाने की कला
प्लान मोड का उपयोग अक्सर अपने आप को यह विश्वास दिलाने के तरीके के रूप में किया जाता है कि एजेंट सही काम करने जा रहा है। लेकिन वास्तविकता यह है कि अमूर्त योजनाएँ आपको केवल प्रगति का भ्रम देती हैं। एक लंबी और विस्तृत योजना यह दिखाती है कि आप और आपके एजेंट बहुत उत्पादक थे, लेकिन इसमें शायद सार का अभाव है।
pstack आपको गहन जाँच, अनुभवजन्य साक्ष्य और कठोर सत्यापन को संयोजित करने के लिए उपकरण देता है। जब आप इस तरह से योजना बनाते हैं, तो एजेंटों के साथ इंजीनियरिंग करना एक जुआ खेलने जैसा महसूस नहीं होता है। यह पूर्वानुमेय और दोहराने योग्य हो जाता है।
https://x.ai/bot/plugin/9717366
पढ़ने के लिए धन्यवाद, और भाग 3 के लिए बने रहें!
