مصنع الكود: التحولات التنظيمية والتحقق العملي لتطوير البرمجيات المدعوم بالذكاء الاصطناعي

الادعاء الرئيسي لتقرير FR-01 – ظهور كيانات تنفيذية تتمتع بالمبادرة وقابلة للتكرار في إنتاج البرمجيات، وتحول نقطة الاختناق من «كتابة الكود» إلى «التعبير عن النية والتحقق منها» – تم تأكيده عملياً، ولكن «وحدة القياس» الخاصة به ثبت أنها خاطئة بمستوى واحد. في الأسبوع الماضي، أظهرت ثلاثة أنظمة حقيقية بشكل جماعي أن ما يدفع دالة الإنتاج للترقية ليس الاستقلالية الفردية للعامل (Agent)، بل نموذج المصنع الذي يتكون من «خط إنتاج + مجمع عمال + نظام تحكم في الوصول». وهذا يعني أن دالة إنتاج البرمجيات توسعت من الصيغة الأولية `Q = F(I, C, V)` لتصبح `Q = min(I, C, V, S, $)` حيث يمثل المتغير `S` المضاف حديثاً «أمن التنسيق» (التزامن الحصري، عقود الإيجار والكلب الحارس، عزل شجرة العمل worktree، والحكم الصارم على النجاح)، ويمثل الرمز `$` «قيود الميزانية» (قطع الدائرة اليومي). هذان المتغيران، اللذان كانا غائبين تماماً في FR-01، يحددان بشكل مباشر ما إذا كان مصنع الذكاء الاصطناعي يمكن أن يعمل بكفاءة واستمرارية، وأصبحا قيوداً صارمة جديدة.

مع إعادة تشكيل دالة الإنتاج، ترقت أيضاً نقطة العتبة للمبادرة. لم تعد L3 (الاستقلالية طويلة الأمد) شرطاً كافياً؛ فالنقطة الحرجة الحقيقية تكمن في الثلاثي `(قدرة L3) × (قنوات غير تفاعلية) × (تحكم ميكانيكي في الوصول)`. إذا كانت هناك قدرة L3 ولكن تفتقر إلى قنوات غير تفاعلية، فإن العامل (Agent) يمكن أن يعمل فقط «بتغذية بشرية»، ولا يمكن جدولته على نطاق واسع. وعلى العكس، إذا كانت هناك قدرة L3 وقنوات غير تفاعلية ولكن تفتقر إلى تحكم ميكانيكي في الوصول، فسيصعب تدقيق مخرجات العامل (Agent)، ولن تكون هناك ثقة. كما صححت الممارسة أيضاً التصور السابق حول نقطة الاختناق: لم تختف نقطة الاختناق المتعلقة بالتحقق، بل تم ترسيخها كتحدٍ مركب يضم «تصميم نظام التحكم في الوصول + معايرة الثقة + عرض نطاق القبول»، ولأول مرة أصبحت التكلفة قيداً أساسياً بنفس أهمية الوظيفة. تشير هذه الآليات التصحيحية مجتمعة إلى استنتاج واحد: أن ما يمكن تكراره ليس قدرة إنتاج مجانية، بل قدرة إنتاج معزولة ومحددة؛ وأن إعادة توليد الكود تتطلب أن تكون قابلة للتتبع، وإلا ستتراكم «ديون الإنقاذ»؛ وأن أنظمة التحكم في الوصول الميكانيكية القابلة للتحكيم تحل محل الحكم الذاتي، لتصبح المعيار الوحيد لقياس جودة المخرجات.

