क्लॉड कोड के संस्थापक बोरिस चर्नी ने सीक्वोया कॉन्फ्रेंस में एआई पर 7 महत्वपूर्ण निर्णय साझा किए

संगठित: अयिंग

क्लॉड कोड के संस्थापक बोरिस चेर्नी ने रेड सीक कॉन्फ्रेंस में अपना साझाकरण किया, जिसमें बहुत सारी जानकारी थी, और मुझे कई बातें पहली बार पूरी तरह सुनने को मिलीं। यह आदमी वास्तव में AI को समझता है।

मैं अपना सारांश साझा करता हूँ।

For a large number of mainstream development scenarios, manually writing code has already become an inefficient task.

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

The way things work now is different.

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

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

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

यह परिवर्तन वास्तव में औद्योगिक क्रांति के बहुत समान है।

औद्योगिक क्रांति से पहले, एक लोहार लोहे को पीटने, बनाने, चमकाने और असेंबल करने तक का सारा काम अकेले करता था। अच्छा लोहार स्वाभाविक रूप से मूल्यवान होता था।

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

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

श्रमिक गायब नहीं हुए, लेकिन श्रमिक की भूमिका बदल गई।

सॉफ्टवेयर इंजीनियरिंग अब इसी तरह के मोड़ से गुजर रही है। कोड खुद अब दुर्लभ चीज़ नहीं है। कोड लिखना, PPT का उपयोग करने जैसी एक बुनियादी क्षमता बनता जा रहा है।

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

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

इसे मशीन को सौंपना, बहुत से लोगों के लिए केवल काम करने का तरीका बदलना नहीं, बल्कि पहचान का एक पुनर्निर्माण है।

लेकिन ट्रेंड ट्रेंड ही है।

कोडिंग एक पेशेवर कौशल से एक बुनियादी क्षमता में बदल रही है। इस बात की तुलना 15वीं शताब्दी के यूरोप में प्रिंटिंग प्रेस से की जा सकती है।

प्रिंटिंग प्रेस के आविष्कार से पहले, यूरोप में केवल लगभग 10% लोग ही पढ़-लिख सकते थे। ये लोग अक्सर अशिक्षित शाही वर्ग के लिए काम करते थे, जिनका काम लोगों के लिए पढ़ना और लिखना था।

फिर प्रिंटिंग प्रेस का आविष्कार हुआ। 50 वर्षों में, यूरोप में प्रकाशित पुस्तकों की संख्या पिछले हजार वर्षों के कुल योग से अधिक हो गई, और पुस्तकों की कीमतें लगभग 100 गुना घट गईं। कई सदियों तक अनुकूलन (शिक्षा प्रणाली, आर्थिक संरचना धीरे-धीरे अनुसरण करती रही) के बाद ही वैश्विक साक्षरता दर आज के 70% तक पहुँची।

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

अंततः, सॉफ्टवेयर बनाना इतना स्वाभाविक हो जाएगा जितना संदेश भेजना।

जब AI ने कोड लिखने की सीमा बहुत कम कर दी, तो वास्तविक रूप से किसी व्यक्ति की क्षमता का अंतर उसकी उत्पाद समझ और किसी विशिष्ट क्षेत्र की वास्तविक समझ होती है।

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

पहले, इंजीनियर के पास आइडिया को लागू करने की अधिक संभावना होती थी।

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

इसका मतलब है कि जब एआई ने कार्यान्वयन की बाधाओं को हटा दिया, तो निर्णय लेने के अंतर को बढ़ा दिया गया।

This event directly redefined the meaning of the word generalist.

पिछले समय हम जनरलिस्ट कहते थे, जिसका अर्थ आमतौर पर एक इंजीनियर होता था जो iOS लिख सकता था, Web लिख सकता था, और बैकएंड भी लिख सकता था। ऐसा जनरलिस्ट, मूल रूप से इंजीनियरिंग के भीतर का स्टैक होता है।

भविष्य का जनरलिस्ट एक बहुविषयक स्टैक है।

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

लेकिन अब AI ने प्रत्येक कार्य की निष्पादन सीमा को कम कर दिया है, एक व्यक्ति कई क्षेत्रों में काम कर सकता है और विशेषज्ञता की गहराई भी बनाए रख सकता है।

क्लॉड कोड टीम ऐसी है। इंजीनियरिंग मैनेजर, पीएम, डिजाइनर, डेटा साइंटिस्ट, फाइनेंस, उपयोगकर्ता अनुसंधान, हर कोई कोड लिख रहा है।

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

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

हर किसी की विशेषज्ञता अभी भी मौजूद है। लेकिन AI सहायता के साथ, कोड लिखना एक साझा भाषा बन गया है।

पिछले दशकों में, SaaS उद्योग में कुछ ऐसे समझौते थे जिन्हें लगभग स्वीकार्य तथ्य माना जाता था।

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

अलग प्रणाली पर स्थानांतरित होना चाहते हैं, इन चीजों को बिल्कुल वैसे ही बाहर निकालकर फिर से अंदर डालना ही काफी है कि आपको हिलने की हिम्मत न हो।

दूसरा बिंदु कार्यप्रवाह लॉक है। कर्मचारियों के दैनिक ऑपरेशन, अंतर्विभागीय सहयोग और अनुमोदन नोड्स सभी इस SaaS के चारों ओर विकसित हुए हैं।

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

