آنتروپیک پس از افزایش چشمگیر کدنویسی عامل‌های هوش مصنوعی، سیستم کنترل نسخه اختصاصی خود را جایگزین گیت کرد
شرکت آنتروپیک (Anthropic) مخزن یکپارچه کدهای داخلی خود را از گیت (Git) به یک سیستم کنترل نسخه اختصاصی منتقل کرده که از پایه طراحی و ساخته است. دلیل این تصمیم روشن است: عامل‌های هوش مصنوعی این شرکت اکنون با چنان سرعتی کد تولید می‌کنند که زیرساخت مبتنی بر گیت دیگر توان پاسخ‌گویی به این حجم از فعالیت را ندارد.
آنتروپیک در مطلبی در وبلاگ مهندسی خود اعلام کرد که در ماه مه ۲۰۲۶، روزانه به‌طور میانگین حدود ۲۵۰۰ تغییر کد را در شاخه اصلی ادغام می‌کرد. این رقم تا سپتامبر به بیش از ۳۰ هزار تغییر در روز رسید. در نتیجه، دیگر سرعت کدنویسی عامل محدودکننده توسعه نرم‌افزار نبود؛ بلکه سیستم کنترل نسخه به گلوگاه اصلی تبدیل شده بود.
سامانه جدید «Scion» نام دارد و گروهی هفت‌نفره از مهندسان آنتروپیک آن را همراه با ابزار بازبینی کدی به نام «Antique» و چند سامانه مرتبط دیگر توسعه داده‌اند. انتقال کامل زیرساخت به این سیستم جدید تنها پنج ماه طول کشید.
چرا گیت دیگر پاسخ‌گوی نیازهای آنتروپیک نبود؟
گیت از ابتدا بر اساس معماری غیرمتمرکز طراحی شده است. در این معماری، هر نسخه کپی‌شده از مخزن، یک مخزن کامل محسوب می‌شود و می‌تواند بدون اتصال به شبکه، تفاوت نسخه‌ها را محاسبه کند، تاریخچه تغییرات را بخواند و هر نسخه دلخواه از کد را بازیابی کند. این ویژگی برای بیشتر تیم‌های توسعه نرم‌افزار مناسب است، اما وقتی اندازه مخزن بسیار بزرگ باشد و بیشتر استفاده‌کنندگان آن ماشین‌ها باشند، محدودیت‌های این معماری آشکار می‌شود.
حجم تاریخچه شاخه اصلی کدهای آنتروپیک به حدود ۱۰۰ گیگابایت رسیده و حتی نسخه فشرده فایل‌های کاری آن بیش از ۲۵ گیگابایت حجم دارد. این شرکت تنها برای فرایند یکپارچه‌سازی مداوم (CI)، روزانه حدود ۲۵ میلیون بار کدها را از مخزن دریافت می‌کند؛ آن هم بدون احتساب محیط‌های توسعه برنامه‌نویسان، محیط‌های ایزوله عامل‌های هوش مصنوعی و وظایف پژوهشی. اگر تمام این دریافت‌ها به روش معمول گیت انجام می‌شد، حجم تبادل داده روزانه از ۶۰۰ پتابایت فراتر می‌رفت.
تیم مهندسی ابتدا راهکارهای رایج را امتحان کرد؛ از جمله کپی‌برداری کم‌عمق از مخزن (Shallow Clone)، دریافت گزینشی فایل‌ها (Sparse Checkout)، مخازن راه‌دور Promisor، ذخیره نسخه‌های لحظه‌ای در فضای ذخیره‌سازی اشیا و ایجاد آینه‌های داخلی گیت. در مقطعی، آنتروپیک چندصد سرور آینه گیت را به‌طور هم‌زمان اداره می‌کرد. این راهکارها موقتاً مشکل را کاهش دادند، اما با افزایش تعداد تغییرات ادغام‌شده، مدیریت زیرساخت روزبه‌روز دشوارتر شد.
در ادامه، مهندسان به نکته مهمی پی بردند. آنتروپیک نیز مانند بسیاری از شرکت‌ها، با وجود معماری غیرمتمرکز گیت، عملاً از آن به‌عنوان یک سیستم متمرکز با یک مرجع اصلی و معتبر استفاده می‌کرد. تقریباً تمام استفاده‌کنندگان مخزن، عامل‌های هوش مصنوعی و فرایندهای خودکاری بودند که همیشه به شبکه دسترسی داشتند. بنابراین مهم‌ترین مزیت گیت، یعنی امکان کار آفلاین، نه‌تنها کمکی به آنتروپیک نمی‌کرد، بلکه به مانعی برای توسعه زیرساخت تبدیل شده بود.
سیستمی برای استفاده‌کنندگانی که همیشه آنلاین هستند
Scion این الگو را معکوس کرده است. در معماری جدید، عملیات سنگین مانند ثبت تغییرات (Commit)، ادغام کدها (Merge)، بازتنظیم مبنای تغییرات (Rebase)، شناسایی نویسنده تغییرات هر خط کد (Blame) و بررسی تاریخچه فایل‌ها روی سرور انجام می‌شود. در مقابل، نرم‌افزار سمت کاربر تنها یک حافظه کش محلی با اندازه محدود نگه می‌دارد، فایل‌ها را در محیط کاری قرار می‌دهد و تغییرات را ردیابی می‌کند. به این ترتیب، نیاز به ذخیره‌سازی اطلاعات روی دستگاه کاربر به‌شدت کاهش می‌یابد.
نرم‌افزار سمت کاربر همچنین تمام درخواست‌های اطلاعاتی را از طریق رابط برنامه‌نویسی کاربردی (API) در دسترس قرار می‌دهد. به همین دلیل، بسیاری از وظایف یکپارچه‌سازی مداوم دیگر نیازی به داشتن نسخه محلی مخزن ندارند. برای مثال، فرایندی که فقط می‌خواهد تفاوت دو نسخه کد را بررسی کند، می‌تواند مستقیماً از سرور درخواست کند. آنتروپیک می‌گوید بدون چنین قابلیتی، اجرای گسترده فرایندهای خودکار یافتن تغییر مشکل‌ساز با روش Bisect و بازگرداندن تغییرات با Revert عملاً امکان‌پذیر نبود.
سایر تصمیم‌های طراحی Scion نیز از همین منطق پیروی می‌کنند. ثبت تغییرات روی سرور و در قالب مجموعه‌هایی موسوم به Changeset انجام می‌شود که فقط اطلاعات مربوط به بخش‌های تغییرکرده را نگه می‌دارند. بنابراین هزینه پردازش هر تغییر به اندازه همان تغییر بستگی دارد، نه حجم کل مخزن. استفاده از شاخه‌ها (Branch) و برچسب‌ها (Tag) نیز توصیه نمی‌شود، زیرا نگهداری وضعیت مشترکی که تمام سرورها باید درباره آن توافق داشته باشند، گسترش‌پذیری سیستم را دشوار می‌کند. دریافت فایل‌ها نیز به‌صورت گزینشی یا مجازی انجام می‌شود تا هر فرایند فقط فایل‌هایی را دریافت کند که واقعاً به آن‌ها نیاز دارد.
تمام داده‌ها در Scion بر اساس محتوای خود آدرس‌دهی می‌شوند و پس از ذخیره‌سازی دیگر تغییر نمی‌کنند. به همین دلیل، هر سرور یا حافظه کش می‌تواند بدون هماهنگی با سایر سرورها به درخواست‌ها پاسخ دهد. معماری Scion سه لایه دارد: یک سرویس پس‌زمینه روی هر گره، حافظه‌های کش منطقه‌ای و سرورهای مرجع اصلی که از پایگاه داده Spanner و فضای ذخیره‌سازی ابری استفاده می‌کنند. به گفته آنتروپیک، نرخ پاسخ‌گویی مستقیم از حافظه کش در هر سه لایه بیش از ۹۹ درصد است.
آنتروپیک از بهبود قابل‌توجه عملکرد زیرساخت خود خبر داده است. Scion در مقایسه با مجموعه سرورهای آینه گیت قبلی، ۲۰۰ برابر کمتر از منابع پردازنده و حافظه استفاده می‌کند. دریافت کد برای فرایندهای یکپارچه‌سازی مداوم و فعالیت‌های پژوهشی که پیش‌تر چند دقیقه طول می‌کشید، اکنون ظرف چند ثانیه انجام می‌شود. همچنین ۲۵ درصد از ظرفیت پردازشی CPU در زیرساخت یکپارچه‌سازی مداوم آزاد شده است.
میچ اشلی (Mitch Ashley)، معاون و مسئول حوزه‌های خریداران فناوری و مدیران ارشد اطلاعات و مهندسی چرخه عمر نرم‌افزار در شرکت The Futurum Group، گفت: «کنترل نسخه نیز اکنون به یکی از عرصه‌های رقابت بر سر توسعه و تحویل نرم‌افزار مبتنی بر عامل‌های هوش مصنوعی تبدیل شده است. ساخت Scion توسط آنتروپیک و توافق انویدیا درباره Hugging Face نشان می‌دهد که پیشگامان هوش مصنوعی، زیرساخت نگهداری کدها و مدل‌ها را چیزی می‌دانند که باید مالکیت و کنترل آن را در اختیار داشته باشند؛ آن هم پس از یک دهه که بیشتر شرکت‌ها این مسئولیت را به گیت‌هاب سپرده بودند.»
استفاده از تجربه‌های پیشین با کمک هوش مصنوعی
ساخت سیستم‌های اختصاصی برای مدیریت مخازن یکپارچه بسیار بزرگ، ایده تازه‌ای نیست. گوگل در سال ۲۰۱۶ از مخزنی با حدود دو میلیارد خط کد در ۹ میلیون فایل منبع خبر داده بود که با سیستم اختصاصی Piper مدیریت می‌شد. شرکت متا نیز حدود یک دهه صرف توسعه سیستم Sapling کرد، زیرا ابزارهای عمومی کنترل نسخه نمی‌توانستند مخزنی با آن ابعاد را مدیریت کنند. آنتروپیک می‌گوید در طراحی Scion از تجربه‌های این دو شرکت استفاده کرده است.
آنچه پروژه آنتروپیک را متمایز می‌کند، سرعت توسعه آن است. مدل هوش مصنوعی Claude بخش عمده کدهای این سیستم را نوشته است. برای نمونه، یکی از نسخه‌های اولیه داخلی Claude Mythos Preview توانست خط لوله دریافت و ورود داده‌ها را که پیش‌تر به‌صورت دستی برنامه‌نویسی شده بود، بازنویسی کند. به گفته آنتروپیک، نسخه جدید ۲۰ برابر حافظه کمتری مصرف می‌کرد و چهار برابر سریع‌تر اجرا می‌شد.
نقش مهندسان نیز در این فرایند تغییر کرده است. تمام اعضای تیم گفته‌اند که Claude اکنون بهتر از خودشان کدنویسی می‌کند. بااین‌حال، مسئولیت طراحی معماری سیستم و تصمیم‌گیری درباره موازنه‌های فنی همچنان بر عهده مهندسان بوده است. در بسیاری از موارد، وظیفه آن‌ها این بوده که به Claude «نه» بگویند. برای مثال، برخی عامل‌ها تلاش می‌کردند به‌جای درخواست اطلاعات از ابزار بازبینی کد، با پیمایش کامل گزارش ثبت تغییرات، اطلاعات موردنیاز را به روشی پرهزینه پیدا کنند. اکنون بازبین‌ها به‌جای بررسی تک‌تک خطوط کد، هدف و مقصود هر تغییر را ارزیابی می‌کنند.
این تیم همچنین از سامانه‌های پایش مبتنی بر Claude استفاده می‌کند که آن‌ها را «Superfans» نامیده است. هرکدام از این سامانه‌ها داده‌های پایش عملکرد یک جزء مشخص را زیر نظر می‌گیرند و مشکلات ظریفی را شناسایی می‌کنند که ممکن است از دید سامانه‌های هشدار معمولی پنهان بمانند.
بازنگری در صف ادغام تغییرات کد
شاید مهم‌ترین درس این تجربه برای تیم‌های دواپس (DevOps)، تغییراتی باشد که در مرحله بعدی توسعه نرم‌افزار رخ می‌دهد. آنتروپیک معتقد است صف سنتی ادغام تغییرات که بر یک قفل سراسری متکی است، در مقیاس فعالیت عامل‌های هوش مصنوعی کارایی خود را از دست می‌دهد. وقتی هزاران تغییر می‌توانند در فاصله اجرای آزمایش‌ها وارد شاخه اصلی شوند، مفهوم و نقش یکپارچه‌سازی مداوم نیز تغییر می‌کند. این شرکت اکنون بیشتر بر آزمایش‌های خودکار پس از ادغام کد و پیش از استقرار نرم‌افزار تکیه دارد. تداخل میان تغییرات همچنان رخ می‌دهد، اما Claude معمولاً آن‌ها را به‌سرعت برطرف می‌کند.
این رویکرد برای بیشتر سازمان‌های توسعه نرم‌افزار تغییر بزرگی محسوب می‌شود. اشلی دراین‌باره گفت: «بیشتر خطوط لوله توسعه نرم‌افزار در شرکت‌ها هنوز بر این فرض استوارند که پیش از ادغام هر تغییر، یک انسان آن را بررسی می‌کند. تیم‌هایی که عامل‌های کدنویسی را به فرایند توسعه اضافه می‌کنند، باید از همین حالا حجم ادغام تغییرات را زیر نظر بگیرند و برای آزمایش، بازگرداندن تغییرات و ثبت سوابق تأییدهایی که پس از ادغام انجام می‌شوند، برنامه‌ریزی کنند.»
Scion قرار نیست جایگزین عمومی گیت شود
آنتروپیک تأکید می‌کند که Scion برای همه مناسب نیست. استفاده از چنین سیستمی تنها برای مخازن یکپارچه واقعاً عظیمی توجیه دارد که ده‌ها هزار مهندس یا انبوهی از عامل‌های هوش مصنوعی با آن‌ها کار می‌کنند. افزون بر این، Scion به ابزارهای اختصاصی بازبینی کد، جست‌وجو و یکپارچه‌سازی مداوم نیاز دارد. آنتروپیک نیز برنامه‌ای برای انتشار این سیستم ندارد.
در عوض، این شرکت قصد دارد ایده‌ها و تجربه‌های خود را با گیت‌هاب، گیت‌لب و جامعه متن‌باز به اشتراک بگذارد. از دید آنتروپیک، ضرورتی ندارد که سرورهای گیت دقیقاً مانند نرم‌افزارهای سمت کاربر آن عمل کنند. پلتفرم‌های میزبانی مخازن کد می‌توانند رابط‌های برنامه‌نویسی غنی‌تری در سمت سرور ارائه دهند، شیوه مذاکره برای تعیین داده‌های موردنیاز هنگام دریافت اطلاعات از مخزن می‌تواند تغییر کند و قابلیت‌های دریافت گزینشی و کم‌عمق گیت نیز می‌توانند هماهنگ‌تر و کارآمدتر عمل کنند.
آنتروپیک پیش‌بینی می‌کند که طی شش تا ۱۲ ماه آینده، تیم‌های بیشتری با محدودیت‌های مشابه روبه‌رو شوند. بیشتر این تیم‌ها قرار نیست سیستم کنترل نسخه اختصاصی خود را بسازند. بااین‌حال، اگر عامل‌های هوش مصنوعی سهم بیشتری از کدنویسی شما را بر عهده می‌گیرند، بهتر است از همین حالا بررسی کنید که کدام بخش از فرایند توسعه نرم‌افزارتان زودتر به محدودیت خواهد رسید. شاید مشکل اصلی نه در مرحله ساخت نرم‌افزار، بلکه در خود مخزن کد باشد.
پرسش‌های متداول
۱. چرا آنتروپیک گیت را با Scion جایگزین کرد؟
عامل‌های هوش مصنوعی آنتروپیک با سرعتی کد تولید و ادغام می‌کردند که زیرساخت مبتنی بر گیت دیگر نمی‌توانست آن را به‌شکل کارآمد مدیریت کند. Scion برای پشتیبانی از مخازن بسیار بزرگ، تغییرات پرتعداد کد و میلیون‌ها بار دریافت روزانه فایل‌ها طراحی شده است.
۲. Scion چه تفاوتی با گیت دارد؟
برخلاف معماری غیرمتمرکز گیت، Scion برای مدیریت ثبت تغییرات، ادغام کد، بازتنظیم مبنای تغییرات و پاسخ‌گویی به درخواست‌های اطلاعاتی مخزن، به سرورهای متمرکز متکی است. نرم‌افزارهای سمت کاربر حافظه کش محلی کوچک‌تری نگه می‌دارند که مصرف منابع را کاهش می‌دهد و گسترش‌پذیری سیستم را بهبود می‌بخشد.
۳. Scion چه بهبودهایی در زیرساخت توسعه آنتروپیک ایجاد کرده است؟
Scion در مقایسه با زیرساخت قبلی آنتروپیک که بر سرورهای آینه گیت متکی بود، نیاز به پردازنده و حافظه را ۲۰۰ برابر کاهش داده، دریافت کد در فرایندهای یکپارچه‌سازی مداوم را سریع‌تر کرده و ۲۵ درصد از ظرفیت پردازشی CPU این زیرساخت را آزاد کرده است.