17 अगस्त को GitHub पर व्यापक सेवा विचलन हुआ, और उसी दिन Cursor ने भुगतान करने वाले उपयोगकर्ताओं के लिए Origin early beta लॉन्च किया। कोड रिपॉजिटरी में लगातार चलने वाले Agent को जोड़ा जा रहा है, जबकि मौजूदा सहयोग बुनियादी ढांचा मनुष्यों की कार्य गति के अनुकूल है। अध्ययनों से पता चलता है कि 40.2% रिपॉजिटरी में ओवरलैपिंग Agent PR हुए हैं, जिसमें merge conflict का प्रतिशत 41.7% है। Cursor Origin Agent की उच्च आवृत्ति लिखने के लिए डिज़ाइन किया गया है, जो सिंगल रिपॉजिटरी में 22.6 commit/s समर्थन करता है, और रिपॉजिटरी, PR, checks और review को एकीकृत करता है। Origin, Git के ऊपर एक कंट्रोल लेयर के रूप में स्थित है, जो उच्च आवृत्ति Agent सहयोग प्रक्रियाओं को पुनः परिभाषित करता है। मस्क के xAI, X, SpaceX और Cursor ने एक पूर्ण AI उत्पादन श्रृंखला बना ली है, जहाँ Colossus कंप्यूटेशनल पावर प्रदान करता है, Grok मॉडल प्रदान करता है, Cursor कोड निष्पादित करता है, और Origin इंजीनियरिंग स्टेटस को प्रबंधित करता है। GitHub मानव सहयोग से Agent की ओर विस्तार कर रहा है, Cursor Agent के कार्यभार के अनुसार forge को पुनः डिज़ाइन कर रहा है, और दोनों पथों के बीच प्रतिस्पर्धा बढ़ती जा रही है।

लेखक, स्रोत: लेफेंगवेन

कोड रिपॉजिटरी के मालिक, इंसान से एजेंट में बदल रहे हैं।

17 अगस्त को, GitHub पर व्यापक सेवा विचलन हुआ। वेब, API, Actions, पुल अनुरोध, जिट ऑपरेशन, वेबहुक आदि मुख्य लिंक्स प्रभावित हुए, कुछ समय के लिए वेब और API अनुरोध त्रुटि दर लगभग 20% तक पहुंच गई।

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

दिलचस्प बात यह है कि दोनों चीजें एक ही समय पर आ गईं, जिससे एक परिवर्तन को बढ़ा दिया गया: कोड रिपॉजिटरी में लगातार चलने वाले एजेंट्स का जुड़ना बढ़ रहा है, जबकि मौजूदा सॉफ्टवेयर सहयोग अवसंरचना लंबे समय से मनुष्यों की कार्य गति के अनुकूल हो चुकी है।

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

GitHub के सामने आने वाली बहुत सी नई समस्याएँ, Origin द्वारा हल करने की इच्छा की गई बहुत सी समस्याएँ, शायद यहीं से शुरू होंगी।

01 GitHub अचानक पुराना नहीं हुआ

जब GitHub शुरू हुआ, तो सॉफ्टवेयर सहयोग का एक स्थिर आधार इकाई थी: व्यक्ति।

एक इंजीनियर कुछ घंटों कूड़ा लिखता है, एक बार commit करता है; एक फीचर के विकास में कुछ दिन लगते हैं, एक PR बनता है; समीक्षा आधे घंटे बाद भी हो सकती है, या अगले दिन; CI कुछ मिनट चलना सामान्य है, merge conflict को थोड़ी देर बाद सुलझाने से पूरी सिस्टम का मतलब खोया नहीं जाता।

इस ताल पर, GitHub ने Pull Request, Issue, Review, Actions, Webhook और अधिकार प्रणाली बनाई। यह ताल लिनक्स कर्नेल जैसी लंबे समय तक उच्च सबमिशन दर बनाए रखने वाली प्रोजेक्ट में भी स्पष्ट रूप से मानव समय पैमाने को दर्शाता है।

LWN के अनुसार, Linux 7.0 के पूरे विकास चक्र में 2362 विकासकर्ताओं से 14,251 non-merge commits हुए। ये सभी सबमिशन लगातार कई सप्ताह तक चलने वाले विकास चक्र के दौरान हुए, जिसमें ईमेल चर्चा, मेंटेनर रिव्यू, सबसिस्टम एकीकरण और रिलीज़ साइकिल शामिल थे।

कर्सर ने 6 जून के Origin प्रदर्शन में एक अलग लोड प्रारूप दिखाया: एकल रिपोजिटरी 22.6 कमिट/सेकंड।

