Anthropic में source control का पुनःडिज़ाइन

मूल लेख ↗ Hacker News चर्चा ↗

Anthropic ने “Scion” नाम का एक custom centralized source control system बनाया है, जो अपने तेज़ी से बढ़ते monorepo और coding agents की fleets के लिए git को replace करने के लिए है; अब ये agents प्रतिदिन tens of thousands of merges और tens of millions of code checkouts generate करते हैं। Commenters इस design की तुलना Perforce या Subversion से करते हैं और बहस करते हैं कि असली समस्या git की scalability है, Anthropic की monorepo और workflow choices हैं, या AI-generated churn की भारी मात्रा। यह thread agent-driven development पर व्यापक सवाल उठाती है: हर line के बजाय intent को कैसे review किया जाए, क्या इतनी गति टिकाऊ या समझदारी भरी है, और Anthropic उस tooling को open-source क्यों नहीं कर रहा जिसे इतने external code पर train किया गया था।

Anthropic ने Scion क्यों बनाया

  • Git Anthropic के पैमाने पर विफल होने लगा: ~100 GB main-branch history, ~25 GB working copy, CI और agents के लिए ~25M checkouts/day।
  • हर job के लिए naïvely cloning करने पर ~600 PB/day traffic का मतलब होता; caching और repacking के बावजूद लोग रिपोर्ट करते हैं कि git repo maintenance brittle होती जा रही है।
  • Monorepo जानबूझकर चुना गया है: atomic cross-cutting changes, consistent tooling, और agents के लिए आसान access देता है, लेकिन scaling समस्याएँ बढ़ा देता है।

Design और comparisons

  • Scion centralized और always-online है: सभी commits/merges/rebases server पर होते हैं; clients सिर्फ ज़रूरत के blobs on demand fetch करते हैं।
  • History और file contents immutable, content-addressed objects हैं जो log + object store में रखे जाते हैं, और derived data asynchronously compute होता है।
  • कई commenters कहते हैं कि यह “sounds like” Subversion, Perforce, ClearCase, या Google का Piper / Meta का Sapling, यानी central server + virtualized working trees।
  • दूसरे लोग EdenFS, artifact-based filesystems, और jj-based tooling में मिलते-जुलते विचारों की ओर इशारा करते हैं; कुछ इसे विशाल monorepos के लिए अनिवार्य pattern मानते हैं।

Scale, agents, और workflow बदलाव

  • Merges ~2.5k/day से बढ़कर >30k/day हो गए, जिनका बड़ा कारण agents हैं। कुछ लोग इसे “gradient descent with code” या brute-force exploration कहते हैं।
  • CI/merge-queue semantics बदलते हैं: आप पूरे repo को globally lock नहीं कर सकते, इसलिए अधिक काम post-merge और pre-deploy किया जाता है; concurrent semantic conflicts अपेक्षित हैं और agents द्वारा ठीक किए जाते हैं।
  • Human engineers की भूमिका problems चुनने, architectural tradeoffs करने, और agents को बार-बार “no” कहने, फिर हर line से ज़्यादा intent review करने के रूप में बताई जाती है।

Quality, safety, और maintainability concerns

  • कई लोग 30k merges/day और high churn को लेकर असहज हैं: spaghetti code, jank, और “AI slop” के समझे जाने से पहले ही जमा होने का डर है।
  • कई लोग नोट करते हैं कि आज भी subtle bugs से बचने के लिए उन्हें AI-generated code की बहुत सावधानी से समीक्षा करनी पड़ती है; उन्हें संदेह है कि Anthropic इस velocity पर सचमुच हर चीज़ oversee कर सकता है।
  • Centralized, online-only VCS outages, security, और offline workflows के नुकसान को लेकर चिंताएँ पैदा करता है; दूसरे जवाब देते हैं कि बड़े orgs पहले से ही हमेशा-online, API-driven setups में रहते हैं।

Open-sourcing, generality, और broader implications

  • Anthropic कहता है कि Scion बहुत bespoke है और git से इतना अलग है कि इसे उपयोगी ढंग से open-source नहीं किया जा सकता; कई readers code के बिना एक detailed blog post से निराश हैं।
  • कुछ लोगों का तर्क है कि अधिकांश organizations को git ही रखना चाहिए या Perforce-like systems खरीदने चाहिए; केवल frontier labs, जिनके पास huge agent fleets और token budgets हैं, उन्हें Scion-style tooling चाहिए।
  • व्यापक बहस: LLMs infrastructure (VCS, CI, deploy, dashboards) को फिर से invent करना सस्ता बनाते हैं, लेकिन यह स्पष्ट नहीं है कि इसका कितना हिस्सा स्थायी value देता है बनाम churn और tech debt।