طراحی مجدد کنترل منبع در آنتروپیک

در آنتروپیک، کدگذاری دیگر گلوگاه ساختن سیستم ها یا انجام تحقیقات نیست. کلود می‌تواند به‌طور مستقل روی حلقه‌های تحقیقاتی تکرار کند، برنامه‌های پیچیده را بهینه‌سازی کند و خدمات جدیدی را از ابتدا با سرعت و مقیاسی که قبلا ندیده‌ایم ایجاد کند. گلوگاه، در حال حاضر، تمام زیرساخت توسعه‌دهنده است که برای مقیاس انسانی ساخته شده است: کنترل منبع، ساخت‌ها و CI.

در ماه مه 2026، Anthropic به طور میانگین حدود 2500 تغییر کد را در روز ادغام کرد. از سپتامبر، ما بیش از 30000 در روز ادغام می‌کنیم. ما انتظار نداریم که این نرخ رشد به این زودی کاهش یابد. تقاضای پنهان برای کد ادغام عملا بی نهایت است و هر گلوگاهی که ما فورا حذف می کنیم منجر به افزایش بیشتر در مقدار کدی که تولید می کنیم می شود.

به منظور حمایت از این رشد، ما Scion، یک سیستم کنترل نسخه داخلی را ساختیم و مونورپوی خود را به طور کامل در عرض پنج ماه از git منتقل کردیم. ما همچنین یک سطح بررسی کد (به نام Antique)، جستجوی کد، یک سیستم کنترل منبع غنی IAM، روش‌های جدید مدیریت و ارسال مقادیر زیادی از کد بازبینی‌شده، و موارد دیگر، همه در همان دوره زمانی ساخته و ارسال کردیم. در این پست، ما بر نحوه ساخت Scion به طور خاص تمرکز خواهیم کرد.

این یک مطالعه موردی جالب را ایجاد می‌کند: توانایی کلود در نوشتن کد هم چیزی بود که در وهله اول ما را در این موقعیت قرار داد و هم اینکه چگونه توانستیم به سرعت یک سیستم با کیفیت بالا و مقیاس‌پذیر برای مقابله با آن بسازیم.

قبل از کشف آنچه ساخته‌ایم، باید اذعان کنیم که حجم کاری ما چقدر غیرعادی است. جای تعجب نیست که آنتروپیک بیش از هر شرکت دیگری از کلود برای نوشتن نرم افزار استفاده می کند، بنابراین ما اغلب اولین کسانی هستیم که می بینیم ابزارهای ساخته شده برای مقیاس انسانی کجا شروع به کار می کنند. کنترل منبع تنها یک نمونه از این است. در حالی که انتظار نداریم بسیاری از سازمان‌ها در کوتاه‌مدت با این مشکلات روبه‌رو شوند، اما گمان می‌کنیم که دیری نخواهد گذشت که دیگرانی که از ابزارهای کدنویسی هوش مصنوعی استفاده می‌کنند، همین نقاط فشار را تجربه کنند، به همین دلیل است که می‌خواهیم آنچه را که ساخته‌ایم و آموخته‌ایم به اشتراک بگذاریم.

Git یک سیستم غیرمتمرکز است: هر کلون یک مخزن کامل و مستقل است که می‌تواند تفاوت‌ها را محاسبه کند، تاریخچه و سرزنش را بخواند و در حالی که کاملا آفلاین است، هر گونه ویرایش را بررسی کند. برای اکثریت قریب به اتفاق مخازن، این طراحی درستی است، و این بخش بزرگی از چرایی تبدیل شدن git به استاندارد است.

همانطور که monorepo ما رشد می کند، به طور فزاینده ای با فضای طراحی مناسب نیست. سابقه شعبه اصلی ما به تنهایی تقریبا 100 گیگابایت است و یک نسخه فشرده فشرده بیش از 25 گیگابایت است. ما قبل از شمارش محیط‌های توسعه‌دهنده، جعبه‌های ایمنی عامل و کارهای تحقیقاتی، به ترتیب ۲۵ میلیون بررسی کد در روز برای CI انجام می‌دهیم. با ساده‌لوحانه‌ای واکشی، این بیش از 600 PB ترافیک git در روز خواهد بود.

