إعادة تصميم التحكم بالمصادر في Anthropic

حُدِّث في 15 أكتوبر ليتضمن تفاصيل إضافية حول المشاريع التي طوّرت العديد من التقنيات التي نستخدمها في Scion.

في Anthropic، لم يعد البرمجة هي عنق الزجاجة في بناء الأنظمة أو إجراء الأبحاث. يستطيع Claude التكرار ذاتيًا في حلقات البحث، وإجراء تحسينات دقيقة للبرامج المعقدة، وبناء خدمات جديدة من الصفر بسرعة ونطاق لم نرهما من قبل. عنق الزجاجة الآن هو كل البنية التحتية للمطورين التي بُنيت لتناسب الحجم البشري: التحكم بالمصادر، والبناء، والتكامل المستمر.

في مايو 2026، كان متوسط Anthropic حوالي 2,500 تغيير برمجي مدموج يوميًا؛ وبحلول سبتمبر، كنا ندمج أكثر من 30,000 يوميًا. لا نتوقع أن يتباطأ هذا المعدل من النمو قريبًا؛ فالطلب الكامن على دمج الشيفرة لا نهائي عمليًا، وكل عنق زجاجة نزيله يؤدي فورًا إلى زيادة إضافية في كمية الشيفرة التي ننتجها.

لدعم هذا النمو، بنينا Scion، وهو نظام تحكم بالإصدارات داخلي، وانتقلنا بالكامل من git لمستودعنا الأحادي خلال خمسة أشهر. كما بنينا وأطلقنا واجهة مراجعة شيفرة (تسمى Antique)، وبحثًا في الشيفرة، ونظام IAM غنيًا للتحكم بالمصادر، وطرقًا جديدة لإدارة وهبوط كميات كبيرة من الشيفرة المراجَعة، وغير ذلك، كل ذلك في نفس الفترة الزمنية. في هذه المقالة، سنركز على كيفية بناء Scion تحديدًا. إنه يشكل دراسة حالة مثيرة للاهتمام: فقدرة Claude على كتابة الشيفرة كانت هي ما وضعنا في هذا الموقف في المقام الأول و هي أيضًا ما مكّننا من بناء نظام عالي الجودة وقابل للتوسع بسرعة للتعامل معه.

نمو مستودعنا الأحادي

قبل أن نستكشف ما بنيناه، ينبغي أن نقر بأن عبء العمل لدينا غير اعتيادي. ليس من المستغرب أن Anthropic تستخدم Claude لكتابة البرمجيات أكثر بكثير من أي شركة أخرى تقريبًا، لذلك غالبًا ما نكون أول من يرى أين تبدأ الأدوات المبنية للحجم البشري في التعثر. التحكم بالمصادر هو مجرد مثال واحد على ذلك. ورغم أننا لا نتوقع أن تواجه منظومات كثيرة هذه المشاكل في المستقبل القريب جدًا، نعتقد أن الأمر لن يطول قبل أن يواجه الآخرون الذين يستخدمون أدوات البرمجة بالذكاء الاصطناعي نفس نقاط الضغط هذه، ولهذا السبب أردنا مشاركة ما بنيناه وما تعلمناه.

Git هو نظام لامركزي: كل نسخة مستنسخة هي مستودع كامل ومستقل يمكنه حساب الفروق، وقراءة السجل واللوم، وفحص أي مراجعة مع كونه غير متصل بالإنترنت بالكامل. بالنسبة للغالبية العظمى من المستودعات، هذا هو التصميم الصحيح، وهو جزء كبير من سبب تحول git إلى المعيار.

ومع نمو مستودعنا الأحادي، أصبح لا يناسب فضاء التصميم هذا بشكل متزايد. تاريخ فرعنا الرئيسي وحده يقارب 100 GB، والنسخة العاملة المضغوطة تتجاوز 25 GB. ننفذ ما يعادل 25 مليون عملية فحص شيفرة يوميًا لأغراض CI، دون احتساب بيئات المطورين، وبيئات العوامل المعزولة، ومهام البحث. لو جُلبت بشكل مباشر، لكان ذلك أكثر من 600 PB من حركة git يوميًا.

