Factory AI: هل يستحق إضافته إلى أدوات فريق التطوير؟

ما هو Factory AI؟

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

جرى التحقق من المعلومات في 21 أكتوبر 2026 بالرجوع إلى صفحة أسعار Factory ووثائقه المنشورة. هذا تقييم يستند إلى الوثائق، مع أمثلة توضيحية وحسابات للتكلفة؛ ولا يتضمن ادعاء بإجراء اختبار معياري للبرمجة أو تجربة عملية للمنتج.

لمن يناسب Factory، ومتى يكون الإبقاء على الوكيل الحالي أفضل؟

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

تضم قائمة المقارنة Claude Code من Anthropic، وهو وكيل الشركة للتطوير؛ و**Codex من OpenAI**، وهو وكيلها للبرمجة؛ و**Cursor**، وهو محرر ومنصة للوكلاء. والمقارنة المفيدة هنا هي ما الذي سيغيّره شراء كل أداة في طريقة العمل.

هذه تقديرات تساعد على الشراء، وليست ترتيباً وفق اختبارات الأداء. فكل من Claude Code وCodex وCursor يتجاوز بالفعل حدود نافذة محادثة أو طرفية واحدة. تعدد الواجهات وحده لا يمنح Factory الأفضلية.

Factory AI أم Claude Code: أيهما يناسب طريقة عملك؟

يستحق Factory النظر حين تريد أن تكون نماذج Claude أحد الخيارات ضمن مسار عمل أوسع. أما Claude Code فهو الخيار الأبسط عندما تكون مؤسستك قد بنت حوله تعليمات وتكاملات وممارسات مراجعة مفيدة. تشغيل نموذج Claude داخل Droid لا يعيد إنتاج تجربة Claude Code؛ فالأدوات المحيطة، واختيار السياق، وسلوك التنفيذ، كلها خصائص تتبع منتج الوكيل نفسه.

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

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

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

Factory AI Droid: احتفظ بمحررك وحدّد المهمة بوضوح

يستطيع Factory Droid العمل داخل محررك الحالي، ما يتيح تجربة محدودة دون الانتقال إلى محرر آخر. في VS Code وCursor وWindsurf، يزوّد التكامل الوكيل بالملف النشط، والنص المحدد، والملفات المفتوحة، ورسائل التشخيص، أي الأخطاء والتحذيرات التي يعرضها المحرر. كما يدعم عرض فروق الشفرة مباشرة داخل المحرر. شغّل droid في الطرفية المدمجة، ثم استخدم /ide لفحص الاتصال. تشرح وثائق Factory الخاصة ببيئات التطوير خطوات الإعداد.

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

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

كيف يتعامل Factory AI مع مواصفات المهمة؟

يفصل Spec Mode في Factory مرحلة الاستقصاء والتخطيط عن التنفيذ. يقرأ السياق ذي الصلة ويقترح خطة ثم يطلب الموافقة عليها؛ وفي CLI يتيح Shift+Tab التبديل بين Normal وSpec. أما مستوى الاستقلالية فهو إعداد منفصل يحدد الإجراءات التي يمكن تنفيذها دون طلب تأكيد آخر. توضّح وثائق هذا الوضع هذا الفرق صراحةً.

في مثال تغيير آلية الصلاحيات، ابدأ بـSpec Mode واشترط أن تحدد الخطة الملفات المتأثرة، وافتراضات التوافق، وخطوات التحقق. ارفض أي خطة تقترح تغيير قواعد الوصول دون توضيح كيفية الحفاظ على السلوك الحالي. ولا توافق على التنفيذ قبل اتضاح هذه القرارات.

يمكن اتباع التسلسل العملي التالي:

1. اطلب من Droid تحديد نقاط الدخول الخاصة بالتحقق من الصلاحيات والاختبارات ذات الصلة.
2. اطلب خطة تحافظ على السلوك الحالي وتكشف أي متطلبات غير محسومة.
3. راجع الخطة، ثم اختر مستوى استقلالية يلائم العمل المسموح به.
4. افحص فروق الشفرة وأدلة الاختبار قبل فتح طلب السحب أو قبوله.

