السِّرَاج

نشرت OpenAI بهدوء Symphony على GitHub هذا الأسبوع. إنه daemon طويل التشغيل يراقب لوحة Linear الخاصة بك بحثًا عن مهام، وينشئ مساحة عمل معزولة لكل مشكلة، ويطلق وكيل Codex، ويبث إثباتات العمل — حالة CI، مراجعة PR، فيديو توضيحي — ثم يدمج PR عند القبول. المهندسون لا يشرفون على تشغيل كل وكيل بشكل فردي. هم يديرون العمل.

سطر واحد في ملف README:

"Symphony يعمل بشكل أفضل في قواعد الأكواد التي تبنّت harness engineering."

فتنقر على الرابط.

Harness Engineering هو تشريح لخمسة أشهر. منتج واحد، صفر أسطر كود مكتوبة يدويًا، نحو مليون سطر تم شحنها، ثلاثة مهندسين نمَوا إلى سبعة، حوالي 1,500 طلب سحب. 3.5 PR لكل مهندس يوميًا. الإنتاجية ازدادت مع نمو الفريق — وهذا هو الرقم المهم. التراكم حقيقي عندما تكون البنية صحيحة.

في منتصف المقال، يشيرون إلى Ralph Wiggum Loop.

إذا كنت تتابع Forgeloop-kit، فأنت تعلم أن Ralph loop هي البنية التي نشغّلها منذ يناير 2026 — قبل أن يوجد منشور harness engineering. النمط نفسه: توجيه المهام عبر git، تنفيذ بواسطة وكلاء، التحقق من إثبات العمل، حلقة. فريق OpenAI اكتشفه بشكل مستقل، وشغّله داخليًا لمدة خمسة أشهر، ثم نشر الدليل. Symphony هو ما بنَوه فوقه.

الدليل على أن النمط يعمل ليس مقالة مدونة. إنه النظام الذي ينشر هذه المقالة.

ما بنَوه فعلًا

ما كانوا يبنونه حقًا — تحت المنتج، من خلال المنتج — كان بيئة قادرة على بناء المنتجات.

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

هذه أسئلة مختلفة عن "ماذا يجب أن تفعل هذه الميزة؟". التحوّل هو من بانٍ إلى مهندس سِراج.

العبارة من المنشور التي تستحق أن تُوشَم في مكان ما:

"ما الذي يتغير عندما لا تكون المهمة الأساسية لفريق هندسة البرمجيات كتابة الكود، بل تصميم البيئات، وتحديد النوايا، وبناء حلقات التغذية الراجعة التي تسمح للوكلاء بأداء عمل موثوق."

هذا هو الوصف الوظيفي لما سيأتي بعد ذلك. كتبت عنه من زاوية الأصيل/العامل — هذا الشيء نفسه من داخل قاعدة الأكواد.

مشكلة AGENTS.md التي واجهوها أولًا

في بداية التجربة، جربوا المقاربة الواضحة: ملف AGENTS.md ضخم واحد يحتوي على كل ما يحتاجه الوكيل. فشل بطرق متوقعة.

ازدحام السياق. ملف تعليمات عملاق لا يترك مساحة للمهمة، والكود، والوثائق ذات الصلة. الوكلاء يطابقون الأنماط محليًا بدلًا من التنقل بقصد. القواعد تتعفن فورًا — البشر يتوقفون عن صيانة دليل أحادي الكتلة، والوكلاء لا يستطيعون تمييز ما لا يزال صحيحًا. لا تحقق آلي.

حلّهم: AGENTS.md كجدول محتويات، حوالي 100 سطر، مع مؤشرات إلى دليل docs/ مهيكل. المعرفة تعيش في المستودع؛ الملف يرسم خريطتها فقط.

SkDD حلّ هذا من زاوية مختلفة. المهارات معيارية بالتصميم — ملفات SKILL.md منفصلة، كل منها يؤدي شيئًا واحدًا، كل منها قابل للصيانة بشكل مستقل. المكافئ لهيكل docs/ الخاص بهم، لكن بشكل مهارة بدلًا من شكل وثائق. المبدأ نفسه: معرفة المستودع يجب أن تكون قابلة للتنقل، لا أحادية الكتلة.

إذا تجاوز ملف AGENTS.md الخاص بك 200 سطر، فهو بالفعل عبء.

ما هو عنق الزجاجة الحقيقي

إنتاجية الكود ليست عنق الزجاجة. لم تكن كذلك منذ فترة.

