हम जिस चीज़ को मॉडल को सिखाना चाहते हैं, वही चीज़ हम अपने बच्चों को सिखाते हैं।

लेखक, स्रोत: मशीन इंडिया

बहुत से लोग कहते हैं कि AI युग में, स्वाद मानवता की अंतिम रक्षा है। लेकिन बोरिस चेर्नी ऐसा नहीं सोचते।

वह Anthropic के तकनीकी सदस्य हैं और Claude Code के प्रमुख निर्माताओं में से एक हैं। वह प्रतिदिन मॉडल का उपयोग करके कोड लिखते हैं और मॉडल का अध्ययन भी करते हैं। और उन्होंने देखा है कि जिसे "स्वाद" कहा जाता है, वह भी तेजी से मॉडल द्वारा सीखा जा रहा है।

अगर "क्या करना है" तक मॉडल के हाथ में है, तो मनुष्य के पास क्या बचा?

हाल के एक साक्षात्कार में, बोरिस ने इस विषय पर बात की।

Claude Code कैसे कंपनियों की व्यवस्था को मूल रूप से बदल देता है;

जब मॉडल अधिकांश कोड लिख सकता है, तो इंजीनियर को अभी भी भर्ती करना उचित है? यदि हाँ, तो किन बातों पर निर्भर करता है?

क्यों एंथ्रोपिक में बहुत सारे लोग मेम्बर ऑफ टेक्निकल स्टाफ हैं, और स्पष्ट रूप से कोई रैंक या भूमिका विभाजन नहीं है?

सभी उद्यमियों के लिए एक विपरीत सलाह क्यों है "कम लोग भर्ती करें, अधिक टोकन दें"?

……

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

और बोरिस द्वारा दिया गया उत्तर, बहुत ही शांति से सोचने लायक है।

Claude Code कैसे बना?

जब होस्ट ने बोरिस क्लॉड कोड की उत्पत्ति के बारे में पूछा, तो उसका जवाब कुछ अप्रत्याशित था।

उसके वर्णन के अनुसार, क्लॉड कोड Anthropic द्वारा शुरू से ही योजनाबद्ध मुख्य उत्पाद नहीं था, बल्कि किसी न किसी तरह एक अनपेक्षित उत्पाद कहा जा सकता है।

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

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

उस समय बाजार में एआई प्रोग्रामिंग टूल्स अधिकांशतः दो दिशाओं तक सीमित थे। एक दिशा में स्वचालित पूर्ति थी, जो डेवलपर्स को अगली पंक्ति कोड पूरा करने में मदद करती थी; दूसरी दिशा में प्रश्न-उत्तर सहायक थे, जहां डेवलपर्स किसी कोड के अर्थ या किसी त्रुटि के समाधान के बारे में पूछ सकते थे। लेकिन बोरिस का मानना था कि उस समय अभी तक कोई वास्तविक Coding Agent नहीं था।

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

हालांकि, बोरिस ने स्वीकार किया कि मूल क्लॉड कोड उपयोग के लिए अच्छा नहीं था।

लंबे समय तक, यह केवल उसके लगभग 10% से 20% काम को ही पूरा कर सकता था। अधिकांश कोड अभी भी उसे खुद लिखना पड़ता था। आज लोग जो Claude Code देखते हैं, वह उस समय के उत्पाद की तुलना में पूरी तरह से अलग चीज है।

Anthropic क्यों कोडिंग पर इतना ध्यान केंद्रित कर रहा है?

बहुत से लोग सोचते हैं कि Anthropic को कोडिंग पर ध्यान देने का कारण सरल है — प्रोग्रामिंग बाजार पर्याप्त रूप से बड़ा है और व्यावसायिक मूल्य पर्याप्त रूप से उच्च है। लेकिन बोरिस द्वारा दिया गया स्पष्टीकरण बिल्कुल अलग है।

उसने कहा कि अगर आप एंथ्रोपिक के कार्यालय में एक यादृच्छिक कर्मचारी को रोककर पूछें कि वह यहाँ क्यों आया, तो अधिकांशतः एक ही उत्तर मिलेगा: AI Safety।

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

और कोडिंग एक लगभग आदर्श प्रयोगशाला है।

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

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

इस दृष्टिकोण से, Claude Code केवल प्रोग्रामरों के लिए एक उत्पादकता उपकरण ही नहीं है। बोरिस के वर्णन के अनुसार, यह Anthropic द्वारा भविष्य के AI सिस्टम को समझने के लिए एक महत्वपूर्ण प्रयोगात्मक मंच भी है।