يقدم Git أدوات للعمل مع جزء من المستودع، مثل النسخ الضحلة، والفحوص المتفرقة، وpromisor remotes. وإلى جانب هذه، توجد حلول بديلة معيارية للمستودعات الأحادية الكبيرة، مثل مرايا git الداخلية ولقطات المستودعات (البذور) المحفوظة في تخزين الكائنات. لقد استخدمناها جميعًا — وفي ذروتنا، شغّلنا عدة مئات من مرايا git الداخلية للتعامل مع الحمل. هذا أكسبنا وقتًا، لكنها أصبحت أصعب في التشغيل مع ارتفاع معدل الدمج لدينا. ابتعدت البذور أكثر عن طرف الفرع الرئيسي بين كل تحديث، وأصبح الحفاظ على العمليات التي تعتمد على السجل، مثل diff وblame، يعمل على النسخ الجزئية يتطلب عناية متزايدة.

وبالنظر إلى الأمور من منظور أوسع، لاحظنا أنه، مثل معظم الشركات، كنا نستخدم git كنظام مركزي بنسخة واحدة موثوقة، لكن جميع عملائنا تقريبًا كانوا وكلاء ومهامًا متصلة بالإنترنت بطبيعتها. كانت الخصائص التي تجعل git ممتازًا للعمل الموزع وغير المتصل تقوّض فعليًا قدرتنا على التوسع مع نمو المستودع. لذلك سألنا أنفسنا: لو صممنا التحكم بالمصادر مع أخذ حقيقة أن الوكلاء متصلون دائمًا بالإنترنت في الاعتبار منذ البداية، فكيف سيبدو؟

مبادئ التحكم بالمصادر بمعايير الوكلاء

مع البرمجة الوكيلية، كثير من الافتراضات الشائعة حول كيفية تطوير البرمجيات تتطور. تبنينا هذه التغييرات عند بناء Scion، مما سمح لنا باتباع نهج مختلف جذريًا عن git في عدة مبادئ جوهرية. التحكم بالمصادر للمستودعات الأحادية الضخمة له سوابق، وأبرزها Piper من Google وSapling,² من Meta، لذلك تمكنا من بناء Scion مع وضع دروسهم التي تحققوا منها بصعوبة في الاعتبار. مبادئنا هي:

العملاء متصلون دائمًا بالإنترنت. يفترض Git أن العملاء يعملون دون اتصال ويحتاجون نسخة كاملة من المستودع. وبما أن جميع عملائنا تقريبًا هم وكلاء ومهام، صممنا عميل Scion وبروتوكولاته حول خادم يمكن الوصول إليه دائمًا، مع جعل العملاء يجلبون البيانات عند الحاجة.

عدم التماثل بين العميل والخادم. في git، كل عميل قادر على أن يكون خادمًا متكاملًا. في Scion، يجيب الخادم على الأسئلة حول تاريخ الملفات واللوم، وينشئ الالتزامات، وينفذ عمليات الدمج وإعادة الأساس، وهكذا. يحتفظ العميل بذاكرة كائنات محلية محدودة، ويرتب ملفات النسخة العاملة على القرص، ويراقب تغييرات نظام الملفات، ويوفر للمستخدمين طريقة عملية للتعامل مع الخادم. لا يستطيع إجراء سوى القليل جدًا بمفرده، لكن في المقابل يحتاج إلى بيانات محلية أقل بكثير.

يمكن لخدمة تحكم بالمصادر شاملة أن تُشغّل تطبيقات جديدة عديدة. مع git، تحتاج وظيفة CI أو أداة تحتاج إلى طرح سؤال عن المستودع، مثل من غيّر سطراً معيناً آخر مرة أو كيف يرتبط طلبا إيداع (commit) ببعضهما، إلى الاحتفاظ بنسخة محلية من المستودع أو الأمل في أن توفر واجهات برمجة التطبيقات الخاصة بالمورّد الإجابة. أما مع Scion، فإن جميع استعلامات التحكم بالمصادر التي يستخدمها العميل متاحة أيضاً عبر API، لذا في كثير من الحالات لا تحتاج الوظائف إلى مستودع محلي على الإطلاق. لن تكون العديد من الأدوات الداخلية، مثل مسارات bisect و revert الآلية لدينا، عملية على نطاق واسع دون هذا الوصول الرخيص والبرمجي إلى التحكم بالمصادر.