الفائدة هنا هي وجود نقطة مراجعة قبل أن يُنتج الوكيل كمية كبيرة من الشفرة. لكن الخطة التي تبدو مقنعة قد تظل خاطئة. يجب أن تشمل معايير القبول سلوك النظام، لا مجرد وجود اختبارات.

وهناك قيد يتعلق بالمحرر نفسه: تذكر Factory أن تكامل JetBrains لا يشارك تلقائياً الملفات المفتوحة، أو النصوص المحددة، أو رسائل التشخيص، ولا يوفّر عرض فروق Droid الأصلي داخل المحرر. على الفريق الذي يستخدم محررات متعددة أن يراعي هذا الفرق، وألا يفترض أن تجربة VS Code تنطبق على الجميع.

حرية اختيار النموذج دون إعادة بناء مسار العمل

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

تتضمن قائمة نماذج Factory المنشورة، من بين نماذج أخرى:

• Claude Opus 5.5 وClaude Sonnet 5.5 من Anthropic.
• GPT-6.1 Sol وGPT-6 Astra من OpenAI.
• Gemini 3.1 Pro من Google وGrok 4.7 من xAI.
• نماذج مفتوحة، منها Mistral Large 4 وKimi K3 وDeepSeek V4.1 Flash.

هذه أمثلة على النماذج المدعومة، وليست ترتيباً لجودتها أو وعداً بأن سياسة كل حساب تسمح باستخدامها جميعاً.

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

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

يعني استخدام مفتاحك الخاص (BYOK) إعداد بيانات اعتمادك لدى مزوّد النموذج أو نقطة اتصال متوافقة. تدعم Factory نماذج شخصية مخصصة، بما فيها إعدادات محلية، لكن وثائق BYOK تضع حداً مهماً لإمكان نقل التجربة بين الواجهات: تتوافر هذه النماذج الشخصية في CLI وتطبيق سطح المكتب، ولا تتوافر في واجهات الويب أو الجوال المستضافة.

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

مراجعة العمل المفوّض عبر سطح المكتب والويب

يفيد تطبيق Factory لسطح المكتب عندما يحتاج الناتج إلى فحص بصري إلى جانب المحادثة. تعرض صفحة المنتج إمكان معاينة فروق الشفرة، والمستندات، والعروض التقديمية، وجداول البيانات، وملفات PDF، والمواقع العاملة، مع إرفاق التعليقات بأسطر الشفرة أو العناصر المحددة. ويتوافر التطبيق لنظامي macOS وWindows. كما تصف صفحة Factory Desktop استمرارية الجلسات بين سطح المكتب والويب والجوال وCLI.

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

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

تدرج Factory أيضاً موصلات لأدوات مثل GitHub وLinear وSlack وSentry. يمكنها تزويد الوكيل بسياق مصرح باستخدامه، لكن ربط أداة لتتبّع المهام لا يجعل التذكرة الغامضة واضحة. تظل المهمة بحاجة إلى مسؤول ونطاق ونتيجة محددة.

ويضيف التنفيذ البعيد فرقاً آخر: الواجهة التي تراجع العمل عبرها ليست الجهاز الذي ينفّذه. فـDroid Computers التي تديرها Factory بيئات دائمة تحتفظ بالملفات والحزم المثبتة والخدمات والإعدادات بين الجلسات. وتوثّق Factory خياراً منفصلاً باسم Remote Control لجهاز تديره أنت بالفعل. تشرح وثائق Droid Computers كلا الخيارين.

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

أتمتة تطوير البرمجيات بالذكاء الاصطناعي تبدأ بمهمة قابلة للتكرار

تزداد فائدة Factory عندما يعالج Droid قائمة مهام محددة دون أن يضطر مطور إلى بدء كل محادثة يدوياً. Droid Exec هو وضع التنفيذ دون واجهة تفاعلية: أمر غير تفاعلي يشغّل مهمة ويعيد ناتجاً يمكن لسكربت أو نظام تكامل مستمر (CI) استخدامه. ويعمل افتراضياً بصلاحية القراءة فقط؛ أما التعديلات والأوامر الأوسع فتتطلب إعدادات استقلالية صريحة. تتناول وثائق Exec صيغ المخرجات، ومجلدات العمل، وأشجار عمل Git المعزولة.