यह संख्या ऑनलाइन डेमो डेटा से संबंधित है और स्वतंत्र रूप से पुनर्उत्पादित उत्पादन benchmark नहीं है, इसलिए यह साबित नहीं करती कि Origin वास्तविक व्यावसायिक परिस्थितियों में समान थ्रूपुट को लंबे समय तक बनाए रख सकता है। लेकिन यह पर्याप्त रूप से बताता है कि Origin किस प्रकार के workload के लिए डिज़ाइन किया गया है: कई Agent एक ही कोड स्टेट पर लगातार लिखते हैं।

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

एजेंट के पास यह सीमा नहीं है।

कई एजेंट एक ही बेस SHA से एक साथ फैल सकते हैं, समान समय पर संबंधित फाइलों को संशोधित कर सकते हैं, और फिर एक साथ push कर सकते हैं, PR खोल सकते हैं, जांच को कॉल कर सकते हैं, समीक्षा पढ़ सकते हैं, कोड में परिवर्तन कर सकते हैं और फिर से push कर सकते हैं। एक ही commit अभी भी इंडेक्स अपडेट, अधिकार जांच, Webhook, CI, कोड स्कैन, समीक्षा स्थिति अपडेट और mergeability गणना को ट्रिगर कर सकता है।

इसलिए परिवर्तन को सहन करने की आवश्यकता न केवल Git ऑब्जेक्ट मॉडल पर है, बल्कि Git पर आधारित forge कंट्रोल प्लेन पर है: API, प्रमाणीकरण, बैकग्राउंड टास्क, CI स्केड्यूलिंग, Webhook, branch संरक्षण, समीक्षा अवस्था, merge कतार, और इन घटकों के बीच बनने वाला कैस्केडिंग लोड।

जुलाई में GitHub पर Agent PR के लिए किए गए एक अध्ययन ने इस समानांतर रूप को देखा है। अध्ययन ने 2807 रिपॉजिटरी में 33596 Agent PR का विश्लेषण किया, जिसमें 40.2% रिपॉजिटरी में समय के दौरान ओवरलैपिंग Agent PR देखे गए।

सैंपल रिप्ले किए गए समानांतर संशोधनों में, एजेंट के बीच टेक्स्ट मर्ज विरोध का अनुपात 41.7% है, जबकि एक ही एजेंट द्वारा उत्पन्न समानांतर PRs में यह 19.8% है।

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

Origin का डिज़ाइन यहीं से शुरू होता है।

02 मूल सहयोग लागत पुनः लिखें

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

इसका अवसर Agent द्वारा सहयोग लागत में परिवर्तन से आता है। stacked PR एक उदाहरण है।

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

एजेंट की लागत संरचना अलग होती है। जब एक संशोधन कई फाइलों में फैला होता है, तो किसी भी चरण में विफलता होने पर, एजेंट को व्यापक संदर्भ को फिर से समझना पड़ सकता है। छोटे change set में विभाजित करने के बाद, schema, service, UI आदि में संशोधन स्पष्ट निर्भरता बना सकते हैं, और प्रत्येक नोड की अलग-अलग पुष्टि की जा सकती है, और विफलता होने पर केवल संबंधित भागों को ही संभाला जाता है।

इसलिए छोटा PR एजेंट के लिए चेकपॉइंट के रूप में काम कर सकता है, जिससे कार्य में स्थानीय सत्यापन, स्थानीय पुनः प्रयास और निर्भरता ट्रैकिंग की क्षमता होती है।

Cursor का Graphite का अधिग्रहण यहाँ भी समझा जा सकता है। Origin की वर्तमान early beta अभी Graphite के stacked workflow को पूरी तरह से सम्मिलित नहीं करती है, लेकिन Graphite द्वारा लंबे समय तक निवेश किए गए stacked PR और stack-aware merge queue, Agent द्वारा कोड उत्पादन की गति बढ़ाने के बाद उत्पन्न हुए अगले बैकलॉग के साथ सटीक रूप से मेल खाते हैं।

PR संख्या बढ़ने के बाद, merge queue का दायित्व भी बढ़ जाएगा। Agent A और Agent B एक ही base SHA से एक साथ काम कर सकते हैं, और दोनों अलग-अलग परीक्षणों से गुजर सकते हैं।

