एंथ्रोपिक ने

यह खंड AI एजेंट्स की मुख्य समस्या पर प्रकाश डालता है, जो उनकी सीमित कॉन्टेक्स्ट विंडो है। इस सीमा के कारण, एजेंट्स पिछली कार्रवाइयों को ठीक से याद नहीं रख पाते, जिससे वे लंबे समय तक चलने वाले कामों में कम प्रभावी हो जाते हैं। उदाहरण के तौर पर, जब क्लाउड कोड को कोई बड़ा काम दिया जाता है, तो वह एक ही फीचर को बनाते समय कई बार कॉम्पैक्ट होता है। इस प्रक्रिया में, वह अपने मुख्य काम को भूल जाता है, जिससे कार्य अधूरा रह जाता है और दक्षता प्रभावित होती है।

एंथ्रोपिक ने हाल ही में एक समाधान पेश किया है जो वास्तविक इंजीनियरिंग माहौल में टीमों के काम करने के तरीके पर आधारित है। उन्होंने लंबे कामों में AI की विफलता के दो मुख्य कारण बताए: पहला, पूरे एप्लिकेशन या बड़ी सुविधाओं को एक बार में बनाने की कोशिश करने से मॉडल अपनी कॉन्टेक्स्ट विंडो से बाहर हो जाता है। दूसरा, बार-बार कॉम्पैक्ट होने के बाद, कॉन्टेक्स्ट विंडो आधे-अधूरे फीचर के साथ रीफ्रेश हो जाती है, जिसमें फीचर की प्रगति की कोई जानकारी नहीं रहती, जिससे काम अधूरा रह जाता है।

इस खंड में AI एजेंट्स की दूसरी महत्वपूर्ण समस्या पर चर्चा की गई है, जो उनकी कम टेस्टिंग क्षमताएं हैं। क्लाउड जैसे AI एजेंट्स अक्सर बिना टेस्ट किए गए फीचर्स को भी पूरा मान लेते हैं। यह एक बड़ी चुनौती है क्योंकि AI यह मान लेता है कि फीचर पूरा हो गया है, भले ही वह ठीक से काम न कर रहा हो। इससे गलत सकारात्मक परिणाम मिलते हैं और अंततः एक दोषपूर्ण उत्पाद बन सकता है।

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

इस खंड में एक Next.js प्रोजेक्ट में ऑनलाइन पायथन कंपाइलर बनाने के लक्ष्य के साथ प्रारंभिक सेटअप प्रक्रिया का वर्णन किया गया है। शुरू करने से पहले, init कमांड का उपयोग करके एक Claude.md फ़ाइल बनाई जाती है, जो कोडबेस का दस्तावेज़ होती है और इसमें प्रोजेक्ट का ओवरव्यू और सभी ज़रूरी जानकारी शामिल होती है। इसके बाद, प्रोजेक्ट रूट में फीचर लिस्ट JSON जेनरेट किया जाता है, जिसमें सभी फीचर्स और उनके टेस्टिंग स्टेप्स होते हैं, और सभी टेस्ट को शुरू में 'फेल' के रूप में मार्क किया जाता है ताकि क्लाउड उन्हें टेस्ट करने के लिए मजबूर हो। JSON का उपयोग इसलिए किया जाता है क्योंकि कॉन्टेक्स्ट में JSON फ़ाइलों को मैनेज करना आसान होता है।

चूंकि क्लाउड केवल कोड को टेस्ट कर सकता है, न कि ब्राउज़र पर दिखने वाले इंटरफ़ेस को, इसलिए ब्राउज़र टेस्टिंग के लिए पपेटियर को कनेक्ट किया जाता है। इसके अतिरिक्त, देव सर्वर शुरू करने के लिए एक इनिट स्क्रिप्ट और एक प्रोग्रेस ट्रैकिंग फ़ाइल बनाई जाती है, ताकि सिस्टम प्रोजेक्ट की कंप्लीशन स्टेटस पर नज़र रख सके। गाइडलाइंस के अनुसार, क्लाउड को हर रन के बाद progress.md को अपडेट करना होगा और हर फीचर को लागू करने के बाद टेस्ट करना होगा। सबसे महत्वपूर्ण अभ्यास गिट में कमिट करना है, क्योंकि स्पष्ट लॉग वाले गिट कमिट दिखाते हैं कि क्या पूरा हो गया है और अगर लागू करने में कोई दिक्कत आती है तो वापस लौटने की सुविधा देते हैं।