Git ابزارهایی را برای کار با تکه‌ای از مخزن ارائه می‌کند، مانند کلون‌های کم عمق، تسویه‌حساب‌های پراکنده و کنترل‌های راه دور promisor. فراتر از اینها، راه‌حل‌های استانداردی برای مونورپوهای بزرگ وجود دارد، مانند آینه‌های git داخلی و عکس‌های فوری مخزن (دانه‌ها) که در ذخیره‌سازی حباب نگهداری می‌شوند. ما از همه آنها استفاده کرده‌ایم - در اوج کار، از چند صد آینه داخلی برای مقابله با بار استفاده کردیم. این برای ما زمان خرید، اما با افزایش نرخ ادغام ما، کار کردن با آنها سخت‌تر شد.

دانه‌ها از نوک اصلی بین تازه‌سازی‌ها دورتر می‌افتند، و مراقبت بیشتر و بیشتر می‌طلبد تا عملیات‌هایی که به تاریخ بستگی دارند، مانند تفاوت و سرزنش، روی کلون‌های جزئی کار کنند.

با برداشتن یک قدم به عقب، متوجه شدیم که مانند بسیاری از شرکت‌ها، از git به عنوان یک سیستم متمرکز با یک نسخه معتبر استفاده می‌کنیم، اما تقریبا همه مشتریان ما نمایندگان و مشاغلی بودند که طبق تعریف آنلاین هستند. ویژگی‌هایی که git را برای کارهای توزیع‌شده و آفلاین عالی می‌سازد، به‌طور فعال توانایی ما را در مقیاس‌پذیری با رشد مخزن تضعیف می‌کرد. بنابراین از خود پرسیدیم: اگر کنترل منبع را با این واقعیت طراحی کنیم که عوامل از ابتدا همیشه آنلاین هستند، چگونه به نظر می رسد؟

با کدگذاری عاملی، بسیاری از مفروضات رایج در مورد چگونگی توسعه نرم افزار در حال تکامل هستند. ما هنگام ساخت Scion از این تغییرات استقبال کردیم، که به ما اجازه داد رویکردی اساسا متفاوت از git در چندین اصل اصلی داشته باشیم. کنترل منبع برای مونورپوهای عظیم دارای هنر قبلی است، به‌ویژه Google's Piper و Meta's Sapling، بنابراین ما توانستیم Scion را با در نظر گرفتن درس‌هایی که به سختی به دست آورده‌اند، بسازیم. اصول ما عبارتند از:

مشتریان همیشه آنلاین هستند. Git فرض می کند که مشتریان به صورت آفلاین کار می کنند و به یک کپی کامل از مخزن نیاز دارند. از آنجایی که تقریبا همه مشتریان ما نمایندگان و مشاغل هستند، ما کلاینت و پروتکل‌های Scion را در اطراف سروری طراحی کردیم که همیشه در دسترس است و مشتریان در صورت نیاز داده‌ها را واکشی می‌کنند.

عدم تقارن مشتری و سرور در git، هر کلاینت می تواند یک سرور تمام عیار باشد. در Scion، سرور به سوالات مربوط به تاریخچه فایل و سرزنش پاسخ می دهد، commit ها را ایجاد می کند، ادغام ها و rebases را انجام می دهد و غیره. کلاینت یک کش محلی محدود نگهداری می کند، فایل های کپی کار را روی دیسک قرار می دهد، تغییرات سیستم فایل را مانیتور می کند و روشی ارگونومیک برای کار با سرور به کاربران ارائه می دهد. می تواند به تنهایی خیلی کم محاسبه کند، اما در عوض، به داده های محلی بسیار کمتری نیاز دارد.

یک سرویس جامع کنترل منبع می تواند بسیاری از برنامه های کاربردی جدید را تامین کند. با git، یک کار یا ابزار CI که نیاز به پرسیدن سؤالی در مورد مخزن دارد، مانند اینکه آخرین بار چه کسی یک خط را تغییر داده یا دو commit چگونه به هم مرتبط هستند، باید یک نسخه محلی از مخزن نگهداری کند یا امیدوار باشد که API های خاص فروشنده پاسخ را ارائه دهند. با Scion، تمام پرس و جوهای کنترل منبع مورد استفاده مشتری نیز از طریق API در معرض دید قرار می گیرند، بنابراین در بسیاری از موارد کارها اصلا به یک مخزن محلی نیاز ندارند.

بسیاری از ابزارهای داخلی، مانند خطوط لوله دوگانه و برگردان خودکار ما، بدون این دسترسی ارزان و برنامه‌ای به کنترل منبع، در مقیاس عملی نخواهند بود.