يجب أن يكون كل شيء قابلاً للتوسع الأفقي. في ذروة نشاطنا، كنا نشغّل عدة مئات من مرايا git، مما أدى إلى إجهاد كبير في السعة وتوقف عن قابلية التوسع بمجرد أن تجاوز المستودع حدود الأقراص أو الذاكرة في المرايا. في Scion، تُوزَّع بيانات المستودع، وكل مكوّن قابل للتوسع بشكل مستقل؛ ولا توجد نسخة مكتملة المادة من المستودع في أي مكان، حتى على الخادم. ولا يوجد ما يعادل ملفات packfiles (حزم git المضغوطة من الكائنات)، لذا لا حاجة لأي صيانة للمستودع.

يجب أن تكون عمليات الحفظ (Commits) رخيصة وتزايدية وخالية من الأقفال. في git، تُجرّب الالتزام محليًا ثم تدفع لمشاركة عملك. أما في Scion، فكل عملية commit أو rebase أو merge تحدث على الخادم، لذا لا يوجد ما يُدفع، لكن كل عملية من هذه العمليات تحتاج إلى أن تكون سريعة. يجب أن تتدرج تكلفة إنشاء commit وتحديث هياكل البيانات اللاحقة له مع حجم التغيير، لا مع الحجم الكلي للمستودع، وإلا فلن يتمكن الخادم من المواكبة. دورة التطوير في Scion لا تشجع على استخدام refs (مؤشرات إلى commits، مثل الفروع branches والوسوم tags)، باستثناء المرجع الرئيسي main ref أو فروع الإصدارات، لأن عالمي التي يجب أن يتفق عليها كل خادم تمثل مشكلة توسّع محتومة.

النسخة العاملة اختيارية، ومتناثرة بطبيعتها. نظرًا لأن مستودعنا الأحادي (monorepo) ضخم للغاية، ولأننا نقوم بسحب الكود عشرات الملايين من المرات يوميًا لعمليات التكامل المستمر (CI)، أردنا تجنب عمليات السحب كلما استطعنا. مع Scion، يمكن لوظيفة CI التي تحتاج إلى الفرق بين إيداع (commit) وقاعدة الدمج الخاصة به، على سبيل المثال، أن تطلب ذلك من الخادم. ينطبق الأمر نفسه على عمليات الكتابة: فكثير من أعباء الكتابة يمكنها أيضًا تخطي عملية السحب والعمل بالكامل عبر واجهة برمجة التطبيقات (API). بروتوكول Scion يتمحور حول عمليات السحب الجزئية (sparse checkouts)، التي لا تحتوي إلا على المجلدات التي يطلبها العميل، وعمليات السحب الافتراضية (virtualized checkouts)، التي تُنشئ الملفات عند الطلب، لذا عندما تحتاج وظيفة ما بالفعل إلى ملفات على القرص، فإن العميل لا يدفع إلا مقابل ما يقرؤه فعليًا.

كيف يعمل Scion

من المفيد فهم كيفية اجتماع هذه المبادئ في التطبيق العملي عند بناء Scion. يمكن تطبيق هذه الرؤى على أنظمة أخرى لإدارة الكود المصدري أو، على نطاق أوسع، على مراحل أخرى من دورة حياة تطوير البرمجيات.

هياكل البيانات

في Scion، وحدة العمل هي «changeset» (مجموعة تغييرات)، وهي مدخل في سجل الكتابة المسبقة (write-ahead log). تخزّن مجموعة التغييرات معظم ما تتوقعه من عملية commit في git. لكن في حين تخزّن عملية commit في git مؤشرًا إلى الشجرة، تخزّن مجموعة التغييرات قائمة بالملفات التي تغيّرت نسبةً إلى أصلها الأول,¹ along with مؤشرات موجهة بالمحتوى إلى محتويات الملف المضغوط في تخزين blob. يتم إنشاء Changesets على جانب الخادم وتصبح متاحة في كل مكان على الفور.

