एजेंट द्वारा उत्पादित कोड को फिर से नहीं ठीक करें, उस सिस्टम को ठीक करें जो कोड उत्पादित करता है।लेखक, स्रोत: InfoQ
अगर कोई डेवलपर एजेंट का उपयोग कैसे भी नहीं कर पा रहा है, तो समस्या डेवलपर में नहीं, बल्कि कंपनी में है, जिसने एजेंट के लिए काम करने वाली कोई प्रणाली तैयार नहीं की है।
बहुत से उद्यम जो AI रूपांतरण का दावा करते हैं, वे अभी भी विकासकों के लिए Cursor, Claude Code आदि उपकरण खरीदने, कुछ प्रशिक्षण आयोजित करने और फिर सभी को स्वयं अनुसंधान करने के लिए छोड़ देने तक सीमित हैं। यदि अंततः Agent का प्रदर्शन खराब है, तो जिम्मेदारी फिर से उपयोगकर्ता पर आ जाती है।
लेकिन DevOps शब्द के लेखक पैट्रिक डीबुआइस का मानना है: "डेवलपर्स को एक महत्वपूर्ण मानसिक परिवर्तन करना होगा: जब एजेंट आपकी उम्मीद के अनुसार कार्य पूरा नहीं करता है, तो उसके द्वारा उत्पन्न कोड को बदलने के बजाय, पूरे सिस्टम को सुधारें, और केवल Prompt को नहीं।"
डीबोइस के अनुसार, यह बदलाव निश्चित प्रणालियों से अनिश्चित, संभाव्य प्रणालियों और वर्कफ्लो में सॉफ्टवेयर इंजीनियरिंग के स्थानांतरण के दौरान अपरिहार्य है। यह केवल तकनीकी बदलाव तक सीमित नहीं है, बल्कि डेवलपर्स, टीमों और पूरे संगठन के काम करने के तरीके को भी पुनर्गठित करेगा। लेकिन यह बदलाव केवल एक इंजीनियर द्वारा या एकल टीम स्तर पर ही सीमित नहीं हो सकता। यह DevOps की तरह है, जो केवल उसके स्केल पर लागू होने पर ही वास्तविक रूप से सफल होता है।
समस्या का मुख्य बिंदु केवल यह नहीं है कि डेवलपर्स Agent का उपयोग कर पाएंगे या नहीं, बल्कि यह है कि कंपनी Agent के आसपास टीमों, प्लेटफॉर्म और सहयोग के तरीकों को पुनः संगठित कर सकती है या नहीं।
मुख्य बिंदु निम्नलिखित हैं:
- एजेंट द्वारा उत्पादित कोड को फिर से नहीं ठीक करें, उस सिस्टम को ठीक करें जो कोड उत्पादित करता है।
- अगर आपकी टीम में कोई अभी भी "YOLO" तरीके से वाइब कोडिंग कर रहा है, तो आपको तुरंत इसे रोकना चाहिए। इंजीनियरिंग प्रथाएं न केवल आपके सिस्टम को बनाए रखने के लिए महत्वपूर्ण हैं, बल्कि एजेंट के स्वयं के लगातार सुधार के लिए भी महत्वपूर्ण हैं।
- डिम फैक्ट्री संभवतः पूरी तरह अंधेरी नहीं है, बल्कि थोड़ी सी मामूली रोशनी बनाए रखती है (dim factory), जिसका अर्थ है कि आपको यह तय करना होगा कि किस फ़ंक्शन के लिए कितना जोखिम स्वीकार करना है, क्योंकि सभी फ़ंक्शन पूरी तरह स्वायत्त होने के लिए उपयुक्त नहीं हैं।
- जो व्यक्ति AI का अद्भुत उपयोग कर सके, मजबूत इंजीनियरिंग कौशल रखता हो, और साझा करने तथा सहयोग करने को तैयार हो, वही आपकी तलाश का व्यक्ति है।
- आपका व्यापारिक लाभ, उन संचित ज्ञानों को पकड़ना है, जिन्हें आप अभी skill, Context और यहां तक कि Harness प्रतिबंधों में सम्मिलित कर रहे हैं।
क्या क्लॉड कोड के साथ डेवलपर्स को सुसज्जित करने से संगठन बदल जाएगा?
2009 में, कई लोगों ने मुझे बताया कि निरंतर डिलीवरी का विचार पागलपन है।
टिप्पणी: 2009 में, उद्योग सामान्य रूप से कुछ महीनों में एक बड़ा संस्करण लॉन्च करने के मॉडल का उपयोग करता था, और लोग मानते थे कि जितनी अधिक प्रकाशन आवृत्ति होगी, उतना ही अधिक जोखिम होगा। इसके अलावा, विकास और संचालन के बीच कठोर बाधाएँ थीं, कंटेनर और क्लाउड जैसी स्वचालित बुनियादी ढांचे अभी परिपक्व नहीं हुए थे, और मानकीकृत pipeline उपकरणों की कमी थी। साथ ही, पारंपरिक परीक्षण और परिवर्तन अनुमोदन प्रक्रियाएँ लॉन्च से पहले सभी दोषों को दूर करने पर ध्यान केंद्रित करती थीं, जबकि सतत डिलीवरी ने उच्च आवृत्ति, आंशिक, और किसी भी समय लॉन्च करने का विचार पेश किया, जिसने सॉफ़्टवेयर लॉन्च के जोखिम और प्रक्रिया नियंत्रण के बारे में सामान्य समझ को उलट दिया। इसलिए, अधिकांश कंपनियों के लिए, यह लगभग कल्पना से परे और बहुत पागलपन लगता था।
और अब, डार्क फैक्ट्री को फिर से ठीक वही विरोध का सामना करना पड़ रहा है।
Translator's note: Dark Factory refers to an AI-driven autonomous software production model where humans input only the SPEC, and AI autonomously completes coding, testing, and deployment without requiring manual line-by-line code review, differing from traditional software factories that still require significant engineer involvement in the process.
मैंने विभिन्न मौकों पर एक ही बात बार-बार सुनी है: "यह चीज हमारे पास काम नहीं करती।" लेकिन इस बात का वास्तविक संदेश तकनीकी असमर्थता नहीं है, बल्कि "हम तैयार नहीं हैं" है। वे इस चीज को लागू करना नहीं चाहते, बल्कि अभी पूरे संगठन की संरचना इस मॉडल का समर्थन नहीं कर सकती।
अब बहुत से लोग एजेंट को चक्रीय रूप से कैसे अनुकूलित करें, हार्नेस कैसे बनाएं, इस बारे में बात कर रहे हैं, ये सब बहुत अच्छा है। लेकिन मैं कहना चाहता हूं कि हम सभी अंततः उस तकनीकी स्तर पर पहुंच जाएंगे, एक दिन ये किसी प्रकार की मानक वस्तु बन जाएंगी, या किसी अग्रणी प्रयोगशाला द्वारा सेवा के रूप में प्रदान कर दी जाएंगी। उस दिन, तकनीकी बाधाएं समाप्त हो जाएंगी। वास्तविक भिन्नता, आपके संगठन के पास है कि वह इसके चारों ओर सहयोग के तरीकों को कैसे पुनर्गठित करता है।
तो मैं मान रहा हूँ कि हम सभी अंधे फैक्टरी की ओर बढ़ रहे हैं। मैंने Tessl और अन्य कंपनियों में देखा है कि जब लोग इन तकनीकों को अपनाना शुरू करते हैं, तो सहयोग का गतिशील पहलू पूरी तरह से बदल जाता है। अगर आप कॉनवे के नियम से परिचित हैं, तो आप जानते होंगे कि संगठन की व्यवस्था और उपकरणों के बीच एक पारस्परिक आकार देने का संबंध होता है—आप लोगों को कैसे व्यवस्थित करते हैं, वही सिस्टम बनता है। लेकिन आज मैं आपको यह नहीं बताना चाहता कि आप अपने Agent को कैसे बेहतर बनाएँ, मैं यह बताना चाहता हूँ कि यह आपकी टीम के गतिशील पहलू, आपके प्लेटफ़ॉर्म और पूरे संगठन को कैसे बदलता है।
मुझे लगता है कि आज के यहां बैठे अधिकांश लोग किसी टीम के साथ काम कर रहे हैं, न कि अकेले, टीम के साथ सहयोग करना और एक व्यक्ति का Claude Code के सामने टाइप करना पूरी तरह से अलग बातें हैं।
अब सब एक बात कहने लगे हैं: डेवलपर्स अंततः एक निर्देशक या एजेंट के ऑर्केस्ट्रेटर बन जाएंगे। मुझे लगता है कि यह बात सही है, यह वास्तव में हमारी ओर जा रही प्रक्रिया है। हम एजेंट के प्रबंधक की तरह अधिक से अधिक बनते जा रहे हैं, और हमें एजेंट के साथ संबंधों को संभालना होगा।
लेकिन समस्या यह है कि मैंने कई डेवलपर्स को निजी रूप से कहते सुना है: हमने शुरुआत इसलिए नहीं की थी कि हम इस तरह का काम करें, हमने कभी सोचा नहीं था कि हमें प्रॉम्प्ट को ऑप्टिमाइज़ करने और बेहतर SPEC लिखने में बहुत समय बिताना पड़ेगा। हम इंजीनियर हैं, हम तकनीक पर काम करते हैं, इससे हमें एक पहचान का संघर्ष महसूस होता है, और हम खुद से लगातार पूछते रहते हैं: क्या यही मेरा वास्तविक भूमिका है?
बाद में "कॉन्टेक्स्ट इंजीनियरिंग" नाम की एक अवधारणा उभरी, जो डेवलपर्स के लिए एक राहत का साधन बनी। इसका मतलब है कि यह केवल प्रॉम्प्ट कॉल करने के बारे में नहीं है, आपको प्रॉम्प्ट का परीक्षण, मूल्यांकन, वितरण और अनुकूलन भी करना होगा, इसलिए इसमें वास्तव में कुछ इंजीनियरिंग का स्वाद है। लेकिन सच बताऊं तो, कई डेवलपर्स अभी भी महसूस करते हैं कि केवल प्रॉम्प्ट और SPEC के साथ काम करना खालीपन भरा है, और वे महसूस करते हैं कि वे इंजीनियर से "प्रॉम्प्ट प्रबंधक" बन गए हैं।
लेकिन मैंने व्यावहारिक रूप से एक दिलचस्प मोड़ देखा है। जब हम हैरन्स, लूप्स शुरू करने लगे और पूरे संगठन को अधिक स्वायत्तता की ओर ले गए, तो एक पूरी नई तकनीकी पथ खुल गया। अचानक, डेवलपर्स को एजेंट के लिए टूल्स बनाने में मदद करनी पड़ने लगी, जिससे कई लोगों को फिर से प्रेरित किया गया। जो डेवलपर्स पहले सोचते थे कि "यह मेरा काम नहीं है", वे अचानक उत्साहित हो उठे। उन्होंने कहा, हाँ, हम यह कर सकते हैं! हमारे पास यह ज्ञान है! हम प्रोग्रामिंग के माध्यम से इस सिस्टम को बेहतर बना सकते हैं। इसलिए यह दिलचस्प है कि जब हम "अमूर्तीकरण, अमूर्तीकरण, और फिर अमूर्तीकरण" की बात करते रहे, तो "कला" का महसूस करना एक अलग स्थान पर फिर से उभरा, जहाँ अधिक कठोर इंजीनियरिंग कार्यों के लिए नया स्थान मिला।
कोड को नहीं, बल्कि कोड उत्पन्न करने वाले सिस्टम को ठीक करें।
लोग अक्सर मुझसे पूछते हैं: संदेहवादियों को कैसे संभालें? मेरा जवाब हमेशा यही होता है: ये लोग वास्तव में आपके खजाने हैं। क्योंकि उनके मन में बहुत सारी अनछुई हुई जानकारी और निर्णय क्षमता होती है, जिसे आपको एजेंट में भरना होगा। आप उनसे कह सकते हैं: "कृपया अपनी सारी जानकारी और आलोचना प्रस्तुत करें", इससे एजेंट और हारनेस बेहतर बनेंगे। अगर आपको कोई ऐसा व्यक्ति मिल जाए जो लगातार शिकायत करता है कि "इसके द्वारा उत्पन्न कोड की गुणवत्ता बहुत कम है", तो उन्हें ईंधन के रूप में प्रयोग करें, और इस क्रोध और संदेह को प्रणाली में सुधार की शक्ति में बदल दें।
अब मैं कंपनी के डेवलपर्स को एक सुझाव देना चाहूंगा: एजेंट द्वारा उत्पादित कोड को ठीक करने के बजाय, उस कोड को उत्पादित करने वाली प्रणाली को ठीक करें। जैसे कि कुछ साल पहले किसी ने कहा था: उस चीज़ को न बनाएं, बल्कि उस चीज़ को बनाने वाली चीज़ को बनाएं। हम अभी इसी अमूर्त स्तर पर हैं, Context, Harness, और लूप के माध्यम से “चीज़ें बनाने वाली चीज़” को बना रहे हैं। जो लोग अभी भी “Human in the Loop”、ऑटो-कंप्लीशन, और Prompt कॉल के स्तर पर हैं, उन्हें अपने आप को सिस्टम-थिंकिंग के स्तर पर उठाने के बारे में सोचना चाहिए।
हमें वास्तव में इंसानी हस्तक्षेप की संख्या को कम करने के लिए अच्छी इंजीनियरिंग प्रथाओं का उपयोग करना चाहिए। शुरुआत में, सभी को "vibe coding" बहुत अच्छा लगता था—एक Prompt डालें, एक परिणाम प्राप्त करें, और आगे बढ़ें। लेकिन अब हमें अधिक स्पष्टता हो रही है कि हम केवल Agent को Prompt के माध्यम से निर्देश नहीं दे रहे हैं, हम वास्तव में कह रहे हैं: कृपया परीक्षण के साथ कोड लिखें, कृपया दस्तावेज़ों को अपडेट करें, कृपया कोडिंग मानकों का पालन करें। जो बातें हम पहले अच्छे इंजीनियर से कहते थे, वे सभी अब Agent के प्रति सीधे-सीधे लागू हो रही हैं। यदि आपकी टीम में कोई अभी भी "YOLO (पहले काम करा लो)" के तरीके से vibe coding कर रहा है, तो आपको तुरंत इसे रोकना चाहिए। इंजीनियरिंग प्रथाएँ न केवल आपके सिस्टम को बनाए रखने के लिए महत्वपूर्ण हैं, बल्कि Agent के स्वयं के सतत सुधार के लिए भी महत्वपूर्ण हैं।
मैं कुछ आगे बढ़ चुकी टीमों में एक नया अनुष्ठान देखने लगा हूँ, जो अभी भी प्लानिंग और रिव्यू मीटिंग्स करती हैं, लेकिन चर्चा का विषय पूरी तरह से बदल गया है। रिव्यू मीटिंग में अब "कोड में क्या समस्या थी?" के बजाय, "सिस्टम में क्या समस्या थी?" पूछा जाता है।
प्लानिंग मीटिंग में मैंने एक दिलचस्प विभाजन भी देखा। जिन कार्यों की परिभाषा बहुत स्पष्ट है और जिनकी सीमाएँ पर्याप्त रूप से स्पष्ट हैं, उन्हें सीधे एजेंट को सौंपा जा सकता है, क्योंकि हैरनेस बेहतर होता जा रहा है और वे इस तरह के स्पष्ट कार्यों को समझ सकते हैं। जबकि जिन कार्यों की सीमाएँ अस्पष्ट हैं और जिनके लिए चर्चा की आवश्यकता होती है, उन्हें अभी भी मनुष्यों के लिए छोड़ दिया गया है। इसलिए प्लानिंग मीटिंग में एक प्राकृतिक विभाजन उत्पन्न हुआ: ये कार्ड सीधे एजेंट पाइपलाइन से होकर जाएँगे, और उन कार्डों पर हम चर्चा करेंगे।
डेवलपर्स आमतौर पर एक सीखने का चक्र अनुभव करते हैं: पहले प्रॉम्प्ट सीखते हैं, फिर बेहतर SPEC, फिर Context, Harness, और चक्र, और पूरा उद्योग इस चक्र में आगे बढ़ रहा है। लेकिन टीम लीड इस प्रक्रिया के लिए गति और सीमाएँ निर्धारित कर सकते हैं, जैसे कि उन्हें कहना: “अब प्रॉम्प्ट बदलना बंद करो, Context को पुन:उपयोगयोग्य बनाओ।” “ठीक है, यह चरण पूरा हो गया, अब हम अगले चरण पर जाते हैं।” टीम लीड का मूल्य इसी गति को सेट करने में है; अगर आप सिर्फ यह कह दें कि “खुद ही समझो,” तो यह काम नहीं करेगा।
एक अन्य प्रभाव यह है: जब आपकी टीम की उत्पादकता अचानक बढ़ने लगती है, तो नीचे के लोग, जैसे GTM (Go to Market) करने वाले, उसके साथ नहीं बढ़ पाते, यहां तक कि उपयोगकर्ता भी नहीं बढ़ पाते। इसलिए आपको उनकी मदद के लिए स्वचालन का उपयोग करना होगा, और आपका फ्रेमवर्क केवल कोडिंग तक ही सीमित नहीं होना चाहिए, बल्कि उनकी ओर विस्तारित होना चाहिए। इसी तरह, ऊपर की आवश्यकताओं के प्रवाह के लिए भी ऐसा ही है; अगर आवश्यकताएं पर्याप्त तेजी से नहीं आतीं, तो टीम फंस जाएगी, और इन सभी पड़ावों को इस नए कार्य प्रवाह में शामिल किया जाना चाहिए।
अब बाजार में कई सूचक हैं, जैसे टोकन खर्च आदि। लेकिन मैं धीरे-धीरे दो ऐसे सूचकों पर विश्वास करने लगा हूँ जो वास्तविक उत्पादकता को मापते हैं। पहला: आप गिनें कि एजेंट को एक काम सही तरीके से करने के लिए आपको कितनी बार मानव हस्तक्षेप की आवश्यकता होती है? यह संख्या लगातार कम होनी चाहिए। आपका हैरन्स जितना बेहतर होगा, कॉन्टेक्स्ट जितना बेहतर होगा, और मार्गदर्शन जितना स्पष्ट होगा, यह संख्या उतनी ही कम होगी। दूसरा सूचक यह है कि जब आप एकल कार्य से साझा प्रणाली पर स्थानांतरित होते हैं, तो एक गुणक प्रभाव होता है। जब आप किसी एक जगह कुछ सुधारते हैं, तो सभी को लाभ मिलता है। यह इसका मतलब नहीं है कि एक व्यक्ति की दक्षता दस गुना हो जाती है, बल्कि एजेंट प्रणाली में किया गया एक सुधार सभी पर गुणक प्रभाव डालता है।
आप एक रिपॉजिटरी में, एक छोटी टीम के भीतर शुरुआत कर सकते हैं, Context को साझा कर सकते हैं और Harness को एक साथ सुधार सकते हैं। लेकिन आप जो वास्तव में करना चाहते हैं, वह है इस प्रभाव को पूरे संगठन तक विस्तारित करना। इस समय, हमें प्लेटफॉर्म टीम के बारे में बात करनी होगी।
हर टीम के लिए अलग हैरन न बनाएं
प्लेटफॉर्म टीम एक पारंपरिक साझा संगठन है, और अब वे संभवतः बुनियादी ढांचे, क्लाउड सेवाओं, MCP गेटवे आदि पर काम कर रही हैं, और एजेंट पर खास ध्यान नहीं दे रही हैं। लेकिन कई नए चीजें उभर रही हैं, जिन्हें उन्हें संभालना होगा, जैसे कौशल रजिस्ट्री (जिसमें हर कोई अपने कोने में एक ही कौशल का आविष्कार न करे), Context का मूल्यांकन प्रणाली (यह Context वास्तव में कारगर है? क्या इसका मापन किया जा सकता है?), और कोडिंग एजेंट के लिए विशिष्ट सुरक्षा और पहचान प्रबंधन (एजेंट किसकी पहचान से कोड सबमिट करता है? अधिकार सीमाएँ कहाँ हैं?)। इसलिए, प्लेटफॉर्म टीम को इस नए केंद्रीय भूमिका में विकसित होने में मदद की आवश्यकता है।
यह बहुत मुश्किल है, आपको इसे आगे बढ़ाने के लिए एक स्पष्ट मालिक की आवश्यकता होती है। लेकिन यह कौन होना चाहिए? प्लेटफॉर्म टीम? डेवलपर एक्सपीरियंस टीम? पहली टीम आमतौर पर डेवलपमेंट-लेवल की चीजों को नहीं छूती, और दूसरी टीम इंफ्रास्ट्रक्चर को ज्यादा नहीं छूती, इसलिए कुछ संयोजन की आवश्यकता होती है, लेकिन यह संयोजन स्वयं नहीं होता। आपको सुनिश्चित करना होगा कि इस केंद्रीकृत कार्य को आगे बढ़ाने के लिए एक जिम्मेदार हो, अन्यथा आपकी टीम केवल अपने अपने क्षेत्र में ही व्यस्त रहेगी, और "Paved Road (पवड़ा सड़क)" कभी नहीं बनेगी।
हमें हर टीम को अलग-अलग प्रमाणीकरण सिस्टम के लिए अलग-अलग इंटीग्रेशन तरीके बनाने क्यों करने चाहिए? यह एक शेयर्ड कॉम्पोनेंट है, इसे रजिस्ट्री में डाला जाना चाहिए। हम सभी को अपने-अपने हैरनेस क्यों बनाने चाहिए? अगर हम सभी एक ही linter और एक ही सुरक्षा स्कैनिंग टूल्स का उपयोग करें, तो यह एक पुन:उपयोग योग्य कॉम्पोनेंट हो जाएगा। मुझे लगता है कि यह पिछले समय में क्लाउड इंफ्रास्ट्रक्चर की तरह होगा, जो धीरे-धीरे प्लेटफॉर्म रजिस्ट्री में केंद्रित हो जाएगा।
लेकिन समस्या यह है कि अगर कोई भी इस केंद्रीय भंडार में बिना किसी नियंत्रण के चीजें डाल सकता है, तो यह जल्दी ही अनियंत्रित रूप धारण कर लेगा (becomes a sprawl)। उदाहरण के लिए, एक skill अपलोड कर दिया गया, तो इसकी देखभाल कौन करेगा? कोई और एक समान skill का fork कर देता है, तो मुझे कौन सा चुनना चाहिए? इसलिए, किसी विशेष क्षेत्र के लिए किसी को स्पष्ट रूप से मालिकाना हक़ होना चाहिए, जो सुनिश्चित करे कि यह परीक्षणयोग्य है, मॉड्यूलर है, और दूसरे इसके आधार पर Context या Harness के सुरक्षा स्कैनिंग हिस्से को विस्तारित कर सकते हैं। आपको इसे संगठन के भीतर बेकाबू तरीके से पास करने के बजाय, केंद्रीकृत तरीके से करना होगा।
सहमति बनाना मुश्किल होता है। यह tabs और spaces के विवाद के जितना प्रसिद्ध नहीं है, लेकिन कभी-कभी यह लगता है जैसे वही बात हो। अगर आप दो डेवलपमेंट टीमों को अपने काम करने के तरीके पर सहमत होने के लिए मजबूर करते हैं, तो इसके लिए बहुत सारी संवाद और मध्यस्थता की आवश्यकता होती है। इसलिए अंततः आपके पास सिर्फ एक ही पक्की सड़क नहीं होगी, बल्कि तीन या चार होंगी, जिनमें से वे कोई एक चुन सकते हैं। अगर वे अपनी खुद की सिस्टम बनाना चाहें, तो वे ऐसा कर सकते हैं, लेकिन यह उनके अपने बजट से होगा। केंद्रीकृत रूप से रखरखाव की जाने वाली सड़क ही "आसान मार्ग" है, जिसे सभी को अपनाने के लिए प्रोत्साहित किया जाता है।
अगर लोग इन साझा क्षमताओं का अंधेरे में उपयोग करते हैं, तो आपको उन्हें लागत दिखानी होगी। जब तक आप खर्च को दृश्यमान नहीं करते, तब तक वे स्वयं इसे अनुकूलित करने की कोशिश नहीं करेंगे। यह प्लेटफॉर्म टीम का कर्तव्य है कि वह खर्च को पारदर्शी बनाए: कितना खर्च हुआ? कितनी मदद मिली? अगर मैं Agent के इटरेशन की संख्या कम कर सकता हूँ, तो यही अनुकूलन है। लेकिन अगर मैं इस सूचक को नहीं देख पा रहा हूँ, और केवल अंतिम परिणाम ही देख पा रहा हूँ, तो मैं कुछ भी नहीं कर सकता; दृश्यमानता सभी अनुकूलन की पूर्वशर्त है।
इसलिए मेरा मुख्य तर्क यह है: हमें एकल डेवलपर्स से टीम स्तर पर साझा Context और साझा कॉम्पोनेंट्स की ओर बढ़ना होगा, और अंततः पूरे संगठन के भीतर एक “मल्टीप्लेयर गेम सिस्टम” की ओर। वहाँ गुणक प्रभाव फूट पड़ेगा, क्योंकि आपके पास एक फ्लायव्हील होगा, जिससे सुधार एक साथ कई दिशाओं में फैल सकते हैं।
सुपर इंडिविजुअल एजेंट युग के संगठन को नहीं बचा सकते
अगले स्तर पर, वीपी इंजीनियरिंग इस बात पर कैसे सोचती है? मैं लगभग अनुमान लगा सकता हूँ कि आपके संगठन में क्या होगा: हैकथॉन या लंच शेयरिंग, सफलता के मामलों की साझाकरण, एक शेयर्ड स्लैक चैनल बनाना, एक चैम्पियंस प्रोग्राम शुरू करना। ये सभी सामान्य परिवर्तन के तरीके हैं। जब एजाइल परिवर्तन हुआ था, तब इसी तरह किया गया था, डेवऑप्स ने भी ऐसा ही किया था, कुछ नया नहीं है।
दूसरी ओर, हम जानते हैं कि "लाइसेंस देना, प्रशिक्षण देना, लोगों को स्वतंत्रता देना और हजारों फूल खिलने देना" यह रणनीति कभी सफल नहीं हुई है। हजारों फूलों का परिणाम आमतौर पर हजारों खरपतवार होता है, जिसमें फूल खिलते हैं लेकिन कोई भी फल नहीं देता। इसलिए मैं सुझाव देता हूँ कि संगठन की ओर से स्पष्ट अधिकार प्रदान किए जाएं, ताकि टीम लीड और प्लेटफॉर्म टीम इसे कर सकें। यह किसी एक सुपर व्यक्ति द्वारा पूरा नहीं किया जा सकता; इसे आगे बढ़ाने के लिए किसी को औपचारिक रूप से अधिकृत किया जाना चाहिए।
किसी की मदद लेना भी एक परेशानी है। वर्तमान में पदनाम बहुत अस्पष्ट हैं—AI उत्पाद इंजीनियर, forward deployed engineer, agentic engineer, AI इंजीनियर... इन शब्दों का वास्तविक अर्थ बहुत कम है। आप इन शीर्षकों से किसी की परिपक्वता का आकलन नहीं कर सकते, क्योंकि पूरा उद्योग अपरिपक्व है। हालांकि, जब आप भर्ती की मांग जारी करते हैं, तो ये शब्द कुछ संकेत प्रदान करते हैं और इच्छुक उम्मीदवारों को आकर्षित करते हैं, लेकिन यह स्वयं इस बात का प्रतिनिधित्व नहीं करता कि व्यक्ति के पास संबंधित कौशल हैं। मैंने कुछ और अधिक अजीब कहानियाँ भी सुनी हैं, जहाँ कुछ उम्मीदवारों ने साक्षात्कार के दौरान AI का उपयोग किया, जो उनके कान में वास्तविक समय में उत्तर देता था—साक्षात्कारकर्ता एक प्रश्न पूछता, और AirPods में AI की सलाह सुनाई देती।
इसलिए मैंने सुना है कि बढ़ती संख्या में कंपनियाँ इस तरह की साक्षात्कार प्रक्रिया अपना रही हैं। पहला चरण: एक अभ्यास दें, और उन्हें AI का उपयोग करके समस्या हल करने के लिए स्वतंत्रता दें—जितना संभव हो उतना AI का उपयोग करें। अगर AI उनकी मदद कर पाता है, तो यह साबित करता है कि वे AI का प्रभावी ढंग से उपयोग करने में कुशल हैं। दूसरा चरण: उनसे अपने समाधान की जाँच करवाएँ और पूछें, “आपने इस समाधान को क्यों चुना? आपने इसे कैसे सत्यापित किया?”—यहाँ आप परीक्षण क्षमता और इंजीनियरिंग निर्णय क्षमता का परीक्षण कर रहे हैं। पहला हिस्सा AI के उपयोग की क्षमता का परीक्षण है, दूसरा हिस्सा इंजीनियरिंग की मजबूत नींव का। तीसरा, देखें कि वे कैसे सहयोग करते हैं, क्या वे साझा करने के लिए तैयार हैं, या वे स्वतंत्र कार्यकर्ता हैं। कुछ लोगों की तकनीकी क्षमता बहुत मजबूत होती है, लेकिन वे सब कुछ अपने हाथों में रखना चाहते हैं; Agent प्रारूप में, ऐसे लोग बाधा बन सकते हैं।
जो व्यक्ति AI का अत्यधिक उपयोग कर सके, मजबूत इंजीनियरिंग कौशल रखता हो, और साझाकरण व सहयोग के लिए तैयार हो, वही आपकी तलाश का व्यक्ति है। यह कोई ऐसा व्यक्ति नहीं है जिसने केवल ML या AI सीखा हो, न ही कोई कोडिंग विशेषज्ञ, बल्कि एक मिश्रण है। आपको संभवतः तीनों क्षेत्रों में पूर्णतः सक्षम व्यक्ति नहीं मिलेगा, और ऐसा कोई बात नहीं है—उदाहरण के लिए, कोई उम्मीदवार किसी एक क्षेत्र में बहुत मजबूत हो सकता है, लेकिन दूसरे क्षेत्र में मार्गदर्शन की आवश्यकता हो सकती है। साथ ही, इन कौशलों को “शुरुआती” या “उन्नत” के रूप में मिलाकर नहीं लेबल करें, क्योंकि ये अलग-अलग कौशल के पहलू हैं; कोई व्यक्ति AI का उपयोग करने में “उन्नत” हो सकता है, लेकिन सहयोग की इच्छा में “शुरुआती”।
वीपी इंजीनियरिंग डिपार्टमेंट को ऊपर को जवाबदेही देनी होगी। हमने इतने अनुमति पत्र खरीदे हैं, क्या हम निवेश और आउटपुट को साबित कर सकते हैं? क्या डिलीवरी तेज़ हुई? संभवतः कुछ वादे हैं, लेकिन उन्हें साबित करना मुश्किल है। क्या गुणवत्ता में सुधार हुआ? वहीं पर यह कहना मुश्किल है। लेकिन मैं पहले जिन दो सूचकांकों के बारे में बात कर चुका हूँ, उनके माध्यम से आप दिखा सकते हैं कि हस्तक्षेपों की संख्या कितनी कम हुई, कितना सुधार हुआ, और पुनः उपयोग दर कितनी बढ़ी। यह “एजेंट के साथ और बिना एजेंट के कोडिंग उत्पादकता” की तुलना करने से कहीं अधिक आसान और अधिक प्रभावी है।
इसलिए, जब कोई व्यक्ति शिकायत करता है कि एजेंट बहुत महंगा है और खर्च सीमित करने की बात करता है, तो आपकी प्राकृतिक प्रतिक्रिया यह नहीं होनी चाहिए कि "हम सभी खर्चों को काट दें", बल्कि यह होनी चाहिए कि "हम खर्च को कैसे अनुकूलित कर सकते हैं?" सबसे सरल तरीका है सही मॉडल चुनना—सभी कार्यों के लिए सबसे शक्तिशाली मॉडल की आवश्यकता नहीं होती; कुछ कार्यों के लिए सस्ते मॉडल पर्याप्त होते हैं। डेवलपर्स को शिक्षित करें कि किस स्थिति में कौन सा मॉडल उपयोग करना है, और आगे बढ़कर, उन्हें बेहतर Context और Harness प्रदान करें, जिससे एजेंट कम भूलेंगे और लागत अधिक से अधिक कम होगी।
एक और टीम के आकार के बारे में बात है। एक सर्वोत्तम व्यक्ति जो सभी काम करता है, वह अंतिम सपना है। लेकिन अगर आप ध्यान से गिनें: इस व्यक्ति को आमतौर पर प्रोडक्ट मैनेजर या डिजाइन जैसे पूरक कौशल की आवश्यकता होती है। फिर आपको बैकअप (backup) के बारे में भी सोचना होगा—अगर कोई व्यक्ति छुट्टी पर चला जाए? तो यह फिर से तीन लोगों तक पहुँच जाता है। फिर संभवतः किसी को प्रोडक्शन और टिकट पर नजर रखनी होगी, और अगर आप वास्तव में अत्यधिक कुशल हैं, तो यही लोग इन कार्यों को साथ-साथ कर सकते हैं। लेकिन जब आप बग सुधारते हैं, तो सुविधाओं को लाने की गति कम हो जाती है। अंत में, नए सदस्य होते हैं—आपको उन्हें यह समझाना होगा कि “अच्छा” क्या है। इसलिए मैं अभी भी मानता हूँ कि संगठन में हम किसी भी टीम को सचमुच एक-दो लोगों में सीमित नहीं कर सकते।
अंत में, डार्क फैक्ट्री पूरी तरह से अंधेरी नहीं हो सकती, बल्कि थोड़ी सी मंद प्रकाश (dim factory) बनी रह सकती है, जिसका अर्थ है कि आपको यह तय करना होगा कि किस सुविधा के लिए कितना जोखिम स्वीकार करना है—सभी सुविधाएँ पूर्ण स्वायत्तता के लिए उपयुक्त नहीं हैं। आप ऑडिट पर अधिक निवेश कर सकते हैं, जैसे कि स्रोत का पता लगाना: किसने कोड बदला? क्या यह एक व्यक्ति है या एजेंट? कोड की वास्तविक उपयोगिता की जांच के लिए वैलिडेटर्स का उपयोग करें, और स्वचालित प्रक्रियाओं की विफलता पर परिदृश्य-संवेदनशीलता में निवेश करें। पूर्ण माइक्रो मैनेजमेंट (प्रत्येक पंक्ति कोड को मनुष्य द्वारा समीक्षित किया जाए) से लेकर पूर्ण स्वायत्त स्वीकृति (मान लें कि एजेंट का आउटपुट सही है) तक, यह एक पूरा स्पेक्ट्रम है। आपका काम, विभिन्न प्रकार के परिवर्तनों के लिए, जोखिम स्तर के आधार पर स्वचालन के स्तर का चयन करना है।
और मुझे लगता है कि आपका प्रतिस्पर्धी लाभ यह है कि आप उन स्थिर ज्ञानों को पकड़ लेते हैं, जिन्हें आप अभी skill, Context, और यहां तक कि Harness के प्रतिबंधों में डाल रहे हैं। मेरे लिए, यह लगातार डिलीवरी को लगातार सीखने की ओर ले जाता है। खुद से पूछें: हम एक नया चीज़ सिस्टम में कितनी जल्दी डाल सकते हैं और एक पुरानी चीज़ को कितनी जल्दी बाहर निकाल सकते हैं? यही आपकी प्रतिक्रिया क्षमता है। अगर आप इस क्षमता में लगातार सुधार कर सकते हैं, तो सवाल यह नहीं रह जाता कि "मुझे पूरे सिस्टम को अधिक विश्वसनीय बनाना है," बल्कि यह हो जाता है कि "क्या मैं सिस्टम के अधिकाधिक हिस्सों को बदलते हुए भी उसकी विश्वसनीयता को बनाए रख सकता हूँ?"
अगर आप केवल एक वाक्य ले जाएँ, तो वह होना चाहिए: विजेता वह अकेले काम करने वाला सुपर प्लेयर नहीं होगा, बल्कि वे होंगे जो बहुत सारे स्तरों पर संगठन को कैसे सुधारें, यह जानते हैं।