16 وكيلًا من Claude يكتبون مُصرِّف C من 100 000 سطر خلال أسبوعين بتكلفة $20 000

أجرى نيكولاس كارليني، الباحث في فريق Safeguards في Anthropic، تجربة عمل خلالها 16 نسخة من Claude Opus 4.6 بالتوازي على مستودع مشترك، وكتبت من الصفر مُصرِّفًا للغة C بلغة Rust. ولم يتدخل البشر إلا نادرًا. وخلال أسبوعين وقرابة 2000 جلسة من Claude Code، أنتج الوكلاء 100 000 سطر من الكود. ويبني المُصرِّف نواة Linux 6.9 القابلة للإقلاع على معماريات x86 وARM وRISC-V. وبلغت فاتورة API أقل بقليل من $20 000.

كيف صُمّمت منظومة الوكلاء

فكرة التصميم بسيطة. يعمل Claude في حلقة لا تنتهي: ينهي مهمة ثم يأخذ التالية. يعيش كل وكيل في حاوية Docker منفصلة، ويستنسخ مستودع git مشتركًا من نوع bare، ثم يدفع تغييراته إليه. ولمنع الوكلاء من حل المشكلة نفسها، تُستخدم آلية أقفال: ينشئ Claude ملفًا نصيًا مثل current_tasks/parse_if_statement.txt، ويمنع git وكيلًا ثانيًا من الاستحواذ على المهمة نفسها. تتكرر تعارضات الدمج كثيرًا، لكن النموذج يحلّها بنفسه.

لا يوجد منسّق (orchestrator)، ولا قنوات اتصال مشتركة بين الوكلاء. يقرر كل وكيل بنفسه ما يفعله لاحقًا، ويختار عادةً المشكلة «التالية الأكثر وضوحًا». وفي إحدى المرات نفّذ وكيل عن طريق الخطأ الأمر pkill -9 bash، فقطع حلقة عمله بنفسه.

لم يذهب الجهد الأكبر إلى كتابة الموجّهات (prompts)، بل إلى البيئة: الاختبارات والسجلات والتغذية الراجعة. فمخرجات الاختبارات مقيّدة بعدة أسطر كي لا تُثقل السياق. وتُكتب الأخطاء في سطر واحد بوسم ERROR ليسهل البحث عنها بـ grep. ولمعالجة «العمى الزمني» أُضيف الخيار --fast، الذي يشغّل عيّنة محددة (حتمية) لكل وكيل تمثّل 1% أو 10% من الاختبارات.

أين اصطدموا بالسقف

ما دامت الاختبارات مستقلة، فالعمل المتوازي سهل: يأخذ كل وكيل اختبارًا فاشلًا خاصًا به. لكن نواة Linux مهمة ضخمة واحدة. فقد اصطدم الوكلاء الـ16 كلهم بالخطأ نفسه، وكتب كلٌّ منهم فوق تعديلات الآخر. وجاء الحل عبر استخدام GCC كمرجع حاكم (oracle): كان GCC يُصرِّف جزءًا عشوائيًا من ملفات النواة، ويُصرِّف Claude الباقي. وهكذا صار الوكلاء يصلحون أخطاءً مختلفة في ملفات مختلفة. أما أزواج الملفات التي كانت تفشل معًا فقط، فاستُخدم معها delta debugging.

كما وُزّعت على الوكلاء أدوار: وكيل يدمج الكود المكرر، وآخر يسرّع المُصرِّف نفسه، وثالث يعنى بكفاءة الكود المولَّد، ورابع يؤدي دور ناقد للبنية المعمارية من منظور مطوّر Rust، وخامس يتولى التوثيق.

الأرقام والقيود

• الحجم: نحو 100 000 سطر بلغة Rust، دون أي اعتماديات سوى المكتبة القياسية.
• الموارد: 2 مليار توكن إدخال و140 مليون توكن إخراج، وما يقارب $20 000.
• الاختبارات: 99% في معظم المجموعات، بما فيها GCC torture.
• يبني: Linux 6.9 (x86 وARM وRISC-V) وQEMU وFFmpeg وSQLite وPostgres وRedis وDoom.
• تطوير بأسلوب «الغرفة النظيفة»: لم يكن لدى Claude وصول إلى الإنترنت.
• دون مُجمِّع (assembler) ولا رابط (linker) خاصين: أُتمتت هاتان الوحدتان في الآخر، وما زالتا تعانيان من أخطاء.
• معمارية x86 بنظام 16 بت للوضع الحقيقي (real mode) غير منفَّذة: يتجاوز الناتج 60 كيلوبايت بينما حد النواة 32 كيلوبايت، ولذلك يُستدعى GCC.
• الكود أقل كفاءة من كود GCC حتى مع تعطيل التحسينات.

يكتب كارليني صراحةً أن المُصرِّف اقترب من حدود قدرات Opus: فالميزات الجديدة والإصلاحات كانت تكسر بانتظام ما سبقها. ويظهر التقدم عبر الأجيال بوضوح: فنماذج Opus 4 الأولى بالكاد أنتجت مُصرِّفًا يعمل، وOpus 4.5 اجتاز لأول مرة مجموعات اختبار كبيرة، لكنه لم يبنِ مشاريع حقيقية.

الخلاصات العملية

الدرس الرئيسي لمن يبنون وكلاء مستقلين: جودة آلية التحقق أهم من النموذج نفسه. فإذا كان المُدقِّق غير دقيق، فسيحل الوكيل المهمة الخطأ بثقة. لذلك ينبغي كتابة الاختبارات مع مراعاة النموذج: مخرجات قصيرة، وسجلات متوافقة مع grep، وعيّنات فرعية سريعة وحتمية، ونظام CI يمنع كسر الإيداعات (commits) السابقة.

الدرس الثاني: التوازي يتطلب تفكيك المهمة. فإذا كانت المهمة متكتلة، فالوكلاء الإضافيون يعرقلون العمل فقط، أما وجود مرجع عملي معروف فيساعد على تقسيمها إلى أجزاء مستقلة.

الدرس الثالث: $20 000 لقاء مُصرِّف بمستوى بناء Linux أرخص بكثير من فريق مهندسين، لكنها تبقى أغلى من الاشتراك. وقد نُشر الكود، ويمكن اختباره على مشاريع C الخاصة بك. ويتحفظ المؤلف نفسه: فالتطوير المستقل بالكامل ينطوي على مخاطر حقيقية، ولا يمكن حتى الآن الاستغناء عن الرقابة البشرية على جودة الكود وأمانه.