تتيح لنا هذه البنية استقبال مجموعات التغييرات بمعدل إنتاجية عالٍ جداً لأنه لا توجد ملفات حزم (packfiles) لاستقبالها، ولا قفل أو تنسيق بين الخوادم، ولا مراجع (refs) لنقلها. يدعم Scion المراجع تقنياً، ولكن بما أنه لا إنشاء الالتزامات ولا جلبها يتضمنها، فإن نقل أحدها هو عملية مقارنة واستبدال على صف واحد في Spanner تحدث بشكل منفصل عن إنشاء مجموعات التغييرات.

تسجل مجموعة التغييرات ما تغيّر فقط، لذا فهي بمفردها لا تستطيع الإجابة بسرعة على أسئلة مثل من عدّل سطراً معيناً آخر مرة أو أي الالتزامات أثّرت على ملف. للإجابة عن تلك الأسئلة، يبني Scion هياكل بيانات إضافية من مجموعات التغييرات، بما في ذلك هياكل مخصصة لإسناد الملفات (file blame) وتاريخ المسارات، وقوائم تخطي (skip lists) لرسم بياني الالتزامات. نسمي كل ما ليس جزءاً مباشراً من مجموعة التغييرات "البيانات المشتقة"، ونحسبها جميعاً من خلال آلية عامة واحدة. يُعرَّف كل نوع من البيانات المشتقة بشكل تكراري، بحيث تُحسب قيمته لمجموعة تغييرات من قيمه لآباء مجموعة التغييرات تلك.

لهذه الآلية ثلاث فوائد. أولاً، يمكننا بسهولة إضافة نوع جديد من البيانات المشتقة عندما يجعل هيكل بيانات جديد بعض العمليات أسرع. ثانياً، لكل نوع، يمكننا اختيار ما إذا كنا نحسبه بشكل فوري أم نؤجل العمل، وبذلك نتجنب تحقيق البيانات التي لا نحتاجها. وثالثاً، بما أن العميل لا يرى أبداً التفاصيل الداخلية لهذه الهياكل، يمكننا تحسينها دون تغيير العميل. لقد أضفنا أنواعاً جديدة من البيانات المشتقة عدة مرات مع نمو النظام، مثل فهارس جديدة لإجراء كشف النسخ أو البحث عن الملفات بناءً على المسار.

توسيع نطاق Scion

توفر مجموعة صغيرة من خوادم Scion واجهات برمجة تطبيقات للتحكم بالمصدر لأي عملية يحتاجها العميل، مثل الحصول على مجموعات التغييرات، وحساب الفروقات، وإيجاد قواعد الدمج، وجلب الكتل (blobs). جميع بيانات التحكم بالمصدر موجهة بعناوين المحتوى، لذلك لا تتغير قطعة البيانات أبداً بمجرد تخزينها، ويمكن لأي خادم تخزينها مؤقتاً دون التحقق من الخوادم الأخرى. ونتيجة لذلك، فإن الخوادم قابلة للتوسع الأفقي وتتطلب تنسيقاً قليلاً. وهي في جوهرها مخابئ كبيرة يمكنها أيضاً حساب البيانات المشتقة أثناء التشغيل وكتابة النتائج مرة أخرى إلى Spanner.

لم يعد كثير من مستهلكي Scion بحاجة إلى الاحتفاظ بمستودعات محلية خاصة بهم. فجلب المستودع وصيانته كانا يشكلان عبئًا صيانة كبيرًا لوظائف CI أو الأدوات التي كانت بحاجة إلى طرح أسئلة على نظام التحكم بالمصدر، لا سيما فيما يتعلق بأصل الالتجات (commit ancestry) والـ blame. في بداية الترحيل، قبل أن يتوفر لدينا عميل خاص أو تنسيق مستودع أو بروتوكولات، كان Scion يجيب فقط على استعلامات "البيانات الوصفية" هذه. أما جلب محتويات الملفات وتحقيق نسخ العمل (working copies) فهي عمليات أكثر كثافة من حيث البيانات بكثير، وقد احتاجت إلى تصميم خاص بها.

