👦🏻 लेखक: हेनरी (DeerFlow टीम)[1]
पिछले एक महीने में, मुझे चार दोस्त मिले जो अपना करियर बदलने की तैयारी कर रहे थे—फ्रंटएंड डेवलपर, सॉल्यूशन आर्किटेक्ट, प्रोडक्ट मैनेजर, और पारंपरिक एल्गोरिथम इंजीनियर—उनकी पृष्ठभूमि, उम्र और शहर अलग-अलग थे, लेकिन सभी ने एक ही अंग्रेजी संक्षिप्त रूप पूछा: FDE[2]क्या यह मेरे लिए वास्तव में स值得 है?
FDE, जिसका पूरा नाम Forward Deployed Engineer है[2]यह दो साल पहले Palantir के वर्ग में एक आंतरिक शब्द था, आज यह अचानक रिक्रूटर्स की शुरुआती बात, भर्ती विज्ञप्तियों में एक आम पद, और सोशल मीडिया पर "AI युग का सबसे मूल्यवान पद" का एक प्रस्तावित उत्तर बन गया है। OpenAI ने 2026 के मई में इसी नाम से Deployment Company की स्थापना की।[3], 40 अरब डॉलर के प्रारंभिक निवेश के साथ, स्पष्ट रूप से कहा गया कि इंजीनियरों को ग्राहकों के स्थानीय कार्यालय में भेजा जाएगा और ग्राहकों के कार्य प्रवाह में शामिल होना होगा; Anthropic की Applied AI टीम भी चार समय क्षेत्रों में FDE की भर्ती कर रही है। यह मामला अंदरूनी शब्दावली से स्पष्ट शब्द बनने में केवल एक साल से थोड़ा अधिक का समय लगा।
मेरे पिछले लेख 《致超级个体》[4] में “मनुष्य का इंजन” — जिज्ञासा, स्व-अध्ययन, स्व-प्रेरणा और हाथों से काम करने की क्षमता — के बारे में चर्चा की गई थी कि ये पूरे Closed-loop के भीतर कैसे जागृत होते हैं। लेकिन मनुष्य निलंबित नहीं होते, उन्हें एक विशिष्ट नौकरी के निर्देशांक प्रणाली द्वारा समर्थित होना चाहिए। यदि सुपर इंडिविजुअल AI युग के उत्पादन संबंधों का “कच्चा माल” है, तो FDE इस साल बाजार में उभरने वाली सबसे स्पष्ट “नौकरी की आकृति” है।

मेरे विचार में, FDE परामर्श वाले बॉक्स में नहीं है, और आउटसोर्सिंग वाले बॉक्स में भी नहीं है। यह सुपर इंडिविजुअल के बहुत करीब है—अंतर केवल यह है कि FDE, "मॉडल कंपनी × क्लाइंट" के बीच की खाई में संगठित सुपर इंडिविजुअल है।
क्या आप जानते हैं—Forward Deployed शब्द कहाँ से आया? यह मूल रूप से अमेरिकी सेना का शब्द Forward Deployed Forces था, जो विदेशों या आगे की रेखा पर तैनात, निकट से प्रतिक्रिया देने में सक्षम सैनिकों को संदर्भित करता था, जो स्थानीय बेस पर रहने वाले पीछे की टुकड़ियों के विपरीत था। Palantir ने 2000 के अंत में इस शब्द को सॉफ्टवेयर उद्योग में लाया, जिसका अर्थ था "इंजीनियरों को हेडक्वार्टर से भेजकर ग्राहक के स्थान पर रहने का" कार्य प्रणाली, जिसमें आंतरिक टीमों को सैन्य अक्षरों के अनुसार Delta और Echo नाम दिए गए। अब इसे OpenAI और Anthropic द्वारा पुनः स्वीकार किया गया है—यह संयोग नहीं है—इंजीनियरों को आगे की रेखा पर भेजने की मूलभूत प्रक्रिया कभी नहीं बदली।
इस लेख में लेखक के निकटतम चार मित्रों द्वारा पूछे गए तीन विशिष्ट संदेहों का उत्तर दिया जाएगा:
क्या FDE एक AI के बाह्य आवरण वाली परामर्श कंपनी है? इसकी पारंपरिक परामर्श से सीमा क्या है?
क्या FDE एक उन्नत सॉफ्टवेयर आउटसोर्सिंग है? इसका मेरे वर्तमान में किए जा रहे बाइटी कार्य से क्या अंतर है?
क्या मैं FDE के लिए उपयुक्त हूँ? इस पद के लिए कौन से प्रकार के लोग बढ़ जाएँगे और कौन से नष्ट हो जाएँगे?
लेखक का दृष्टिकोण सावधानी से आशावादी है: FDE वास्तव में विकसित हो रहा है, लेकिन यह सभी के लिए एक परिवर्तन का रास्ता नहीं है। इसे जल्दबाजी में नहीं, बल्कि स्पष्ट रूप से समझाना अधिक महत्वपूर्ण है।
OpenAI के डिप्लॉयमेंट टीम से शुरू करते हैं
अगर केवल एक चीज़ के द्वारा FDE के इस चक्र के पुनर्प्रकट होने का समय निर्धारित किया जा सकता है, तो लेखक 11 मई, 2026 को चुनेगा—उस दिन OpenAI ने Deployment Company की स्थापना की घोषणा की।[5], COO ब्रैड लाइटकैप ने अपने मूल व्यापार रेखा को छोड़ दिया और स्पेशल प्रोजेक्ट्स के लिए सैम आल्टमैन को सीधे रिपोर्ट करने लगे, जिसमें वे पूर्णकालिक रूप से इस मामले की निगरानी करेंगे। उसी सप्ताह, OpenAI ने ब्रिटिश AI परामर्श कंपनी Tomoro का अधिग्रहण किया, जिससे 150 Forward Deployed Engineers और Deployment Specialists नए कंपनी में शामिल हो गए।
ध्यान देने योग्य बात यह है कि OpenAI की भर्ती पृष्ठ पर एक साथ दर्जनों FDE पद उपलब्ध हैं: सैन फ्रांसिस्को, न्यूयॉर्क, वाशिंगटन, और Life Sciences, Semiconductor, Gov जैसे उद्योग-आधारित ऊर्ध्वाधर दिशाओं के साथ, यहां तक कि FDE भर्ति अधिकारी[6]इस पद के लिए अभी भर्ती चल रही है। विश्लेषकों का अनुमान है कि यह टीम तीन साल में 2000–4000 लोगों तक विस्तारित हो जाएगी। यह एक अनुसंधान समूह का आकार नहीं है, यह एक नियमित सेना है।
एंथ्रोपिक की ओर से लगभग दर्पण जैसी कार्रवाई हो रही है। एप्लाइड एआई टीम के तहत फॉरवर्ड डिप्लॉयड इंजीनियर पद[7]बोस्टन, न्यूयॉर्क, सीएल, सैन फ्रांसिस्को, वाशिंगटन, लंदन में एक साथ जारी किया गया, जिसमें 25%–50% ग्राहकों को स्थानीय यात्रा की आवश्यकता है। एक हाल ही में बार-बार उद्धृत उदाहरण फिनटेक कंपनी FIS है—जिसने अपनी घोषणा में सीधे लिखा है कि “Anthropic की Applied AI टीम और forward-deployed engineers FIS में एम्बेडेड हो गए हैं, जिन्होंने Financial Crimes AI Agent का डिज़ाइन किया है और FIS को ज्ञान स्थानांतरित किया है, ताकि वह बाद में अधिक agent को स्वतंत्र रूप से विस्तारित कर सके।”
इस वाक्य में FDE के काम की वास्तविक छवि छिपी हुई है। यह प्रारंभिक आर्किटेक्ट नहीं है, न ही SDR, और न ही ग्राहकों को प्रशिक्षण देने वाला दूत (Evangelist)। यह मॉडल लेकर ग्राहक के कोडबेस में रहने वाला इंजीनियर है। ब्रैड लाइटकैप स्वयं और स्पष्टता से कहते हैं: “हमारे ग्राहक हमें बताते हैं कि उन्हें pilot से production तक पहुँचने की क्षमता की आवश्यकता है। Deployment Company हमारे इंजीनियरों को उनकी टीम में भेजता है और प्रदान करता है।”
इस बात को एक चित्र के रूप में दर्शाएं, तो तीनों पक्षों का संबंध बहुत स्पष्ट हो जाएगा:

इस चित्र में सबसे अधिक जानकारी वाली दो रेखाएँ, FDE द्वारा दोनों ओर भेजी गई प्रतिक्रिया हैं। ग्राहक की ओर, FDE मॉडल को SaaS के रूप में नहीं बेचता, बल्कि ग्राहक के डेटा, अधिकार, अनुपालन और आंतरिक प्रणाली को एक ऐसे पाइपलाइन में जोड़ता है जो मॉडल को चला सके; मॉडल कंपनी की ओर, FDE ग्राहक के वास्तविक समस्याओं और विफलता के नमूनों को product और research में लौटाता है, जिससे roadmap पर प्रभाव पड़ता है—एक बार-बार गलती करने वाला tool calling पैटर्न, SDK के अगले बिल्ट-इन अमूर्तीकरण में बदल सकता है।
इसीलिए FDE को इस चक्र में दो शीर्ष मॉडल कंपनियों द्वारा एक साथ पुनः लागू किया गया, और इसके पीछे केवल “हमें भी Palantir की तरह कंसल्टिंग करनी है” जैसी सरल बात नहीं है। यह मॉडल कंपनियों के लिए एक सिग्नल एक्विज़िशन डिवाइस है—सबसे अधिक सघन ग्राहक चुनौतियों को समझने के लिए, अपने लोगों को स्थिति में होना आवश्यक है; साझेदारों के माध्यम से प्राप्त आवश्यकताएँ हमेशा एक परत से दूर होती हैं। Anthropic एक मिश्रित पथ पर चल रहा है: एक ओर FDE को स्वयं संचालित करते हुए, दूसरी ओर कंसल्टिंग कंपनियों और PE विशालकायों के साथ संयुक्त रूप से डिप्लॉयमेंट नेटवर्क बनाते हुए। एक स्वयं संचालित पर आधारित, दूसरा परितंत्र पर आधारित, लेकिन दोनों का आंतरिक सार एक ही है: मॉडल कंपनियाँ केवल API आपूर्तिकर्ता नहीं रहीं, वे अपने इंजीनियरों को सीधे ग्राहक के उत्पाद में भेजने लगी हैं।
अगला जवाब दो सबसे आम तुलनात्मक प्रश्नों का है—FDE और पारंपरिक परामर्श (मैकिन्से, एक्सेंटर जैसे) की सीमा कहाँ है? और क्या यह हमारे परिचित सॉफ्टवेयर आउटसोर्सिंग से एक ही बात है?
FDE नहीं है मैकिन्से: मॉडल सीमा बनाम प्रक्रिया सीमा
जब लोग पहली बार FDE के कार्य विवरण को सुनते हैं, तो उनकी पहली प्रतिक्रिया होती है: "यह तो नया मैकिन्से, एक्सेंचर नहीं है?"
मैं इस तरह की संबंधित कल्पना को समझता हूँ। सूट पहनना, ग्राहक स्थल पर यात्रा करना, ग्राहक की मीटिंग रूम में बैठकर ब्लैकबोर्ड पर ड्रॉ करना, C-लेवल एक्जीक्यूटिव्स के साथ एलाइन करना—दृश्य के आधार पर, FDE और कंसल्टिंग कंसल्टेंट वास्तव में एक जैसे दिखते हैं। लेकिन जब आप एक स्तर अंदर जाते हैं, तो दोनों का कार्य संरचना पूरी तरह से अलग होती है। कंसल्टिंग प्रक्रिया की सीमाओं को बेचती है, FDE मॉडल की सीमाओं को बेचता है।
इन दोनों को एक टेबल में पार्श्वक्रम में रखें, तो अंतर तुरंत सामने आ जाएगा।

