گیت در مقیاس عامل‌های هوش مصنوعی از کار می‌افتد؛ آنتروپیک در پنج ماه جایگزینی ساخت که در اختیار هیچ‌کس قرار نمی‌گیرد
تحلیل
بلر هیز | ذهن آکادمی فورکست
در ماه مه ۲۰۲۶، به‌طور متوسط روزانه حدود ۲۵۰۰ تغییر کد در آنتروپیک ادغام می‌شد. طبق داده‌های اعلام‌شده از سوی شرکت، این رقم تا سپتامبر به بیش از ۳۰ هزار مورد در روز رسید؛ افزایشی ۱۲ برابری در چهار ماه. این جهش، نقطه‌ای است که ساختار زیرساخت به مرز تحمل خود می‌رسد. آنتروپیک در مطلب خود با عنوان «بازطراحی کنترل نسخه» مشخص می‌کند که چه چیزی دیگر جواب‌گو نیست: برنامه‌نویسی دیگر گلوگاه اصلی نیست؛ محدودیت از زیرساخت توسعه نرم‌افزار ناشی می‌شود که برای مقیاس فعالیت انسان‌ها طراحی شده است، از جمله سامانه‌های کنترل نسخه، ساخت نرم‌افزار و یکپارچه‌سازی مداوم (CI). این همان گلوگاهی است که گزارش پشته چهارلایه نیز شناسایی کرده بود: در پذیرش عامل‌های هوش مصنوعی در سازمان‌ها، زیرساخت، نه کیفیت مدل، عامل محدودکننده است؛ آن هم در حوزه‌های حافظه، اجرا، ابزارها و حاکمیت.
آنچه از کار می‌افتد، یکی از فرض‌های بنیادین طراحی گیت است. گیت برای کار توزیع‌شده و آفلاین ساخته شده بود؛ اما به گفته آنتروپیک، تقریباً تمام کلاینت‌های این شرکت عامل‌های هوش مصنوعی و وظایف خودکار بودند که بنا بر ماهیت فعالیتشان همواره آنلاین‌اند. شرکت توضیح می‌دهد: «ویژگی‌هایی که گیت را برای کار توزیع‌شده و آفلاین به گزینه‌ای عالی تبدیل می‌کنند، عملاً توانایی ما را برای مقیاس‌پذیری مختل می‌کردند.» ارقام اعلام‌شده از سوی شرکت ابعاد مسئله را روشن می‌کند: تنها سامانه CI روزانه در حدود ۲۵ میلیون بار دریافت نسخه‌های کاری کد را انجام می‌دهد؛ آن هم پیش از احتساب محیط‌های توسعه برنامه‌نویسان، محیط‌های ایزوله عامل‌ها و کارهای پژوهشی. اگر داده‌ها به شیوه ساده و بدون بهینه‌سازی دریافت شوند، ترافیک گیت به بیش از ۶۰۰ پتابایت در روز می‌رسد. راهکار متداول مدتی جواب می‌داد؛ آنتروپیک در اوج فعالیت خود چند صد آینه داخلی گیت داشت. بااین‌حال، به گفته شرکت، این آینه‌ها «برای ما زمان خریدند، اما با افزایش نرخ ادغام تغییرات، بهره‌برداری از آن‌ها دشوارتر شد». راه‌حل مبتنی بر معکوس‌کردن فرض اولیه، در بیان ساده است: فرض کنید کلاینت‌ها همیشه آنلاین هستند و بخش عمده کار را به سرور بسپارید.
سامانه جایگزین داخلی آنتروپیک، Scion، بر همین تغییر رویکرد استوار است. سرور تاریخچه فایل‌ها و اطلاعات مربوط به منشأ خطوط کد (blame) را ارائه می‌کند، کامیت‌ها را می‌سازد و عملیات ادغام و بازپایه‌گذاری (rebase) را انجام می‌دهد؛ کلاینت نیز تنها یک حافظه نهان محلی با اندازه محدود از اشیای موردنیاز را نگه می‌دارد. واحد اصلی کار، «مجموعه تغییرات» (changeset) است؛ مدخلی در یک گزارش ثبت پیشاپیش (write-ahead log) که در سمت سرور ایجاد می‌شود. طبق گزارش شرکت، در این معماری دیگر نیازی به دریافت و پردازش فایل‌های بسته‌بندی‌شده (packfiles)، قفل‌گذاری، هماهنگی میان سرورها یا جابه‌جایی ارجاع‌ها (refs) نیست. استفاده از شاخه‌ها و برچسب‌ها نیز عمداً تشویق نمی‌شود، زیرا نگهداری وضعیت سراسری‌ای که همه سرورها باید بر سر آن توافق داشته باشند، به مسئله‌ای برای مقیاس‌پذیری تبدیل می‌شود. دریافت نسخه‌های کاری به‌صورت تنک انجام می‌شود و محیط فایل‌ها مجازی است؛ بنابراین، فایل‌ها فقط هنگام نیاز ایجاد یا در دسترس قرار می‌گیرند. نتایج اعلام‌شده از سوی آنتروپیک عبارت‌اند از: نرخ اصابت به حافظه نهان در هر سطح بیش از ۹۹ درصد است؛ ردپای زیرساخت از نظر مصرف پردازنده و حافظه، در مقایسه با معماری قدیمی مبتنی بر آینه‌های گیت، ۲۰۰ برابر کوچک‌تر شده است؛ دریافت نسخه‌های کاری با سرعتی دو مرتبه بزرگی بیشتر انجام می‌شود و به‌جای چند دقیقه، چند ثانیه طول می‌کشد؛ همچنین، تنها در بخش CI، ظرفیت قابل‌استفاده پردازنده ۲۵ درصد افزایش یافته است.
داستان ساخت نرم‌افزار نیز همین تغییر رویکرد را نشان می‌دهد. تیمی متشکل از هفت نفر طی پنج ماه مخزن یکپارچه عظیم شرکت (monorepo) را از گیت به سامانه جدید منتقل کرد و هم‌زمان ابزار بازبینی کد، جست‌وجوی کد، مدیریت دسترسی به کنترل نسخه و حدود شش سامانه مرتبط دیگر را نیز ساخت؛ آن هم در شرایطی که حجم ادغام تغییرات در همان دوره حدود ۱۰ برابر افزایش می‌یافت. بر اساس گزارش شرکت، یکی از نسخه‌های اولیه داخلی Claude Mythos Preview توانست خط لوله دست‌نویس انتقال داده از گیت به Scion را بدون دریافت دستورالعمل بیشتر بازنویسی کند؛ نسخه جدید ۲۰ برابر حافظه کمتری مصرف می‌کرد و چهار برابر سریع‌تر اجرا می‌شد. در نتیجه، نقش مهندسان به سطح بالاتری منتقل شد. به تعبیر مطلب آنتروپیک، «نقش مهندسان این بود که به کلود بگویند نه»؛ یعنی به‌جای بررسی تک‌تک خطوط کد، هدف و منطق تغییرات را ارزیابی کنند. این تقسیم کار همان الگویی است که تحریریه ما در حوزه ابزارهای توسعه نرم‌افزار نیز شاهد شکل‌گیری آن بوده است؛ الگویی که در آن نسبت بازبینی کد به مسئله اصلی تبدیل شده است: عامل‌ها با سرعت بالا گزینه‌ها را بررسی می‌کنند و کد تولید می‌کنند، اما انسان‌ها تصمیم می‌گیرند کدام تغییرات باقی بمانند.
روشن‌ترین نمود این نقطه شکست، اتفاقی است که برای صف ادغام تغییرات رخ داده است. در مطلب آنتروپیک آمده است: «برای مثال، صف ادغام اصولی در مقیاس فعالیت عامل‌ها چندان منطقی به نظر نمی‌رسد. وقتی صدها یا حتی هزاران تغییر می‌توانند هم‌زمان با اجرای آزمون‌ها ادغام شوند، اصلاً منظور از CI چیست؟» شرکت نتوانست قفل سراسری مخزن را که در صف‌های ادغام متداول صنعت استفاده می‌شود، بازآفرینی کند؛ در عوض، سرمایه‌گذاری خود را بر آزمون‌گیری پس از ادغام و پیش از استقرار متمرکز کرد. تغییرات هم‌زمان ممکن است با یکدیگر تعارض پیدا کنند، اما به گفته شرکت، «کلود معمولاً می‌تواند این تعارض‌ها را سریع‌تر از زمانی برطرف کند که انسان‌ها صرفاً برای شناسایی آن‌ها نیاز دارند». بااین‌حال، این سامانه برای فروش عرضه نشده است. Scion یک ابزار داخلی است و کد آن متن‌باز نشده؛ آنتروپیک نیز صریحاً اعلام می‌کند که این سامانه «به‌هیچ‌وجه جایگزینی مناسب برای گیت در استفاده عمومی نیست». Scion فقط در شرایطی معنا پیدا می‌کند که با مخازن یکپارچه عظیمی روبه‌رو باشیم که ده‌ها هزار مهندس روی آن‌ها کار می‌کنند یا انبوهی از عامل‌های هوش مصنوعی با سرعت بسیار زیاد کد تولید می‌کنند.
برای توسعه‌دهندگان و سازندگان ابزارها، آنچه عرضه شده، شناخت مسئله و الگوهای طراحی است، نه خود محصول. آنتروپیک پیش‌بینی می‌کند که «این دسته از مشکلات طی شش تا ۱۲ ماه آینده رایج‌تر خواهند شد». پیشنهادهای این شرکت شامل استفاده از سرورهای گیت با سازوکارهای داخلی متفاوت، ارائه رابط‌های فراخوانی رویه از راه دور (RPC) در سمت سرور ــ «شاید حتی به شکلی استاندارد در میان پلتفرم‌های میزبانی مخازن» ــ و همکاری با GitHub، GitLab و جامعه متن‌باز است. پیشینه این رویکرد نیز قابل‌توجه است: در مطلب آنتروپیک، از Piper متعلق به گوگل و Sapling متعلق به متا به‌عنوان نمونه‌های پیشین یاد شده است؛ هر دو سامانه‌هایی داخلی بودند که برای استفاده دیگران عرضه نشدند. الگویی که لایه ابزارها همچنان دنبال می‌کند، این است که زیرساخت متناسب با مقیاس فعالیت عامل‌های هوش مصنوعی ابتدا در داخل شرکتی ساخته می‌شود که زودتر از دیگران به محدودیت‌ها برخورد کرده است. پرسش باز این است که آیا اکوسیستم پلتفرم‌های میزبانی مخازن می‌تواند پیش از آنکه موج بعدی عامل‌ها به همان سقف محدودیت برسد، رابط‌های استانداردی برای این زیرساخت‌ها تعریف کند یا نه. تا آن زمان، تیم‌هایی که عامل‌های هوش مصنوعی را با سرعت بالای ثبت و ادغام تغییرات به کار می‌گیرند، به‌جای پلی آماده عبور، فقط نقشه مسیر را دریافت می‌کنند.