همه چیز باید به صورت افقی مقیاس پذیر باشد. در اوج کار، ما چندین صد آینه git را اجرا کردیم که به میزان قابل توجهی ظرفیت را کاهش داد و زمانی که مخزن از دیسک‌های آینه‌ها یا محدودیت‌های حافظه بیشتر شد، دیگر مقیاس‌پذیر نشد. در Scion، داده‌های مخزن توزیع می‌شوند و هر جزء به طور مستقل مقیاس‌پذیر است. هیچ کپی کاملی از مخزن در هیچ کجا وجود ندارد، حتی روی سرور. هیچ معادلی برای فایل های بسته (دسته های فشرده شده اشیاء git) وجود ندارد، بنابراین نیازی به نگهداری مخزن نیست.

تعهدات باید ارزان، افزایشی و بدون قفل باشد. در git، شما به صورت محلی متعهد می شوید و سپس فشار می آورید تا کار خود را به اشتراک بگذارید. در Scion، هر commit، rebase یا ادغام روی سرور اتفاق می‌افتد، بنابراین چیزی برای فشار دادن وجود ندارد، اما هر یک از این عملیات باید سریع باشد. هزینه ایجاد یک commit و به‌روزرسانی ساختارهای داده پایین‌دستی آن باید متناسب با اندازه تغییر باشد، نه اندازه کلی مخزن، در غیر این صورت سرور نمی‌تواند به آن ادامه دهد.

چرخه عمر توسعه در Scion از ref ها (نشانگرهای تعهد، مانند شاخه ها و تگ ها) جلوگیری می کند، به جز شاخه های ref اصلی یا انتشار، زیرا وضعیت جهانی که هر سرور باید با آن موافقت کند، یک مشکل مقیاس پذیری است.

نسخه کار اختیاری است و از نظر طرح کم است. از آنجایی که monorepo ما بسیار بزرگ است، و از آنجایی که ما ده‌ها میلیون بار در روز کد را برای CI بررسی می‌کنیم، می‌خواستیم هر زمان که می‌توانیم از پرداخت‌ها اجتناب کنیم. برای مثال، با Scion، یک کار CI که به تفاوت بین یک commit و پایه ادغام آن نیاز دارد، می‌تواند آن را از سرور بخواهد. همین امر در مورد نوشتن نیز صدق می کند: بسیاری از بارهای کاری نوشتن نیز می توانند پرداخت را نادیده بگیرند و به طور کامل از طریق API کار کنند.

پروتکل Scion حول تسویه‌حساب‌های پراکنده، که فقط شامل دایرکتوری‌هایی است که مشتری درخواست می‌کند، و تسویه‌حساب‌های مجازی‌سازی شده است که فایل‌ها را بر اساس تقاضا انجام می‌دهند، بنابراین وقتی یک کار به فایل‌های روی دیسک نیاز دارد، مشتری فقط برای آنچه که در واقع خوانده است، پرداخت می‌کند.

درک اینکه چگونه این اصول در عمل در هنگام ساخت Scion با هم ترکیب شدند، مفید است. این بینش‌ها می‌توانند برای سایر سیستم‌های کنترل منبع یا به طور گسترده‌تر، در سایر مراحل چرخه عمر توسعه نرم‌افزار اعمال شوند.

در Scion، واحد کار یک «تغییر مجموعه» است، یک ورودی در یک ثبت پیش‌نویس. تغییرات مجموعه بیشتر آنچه را که از یک commit در git انتظار دارید ذخیره می کند. اما در جایی که git commit یک اشاره گر را به درخت ذخیره می کند، یک تغییرات مجموعه لیستی از فایل هایی را که نسبت به والد اول خود تغییر کرده اند، 1 همراه با اشاره گرهای آدرس محتوا به محتوای فایل فشرده در ذخیره سازی blob ذخیره می کند. مجموعه‌های تغییرات در سمت سرور ایجاد می‌شوند و فورا در همه جا در دسترس هستند.

این ساختار به ما اجازه می‌دهد تا تغییرات را با توان عملیاتی بسیار بالا بپذیریم، زیرا هیچ فایل بسته‌ای برای پذیرش، هیچ قفل یا هماهنگی بین سرور و هیچ مرجعی برای جابجایی وجود ندارد. Scion از نظر فنی از ref ها پشتیبانی می کند، اما از آنجایی که نه ایجاد و نه واکشی commit ها را شامل نمی شود، جابجایی یکی یک مقایسه و تعویض در یک ردیف Spanner است که جدا از ایجاد تغییرات انجام می شود.