इस तालिका में सबसे अधिक ध्यान देने योग्य पंक्ति "संपत्ति की अवमूल्यन" है।
पारंपरिक परामर्श का सबसे लाभदायक तरीका संपत्ति का पुनः उपयोग है—किसी बैंक के लिए एक योजना, अगले के लिए थोड़ा संशोधित करके फिर से बेची जाती है; रिटेल उद्योग का डिजिटल playbook तीस ग्राहकों पर बार-बार लागू किया जा सकता है। यही पिछले तीस वर्षों में Accenture, Deloitte, McKinsey Digital के विकास का नींव का आर्थिक मॉडल है।
FDE के पास ऐसा संपत्ति नहीं है। मॉडल क्षमताएँ तेजी से बदल रही हैं—आज के लिए एक ध्यान से डिज़ाइन किया गया प्रॉम्प्ट चेन आवश्यक है, लेकिन अगले संस्करण में शायद एक ही वाक्य से काम चल जाएगा। इस गति के सामने “विधि संचय” का परामर्श तेजी से मूल्यहीन हो जाएगा। इसलिए FDE को संपत्ति पुन:उपयोग मॉडल का उपयोग नहीं करना चाहिए, बल्कि प्रत्येक बंद चक्र को पुनः चलाना होगा—मॉडल की सीमाओं का पुनः मूल्यांकन करना, टूलस्टैक का पुनः चयन करना, और उत्पाद आकृति को पुनः जोड़ना। यह दिखने में कम कुशल है, लेकिन मॉडल की गति के साथ चलने का एकमात्र तरीका है।
क्या आप जानते हैं—प्रोडक्ट ओवरहैंग क्या है? लेखक ने पिछले लेख में '致超级个体'[4]इस शब्द की व्याख्या पहले ही की जा चुकी है: मॉडल क्षमता मौजूदा उत्पाद रूप से अधिक है, लेकिन इसे लागू करने के लिए कोई उत्पाद प्रवेश बिंदु, अधिकार या संदर्भ नहीं है। FDE पद का मूल्य मूल रूप से ग्राहक के स्थिति में लटके हुए Overhang को एक वास्तविक, कार्यरत उत्पाद में बदलना है। ग्राहक मॉडल API के कॉल क्वोटा को नहीं, बल्कि "कोई ऐसा है जो इन Overhang को मेरे व्यवसाय में वास्तविक रूप से लागू कर सकता है" की क्षमता को खरीदता है।
यह “प्रोजेक्ट स्ट्रक्चर” पंक्ति के अंतर को भी समझाता है। परामर्श प्रोजेक्ट की मानक संरचना SOW (Statement of Work) + WBS (Work Breakdown Structure) + चरणगत स्वीकृति है: अनुबंध में स्पष्ट रूप से लिखा जाता है कि क्या डिलीवर किया जाना है, कब डिलीवर किया जाना है, और किस मानदंड के आधार पर स्वीकृति दी जाएगी। यह संरचना इस परिकल्पना पर आधारित है कि लक्ष्य अनुबंध पर हस्ताक्षर करने से पहले पहले से ही स्पष्ट हो चुका होता है।
FDE के प्रोजेक्ट इस तरह काम नहीं करते। ग्राहक सबसे अधिक यह कहते हैं: "मुझे पता है कि AI मुझे कुछ करने में मदद कर सकता है, लेकिन मुझे नहीं पता कि क्या।" लक्ष्य स्वयं प्रोजेक्ट का हिस्सा है। इसलिए FDE SOW नहीं लेता, बल्कि mission लेता है—एक अपेक्षाकृत अस्पष्ट दिशा; फिर iteration के माध्यम से एक-एक करके दिशा को स्पष्ट करता है; और अंत में किसी एक iteration में, पहले से जमा मॉडल की समझ को एक उत्पाद रूप में प्राप्त करता है।
“डिलीवरेबल” लाइन को भी विस्तार से समझना चाहिए। FDE चले जाने के बाद, ग्राहक सिस्टम में एक कार्यरत कार्यक्षमता बच जाती है—शायद छोटी, शायद असुंदर, शायद कोई उपयोगकर्ता इंटरफ़ेस नहीं है, लेकिन यह रोज़ाना किसी द्वारा कॉल की जाती है, किसी द्वारा बदली जाती है, किसी द्वारा आलोचित की जाती है। परामर्श का डिलीवरेबल PPT और परिवर्तन प्रबंधन रिपोर्ट होता है, भले ही प्रोजेक्ट में कोड लिखा गया हो या ERP कॉन्फ़िगर किया गया हो, अंत में ग्राहक के उच्च प्रबंधन के पास अभी भी एक पद्धति दस्तावेज़ ही रहता है।
“护城河”这一行最为微妙。FDE 的护城河是对模型能力边界的实时手感——你这个月运行了多少个真实客户场景,你就比别人更清楚 Claude 4.7 能做什么、哪些事必须等到 Claude 5。这种手感无法写进 PPT,也无法放入知识库,它只能存在于过去 90 天内亲手操作过的工程师脑海中。
इसलिए अगली बार जब कोई कहे "FDE तो नया Accenture है", तो ऐसे जवाब दें: Accenture के इंजीनियर्स ग्राहकों की प्रक्रियाओं को फिर से डिज़ाइन करने जाते हैं, जबकि FDE मॉडल की सीमाओं को फिर से समझने जाता है। पहले के संपत्ति दस साल तक स्थिर रह सकती है, जबकि दूसरे की संपत्ति 90 दिनों के बाद फिर से उगनी पड़ती है।
FDE एक सॉफ्टवेयर आउटसोर्सिंग नहीं है: साझा खोज बनाम आवश्यकता का कार्यान्वयन
अगर "FDE नया एक्सेंटर है" पहली स्तर की गलत व्याख्या है, तो "FDE महंगा सॉफ्टवेयर आउटसोर्सिंग है" दूसरी स्तर की है। यह स्तर अधिक भ्रमित करने वाला है, क्योंकि बाहरी साक्ष्य बहुत अधिक प्रतीत होते हैं: FDE वास्तव में ग्राहक के स्थान पर कोड लिखता है, वास्तव में ग्राहक के व्यवसाय के अनुसार कार्यक्षमता को कस्टमाइज़ करता है, और वास्तव में ग्राहक द्वारा कार्य समय के दौरान कॉल किया जाता है। पहली नज़र में, यह आउटसोर्सिंग इंजीनियर से कोई अंतर नहीं दिखता।
लेकिन फीडबैक लूप को देखते ही अंतर साफ़ दिख जाता है।
इस चित्र में सबसे महत्वपूर्ण अंतर यह नहीं है कि चित्र का ऊपरी हिस्सा कितना सरल है, बल्कि चित्र के निचले हिस्से में मॉडल कंपनी की ओर विस्तारित एक प्रतिक्रिया श्रृंखला का अतिरिक्त होना है। यह श्रृंखला सजावट नहीं है, यह FDE पद के अस्तित्व का वास्तविक कारण है। इस अंतर को अलग-अलग करके देखें, तो कम से कम चार युग्मों की तुलना होती है।
जो कुछ जुड़ा है, वह अलग है। बाहरी दल SOW को जोड़ता है—एक ऐसी आवश्यकता सूची जो अनुबंध पर हस्ताक्षर करने से पहले ही स्पष्ट रूप से परिभाषित कर दी गई होती है: कौन से फ़ंक्शन बनाए जाएंगे, किस तकनीक स्टैक का उपयोग किया जाएगा, किस मानदंड के आधार पर स्वीकृति दी जाएगी, और अनुबंध का उल्लंघन होने पर क्या मुआवजा दिया जाएगा। FDE mission को जोड़ता है—ग्राहक स्वयं यह नहीं जानता कि उसे क्या चाहिए, बस इतना जानता है कि “AI मुझे कुछ करने में मदद करना चाहिए।” SOW की पूर्वशर्त निश्चितता है, mission की पूर्वशर्त अन्वेषण है। दोनों पूरी तरह से अलग प्रोजेक्ट स्टार्टअप के दृष्टिकोण हैं।
काम का दायरा अलग है। आउटसोर्स किया गया काम स्थानीय डिलीवरी है—एक मॉड्यूल, एक वेबसाइट, एक डेटा पाइपलाइन, जिसे पूरा करके पैक किया जाता है और अगले क्लाइंट के लिए चला जाता है। FDE एंड-टू-एंड करता है—व्यावसायिक समस्याओं से शुरू करके, मॉडल चयन, उत्पाद रूपरेखा डिज़ाइन, और लॉन्च के बाद वास्तविक उपयोगकर्ताओं के रिटेंशन और चर्न पर।
बिलिंग मॉडल अलग होता है। यह सबसे अनुमान के विपरीत बात है। एक मॉडल कंपनी FDE को क्लाइंट के स्थान पर भेजती है, और उसकी सबसे बड़ी चिंता सिर्फ इस प्रोजेक्ट से कितना कंसल्टिंग फीस मिलेगी, यह नहीं है, बल्कि यह है: इस क्लाइंट के द्वारा आगे कितने token खपते जाएंगे? क्या यह एक retention क्लाइंट बनेगा? क्या यह अधिक बिजनेस लाइन्स में विस्तार करेगा? FDE का वास्तविक KPI, प्रोजेक्ट हस्ताक्षर पर दिखने वाला नंबर नहीं, बल्कि मॉडल token की लंबी अवधि की खपत का वक्र है।
फीडबैक का गंतव्य अलग है। यह चार समूहों में सबसे गहरा समूह है। बाहरी परियोजनाओं में, ग्राहक का फीडबैक केवल बाहरी कंपनी तक ही पहुँचता है और उस कंपनी के भविष्य में दूसरों को बेचे जाने वाले उत्पादों पर कोई प्रभाव नहीं डालता। FDE का फीडबैक मॉडल कंपनी के रोडमैप में वापस आता है—ग्राहक द्वारा वास्तविक परिदृश्य में अनुभव किए गए प्रत्येक समस्या, प्रत्येक प्रॉम्प्ट विफलता, प्रत्येक टूल कॉल बग, अगले संस्करण के ट्रेनिंग डेटा, अगले संस्करण के टूल डिज़ाइन, और अगले संस्करण के उत्पाद कार्यों के लिए इनपुट बन जाते हैं। अर्थात, प्रत्येक FDE स्थापित ग्राहक, मॉडल कंपनी के लिए एक प्राकृतिक design partner के रूप में कार्य करता है।
यही कारण है कि मॉडल कंपनियाँ FDE को उच्च वेतन देने के लिए तैयार हैं। वे केवल एक सेवा बेच रही हैं, बल्कि अपने ग्राहक के स्थान पर वास्तविक दुनिया के उत्पाद रूप के संकेत एकत्रित कर रही हैं। ये संकेत खरीदे नहीं जा सकते, न ही पकड़े जा सकते, न ही प्रश्नावली सर्वेक्षण से निकाले जा सकते—ये केवल एक विशिष्ट इंजीनियर द्वारा, एक विशिष्ट ग्राहक के कार्य प्रवाह में, कुछ बार दीवारों से टकराने के बाद ही प्राप्त किए जा सकते हैं।
क्या आप जानते हैं—OpenAI और Anthropic के FDE टोटल कंपेंसेशन कितने हो सकते हैं? Levels.fyi पर Anthropic सॉफ्टवेयर इंजीनियर के पब्लिक डेटा के अनुसार[8], सीनियर SDE का कुल पैकेज मीडियन \$710K तक पहुँच गया है। FDE इस पद का जोखिम अधिक है—मॉडल क्षमता की अनिश्चितता, ग्राहक व्यवसाय की अनिश्चितता, और उत्पाद रूपरेखा की अनिश्चितता सभी का सामना करना पड़ता है, इसलिए उद्योग संगठित है[9]उल्लेख किया गया है कि अग्रणी AI प्रयोगशाला FDE में उच्च स्तरीय टोटल कंपेंसेशन लगभग 350K - 550K के बीच है, और स्टाफ स्तर से ऊपर के लोगों को \$630K+ तक पहुँच सकते हैं। यह कीमत “बाहरी घंटे” के लिए भुगतान नहीं है, बल्कि “उत्पाद + ग्राहक + मॉडल” तीन जोखिमों के संयोजन के लिए जिम्मेदारी उठाने वालों को भुगतान है। > 2006 की याद दिलाएँ, जब मैंने अपना करियर शुरू किया, और किसी केंद्रीय सार्वजनिक क्षेत्र के उद्यम में काम किया, जब हमारा समूह सूचना प्रौद्योगिकी में परिवर्तन कर रहा था, उस समय हमारे समूह ने एक्सेंटर के परामर्शदाताओं को स्थानीय रूप से भेजा, और समूह को एक्सेंटर को प्रतिदिन 3500 युआन का परामर्श शुल्क देना पड़ता था, जो कई सालों तक रहे, और उस समय के मीडिया ने उन्हें “गोल्डन कॉलर” कहा। मैंने बाद में जर्मन SAP कंपनी में काम किया, SAP ने परामर्श उद्योग के लिए एक नाम परिभाषित किया, और SAP परामर्शदाता “गोल्डन कॉलर” का प्रतीक बन गए। इसलिए, FDE के वेतन कम से कम 24-36 महीनों तक लगातार बढ़ते रहेंगे, और मांग भी स्थिर रूप से बढ़ती रहेगी।
आउटसोर्सिंग श्रम लाभ है, FDE फ्रंटलाइन सेंसर है। इन दोनों चीजों को भ्रमित करने से क्लाइंट को यह गलत धारणा हो सकती है कि वे FDE को SOW के माध्यम से भर्ती कर सकते हैं, और उम्मीदवार FDE के लिए आउटसोर्सिंग के दृष्टिकोण से काम कर सकते हैं। दोनों पक्ष जल्द ही दीवार से टकरा जाएंगे।
विदेशी FDE के दो मूल: Palantir और नवीन मॉडल कंपनियाँ
बहुत से लोग गलती से सोचते हैं कि FDE शब्द OpenAI द्वारा आविष्कृत है। वास्तव में ऐसा नहीं है। इसकी दो ऐतिहासिक जड़ें हैं, एक Palantir से और दूसरी 2023 के बाद की नवीन मॉडल कंपनियों से। इन दोनों जड़ों को एक साथ देखने से FDE पद का वास्तविक कार्य अधिक स्पष्ट रूप से समझ में आता है।
समयरेखा देखें।
The first root is Palantir.
पालेंटिर की स्थापना 2003 में पीटर थील, एलेक्स कार्प, जो लॉन्सडेल आदि द्वारा की गई थी, और इसके पहले ग्राहक अमेरिकी सूचना संगठन थे। कार्प के पास सीएस का पृष्ठभूमि नहीं है—वह फ्रैंकफर्ट में दार्शनिक यूर्गेन हैबरमास के साथ डॉक्टरेट किया, और अमेरिका लौटने के बाद थील ने उन्हें सीईओ के रूप में शामिल किया। FDE इस पद को ठीक इसी "असामान्य सीईओ + अत्यधिक गुप्त ग्राहक" संयोजन से उत्पन्न किया गया: 36Kr की समीक्षा[10]इसमें बहुत सीधे तरीके से लिखा गया है कि Palantir को शुरुआत में सूचना एजेंसियों द्वारा कड़ी आलोचना की गई, क्योंकि इंजीनियर्स को वास्तविक व्यावसायिक परिदृश्य नहीं मिल पा रहे थे, और आवश्यकताओं के कई स्तरों पर अनुवाद के बाद वे विकृत हो चुकी थीं। बाद में Palantir ने एक बात सुनिश्चित की—अपने इंजीनियर्स को सीधे ग्राहक के स्थान पर भेजना, जहाँ वे सूचना विश्लेषकों के साथ साझा कार्यस्थल पर काम करें। इस मॉडल को बाद में Shyam Sankar ने प्रणालीगत ढंग से विकसित किया, जिससे FDE का आरंभिक रूप बना।
2009 तक, FDE व्यावसायिक क्षेत्र में विस्तारित हो गया। जेपी मॉर्गन ने Palantir के Metropolis प्लेटफॉर्म को लागू करते समय, 120 FDE आंतरिक खतरा निगरानी के लिए स्थानांतरित किए गए। इस समय से, FDE केवल "इंजीनियरों को बिजनेस ट्रिप पर भेजना" नहीं रहा, बल्कि एक व्यवस्थित ग्राहक एम्बेडेड दृष्टिकोण बन गया: Foundry / Gotham को ग्राहक के व्यावसायिक प्रवाह में सचमुच शामिल किया जाने लगा, बस एक लाइसेंस देकर चले जाने के बजाय।
Palantir की FDE भर्ती में एक अनुमान के विपरीत मानदंड है—CS की डिग्री की आवश्यकता नहीं है। इसे "क्या आप जानते हैं?" में शामिल किया जा सकता है।
क्या आप जानते हैं—Palantir FDE को CS की डिग्री की आवश्यकता नहीं है? SkillScouter द्वारा तैयार Palantir भर्ती मानदंड के अनुसार[11]Palantir की आधिकारिक करियर पेज के साथ[12]पालेंटिर गैर-सीएस बैकग्राउंड के उम्मीदवारों का स्पष्ट रूप से स्वागत करता है, और हाल के FDE भर्तियाँ मैकेनिकल इंजीनियरिंग, अर्थशास्त्र, दर्शन आदि के विषयों से आई हैं। इसके लिए वास्तविक रूप से महत्वपूर्ण दो बातें हैं: अपूर्ण जानकारी में कार्रवाई करने की क्षमता, और सी-लेवल क्लाइंट्स के साथ सीधे बातचीत करने की क्षमता। सीएस डिग्री एक प्लस है, लेकिन प्रवेश पास नहीं है। कार्प स्वयं इस मानदंड के पहले उदाहरण हैं—एक दर्शन का छात्र, जो भौतिकी, गणित और दर्शन के छात्रों के साथ FDE टीम बनाता है।
दूसरी जड़ 2023 के बाद की नई पीढ़ी की मॉडल कंपनी है।
ChatGPT के 2022 के अंत में लॉन्च होने के बाद, OpenAI ने जल्द ही एक बात का एहसास किया: मॉडल API को डॉक्यूमेंटेशन पर लगाकर ग्राहकों को खुद कनेक्ट करने के लिए छोड़ देना, पूरी तरह से काम नहीं कर रहा था। ग्राहक इसका उपयोग नहीं करना नहीं चाहते थे, बल्कि यह जानते नहीं थे कि इसका उपयोग कैसे करें—उनके पास बिजनेस समस्याएं तो थीं, लेकिन प्रोडक्ट फॉर्म नहीं। इसलिए OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia, Decagon जैसी कंपनियां FDE की बड़े पैमाने पर भर्ती करने लगीं।
इस लहर में FDE बिल्कुल Palantir के playbook को सीख रहा है—इंजीनियरों को ग्राहक स्थल पर भेजकर एक एंड-टू-एंड वर्कफ्लो को सफलतापूर्वक चलाया जाता है। लेकिन उत्पाद वाहन पूरी तरह से बदल चुका है: Palantir के समय में FDE का काम डेटा एकीकरण और UI कस्टमाइजेशन था, जबकि नवीनतम FDE Prompt डिजाइन, Agent ऑर्केस्ट्रेशन, टूल कॉलिंग और वर्कफ्लो एम्बेडिंग पर काम करता है।
Pragmatic Engineer का FDE पर विशेष लेख[13]इस नए संस्करण को वे “एंटरप्राइजेज के साथ एम्बेडेड करके क्लॉड को वास्तविक, विशिष्ट और उच्च मूल्यवान समस्याओं को हल करने के लिए” कहते हैं—यह व्यक्ति प्रायः पैलेंटिर के समय के समान है, केवल “डेटा” को “मॉडल” से बदल दिया गया है।
Looking at these two roots together, you can see a clear set of commonalities and differences.
सामान्य बिंदु: ग्राहक सॉफ्टवेयर नहीं, बल्कि "मेरी समस्या हल करने वाले इंजीनियर + उपकरण संयोजन" खरीद रहे हैं। पिछले तीस वर्षों के उद्योग सॉफ्टवेयर के इतिहास में यह असामान्य था। SAP, Oracle, Salesforce ने सॉफ्टवेयर को ही बेचा—इंजीनियर केवल "ग्राहक को इस सॉफ्टवेयर का उपयोग करने में सक्षम बनाने" के लिए सहायक संसाधन थे। Palantir इसके विपरीत है: उपकरण केवल "FDE को ग्राहक के पास समस्या हल करने में सक्षम बनाने" के लिए एक लीवरेज के रूप में मौजूद हैं। नई पीढ़ी की मॉडल कंपनियाँ इस उलटा संबंध को आगे बढ़ाती हैं—OpenAI GPT-4 लाइसेंस नहीं, बल्कि "हमारे FDE GPT-4 का उपयोग करके आपकी कस्टमर सपोर्ट को स्वचालित कर सकते हैं" बेचती हैं।
अंतर: पैलेंटिर के समय का ध्यान OPS एकीकरण पर था—मुख्य बात डेटा एकीकरण, ओंटोलॉजी मॉडलिंग और अधिकार प्रबंधन थी। नवीन पीढ़ी का ध्यान मॉडल क्षमताओं के कार्यान्वयन पर है—मुख्य बात प्रॉम्प्ट डिज़ाइन, एजेंट ऑर्केस्ट्रेशन और रिटेंशन अनुकूलन है। पहला सिस्टम एकीकरणकर्ता का उन्नत संस्करण है, दूसरा उत्पाद इंजीनियर का विस्तारित संस्करण है।
अंत में एक दिलचस्प तथ्य: पैलेंटिर के प्रारंभिक FDE, बाद में कई उद्यमी बन गए या सीधे नवीन मॉडल कंपनियों में शामिल हो गए। एंथ्रोपिक, ओपनएआई, सिएरा, हेबिया की प्रारंभिक टीमों में, ex-Palantir के नामों की लंबी सूची गिनी जा सकती है। यह संयोग नहीं है—FDE पद स्वयं एक व्यक्ति को उत्पाद जोखिम, ग्राहक जोखिम और इंजीनियरिंग जोखिम सभी सहने के लिए मजबूर करता है, जो लगभग एक उद्यमी की प्रशिक्षण कक्षा है। लेखक पैलेंटिर को एक अदृश्य उद्यमी प्रशिक्षण शिविर के रूप में देखना पसंद करता है: यह न केवल इंजीनियर, बल्कि अपूर्ण जानकारी में किसी चीज को शून्य से एक तक आगे बढ़ाने का तरीका जानने वाले लोगों को पलटता है। दो मूल, 2023 के बाद मिलते हैं।
देशी FDE: समाधान आर्किटेक्ट से AI लागू इंजीनियर तक
दो मूलों का संगम मुख्य रूप से विदेशों में होता है। घरेलू रूप से, FDE शब्द का उपयोग अभी तक कम समय से हुआ है, लेकिन इसके संबंधित कार्य अचानक नहीं आए हैं। घरेलू FDE को समझने के लिए, पहले इसके दो स्थानीय पूर्वजों को समझें, फिर इसके अमेरिकी संस्करण से तीन जलवायुगत अंतरों को समझें।
दो स्थानीय पूर्ववर्ती
पहला पूर्ववर्ती क्लाउड प्रदाता के समाधान आर्किटेक्ट था। अलीबाबा क्लाउड, टेंसेंट क्लाउड और हुआवेई क्लाउड ने पिछले दशक में ग्राहकों को आर्किटेक्चर समझाने, POC लिखने, माइग्रेशन योजनाएँ बनाने और लॉन्च तक के डिलीवरी में सहयोग करने के लिए एक पूरी समाधान आर्किटेक्ट (SA) टीम विकसित की है। हुआवेई के अंदर “डिलीवरी इंजीनियर” श्रेणी भी है, जो प्रोजेक्ट को कस्टमर के डेटासेंटर में लागू करने के लिए जिम्मेदार है। यह प्रणाली FDE कार्य के 80% को पहले से ही कर रही है, लेकिन इसका केंद्र अभी भी प्रारंभिक बिक्री और डिप्लॉयमेंट पर है—एंड-टू-एंड प्रोडक्ट इटरेशन की जिम्मेदारी SA के हाथ में नहीं है, अगर आवश्यकता बदलती है तो इसके लिए परिवर्तन प्रक्रिया से गुजरना पड़ता है, मॉडल बदलने पर हेडक्वार्टर के समय सूची का इंतजार करना पड़ता है।
दूसरा पूर्ववर्ती AI स्टार्टअप में नए बने सीक्वेंस है। MiniMax, BOSS डायरेक्ट पर "AI प्री-सेल्स सॉल्यूशन एक्सपर्ट" के लिए पोस्ट कर रहा है, और मून ऑफ डार्कनेस, ज़हीपु, टोन्गयी, हुनयुआन जैसी मॉडल कंपनियाँ भी इसी तरह की भूमिकाएँ पोस्ट कर रही हैं। नाम में थोड़ा अंतर है, लेकिन JD की सामग्री अत्यधिक समान है: ग्राहक के सीन को समझना, डेमो बनाना, Prompt एडजस्ट करना, RAG चलाना, डिलीवरी समाधान लिखना, और ग्राहक के इंजीनियरिंग टीम के साथ लाइव होने तक का समन्वय करना। यह भूमिकाएँ वास्तविक अर्थों में "भारतीय FDE" हैं।