تطبيق مصنع البرمجيات هو الدليل المباشر على التغيير النموذجي. يحدد `SOFTWARE_FACTORY.md v1.0` (2026-09-20) [تم التحقق منه محلياً] بوضوح أربعة خطوط إنتاج مثل حلقة البحث ومصنع الهندسة، ويشمل أنواعاً متعددة من وكلاء العمال (Agent) (مثل Codex، dsh، Grok)، ويحدد قائمة صارمة للجدولة والتحكم في الوصول. أكملت حلقة البحث 51 مهمة، ونشرت 19 مقالاً على الموقع الرئيسي، وهناك 32 مقالاً متراكماً، وتستمر المهام الجديدة في الانضمام إلى الطابور. في VoxSign `scripts/factory/` [تم التحقق منه محلياً]، يعمل المصنع بآليات مثل جدولة cron كل 15 دقيقة، مثيل `flock` وحيد، عزل worktree، كلب حارس للإيجار (lease watchdog)، وقطع الدائرة اليومي، وقد أنتج 103 عمليات إرسال (commits) في سبتمبر 2026. هذا لم يجسد فقط دالة الإنتاج المجردة لـ FR-01 في شكل تنظيمي، بل أثبت أيضاً من خلال «التعلم مزدوج الحلقات» (حيث يتم الإشارة إلى الحوادث الحقيقية المقابلة لكل مبدأ تصميم، مثل توقف عقد الإيجار في 29-7، وتداخل المثيلات، والنجاح الزائف، وحساب ميزانية مورد واحد فقط) أن المنظمة تتساءل عن متغيرات الحوكمة نفسها، وليس فقط تسريع العمليات القديمة. كما كشف أيضاً عن قاعدة مفادها أن التنفيذ الآلي ينقل نقطة الاختناق بالكامل إلى نظام التحكم في الوصول: حيث تتجاوز القدرة التوليدية بكثير استيعاب نظام التحكم في الوصول، مما يؤدي إلى تراكم كبير.

تعتبر القناة غير التفاعلية لـ `codex exec` الواجهة الرئيسية التي ترقي العامل (Agent) من «أداة» إلى «قوة عاملة». يحدد مصنع VoxSign الهندسي Codex على أنه `codex exec --sandbox danger-full-access` (صندوق رمل بصلاحيات كاملة) [تم التحقق منه محلياً]، وقد أعد قنوات مراجعة متعددة المستويات، مثل `codex review --uncommitted`. يحتوي دليل `docs/codex-prompts/` على 6 ملفات موحدة للتعليمات (prompts)، تغطي المهام المختلفة من مراجعة مجلس الإدارة إلى بوابة النشر. يظهر سجل المستودع أن مؤلف «فريق Codex AI» ساهم بـ 5,488 عملية إرسال (commits) [تم التحقق منه عبر git]. هذه اللاتفاعلية تمكن العامل (Agent) من الاستدعاء برمجياً، وتعيين المهام عبر جدولة زمنية، والتراكم وإعادة التشغيل في الطوابير، مما يحقق قابلية جدولة العامل (Agent) وقياسه. هذه الآلية تفرض أيضاً «فصل السلطات والمسؤوليات» كقيد هندسي: فصندوق الرمل ذو الصلاحيات الكاملة يعني أن العامل (Agent) يمكن أن يسبب عواقب لا رجعة فيها، ولذلك يجب على المصنع الحد من نطاق الضرر المحتمل من خلال استخدام شجرة عمل (worktree) لمرة واحدة، وقطع الدائرة عند انتهاء المهلة، وقتل مجموعات العمليات، والمراجعة المستقلة. وقد تحول نمط فشلها من «كتابة سيئة» إلى «اكتمل التشغيل ولكن غير موثوق به»، ويجب أن ترتبط معايير النجاح بحقائق خارجية.

