وكلاء Stripe Minions ينتجون 1,300 طلب دمج أسبوعيًا
ينتج وكلاء البرمجة Stripe Minions الآن أكثر من 1,300 طلب دمج أسبوعيًا، بحسب منشور هندسي لـ Stripe في 19 فبراير 2026، ارتفاعًا من 1,000 سابقًا. يراجع إنسان كل تغيير، لكنه لا يحتوي على شيفرة كتبها إنسان. وبالنسبة إلى فرق الهندسة، تُظهر الحالة وكلاء بلا إشراف يتولون التدفق المستمر من الترقيات والإصلاحات الصغيرة، بينما يحتفظ المهندسون بكلمة الحسم في كل دمج.
لماذا أرادت Stripe وكلاء يعملون دون مراقبة بشرية
كانت مشكلة Stripe هي الحجم في قاعدة شيفرة تكلف فيها الأخطاء غاليًا. فالشيفرة التي يعمل عليها وكلاؤها تدعم أكثر من 1 تريليون دولار من حجم المدفوعات السنوي، وتعمل ضمن اعتماديات مع مؤسسات مالية وأطر تنظيمية والتزامات امتثال، بحسب InfoQ.
كانت أدوات تفاعلية مثل Cursor وClaude Code متاحة لمهندسي Stripe، لكنها تعمل رفيقًا يراقب مهندس كل خطوة فيه. وأرادت Stripe نوعًا مختلفًا من الأدوات: أداة تأخذ تعليمة واحدة وتعيد طلب دمج جاهزًا دون أن يشرف أحد على التشغيل.
ما الذي بنته Stripe: وكلاء Minions
Minions وكلاء برمجة محليو الصنع لدى Stripe يعملون دون مراقبة. في أواخر 2024 أخذت Stripe نسخة من وكيل البرمجة goose التابع لـ Block وخصصته لبنية نماذجها اللغوية، ثم ركزت التطوير على احتياجات التشغيل دون مراقبة.
"أكثر جوانب Minions تفردًا هو غياب الإنسان المشرف." — Stripe، عن وكلاء البرمجة Minions
يمكن أن تبدأ المهمة من سلسلة في Slack أو تقرير خطأ أو طلب ميزة. يكتب الوكيل الشيفرة والاختبارات والتوثيق، وينتهي التشغيل بطلب دمج يراجعه مهندس قبل دمجه.
كيف يعمل Minions يومًا بيوم
يعمل كل وكيل على devbox، وهي بيئة المطور السحابية نفسها التي يستخدمها مهندسو Stripe: نسخة AWS EC2 تحمل شيفرة Stripe المصدرية. وتحتفظ Stripe بمجموعة من بيئات devbox المسخنة مسبقًا لتكون جديدة جاهزة خلال 10 ثوانٍ، مع نسخ المستودعات وبناء الذاكرات المؤقتة. ولأن كل devbox معزولة، يبقى الخطأ داخل صندوق واحد، فيعمل الوكيل بكامل الصلاحيات ويتجاوز رسائل التأكيد.
يتبع العمل مخططًا، وهو سير عمل معرّف بالشيفرة. بعض الخطوات حلقات وكيل لها مجال للقرار، مثل "تنفيذ المهمة" أو "إصلاح إخفاقات CI". وأخرى شيفرة ثابتة لا تستدعي نموذجًا أبدًا، مثل "تشغيل أدوات الفحص المهيأة" أو "دفع التغييرات". وتقول Stripe إن تثبيت الخطوات المتوقعة في الشيفرة يوفر الرموز وتكاليف CI على نطاق واسع ويعطي الوكيل مجالًا أقل للخطأ.
ولتعلّم قاعدة الشيفرة، يقرأ الوكلاء ملفات قواعد مقيدة بمجلدات وأنماط ملفات محددة، بالصيغة نفسها التي يستخدمها Cursor، فيتشارك البشر والوكلاء مجموعة إرشادات واحدة. ثم تمر التغييرات المولدة عبر خطوط CI/CD والاختبارات الآلية والتحليل الثابت قبل المراجعة البشرية.
ماذا تُظهر نتائج Stripe Minions
النتيجة المقيسة هي الحجم. ففي منشور بتاريخ 19 فبراير 2026 كتب أليستر غراي من Stripe أن أكثر من 1,300 طلب دمج أسبوعيًا في Stripe ينتجها Minions بالكامل، ارتفاعًا من 1,000 في الجزء الأول من السلسلة. يراجع إنسان كل واحد منها، ولا يحتوي أي منها على شيفرة كتبها إنسان.
وكتب مدير الهندسة كاميرون برنهارد أن الوكلاء ينتجون التغييرات بشكل متزايد من البداية إلى النهاية. ويقول مهندسو Stripe إن Minions يبرعون في المهام المحددة جيدًا مثل تغييرات الإعدادات وترقيات الاعتماديات وإعادة الهيكلة الصغيرة. ولم تنشر Stripe أرقامًا للوقت الموفر أو جهد المراجعة أو معدلات العيوب.
ماذا يغيّر وكلاء البرمجة المستقلون لفرق الهندسة
بالنسبة إلى شركة، المهمة التي يتولاها Minions هي التدفق المستمر من التغييرات الصغيرة المحددة جيدًا التي تتراكم في قاعدة شيفرة كبيرة: ترقيات وإعدادات وتنظيفات لا يريد أحد قضاء بعد ظهر كامل فيها. ونقل هذا العمل إلى الوكلاء يحرر المهندسين للتصميم والمراجعة، مع بقاء شخص مسؤول عن كل دمج.
وتُظهر حالة Stripe أيضًا أين يذهب الاستثمار. النموذج جزء واحد فقط. تأتي المكاسب من بنية بُنيت سابقًا للبشر: بيئات مطورين سريعة ومعزولة واختبارات جيدة وملفات قواعد مشتركة. وبنت فرق في Stripe مخططاتها الخاصة لعمليات ترحيل على مستوى قاعدة الشيفرة كلها لا يستطيع تغيير شيفرة بسيط مبرمج معالجتها.
أسئلة وأجوبة
كم طلب دمج ينتجه Minions في Stripe؟
أكثر من 1,300 طلب دمج أسبوعيًا ينتجها Minions بالكامل، ارتفاعًا من 1,000 سابقًا، بحسب مدونة Stripe الهندسية.
هل يراجع البشر الشيفرة التي يولدها الذكاء الاصطناعي في Stripe؟
نعم. يراجع مهندس بشري كل طلب دمج من Minions قبل دمجه، رغم أن الشيفرة نفسها لا تحتوي على سطور كتبها إنسان.
ما المهام التي يبرع فيها وكلاء البرمجة في Stripe؟
المهام المحددة جيدًا مثل تغييرات الإعدادات وترقيات الاعتماديات وإعادة الهيكلة الصغيرة، بحسب مهندسي Stripe.
رؤية MOZGII
كيف كنا سنبنيه
تُظهر حالة Stripe أن وكيل البرمجة العامل دون مراقبة هو في معظمه مشروع بنية تحتية. النموذج يكتب الشيفرة، لكن جهاز المطور المعزول ومجموعة الاختبارات وملفات القواعد المشتركة هي التي تقرر هل الشيفرة آمنة للدمج. والشركة التي تفتقر إلى هذه القطع تحصل على طلبات دمج أكثر ومخاطر أكثر في وقت واحد.
لو كنا نبني هذا، لبدأنا باختيار مهمة واحدة ضيقة وعادية، مثل ترقية الاعتماديات، وكتبنا كيف يبدو التغيير الصحيح. يجري كل تشغيل للوكيل في بيئة مؤقتة بلا وصول إلى الإنتاج أو بيانات الاعتماد الشخصية. وتكون الخطوات الثابتة، مثل الفحص والدفع، شيفرة عادية، ولا يتولى النموذج إلا الأجزاء التي تحتاج إلى حكم. ويذكر كل طلب دمج اسم المهندس الذي راجعه.
سيتعثر النهج عند المراجعة. حين ينتج الوكلاء مئات التغييرات أسبوعيًا يبدأ المراجعون بالتصفح السريع، وقد يمر تغيير صغير خاطئ في شيفرة المدفوعات لأنه يشبه الذي قبله. وتتقادم ملفات القواعد أيضًا مع تحرك قاعدة الشيفرة. والمقياس الوحيد الذي سنراقبه هو حصة طلبات دمج الوكلاء التي تُتراجع أو تُرقَّع لاحقًا، مقارنة بطلبات البشر.
بعد ذلك سنبني طابور مراجعة يرتب تغييرات الوكلاء حسب المخاطر، فتحصل تعديلات الإعدادات الصغيرة على فحص سريع، وتحصل التغييرات القريبة من حركة الأموال على مراجع ثانٍ.
المصادر
من أين جاءت حقائق هذا الخبر.