OpenAI में Git का स्केलिंग
AI-जनित code की विस्फोटक वृद्धि OpenAI की Git infrastructure को उसकी सीमाओं तक धकेल रही है, जिससे petabyte-scale monorepos और प्रति दिन दसियों हज़ार commits को संभालने के लिए एक custom system (“Pando”) की ज़रूरत पड़ी। टिप्पणीकार इस पर बहस करते हैं कि क्या यह वास्तविक उत्पादकता लाभ है या सिर्फ “AI slop” — विशाल मात्रा में दोहराया हुआ, कम-गुणवत्ता वाला, या बार-बार फिर से लिखा जाने वाला code, जिसे इंसान अब पूरी तरह समझ या review नहीं कर सकते। यह चर्चा maintainability, security, और human developers की भविष्य की भूमिका पर व्यापक सवाल उठाती है, क्योंकि बड़े labs agent-driven software development के लिए source control को फिर से डिज़ाइन कर रहे हैं.
कोड और कमिट के विस्फोट की धारणा
- कई लोग कमिट/LOC की भारी मात्रा देखकर हैरान हैं और पूछते हैं कि यह कैसे बोझ के बजाय एक संपत्ति हो सकता है।
- अन्य लोग नोट करते हैं कि कंपनी के आकार के हिसाब से यह मात्रा शायद “हल्की” है, और पारंपरिक LOC मीट्रिक अब repository size और churn patterns की तुलना में कम अर्थपूर्ण होते जा रहे हैं।
AI-जनित “slop” बनाम उत्पादकता
- कई टिप्पणीकार AI-agent के आउटपुट को भारी मात्रा वाले “slop” के रूप में वर्णित करते हैं: जरूरत से ज़्यादा बने abstractions, दोहराया हुआ logic, लंबी-चौड़ी टिप्पणियाँ, और अंतहीन “fix” commits।
- वे बताते हैं कि छोटे-छोटे काम token और commit counts में भारी बढ़ोतरी कर देते हैं, और agents बार-बार अपनी ही गलतियों को patch करते रहते हैं।
- समर्थकों का तर्क है कि यदि compute सस्ता है तो यह स्वीकार्य है: code और tests को benchmarks पूरे होने तक बार-बार regenerate या refactor किया जा सकता है।
मानवीय निगरानी, भरोसा, और ज़िम्मेदारी
- एक पक्ष का तर्क है कि LLMs अधिकांश code reliably लिख और review कर सकते हैं, और humans केवल out-of-distribution या high-stakes मामलों में चाहिए।
- आलोचक incentives पर जोर देते हैं (खराब code के लिए लोग नौकरी से निकाले जाते हैं, models नहीं), regulatory और customer-data responsibilities, और यह ज़रूरत कि कोई वास्तव में समझे कि data कैसे process हो रहा है।
- चिंता यह भी है कि managers को अंततः “मुझे नहीं पता, model ने किया” का जवाब देना पड़ेगा, और human debuggability खो जाएगी।
यह सारा code आखिर कर क्या रहा है?
- अनुमान में ये शामिल हैं: RL environments, training/serving infrastructure, internal apps, भारी experimentation, और training के लिए हर agent edit को capture करना।
- अन्य लोगों को duplication, ephemeral scripts, और generated code को “cache” करने का संदेह है, जिसे इसके बजाय मांग पर पुनः generate किया जा सकता था।
- कुछ लोगों को चिंता है कि visible product changes अपेक्षाकृत मामूली होने और कभी-कभी clunky client apps होने के बावजूद users को मिलने वाला लाभ स्पष्ट नहीं है।
Git, monorepos, और वैकल्पिक VCS मॉडल
- कई लोग नोट करते हैं कि Git पहले से ही बड़े monorepo scales पर संघर्ष कर रहा था (Meta, Google); OpenAI agent-driven workflows के साथ समान या उससे भी बदतर सीमाओं तक पहुँच रहा है।
- इस पर बहस है कि क्या यह मूलतः monorepo problem है, Git problem है, या एक नया “agent-scale” use case (high commit rate, snapshot/log-like usage) है।
- कुछ का तर्क है कि बड़े खिलाड़ियों को Git को खींचने के बजाय पूरी तरह नए, केंद्रीकृत VCS topologies अपनाने चाहिए; अन्य लोग Git को अधिक एक protocol layer की तरह विकसित होते देखते हैं।
व्यापक निहितार्थ
- कुछ लोग इसे इस बात का प्रभावशाली प्रमाण मानते हैं कि LLMs जटिल systems जल्दी बना सकते हैं।
- अन्य इसे एक चेतावनी के रूप में देखते हैं: फटते हुए codebases, बड़े attack surfaces, और एक development culture जो clarity और maintainability के बजाय throughput को optimize करती है।