بداية جيدة هي تحليل مستودع ينتج أدلة يستطيع المسؤول عن صيانته التحقق منها. بعد تثبيت Droid وتسجيل الدخول، شغّل الأمر التالي من داخل مستودع:

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

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

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

هناك عائق دقيق في الأتمتة يسهل إغفاله: قرار سياسة الأوامر الفعلي ask يظل يتطلب موافقة حتى عند مستوى الاستقلالية High، والمهمة التي تعمل باستدعاء واحد لا تستطيع جمع موافقة تفاعلية. لذلك لا تؤدي زيادة الاستقلالية بالضرورة إلى تشغيل الأتمتة المتوقفة. وتوثّق Factory الأمر droid rules check لمعاينة قرارات السياسة قبل التنفيذ. هذه مشكلة إعداد يجب حلها بعناية، وليست مبرراً لتعطيل جميع فحوص الصلاحيات.

وللمهام الأكبر، ينسّق Mission Mode عمل الوكلاء المنفّذين وعمليات التحقق. ويتطلب مستوى الاستقلالية High أو خيار التجاوز غير الآمن الموثّق، كما قد تتوقف Missions على الخطط الفردية مؤقتاً عند بلوغ حدود المعدل. ابدأ بمهام عادية محددة النطاق قبل أن تعد بإتمام انتقال كبير دون متابعة بشرية.

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

أسعار Factory AI: اختر الخطة التي تخدم مسار عملك

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

فيما يلي الشروط الشهرية الواردة في صفحة أسعار Factory المنشورة، كما جرى التحقق منها في 21 أكتوبر 2026:

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

تكلف خمسة مقاعد في Teams $260 شهرياً، وفق الحساب: $60 + 5 × $40. وتكلف عشرة مقاعد $460. وإذا افترضنا أن فريقاً من خمسة مقاعد قَبِل 20 طلب سحب من Droid خلال شهر، فستبلغ حصة الاشتراك من التكلفة $13 لكل طلب سحب مقبول. هذا حساب رياضي، وليس توقعاً للطاقة الإنتاجية؛ ولا بد من إضافة الاستخدام الإضافي، والحوسبة، ووقت المراجع قبل مقارنة التكلفة الإجمالية.

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

قيود قد تعطل اعتماد Factory داخل الفريق

أكثر قيود Factory تأثيراً تتعلق بتفاوت الإمكانات بين الواجهات والخطط. وقد توقف اعتماد المنتج حتى لو بدت جلسة برمجة فردية ناجحة.

دعم المحرر لا يعني تكافؤ المزايا. يفتقر JetBrains إلى المشاركة التلقائية للملفات والنصوص المحددة ورسائل التشخيص المتاحة في المحررات المبنية على VS Code. كما أن Agent Panel في Zed لا يستعيد جلسات Factory Droid السابقة. لذلك يظل الفريق الذي يوحّد عمله على Droids بحاجة إلى تهيئة خاصة بكل محرر، وخطة لاستعادة السياق. توثّق Factory هذه الاختلافات.

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

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

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

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

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

مراجعة Factory AI: متى يستحق الاعتماد؟

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

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

ابدأ أسبوع العمل بتقييم صغير يقوده شخص مسؤول عن النتيجة:

Factory مرشح جدير بهذا التقييم. تدعم وثائقه وجود منظومة واسعة وقابلة للضبط من الوكلاء، لكنها لا تثبت أن مهندسيك سيُنجزون عملاً أفضل لمجرد استبدال الوكيل الذي يعرفونه بـDroid.

أسئلة شائعة

احصل على AI Business Workflow Audit Checklist عبر النشرة البريدية، لتحديد المهمة والصلاحيات والمسؤول عن المراجعة وتكلفة التشغيل قبل التوسع في استخدام الوكلاء.