فريق OpenAI أدرك ذلك بسرعة. بمجرد أن أصبح Codex يشحن PR بشكل موثوق، أصبح القيد هو قدرة البشر على ضمان الجودة. ردّهم كان جعل كل ما يحتاجه الوكيل للتحقق مقروءًا مباشرة للوكيل — نسخ تطبيق لكل worktree، وChrome DevTools Protocol موصول بـ runtime الوكيل، ومنظومات مراقبة مؤقتة (سجلات، مقاييس، تتبعات) لكل worktree.

أوامر مثل "تأكد من أن بدء تشغيل الخدمة يكتمل في أقل من 800 مللي ثانية" تصبح قابلة للمعالجة عندما يستطيع الوكيل فعلًا الاستعلام عن مقاييس البدء. أوامر مثل "لا يوجد span في مسارات المستخدم الأربعة الحرجة يتجاوز ثانيتين" تصبح قابلة للمعالجة عندما يكون لدى الوكيل وصول إلى PromQL.

هذا هو مبدأ depth-first الذي يصفه المنشور: عندما يفشل شيء ما، الحل ليس أبدًا "حاول بجهد أكبر". السؤال دائمًا هو "ما القدرة المفقودة، وكيف نجعلها مقروءة للوكيل؟". تبني القدرة، تجعلها متاحة، والوكيل يستخدمها.

الحلقة لا تتوقف عند المهام الصعبة. تتوقف عند المهام التي لم تُجهَّز فيها البيئة لهذا النوع من العمل.

ما المتشابه وما المختلف

بنية Forgeloop تتطابق تقريبًا. git sync ← توجيه المهام ← خطة ← بناء ← تحقق ← push. Ralph loop هي الحلقة نفسها التي يصفونها — الوكلاء يعملون على مهام منفصلة، يُودعون إثباتات العمل، ويكررون. الفرق هو المساحة: OpenAI كان لديها ثلاثة مهندسين بدوام كامل وخمسة أشهر. Forgeloop محمول، مصمم للتثبيت في أي مستودع والعمل من اليوم الأول.

فرق ملموس يستحق التسمية: Symphony مبني حول Linear كقائمة انتظار للعمل. Forgeloop يستخدم GitHub Projects أو ملفات markdown محلية — IMPLEMENTATION_PLAN.md، REQUESTS.md. لا اعتماد على Linear، لا SaaS خارجي مطلوب. للفرق التي تعيش بالفعل في GitHub، هذا هو الخيار الافتراضي الصحيح. البدائيات مختلفة؛ النمط متطابق.

الأنماط التي انتقلت بسلاسة: المعرفة المعيارية المدفوعة بالمهارات، التنفيذ المدفوع بالمهام (لا بالمحادثة)، المراجعة من وكيل إلى وكيل، الوقت البشري كمورد نادر حقًا.

الأنماط التي تعمقوا فيها أكثر: العزل لكل worktree للتشغيل المتوازي للوكلاء، مقروئية واجهة المستخدم عبر DevTools Protocol، المراقبة المؤقتة. هذه ليست في Forgeloop-kit بعد. إنها في خارطة الطريق — والآن هناك مواصفات عامة للبناء عليها.

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

Symphony: مستوى أعلى

Symphony هو ما يجعله harness engineering ممكنًا.

بمجرد أن يُصمَّم المستودع ليتنقل فيه الوكلاء — وثائق مهيكلة، تحقق مؤتمت، مراقبة مقروءة — يكون Symphony هو الـ daemon الذي يزيل الخطوة اليدوية الأخيرة: مطور يفتح حاسوبه ويبدأ تشغيلًا. يراقب Linear، ينشئ مساحة عمل لكل مشكلة، يطلق Codex، ويدمج طلبات السحب. الحلقة لا تنتظرك. تعمل وأنت نائم.

السياسة تعيش في WORKFLOW.md، مُنسَّخة مع الكود، تُحمَّل في كل تشغيل. المبدأ نفسه لـ AGENTS.md-كخريطة: المستودع يملك تعليماته التشغيلية، وهذه التعليمات تتطور مع قاعدة الأكواد.

تفصيل يدفنه ملف README: يقول إنك تستطيع أن تطلب من وكيل البرمجة الخاص بك تنفيذ Symphony من المواصفات. الأداة المصممة لتشغيل الوكلاء هي نفسها مصممة لتُبنى بواسطة وكيل. هذا ليس تعاودًا لطيفًا — إنها المنهجية تُصادق على نفسها. إذا كان مستودعك مُهندسًا بالسراج، يصبح بناء Symphony مهمة وكيل قابلة للمعالجة.