A मुख्य में प्रवेश करने के बाद, B का परीक्षण परिणाम केवल पुरानी स्थिति में कोड की वैधता साबित कर सकता है, लेकिन नए मुख्य में प्रवेश के बाद भी सुरक्षित होने की पुष्टि नहीं कर सकता। इसलिए, queue को लगातार बदलते मुख्य के आधार पर उम्मीदवार स्थितियों को पुनः बनाना, checks को पुनः निष्पादित करना और PR के बीच के निर्भरता को संभालना होगा।

Conflict can also gradually evolve from manual intervention into a recoverable failure state in the pipeline. Cursor already provides /babysit capabilities to continuously handle PR feedback, failed checks, and conflicts. When a candidate merge encounters issues, the relevant context can be reassigned to the Agent to correct and revalidate it in an isolated environment.

समीक्षा भी संरचित हो जाएगी। मानव सहयोग बहुत अधिक प्राकृतिक भाषा और टीम के अनुभव पर निर्भर करता है, जबकि एजेंट को लंबे समय तक चलाने के लिए स्पष्ट रूप से पता होना चाहिए कि कौन सी जांच विफल हुई, कौन से थ्रेड अभी तक हल नहीं हुए, कौन सी नीति पूरी नहीं हुई, और वर्तमान head SHA क्या है।

Origin ने API के माध्यम से repository, commit, checks, PR आदि ऑब्जेक्ट्स को प्रकट कर दिया है और formal review और सामान्य चर्चा के बीच अंतर किया है।

इन संरचित स्थितियों को बाद में सीधे Automations द्वारा उपयोग किया जा सकता है। push, PR opened या PR pushed द्वारा cloud agent ट्रिगर होता है, और नतीजे checks और PR में वापस लिखे जाते हैं, जिसके बाद विफलता पर प्रोसेसिंग प्रक्रिया शुरू होती है। MCP, hooks और Agent API बाहरी उपकरणों को एक ही घटना श्रृंखला में शामिल होने की अनुमति देते हैं।

“GitHub से अलग करें” स्थानांतरण पथ को हल करता है। टीम पहले GitHub रिपॉजिटरी का मिरर बना सकती है, ताकि GitHub स्रोत सत्य बना रहे, जबकि Agent वर्कफ्लो Origin पर स्थानांतरित हो जाए; स्थिरता के बाद सिंक्रनाइजेशन को काट दिया जाएगा, और Origin रिपॉजिटरी को स्वतंत्र रूप से प्रबंधित करेगा।

यह Cursor को एजेंट, PR, समीक्षा, जांच और स्वचालन को पहले संभालने की अनुमति देता है, और फिर धीरे-धीरे अधिक इंजीनियरिंग स्थितियों को अपने प्रणाली में रखता है।

इसलिए ओरिजिन का उत्पाद तर्क स्पष्ट है: गिट वर्जन कंट्रोल को जारी रखता है, ओरिजिन जो फिर से बनाना चाहता है, वह उच्च आवृत्ति एजेंट सहयोग पर आधारित गिट के ऊपर की नियंत्रण परत है।

03 लाओ मा एक AI उत्पादन श्रृंखला को एकत्रित कर रहे हैं

पिछले एक से अधिक वर्षों में, xAI, X, SpaceX और Cursor के बीच एक श्रृंखला कार्रवाइयों ने अधिक पूर्ण ऊपरी-निचली श्रृंखला संबंध बनाया है।

xAI ने X का अधिग्रहण किया, जिसके बाद SpaceX प्रणाली में शामिल हो गया; Cursor को Colossus कॉम्प्यूटिंग संसाधन मिले, जिसके बाद यह भी SpaceX प्रणाली में शामिल हो गया। इसी बीच, Grok 4.6 जारी किया गया और Origin खुलना शुरू हो गया।

इस पथ का एमसीएल के पिछले टेस्ला पर ऊर्ध्वाधर एकीकरण के दृष्टिकोण के समान है: जब बाहरी चरणों में आवर्तन घर्षण बढ़ने लगे, तो ऊपर और नीचे की ओर विस्तार करते रहें और महत्वपूर्ण इंटरफेस को एक ही प्रणाली में शामिल करें।

एजेंट वर्तमान में इसी समस्या का सामना कर रहा है। मॉडल तर्क कर सकता है, लेकिन एक सॉफ्टवेयर कार्य के लिए रिपॉजिटरी तक पहुँच, फाइलें संशोधित करना, परीक्षण चलाना, CI संभालना, समीक्षा प्राप्त करना, संघर्ष हल करना और विफलता के बाद निष्पादन पुनः प्रारंभ करना आवश्यक है।

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