مجموعه تغییرات فقط آنچه را که تغییر کرده است ثبت می‌کند، بنابراین به تنهایی نمی‌تواند به سؤالاتی مانند آخرین بار چه کسی یک خط را ویرایش کرده یا کدام یک پرونده تأثیرگذار است، پاسخ دهد. برای پاسخ به آن‌ها، Scion ساختارهای داده اضافی را از مجموعه‌های تغییرات ایجاد می‌کند، از جمله ساختارهای اختصاصی برای سرزنش فایل و تاریخچه مسیر و پرش از لیست‌ها برای گراف commit. ما هر چیزی را که مستقیما بخشی از مجموعه تغییرات نیست «داده‌های مشتق شده» می‌نامیم و همه آن‌ها را از طریق یک مکانیسم عمومی محاسبه می‌کنیم. هر نوع داده مشتق شده به صورت بازگشتی تعریف می شود، بنابراین مقدار آن برای یک تغییرات از مقادیر آن برای والدین آن تغییرات محاسبه می شود.

این مکانیسم سه مزیت دارد. اول، ما به راحتی می توانیم نوع جدیدی از داده های مشتق شده را اضافه کنیم، زمانی که یک ساختار داده جدید برخی عملیات را سریعتر می کند. دوم، برای هر نوع، می‌توانیم انتخاب کنیم که مشتاقانه آن را محاسبه کنیم یا کار را به تعویق بیندازیم، بنابراین از تحقق داده‌هایی که به آن نیاز نداریم اجتناب می‌کنیم. و سوم، از آنجایی که مشتری هرگز اجزای داخلی این ساختارهای داده را نمی بیند، می توانیم آنها را بدون تغییر مشتری بهینه سازی کنیم. با رشد سیستم، انواع جدیدی از داده های مشتق شده را بارها اضافه کرده ایم، مانند شاخص های جدید برای انجام تشخیص کپی یا جستجوی فایل مبتنی بر مسیر.

ناوگان کوچکی از سرورهای Scion APIهای کنترل منبع را برای هر عملیاتی که مشتری نیاز دارد، مانند دریافت تغییرات، محاسبه تفاوت‌ها، یافتن پایه‌های ادغام و واکشی حباب‌ها فراهم می‌کند. تمام داده‌های کنترل منبع دارای آدرس محتوا هستند، بنابراین بخشی از داده‌ها پس از ذخیره شدن هرگز تغییر نمی‌کند و هر سروری می‌تواند آن را بدون بررسی با دیگران در حافظه پنهان ذخیره کند. در نتیجه، سرورها به صورت افقی مقیاس پذیر هستند و نیاز به هماهنگی کمی دارند. آنها اساسا حافظه پنهان بزرگی هستند که همچنین می توانند داده های مشتق شده را در لحظه محاسبه کرده و نتایج را به Spanner بازگردانند.

بسیاری از مصرف کنندگان Scion دیگر نیازی به نگهداری مخازن محلی خود ندارند. واکشی و نگهداری مخزن در گذشته بار تعمیر و نگهداری قابل توجهی برای مشاغل CI یا ابزارهایی بود که نیاز به پرسیدن سؤالات کنترل منبع، به ویژه در مورد اصل و نسب تعهد و سرزنش داشتند. در اوایل مهاجرت، قبل از اینکه مشتری، فرمت مخزن یا پروتکل های خود را داشته باشیم، Scion فقط به این پرس و جوهای «فراداده» پاسخ می داد. واکشی محتویات فایل و عملی کردن کپی‌های کاری عملیاتی بسیار فشرده‌تر از داده‌ها هستند و نیاز به طراحی خاص خود داشتند.

کلاینت scn Scion به چندین روش مهم از پروتکل‌های واکشی git منحرف می‌شود و در نتیجه، خود را به معماری بسیار مقیاس‌پذیری می‌رساند که به طور قابل‌توجهی به CPU کمتری نسبت به سرورهای git نیاز دارد. مذاکره Scion به سرور نمی گوید که مشتری قبلا چه چیزی دارد. در عوض، منحصرا روی درختان و حباب‌هایی که مشتری می‌خواهد عمل می‌کند. با شروع از یک درخت ریشه، مشتری فروشگاه محلی خود را برای درختان از دست رفته بررسی می کند و آنها را به صورت بازگشتی درخواست می کند، سپس این فرآیند را برای حباب ها تکرار می کند.

