چرا آنتروپیک با افزایش ادغام روزانه کد از ۲۵۰۰ به بیش از ۳۰ هزار مورد، گیت را کنار گذاشت؟
آنتروپیک در مه ۲۰۲۶ روزانه به‌طور متوسط حدود ۲۵۰۰ تغییر کد را ادغام می‌کرد، اما این رقم تا سپتامبر به بیش از ۳۰ هزار مورد در روز رسید؛ رشدی که زیرساخت کنترل نسخه این شرکت را با مشکل مواجه کرد. آنتروپیک می‌گوید در پاسخ به این وضعیت، سامانه کنترل نسخه اختصاصی خود را با نام Scion توسعه داد و طی پنج ماه، مخزن یکپارچه کد خود را از گیت به این سامانه منتقل کرد. آنتروپیک در توضیح فنی این پروژه جزئیات طراحی آن را منتشر کرده است.
دلیل این تغییر، ابعاد زیرساخت بود. به گفته آنتروپیک، تاریخچه شاخه اصلی مخزن به‌تنهایی نزدیک به ۱۰۰ گیگابایت حجم دارد و یک نسخه کاری فشرده از آن نیز بیش از ۲۵ گیگابایت است. این شرکت همچنین روزانه در حدود ۲۵ میلیون بار برای فرایند یکپارچه‌سازی و تحویل پیوسته (CI) نسخه‌ای از کد را دریافت می‌کند؛ رقمی که هنوز محیط‌های توسعه برنامه‌نویسان، محیط‌های ایزوله عامل‌های هوش مصنوعی و کارهای پژوهشی را شامل نمی‌شود. آنتروپیک برآورد می‌کند که اگر همه این دریافت‌ها به شکل ساده و بدون بهینه‌سازی انجام می‌شد، ترافیک روزانه گیت از ۶۰۰ پتابایت فراتر می‌رفت.
این رقم آخر یک برآورد فرضی است، نه میزان ترافیکی که آنتروپیک واقعاً منتقل کرده باشد. همچنین عدد ۳۰ هزار به تعداد تغییرات ادغام‌شده در یک مخزن یکپارچه داخلی اشاره دارد، نه تعداد خطوط کد، کامیت‌ها یا درخواست‌های ادغام (pull request).
چند صد آینه گیت فقط زمان خریدند، نه راه‌حل
آنتروپیک پیش از کنار گذاشتن گیت، راهکارهای متداول برای کاهش فشار بر مخزن را امتحان کرده بود؛ از جمله کلون‌های کم‌عمق، دریافت گزینشی فایل‌ها، مخازن راه‌دور وعده‌دهنده (promisor remotes)، آینه‌های داخلی گیت و نسخه‌های snapshot مخزن که در فضای ذخیره‌سازی اشیای دودویی نگهداری می‌شدند. این شرکت می‌گوید: «همه این روش‌ها را به کار گرفته‌ایم» و در اوج فعالیت، برای مدیریت بار کاری چند صد آینه داخلی گیت را اداره می‌کرد.
با افزایش سرعت ادغام تغییرات، نگهداری و مدیریت هر یک از این راهکارها دشوارتر شد. به گفته آنتروپیک، نسخه‌های snapshot در فاصله میان به‌روزرسانی‌ها بیش از پیش از آخرین وضعیت شاخه اصلی عقب می‌ماندند. همچنین، حفظ عملکرد عملیات وابسته به تاریخچه، مانند مقایسه تغییرات (diff) و مشخص‌کردن نویسنده خطوط کد (blame)، در کلون‌های ناقص به مراقبت و مدیریت فزاینده‌ای نیاز داشت.
ریشه مشکل به یکی از فرض‌های بنیادی طراحی گیت برمی‌گشت: این سامانه انتظار دارد هر کاربر یک نسخه کامل از مخزن را در اختیار داشته باشد و بتواند به‌صورت آفلاین روی آن کار کند. آنتروپیک این رویکرد را برای بیشتر مخازن «طراحی درستی» می‌داند و آن را یکی از دلایل اصلی تبدیل‌شدن گیت به استاندارد رایج کنترل نسخه معرفی می‌کند. با این حال، این فرض در محیطی که تقریباً همه دریافت‌کنندگان کد عامل‌های هوش مصنوعی یا کارهای خودکار CI هستند، دیگر به‌خوبی جواب نمی‌دهد.
در Scion، ثبت تغییرات روی سرور انجام می‌شود
آنتروپیک پنج اصل اساسی را برای طراحی Scion برمی‌شمارد. نخستین تفاوتی که کاربران گیت متوجه آن می‌شوند، محل انجام عملیات است. این شرکت می‌گوید: «در Scion، هر کامیت، بازپایه‌گذاری (rebase) یا ادغام روی سرور انجام می‌شود؛ بنابراین، چیزی برای push کردن وجود ندارد.» در این ساختار، هزینه ثبت یک تغییر به اندازه خود تغییر بستگی دارد، نه به حجم کل مخزن.
داده‌های مخزن نیز در یک محل گردآوری نمی‌شوند. اطلاعات Scion به‌صورت توزیع‌شده نگهداری می‌شود و هر بخش می‌تواند مستقل از سایر بخش‌ها مقیاس‌پذیر شود. آنتروپیک می‌گوید «هیچ نسخه کاملاً بازسازی‌شده‌ای از مخزن در هیچ‌جا، حتی روی سرور، وجود ندارد». از آنجا که این سامانه معادلی برای فایل‌های pack گیت ندارد، به فرایند نگهداری و بازسازی دوره‌ای مخزن نیز نیازی نیست.
داشتن نسخه کاری اختیاری است و ساختار سامانه از ابتدا بر دریافت گزینشی کد تکیه دارد. برای مثال، اگر یک کار CI به اختلاف میان یک کامیت و نقطه پایه ادغام آن نیاز داشته باشد، می‌تواند این اختلاف را مستقیماً از سرور درخواست کند و لازم نیست ابتدا کد را دریافت کند. آنتروپیک همچنین استفاده از شاخه‌ها و برچسب‌ها را، به‌جز ارجاع‌های اصلی و شاخه‌های انتشار، تشویق نمی‌کند؛ زیرا از نگاه این شرکت، هر وضعیتی که همه سرورها باید درباره آن به توافق برسند، می‌تواند در آینده به مانعی برای مقیاس‌پذیری تبدیل شود.
البته این ایده‌ها کاملاً بی‌سابقه نیستند. آنتروپیک به سامانه Piper گوگل و Sapling شرکت متا به‌عنوان نمونه‌های پیشین اشاره می‌کند که در طراحی Scion از تجربه آن‌ها بهره گرفته است. این شرکت تأکید می‌کند: «Scion به‌هیچ‌وجه جایگزینی مناسب برای گیت در استفاده عمومی نیست.»
کلود خط لوله انتقال کد به Scion را بازنویسی کرد
برای انتقال تاریخچه گیت به Scion، آنتروپیک به یک خط لوله پردازش داده نیاز داشت و نسخه نخست آن را عمدتاً به‌صورت دستی نوشت. سپس از «یک نسخه اولیه و داخلی از Claude Mythos Preview» خواست کل این خط لوله را بازنویسی کند. به گفته این شرکت، مدل بدون دریافت دستورالعمل بیشتری نسخه‌ای تولید کرد که ۲۰ برابر حافظه کمتری مصرف می‌کرد و چهار برابر سریع‌تر بود؛ در عین حال، تمام قواعد ضمنی مربوط به ترتیب ورود داده‌ها و ساختارهای داده را حفظ کرد.
این نتیجه به یک بازنویسی مشخص از یک خط لوله مربوط است و روش انجام آزمون‌های سنجش عملکرد آن منتشر نشده است. از این رو، باید آن را در کنار دیگر ارقامی قرار داد که آنتروپیک خودش به دست آورده و گزارش کرده است؛ برای نمونه، این شرکت عملکرد Opus 5.5 را در آزمون Terminal-Bench نیز خودش ارزیابی کرد و به‌جای استفاده از تابلوی عمومی نتایج، به آزمون داخلی متکی بود.
Scion تنها محصولی نبود که آنتروپیک طی آن پنج ماه توسعه داد. این شرکت می‌گوید ابزار بازبینی کد Antique، سامانه جست‌وجوی کد و یک سامانه مدیریت هویت و دسترسی (IAM) برای کنترل نسخه را نیز عرضه کرده است. با این حال، آنتروپیک هیچ رقمی درباره هزینه مهاجرت، تعداد توکن‌های مصرف‌شده یا میزان مشارکت Claude در نوشتن کد Scion منتشر نکرده است.
هیچ سازمانی خارج از آنتروپیک نمی‌تواند از این ابزارها استفاده کند. آنتروپیک می‌گوید ارائه Scion به شکلی که برای سازمان‌های دیگر نیز کاربرد گسترده داشته باشد، «دشوار خواهد بود»، زیرا این سامانه تفاوت‌های چشمگیری با گیت دارد و ابزارهای اختصاصی بازبینی کد، جست‌وجوی کد و CI را نیز با خود همراه می‌کند.
به گفته آنتروپیک، این مفاهیم «عملاً فقط برای مخازن یکپارچه بسیار عظیم معنا پیدا می‌کنند؛ مخازنی که یا ده‌ها هزار مهندس روی آن‌ها کار می‌کنند یا انبوهی از عامل‌ها با سرعت زیاد کد می‌نویسند». این شرکت ابزارهای خود را برای گروه دوم نیز توسعه می‌دهد: Claude اکنون می‌تواند برنامه‌های خودش را بنویسد تا حداکثر ۱۰۰۰ عامل را اجرا کند و خودش آن‌ها را به کار بیندازد.