इन दोनों को मिलाकर, पिछले SaaS उद्योग की सबसे गहरी रक्षा बन गई। लेकिन पर्याप्त शक्तिशाली मॉडल के साथ, बातों का तर्क बदलने लगा।

सबसे पहले स्विचिंग लागत पर नजर डालें। पिछले समय में, एक SaaS से दूसरे पर स्विच करने के लिए, केवल फील्ड्स को मैप करना और डेटा स्ट्रक्चर को एक बार फिर से कॉपी करना ही इंजीनियरिंग टीम के लिए कई महीनों तक ओवरटाइम करने के लायक होता था।

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

अब कार्यप्रवाह लॉक की ओर देखें, यह अधिक दिलचस्प है। पिछले समय में कार्यप्रवाह ग्राहकों को लॉक कर पाए क्योंकि ये प्रक्रियाएँ स्वयं जटिल, अदृश्य और मानव पर निर्भर थीं।

कर्मचारियों के मन में जो समझौता होता है कि कौन किससे अनुमोदन मांगे, कब कौन से चरण पर रुके, वह सीधे नहीं ले जाया जा सकता।

लेकिन Opus 4.7 जैसे मॉडल सबसे अच्छे ढंग से एक जटिल प्रक्रिया को समझते हैं, इसे तोड़ते हैं, और एक नए वातावरण में फिर से बनाते हैं। यहां तक कि फिर से बनाई गई संस्करण, मूल की तुलना में अधिक चिकना हो सकता है।

इसलिए पुराने डेटा और प्रक्रिया स्थिरता पर आधारित व्यापारिक लाभ ढीले पड़ रहे हैं।

SaaS बनाने वालों के लिए यह खबर खराब हो सकती है। लेकिन SaaS का उपयोग करने वाले सभी ग्राहकों और नई पीढ़ी के SaaS बनाने की तैयारी कर रही टीमों के लिए यह एक वास्तविक अवसर का समय है।

अगले 10 वर्षों में वास्तविक रूप से उद्योग को बदल देने वाली स्टार्टअप की संख्या पिछले 10 वर्षों की तुलना में 10 गुना अधिक हो सकती है।

कारण वास्तव में जटिल नहीं है।

छोटी टीमें AI का उपयोग करके बड़ी कंपनियों के बराबर या उससे बेहतर उत्पाद बना सकती हैं। विपरीत रूप से, बड़ी कंपनियों के लिए AI का वास्तविक रूप से उपयोग करना एक नेगेटिव एसेट हो सकता है।

How to say it?

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

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

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

इस गति का अंतर पहले से ही AI के पहले भी मौजूद था। स्टार्टअप्स के पास बड़ी कंपनियों के लिए मूल रूप से गति का लाभ होता है। लेकिन AI ने इस अंतर को कई गुना बढ़ा दिया है।

क्यों?

क्योंकि जितना अधिक AI शक्तिशाली होगा, उतना ही एक व्यक्ति एक इकाई समय में अधिक लीवरेज उठा सकता है। एक वास्तविक रूप से AI का उपयोग करने वाली एक छोटी टीम, आज का उत्पादन पिछले दस लोगों के बराबर हो सकता है, कल यह पिछले तीस लोगों के बराबर हो सकता है।

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

यही Boris द्वारा कहे गए नेगेटिव एसेट्स हैं। यह बड़ी कंपनियों के पास पैसा, लोग या इच्छा न होने की बात नहीं है, बल्कि उनके पिछले समय में लाभ कमाने वाले मांसपेशियाँ आज AI के वास्तविक मूल्य को प्राप्त करने के रास्ते में फंस गई हैं।

MCP मरेगा नहीं।

स्किल लोकप्रिय होने के बाद, कई लोगों को लगा कि MCP की आवश्यकता नहीं है। ओपनक्लॉ फाउंडर का भी इसी तरह का विचार है।

लेकिन बोरिस इस बात से सहमत नहीं हैं। वे मानते हैं कि MCP AI युग का सॉफ्टवेयर कनेक्टिविटी लेयर बनेगा।

पिछले इंटरनेट के सॉफ्टवेयर कनेक्शन का तरीका API था।

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

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

इसलिए बोरिस ने API को ह्यूमन डेवलपर इंटरफेस कहा और MCP को मॉडल इंटरफेस प्रोटोकॉल। एक इंसानों के लिए है, दूसरा मॉडल्स के लिए।

यह वास्तव में उस समय के समान है। मोबाइल इंटरनेट युग में, सभी सेवाओं को API-कृत होना आवश्यक माना जाता था। AI युग में, सभी सेवाओं को MCP-कृत होना आवश्यक माना जाता है।

अब बहुत से लोग कंप्यूटर यूज़ के बारे में बात करते हैं, और लगता है कि यह दिशा संभवतः काम नहीं करेगी।

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

लेकिन बोरिस ने पूरी तरह से अलग स्तर देखा।

वह वास्तव में यह महत्वपूर्ण मानता है कि Computer Use AI के व्यावहारिक अनुप्रयोग के सबसे बड़े चुनौतियों में से एक को हल करता है: वास्तविक दुनिया में, बहुत सारी प्रणालियाँ न तो API हैं और न ही MCP।

विशेष रूप से व्यवसाय दुनिया में।

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

तो उन्हें सीधे API क्यों नहीं बनाया जाए?

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

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

अल्पकालिक रूप से, प्रमुख मॉडल अपनी कंप्यूटर उपयोग क्षमता में सुधार करते रहेंगे।