هر درخواستی برای یک شی خاص است که هرگز تغییر نمی کند، بنابراین هر کش می تواند به آن پاسخ دهد، و معماری بسیار شبیه حافظه پنهان سنتی است. این فرآیند همچنین کارآمد و قابل ازسرگیری است، زیرا هیچ پاسخ فایل بسته چند گیگابایتی واحدی وجود ندارد. تسویه‌حساب‌های پراکنده و حتی مجازی‌شده نیازی به پشتیبانی خاصی ندارند، زیرا مشتری به سادگی درخت‌هایی را که نمی‌خواهد درخواست نمی‌کند.

در ناوگان، مشتری از طریق یک سوکت با یک دیمون، پیوندک، صحبت می کند که اشیاء را برای کل گره ذخیره می کند. بیشتر گره‌های ما نیاز به دسترسی به monorepo دارند، و کارهای روی همان گره از بسیاری از اشیاء مشابه استفاده مجدد می‌کنند. هر دیمون از یک عکس فوری تازه‌سازی شده به صورت دوره‌ای شروع می‌شود، سپس فقط با سرورهای کش درختی و حباب در منطقه خود به نام scion-cache صحبت می‌کند. این سرورهای کش اشیاء را مستقیما از حافظه، در قالب دیسکی که دیمون مصرف می کند، پخش می کنند، بنابراین نیازی به صرف زمان برای محاسبه اشیاء گمشده مشتری یا انجام فشرده سازی دلتا ندارند.

هنگامی که حافظه پنهان یک شی را از دست می دهد، از سرورهای جانشین معتبر می پرسد که در صورت نیاز از Spanner یا فضای ذخیره سازی ابری می خوانند.

scion-daemon، scion-cache و scion-server همگی به RPCهای یکسان برای این پروتکل پاسخ می دهند، بنابراین مشتری نیازی به دانستن توپولوژی کش ندارد. هر سطحی از نظر تئوری می‌تواند با هر سطح دیگری صحبت کند، اما ما برای جداسازی دامنه‌های خرابی به شدت این ردیف‌بندی را اجرا می‌کنیم. ما می‌خواهیم از موقعیتی جلوگیری کنیم که در آن یک شکست در حافظه پنهان منطقه‌ای، سرورهای پیوندی بالادستی را تحت تأثیر قرار دهد و کل سیستم را خراب کند.

هر لایه از این سیستم نرخ ضربه کش بیش از 99٪ را حفظ می کند و به حالت طولانی مدت نیاز ندارد، بنابراین در صورت نیاز به راحتی می توان آن را افزایش داد. ردپای زیرساخت Scion ما اکنون 200 برابر کمتر از زیرساخت git mirroring قبلی ما از نظر CPU و حافظه مورد نیاز است. CI و کارهای تحقیقاتی کد را دو مرتبه سریعتر بررسی می کنند (در ثانیه به جای چند دقیقه)، که مقدار قابل توجهی از ظرفیت را در سراسر ناوگان آزاد می کند. CI به تنهایی 25 درصد ظرفیت پردازنده را به دست آورد.

نه کلاینت‌ها و نه کش‌ها نیازی به نگهداری مخزن ندارند، که مدیریت چرخه عمر مشاغل ما را ساده می‌کند.

ما ساخت Scion را در همان زمانی شروع کردیم که Claude Mythos Preview و Claude Tag به صورت داخلی در دسترس قرار گرفت. هر دوی این نسخه ها به طور همزمان نیاز به Scion را تشدید کردند و به طور معناداری سرعت ساخت آن را افزایش دادند.

در اینجا یک مثال برجسته است. در اوایل سال، ما تا حد زیادی اولین نسخه خط لوله مصرف git-to-Scion را به عنوان نمونه اولیه دست نوشته بودیم. ما فکر کردیم خوب است - تا اینکه یک عکس فوری داخلی اولیه از پیش‌نمایش کلود میتوس را به دست آوردیم. ما از آن خواستیم که همه چیز را بازنویسی کند، و بدون هیچ دستورالعمل دیگری، نسخه‌ای تولید کرد که 20 برابر حافظه کمتری مصرف می‌کرد و 4 برابر سریع‌تر بود، در حالی که تمام تغییرات ضمنی در مورد ترتیب جذب و ساختارهای داده را حفظ می‌کرد.