Three water and soil differences
प्राइवेट डिप्लॉयमेंट + डेटा कॉम्प्लायंस, सिर्फ मॉडल कॉल के मॉडल को दबा देता है। भारतीय B2B ग्राहकों की डेटा आउटसाइड देश नहीं जाए, मॉडल वेट्स पर नियंत्रण हो, और ऑडिट ट्रेसेबल हो, इन आवश्यकताओं का स्तर अमेरिकी बाजार की तुलना में कहीं अधिक है। एक FDE प्रोजेक्ट में, सिर्फ API कॉल और प्रॉम्प्ट चलाने का काम सिर्फ 30% हो सकता है, शेष 70% मॉडल को कस्टमर के डेटासेंटर में स्थानांतरित करने, ऑथेंटिकेशन सेटअप करने, डेटा प्लेटफॉर्म से जोड़ने, और कॉम्प्लायंस रजिस्ट्रेशन पूरा करने में लगता है।
मॉडल क्षमताएँ अभी भी SOTA के पीछे हैं, और इसका विकास स्थान केवल इंजीनियरिंग स्तर तक सीमित हो गया है। अमेरिका के OpenAI और Anthropic मॉडल क्षमता को ही ग्राहकों को प्रभावित करने के लिए उपयोग कर सकते हैं; जबकि देश के Tongyi, DouBao, Kimi, GLM, DeepSeek की क्षमताओं में विभिन्नता इतनी अधिक नहीं है, इसलिए ग्राहकों का निर्णय Agent ऑर्केस्ट्रेशन, RAG खोज गुणवत्ता, टूल एकीकरण और Workflow डिज़ाइन जैसी इंजीनियरिंग क्षमताओं पर केंद्रित होता है। देश के FDE की प्रतिस्पर्धा “हमारा मॉडल कितना मजबूत है” नहीं, बल्कि “क्या मैं इस व्यवसाय को वास्तव में सफलतापूर्वक चला सकता हूँ” पर है।
B एंड की भुगतान की इच्छा और मूल्य निर्धारण गति अमेरिका से अलग है। पैलेंटिर का “पहले FDE को तैनात करें, फिर उच्च मूल्य वाली सदस्यता शुल्क लें” का मॉडल सीधे नकल नहीं किया जा सकता। देशी ग्राहकों का बजट वार्षिक खरीदारी के साथ चलता है, भुगतान परियोजना-आधारित होने की प्रवृत्ति रखता है, और FDE का व्यावसायिक मॉडल अक्सर सदस्यता + निजीकरण लाइसेंसिंग + परियोजना डिलीवरी का मिश्रित रूप होता है।
एक अनूठी स्थिति: आंतरिक FDE
कई बड़ी कंपनियों के आंतरिक AI टीमें "आंतरिक ग्राहकों" के लिए FDE मॉडल का उपयोग शुरू कर रही हैं। अलीबाबा क्लाउड PAI ने टैobao में इंजीनियर भेजे हैं, और टेंसेंट हुनयुन के पास वेशिन, विज्ञापन बिजनेस के साथ जुड़ने के लिए समान मैकेनिज्म है। JD पर "उद्योग लागू इंजीनियर", "AI अनुप्रयोग इंजीनियर", "स्मार्ट बिजनेस विशेषज्ञ" दिखाए गए हैं, जो मूल रूप से आंतरिक FDE हैं—मॉडल टीम की क्षमताओं को बिजनेस साइड तक एंड-टू-एंड ले जाना। यह बड़ी कंपनियों के लीडर्स को एक नया विचार देता है: कुछ आंतरिक FDE बिजनेस साइड पर स्थित हों, पहला demo चलाएं, और ROI के डेटा को बिजनेस के मालिक के हाथ में सौंपें, तो विभागीय दीवारें दस मीटिंग्स से जल्दी समाप्त हो जाएंगी।
FDE के लिए कौन उपयुक्त है, कौन नहीं
लेखक ने पिछले लेख में 《सुपर इंडिविजुअल्स के लिए》[4]उसमें सुपर इंडिविजुअल के पांच इंजन के बारे में बताया गया है: उत्सुकता, खोज और नवीनता की भावना, स्व-अध्ययन क्षमता, स्व-प्रेरणा और हाथों से काम करने की क्षमता। ये पांच बातें FDE के लिए प्रवेश पत्र हैं, लेकिन सब कुछ नहीं। FDE पद के लिए पांच इंजन के अलावा, कुछ बहुत विशिष्ट अतिरिक्त विशेषताएँ होती हैं, और कुछ प्रकार के व्यक्तित्व स्पष्ट रूप से उपयुक्त नहीं हैं। लेखक ने कई उत्कृष्ट इंजीनियर्स को FDE में बदलने के बाद समायोजित न हो पाने को देखा है; समस्याएँ अक्सर क्षमता में नहीं, बल्कि व्यक्तित्व और कार्य प्राथमिकताओं में होती हैं।
FDE के लिए पाँच गुण
अपने बिक्री और संचार से न डरें। FDE का दैनिक कार्य कोड लिखने के लिए दरवाजे बंद करना नहीं, बल्कि ग्राहकों के CTO, बिजनेस लीड, खरीद, कॉम्प्लायंस और IT के साथ सीधे संपर्क करना है। एक आम गतिविधि: ग्राहक CTO demo के बीच में आपको रोक देता है, FDE की प्रतिक्रिया “मैं वापस जाकर एक नया संस्करण बनाकर अगले सप्ताह आता हूँ” नहीं होनी चाहिए, बल्कि वह तुरंत IDE खोलकर Prompt बदलकर पुनः चलाकर दिखाता है। “ग्राहक मौजूद है, मैं बदल रहा हूँ” FDE की सामान्य स्थिति है।
अज्ञात क्षेत्र का आनंद लें। FDE को स्पष्ट PRD नहीं, बल्कि एक वाक्य मिलता है—"हम एआई का उपयोग करके कुछ करना चाहते हैं।" ग्राहक खुद भी नहीं जानता कि वह क्या चाहता है, इसलिए FDE को उसके साथ इस अस्पष्ट अपेक्षा को विशिष्ट आकार देना होगा। अगर आप केवल स्पष्ट आवश्यकताओं के साथ ही काम कर पाते हैं, तो FDE आपको हर दिन चिंतित करेगा।
इंजीनियरिंग क्षमता मजबूत होनी चाहिए, लेकिन 10x की आवश्यकता नहीं है। FDE को आपको कंपनी का सबसे साफ़ कोड लिखने वाला या सबसे गहरा एल्गोरिथम वाला व्यक्ति होने की आवश्यकता नहीं है; इसे आपको एंड-टू-एंड काम करने वाला सिस्टम बनाना है: फ्रंटएंड पर एक क्लिक करने योग्य पेज, बैकएंड पर एक चलने वाली सेवा, और मॉडल को बिजनेस डेटा स्रोत से जोड़ना। FDE की दुनिया में, “लगभग काफी है” एक कमी नहीं, बल्कि एक गुण है।
प्रतिक्रिया से बेहतर बनना पसंद करते हैं। FDE के काम में कई ऐसे पल होते हैं जहाँ "ग्राहक द्वारा आलोचना करके फिर से करने" की मांग की जाती है: आज का डेमो कल बिजनेस टीम द्वारा "यह मेरा नहीं है" कहकर खारिज कर दिया जाता है; पिछले हफ्ते समझाई गई योजना, इस हफ्ते ग्राहक के एक नए एचआई प्रबंधक द्वारा फिर से करने की मांग की जाती है। FDE के लिए उपयुक्त व्यक्ति इस प्रतिक्रिया को ईंधन की तरह लेते हैं, पूरी प्रक्रिया की जिम्मेदारी संभालते हैं और "आवश्यकता स्पष्ट नहीं कही गई" का बहाना नहीं बनाते।
मॉडल की सीमाओं के प्रति संवेदनशील हों। यह सबसे तकनीकी और सबसे अदृश्य नियम है। FDE को यह निर्णय लेना होगा कि कौन सा कार्य LLM के लिए उपयुक्त है और कौन सा नहीं, और किस प्रकार का fallback अपनाया जाए — इस संवेदनशीलता को पेपर्स से नहीं, बल्कि विफलता के मामलों से ही सीखा जा सकता है। विफलता के नमूनों के संचय से FDE को मॉडल की सीमाओं के प्रति मांसपेशीय स्मृति विकसित होती है: किस स्थिति में RAG का उपयोग करना है, किस स्थिति में नियमों का पालन करना है, और किस स्थिति में मानवीय fallback प्रवेश बिंदु अनिवार्य है।
FDE के लिए अउपयुक्त चार प्रकार के लोग
कोड के भीतर छिपना पसंद करने वाले तकनीकी एक्सपर्ट। FDE लगभग 50% समय कोड लिखने के बजाय ग्राहक मीटिंग्स, आंतरिक समन्वय, उत्पाद चर्चाओं और अनुबंधों को आगे बढ़ाने में बिताता है। अगर आपकी खुशी लगातार चार घंटे तक किसी के बिना कोड लिखने में है, तो FDE आपको लंबे समय तक मानसिक थकान में डाल देगा।
जिन्हें OKR की आवश्यकता होती है ताकि वे कार्य कर सकें। FDE के लक्ष्य ग्राहक के पास होते हैं, आपके प्रदर्शन टेबल पर नहीं। कार्य की प्रगति ग्राहक के प्रोजेक्ट नोड्स, मॉडल की क्षमता में परिवर्तन, और आपके स्वयं के स्थिति के निर्णय द्वारा निर्धारित होती है। "पहले OKR होना चाहिए, तभी पता चलेगा कि क्या करना है" की आदत वाले लोग अपना आधार नहीं पा पाएंगे।
把“晋升”看得比“作品”重的人。FDE 在大厂晋升体系里不占便宜——客户满意度、项目签单、复用率这些指标,跟代码量、上线频次比起来在职级评审里说不响。如果你的工作动机里晋升排第一,FDE 不是好选择。
व्यावसायिक संदर्भ से दूर रहने वाले। FDE को ग्राहक के P&L, ROI, खरीद प्रक्रिया, अनुपालन आवश्यकताओं को समझना होगा। यदि आप स्वभाव से पैसे, अनुबंध और व्यावसायिक तर्क की चर्चा से नफरत करते हैं, तो FDE का कार्य आपको लगेगा कि आप अपनी तकनीकी आदर्शों को बेच रहे हैं।
स्व-जांच सूची
7 प्रश्न, प्रत्येक FDE के एक वास्तविक कार्य स्थिति के लिए। 5 से अधिक "हाँ" के उत्तर देने पर FDE को गंभीरता से विचार करें, 3 से कम के उत्तर देने पर सावधानी से निर्णय लें।
क्या आप अपना दिन का 50% समय कोड से हटाकर ग्राहक बैठकों, संदेशों और फोन कॉल्स पर लगाने के लिए तैयार हैं?
2. जब ग्राहक आपको बताता है "यह काम नहीं कर रहा है, मैं नहीं बता सकता कि क्यों", तो आपकी पहली प्रतिक्रिया जिज्ञासा होती है, या असहनशीलता?
3. कोई आपके लिए पीआरडी नहीं लिख रहा है, क्या आप एक हफ्ते में क्लॉड कोड के साथ एक कस्टमर के लिए दिखाने योग्य प्रोटोटाइप चला सकते हैं?
4. एक ही डिलीवरी के लिए, ग्राहक ने आपसे 8 वर्जन बदलने को कहा, क्या आप अभी भी अपनी निर्णय क्षमता बनाए रख सकते हैं, और केवल मशीनी रूप से कार्य नहीं करते?
5. जब मॉडल गलत उत्तर देता है, तो आपकी पहली प्रतिक्रिया फॉलबैक डिज़ाइन करना है या मॉडल की आलोचना करना है?
6. क्या आप अनुबंध पर हस्ताक्षर करना, रिपोर्ट लिखना, ग्राहक स्वीकृति के लिए जाना और कानूनी टीम के साथ अनुपालन शर्तों पर बातचीत करना चाहेंगे?
7. क्या आप त्वरित प्रोटोटाइप और त्वरित विफलता स्वीकार कर सकते हैं?
पाँच विशेषताएँ, चार प्रकार के विपरीत चित्र, सात प्रश्न, अंततः एक ही प्रश्न: क्या आप अपनी उत्पाद समझ, इंजीनियरिंग क्षमता और व्यावसायिक निर्णय को एक ही कार्य प्रवाह में एक साथ विकसित करने के लिए तैयार हैं?
अंतिम विचार: सुपर इंडिविडुअल से सुपर पोस्ट तक
पिछले लेख में मैंने “मानव इंजन” पर चर्चा की थी: जिज्ञासा, अन्वेषण की भावना, स्व-अध्ययन क्षमता, स्व-प्रेरणा और हाथों से काम करने की क्षमता—ये सभी बड़ी कंपनियों के अंदर कैसे पूर्ण बंद चक्र के रूप में प्रेरित होते हैं। इस लेख में मैं एक अलग बात पर चर्चा कर रहा हूँ—पद का रूप। FDE AI औद्योगिक क्रांति का पहला ऐसा नया पद है जिसका नाम है, वेतन बैंड है, भर्ती JD है, और ग्राहकों के भुगतान से सत्यापित है। यह “सुपर इंडिविजुअल” अवधारणा का समानार्थी नहीं है, बल्कि इस नवीकरण के दौरान पहला ऐसा सूचक है जो काल्पनिक से वास्तविक में सफलतापूर्वक उतरा है।
FDE अंत नहीं है। लेखक का मानना है कि FDE केवल नए विभाजन में पहला नाम पाने वाला रूप है। इसके बाद Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher आएंगे—सभी ग्राहक स्थितियों के साथ घनिष्ठ रूप से जुड़े, जिन्हें अस्पष्ट क्षेत्र में उत्पाद को विकसित करने की आवश्यकता होती है, उन सभी के पास अपना “फॉरवर्ड डिप्लॉयड” संस्करण होगा। पद के नाम बदलेंगे, लेकिन मूल तर्क एक समान होगा: मॉडल क्षमता आगे चलती है, उत्पाद रूप पीछे भागता है, और पद संरचना कार्य प्रवाह के साथ पुनः विभाजित होती है।
तीनों पाठकों के लिए एक-एक वाक्य छोड़ें।
टेक्निकल लोगों के लिए: FDE आपसे यह नहीं मांगता कि आप कंपनी में सबसे अच्छे कोडर हों, लेकिन यह आपसे यह मांगता है कि आप अपना आधा समय कोड से ग्राहकों की ओर स्थानांतरित करने को तैयार हों। अगर आपका जवाब "हां" है, तो बाजार का खिड़की अभी खुली है, और देश के शीर्ष मॉडल कंपनियां, क्लाउड प्रोवाइडर्स और बड़ी कंपनियों के आंतरिक AI टीमें भर्ती को तेज कर रही हैं। अगर जवाब "नहीं" है, तो कोई बात नहीं, नए विभाजन में आपके लिए अन्य पद भी उभरेंगे।
HR और OD के लिए: "नाम और वास्तविकता में अंतर" के प्रति सावधान रहें। आपकी कंपनी में पहले से ही कुछ FDE काम कर रहे हो सकते हैं, लेकिन उनके पद विवरण में "समाधान विशेषज्ञ", "उद्योग आर्किटेक्ट", "AI अनुप्रयोग इंजीनियर" लिखा हुआ है। उन्हें पहचानें, पुनर्वर्गीकृत करें, और उन्हें उनके कार्य के अनुरूप एक विकास मार्ग प्रदान करें—यह शून्य से नए कर्मचारी भर्ती करने की तुलना में अधिक कुशल है।
प्रबंधकों के लिए: FDE मॉडल केवल बाहरी नहीं, बल्कि आंतरिक रूप से भी हो सकता है। कंपनी के अंदर कुछ "आंतरिक FDE" रखें जो बिजनेस साइड पर बैठें और मॉडल टीम की क्षमताओं को बिजनेस प्रक्रिया में एंड-टू-एंड लाएं—यह एक नया AI विभाग बनाने और दस बार क्रॉस-टीम अलाइनमेंट मीटिंग्स करने की तुलना में कहीं अधिक कुशल हो सकता है। विभागीय दीवारें संगठनात्मक डिज़ाइन से नहीं, बल्कि एक कामकाजी डेमो से हटाई जाती हैं।
AI युग का करियर ट्रांसफॉर्मेशन शुरू हो चुका है, FDE इसका पहला संकेत है, जो हमें बताता है कि मॉडल क्षमताओं में परिवर्तन की गति इतनी तेज हो चुकी है कि नए पदों का उदय हो रहा है। लेखक आपके लिए एक विशिष्ट प्रश्न छोड़ना चाहता है—अगर तीन साल बाद आपकी कंपनी के संगठनात्मक संरचना चार्ट पर तीन नए पद जुड़ जाएँ, तो आपका अनुमान है कि वे कौन से होंगे? इस प्रश्न को स्पष्ट करना, इस लेख को पढ़ने से अधिक उपयोगी है।
