أغلب الشركات اللي بتبيع أدوات تسليم البرمجيات بتبني منتجها بالطريقة التقليدية، وبعدين بتطلب منك تثق في الأداة. إحنا بنعمل العكس. منتج Dutopilot نفسه بيبنيه Dutopilot. مستودعه متوصل بالخدمة المستضافة تمامًا زي مستودع أي عميل. التذاكر موجودة على لوحة مشروع، والوكلاء بيخططوها ويبنوها ويراجعوها ويختبروها ويصلحوها ويدمجوها. وكل دمج في الفرع main بيتنشر على الإنتاج.
منتج Dutopilot نفسه، من 29 سبتمبر
أول مشاريع عملائنا، على الإصدار الحالي من 19 أغسطس
المقال ده بيشرح إزاي ده بيتم عمليًا: الإعداد، واللي بيحصل لتذكرة واحدة، وإزاي عشرات التغييرات من الناس والوكلاء بتوصل لنفس فرع main كل يوم من غير ما تستنى بعضها، واللي بيحصل لما حاجة تتعطل، والدور اللي لسه بيقوم بيه الناس عندنا. وكمان بيعرض اللي قسناه، واللي اتعلمناه وتقدر تستفيد منه في فريقك.
كلمة عن Dutopilot نفسه علشان باقي المقال يبقى واضح. Dutopilot خدمة مُدارة وبرمجيات كخدمة في نفس الوقت. هو طبقة فوق وكلاء البرمجة: بيشغّل Claude Code وCodex وOpenCode وOh My Pi على حساب الذكاء الاصطناعي الخاص بيك، على بنية سحابية مخصصة، وكل عميل بياخد Forward Deployed Engineer (مهندس مخصص يعمل مع فريقك) بيجهّزه حوالين قائمة مهامك وبيفضل معاك. كل وكيل هو عضو فريق افتراضي في Dutopilot، وكل واحد منهم يقدر يشغّل مئات الوكلاء الفرعيين المتوازيين، في كل الخطط. وانت بتحتفظ بلوحة المشروع اللي بتستخدمها أصلًا. والوكلاء بيعملوا شغل التسليم.
ليه بنبني المنتج بالمنتج نفسه
فيه ثلاثة أسباب، وأولهم مش تسويقي.
السبب الأول هو الأمانة. أداة التسليم اللي عمرها ما شالت شغل صانعها ماتختبرتش على أصعب عميل موجود: عميل بيغيّر رأيه كل يوم، وبيفتح تذاكر مبهمة، وبيدمج على عجل، وبياخد باله من كل دقيقة تأخير. لما منتجنا يستنى مراجعة متعطلة، بنحس بيها في نفس اليوم. والضغط ده اختبار أفضل من أي مجموعة اختبارات ممكن نكتبها عن قصد.
السبب الثاني سرعة الملاحظات. لما وكيل يتعطل، أو يلف في حلقة، أو يطلّع تغيير مكناش هنقبله، الشخص اللي يقدر يصلّح Dutopilot هو نفسه اللي لسه حاسس بالمشكلة. مفيش طابور دعم بين المشكلة والإصلاح. وأي عيب بنلاقيه بيبقى تذكرة على اللوحة فورًا، والإصلاح بيمشي في نفس خط الإنتاج.
السبب الثالث دليل تقدر تفحصه بنفسك. لما بنقول إن خط الإنتاج بيصمد قدام تغييرات كتير في نفس الوقت، إحنا بنوصف مستودعنا، اللي الناس والوكلاء بيدمجوا فيه في نفس فرع main طول اليوم. ومش بنوصف مشروع تجريبي معمول علشان يبان كويس.
ده كله مش معناه إن كل عميل يتوقع إعدادنا بالتحديد. العملاء بيختاروا موافقاتهم ولوحتهم ومستودعاتهم. اللي بينتقل هو المنهج: تذكرة بتدخل، وتغيير متحقق منه ومدموج بيطلع، وشخص بيتدخل بس عند البوابات المهمة بالنسبة لك.
شوفه على قائمة مهامك
احجز مكالمة وهيشرح لك Forward Deployed Engineer شكل الإعداد ده على مشروع من مشاريعك. أو ابدأ مجانًا بخطة Solo.
الإعداد: لوحة، ومستودع، وتقسيم واضح للشغل
الإعداد بسيط عن قصد، لأن العميل لازم يقدر ينسخه.
لوحة المشروع
كل الشغل بيبدأ كتذكرة على لوحة مشروع. اللوحة هي المكان اللي الناس بيقولوا فيه هم عايزين إيه: إمكانية جديدة، أو إصلاح، أو تعديل في الصياغة. التذكرة بتتكتب بلغة عادية، زي ما بتشرح لزميل. ومش لازم تكون مواصفات فنية. ولو ناقصها حاجة مهمة، خطوة التخطيط بتسأل عنها.
المستودع
كود المنتج موجود في مستودع واحد، وخدمة Dutopilot المستضافة بتقراه وبتعدّله من خلال منح صلاحية، بنفس الطريقة اللي بتتعامل بيها مع أي عميل. مستودعنا مالوش أي باب خلفي خاص. لو خطوة نجحت معانا، فهي بتنجح من خلال نفس المسار اللي مستودعك هيستخدمه.
كل تغيير قطعة شغل صغيرة ومستقلة بتروح مباشرة للفرع main. مش بنحتفظ بفروع تكامل طويلة العمر، ولا بتغيير إصدار مجمّع كبير في الآخر. القطع الأصغر معناها مراجعات أصغر، وتراجع أسهل، ومفيش تراكم تعطّل فيه قطعة واحدة متأخرة عشر قطع مكتملة.
دور الناس ودور الوكلاء
التقسيم سهل في الشرح. الناس بيقرروا إيه اللي يستاهل يتعمل، وفين لازم إنسان يوافق. والوكلاء بيعملوا شغل التسليم اللي بينهم.
- الناس: بيكتبوا التذاكر ويرتبوا أولوياتها على اللوحة، ويردوا على الأسئلة اللي الوكيل ماقدرش يحسمها لوحده، ويوافقوا على الخطوات اللي اختاروا يخلوها خلف بوابة بشرية، وياخدوا قرارات المنتج.
- الوكلاء: بيوضحوا التذكرة، ويخططوها، ويقسموها لو كبيرة، ويكتبوا الكود والاختبارات، ويراجعوا شغل بعض، ويشغّلوا فحوصات الجودة، ويصلحوا الأعطال، ويدمجوا وينشروا التغييرات.
وراء ده حسابات الذكاء الاصطناعي الخاصة بيك. Dutopilot بيشغّل Claude Code وCodex وOpenCode وOh My Pi على اشتراكك أو مفتاحك، فتكلفة شغل الذكاء الاصطناعي بتروح لحساب انت متحكم فيه، وبتشوف بدقة بتروح فين. والوكلاء في خطتك مش بيتشاركوا قناة ضيقة واحدة. كل وكيل في الخطة بيشتغل كعضو فريق افتراضي في Dutopilot، يقدر يوزّع أجزاء من المهمة على أي عدد يحتاجه الشغل من الوكلاء الفرعيين المتوازيين.
حياة التذكرة، خطوة بخطوة
ده اللي بيحصل لتذكرة واحدة، من اللحظة اللي بتبقى فيها جاهزة لحد ما توصل للإنتاج. التذكرة بتعدّي على تسع مراحل في المجمل: المعماري، والمخطِّط، والمنفِّذ، والبوابة، وثلاثة مراجعين، ووكيل الإصلاح التلقائي، وQA. هنوصف المسار بنفس الترتيب اللي هتشوفه بيه. الخطوات السبع المرقّمة تحت بتجمّع المراحل التسع دي، والبطاقات الثماني في الصورة بتعرض نفس الرحلة.
1. التوضيح والتخطيط
لما التذكرة تتعلّم إنها جاهزة، وكيل بيقراها مع أجزاء المستودع اللي بتلمسها. أول مهمة ليه مش كتابة الكود. أول مهمة إنه يتأكد إن التذكرة ممكن تتبني: هل الهدف واضح؟ هل فيه تناقض؟ هل ناقص قرار مفيش غير شخص يقدر ياخده؟
لو التذكرة واضحة، وكيل معماري ووكيل مخطِّط بيحولوها لخطة: إيه اللي هيتغير، وبأي ترتيب، وإيه اللي ممكن يغلط، وإزاي نعرف إنه نجح. التذكرة الكبيرة بتتقسم لتذاكر أصغر، كل واحدة ممكن تتبني وتتراجع وتتسلّم لوحدها. والتقسيم ده مهم: التذاكر الصغيرة بتخلص أسرع وتكلفة مراجعتها أقل، والمشكلة في واحدة منها مش بتعطّل الباقي.
لو ناقص حاجة مفيش غير شخص يقدر يقررها، الوكيل بيسأل بكلام بسيط على التذكرة. والرد بكلام الشخص نفسه كفاية. محدش محتاج يتعلم عبارات معينة.
2. البناء في بيئة sandbox معزولة
البناء بيتم على بنية سحابية مخصصة، داخل بيئة sandbox معمولة للتذكرة دي بس. البيئة بتاخد نسخة جديدة من المستودع، وبتنجز الشغل، وبعدها بتتمسح. ومفيش أي حاجة من تشغيل تذكرة تقدر تتسرب لتذكرة تانية.
داخل الـ sandbox، وكيل برمجة (Claude Code أو Codex أو OpenCode أو Oh My Pi، على حسابك) بيكتب التغيير والاختبارات الخاصة بيه. ولأن الشغل متقسم على وكلاء فرعيين، واحد ممكن يتولى جانب البيانات، وتاني الشاشة، وتالت يكتب الاختبارات، وكلهم في نفس الـ sandbox. وقبل ما يكتب أي حاجة، الـ sandbox بيدمج أحدث نسخة من الفرع main في نسخة الشغل. وهنرجع لسبب أهمية اللحظة دي في القسم الخاص بالشغل على نطاق واسع.
3. المراجعة المستقلة
لما البناء يخلص، التغيير بيتفتح كطلب دمج (pull request)، وده الأسلوب المعتاد لاقتراح تغيير للمراجعة. المراجعين وكلاء منفصلين ماكتبوش الكود. بيقروا التغيير بعين جديدة، وبيقارنوه بالتذكرة والخطة، وبيدوّروا على الأخطاء والحالات المنسية والاختصارات الخطرة والتغييرات اللي بتخرج عن حدود التذكرة.
الهدف من فصل المراجع عن الكاتب هو نفس الهدف مع الناس. الكاتب بيقرا اللي كان قاصد يكتبه. والمراجع بيقرا اللي مكتوب فعلًا.
4. بوابات الجودة
جنب المراجعة، بتشتغل مجموعة من بوابات الجودة. البوابة فحص تلقائي نتيجته واضحة: نجاح أو فشل. زي الاختبارات، وفحوصات الأنواع والأسلوب، وفحص إن التغيير بيلمس اللي الخطة قالت إنه هيلمسه، وفحوصات لحاجات زي الأمان وشكل الصفحات.
5. دورة الإصلاح الذاتي
لما مراجع يلاقي مشكلة أو بوابة تفشل، التذكرة مش بترجع لشخص. بتروح لمرحلة إصلاح. وكيل الإصلاح بيقرا الفشل بدقة، وبيغيّر الكود، وبيرجّع التغيير للمراجعة والبوابات. والدورة دي بتتكرر طول ما فيه تقدم. ولو نفس الفشل فضل يرجع من غير تقدم، الأسلوب بيتغيّر بدل ما يتكرر نفس الحل، ولو لسه ماتحلّش، التذكرة بتقف مع شرح واضح يقدر شخص يتصرف على أساسه.
6. الدمج
لما كل البوابات تبقى خضراء والمراجعة نظيفة، التغيير بيندمج في main. الدمج بيتم بأسلوب squash-and-merge، فكل تذكرة بتبقى سطر واحد واضح في السجل، وده بيسهّل قراءته والتراجع عنه. ولو اخترت تحتفظ بموافقة بشرية قبل الدمج، التذكرة بتستنى الموافقة دي وبتوضح للشخص بدقة هو بيوافق على إيه.
7. النشر
في منتجنا، الدمج في main معناه إصدار: النشر بيبدأ لوحده وبيحط التغيير على الإنتاج. والتذكرة مش بتتقفل غير لما التغيير يكون شغال فعلًا ومتفحوص، مش لما طلب الدمج يندمج. ولو فحص النشر فشل، بيتعامل زي أي فشل تاني: بيرجع كشغل للوكلاء، مش كرسالة مستنية حد ياخد باله منها. أما في مشاريع العملاء، فالشغل بيقف عند staging أو بيئة الاختبار، وشخص بيعمل الإصدار، والتذكرة بتخلص هناك.
مثال عملي (توضيحي)
مثال توضيحي. دي تذكرة افتراضية لتوضيح المسار، ومش سجل لتغيير فعلي بعينه.
التذكرة: «اعرض تاريخ الفاتورة الجاية في صفحة الحساب، علشان العملاء ميسألوش الدعم تاني عن موعد الخصم الجاي.»
التخطيط. الوكيل بيقرا التذكرة وكود صفحة الحساب. بيلاحظ إن التذكرة مش محددة اللي يتعرض لعملاء الخطة المجانية، فبيسأل سؤال واحد على التذكرة. حد من فريق المنتج بيرد بجملة واحدة: متعرضش حاجة. المعماري بيكتب خطة قصيرة: يضيف التاريخ لبيانات الحساب، ويعرضه في الصفحة، ويخفيه للخطط المجانية، ويضيف اختبارات للحالتين. والتغيير صغير كفاية إنه يتسلّم كتذكرة واحدة.
البناء. بيئة sandbox بتبدأ بنسخة جديدة من المستودع وبتدمج فيها أحدث نسخة من main. وكيل برمجة بيضيف الحقل، ووكيل فرعي تاني بيحدّث الصفحة، وتالت بيكتب الاختبارات. وبعدها بيفتح طلب دمج.
المراجعة والبوابات. وكيل المراجعة بينبّه إن التاريخ معروض بصيغة واحدة ثابتة، مع إن المنتج بيشتغل بخمس لغات. وبوابة كمان بتبلّغ عن اختبار ناقص لعميل خطته بتتجدد في آخر يوم في الشهر. والملاحظتين بيروحوا لمرحلة الإصلاح.
الإصلاح. وكيل الإصلاح بيستخدم تنسيق التاريخ اللي بيراعي اللغة والموجود أصلًا في المنتج، وبيضيف الاختبار الناقص. التغيير بيعدّي على المراجعة والبوابات تاني، وكل النتائج بتطلع خضراء.
الدمج والنشر. التغيير بيندمج في main، والإصدار بيطلع، وفحص الصفحة الحية بينجح. والتذكرة بتتقفل. محدش فتح محرر كود، والمدخل البشري الوحيد كان جملة واحدة على التذكرة.
عايز الدورة دي على لوحة مشروعك؟
Forward Deployed Engineer بيجهّز اللوحة والمستودع والموافقات اللي عايزها، وبيفضل معاك طول ما الوكلاء بيتولوا شغل التسليم. احجز مكالمة، أو ابدأ مجانًا بخطة Solo.
الشغل على نطاق واسع: تذاكر كثيرة، وأشخاص كثيرون، وفرع main واحد
تذكرة واحدة ماشية في خط نظيف دي الحالة السهلة. الاختبار الحقيقي هو تذاكر كتير في نفس الوقت، والناس كمان بيدمجوا في نفس المستودع.
في مستودعنا، تذاكر كتير شغالة في نفس الوقت، كل واحدة في sandbox خاص بيها، وفريقنا بيدمج تغييراته في main طول اليوم. وكل دمج من دول بيغيّر شكل main. والنظام اللي بيشتغل بس لما تغيير واحد يتحرك في المرة هيقضي أغلب وقته في الانتظار. وكل عضو فريق افتراضي في Dutopilot يقدر يشغّل مئات الوكلاء الفرعيين المتوازيين، في كل الخطط.
ليه مفيش حاجة بتستنى فرع يتحدّث
فيه قاعدة شائعة في فرق البرمجيات بتقول إن الفرع لازم يكون محدّث بأحدث نسخة من main قبل ما يندمج. مع عدد قليل من الأشخاص، ده إزعاج بسيط. لكن مع عشرات التغييرات اللي بتوصل طول اليوم بيتحول لفخ: في اللحظة اللي أي تغيير بيندمج فيها، كل التغييرات المفتوحة التانية بتبقى قديمة من جديد، ومحتاجة تتحدّث وتتفحص تاني. وتحت الضغط الكبير الدورة دي مش بتخلص أبدًا، والناس بيقضوا يومهم في الضغط على أزرار التحديث.
إحنا رافضين القاعدة دي عن قصد. بدلها، كل وكيل بيدمج أحدث نسخة من main في شغله في اللحظة اللي بيحتاجها فيها: قبل ما يكتب الكود، ومرة تانية قبل الفحوصات النهائية مباشرة. الوكيل بيتأكد بنفسه إن شغله متوافق مع main الحالي، بدل ما يستنى حد يحدّث فرعه.
لو main اتحرك أثناء الشغل والتغييرين مش بيلمسوا بعض، مفيش حاجة تانية مطلوبة. ولو حصل تعارض، الوكيل بيحله في نسخته، وبيشغّل الفحوصات تاني، وبيكمل. التكلفة بيدفعها التغيير الوحيد اللي حصل فيه التعارض فعلًا، ووقت حدوثه بس. وكل الباقي بيفضل شغال.
نفس الفكرة بتنطبق على أي مورد مشترك
بنطبق نفس الاختبار على كل حاجة بتتشارك فيها تغييرات متعددة: مجموعة بيئات الـ sandbox، وعدد الطلبات المسموح لنا نبعتها لمضيف الكود، وحسابات الذكاء الاصطناعي، وطابور الشغل. والأسئلة دائمًا هي نفسها. هل ده لسه بيشتغل مع عشرات الكتّاب في نفس الوقت؟ هل كل انتظار بينتهي لوحده؟ هل تكلفة كل دورة بتزيد مع حجم الشغل النشط، مش مع حجم قائمة المهام كلها؟
التصميم اللي صح لتذكرة واحدة في المرة، لكنه بيتعطل أو بيحتاج شخص لما تذاكر كتير توصل، هو بالنسبة لنا تصميم غلط، مهما كان شكله آمن. ده أول اختبار لازم كل قرار في منتجنا يعدّي عليه، وهو السبب إن الإعداد بيصمد لما عميل يوصّل مستودع مزدحم.
عدد التذاكر اللي حساب ذكاء اصطناعي واحد يقدر يشيلها موجود تحت في «أرقام اليوم».
لما يحصل خطأ
الأخطاء بتحصل في أي خط تسليم. اختبار كان أصلًا مش مستقر بيفشل، أو خدمة بتبقى مش متاحة لفترة قصيرة، أو وكيل بيفهم تذكرة غلط، أو تغيير بيتعارض مع تغيير تاني. المهم هو اللي بيحصل بعدها، وهل لازم شخص ياخد باله الأول.
الإصلاح الذاتي أولًا
أغلب الأعطال بتتعامل معاها دورة الإصلاح اللي شرحناها فوق. وكيل بيقرا الفحص الفاشل ويفهمه ويصلحه، وبعدين الفحص بيتعاد. في أول مشاريع عملائنا، الوكلاء أصلحوا 150 حالة فشل في المراحل بنفسهم (الأرقام في قسم الأرقام). وكل حالة منهم كانت لحظة، في الإعداد التقليدي، هيحتاج فيها شخص ياخد باله من بناء أحمر، ويعرف المشكلة مسؤولية مين، ويتابع لحد ما تتصلح.
العيوب اللي Dutopilot بيلاقيها في نفسه بتتحول لتذاكر
Dutopilot بيراقب سلوكه. لما يكتشف عيب في نفسه، زي تذكرة مستنية من غير سبب، أو خطوة بتفشل بنفس الطريقة كل مرة، بيبلّغ عن المشكلة كتذكرة على لوحة مشروعه، عليها وسم يوضح إنها جاية من النظام. وبعدها نفس الوكلاء بيخططوا التذكرة دي ويبنوها ويراجعوها ويدمجوها زي أي تذكرة تانية. والدورة اللي في الرسم أول الصفحة حقيقية: سلوك الإنتاج بيرجع للوحة، ومنها للتغيير اللي بعده.
وده كمان السبب إننا بنثق في الإعداد في مستودعنا. المشكلة مش بتعيش في ذاكرة حد ولا في محادثة. دي تذكرة، ليها مسؤول وخطة وحالة.
بعض الأمثلة الحقيقية لعيوب Dutopilot بلّغ عنها في نفسه وبعدين صلّحها. سجّل بنفسه بلاغ إن حلقة المجدول وقفت، وصلّحها. ولوحة المتابعة قالت مرة لعميل يصلّح إعداده مع إن العطل كان من Dutopilot نفسه، فصحّح ده علشان المسؤولية تتنسب للطرف الصح.
توقفات يقدر شخص يحلها لوحده
أحيانًا التصرف الصح إننا نوقف ونسأل. قرار ناقص، أو اختيار ليه عواقب، أو بوابة انت اخترتها ومحتاجة إنسان. لما Dutopilot يوقف، بنلزم نفسنا بمعيار بنسميه الخدمة الذاتية: الشخص اللي بيقرا الإشعار لازم يقدر يحل التوقف لوحده، من غير أي توثيق ومن غير مساعدة مننا.
- الرسالة بتوضح بكلام بسيط إيه اللي حصل، قبل أي تفاصيل تقنية.
- بتوضح المشكلة مسؤولية مين: تغييرهم، ولا الإعداد.
- بتعرض الإجراء الوحيد اللي يقدروا يعملوه. ولو فيه اختيار افتراضي معقول، بتعتمده وبتبلّغهم، مع طريقة سهلة للتراجع.
- الرد بكلام الشخص نفسه كفاية. مفيش أمر خاص، ولا تعديل يدوي لأي حاجة.
التفاصيل التقنية (اسم الفحص، والإعداد المعني) بتيجي في الآخر، للمسؤول. والإشعار اللي لازم يتختصر بيستغنى عن التفاصيل التقنية الأول، وعمره ما بيستغنى عن الشرح البسيط.
الدور اللي لسه بيقوم بيه الناس
أي أتمتة بتدّعي إن الناس مش ضروريين مش مقنعة، ومش هي اللي بنيناها. الناس لسه بيعملوا الحاجات الثلاثة اللي محدش غيرهم يقدر يعملها.
- اختيار الشغل. إيه اللي يتحط على اللوحة، وبأي ترتيب، وإيه اللي مش مستاهل أصلًا. الأولوية قرار تجاري. الوكيل يقدر يقدّر المجهود، لكنه مايعرفش سوقك محتاج إيه في الربع ده.
- الموافقة في المواضع اللي اخترتها. انت اللي بتحدد الخطوات اللي تفضل خلف بوابة بشرية: خطة، أو تصميم، أو دمج، أو إصدار. البوابة اللي بتختارها بوابة حقيقية. الوكلاء بيستنوها وبيوضحوا للموافق بدقة هو بيوافق على إيه. أما الخطوات اللي ماختارتهاش فـ Dutopilot بيقررها لما يكون واثق، مع سجل واضح وطريقة سهلة للتراجع.
- اتخاذ قرارات المنتج. هل الميزة تتعمل أصلًا، وتجربتها تكون إزاي، وأنهي مفاضلة نقبلها. الوكلاء بيحولوا القرارات دي لبرمجيات شغالة، لكنهم مش بيحلّوا محل التقدير اللي وراها.
النتيجة يوم شغل مختلف. الناس بيقضوا وقتهم في القرارات والأولويات. بيقروا شروحات قصيرة بدل diffs طويلة. ومش محتاجين يراقبوا عمليات البناء خطوة بخطوة.
الأرقام
الأرقام مش بتفيد غير لو كانت محددة بتحسب إيه بالتحديد. بنقدم مجموعتين منفصلتين ومش بنخلط بينهم.
عبر أول مشاريع عملائنا
الأرقام دي جاية من أول مشاريع عملائنا. ماتقاستش على مستودع Dutopilot نفسه، ومش بنقدمها على الأساس ده. أرقام مستودعنا بتتقاس لوحدها وبتظهر في مربع خاص بيها تحت.
من يونيو 2026
من يونيو 2026، الوكلاء دمجوا 127 تذكرة وأنجزوا 539 مهمة وكيل عبر مشاريع عملائنا. المشاريع دي هي serpent.cloud، وموقع شركة خدمات، ومستودع واحد (monorepo) بيجمع Salesforce وتطبيق iOS أصلي. وآخر مشروعين مش مذكورين بالاسم هنا. كل مشروع ليه إعداده وموافقاته، وفي مشاريع العملاء الشغل بيقف عند staging أو بيئة الاختبار، وشخص بيقرر إمتى يتم الإصدار. اقرا الأرقام دي كمؤشر على الاتساع، مش على سرعة مشروع واحد.
على الإصدار الحالي، من 19 أغسطس
مجموعة تانية أضيق اتقاست على نفس مشاريع العملاء بالإصدار الحالي، من 19 أغسطس وبعده:
- 0.4% من الـ commits على فروع الشغل كتبها إنسان. والباقي كتبه الوكلاء.
- 2% من التذاكر احتاجت موافقة بشرية.
- 54 دقيقة كان الوسيط الزمني من أول commit لحد الدمج.
- 150 حالة فشل في المراحل أصلحها الوكلاء بنفسهم.
- 9 مراحل بتكوّن مسار التذكرة.
النسبة المنخفضة للتذاكر اللي احتاجت موافقة راجعة لطريقة ضبط المشاريع دي لموافقاتها. ده إعداد، مش حد أقصى. لو عايز شخص يوافق على كل دمج تقدر تعمل كده، والأرقام وقتها هتبان مختلفة، وده باختيارك.
أرقام اليوم
- حساب Claude Ultra واحد بيسلّم حوالي 50 تذكرة متوسطة الحجم في الأسبوع (حوالي 25 ملف لكل تذكرة)، أي حوالي 200 في الشهر، لما يشتغل عليه عدد كافي من أعضاء الفريق الافتراضيين في Dutopilot.
- 8 من أعضاء الفريق الافتراضيين في Dutopilot يقدروا يخلّصوا حوالي 50 تذكرة في يوم واحد، وده بيستهلك تقريبًا حصة الذكاء الاصطناعي الأسبوعية لحساب واحد.
- من 29 سبتمبر، وكلاء Dutopilot دمجوا 497 تغيير في منتج Dutopilot نفسه من تلقاء نفسهم، وقفلوا أكثر من 375 تذكرة.
- في خطة Solo، فريق Dutopilot الأصغر (لحد 3 أعضاء فريق افتراضيين) بيشغّل حساب واحد على حوالي 100 تذكرة في الشهر. وفي خطة Team بيوصل لحوالي 200 في الشهر لكل حساب Claude Ultra بتوصّله.
بنحسّن Dutopilot كل يوم، علشان كده دي أرقام اليوم (نوفمبر 2026)، مش متوسط لشهور فاتت. أرقام السعة دي خاصة بالمنتج، ومش قياسات من مشاريع العملاء.
الدروس المستفادة لفريقك
دي الدروس اللي طلعنا بيها من البناء بالطريقة دي، وتنفع أي فريق عايز يعتمد على الوكلاء في شغل التسليم.
اكتب التذاكر لزميل كفء
جودة المخرجات بتتبع جودة التذكرة. التذكرة اللي بتحدد الهدف، ولمين، وإزاي هتعرف إنها نجحت، بتتبني كويس. أما التذكرة اللي مكتوب فيها «حسّن لوحة التحكم» فبتاخد سؤال توضيحي الأول. ودي نتيجة كويسة، وأقل تكلفة من بناء غلط.
خلّي كل تغيير صغير
التذاكر الصغيرة بتعدّي المراجعة أسرع، وبتفشل أقل، وسهل التراجع عنها. ولما الشغل يكون كبير، خطوة التخطيط بتقسمه. ماتقاومش التقسيم ده. التغيير الكبير مخاطرة كنت هتشيلها لأيام.
خلّي وكلاء منفصلين يراجعوا
الوكيل اللي بيكتب الكود مينفعش يكون هو اللي بيوافق عليه. المراجعة المستقلة بتكتشف الأخطاء اللي الكاتب مش شايفها، والملاحظات بتروح لدورة الإصلاح مباشرة بدل ما تتراكم على مكتب شخص.
خلّي الفحوصات كود عادي
أي حاجة ليها إجابة صحيحة واضحة، زي هل الاختبار نجح أو هل الملف اتغير، لازم يقررها برنامج عادي، مش رأي نموذج. استخدم النماذج في مهام التقدير: قراءة تغيير، وتحديد هل هو مطابق للتذكرة.
صمّم لشغل كثير في نفس الوقت من أول يوم
خط الإنتاج اللي سريع مع تذكرة واحدة ومتعطل مع عشرة مش سريع. جرّب كل قاعدة على حالة الزحمة: مفيش انتظار لفرع علشان يبقى محدّث، ولا مورد مشترك مش بيتحرر أبدًا، ولا انتظار محتاج شخص علشان ينتهي.
اختر بوابات الموافقة البشرية عن قصد
حدد الخطوات اللي محتاجة شخص، وخلّي البوابات دي حقيقية. وكل حاجة تانية لازم تتحرك لوحدها مع سجل واضح. البوابة المختارة اللي سهل تجاوزها بتعلّم الناس يتجاهلوا البوابات.
اعتبر كل توقف رسالة لعميل
كل مرة النظام بيقف فيها، اكتب الإشعار كأن شخص عمره ما سمع عن الأداة هو اللي هيقراه. لو مقدرش يتصرف لوحده، يبقى الإشعار لسه ماكملش.
ده معناه إيه لفريقك
مش لازم تشغّل إعداد زي إعدادنا علشان تستفيد منه. النسخة العملية منه هي النسخة المُدارة.
بتحتفظ بلوحة المشروع ومستودعاتك. Dutopilot بيتوصل بيهم (Jira أو Linear أو Notion أو GitHub Issues أو Azure DevOps لقائمة المهام؛ وGitHub أو GitLab أو Bitbucket أو Azure DevOps للكود؛ وSlack للإشعارات)، وحساب الذكاء الاصطناعي الخاص بيك هو اللي بيدفع تكلفة شغل الذكاء الاصطناعي، فالتكلفة بتفضل في إيدك. الوكلاء بيشتغلوا على بنية سحابية مخصصة إحنا اللي بنديرها، وكل تذكرة ليها sandbox خاص بيها. وكل عضو فريق افتراضي في Dutopilot في خطتك يقدر ينسّق مئات الوكلاء الفرعيين المتوازيين، في كل الخطط. وعدد التذاكر الشغالة بيتبع عدد أعضاء الفريق الافتراضيين في Dutopilot في خطتك (Solo لحد 3، وTeam لحد 15، وEnterprise من غير حد) وموافقاتك. الخطط بتتسعّر على أساس أعضاء الفريق الافتراضيين في Dutopilot، مش على أساس المستخدمين: فريقك كله يقدر يستخدم Dutopilot.
Forward Deployed Engineer
كل عميل بياخد Forward Deployed Engineer، وده مهندس من فريقنا بيشتغل معاك، مش مكتب دعم بتستنى في طابوره. بيوصّل لوحتك ومستودعاتك، وبيقرا الكود وأعراف الشغل عندك، وبيجهّز الفحوصات والموافقات اللي عايزها، وبيظبط الوكلاء على طريقة شغلك. وكمان بيفضل معاك بعد الإطلاق: بيتابع أول تذاكرك ماشية إزاي، وبيعدّل لما الوكلاء يتعثروا، وبيساعدك تقرر إمتى تخفف بوابة أو تشددها.
عمليًا، ده معناه إنك بتاخد أعضاء فريق افتراضيين في Dutopilot ومهندس عارف إزاي يخليهم يشتغلوا في الكود الخاص بيك، بدل أداة لازم تتعلمها لوحدك. وأحسن خطوة أولى تكون صغيرة: مشروع واحد، وعدد قليل من التذاكر، والموافقات اللي انت مرتاح ليها.
ابدأ بمشروع واحد
احجز مكالمة تشوف فيها شكل الإعداد على مستودعك، أو ابدأ مجانًا بخطة Solo.
الأسئلة الشائعة
هل Dutopilot فعلًا بيبني Dutopilot؟
نعم. مستودع المنتج نفسه متوصل بخدمة Dutopilot المستضافة زي أي عميل. الوكلاء بيخططوا التذاكر اللي على لوحة المشروع وبيبنوها ويراجعوها ويختبروها ويصلحوها ويدمجوها، وكل دمج في main بيتنشر على الإنتاج.
هل للناس دور أصلًا؟
نعم. الناس بيختاروا الشغل، وبيوافقوا على الخطوات اللي قرروا يخلوها خلف بوابة بشرية، وبياخدوا قرارات المنتج. والوكلاء بيعملوا شغل التسليم اللي بين النقط دي.
إيه اللي بيحصل لما وكيل يغلط؟
مراجع أو بوابة جودة بيكتشفه، ووكيل إصلاح بيصلحه ويرجّعه على الفحوصات تاني. ولو ماتحلّش، التذكرة بتقف مع شرح واضح يقدر أي شخص يتصرف على أساسه لوحده.
أقدر أشغّل نفس الإعداد على قائمة مهامي؟
نعم. بتحتفظ بلوحة المشروع ومستودعاتك، وDutopilot بيشغّل Claude Code وCodex وOpenCode وOh My Pi على حساب الذكاء الاصطناعي الخاص بيك. وForward Deployed Engineer بيجهّزه حوالين قائمة مهامك والموافقات اللي عايزها.
إزاي عدد كبير من التذاكر والأشخاص بيدمجوا في فرع main واحد؟
كل وكيل بيدمج أحدث نسخة من main في شغله في اللحظة اللي بيحتاجها فيها، بدل ما يستنى فرعه يتحدّث. بالشكل ده مفيش تغيير بيستنى تغيير تاني، والمستودع المزدحم بيفضل شغال.