آنچه ما در ساخت و راه اندازی Scion یاد گرفتیم، درس های جالبی را در مورد اینکه نرم افزار در مقیاس عامل ساخت چگونه می تواند باشد ارائه می دهد.

توسعه سریع با یک تیم کوچک رایج تر خواهد شد. تیمی متشکل از هفت نفر هم Scion و هم Antique (ابزار بررسی کد ما، که می‌توانیم به راحتی یک پست وبلاگ کامل دیگر درباره آن بنویسیم) را ساختند، و البته در عرض پنج ماه به طور کامل به آنها مهاجرت کردند. ما همه این کارها را در حالی انجام دادیم که حجم کدهای ادغام شده در روز 10 برابر افزایش یافت. در گذشته، توسعه و استقرار یک سیستم کنترل منبع مانند این، سالها مهاجرت مکرر شرکت را با مهندسان بسیار بیشتری به طول انجامید. ما فکر می کنیم این نوع مهاجرت سریع و چابک در آینده رایج تر خواهد شد.

مهندسان ارزش کمتری ندارند، اما کارشان در حال تغییر است. همه مهندسانی که روی این سیستم کار می کردند اکنون کلود را در نوشتن کد بهتر از آنها ارزیابی می کنند. اما مهندسان ما هنوز درک ارزشمندی از اجزای بین سیستمی سطح بالا و معاوضه‌های سطح طراحی ارائه می‌کنند، و انتخاب‌های آگاهانه‌ای پیرامون مشکلاتی که می‌خواهیم حل کنیم و مقیاسی که می‌دانستیم باید به آن برسیم، انجام می‌دهند.

خیلی وقت ها متوجه می شدیم که نقش مهندسان این بود که به کلود «نه» بگویند. عوامل گاهی اوقات محدودیت های سیستم اصلی را نقض می کنند تا الگویی را برآورده کنند که هرگز نباید از ابتدا مجاز می شد. این به ویژه در مهاجرت ما رایج بود. برای مثال، سیستم‌های متعددی وجود داشتند که سعی می‌کردند با خواندن خطی گزارش commit به‌جای پرسش از ابزار بررسی کد ما، هنگام ادغام یک تغییر به اصلی، به دنبال نیروی بی‌رحمانه باشند.

Anthropic همچنین از بررسی خصمانه استفاده گسترده ای می کند، و در حالی که این کار از بسیاری جهات فوق العاده موثر است، می تواند نزدیک بینی نیز باشد، بنابراین مهندسان ماهر باید در پاسخ به نگرانی های فرضی، کلود را از بخش های مهندسی بیش از حد سیستم دور کنند. به عنوان مثال، یکی از این بررسی ها در مورد اعتماد به یک سرویس داخلی دیگر بیش از حد دفاعی بود، که منجر به اضافه کردن اعتبار و پیچیدگی بیش از حد کلود شد. اعضای تیم ما هنوز هر درخواست تغییری را برای سیستم بررسی می‌کنند، اما اکنون قصد تغییر را به جای خواندن هر خط کد بررسی می‌کنند.

ما توانستیم بهینه سازی و کیفیت را بطور قابل ملاحظه ای بهبود بخشیم. به دلیل توانایی کلود در نوشتن مقادیر بسیار زیاد کد بسیار سریعتر از آنچه که خودمان می توانستیم، Scion یکی از آزمایش شده ترین و به خوبی دفاع شده ترین پایگاه های کدی است که تا به حال روی آن کار کرده ایم. حتی در جدول زمانی فشرده‌مان، ما توانستیم شبیه‌سازی‌های هرمتیکی از هر زیرساخت غیر پیش پا افتاده و تعامل کنترل منبعی که تا به حال با آن مواجه شده‌ایم، و همچنین محدودیت‌های نرخ فازی و پیچیده ایجاد کنیم.

کلود همچنین به طور اتفاقی بهینه‌سازی‌های قابل توجهی را پیدا کرد - برای مثال، یک بهینه‌سازی الگوریتمی برای جستارهای اجدادی که یکی از فهرست‌های ما را از دست داده بود - که تحلیل و تنظیم آن روزها یا هفته‌ها متخصص طول می‌کشید... و سپس همه آن را دوباره روز بعد انجام داد.