أما واجهة المستخدم المدعومة بالصوت VoiceSign (Dynamic UI / Generative UI L1/L2) [تم التحقق منه عبر git]، فتمد مبدأ «التركيز على النية» من طبقة الكود إلى طبقة التفاعل. قدمت عملية الإرسال (commit) `e0fe5a5f7` (2026-09-16) تصحيح Dynamic UI، حيث يقوم الخلفية (backend) بإرفاق حقل `ui_patch` برسائل VIDS بطريقة متوافقة مع الإصدارات السابقة، ويقوم العميل (client) بالعرض حسب الدليل. يثبت هذا أن واجهة المستخدم لم تعد واجهة ثابتة في وقت التجميع، بل هي تيار من التصحيحات يمكن توليدها في وقت التشغيل بناءً على النية الصوتية، مما يؤكد وجهة النظر القائلة بأن «واجهة المستخدم هي أيضاً مخرج قابل لإعادة التوليد». في الوقت نفسه، قدم هذا النظام نموذجاً للاستقلالية المحدودة للتوليد: حيث يدعم بوضوح L1/L2 فقط (اختيار المكونات المحددة مسبقاً وتعبئة الفراغات)، بدلاً من توليد شاشة كاملة أو أي HTML بشكل عشوائي، وهذا يتشابه مع «تصنيف درجات الاستقلالية» على مستوى البرمجيات، مما يشير إلى أن الصناعة قد تبنت تلقائياً استراتيجية «سلم القدرات + التراجع» على جانب واجهة المستخدم. كما تظهر انضباطيتها في التوافقية (تجاهل العملاء القدماء الحقول الجديدة بأمان، والعودة إلى النص العادي للمكونات غير المعروفة، وعدم عرقلة المسار الرئيسي عند حدوث استثناء في توليد التصحيح) خصائص الانتقال التدريجي للتحول النموذجي. ومع ذلك، لم يتضمن هذا الإرسال اختبارات فردية (unit tests) لـ `ui_patch`، وكان المنتج الأدنى القابل للتطبيق (MVP) يعتمد على قواعد حتمية، وبالتالي فهو يدعم L1/L2، ولكنه لا يكفي لدعم الادعاءات القوية لـ L3/L4 [تم التحقق منه عبر git].

يقدم هذا التقرير تصنيفاً لمستويات التصنيع من F0 إلى F5، لقياس مسار تطور إنتاج البرمجيات بناءً على حقائق قابلة للملاحظة. F0 هو خط الأساس للترميز اليدوي؛ F1 هو مساعد الذكاء الاصطناعي/الإكمال، ويتطلب موافقة بشرية لكل عنصر؛ F2 هو عامل (Agent) تفاعلي، ويتطلب تأكيداً بشرياً لكل خطوة. حالياً، تجسدت الحالة الهندسية لـ «نقطة العتبة L3» في FR-01 على شكل F3 «المهام الطويلة غير التفاعلية»، مما يعني أن العامل (Agent) يمكن أن يعمل بدون واجهة رسومية (headless)، ويحتوي على صندوق رمل ومهلة زمنية، وينتج طلبات سحب (PR) قابلة للتحقق، ويكون المنشئ (builder) ليس هو الموافق (approver)، وتبقى صلاحية الدمج النهائية للإنسان. وعلاوة على ذلك، تتطلب مرحلة F4 «التصنيع» تلبية عدة شروط: وجود نوعين على الأقل من العمال غير المتجانسين (Worker)، وجدولة المهام عبر قوائم الانتظار، ووجود بوابات تحكم ميكانيكية متعددة ومستقلة، وجدولة لا تتطلب تدخلاً بشرياً، وسجل تكلفة وقطع الدائرة، وكلب حارس (watchdog) للعقود القديمة، وأن يكون حكم النجاح مرتبطاً بالمخرجات الخارجية بدلاً من رمز الخروج، وأن يقتصر دور الإنسان على جدولة الإنتاج، والاستلام، والتواصل الخارجي. لقد وصلت كل من خط إنتاج P1 لـ OPC ومصنع VoxSign v1 إلى مرحلة F4 [تم التحقق منه محلياً]، ولكن انخفاض معدل اجتياز نظام التحكم في خط البحث (32 مقالاً متراكماً) يكشف عن قصور في المحور D (كفاية نظام التحكم في الوصول) في مرحلة F4.

