تبنّي نموذج مصنع البرمجيات: الزحف، المشي، الجري

نهج «مصنع البرمجيات» (Software Factory)

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

الزحف

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

فكّر في هذه الأتمتات على أنها: مُشغّل ← نشاط الوكيل.

على سبيل المثال:

• إعادة إنتاج المشكلات وفرزها: جعل وكيل يفحص جميع المشكلات الجديدة المُبلَّغ عنها، ويعيد إنتاجها، ويصنفها.
• مراجعة الكود: مراجعة طلبات السحب (PRs) تلقائياً بمجرد فتحها وترك تعليقات عليها.
• المراقبة: وجود وكيل يستجيب لتنبيهات Sentry ويقوم بتصحيح الأخطاء وإصلاح المشكلات.
• إصلاح CI ذاتياً: إصلاح عمليات التكامل المستمر المعطلة من خلال تحديد طلبات السحب المراد تراجعها وحل تعارضات الدمج.
• تحديث الوثائق تلقائياً: تحديث وثائق المستخدم وإنشاء سجلات التغييرات.
• التحقق: استخدام وكلاء browser-use و computer-use لإجراء فحص بصري للتحقق من صحة التغييرات.
• إصلاح الأخطاء البسيطة: قيام الوكلاء بتحديد وإصلاح مشكلات بسيطة أبلغ عنها المستخدمون.

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

مثال على أتمتة مراقبة التنبيهات

قد يتم بناء هذه الأتمتات باستخدام بنية تحتية داخلية (مثل وضع Claude Code SDK في حاوية Docker وربط خادم لتشغيله)، أو قد تستخدم منصة عامة لأتمتة وكلاء السحابة مصممة لتشغيل الوكلاء بناءً على مشغلات محددة. كما قد تستخدم منصة كاملة مخصصة لمرحلة واحدة من الدورة (مثل مراجع كود آلي مخصص أو SRE مدعوم بالذكاء الاصطناعي).

البدء بمجموعة من الحلول النقطية للأتمتة أمر مقبول، لكن معظم الفرق تصطدم بحدود هذا النهج عاجلاً أم آجلاً.

وتحديداً:

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

المشي

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

وبشكل أكثر تحديداً، يسألون:

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

معظم قادة الهندسة وفرق المنصات الذين يتأملون هذه الأسئلة بعمق يصلون إلى شيء يشبه نهج مصنع البرمجيات السحابي. فهم يريدون:

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

بمجرد أن تقرر الشركة اعتماد نهج المصنع، يصبح السؤال: كيف تصل إلى هناك من أتمتاتك النقطية الحالية؟ عادة ما يختصر الأمر في ما إذا كنت ستقوم بـ (1) بناء المزيد من البنية التحتية حول تلك الأتمتات أو (2) الانتقال إلى منصة مثل Warp Factories، والتي توفر بنية تحتية للمصانع.

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

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

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

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

الهدف هو نظام متعدد الوكلاء ينتقل من الفرز ← المواصفات ← التنفيذ ← المراجعة ← التحقق ← المراقبة. وبشكل أكثر تفصيلاً:

1. تدخل مشكلة جديدة إلى النظام، سواء عبر إنسان أو وكيل مراقبة.
2. يعمل وكيل الفرز ويحاول فهم المشكلة وإعادة إنتاجها. إذا حدد أن المهمة قابلة للأتمتة → يمررها إلى وكيل التنفيذ. إذا احتاجت لمواصفات بسبب نطاقها → يجعل وكيل المواصفات يتكرر مع إنسان للوصول إلى مواصفة. إذا كانت غامضة → يحصل على مدخلات بشرية ويعيد التشغيل، أو يقرر ببساطة تأجيل المشكلة مؤقتاً.
3. [إذا لزم الأمر] يعمل وكيل المواصفات، يراجع الإنسان المواصفات، ثم يمررها إلى وكيل التنفيذ.
4. يكتب وكيل التنفيذ الكود.
5. يراجع وكيل مراجعة الكود الكود.
6. يقوم وكيل التحقق بـ استخدام الحاسوب أو أنواع أخرى من التحقق.
7. يراجع الإنسان الكود ومخرجات التحقق. إذا لزم الأمر، يعود إلى الخطوة 2، 3، 4 أو 5.
8. CI / CD.
9. إطلاق المنتج.
10. يعمل وكيل المراقبة وينشئ مشكلات إذا لزم الأمر، مما يكمل الحلقة.

داخلياً في Warp، يؤتمت مصنعنا في مرحلة المشي حوالي 75% من التغييرات على warp.dev، وهو موقع التسويق الخاص بنا. على عكس Warp Terminal (65 ألف نجمة على GitHub، تقريباً مليون مطور نشط، مليون سطر من Rust الأصلي)، فإن موقع التسويق الخاص بنا تطبيق بسيط نسبياً. لاحظ أنه عندما أقول "أتمتة"، أعني الانتقال من مدخل بشري إلى ميزة مُطلقة بالكامل عبر المصنع، مع نقاط لمس بشرية ضئيلة بخلاف وصف التغيير الذي نريده، سواء في Slack أو في متتبع المهام الخاص بنا.

الجري

فقط عندما تكون لديك الحلقة الأساسية قائمة في مشروع بسيط، يجب عليك التوسع نحو مشاريع أكثر تعقيداً. يتطلب توسيع نطاق المصانع بنية تحتية أكثر متانة.

وتحديداً، مع التوسع تظهر بعض الاختناقات:

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

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

لتعمل المصانع بسلاسة حقيقية، يتطلب ذلك استثماراً كبيراً. في Warp، نفكر في هذا على أنه بناء كامل لطبقات المصنع الخاصة بك:

أتناول كل واحدة من هذه الطبقات بالتفصيل في هذا المنشور:

https://x.com/zachlloydtweets/status/2097739116720910619

بعض النقاط الرئيسية التي تستحق الذكر وقد لا تكون واضحة:

• المصانع ككود: أحد الخيارات الرئيسية التي يمكنك اتخاذها هو تعريف مصانعك ككود. هذا يتيح اختبار تكوينات مختلفة للمصانع لمعرفة أيها الأكثر كفاءة، وجودة، إلخ.
• متعدد النماذج وأطر العمل: يجب أن تضمن أن مصانعك قادرة على استخدام أحدث النماذج، سواء كانت حدودية أو مفتوحة الوزن، واستخدام أطر عمل مختلفة لوكلاء البرمجة مثل Claude Code و Codex.
• ملكية البيانات: يجب أن تضمن تخزين وامتلاك جميع البيانات الخارجة من مصنعك - فهذا هو المادة الخام لتحسين عملياته.

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

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

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

Warp Factories حالياً في وصول مبكر. تحصل الشركات المؤهلة على 10 آلاف دولار من استخدام المصنع.