पिछले वर्ष में, एजेंटिक इंजीनियरिंग के इर्द-गिर्द चर्चा हार्नेस और लूप्स, फ्लीट्स और सॉफ्टवेयर फैक्ट्रियों की ओर बढ़ गई है। मेरा मानना है कि इंजीनियरों को बाहरी लूप - इन प्रणालियों के लिए जवाबदेही - का स्वामित्व लेना चाहिए। यह तब और भी सच हो जाता है जब Fable और GPT-5.6 जैसे शक्तिशाली मॉडल उपलब्ध हो जाते हैं।
एजेंटों के पास लीवरेज होता है, और लीवरेज दायित्व पैदा करता है। किसी को यह समझाने में सक्षम होना चाहिए कि वास्तव में क्या बदला, यह सुरक्षित क्यों था, और यदि वे गलत हैं तो क्या होगा। अन्यथा, उनके कार्यों को उचित नहीं ठहराया जा सकता है। जिससे यह संभावना नहीं रह जाती कि उनका संगठन पहली बार में उनसे पूछेगा।
और इसलिए मैं तीन शब्दों के बारे में बात करना चाहता हूं। पहला, गुणवत्ता, उन सभी जांचों को संदर्भित करता है जो हम सिस्टम को छोड़ने से पहले स्थापित करते हैं। वे जांचें सबूत पैदा करती हैं, और उस सबूत से हम एक फैसला प्राप्त करते हैं।
दूसरा, फैसला, उस अंतिम निर्णय को संदर्भित करता है जो हम अपने आश्रित सिस्टम में काम प्रवेश करने से पहले लेते हैं: मैं इस सामग्री का लाइन-निर्माता हूं। मैं उस टीम को चलाता हूं जिसका काम मेरे नाम पर भेजा जाता है। मॉडल लाइन लिख सकता है, लेकिन फैसला मेरा है। मेरे निर्णय के बिना मेरी टीम का काम हमारे आश्रित सिस्टम में प्रवेश नहीं करेगा। एक फैसला उत्पादन निर्णय है: क्या हमें भेजना चाहिए, ब्लॉक करना चाहिए, पुनर्निर्देशित करना चाहिए, प्रतिक्रिया को संकीर्ण करना चाहिए, एक गार्डरेल जोड़ना चाहिए, या पूरी तरह से अस्वीकार करना चाहिए?
तीसरा, उत्तरदेयता, उस गारंटी को संदर्भित करता है कि अगर कोई पूछता है, तो मैं समझा सकता हूं कि क्यों।
इसे दूसरे तरीके से कहें तो: हमारा एजेंट (जिसे मैं एक मॉडल और फाइलों, टूल्स, मेमोरी, स्किल्स, सैंडबॉक्स, अनुमतियों, ऑब्जर्वेबिलिटी और रिकवरी के हार्नेस के रूप में परिभाषित करता हूं) वह है जो हमारे लूप को चलाता है (जिसे मैं जांच, कार्यान्वयन, सत्यापन और दोहराव के रूप में परिभाषित करता हूं)। और यही वह चीज है जो हमारी सॉफ्टवेयर फैक्ट्री बनाती है।
मॉडल सिर्फ इंजन है। हार्नेस - टूल्स, मेमोरी, अनुमतियां, सैंडबॉक्स, टेस्ट - वह कार है जिसे आप इसके चारों ओर बनाते हैं ताकि यह सुरक्षित रूप से वास्तविक काम कर सके।
उस हार्नेस को एक दोहराए जाने योग्य चक्र में लपेटें: जांच करें, कार्यान्वित करें, सत्यापित करें, दोहराएं। लूप वह तरीका है जिससे एक अच्छा रन एक ऐसी प्रक्रिया बन जाता है जिस पर आप फिर से चलने के लिए भरोसा कर सकते हैं। उस हार्नेस को एक दोहराए जाने योग्य चक्र में लपेटें - जांच करें, कार्यान्वित करें, सत्यापित करें, दोहराएं - जहां एक स्वतंत्र जांच, न कि मॉडल का अपना कहना, यह तय करता है कि काम कब पूरा हुआ।
अब एक साथ कई लूप चलाएं। एक फैक्ट्री पैमाने पर लूप है - एजेंट अंदर काम भेजते हैं, जबकि मनुष्य सीमा पर निर्णयों का स्वामित्व रखते हैं।
और उस फैक्ट्री के केंद्र में सिस्टम के अंदर और उसके बाहर क्या है, के बीच एक सावधान सीमा है। सिस्टम के अंदर: हम इनपुट एकत्र करते हैं (उत्पाद टीम के इरादे, या पहले भेजे गए काम के ज्ञान, या हाल की घटनाओं, या उपयोगकर्ताओं से विशिष्ट प्रतिक्रिया से)। एजेंट लूप कार्य की जांच करता है, एक योजना लागू करता है, और परिणाम सत्यापित करता है। फिर, सबूत उस सीमा को पार करता है। एक मानव, जो आश्रित सिस्टम का मालिक है, सबूत देखता है और तय करता है कि आगे बढ़ना है या नहीं।
और यही, दोस्तों, वह बदलाव है जिसे हम करने की कोशिश कर रहे हैं। पहले, हमारे एजेंट निष्पादन लूप के आंतरिक लूप कर रहे थे। अब वे आंतरिक निष्पादन लूप चलाते हैं। इंजीनियर बाहरी लूप के मालिक हैं।
सिस्टम के अंदर, वास्तव में केवल एक तरह की चीज है जो हमारे एजेंट कर रहे हैं: क्षमता। कार्यों की जांच करने, योजनाओं को लागू करने, उनके परिणामों का परीक्षण करने और रिपोर्ट करने की क्षमता। यह एक मॉडल की क्षमता है। और जैसा कि हमने कहा है, वह भविष्य पहले से ही यहां है।
सिस्टम के बाहर, एक ही तरह की चीज है: एजेंसी। निर्णय लेने, सत्यापित करने, अनुमोदित करने और स्वामित्व रखने की एजेंसी।
हम अभी भी कोड के बारे में बात कर रहे हैं, आप देखिए। इसे बस एक ऐसी जगह पर रहने और उन लोगों द्वारा किए जाने की जरूरत है जो जानते हैं कि वे क्या कर रहे हैं।
AI कोड की क्षमता अब सीमांत नहीं रह गई है। Sonar 2026 सर्वेक्षण में, हमने टीमों से उनकी प्रतिबद्धताओं के हिस्से के बारे में पूछा जो AI-सहायता प्राप्त थीं। यह छोटा लेकिन गैर-तुच्छ था। और कई उत्तरदाताओं ने कहा कि वे उम्मीद करते हैं कि AI-सहायता प्राप्त प्रतिबद्धताओं का हिस्सा काफी बढ़ जाएगा। Sonar की 2026 स्टेट ऑफ़ कोड रिपोर्ट में पाया गया कि 42% प्रतिबद्ध कोड AI-जनरेटेड या महत्वपूर्ण रूप से AI-सहायता प्राप्त था, जिसमें उस हिस्से के स्थिर होने के बजाय बढ़ते रहने की उम्मीदें थीं।
दूसरे शब्दों में, सृजन सस्ता होता जा रहा है। दुर्लभ संसाधन समीक्षा, सत्यापन, समझ और रखरखाव हैं।
हमने पीढ़ी की गति को नियंत्रण की गति से तेज कर दिया। और इसलिए हमारे पास एक विश्वास-सत्यापन अंतर है। हम जिन बहुत से लोगों से बात करते हैं, वे अभी भी AI कोड के प्रति कुछ हद तक अविश्वास व्यक्त करते हैं। फिर भी उनमें से कम लोग उस अविश्वास को लगातार अपनी सत्यापन प्रक्रियाओं में बनाते हैं।
और यह एक खतरनाक स्थिति है। हमें AI कोड की विश्वसनीयता को सत्यापित करने के सस्ते, स्पष्ट तरीकों की आवश्यकता होगी।
यदि आप GitLab जून 2026 रिपोर्ट देखें, तो आप देखेंगे कि शासन प्रश्न बदल गए हैं। GitLab के जून 2026 AI जवाबदेही शोध से पता चलता है कि समीक्षा और सत्यापन AI का उपयोग करते समय वर्तमान बाधाएं हैं और, अधिक चिंताजनक रूप से, शासन आमतौर पर कोड निर्माण के बाद होता है, जोखिम स्वीकार करने और स्वामित्व पर नियंत्रण खोने के बाद। आज, यह सिर्फ नियंत्रण के बारे में नहीं है। यह इस बारे में है कि हम सिस्टम पर क्या बाधाएं निर्धारित करते हैं। यह इस बारे में है कि हम सबूतों के साथ काम की जांच कैसे करेंगे, और हम टीमों को जवाबदेह कैसे ठहराएंगे। यह इस बारे में है कि AI जीवनचक्र के किस हिस्से का मालिक कौन होगा।
तो इस श्रृंखला में अंतिम अंतर प्रक्रिया और गुणवत्ता के बीच है। गुणवत्ता बैक प्रेशर की अवधारणा है। हम इसका शाब्दिक अर्थ लेते हैं। हम अपने एजेंटों को उतनी स्वायत्तता नहीं देना चाहते जितनी वे संभवतः प्रयोग कर सकते हैं। हम उन्हें पर्याप्त स्वायत्तता देना चाहते हैं ताकि हमारे पास उन्हें रोकने, उन्हें विनियमित करने, उनके काम की जांच करने और अपनी मानवता सुनिश्चित करने के लिए पर्याप्त बैक प्रेशर हो।
सामान्य इंजीनियरिंग बहुत सारे संकेत रखती है जो इंगित करते हैं कि किया जा रहा काम सही काम कर रहा है। टाइप चेक, टेस्ट, हुक, सैंडबॉक्स सीमाएं, ऑडिट लॉग, मॉनिटर। हमारी इंजीनियरिंग प्रणालियां इस तरह के संकेतों से भरी हैं, और वे सिस्टम को ईमानदार रखने के लिए पर्याप्त बैक प्रेशर प्रदान करने के लिए डिज़ाइन की गई हैं।
और इसलिए जब तक हमारे एजेंट इन्हीं संकेतों का उत्सर्जन कर रहे हैं, हम उचित बैक प्रेशर प्रदान करने के लिए अपनी सामान्य इंजीनियरिंग पर भरोसा कर सकते हैं।
अपने सिस्टम पर भरोसा करने का मतलब यह नहीं है कि हम लूप में एक मानव नहीं चाहते हैं। इसका सीधा सा मतलब है कि मानव को आंतरिक लूप में रहने की आवश्यकता नहीं है। हम उन्हें बाधाओं के लूप (हमें कौन से इनपुट, आर्किटेक्चर, निर्देश या अपरिवर्तनीय सेट करने चाहिए?), नमूना लूप (हमें कितना आउटपुट नमूना और समीक्षा करनी चाहिए?), ऑडिट लूप (हमें कौन से सबूत रखने चाहिए और हम कैसे सुनिश्चित करें कि हमारा ऑडिट लॉग प्रभावी है?), और स्वामित्व लूप (हमें उत्पादन सीमा के किस हिस्से का मालिक होना चाहिए) में चाहते हैं।
लेकिन मानव को आंतरिक लूप में रहने की आवश्यकता नहीं है।
एजेंट आपकी समीक्षा से अधिक भेज सकता है।
और दुर्लभ संसाधन आपका अपना मुख्य मानवीय निर्णय है, जो लॉग या टेस्ट जैसे गुणवत्ता संकेतों द्वारा सूचित होता है।
AI जून 2026 रिपोर्ट से पता चलता है कि, प्रयोगात्मक सेटिंग में, घंटे के पैमाने के समय क्षितिज के साथ एजेंटिक प्रतिनिधिमंडल मूल रूप से यहां है। इस वर्ष एजेंटों और काम के भविष्य पर OpenAI का काम इन विचारों के लिए एक बड़ा स्रोत था। इसलिए हमें यह सोचना शुरू करने की आवश्यकता है कि इस स्वामित्व सीमा को कैसे स्थापित किया जाए, क्योंकि हमारे सिस्टम हमारी समीक्षा से अधिक भेजना शुरू कर देते हैं।
और यहीं पर उत्तरदेयता आती है।
क्योंकि लंबे क्षितिज वाले एजेंटों के साथ, घंटे के पैमाने के समय क्षितिज पर लिए गए निर्णय बस वही हैं - निर्णय। और सभी निर्णय रिकॉर्ड नहीं किए जाएंगे। आप उन सभी को इनपुट टोकन तक वापस नहीं खोज सकते। यदि आप केवल यह भरोसा कर रहे हैं कि आपको मिलने वाला आउटपुट हाथ में समस्या के लिए सही विकल्प है, तो उस तक ले जाने वाले निर्णयों की श्रृंखला के पुनर्निर्माण के लिए आपको सैकड़ों या हजारों मानव-घंटे के काम की आवश्यकता होगी, जो असंभव हो जाता है। और इसलिए, फिर से, उत्तरदेयता कुछ ऐसी बन जाती है जो हमारे सिस्टम डिज़ाइन के मूल में होनी चाहिए।
तीन छिपी हुई लागतें
और तीन छिपी हुई लागतें हैं:
संज्ञानात्मक समर्पण ~ AI आपको जो देता है उसे आँख बंद करके स्वीकार करना। जब आप किसी एजेंट को काम सौंपते हैं, तो काम स्वयं एजेंट का काम प्रतीत हो सकता है। लेकिन यह वास्तव में आपका काम है। यह आपकी प्रतिष्ठा है। यह आपकी जिम्मेदारी है। और यह आपका सॉफ्टवेयर है जिसने आउटपुट में दोष झेले हैं। और यह आपका सॉफ्टवेयर है जिसे उस आउटपुट को प्रतिबिंबित करने के लिए बदलने की आवश्यकता है। तो एजेंट का आउटपुट आपका उत्तर बन जाता है। और इसके साथ सारी जवाबदेही आती है। व्हार्टन अध्ययन जिसने इसे एक साथ रखा, जब AI सही है तो आश्वस्त करने वाला है। लेकिन जब यह गलत है, तो खबर अच्छी नहीं है। जब AI गलत था, तब भी लगभग तीन-चौथाई लोगों ने इसे स्वीकार कर लिया, और AI के बिना उनकी तुलना में अधिक आत्मविश्वास महसूस किया।
संज्ञानात्मक ऋण ~ समस्याओं को हल करने के तरीके की आपकी समझ और स्मृति का क्षरण। जब आप किसी एजेंट को काम सौंपते हैं, तो आप सभी विचार कार्य को एजेंट पर स्थानांतरित कर रहे हैं। और जबकि यह सब स्वयं सोचने में समय और ऊर्जा लगती है, एक विशाल कोडबेस पर इसके बारे में सोचने में संसाधन लगते हैं जो तब उपलब्ध नहीं होते जब आप सीखने की अवस्था को चलाने की कोशिश कर रहे होते हैं। तो आपको मिलने वाला आउटपुट अक्सर आपके लिए अप्राप्य होता है। और एजेंटिक योजना का समय क्षितिज जितना लंबा होगा, एजेंट द्वारा उत्पादित कोड और उसकी आपकी समझ के बीच का अंतर उतना ही बड़ा होता जाएगा। अंतर बढ़ता है। ऋण जमा होता है। और सीखने की अवस्था पर चढ़ने की लागत लगभग तेजी से बढ़ती है। Anthropic से एक यादृच्छिक नियंत्रित परीक्षण है जो देख रहा है कि क्या इंजीनियर जो कोड लिखने के लिए AI पर झुकते हैं, वे इसे उतना ही समझते हैं जितना कि इंजीनियर जो इसे स्वयं लिखते हैं। निष्कर्ष निराशाजनक था: एक समझ प्रश्नोत्तरी पर, जिन इंजीनियरों ने AI के माध्यम से काम किया, उन्होंने उन लोगों की तुलना में सत्रह प्रतिशत अंक कम प्राप्त किए, जिन्होंने नहीं किया, 50 प्रतिशत बनाम 67 प्रतिशत।
और फिर ऑर्केस्ट्रेशन टैक्स है ~ अब बहुत सारे एजेंटों को चालू करना आसान है, लेकिन आपका संज्ञानात्मक बैंडविड्थ उसी तरह समानांतर नहीं होता है। अपने एजेंट को सबसे खराब व्यवहारों से दूर करना, एजेंट द्वारा उत्पादित कार्य को छांटना ताकि उनकी पहचान हो सके जिन पर आपके ध्यान की आवश्यकता है, इसे उस काम पर ध्यान केंद्रित करने का निर्देश देना जिसकी आपको पहले परवाह है, इसे चलाने देने से पहले अपनी सबसे महत्वपूर्ण बाधाओं और अपनी सबसे खतरनाक मान्यताओं को सत्यापित करना…
यह सब काम लेता है, और इसे स्वचालित नहीं किया जा सकता है।
मानवीय निर्णय का कोई विकल्प नहीं है।
ब्राउनफील्ड सिस्टम यहां विशेष रूप से खतरनाक हैं, क्योंकि सिस्टम व्यवहार जिसका आपको ऑडिट करना है, वह कोड में नहीं रहता है। यह निशानों में रहता है।
समाधान? अपने वास्तुशिल्प निर्णयों में ध्यान को प्राथमिकता बनाएं। अपनी प्रारंभिक योजना और उससे उभरने वाले काम के बीच युग्मन को कम करने के लिए वर्कट्री, स्कोप और सबूत का उपयोग करें। अनुपयोगी चरणों को हल करने के प्रयास को समय-सीमित करें। और अपने सॉफ्टवेयर में परिवर्तन को सख्ती से ऑप्ट-इन अनुमति बनाएं।
अल्फा, क्षय और स्वाद: ये तीन मुख्य पैटर्न हैं जो डोमेन में करियर और प्रदर्शन को आकार देते हैं।
अल्फा प्रतियोगिता में सर्वोच्च उपलब्धि हासिल करने वाले द्वारा लिया गया अग्रणी हिस्सा है, जब आप अपना सर्वोच्च-मूल्य वाला गेम मूव खेल रहे होते हैं। क्षय स्थापित पैटर्न हैं जो हर कोई दोहराव और दूसरों को देखने (यदि आप चाहें तो पठार) के माध्यम से सीखता है। स्वाद सबसे पहले है जब हम अल्फा में बढ़त या क्षय में बदलाव को महसूस कर सकते हैं। यह कुछ भी होने का कोई सबूत होने से पहले आने वाली चीज़ के बारे में हमारा निर्णय है। पॉल ग्राहम का बिंदु यह है कि जब कोई भी कुछ भी बना सकता है, तो क्या बनाना है यह चुनना अधिक मायने रखता है, और मिशेल हाशिमोटो की परिभाषा परिचालन वाली है: जहां अभी तक कोई उद्देश्य मीट्रिक मौजूद नहीं है, वहां उच्च गुणवत्ता वाले गुणात्मक निर्णय लेना। अब से, स्वाद सब कुछ चलाता है: अल्फा बदलाव स्वाद में बदलाव हैं। और क्षय फीके पड़ जाते हैं क्योंकि हम कुछ अलग स्वाद लेने लगते हैं।
अगला कदम? अपने स्वाद को परिचालित करें। कैसे? इसे एक ऐसा नाम दें जो दर्शाता हो कि आप लिम्बिक से सचेतन की ओर क्या ले जाने की कोशिश कर रहे हैं। आलोचना और उदाहरणों में इसका अभ्यास करें। इसके तर्क को स्पष्ट करें।
और अपने उद्योग में सबसे टिकाऊ प्रतिस्पर्धात्मक लाभ देने वाला कदम चलते रहें। वह क्या है? किनारे को सिर्फ कार्य करने से ऊपर उठाते रहें, इसे सिखाने, इसे व्यवस्थित करने, यह तय करने कि इसे कब किया जाना चाहिए, और परिणाम का स्वामित्व लेने की ओर।
हर कोई एक डेवलपर है, लेकिन हर कोई इंजीनियर नहीं है। इंजीनियरिंग वह है जो एक डेवलपर तब बनता है जब वे एक कार्य अनुशासन को अपनाते हैं जो अधिक सख्त है: पूर्ण और तार्किक रूप से ध्वनि तर्क, बाधाओं और ट्रेड-ऑफ पर विचार, जोखिम और जोखिम की पहचान, और व्यावहारिक जवाबदेही।
भविष्य में, लोग इंजीनियरिंग का प्रशासनिक काम छोड़ देंगे और नई भूमिकाओं को अपनाएंगे जो इंजीनियरिंग के अधिक मांग वाले होने के साथ उभरती हैं। ऐसी भूमिकाएं जो शिल्प की भावना से अलग हो गई हैं लेकिन स्पष्ट करती हैं कि प्रत्येक व्यक्ति क्या करता है। वे होंगे जो प्रोटोटाइप बनाते हैं। वे जो निर्माण करते हैं। वे जो सफाई करते हैं। वे जो बढ़ते हैं। वे जो रखरखाव करते हैं।
मनुष्य दूसरी दिशा में भी सिस्टम के किनारे को पकड़ते हैं। दूसरी दिशा में अल्फा बढ़ाना: यह चुनना कि क्या करने लायक है, उन बाधाओं को परिभाषित करना जिनके भीतर इसे किया जाना चाहिए, यह तय करना कि आगे बढ़ने के लिए सबूत पर्याप्त हैं या नहीं, और परिणाम की देखभाल करना। चाहे वह एक टीम हो या सौ टीमें, यह वह किनारा है जिसे केवल मनुष्य ही पकड़ सकते हैं।
जवाबदेही फैक्ट्री को स्केल करेगी। ध्यान और स्वाद की तरह, जवाबदेही भी उन तीन द्वंद्वों में से एक है जो सब कुछ काम करता है। जवाबदेही के बिना, कोई नियम नहीं हैं। प्रश्नकर्ताओं के साथ कोई बहस नहीं। कोई ट्रेड-ऑफ नहीं। कोई जोखिम नहीं। कोई सुरक्षा जाल नहीं। यदि कोई निर्णय के परिणाम का मालिक नहीं है, तो उच्च एजेंसी केवल अराजकता ला सकती है।
एक किनारे का आधा जीवन एक रिलीज़ है, लेकिन एक हस्ताक्षर का आधा जीवन एक करियर है। एक हस्ताक्षर काम पर आपका नाम है, इस तरह से कि आपको लगता है कि आप जो भेजा गया था उसके पीछे खड़े हो सकते हैं। कौशल आपको लीवरेज देते हैं; जवाबदेही लीवरेज को विश्वास में बदल देती है।
केवल लोग ही चुन सकते हैं। केवल लोग ही परिणाम प्राप्त करते हैं। एजेंटों को एक नीति के भीतर सुरक्षित रूप से चुनने, रूट करने, मर्ज करने और एस्केलेट करने के लिए कहा जा सकता है, लेकिन वे परिणाम प्राप्त नहीं कर सकते।
प्रत्येक कोडबेस शायद किसी प्रकार के जवाबदेही अनुबंध के साथ आना चाहिए जो स्पष्ट रूप से उस चेकलिस्ट को बताता है जिसे परिवर्तन स्वीकार किए जाने पर समझा गया था, वह सबूत जो निर्णय में गया, परिवर्तन के लिए कौन जिम्मेदार था, और परिवर्तन के अवरुद्ध होने के बाद सिस्टम की स्थिति। बिल्कुल इस तरह:
- आपका ध्यान और स्वाद
- आपका सबूत, फैसला और स्वामित्व
- आपका अल्फा, क्षय और स्वाद
उच्च एजेंसी
एक विशिष्ट एजेंटिक वर्कफ़्लो में, उच्च एजेंसी यह जानने की कला है कि कब प्रतिनिधि बनाना है, कब निरीक्षण करना है, कब रुकना है, और कब किसी प्रक्रिया के परिणाम का स्वामित्व लेना है। एजेंसी की सीढ़ी निम्न से उच्च तक चलती है: एक संभावित समस्या को चिह्नित करना, उसकी जांच करना, उसके खिलाफ निष्पादित करना, उसका निदान करना, समाधान प्रस्तावित करना, सुधारों की सिफारिश करना और मुद्दे को हल करना। एजेंसी की सीढ़ी पर एक उच्च पायदान विवेक है: मिल गया, यह ठीक करने लायक नहीं है, आगे बढ़ो।
सॉफ्टवेयर फैक्ट्री को संभाले रखने वाले बारह स्तंभ
ब्राउनफील्ड उन फैक्ट्रियों के लिए सीमा है जो स्केल करने की उम्मीद करती हैं। वे सभी चतुर छोटे नवाचार अभी तक बहुत कुछ महसूस नहीं कर सकते हैं, लेकिन उत्पादन वातावरण बहुत कुछ है। एक पूरी तरह से नई प्रणाली का निर्माण करते समय, पर्याप्त बैक प्रेशर तंत्र की योजना बनाना और लागू करना बहुत आसान है क्योंकि आपका पूर्ण नियंत्रण होता है। हालांकि, जब आप एक विरासत प्रणाली में बुद्धिमान एजेंट जोड़ रहे हैं, तो यह पूरी तरह से अलग मामला है।
विरासत प्रणालियों में उत्पादन व्यवहार की संपूर्णता, ग्राहकों से भविष्य की अपेक्षाएं, प्रवासन इतिहास, रिलीज़ और बजट चक्र अवधि, अनकही मान्यताएं, किनारे के मामले, डेटा विचित्रता, रनबुक प्रक्रियाएं, और वे सभी निशान शामिल हैं जो सिस्टम की देखभाल करने की इच्छा के बिना जमा हुए।
ब्राउनफील्ड का प्रबंधक होने के लिए टिकाऊ इंजीनियरिंग के एक रूप की आवश्यकता होती है। निहित ज्ञान को स्पष्ट बाधाओं में बदलने, इसे टीमों और पीढ़ियों में सुसंगत रखने, उस ज्ञान को परीक्षण प्रक्रियाओं और कार्यात्मक विशिष्टताओं में औपचारिक रूप देने और उस ज्ञान को उद्देश्य सबूत से जोड़ने के लिए काम करना होगा। यह सब विफलता को अधिक सीखने में बदलते हुए। क्योंकि यदि सिस्टम को वह देखभाल नहीं मिलती जो उसे हमेशा मिली है, तो सब कुछ ढह जाएगा।
नया काम वास्तविक काम है
जैसे-जैसे आप स्केल करेंगे, काम और दिलचस्प होता जाएगा। क्योंकि जब बाकी सब कुछ बन जाता है, तो लोग नई चीजें बनाना चाहेंगे। वे अपने शिल्प के माध्यम से विकसित अल्फा और स्वाद को नियोजित करना चाहेंगे ताकि नए लूप डिज़ाइन किए जा सकें जिन्हें सॉफ्टवेयर फैक्ट्री पर ग्राफ्ट किया जा सके। या वे ग्रीनफील्ड सिस्टम बनाना चाहेंगे जो सॉफ्टवेयर फैक्ट्री के सभी ज्ञान को एक सुरुचिपूर्ण, सार्थक, सैद्धांतिक प्रयास में नियोजित करते हैं। वे नए प्रकार के सबूत डिज़ाइन और कार्यान्वित करना चाहेंगे जो नई प्रणालियों के लिए सत्यापन के स्तर तक बढ़ेंगे। वे ब्राउनफील्ड सिस्टम की देखभाल करना चाहेंगे जो अब इतने जटिल हैं कि उन्हें समर्पित ध्यान देने की आवश्यकता है। वे नए बैक-प्रेशर तंत्र डिज़ाइन और प्रबंधित करना चाहेंगे। वे नए एजेंट डिज़ाइन करना चाहेंगे। और वे एजेंसी का निर्माण करना चाहेंगे।
और, जैसा कि वे करते हैं, वे देखेंगे कि यह सब वास्तविक काम है। यह एक अच्छी बात है।
स्वचालन बाधाएं पैदा करता है। उत्पादन में बाधाएं जो स्वामित्व के लायक हैं। क्योंकि स्वचालन हमें औद्योगिक पैमाने पर नियंत्रण देता है। लेकिन औद्योगिक पैमाने से उत्पन्न होने वाली नई बाधाएं भी हैं। बाधा "क्या हम इसे बना सकते हैं?" से "क्या इसका अस्तित्व होना चाहिए, क्या हम इसके लिए जवाब दे सकते हैं?" की ओर बढ़ती है।
मैं जो सुझाव दे रहा हूं वह एजेंटिक इंजीनियरिंग को स्केल करने के लिए एक व्यावहारिक परिचालन मॉडल है। आंतरिक और बाहरी लूप हैं। आंतरिक लूप वह जगह है जहां काम किया जाता है। लूप को यथासंभव स्वतंत्र होने के लिए डिज़ाइन किया गया है। सभी गुणवत्ता आश्वासन और सत्यापन को लूप के अंदर रखें। एक बार जब आप लूप को स्वयं डिज़ाइन और मान्य कर लेते हैं, तो आपके पास करने के लिए केवल एक चीज बचती है कि एक बैक-प्रेशर तंत्र स्थापित करके स्वायत्तता प्रदान करें जो लूप के चलने की दर और इसके संचालन के दायरे को नियंत्रित करने का कार्य करता है। और मनुष्यों को उनके सही स्थान पर, सही निर्णयों पर रखें। समझ को हैंड-ऑफ या रिलीज़ गेट के रूप में न मानें, बल्कि निर्णय के एक बिंदु के रूप में मानें जहां मनुष्य अपनी अंतर्दृष्टि प्रदान करने के लिए तैयार हैं। और फिर हर उस कलाकृति के लिए जो मौजूद है और उत्पादन और नई टीमों और इंजीनियरों को वापस खिलाई जाती है, बेहतर कलाकृतियां छोड़ें।
फैक्ट्री बनाएं; लाइटें जलाए रखें; काम को सुपाठ्य, सत्यापन योग्य, स्वामित्व वाला बनाएं।
एक एजेंट इसे लिख सकता है। लेकिन उपयोगकर्ताओं तक पहुंचने से पहले, किसी को यह समझाना होगा कि इसका अस्तित्व क्यों होना चाहिए, यह उत्पादन का हिस्सा होने के लिए पर्याप्त सुरक्षित क्यों है, और जब यह गलत होगा तो वे क्या करेंगे।
यह बाहरी लूप पर एजेंटिक इंजीनियरिंग है - यह अब काम है।
Pangram ने इस लेख को 100% मानव लिखित के रूप में स्कोर किया है: https://www.pangram.com/history/ae6caccc-b70f-4336-a019-5c3411516871