ينحرف عميل Scion المسمى scn عن بروتوكولات الجلب في git بعدة طرق مهمة، ونتيجة لذلك فهو يُفضي إلى بنية عالية القابلية للتوسع تتطلب معالجة (CPU) أقل بكثير من خوادم git. فالتفاوض في Scion لا يخبر الخادم بما يملكه العميل بالفعل؛ بل يعمل حصريًا على الأشجار والـ blobs التي يريدها العميل. بدءًا من شجرة جذر، يتحقق العميل من مخزنه المحلي بحثًا عن الأشجار الناقصة ويطلبها بشكل متكرر (recursively)، ثم يكرر العملية نفسها مع الـ blobs. كل طلب يكون لكائن محدد لا يتغير أبدًا، لذا يمكن لأي ذاكرة تخزين مؤقت أن تجيب عليه، وتشبه هذه البنية إلى حد كبير ذاكيرات التخزين المؤقتة الطبقية التقليدية. كما أن العملية فعالة وقابلة للاستئناف، لأنه لا يوجد استجابة واحدة على شكل ملف حزمة (packfile) بأحجام متعددة الجيجابايت. ولا تحتاج عمليات الـ checkout المتفرقة بل والافتراضية إلى دعم خاص، لأن العميل ببساطة لا يطلب الأشجار التي لا يريدها.

وفي التجمع (fleet) الحاسوبي، يتحدث العميل عبر مقبس (socket) مع خفيّ (daemon) اسمه scion-daemon يخزّن الكائنات لكل العقدة. معظم عقدنا تحتاج إلى الوصول إلى المستودع الأحادي (monorepo)، والوظائف على العقدة نفسها تعيد استخدام معظم الكائنات نفسها. يبدأ كل خفيّ من لقطة (snapshot) تُحدَّث دوريًا، ثم يتحدث فقط مع خوادم ذاكرة التخزين المؤقتة للأشجار والـ blobs في منطقته، وتسمى scion-cache. تبث خوادم التخزين المؤقت هذه الكائنات مباشرة من الذاكرة، بالتنسيق القرصي الذي سيستهلكه الخفيّ، لذا فهي لا تحتاج إلى إنفاق وقت في حساب الكائنات الناقصة للعميل أو إجراء ضغط الفروق (delta compression). وعندما يفتقد خادم تخزين مؤقت إلى كائن ما، فإنه يسأل خوادم scion-server المرجعية، التي تقرأ من Spanner أو التخزين السحابي حسب الحاجة.

كل من scion-daemon وscion-cache وscion-server يستجيبون جميعًا لاستدعاءات RPC متطابقة لهذا البروتوكول، لذا لا يحتاج العميل إلى معرفة طوبولوجيا ذاكيرات التخزين المؤقتة. يمكن نظريًا لأي طبقة أن تتحدث مع أي طبقة أخرى، لكننا نفرض الطبقية بصرامة لعزل نطاقات الفشل. نريد تجنّب حالة يُغرق فيها فشل في scion-cache إقليمي خوادم scion-server الأصلية فيُسقط النظام بأكمله.

تحافظ كل طبقة من هذا النظام على معدل إصابة في التخزين المؤقت يتجاوز 99% ولا تتطلب حالة طويلة الأمد، لذا يسهل توسيعها عند الحاجة. أصبحت البصمة التحتية لدينا لـ Scion الآن أصغر بـ 200 مرة من بنيتنا السابقة لمرايا git من حيث متطلبات المعالجة والذاكرة. تجلب وظائف CI والبحوث الشيفرة أسرع بمقدار درجتين عشريتين (بالثواني بدلًا من الدقائق)، مما يحرر قدرًا كبيرًا من السعة عبر التجمع؛ فقد حققت CI وحدها مكسبًا في سعة المعالجة بنسبة 25%. ولا يحتاج العملاء ولا ذاكرات التخزين المؤقتة إلى إجراء صيانة للمستودع، مما يبسّط إدارة دورة حياة وظائفنا.

ما تعلمناه أثناء بناء Scion

بدأنا بناء Scion في الوقت نفسه تقريبًا الذي أصبح فيه Claude Mythos Preview و Claude Tag متاحَين داخليًا. وقد أدى كلا الإصدارين في آن واحد إلى تضخيم الحاجة إلى Scion وتسريع بشكل ملموس لسرعة بنائه.