Claude Code क्यों अचानक मजबूत हो गया?

क्लॉड कोड की उत्पत्ति के बाद, होस्ट ने एक ऐसा प्रश्न उठाया जिसका जवाब बहुत से लोग जानना चाहते हैं। चूंकि क्लॉड कोड के शुरुआती दिनों में यह बोरिस के काम का केवल 10% से 20% ही पूरा कर पा रहा था, तो आगे क्या हुआ? क्योंकि आज बोरिस ने सार्वजनिक रूप से घोषणा कर दी है कि उन्होंने पिछले छह महीनों से कोड लिखने का काम खुद नहीं किया है। एक छोटे से हिस्से के काम को पूरा करने से लेकर विकास के काम को लगभग पूरी तरह से संभालने तक, इसके बीच स्पष्ट रूप से भारी परिवर्तन हुआ है।

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

पिछले वर्ष में, Anthropic टीम ने वास्तव में Claude Code को लगातार सुधारा है। उन्होंने काफी इंजीनियरिंग कार्य किया है और विभिन्न नए इंटरैक्शन तरीके और उत्पाद रूप जोड़े हैं। शुरू में Claude Code केवल एक कमांड लाइन टूल था, लेकिन बाद में यह डेस्कटॉप, मोबाइल, Slack, GitHub जैसे विभिन्न स्थितियों में विस्तारित हुआ। टीम ने विकासकर्ताओं और Agent के साथ सहयोग करने में मदद करने वाले विभिन्न फीचर्स, जैसे प्लान मोड (Plan Mode), का प्रयास भी किया है। लेकिन बोरिस के अनुसार, ये सभी वृद्धिकारी सुधार हैं।

क्लॉड कोड की अधिकतम सीमा वास्तव में नींव के मॉडल द्वारा निर्धारित होती है।

उन्होंने कुछ महत्वपूर्ण बिंदुओं का उल्लेख किया। सोनेट 4, ओपस 4 से लेकर बाद के ओपस 4.5 तक, प्रत्येक मॉडल क्षमता में वृद्धि सीधे क्लॉड कोड के प्रदर्शन पर प्रतिबिंबित होती है।

फिर होस्ट ने पूछा कि क्लॉड कोड के उपयोग का अनुभव क्या मॉडल विकास पर प्रतिकूल प्रभाव डालेगा। बोरिस के अनुसार, एंथ्रोपिक के अंदर लगभग हर कोई रोजाना क्लॉड कोड का उपयोग करता है, जिसमें मॉडल विकसित करने वाले, उत्पाद विकसित करने वाले... पूरी कंपनी शामिल है।

इसलिए कोई विशेष फीडबैक चैनल नहीं है। फीडबैक स्वयं कंपनी के दैनिक कार्य का हिस्सा है।

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

Claude Code ने Anthropic को कितनी उत्पादकता में वृद्धि दी?

बोरिस कहते हैं कि AI प्रयोगशाला में लंबे समय तक काम करने के बाद, लोग घातीय वृद्धि के तरीके से सोचने की आदत डाल लेते हैं। आय, उपयोग या मॉडल क्षमता जैसे कई आंतरिक सूचकांक घातीय वक्र की तरह दिखते हैं, इसलिए वे परिवर्तनों को देखने के लिए लघुगणकीय स्केल का उपयोग करने की आदत डाल लेते हैं।

और कोड आउटपुट भी समान प्रवृत्ति दिखाता है।

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

अधिक दिलचस्प बात यह है कि यह वृद्धि कंपनी के तेजी से विस्तार के दौरान हुई।

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

लेकिन बोरिस ने विपरीत बात देखी। पिछले समय में एक नए इंजीनियर को कंपनी के आंतरिक प्रणालियों को समझने में कई सप्ताह लग जाते थे। अब यह प्रक्रिया अक्सर केवल दो दिनों में पूरी हो जाती है।

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

Claude Code केवल कोड जेनरेशन की गति ही नहीं बढ़ाता, बल्कि संगठन के भीतर ज्ञान स्थानांतरण की लागत को धीरे-धीरे कम कर रहा है। पिछले समय में, व्यवसाय ज्ञान प्रवाह को पूरा करने के लिए परंपरागत शिक्षण और मार्गदर्शन पर निर्भर थे। अब, बढ़ती संख्या में ज्ञान सीधे मॉडल में समाहित हो रहा है।