Colossus, Grok, Cursor और Origin इस चेन पर विभिन्न स्तरों के अनुरूप हैं: Colossus कंप्यूटिंग पावर प्रदान करता है, Grok मॉडल क्षमता प्रदान करता है, Cursor कोड Agent और निष्पादन वातावरण प्रदान करता है, Origin repository, PR, checks और review स्थिति को सहेजता है।

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

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

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

X की इस चेन में स्थिति अभी भी अस्पष्ट है। इसमें रियल-टाइम कंटेंट, उपयोगकर्ता संबंध, पहचान और वितरण नेटवर्क शामिल हैं, भविष्य में यह कार्यों का स्रोत और वितरण प्रवेश बिंदु बन सकता है; वर्तमान में, Grok Bot उत्पाद रूप में केवल एक “प्रतीक्षारत, केवल प्रश्नों का जवाब देने वाला चैटबॉट” नहीं, बल्कि लगातार कार्य निष्पादन की परत के अधिक समीप है।

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

और Origin यही लेयर पूरा करता है।

04 GitHub और Origin का विवाद

GitHub के पास stacked PR, merge queue, REST API हैं, और यह Copilot कोडिंग एजेंट को Issue, Actions, PR और कोड रिव्यू में लगातार एकीकृत कर रहा है। केवल फीचर लिस्ट को देखकर, दोनों के भविष्य में अधिक ओवरलैप दिखाई देगा।

अंतर मुख्य रूप से डिजाइन की पूर्वधारणाओं से आता है।

GitHub एक परिपक्व मानव डेवलपर नेटवर्क पर आधारित है, इसलिए एजेंट को मौजूदा Issue, PR, Actions और branch protection प्रणाली में शामिल करना अधिक प्राकृतिक मार्ग है।

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

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

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

इसलिए, Agent-native forge के मापदंड भी बदल जाएंगे। 22.6 commit/s ध्यान आकर्षित करता है, लेकिन commit की संख्या स्वयं सॉफ्टवेयर उत्पादकता का प्रतिनिधित्व नहीं करती। अधिक अर्थपूर्ण मापदंडों में प्रणाली में कार्य के प्रवेश से merge तक का समय, विफलता के बाद स्थानीय पुनर्स्थापन क्षमता, policy के अंतर्गत स्वचालित रूप से पूरा किए गए परिवर्तनों का अनुपात, accepted change की गणना लागत, और उच्च जोखिम वाले परिवर्तनों द्वारा खपत की गई मानवीय ध्यान क्षमता शामिल होंगी।

Origin जिसे नियंत्रित करना चाहता है, वह है repository, checks, review, permissions और events के संयोजन से बना सॉफ्टवेयर प्रोडक्शन कंट्रोल प्लेन।

इसलिए GitHub और Origin के बीच प्रतिस्पर्धा धीरे-धीरे दो मार्गों पर केंद्रित हो जाएगी: GitHub परिपक्व मानव सहयोग प्रणाली से Agent तक विस्तार करेगा, जबकि Cursor Agent के कार्यभार के अनुसार forge को पुनः डिज़ाइन करने का प्रयास करेगा।

05 लाओ माओ अगले स्तर पर हैं

वैसे, Grok 4.6 के लॉन्च के बाद, बाहरी दुनिया आसानी से benchmark के आसपास कोडिंग क्षमता, निष्कर्ष अंक और कीमत पर चर्चा करती रही। लेकिन Colossus, Grok, Cursor और Origin को एक साथ देखें, तो यह व्यवस्था वास्तव में मॉडल के बाद की सॉफ्टवेयर उत्पादन श्रृंखला तक फैल गई है।

Colossus प्रोसेसिंग पावर प्रदान करता है, Grok निष्कर्ष निकालने के लिए जिम्मेदार है, Cursor मॉडल क्षमताओं को कोड संशोधन में बदल देता है, और Origin आगे की रिपॉजिटरी स्थिति, PR, checks और review को संभालता है। जब मॉडल क्षमताएँ बढ़ती हैं, तो लाभ सीधे निष्पादन श्रृंखला के माध्यम से स्थानांतरित हो सकता है; भले ही एकल पीढ़ी के मॉडल में स्पष्ट अंतर न हो, फिर भी बाद की बुनियादी ढांचा जमा होता रह सकता है।

इसलिए, Grok 4.6 आज किसी सूची में किस स्थान पर है, शायद केवल अस्थायी परिणाम है। अधिक दीर्घकालिक प्रश्न यह है कि कौन मॉडल, निष्पादन वातावरण और सॉफ्टवेयर इंजीनियरिंग स्थिति को एक निरंतर चल रहे उत्पादन प्रणाली में व्यवस्थित कर सकता है।

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