إليك مثالًا لافتًا بشكل خاص. في وقت سابق من العام، كتبنا يدويًا إلى حد كبير الإصدار الأول من خط أنابيب الاستيعاب من git إلى Scion كنموذج أولي. ظننا أنه جيد—إلى أن حصلنا على لقطة داخلية مبكرة من Claude Mythos Preview. طلبنا منه إعادة كتابة كل شيء، ودون أي تعليمات إضافية، أنتج نسخة تستهلك ذاكرة أقل بـ 20 مرة وتعمل أسرع بـ 4 مرات، مع الحفاظ على جميع الثوابت الضمنية المتعلقة بترتيب الاستيعاب وهياكل البيانات.

ما تعلمناه أثناء بناء Scion وتشغيله يقدم دروسًا مثيرة للاهتمام حول كيف قد يبدو بناء برمجيات بمقياس الوكلاء (agent-scale).

سيتزايد شيوع التطوير السريع بفريق صغير. فريق مكوّن من سبعة أشخاص بنى Scion و Antique (أداة مراجعة الشيفرة لدينا، والتي يمكننا بسهولة أن نكتب عنها تدوينة أخرى كاملة)، فضلًا عن نصف دزينة من الأنظمة ذات الصلة، وهاجرنا إليها بالكامل في خمسة أشهر. وفعلنا كل ذلك بينما تزايد حجم الشيفرة المدمجة يوميًا بمقدار 10 مرات. في الماضي، كان تطوير ونشر نظام تحكم بالمصدر كهذا يتطلب من شركة سنوات من الترحيل التدريجي وبمهندسين أكثر بكثير. نعتقد أن هذا النوع من الترحيل السريع والرشيق سيصبح أكثر شيوعًا في المستقبل.

المهندسون ليسوا أقل قيمة، لكن طبيعة عملهم آخذة في التغيير. جميع المهندسين الذين عملوا على هذا النظام يقيّمون الآن Claude على أنه أفضل منهم في كتابة الشيفرة. لكن مهندسينا لا يزالون قدموا الفهم الذي لا يقدّر بثمن للمكونات عالية المستوى بين الأنظمة والمقايضات على مستوى التصميم، واتخذوا اختيارات مستنيرة حول المشكلات التي أردنا حلها والنطاق الذي كنا نعلم أننا بحاجة إلى تحقيقه. وكثيرًا ما وجدنا أن دور المهندسين كان إخبار Claude بـ"لا". فالوكلاء أحيانًا ينتهكون قيود النظام الأساسية لتلبية نمطٍ لم يكن يجب السماح به من الأصل. وكان هذا شائعًا بشكل خاص في عملية الترحيل لدينا. فعلى سبيل المثال، كانت هناك أنظمة متعددة حاولت معرفة وقت دمج تغيير معين في الفرع الرئيسي main بالقوة الغاشمة من خلال قراءة سجل الالتزامات Commit Log خطيًا بدلاً من سؤال أداة مراجعة الشيفرة لدينا. كما تستخدم Anthropic على نطاق واسع المراجعة الخصومية (Adversarial Review)، وعلى الرغم من أنها فعالة للغاية بطرق كثيرة، إلا أنها قد تكون قصيرة النظر أيضًا، لذا احتاج المهندسون المهرة إلى توجيه Claude بعيدًا عن الهندسة المفرطة لأجزاء من النظام استجابةً لمخاوف افتراضية. فمثلًا، كانت إحدى هذه المراجعات متحفظة بشكل مفرط بشأن الوثوق بخدمة داخلية أخرى، مما أدى إلى قيام Claude بإضافة تحقق وتعقيد زائدين. ولا يزال أعضاء فريقنا يراجعون كل طلب تغيير على النظام، لكنهم يفحصون الآن القصد من التغيير بدلاً من قراءة كل سطر من الشيفرة.

تمكنا من تحسين عملية التحسين والجودة بشكل كبير. بفضل قدرة Claude على كتابة كميات هائلة من الشيفرة أسرع بكثير مما نستطيع نحن، يُعد Scion من بين أكثر قواعد الشيفرة التي عملنا عليها اختبارًا وحمايةً جيدة. حتى ضمن جدولنا الزمني الضيق، تمكنا من بناء محاكاات محكمة لكل تفاعل غير بسيط في البنية التحتية وإدارة المصادر واجهناه على الإطلاق، بالإضافة إلى الفحص العشوائي (Fuzzing) وتحديد معدل متطور. كما عثر Claude أيضًا بارتياح تام على تحسينات جوهرية — على سبيل المثال، تحسين خوارزمي لاستعلامات النسب (Ancestry Queries) تجاهل أحد فهارسنا — كان سيستغرق من خبير أيامًا أو أسابيع من التحليل والضبط… ثم أعاد فعل ذلك بالكامل في اليوم التالي.

