सॉफ्टवेयर फैक्ट्रीज: प्रकाश और अंधकार

<code-segment id="0" lang="text">

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

</code-segment>

सॉफ्टवेयर फैक्ट्री का यह विचार बॉब बीमर के 1968 के पेपर, "द इकोनॉमिक्स ऑफ प्रोग्राम प्रोडक्शन" से आया है। आधी सदी से, कई लोगों ने एक ऐसी दुनिया का सपना देखा है जिसमें सॉफ्टवेयर एक दोहराई जाने वाली और मापने योग्य उत्पादन प्रक्रिया (जैसे कारखाने में कार के पुर्जे बनाना) हो, न कि व्यक्तियों का एक अलग-थलग शिल्प। ऐतिहासिक रूप से, यह सपना आम तौर पर (हालांकि सार्वभौमिक रूप से नहीं) विफल रहा है, आंशिक रूप से विचारों को ढालने की कठिनाई के कारण।

लेकिन पिछले दो वर्षों में, चीजें इतनी नाटकीय रूप से बदल गई हैं कि अब पुराने सपने पर एक नई नज़र डालना समझदारी है। और चूंकि कुछ बारीकियों को आसानी से अनदेखा किया जा सकता है, इसलिए यह कुछ हद तक सटीक होना फायदेमंद है कि वास्तव में क्या नया और अलग है, और क्या नए अवसरों के रूप में तैयार किए गए आवर्ती जाल हो सकते हैं।

@dexhorthy, HumanLayer के सह-संस्थापक, ने हाल ही में AI Engineer World's Fair में एक शानदार टॉक दिया जिसका शीर्षक था "हार्नेस इंजीनियरिंग ही काफी नहीं है: सॉफ्टवेयर फैक्ट्रियां क्यों विफल होती हैं।" इस विषय पर यह देखने लायक है।

लूप ही परमाणु है। फैक्ट्री बड़े पैमाने पर लूप है।

संरचना ही सब कुछ है, और यह सब छोटी इकाइयों से शुरू होता है। पूरा स्टैक वास्तव में एक दूसरे के ऊपर स्तरित तीन अवधारणाएं हैं: लूप, हार्नेस और फैक्ट्री।

एक लूप एक एजेंट है जो एक ही काम को बार-बार करता है: संदर्भ इकट्ठा करना, कार्रवाई करना, परिणाम जांचना, और फिर से जाना जब तक कोई शर्त पूरी न हो जाए। यह एजेंटिक काम की सबसे छोटी इकाई है, और इसके ऊपर की हर चीज लूप के ऊपर लूप ही है।

लूप इंजीनियरिंग का उद्देश्य यह है कि आप एजेंट को बारी-बारी से प्रॉम्प्ट करना बंद कर दें और इसके बजाय उस छोटी प्रणाली को डिज़ाइन करें जो आपके लिए इसे प्रॉम्प्ट करती है।

एक हार्नेस एक लूप के चारों ओर की दीवारें हैं: वह सैंडबॉक्स जिसमें वह चलता है, वे उपकरण जिन तक वह पहुंच सकता है, वह मेमोरी जो रनों के बीच बची रहती है, और वे गेट जो तय करते हैं कि "हो गया" का क्या मतलब है। लूप व्यवहार है; हार्नेस वह वातावरण है जिसके अंदर वह व्यवहार चलता है।

एक कच्चे मॉडल को बिना हार्नेस के सौंप दें और वह खुशी-खुशी हमेशा के लिए घूमता रहेगा। हार्नेस वह सब कुछ है जो इसके आसपास है जो इसे चलाने के लिए उपयोगी और सुरक्षित बनाता है।

एक सॉफ्टवेयर फैक्ट्री एक साथ चलने वाले कई हार्नेस्ड लूप हैं, जो काम की एक कतार द्वारा फीड किए जाते हैं और एक समीक्षा गेट के माध्यम से प्रोडक्शन में ड्रेन किए जाते हैं, जिसमें मनुष्य पूरी चीज के मालिक होते हैं। यह एक बड़ा एजेंट नहीं है; यह लूप से बना एक ऑर्ग चार्ट है।

अंतिम प्रतिमान बदलाव कोड लिखने से उस फैक्ट्री के निर्माण और संचालन की ओर बढ़ रहा है जो इसे लिखती है। काम की इकाई एक स्तर ऊपर, लूप, हार्नेस और उनके बीच प्रवाह पर स्थानांतरित हो जाती है, न कि व्यक्तिगत कोड डिफ पर।

लूप → हार्नेस → फैक्ट्री। एक फैक्ट्री एक समझदार एजेंट नहीं है; यह कई हार्नेस्ड लूप हैं जो एक समीक्षा गेट को फीड करते हैं, जिसमें एक मानव बाहरी लूप का मालिक होता है। फैक्ट्री, चित्रित

