Compound Engineering لتنظيم البرمجة

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

تقوم فكرتها على أن قيمة العمل البرمجي لا تقتصر على الشيفرة التي أُضيفت. فالقرارات المهمة وأسباب استبعاد بعض الحلول والمشكلات التي استغرقت تحقيقًا قد تفيد المهمة التالية، إذا حُفظت بطريقة يستطيع المطور أو الوكيل الرجوع إليها.

من المتطلبات إلى خطة قابلة للتنفيذ

عندما تكون الفكرة غير مكتملة، تساعد مهارة ce-brainstorm على استكشاف المطلوب قبل الدخول في تفاصيل التنفيذ. الهدف هنا هو تحديد ما ينبغي بناؤه، ولمن، وما الحدود التي لا ينبغي تجاوزها. أما إذا كانت المتطلبات واضحة بالفعل، فليس من الضروري تكرار مرحلة الاستكشاف لمجرد الالتزام بتسلسل شكلي.

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

تنفيذ مأذون ومراجعة فعلية

بعد مراجعة الخطة وتحديد نطاق التفويض، يمكن الانتقال إلى ce-work لتنفيذ العمل. ويظل من المفيد توضيح ما تسمح به المهمة، خصوصًا عندما تشمل تعديل البيانات أو التعامل مع خدمات خارجية أو نشر تغييرات. بهذه الطريقة يصبح الانتقال من التفكير إلى الفعل قرارًا واضحًا، لا نتيجة ضمنية لطلب التخطيط.

تدعم الحزمة مراجعة الشيفرة عبر مهارات مثل ce-code-review، لكن تقرير المراجعة لا يساوي نجاح الاختبارات. ينبغي تشغيل أدوات البناء والاختبار المناسبة للمشروع، وفحص السلوك الناتج، ومعالجة الملاحظات المؤثرة قبل اعتماد التغيير. وعند وجود واجهة مستخدم، قد يلزم اختبار التفاعل أيضًا، لا الاكتفاء بقراءة الملفات المعدلة.

معرفة تستحق الاحتفاظ بها

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

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

مثال عملي على إضافة ميزة

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

بعد ذلك تُصاغ خطة توضح التعديلات المطلوبة في الواجهة والخادم والبيانات، والحالات التي يجب اختبارها. يراجع الفريق الخطة، ويمنح إذن التنفيذ ضمن النطاق المتفق عليه، ثم يفحص النتائج: هل تصل الدعوة إلى المشروع الصحيح؟ هل تُرفض الدعوة المنتهية؟ وهل تبقى صلاحيات العضو محدودة بالدور الممنوح له؟

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

التوافق ومتطلبات الاستخدام

تعمل Compound Engineering مع وكلاء من بينهم Claude Code وCodex وCursor، لكن طريقة التثبيت وصيغة استدعاء المهارات تختلف حسب البيئة. لذلك يجب اختيار التعليمات الخاصة بالوكيل المستخدم، والتأكد من تفعيل الإضافة قبل بدء المهمة، بدل افتراض أن أمرًا واحدًا يصلح للجميع.

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

لمن تناسب هذه الحزمة؟

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

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

التكلفة والحدود

كود الحزمة متاح مجانًا بترخيص MIT، بينما تبقى تكاليف اشتراك الوكيل واستهلاك النماذج والخدمات الخارجية منفصلة. وقد يزيد التخطيط المفصل والمراجعة من الوقت والاستهلاك، لذلك ينبغي موازنة عمق العمل مع أهمية التغيير.

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