पंच कार्ड से लेकर Vibe Coding तक, मनुष्य केवल प्रोग्रामिंग के अमूर्त स्तर को फिर से बढ़ा रहा है

चूंकि क्लॉड कोड इतना शक्तिशाली है, तो एंथ्रोपिक द्वारा हाल ही में भर्ती किए गए इंजीनियर्स कोड लिखते हैं? जब होस्ट ने यह प्रश्न उठाया, तो चर्चा का केंद्र तुरंत इस बात पर स्थानांतरित हो गया: आप 'कोड लिखना' को कैसे परिभाषित करते हैं?

बोरिस के अनुसार, सॉफ्टवेयर इंजीनियरिंग का विकास इतिहास मूल रूप से अमूर्त स्तर को लगातार बढ़ाने का इतिहास है।

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

उसने पिछले वर्ष के दौरान अपने काम के परिवर्तन का वर्णन किया। शुरुआत में, वह अधिकांश डेवलपर्स की तरह था: IDE खोलना, कोड लिखना, और कभी-कभी ऑटो-कंप्लीशन का उपयोग करना, जो पारंपरिक सॉफ्टवेयर डेवलपमेंट का तरीका है।

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

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

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

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

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

इंजीनियर कोड नहीं लिखते, तो भर्ती में क्या देखा जाता है?

इस पर मेजबान ने एक दिलचस्प सवाल पूछा: अगर आज एक इंजीनियर Anthropic में शामिल होना चाहता है, तो Anthropic उसका मूल्यांकन कैसे करेगी? या फिर: एक ऐसी दुनिया में जहाँ कम से कम कोड लिखा जाता है, कंपनियाँ किस प्रकार के लोगों की तलाश कर रही हैं?

बोरिस के उत्तर ने लगभग सीधे रूप से संगठनात्मक संरचना पर अगली चर्चा को जन्म दिया। उन्होंने कहा कि Claude Code टीम को सबसे अधिक पसंद आने वाले लोग वास्तव में: जनरलिस्ट (सामान्यज्ञ) हैं।

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

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

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

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

इसीलिए बोरिस मानते हैं: हम एक जनरलिस्ट के स्वर्ण युग की ओर बढ़ रहे हैं। जिन लोगों के पास कई काम करने की इच्छा है, उनके लिए अब शायद इतिहास का सबसे अच्छा समय है।

टेक्निकल स्टाफ का सदस्य एक झूठा दावा नहीं है, बल्कि भविष्य का पूर्वाभास है

होस्ट ने विषय को उत्पाद से संस्कृति और संगठनात्मक डिज़ाइन पर ले आया। उन्होंने ध्यान दिया कि बोरिस का शीर्षक 'प्रोडक्ट डायरेक्टर' या 'इंजीनियरिंग डायरेक्टर' नहीं, बल्कि मेम्बर ऑफ टेक्निकल स्टाफ है, और एंथ्रोपिक में कई लोगों का यही शीर्षक है। वे जानना चाहते हैं: इसके क्या फायदे हैं? क्या कोई नुकसान है?

बोरिस बहुत ईमानदार था। उन्होंने कहा कि सबसे खराब बात यह थी कि आप Slack पर किसी को मैसेज करते हैं, जिसका टाइटल MTS है, और आपको पता नहीं होता कि यह व्यक्ति डिजाइनर है, इंजीनियर है या मैनेजर, और न ही उसका कौन सा प्रोजेक्ट है। लेकिन उन्हें इस टाइटल से बहुत प्यार था।

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

हाँ, वह मानता है कि स्तर शीर्षक गायब होने से वास्तव में गायब नहीं हो जाते। आप जानते हैं कि कोई व्यक्ति L7 है, केवल शीर्षक नहीं लिखा गया है। लेकिन दिलचस्प बात यह है कि अक्सर आपको वास्तव में पता नहीं होता।

उसने अपने Facebook पर L4 इंजीनियर के रूप में काम करने के दौरान एक कहानी सुनाई। उसके पास एक विचार आया, उसने सीधे कनेक्टिविटी के लिए जिम्मेदार VP को देखा और कहा: "यह मेरा विचार है, चलिए इसे एक साथ करते हैं।" उस VP को पता नहीं था कि वह किस स्तर का है। उसने एक और VP को देखा, लेकिन वह भी असफल रहा। तीसरी बार, वह सफल हुआ। उन्होंने एक टीम बनाई और उत्पाद विकसित करना शुरू कर दिया।

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