डेक्स ने जिस सेंट्रल स्लाइड पर सबसे अधिक समय बिताया वह शानदार थी क्योंकि यह एक स्पष्ट वायरिंग आरेख है जो उस चीज़ को दर्शाता है जो अन्यथा एक स्पष्ट लूप है। यहाँ मेरी राय है:

फैक्ट्री एक बंद लूप है: इरादा और प्रोडक्शन सिग्नल एक कतार को फीड करते हैं, हार्नेस बनाता है, स्वचालित जाँचें और समीक्षा गेट इसे जांचते हैं, डिप्लॉय इसे शिप करता है, मॉनिटरिंग प्रोड को वापस सिग्नल में बदल देती है। इरादा इंजीनियरिंग लीडरशिप की दृष्टि से और सीधे इंजीनियरों से, किए जाने वाले कामों की कतार में प्रवाहित होता है। घटनाओं और उपयोगकर्ता अनुरोधों द्वारा संचालित सिग्नल उसी कतार को चलाते हैं।

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

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

हम इसे "डार्क" क्यों कहते हैं

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

यह छवि विनिर्माण से उधार ली गई है। इसकी उत्पत्ति डिजिटल के बजाय भौतिक है, जो उन सुविधाओं में निहित है जहां रोशनी बंद कर दी जाती है और काम रोबोट द्वारा किया जाता है। जापान में FANUC 2001 से इस तरह की लाइट्स-आउट फैक्ट्री चला रहा है; Xiaomi ने 2024 में अपनी स्वयं की एक भारी स्वचालित डार्क फैक्ट्री खोली। इनमें जो समानता है वह एक उत्पाद है जिसे बिना किसी एक मानव द्वारा पढ़े इकट्ठा और शिप किया जाता है। "डार्क" तब आता है जब पढ़ने का वह कार्य प्रक्रिया से हटा दिया जाता है।

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

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

हार्नेस इंजीनियरिंग ही काफी नहीं है

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

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

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

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

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

डार्क फैक्ट्री वास्तव में जहां चमकती है, वह है टेस्ट को ग्रीन रखते हुए बेदाग कोड को जलाने की अपनी क्षमता में। अंतिम लेखा-जोखा, जब आता है, एक नाटकीय "सब कुछ बिगड़ जाता है" पल नहीं होगा। यह शांत और देर से होगा।

डार्क और लिट एक ही पाइपलाइन हैं जिनमें रोशनी अलग-अलग जगहों पर है। लिट संस्करण केवल अंत में समीक्षा को फिर से नहीं जोड़ता है - यह मानव निर्णय को डिज़ाइन और आर्किटेक्चर में भी अपस्ट्रीम ले जाता है। बाधा कभी जनरेशन नहीं थी

सॉफ्टवेयर फैक्ट्री में मूलभूत बाधा यह नहीं है कि हम कितना कोड निकाल सकते हैं: यह है कि हम इसे कितनी जल्दी सत्यापित कर सकते हैं।

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

क्योंकि असीमित जनरेशन क्षमता मानव ध्यान के सीमित, गैर-स्केलिंग संसाधन के साथ निरंतर तनाव में है, मूल समस्या सस्ती जनरेशन और बाध्य समीक्षा के बीच का अंतर है। फ़नल को देखें: जब तक सत्यापन का प्रतिनिधित्व करने वाली गर्दन चौड़ी नहीं होती, यह बैक अप करने वाला है। जैसा कि डेक्स बताते हैं, अकेले वॉल्यूम समस्या नहीं है: हम वास्तव में जिस चीज़ से पीड़ित हैं, वह खराब PRs की अधिकता है। जब आपके पास विश्वसनीय गेट के बिना उच्च मात्रा होती है, तो निर्मित दोष अपरिहार्य हैं। यह फिर से बैक प्रेशर है: स्वायत्तता उससे आगे नहीं बढ़ सकती जिसे सस्ते और विश्वसनीय रूप से सत्यापित किया जा सके।

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

जनरेशन एक चौड़ा मुंह है; सत्यापन संकरी गर्दन है। मुंह को तेज करना केवल गर्दन पर ढेर को गहरा करता है।

रोशनी वापस चालू करना

एक लिट फैक्ट्री वही पाइपलाइन है जिसमें रोशनी उस जगह पर छोड़ दी जाती है जहां निर्णय रहता है। एजेंट अभी भी अधिकांश निर्माण करते हैं, लेकिन एक मानव शिप होने से पहले जो निकलता है उसे पढ़ता है, और रोशनी वहां रहती है जहां एक गलत कॉल महंगी है।

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

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

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