F5 «المصنع التكيفي» هو الهدف النهائي، وتشمل معاييره: توليد مصادر المهام تلقائياً من «الفجوات المكتشفة عملياً»، وتوليد مهام فرعية للمراجعة تلقائياً عند فشل نظام التحكم في الوصول، وتعدد القنوات المتوازية، والتقييم المتبادل بين الذكاء الاصطناعي، وجمع مؤشرات الأداء الرئيسية (KPI) للمصنع تلقائياً لدفع إعادة التوزيع. حالياً، لم يتم تحقيق مرحلة F5 بالكامل. على الرغم من أن المصنع يحتوي بالفعل على نماذج أولية لـ «التراكمات المدرجة تلقائياً في قائمة الانتظار» و«حلقة إعادة العمل للمراجعة من قبل المنسق» (F5 ضعيف)، إلا أن تشخيص OPC-102 أشار إلى أن حلقة البحث لا تزال «مستهلكة وليست منتجة»، وأن عيب Jev الخاص بالجسد الفارغ لم يتم إصلاحه؛ كما أن ملف README لمصنع الهندسة نفسه ذكر أن «التقييم المتبادل بين الذكاء الاصطناعي لم يتحقق، والمسارات المتوازية هي موضوع للإصدار الثاني» [تم التحقق منه محلياً]. كما أن مهام هذا التقرير تم إدخالها يدوياً بواسطة البشر، بدلاً من أن يتم توليدها تلقائياً بناءً على الحالة الصحية، مما يشكل دليلاً ذاتياً داخل F4 يؤكد الوضع الحالي لعدم الوصول إلى F5. خلال عملية التحول هذه، اكتشفنا «مفارقة التصنيع» [استنتاج]: إذا كان معدل نمو قوة التحكم في الوصول G أقل من معدل نمو القدرة التوليدية I، فإنه على الرغم من زيادة إنتاجية المصنع، إلا أن استقراره ينخفض، وستلتهم التراكمات وإعادة العمل جميع المكاسب. لذلك، لا يعتمد النجاح في الانتقال من F3 إلى F4 على عدد العمال المضافين، بل على ما إذا كان نظام التحكم في الوصول يمكن أن يتوسع بالتزامن مع القدرة الإنتاجية.

قدم تقرير OPC-104 تحديثات شاملة وعميقة لـ FR-01، تجلت بشكل رئيسي في أبعاد متعددة مثل وحدة التحليل، دالة الإنتاج، النقطة الحرجة، نقطة الاختناق، نوع الأدلة، القياس، متغيرات الاستقلالية، مكان الإنسان، إدراك L4، وشكل المخرجات. ركز FR-01 على استقلالية العامل الفردي (Agent) (L0–L4)، بينما ركز OPC-104 على الشكل التنظيمي «للمصنع»، مؤكداً على الدور المنهجي لخطوط الإنتاج ومجمعات العمال وأنظمة التحكم في الوصول. توسعت دالة الإنتاج من `Q=min(I,C,V)` إلى `Q=min(I,C,V,S,$)`، متضمنةً أمن التنسيق والميزانية كقيود صارمة. كما تم تعديل النقطة الحرجة من L3 لتصبح `L3×قنوات غير تفاعلية×تحكم ميكانيكي في الوصول`، مؤكدة على قابلية الجدولة والتدقيق. وتم تضييق تعريف نقطة الاختناق من «التحقق» البسيط إلى تحدٍ مركب يضم «تصميم نظام التحكم في الوصول + معايرة الثقة + عرض نطاق القبول». ويكمن التحول الأساسي في أن نوع الأدلة في OPC-104 ترقى من تقارير الأبحاث الثانوية في FR-01 إلى بيانات أنظمة التشغيل الأولية مثل الملفات المحلية، والسكريبتات، والسجلات، وسجل git، محققاً بذلك تحولاً نوعياً من «الاستنتاج الأدبي» إلى «أدلة التشغيل».

السبب الجوهري وراء هذه التحديثات هو أن FR-01، كتقرير نموذجي يركز على «جانب القدرة»، قد تنبأ بنجاح بظهور مبادرة الآلة وتحول نقاط الاختناق، ولكن في وقت كتابته لم يكن هناك تطبيق عملي لمفاهيم مثل المصانع، والقنوات غير التفاعلية، وواجهة المستخدم الديناميكية. لذلك، افتقر FR-01 إلى فهم عميق لـ «الجانب التنظيمي وجانب التنفيذ الهندسي»: أي كيف تجعل القنوات المبادرة قابلة للجدولة، وكيف تجعل أنظمة التحكم في الوصول المبادرة موثوقة، وكيف تجعل أمن التنسيق والميزانية المبادرة مستدامة. يكمن إسهام OPC-104 في دفع النموذج من «العامل (Agent) يكتب الكود» إلى «المصنع يسلم الكود»، وفي هذه العملية قام بتوسيع معايير التقييم من محورين إلى أربعة محاور، ومن متغير واحد إلى متغيرين (درجة الاستقلالية L وقوة التحكم في الوصول G)، مما يعكس بشكل أكثر واقعية التعقيدات والتحديات التي يواجهها تطوير البرمجيات المدعوم بالذكاء الاصطناعي في الممارسة العملية. كما تقلص دور الإنسان من «الموافق الخارجي على العملية والمسؤول» إلى «صاحب صلاحية الدمج النهائي الوحيد»، وحتى في ظل وجود صندوق رمل بصلاحيات كاملة، تم الإبقاء على آلية `deny git push origin master` [تم التحقق منه محلياً].