Symphony موسوم بـ "low-key engineering preview for trusted environments". ليس جاهزًا للإنتاج لجميع الفرق بعد. لكن المواصفات عامة والتنفيذ المرجعي موجود. الهدف مرئي.

المنظومة التي لم يسمّها أحد بعد

SkDD وharness engineering وSymphony ليست منهجيات متنافسة. إنها متطلبات مسبقة متتالية.

SkDD هي طبقة المعرفة. الوكلاء يصوغون مهارات أثناء البناء. المستودع يراكم قدرات قابلة لإعادة الاستخدام. كل جلسة تترك شيئًا وراءها — قابل للاستدعاء، قابل للاكتشاف، قابل للتركيب.

Harness engineering هي طبقة البيئة. المستودع مصمم ليتنقل فيه الوكلاء. AGENTS.md هي خريطة. المراقبة قابلة للاستعلام بواسطة الوكلاء. التحقق مؤتمت. البيئة تجعل العمل قابلًا للمعالجة.

Symphony هي طبقة التنسيق. daemon يقرأ قائمة انتظار العمل، يوزع الوكلاء لكل مشكلة، يجمع إثباتات العمل، يدمج طلبات السحب. البشر يديرون العمل، لا الوكلاء.

لا يمكنك تشغيل Symphony على مستودع غير مُسرَّج — سينتج فوضى أسرع فحسب. لا يمكنك بناء سراج جيد بدون بدائيات المعرفة لملئه. الترتيب مهم. ابدأ بطبقة المعرفة، ابنِ البيئة، وسيصبح التنسيق ممكنًا.

Forgeloop-kit يغطي الطبقة الوسطى — سراج محمول تستطيع الفرق تثبيته من اليوم الأول، بدون فريق من ثلاثة مهندسين، بدون خمسة أشهر من المدرج، بدون اشتراك Linear. كان يعمل قبل أن تنشر OpenAI الدليل. Symphony هو الدرجة التالية. المسافة بين حالة معظم المستودعات الآن وأين يجب أن تكون هي العمل.

ما يجب أن تأخذه من هذا إذا كنت تبني

المنشور يحتوي على خيوط مدفونة. ما يتراكم فعلًا:

ابدأ بالسراج، لا بالمهام. قبل أن تعطي وكيلك قائمة مهام، اسأل كيف يجب أن يبدو المستودع حتى يتمكن وكيل من التنقل فيه. ماذا يوجد في AGENTS.md؟ أي وثائق موجودة؟ ماذا يستطيع الوكيل تشغيله للتحقق من عمله؟ جودة السراج هي سقف إنتاجية الوكلاء.

اجعل AGENTS.md خريطة، لا دليلًا. حوالي 100 سطر. مؤشرات. دع هيكل المستودع يحمل الباقي. إذا كنت مغريًا بكتابة كل شيء في ملف واحد، اكتب skill بدلًا من ذلك.

جهّز الأدوات لوصول الوكيل، لا لمقروئية البشر. السجلات، المقاييس، حالة واجهة المستخدم — إذا استطاع الوكيل الاستعلام عنها، يستطيع الوكيل التحقق منها. ابنِها مرة واحدة، استخدمها في كل مهمة. هذا هو المُضاعِف.

عنق الزجاجة ليس أبدًا التوليد. وكيلك ليس بطيئًا جدًا. بيئتك ليست مقروءة بما يكفي. صحّح السراج قبل أن تصحح النموذج.

تفكيك المهام بأسلوب depth-first هو الوحيد الذي يتراكم. عندما تفشل مهمة، اعثر على القدرة المفقودة. ابنِها. اجعلها مقروءة. الآن كل فئة المهام أصبحت مفتوحة. النهج العرضي يعطي تغطية. النهج العمقي يعطي تراكمًا.

أجرت OpenAI تجربة لمدة خمسة أشهر لتأكيد ما يفعله Ralph loop في الإنتاج. ثم شحنوا Symphony كدرجة تالية. السؤال الآن هو ما إذا كان مستودعك جاهزًا لذلك.

المنظومة هي: SkDD ← سراج ← Symphony. الترتيب مهم.

Forgeloop-kit: forgeloop.zakelfassi.com
SkDD: github.com/zakelfassi/skills-driven-development
Symphony: github.com/openai/symphony