उस सुरक्षा जाल को मॉडल के बाहर रहना होगा, क्योंकि मॉडल इसे प्रदान नहीं करेगा। सबसे सक्षम महसूस करने वाले कोडिंग एजेंट, जिनमें Claude Code और Codex शामिल हैं, अपने स्वयं के हार्नेस और टूल के खिलाफ रीइन्फोर्समेंट-प्रशिक्षित होते हैं: व्यापार के सभी उपकरणों और मुहावरों में धाराप्रवाह, लेकिन दीर्घकालिक रखरखाव जैसी चीजों में नहीं। जिस जानबूझकर की गई आर्किटेक्चर के बारे में हमने हमेशा बात की है, वह वह उपकरण है जो उस ऋण को पकड़ता है, और हम जो निवेश करते हैं, वह हमारी स्वायत्तता को वापस खरीद रहा है।

इसे सुरक्षित बुनियादी ढांचे के साथ रखें, और कुछ तंग, कम जोखिम वाले लूप हैं जिन्हें आप बिना देखरेख के चला सकते हैं। हॉर्टी ने हाल ही में एक पोस्ट में एक का वर्णन किया: एक रात्रिकालीन GitHub Actions क्रॉन जो बिल्कुल एक एंटी-पैटर्न को ठीक करता है, एक लिंट उल्लंघन या एक अनावश्यक रूप से वैकल्पिक प्रोप, कमिट करता है, और अपने आप एक छोटा पुल रिक्वेस्ट खोलता है, ताकि टीम थोड़े बेहतर कोडबेस और पढ़ने के लिए पर्याप्त छोटे डिफ के साथ जागे। लेकिन पर्याप्त उच्च दांव वाले लूप के लिए, आप एक टूटी हुई ऑथ सिस्टम, बिलिंग इंजन या पब्लिक API कॉन्ट्रैक्ट के साथ जागने का जोखिम नहीं उठाना चाहेंगे। वहाँ रोशनी रखें, और भरोसा रखें कि निर्णय और सिस्टम का वास्तविक कार्य ज्ञान रखने वाला व्यक्ति गलती को पकड़ लेगा।

एक लूप को डार्क क्या अर्जित करता है

यह नियम लागू होता है चाहे आप इसे बैक प्रेशर, सत्यापन या लाइट स्विच कहें।

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

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

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

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

लूप, ग्राफ या स्टेट मशीन?

आपको "2 मिनट में स्टेट मशीन" by @DavidKPiano पढ़ना चाहिए

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

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

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

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

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

उस ग्राफ की वास्तविक अपील, निश्चित रूप से, यह है कि यह एक आरेख के रूप में खींचा गया बैक प्रेशर है। आप एजेंट की कुछ स्वतंत्रता छोड़ देते हैं और बदले में अनिवार्य जाँच और सुपाठ्य विफलता बिंदु प्राप्त करते हैं, ताकि जब कोई रन विफल हो जाए तो आप उस नोड को इंगित कर सकें जिसने इसे मारा। यह वही प्रवृत्ति है जो डेक्स की कठोर पंक्ति के पीछे है कि अधिकांश तथाकथित एजेंट बिल्कुल भी बहुत एजेंटिक नहीं हैं, "ज्यादातर नियतात्मक कोड, सही बिंदुओं पर LLM चरणों के साथ छिड़का हुआ।" और यह सिर्फ एक कलाकृति नहीं है कि लोग अभी कैसे चीजों का निर्माण कर रहे हैं: आप पैटर्न को LangGraph और LlamaIndex Workflows में, जैरी लियू के हाइब्रिड workflow-graph-over-agents में एक बाहरी लूप के साथ देख सकते हैं जो चलने पर ग्राफ के कुछ हिस्सों को बढ़ाता है, और डेविड खोरशीद के अनुस्मारक में कि यह वास्तव में सिर्फ स्टेट मशीन और अभिनेता मॉडल है जो नए कपड़ों में दिखाई दे रहे हैं।

एक स्पष्टीकरण, क्योंकि इस शब्द का बुरी तरह से अधिभार है: जब मैं इसे लगातार एक ग्राफ कह रहा हूं, तो मेरा मतलब नॉलेज ग्राफ नहीं है। मेरा मतलब काम के प्रवाह के एक पूर्वनिर्धारित निर्देशित ग्राफ से है, जिसमें सशर्त किनारे और सब कुछ शामिल है, जो लूप को एक ऐसा आकार देता है जिस पर आप वास्तव में भरोसा कर सकते हैं।

मानव वास्तव में कहाँ जाता है

ध्यान दें कि व्यक्ति ने कभी फैक्ट्री नहीं छोड़ी। वे स्थानांतरित हो गए।

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

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

रोबोट अंधेरे में काम करने में ठीक हैं, लेकिन मनुष्यों को यह देखने की जरूरत है कि वे क्या कर रहे हैं। यदि फैक्ट्री फ्लोर पर सब कुछ अंधेरा है, और आप कुछ भी नहीं देख सकते हैं, और आपको लाइट स्विच भी नहीं मिल रहा है, तो वहीं खतरा है।

Pangram ने स्कोर किया इस लेख को 100% मानव द्वारा लिखित।