الإجماليات، على مشاريع العملاء الثلاثة: 127 تذكرة اتدمجت و539 مهمة للوكلاء اتنفّذت من يونيو 2026.
الإصدار الحالي، متقاس لوحده من 19 أغسطس: 0.4% commits بشرية على الفروع، و2% من التذاكر احتاجت موافقة بشرية، على نفس مشاريع العملاء.
السرعة: وسيط 54 دقيقة من أول commit لحد الدمج، على نفس الإصدار الحالي ونفس مشاريع العملاء.
التحدي
Dutopilot بيسلّم مشاريع العملاء بنفس مسار التسليم (pipeline) اللي بيبيعه. كل رقم في الصفحة دي اتقاس على ثلاث مشاريع عملاء: موقع شركة خدمات Salesforce، وموقع serpent.cloud، وmonorepo فيه كود Salesforce وكود iOS أصلي (native). ولا واحد فيهم اتقاس على المستودع الخاص بـ Dutopilot نفسه. والهدف كان إن أعضاء الفريق الافتراضيين في Dutopilot يتولوا شغل التسليم الروتيني، وفريق العميل يتفرغ للقرارات.
قبل المسار ده، الشغل الروتيني في كل تذكرة كان على الناس: حد بيكتب الخطة، ويبني التغيير، ويقرأ طلب الدمج (pull request)، ويتابع الفحوصات اللي بتفشل، وفي الآخر يضغط زر الدمج. الشغل ده ضروري، ومعظمه متكرر.
قبل وبعد
| الخطوة | قبل | دلوقتي |
|---|---|---|
| الخطة | شخص بيكتبها. | وكيل بيقترحها. وشخص بيوافق عليها لما يكون التغيير جديد أو فيه مخاطرة. |
| البناء | شخص. | وكيل، على فرع خاص بيه. |
| الفحوصات | شخص بيستناها وبيتابع حالات الفشل. | حكم واحد مجمّع. والفشل بيروح مباشرة لوكيل إصلاح. |
| المراجعة | شخص واحد من فريقك، لما يكون عنده وقت. | أعضاء فريق افتراضيين منفصلين في Dutopilot كمراجعين، على كل طلب دمج. |
| الدمج | شخص بيضغط الزر. | طلب الدمج بيتدمج تلقائيًا لما كل الفحوصات تنجح، تحت حماية الفروع (branch protection). |
| الإطلاق على production (في مشاريع العملاء دي) | شخص بيقرر. | لسه شخص هو اللي بيقرر. |
بيشتغل إزاي
كل تذكرة من لوحة المشروع بتعدّي على تسع مراحل: architect وplanner وimplementer وgate وثلاث reviewers وautofixer وQA. وحوالين المراحل دي، الناس بتحدد نقاط الموافقة البشرية مرة واحدة لكل مشروع، والمسار بيستلم التذكرة قبل أول مرحلة، وشخص بيتولى الإطلاق على production بعد آخر مرحلة. الخطوات الثلاث دي مش مراحل. والتذكرة بتوضّح هي وصلت لفين.
- Architect: بيقترح خطة على مستوى الملفات، وتدفقات البيانات، وخطة اختبار قبل ما يتكتب أي كود. وشخص بيوافق عليها لما يكون التغيير جديد أو فيه مخاطرة.
- Planner: بيحوّل التصميم المعماري اللي اتوافق عليه لقائمة مهام مرتّبة للـ implementer.
- Implementer: بيكتب التغيير على فرع خاص بيه.
- Gate: بيشغّل الفحوصات الآلية على طلب الدمج وبيطلّع حكم واحد.
- المراجع الأول: وكيل منفصل بيقرأ التغيير لوحده.
- المراجع الثاني: وكيل منفصل آخر بيقرأ التغيير باستقلالية.
- المراجع الثالث: وكيل منفصل ثالث بيقرأ التغيير باستقلالية.
- Autofixer: بيصلّح اللي لقاه فحص أو مراجع، وبعدها الـ gate بيشتغل مرة تانية.
- QA: التغيير بيتدمج في staging أو test، والـ QA بيختبر النتيجة.
في مشاريع العملاء دي، الشغل المدموج بيوصل لبيئة staging أو test، وشخص بيتولى الإطلاق على production. وDutopilot كمان بيبني منتجه بنفس الطريقة.
تذكرة واحدة، من لوحة المشروع لحد الدمج
دي تذكرة توضيحية من مشاريع المواقع، علشان نوضّح الناتج من كل مرحلة: "إضافة فلتر للقطاع في صفحة دراسات الحالة".
| الخطوة | إيه اللي بيحصل |
|---|---|
| التذكرة | شخص من فريق المنتج بيكتبها بالنتيجة المطلوبة وشكل الإنجاز، وبيعلّمها إنها جاهزة. |
| Architect وplanner | الـ architect بينشر الملفات اللي هيغيّرها والاختبارات اللي هيضيفها، والـ planner بيسرد المهام. وشخص بيوافق، لأن التغيير بيعدّل سلوك الصفحة. |
| Implementer | الـ implementer بيبني التغيير على فرع خاص بيه وبيفتح طلب دمج. |
| البوابة | بيشتغل Lint والبناء والاختبارات. واختبار واحد بيفشل. |
| Autofixer | الـ autofixer بيستلم سجل الفشل، وبيصلّح الكود، والبوابة بتعدّي في التشغيل اللي بعده. |
| Reviewers | المراجعين بيسيبوا تعليقات. والـ autofixer بيرد عليها، والفحوصات بتشتغل مرة تانية. |
| QA | طلب الدمج بيتدمج في staging أو test، والـ QA بيختبر النتيجة. |
| الإطلاق (شخص) | في مشاريع العملاء دي، شخص بيتولى الإطلاق على production. |
في الإصدار الحالي، الوسيط من أول commit لحد الدمج 54 دقيقة.
لما حاجة تفشل
الفشل متوقع، فالمسار عامل حسابه. أي فحص بيفشل أو ملاحظة مراجعة بترجع لوكيل الإصلاح ومعاها السجل أو التعليق بالضبط. والاختبار اللي بيفشل عشوائيًا بيتعاد وبيتصلّح، علشان ما يعطّلش الشغل السليم. من 19 أغسطس، المسار صلّح 150 فشل في المراحل لوحده. ولما الإصلاح يبطّل يقرّب من الحل، أو المخاطرة تزيد، التشغيل بيقف والتذكرة بتطلب تدخّل شخص.
النتائج
| المقياس | النتيجة | الفترة والنطاق |
|---|---|---|
| التذاكر اللي اتدمجت | 127 | من يونيو 2026، على المشاريع الثلاثة |
| مهام الوكلاء اللي اتنفّذت | 539 | من يونيو 2026، على المشاريع الثلاثة |
| الـ commits البشرية على الفروع | 0.4% | الإصدار الحالي، من 19 أغسطس |
| التذاكر اللي احتاجت موافقة بشرية | 2% | الإصدار الحالي، من 19 أغسطس |
| الوسيط من أول commit لحد الدمج | 54 دقيقة | الإصدار الحالي، من 19 أغسطس |
| حالات فشل في المراحل صلّحها المسار | 150 | الإصدار الحالي، من 19 أغسطس |
كل الصفوف جاية من مشاريع العملاء الثلاثة. أول صفين إجماليات للفترة كلها. وباقي الصفوف متقاسة على الإصدار الحالي بس، فالمجموعتين مش مقصود إنهم يتقارنوا ببعض.
اللي لسه بيعمله الناس
- تحديد معمارية أي حاجة جديدة أو فيها مخاطرة قبل كتابة الكود.
- توافق على التغييرات في الأجزاء اللي الغلطة فيها مكلّفة.
- الإطلاق على production، في مشاريع العملاء دي.
- الرد لما تذكرة تقف وتطلب قرار.
الموافقات اختيارك أنت. شرح إزاي تختار الخطوات اللي محتاجة موافقة بيوضّح إزاي الفرق بتضبطها.
عمليًا، ده معناه شخص من فريق المنتج بيكتب التذاكر وبيرتبها، ومهندس بيوافق على الخطط والتغييرات الحساسة، ومسؤول تسليم بيقرر الإصدارات. وباقي الوقت مش محتاج حد يتابع، والتذكرة بتوضّح إمتى محتاجين شخص.
كل عميل بيحصل على Forward Deployed Engineer
Forward Deployed Engineer (مهندس مخصص يعمل مع فريقك) من Dutopilot بيكون معاكم من أول يوم. مش بيكتب كود منتجك، هو بيضبط المسار على طريقة شغلكم الحالية.
- البداية (onboarding): بيربط أدواتك معاك وبيختار أول جزء من قائمة المهام.
- جاهزية التذاكر: بيتفق مع مسؤول المنتج (product owner) عندك على قالب قصير للتذكرة، علشان الوكلاء ياخدوا شغل واضح.
- الموافقات والبوابات: بيحدد أنهي خطط وأنهي أجزاء من الكود محتاجة شخص، بما يناسب طريقة المراجعة في فريقك.
- التحسين المستمر: بيراجع معاك التذاكر المتعطلة والنتائج، وبيعدّل البوابات كل ما الثقة تزيد.
ده معناه إيه لفريقك
حساب Claude Ultra واحد بيسلّم حوالي 50 تذكرة متوسطة الحجم في الأسبوع (بمتوسط حوالي 25 ملف متغيّر لكل تذكرة)، يعني حوالي 200 في الشهر، لما يشتغل عليه عدد كافي من أعضاء الفريق الافتراضيين في Dutopilot. في باقة Solo، فريق Dutopilot الأصغر (لحد 3 أعضاء فريق افتراضيين) بيخلّي الحساب الواحد عند حوالي 100 تذكرة في الشهر؛ وفي باقة Team بتحصل على حوالي 200 تذكرة في الشهر لكل حساب Claude Ultra بتربطه. 8 من أعضاء الفريق الافتراضيين في Dutopilot يقدروا يخلّصوا حوالي 50 تذكرة في يوم واحد، وده بيستهلك تقريبًا حصة الذكاء الاصطناعي الأسبوعية لحساب واحد. كل وكيل في الباقة هو عضو فريق افتراضي. وكل عضو فريق افتراضي يقدر يشغّل مئات الوكلاء الفرعيين بالتوازي، في كل الباقات، وباقة Enterprise من غير أي حد لعدد الوكلاء اللي بتشغّلهم. الباقات بتتسعّر حسب أعضاء الفريق الافتراضيين في Dutopilot، مش حسب المستخدمين: فريقك كله يقدر يستخدم Dutopilot. Dutopilot بيشتغل مع Jira وLinear وNotion وGitHub Issues وAzure DevOps لقائمة المهام، ومع GitHub وGitLab وBitbucket وAzure DevOps للكود، ومع Slack، ومع Claude Code وCodex وOpenCode وOh My Pi للذكاء الاصطناعي. علشان تشوفه على جزء من قائمة مهامك، احجز مكالمة.