على الرغم من التقدم الملحوظ الذي أحرزته ممارسات مصانع البرمجيات بالذكاء الاصطناعي، إلا أن الطريق إلى الأمام لا يزال مليئاً بالتحديات والقضايا العالقة. أولاً، هناك مشكلة عدم اتساق مقاييس الأرقام التشغيلية: يسجل `SOFTWARE_FACTORY.md` «51/51 دورة مكتملة، إجمالي المهام 51»، بينما يظهر `RESEARCH_OPC_STATUS.md` (2026-09-20 23:50) «إجمالي المهام 57، 51 مكتملة، 6 في قائمة الانتظار» [تم التحقق منه محلياً]. على الرغم من عدم وجود تناقض بين الاثنين، إلا أن هذا يشير إلى أن مقاييس الحالة لم توحد بعد، وهناك نقص في مصدر بيانات واحد موثوق، مما يسبب تداخلاً محتملاً في القياس واتخاذ القرارات. ثانياً، لم يتم حفظ معدلات اجتياز نظام التحكم في الوصول ودرجات الجودة بشكل منظم، ولم تتمكن درجات `dup/value/quality` لبوابات Jev الثلاث من تشكيل ملف `health.json` قابل للإحصاء، كما أشار عيب OPC-102 [تم التحقق منه محلياً]، وهذا يعيق التحليل الكمي لكفاءة وفعالية نظام التحكم في الوصول.

بالإضافة إلى ذلك، لم تتحقق آلية التقييم المتبادل بين أنظمة الذكاء الاصطناعي في مصنع الهندسة بعد، ويشير `scripts/factory/README.md` بوضوح إلى أن «التقييم المتبادل بين أنظمة الذكاء الاصطناعي لم يتحقق، يجب أولاً تشغيل حلقة الذكاء الاصطناعي الواحدة المغلقة» [تم التحقق منه محلياً]. وهذا يعني أن «الكيانات الفاعلة المتعددة» الحالية تشير بشكل أساسي إلى إمكانية اختيار عدة كيانات تنفيذية، وليس فرض متطلبات على وكلاء (Agents) متعددين لإجراء تقييم متبادل، ولا يزال هناك طريق طويل لتحقيق معايرة الثقة المثالية. على الرغم من أن Dynamic UI قد تم تطبيقها على مستويي L1/L2، إلا أنها تفتقر إلى اختبارات الوحدة (unit tests) وأن المنتج الأدنى القابل للتطبيق (MVP) يعتمد على قواعد حتمية، مما لا يكفي لدعم الادعاءات القوية لـ L3/L4 [تم التحقق منه عبر git]، ولا يزال يتعين استكشاف حدود قدرتها التوليدية والتحقق منها بشكل أكبر. أخيراً، لا تزال «مفارقة التصنيع» ومعايير F0-F5 المقترحة في هذا التقرير [استنتاج/قيم تصميم] في الوقت الحالي، ولم يتم جمعها كمؤشرات أداء رئيسية (KPI) تم اختبارها في المصنع، ولا يمكن اعتبارها استنتاجات تم التحقق منها للاستشهاد بها. تشكل هذه التحديات مجتمعة نقاط ضعف في التطور الحالي لمصانع البرمجيات بالذكاء الاصطناعي، وهي الاتجاهات التي تحتاج البحوث والممارسات الهندسية المستقبلية إلى التركيز عليها للتغلب عليها.