مهّدنا الطريق لأشكال جديدة من أمن المستودعات الضخمة (Monorepo). إدارة السلامة والأمن والامتثال في مستودع ضخم (Monorepo) لا تقل أهمية عن إدارة حجمه ونطاقه. لقد بنينا Scion مع وضع ذلك في الحسبان منذ البداية. فهو يدعم تحكمًا وافرًا في الوصول على مستوى المستودعات، بالإضافة إلى إمكانية تطبيق الأذونات على المجلدات الفردية من أجل حماية أكثر الشيفرة حساسية دون فقدان مزايا المستودع الضخم. وعلاوة على ذلك، فإن أدوات مراجعة الشيفرة التي بنيناها تستطيع التعبير عن قيود دلالية معقدة على الموافقات، مما يتيح لنا التمييز بين الأمور البسيطة مثل التغييرات التي تقتصر على التعليقات والتغييرات المنطقية الحساسة، بحيث يتمكن المراجعون البشريون من التركيز على التغييرات الأكثر أهمية.

مستوى جديد من التميز التشغيلي أصبح ممكنًا. يستخدم فريقنا Claude Tag بكثافة، مما ساعدنا في مراقبة كل مكون من مكونات النظام. فعلى سبيل المثال، أنشأنا قنوات Slack كلّفنا فيها Claude بالتركيز بشكل وسواسي على صحة مكون واحد. نطلق على هذه الوكلاء من Claude اسم "المشجعين المتحمسين" (Superfans). لدينا مشجع متحمس لـ scion-daemon، ومشجع متحمس لـ scion-cache، ومشجع متحمس لطابور الدمج Antique، وهكذا. لهم صلاحية الوصول إلى بيانات القياس عن بُعد والسجلات لدينا، ويتصرفون كمهندس خبير ليس لديه ما يفعله أفضل من تحديث المخططات والبحث عن أي شيء غريب. لدينا أيضًا تنبيهات تقليدية لجميع أنظمتنا، لكن مشجعينا المتحمسين يستطيعون اكتشاف مشكلات خفية وجديدة تجعل هذه التنبيهات تبدو أحادية البعد بالمقارنة.

نعيد التفكير جذريًا في افتراضاتنا المسبقة. دفعنا هذا المشروع إلى النظر بعين فاحصة جدًا في سير العمل الأخرى المصممة للنطاق البشري. فطابور الدمج (Merge Queue) السليم مثلًا لا معنى له كثيرًا على نطاق الوكلاء. ما معنى CI أصلًا عندما يمكن دمج مئات أو حتى آلاف التغييرات أثناء تشغيل الاختبارات؟ لم نتمكن من محاكاة المعيار الصناعي المتمثل في قفل عام للمستودع على طابور الدمج بطريقة فعالة، لذا استثمرنا بدلاً من ذلك في الاختبارات الآلية بعد الدمج وقبل النشر. هذا يعني بالفعل أن التغييرات المتزامنة قد تتعارض، لكن Claude يستطيع عادةً إصلاح هذه التعارضات أسرع مما يستطيع البشر حتى تحديدها.

المساهمة في المنظومة الأوسع

نرى Scion كجزء واحد فقط من الإجابة على مخاوف التوسع التي أثارها وكلاء الذكاء الاصطناعي ذوو القدرات المتزايدة. نحن نشارك هذه التفاصيل كمثال على كيفية معالجة الفرق لتحديات مماثلة، مع أننا لا نتوقع أن يناسب حلّنا، أو اعتباراتنا، كل حالة.