ما زمینه را برای اشکال جدید امنیت monorepo فراهم کردیم. مدیریت ایمنی، امنیت و انطباق در یک monorepo عظیم به اندازه مدیریت اندازه و مقیاس مهم است. ما از همان ابتدا Scion را با در نظر گرفتن این موارد ساختیم. این برنامه از کنترل دسترسی غنی در مخازن و همچنین توانایی اعمال مجوزها به فهرست‌های جداگانه برای محافظت از حساس‌ترین کدها بدون از دست دادن مزایای monorepo پشتیبانی می‌کند.

علاوه بر این، ابزار بازبینی کدی که ساخته‌ایم می‌تواند محدودیت‌های معنایی پیچیده را در تأییدها بیان کند، که به ما امکان می‌دهد چیزهای ساده‌ای مانند تغییرات صرفا اظهارنظر را از تغییرات منطقی حساس متمایز کنیم، به طوری که بازبین‌های انسانی بتوانند روی پیامدترین تغییرات تمرکز کنند.

سطح جدیدی از تعالی عملیاتی ممکن است. تیم ما به شدت از Claude Tag استفاده می کند، که به ما کمک کرده است تا هر جزء از سیستم را نظارت کنیم. به عنوان مثال، ما کانال‌های Slack را ایجاد کردیم که در آن به کلود وظیفه داشتیم با وسواس بر سلامت یک جزء متمرکز شود. ما به این کلودز می گوییم "سوپر فن". ما یک superfan scion-daemon، یک superfan scion-cache، یک ابر فن صف ادغام Antique و غیره داریم. آنها به تله متری و لاگ های ما دسترسی دارند و مانند یک مهندس باتجربه عمل می کنند که کاری بهتر از تازه کردن نمودارها و جستجوی چیزهای عجیب و غریب ندارد.

ما همچنین هشدارهای سنتی را برای همه سیستم‌های خود داریم، اما سوپر فن‌های ما می‌توانند مسائل ظریف و جدیدی را شناسایی کنند که باعث می‌شود این هشدارها در مقایسه یک بعدی به نظر برسند.

ما در حال بازنگری کامل در موارد قبلی خود هستیم. این پروژه ما را بر آن داشت تا نگاهی بسیار دقیق به سایر جریان های کاری طراحی شده برای مقیاس انسانی بیندازیم. برای مثال، یک صف ادغام مناسب، در مقیاس عامل چندان منطقی نیست. حتی زمانی که صدها یا حتی هزاران تغییر می توانند در حین اجرای آزمایش ها ادغام شوند، CI به چه معناست؟ ما نتوانسته‌ایم استاندارد صنعتی یک قفل مخزن جهانی را در صف ادغام به طور موثر تکرار کنیم، بنابراین در عوض، روی تست‌های خودکار پس از ادغام و پیش استقرار سرمایه‌گذاری کرده‌ایم.

این بدان معنی است که تغییرات همزمان ممکن است با هم تضاد داشته باشند، اما کلود معمولا می‌تواند این تضادها را سریع‌تر از تشخیص انسان‌ها برطرف کند.

ما Scion را تنها بخشی از پاسخ به نگرانی‌های مقیاس‌پذیری می‌دانیم که عوامل هوش مصنوعی توانمندتر ایجاد کرده‌اند. ما این جزئیات را به عنوان نمونه ای از نحوه برخورد تیم ها با چالش های مشابه به اشتراک می گذاریم، اگرچه انتظار نداریم راه حل یا ملاحظات ما برای هر موردی مناسب باشد.

Scion به هیچ وجه جایگزین مناسبی برای git برای استفاده عمومی نیست. مفاهیمی که در اینجا بیان کردیم، واقعا فقط برای مونورپوهای واقعا عظیم، با ده‌ها هزار مهندس یا انبوهی از عوامل که به طور مکرر کد می‌نویسند، منطقی است. بعلاوه، آنتروپیک از این نظر منحصر به فرد است که توانایی ما برای خرج کردن توکن ها برای استفاده داخلی بسیار بیشتر از آن چیزی است که هر کسب و کار دیگری واقعا می خواهد خرج کند. ما این کار را هم برای رفع نیازهای توسعه نرم افزار خود و هم برای آزمایش قابلیت های کلود انجام می دهیم.