हर नए मॉडल के आने पर, सभी को पुनः कैलिब्रेट करना होता है। इस युग में अनुभव रेखीय रूप से जमा नहीं होता, कभी-कभी यह दायित्व भी हो सकता है।

इसलिए, Member of Technical Staff जैसा अस्पष्ट शीर्षक, बोरिस के लिए, एक आगामी वास्तविकता का पूर्वाभास है: इंजीनियर, PM, डिजाइनर और उपयोगकर्ता शोधकर्ता के बीच की सीमाएँ, अंत तक लगभग समाप्त हो जाएँगी। इस परिवर्तन को निष्क्रिय रूप से स्वीकार करने के बजाय, शीर्षक के माध्यम से सभी को एक ही भूमिका पर लाने का सक्रिय प्रयास करें: Builder।

सभी संस्थापकों के लिए सलाह: कम लोगों को भर्ती करें, अधिक टोकन जारी करें

मेजबान ने बोरिस से एंथ्रोपिक के दृष्टिकोण से उपस्थित संस्थापकों और कंपनियों के लिए एक सामान्य सलाह मांगी: 2026 के अंत तक, संगठन को मानसिकता कैसे समायोजित करनी चाहिए?

बोरिस की पहली बात पर हंसी आ गई: “सभी को जितने संभव हो सके टोकन दें।” यह एक तरह से हुआंग रेन्यून के प्रसिद्ध कथन की तरह है: “जितना अधिक आप खरीदते हैं, उतना अधिक आप बचाते हैं।”

यह मजाक नहीं है। वह गंभीर है। उसने दो बातें विशिष्ट सुझाव दिए हैं:

सबसे पहले, जितने संभव हो उतने टोकन दें, ताकि सभी लोग बहुत सारे प्रयोग कर सकें।

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

होस्ट ने इस सुझाव का बहुत संक्षिप्त सारांश दिया: कम लोगों के साथ, बजट को लोगों के वेतन से टोकन पर स्थानांतरित करें। इससे आपकी शुरुआती लागत बढ़ेगी, लेकिन निरंतर लागत में भारी कमी आएगी। यह प्री-कंपाइलिंग की तरह है — आप एक बार में सारा कठिन काम कर लेते हैं, और हर बार दोहराने पर लगभग मुफ्त होता है।

बोरिस पूरी तरह सहमत है। होस्ट ने एक और तीखा प्रश्न पूछा: पिछले समय में लोग अपने विषय (discipline) के बारे में बहुत गर्व महसूस करते थे। PM अपने लिखे गए उत्पाद लेखों के लिए गर्व करते थे, डिजाइनर अपने सुंदर पोर्टफोलियो के लिए। क्या 12 महीनों में सभी को अपनी पहचान "मैं किसी विशेष व्यक्ति हूँ" को छोड़कर, "एक लचीला, token खपाने वाला बैग" बनना पड़ेगा?

बोरिस कहते हैं: "मैं थोड़ा अलग शब्दों में कह सकता हूँ, लेकिन... हाँ, लगभग ऐसा ही है।"

क्या स्वाद को भी मॉडल ने निगल लिया? अंततः बचा हुआ केवल「मूल्यवान」ही है

होस्ट ने पहले एंथ्रोपिक के एक अन्य सदस्य जैरेड के साथ चर्चा किए गए विषय का उल्लेख किया, और बोरिस की राय जानना चाहता है: आप 'टेस्ट' (स्वाद) को कैसे समझते हैं?

बोरिस का जवाब बहुत ईमानदार था। उन्होंने कहा कि जब भी उन्हें लगा कि उन्हें प्रोग्रामिंग में कोई 'विशेष स्वाद' है, तो अंततः यह साबित हो गया कि वे गलत थे।

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

फिर उसने एक अधिक साहसिक अनुमान लगाया। अब सब कहते हैं कि "उत्पाद स्वाद अंतिम अल्फा है।" लेकिन उसका मानना है कि यह अल्फा भी तेजी से गायब हो रहा है।

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

मेजबान ने पूछा: तो मनुष्य के पास अंततः क्या अनूठा कुछ बचा है? क्या कोई ऐसी चीज है जो मॉडल कभी नहीं कर सकता?

बोरिस ने सोचा और कहा: मूल्य।

वह कहते हैं कि हम जो अंततः मॉडल को सिखाना चाहते हैं, वही है जो हम अपने बच्चों को सिखाते हैं: एक अच्छा अस्तित्व कैसे बनें। सही चीजें कैसे करें, और सिर्फ चीजों को सही तरीके से करना नहीं।