Scion ليس بأي حال بديلاً مناسبًا عن git للاستخدام العام. فالمفاهيم التي حددناها هنا لا معنى لها فعليًا إلا للمستودعات الضخمة (Monorepo) للغاية، التي تحتوي إما على عشرات الآلاف من المهندسين أو على أسراب من الوكلاء يكتبون الشيفرة بإنتاجية وفيرة. بالإضافة إلى ذلك، تتميز Anthropic بأن قدرتنا على إنفاق الرموز (Tokens) للاستخدام الداخلي تفوق بكثير ما قد يرغب أي عمل آخر واقعيًا في إنفاقه. نفعل هذا لمعالجة احتياجاتنا الخاصة في تطوير البرمجيات، ولامتبار قدرات Claude.

ومن الناحية العملية، من الصعب تقديم Scion في شكل يكون مفيدًا على نطاق واسع للمؤسسات الأخرى. فهو يتباين بشكل كبير مع git، مما يعني أن الشركات ستحتاج إلى ترحيل كل جزء من دورة حياة التطوير، كما يتطلب أدوات مراجعة شيفرة وبحث شيفرة وCI خاصة به. ونحن إن نسخنا الداخلية من هذه المكونات مخصصة إلى حد كبير، لذا سيكون من الصعب على المؤسسات الأخرى تبنّيها، ونخشى أن محاولة بناء نسخة عامة تحاول إرضاء الجميع لن تكون في الحقيقة مفيدة جدًا.

ومع ذلك، نتوقع أن تصبح هذه الفئة من المشكلات أكثر شيوعًا خلال الستة إلى 12 شهرًا القادمة، ومن شأنه أن يكون استخدامًا غير كفء للموارد الهندسية أن تواجه كل شركة تستخدم git تحديات مماثلة بمفردها. ونظرًا لذلك، نعتقد أن أكثر ما يمكننا فعله بتأثير هو مشاركة تفكيرنا، حتى يتمكن المطورون الآخرون من تطبيق بعض أكثر أجزاء Scion نجاحًا على git دون الخروج عن النموذج العام. لا يتعين على خادم git أن يعمل بنفس الطريقة التي يعمل بها عميل git؛ فهناك هياكل خوادم مبتكرة توفر تحسينات كبيرة في قابلية التوسع. يمكن لمنصات git توفير RPCs من جانب الخادم شاملة مثل Scion، وربما حتى بطريقة موحدة عبر المنصات (forges) يمكن لعميل git أن يتعلم التواصل معها. ولا يتعين على بروتوكول التفاوض أيضًا أن يبدو تمامًا كما هو اليوم، كما يمكن جعل ميزات sparse و shallow المتنوعة في git تعمل معًا بشكل جيد.

وأخيرًا، نود أن نقر بأن مجتمع git أنفق ما يقارب عقدين من الزمن على توسيع نطاق المنصة لملايين المطورين. إن مساهمتنا أضيق نطاقًا بكثير: فهي مشاركة نظرتنا المبكرة في كيفية تفاعل تطوير البرمجيات الوكيلي (agentic) مع هذه الأنظمة، حتى نتمكن من الشراكة مع GitHub و GitLab ومجتمع OSS لدعم الاحتياجات المتغيرة للمطورين. نحن جميعًا في هذا معًا مع تقاطع دورة حياة تطوير البرمجيات مع النمو الأسي للذكاء الاصطناعي.

الحواشي

01تخزين الملفات المتغيرة بالنسبة إلى الأصل الأول لعملية الدمج هو خيار أسلوبي؛ عمليًا، وجدنا أن الناس يهتمون فقط بالسجل أو blame للالتزامات (commits) على الخط الرئيسي في التطوير القائم على الجذع (trunk-based development) في المستودع الأحادي (monorepo).

02على وجه التحديد، المكوّن الخادمي من Sapling، Mononoke. وقد طوّر هذا المشروع العديد من التقنيات التي نستخدمها في Scion، وعلى وجه الخصوص Bonsai ، نموذج البيانات.

المؤلفون والشكر &

شكر وتقدير

كتبه Nick G. وفريق إدارة الكود المصدري: S.G. و R.K. و Dan C. و Garrett H. و Ben L. و Colin M. و Joe P. إننا ممتنون لـ Vilas J. و Sergiu D. لدعمهما فريق إدارة الكود المصدري في هذه الرحلة الطموحة، ولـ Amir O. على مساهماته المبكرة في Antique.