इस चरण में, क्लाउड को फीचर्स लिस्ट में केवल 'लागू' के रूप में मार्क करने के अलावा कोई बदलाव नहीं करना चाहिए। जब एनवायरनमेंट तैयार हो जाता है, तो कोडिंग पार्ट शुरू होता है, जिसमें फीचर्स JSON से हर फीचर को एक-एक करके लागू किया जाता है। क्लाउड हर टेस्ट किए गए फीचर के बाद विस्तृत कमिट मैसेज भी बनाता है और ज़रूरत पड़ने पर ब्राउज़र भी लॉन्च करता है। एक बार जब यह ऐप के काम करने की पुष्टि कर लेता है, तो यह JSON फ़ील्ड को 'फॉल्स' से 'ट्रू' में अपडेट करता है और progress.md में अब तक के पूरे हुए काम की जानकारी अपडेट करता है।

इस इंक्रीमेंटल अप्रोच का एक बड़ा फायदा यह है कि अगर सेशन खत्म भी हो जाए, तो उपयोगकर्ता वहीं से फिर से शुरू कर सकते हैं जहाँ उन्होंने छोड़ा था। सब कुछ गिट लॉग्स में ट्रैक होता है, इसलिए कोड खराब होने की चिंता करने की ज़रूरत नहीं है। क्लाउड प्रोजेक्ट को गिट लॉग्स और प्रोग्रेस फ़ाइल से समझ सकता है, न कि केवल कोड से, जिससे सेशन को आसानी से फिर से शुरू किया जा सकता है। यह तरीका क्लाउड की बिना ठीक से टेस्ट किए फीचर्स को पूरा मार्क करने की प्रवृत्ति को भी कम करता है, क्योंकि हर इटरेशन यह सुनिश्चित करता है कि ऐप को एंड-टू-एंड वास्तविक टेस्टिंग के साथ बनाया गया है, जिससे उन बग्स की पहचान करने में मदद मिलती है जो केवल कोड से स्पष्ट नहीं होते।

यह खंड इस वर्कफ़्लो की तुलना BMAD विधि से करता है, जिसमें कुछ समानताएं हैं। हालांकि, क्लाउड का वर्कफ़्लो कुछ मायनों में बेहतर माना जाता है, क्योंकि इसमें एजेंट्स को अलग से कॉल नहीं करना पड़ता था और कॉन्टेक्स्ट का इस्तेमाल भी बेहतर था। कई फीचर्स को लागू करने के बाद भी, इसने केवल 84% कॉन्टेक्स्ट का इस्तेमाल किया, जबकि BMAD ने अपनी बड़ी स्टोरीज के कारण दो बार कॉम्पैक्ट किया होता। फिर भी, BMAD एक रेडी-टू-यूज़ फुल सिस्टम है, जबकि यह अभी भी एक विचार है जिसे लागू करने की ज़रूरत है, लेकिन BMAD इससे गिट सिस्टम जैसी कुछ चीज़ें इस्तेमाल कर सकता है।

वीडियो के इस हिस्से में Automater.dev का परिचय दिया गया है, जो लाखों लोगों को AI के साथ बनाना सिखाने के बाद खुद इन वर्कफ़्लो को लागू करना शुरू कर चुका है। कंपनी का दावा है कि वे पहले से कहीं बेहतर उत्पाद तेजी से बना सकते हैं और आपके विचारों को हकीकत में बदलने में मदद करते हैं, चाहे वे ऐप्स हों या वेबसाइट्स। वे खुद को एक टेक्निकल को-पायलट के रूप में प्रस्तुत करते हैं, जो सिखाए गए वर्कफ़्लो को सीधे आपके प्रोजेक्ट पर लागू करते हैं, जिससे कॉन्सेप्ट्स वास्तविक, काम करने वाले सॉल्यूशंस में बदल जाते हैं, बिना किसी हायरिंग या देव टीम को मैनेज करने के सिरदर्द के।

वीडियो का समापन Automater.dev से संपर्क करने के लिए एक कॉल टू एक्शन के साथ होता है, जिसका ईमेल hello@autometer.dev है। स्पीकर दर्शकों को चैनल को सपोर्ट करने और ऐसे वीडियो बनाने में मदद करने के लिए सुपर थैंक्स बटन का उपयोग करने के लिए प्रोत्साहित करता है। अंत में, वह दर्शकों को देखने के लिए धन्यवाद देता है और अगले वीडियो में मिलने की उम्मीद करता है।