00:00:00قامت شركة Anthropic للتو بشيء ضخم، حيث أطلقت 16 عميلاً من عملاء Claude
00:00:05لبناء مترجم لغة C (C compiler)، وبعد العمل على مدار الساعة لمدة أسبوعين، نجحوا بالفعل في بناء واحد قادر على تجميع
00:00:11نواة نظام Linux وحتى تشغيل لعبة Doom، وهو أمر مثير للإعجاب حقاً ولم يكن ممكناً بالتأكيد
00:00:16باستخدام الإصدارات القديمة من Opus 4. لكن البعض يصف هذا الإنجاز بأنه مجرد “طعم للنقرات” (clickbait) و
00:00:22نصف حقيقة بسبب التقنيات المشكوك فيها التي استخدمتها Anthropic لتحقيق هذه النتيجة.
00:00:28لذا، هل غشت Anthropic؟ اضغط على زر الاشتراك ودعنا نكتشف ذلك.
00:00:31سنقسم هذا الفيديو إلى ثلاثة أجزاء. أولاً، سنستعرض كيفية إعداد التجربة،
00:00:37ثم سننتقل إلى النتائج الرئيسية، والتي أعتقد أن كل مطور سيتعلم منها الكثير،
00:00:42وأخيراً، سنناقش مدى صحة النتائج، لأن لدي بعض الآراء حقاً
00:00:47حول الطريقة التي تمكنت بها Anthropic من بناء هذا المترجم. حسناً، أجرى هذه التجربة نيكولاس
00:00:52كارليني، وهو في رأيي إنسان ذكي جداً. أعني، دعونا نلقي نظرة على كيفية
00:00:58إعداده لهذا الأمر. المشروع الفعلي كان موجوداً في مجلد يسمى Upstream، وكان متصلاً
00:01:03بـ 16 حاوية Docker مختلفة. أعلم أن هناك أربعة فقط هنا، لكن دعونا نتخيل وجود 16.
00:01:08وكل واحدة من حاويات Docker هذه كانت تحتوي على نسخة من كود Claude تعمل بإصدار Opus 4.6 و
00:01:15تقوم بنسخ مستودع Upstream إلى مساحة العمل (Workspace) وإجراء كافة التغييرات هناك ثم
00:01:21دفعها إلى Upstream. كانت هذه فكرة ذكية جداً لأن كل عميل كان يعمل بمعزل عن غيره دون
00:01:27التأثير على عمل العملاء الآخرين. وفي حال حدوث تعارض في الدمج (merge conflict)، كان كلوود
00:01:32ذكياً بما يكفي لحله ثم دفعه مرة أخرى إلى Upstream. كل عميل يختار من بين
00:01:38بعض المهام. لست متأكداً ما إذا كانت هذه المهام قد وُضعت بواسطة بشري أم بواسطة العميل نفسه
00:01:44بناءً على تشغيل بعض الاختبارات، ولكن كانت هناك مهام محددة بأسماء، وكان كل عميل
00:01:50يأخذ مهمة جديدة وعندما يفعل ذلك، يبدأ جلسة جديدة. وللحفاظ على
00:01:56استمرارية عمل هؤلاء العملاء لفترة طويلة، تم استخدام حلقة Ralph، حيث يعمل العملاء على المهمة،
00:02:02وينهونها، ثم يدفعون التغييرات لـ Upstream، ثم يختارون مهمة جديدة بجلسة نظيفة ويكررون ذلك مراراً.
00:02:08إذا شاهدتم فيديونا عن Ralph، ستعرفون أن السر في استمرارية العملاء لفترة طويلة
00:02:13هو وجود مهام محددة بوضوح. ولكن مع وجود 16 عميلاً يعملون في نفس الوقت،
00:02:19كيف تمنعهم من اختيار نفس المهمة تماماً؟ قفل المهمة (Task lock-in). الطريقة التي يعمل بها هذا هي
00:02:24وجود قائمة مهام في مكان لم يذكره المؤلف، حيث يختار العميل مهمة وينشئ
00:02:30ملفاً نصياً يطابق اسمها، ثم يقوم بعمل commit لقفل المهمة ليعمل عليها بمفرده
00:02:36ويدفع ذلك لمجلد Upstream. فإذا اختار عميل آخر المهمة نفسها
00:02:42وأنشأ نفس الملف النصي، وحاول دفعه للمستودع، سيرفضه Git موضحاً
00:02:48أن هذا الملف موجود بالفعل، وعندها سيتعين عليه العمل على مهمة مختلفة. وهذا هو الأساس
00:02:53الذي استخدمه كارليني لاختبار قدرة العملاء طويلو الأمد المدعومين بـ Opus 4.6، والنتائج
00:03:00مذهلة حقاً. ولكن من خلال هذه التجربة، وجد بعض الأشياء المثيرة للاهتمام التي
00:03:07أعتقد أن كل مطور يمكنه التعلم منها. الأمر الأول هو بناء نظام اختبار (test harness) أو سكربت
00:03:12يشغل أنواعاً مختلفة من الاختبارات، لأنه عندما كان نيك يدير التجربة -نعم، أصبحنا نناديه باسمه الأول الآن-
00:03:17لاحظ أن كلوود كان يكسر ميزات موجودة بالفعل في كل مرة يعمل فيها على ميزة جديدة.
00:03:23لذا قام ببناء نظام اختبار يتكون من اختبارات عالية الجودة من مشاريع مفتوحة المصدر مشهورة مثل
00:03:29SQLite و libjpg و Redis. ولمنع تشتيت السياق (context pollution)، حرص على أن يُظهر نظام الاختبار
00:03:35فقط السجلات (logs) المفيدة للعميل، وهي أساساً سجلات الأخطاء، ووضع
00:03:41بقية السجلات في ملف منفصل ليطلع عليها كلوود عند الحاجة. ومع ذلك، مع وجود آلاف
00:03:47الاختبارات، كان سيستغرق العملاء ساعات لتشغيل مجموعة الاختبارات بالكامل بدلاً من استغلال ذلك
00:03:52الوقت في القيام بشيء آخر. وهنا قام نيك بشيء ذكي للغاية، حيث أضاف خاصية “fast flag”
00:03:58إلى نظام الاختبار الخاص به، مما يعني أن العميل سيقوم بتشغيل إما 1% أو 10% فقط من إجمالي الاختبارات بناءً على
00:04:05الرقم الذي يحدده نيك. وإذا قام كل عميل بتشغيل 10%، فسيكون المجموع 160% من الاختبارات، وهو
00:04:13أكثر من كافٍ، وهذا ليس سيئاً. والطريقة التي تم بها الأمر هي أن الاختبارات، أي الاختبارات المحددة
00:04:19التي يشغلها كل عميل، كانت عشوائية ولكن مع استخدام نفس الرقم الأساسي (seed number)
00:04:25لجعلها حتمية (deterministic). فكل عميل سيحصل على نفس الاختبارات العشوائية وسيتمكنون في النهاية
00:04:31من إنهاء مجموعة الاختبارات بالكامل أسرع بكثير مما لو كان كل منهم يشغلها بمفرده. النقطة
00:04:36التالية ذكية أيضاً، لكنها مثيرة للجدل بعض الشيء لأنها تتعلق باستخدام التكنولوجيا الحالية.
00:04:41حتى الآن، كان كل عميل يقوم بتشغيل اختبارات الوحدات (unit tests) من عدة مشاريع مفتوحة المصدر،
00:04:46وكان ذلك يعمل بشكل جيد بتقسيمها إلى أجزاء بنسبة 1% أو 10%. ولكن عندما وصل الأمر لتجميع
00:04:53نواة Linux، وبما أن ملفات المصدر هذه ليست اختبارات وحدات مستقلة، أصبحت الأمور
00:04:58صعبة لأن كل عميل سيحاول تجميع الملف بالكامل، وسيواجه نفس الخطأ،
00:05:04وسيحاول حله وبالتالي سيلغي كل منهم إصلاح الآخر. لذا كان الحل الذي اتبعه نيك مجدداً
00:05:09هو جعل كل عميل يقوم بتجميع نسبة مئوية معينة، ثم ترك GCC، أي مترجم
00:05:15GNU، يكمل البقية. أطلق نيك على GCC اسم “العراف” (oracle) لأن نواة Linux يجب أن تُجمع
00:05:22بشكل مثالي باستخدامه. فإذا قام العميل بتجميع جزء من نواة Linux بمترجمه الخاص،
00:05:27أي جزء مختلف لكل عميل، والباقي باستخدام GCC، فإذا حدث خلل ما، فالمسؤول هو بالتأكيد
00:05:34مترجم العميل وليس GCC، وبالتالي سيقوم العميل بإصلاح ذلك الشيء بدلاً من إصلاح
00:05:40خطأ تسبب فيه عميل آخر. وهذا أمر مثير للجدل لأنه يستخدم مترجماً موجوداً للقيام
00:05:46بشيء طُلب من كلوود القيام به من الصفر. ولكننا سنتحدث أكثر عن هذا في نهاية
00:05:51الفيديو. دعونا ننتقل إلى النقطة التالية، وهي منح عميلك ذاكرة. وبما أن المهام الجديدة
00:05:57يتم العمل عليها بواسطة جلسات كلوود جديدة ليس لديها أي ذاكرة تقريباً عما تم إنجازه قبلها،
00:06:03وجد نيك أنه من المفيد تحديث ملف الـ readme واستخدام ملفات تقدم (progress files) مختلفة تتضمن تعليمات
00:06:09عن المكان الذي توقف عنده العمل وسير المشروع، لكي تبدأ الجلسات الجديدة من
00:06:13قاعدة جيدة ولا تسبب أخطاء تم إصلاحها مسبقاً. والنقطة الأخيرة والأكثر وضوحاً
00:06:18هي منح عملائك أدواراً مختلفة. فجمال وجود عدة عملاء يعملون على كود برمجى
00:06:23بالتوازي هو إمكانية القيام بعدة أشياء في نفس الجزء من الكود في نفس الوقت. وعندما
00:06:29لم يكن هناك كود جديد يُكتب، أعطى نيك أدواراً فريدة للعملاء مثل
00:06:35واحد للبحث عن الكود المكرر، وآخر لإيجاد طريقة لجعل الكود بأفضل أداء ممكن،
00:06:40حتى أنه كلف أحدهم بنقد التصميم من منظور مطور لغة Rust، والذي آمل ألا يكون
00:06:45قد أعلن للعملاء الآخرين أنه مطور Rust. ولكن رغم نجاح هذا المشروع،
00:06:51يبقى السؤال الحقيقي: هل غشت Anthropic لتحقيق هذه النتيجة؟ حسناً، نوعاً ما. فالمهمة كانت
00:06:57بناء مترجم لغة C من الصفر ولم يكن لدى العميل وصول للإنترنت، لذا فقد أنشأ
00:07:03كل الكود بنفسه. أم فعل ذلك حقاً؟ لأنه كان لديه وصول لمجموعات اختبار مشاريع
00:07:10مفتوحة المصدر وكان لديه وصول لنسخة مُجمعة من GCC. لذا تقنياً، كان بإمكانه فحص
00:07:16مترجم GCC وتجربته، وإعطاؤه مدخلات وفحص المخرجات واستخدام ذلك لتوجيه
00:07:24تصميم مترجمه الخاص المكتوب بلغة Rust. ولكن للإنصاف، لو كنت أبني مترجم C من
00:07:31الصفر، لفعلت الشيء نفسه. كنت سأنظر للمترجمات الموجودة، وأرى كيف تم تنفيذها
00:07:36وأستخدم ذلك لتشكيل اتجاه مترجمي الخاص. أما لو كنت أبني مترجماً
00:07:41للغة جديدة تماماً، فستكون الأمور أصعب بكثير، وربما سيكون هذا اختباراً جيداً حقاً
00:07:47للقيام به مع كلوود لنرى ما إذا كان جيداً حقاً في إنشاء المترجمات من الصفر. ربما
00:07:53تكون هذه فكرة أخرى ليجربها نيك، لكن دعونا ننتقل للحديث عن الطبيعة الذاتية (المستقلة)
00:07:57للتجربة لأن ذلك تم اختباره أيضاً. وللإنصاف، نعم، كلوود كتب كل الكود، لكنه
00:08:04حصل على توجيه مكثف من بشري. فالبشري هو من حدد مجموعة الاختبارات، وهو من بدأ
00:08:11الحلقة وقرر استخدام مسارات معينة. والبشري هو من بنى نظام الاختبار وأعطى العملاء
00:08:16أدواراً محددة. لذا، في حين أن الأمر أبعد ما يكون عن مجرد الطلب من كلوود بناء مترجم وتركه
00:08:22يعمل للأبد، فلا يمكنني القول إن الكود كتبه عميل كان مستقلاً بنسبة مائة بالمائة
00:08:28لأننا لا نعرف مدى جودة المترجم لو لم يكن هناك تدخل بشري في المقام الأول.
00:08:33وحتى مع كل هذه الأنظمة التي صممها البشر، كان لمترجم كلوود للغة C بعض
00:08:39القيود الرئيسية. فمثلاً، استخدم المجمّع (assembler) والواصل (linker) من GCC لأن ما أنشأه كان
00:08:46مليئاً بالأخطاء. كما احتاج لمترجم x86 بـ 16 بت الخاص بـ GCC لتشغيل Linux. وفوق كل ذلك،
00:08:54لم يكن الكود فعالاً جداً. فالنسخة الأكثر تحسيناً من مترجم كلوود كانت أقل
00:09:00كفاءة من النسخة الأقل تحسيناً لمترجم GCC. لذا يبدو أن المطورين
00:09:05لن يذهبوا إلى أي مكان قريباً، أو على الأقل في الوقت الحالي.