كيف يُنجز فريق من 5 أفراد بسرعة 10×: الهندسة بالذكاء الاصطناعي في eSimphony

يبني eSimphony فريق هندسة من خمسة أشخاص. والمنتج يغطي أكثر من 150 دولة، ويطلق تطبيقات أصلية على iOS وAndroid، ويشغّل منظومة تكامل مع المشغلين عبر مناطق متعددة، ويدعم خمس لغات من طرف إلى طرف، ويطلق تحديثات للمنتج أسبوعياً. نحن لسنا شركة اتصالات بألف موظف. نحن فريق صغير يعمل برافعة مقصودة.

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

شكل الفريق

خمسة مهندسين. ومصمم منتج واحد. ورئيس تنفيذي ما زال يكتب بعض مواصفات المنتج بنفسه. لا مدير منتج رسمي — فالمواصفات تأتي من الرئيس التنفيذي مع مسوّدات بمساعدة Moza وحُكم هندسي. ولا فريق اختبار جودة مخصص — فالاختبار جزء من حلقة البناء. ولا فريق DevOps منفصل — فالبنية التحتية يملكها من يطلق الميزة.

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

سير العمل ذو المراحل الخمس

كل تغيير في eSimphony — من تصحيح نص إلى تكامل جديد مع مشغل — يمر بالمراحل الخمس نفسها. وكل مرحلة مدعومة بالذكاء الاصطناعي؛ وفي كل مرحلة إنسان داخل الحلقة.

1. الاستكشاف (بلا حواجز تقنية)

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

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

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

2. المواصفات (ساعات لا أسابيع)

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

نهجنا: يكتب المهندس (أو الرئيس التنفيذي، حسب الميزة) فكرة منتج في سطر واحد. ويوسّعها الذكاء الاصطناعي إلى وثيقة متطلبات منظمة — تدفق المستخدم، والحالات الحدية، ومقاييس النجاح، ومعايير القبول، والأسئلة المفتوحة. ثم يصقلها الفريق في جلسة عمل مدتها 45 دقيقة. وتصل المواصفة إلى الهندسة في اليوم نفسه.

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

3. التصميم (حلقة تغذية راجعة سريعة)

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

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

4. البناء (الذكاء الاصطناعي يكتب الكود؛ والبشر يراجعون كل تغيير)

هذا هو أكثر الأجزاء ظهوراً في نهجنا. عملية الهندسة في eSimphony اليوم:

• يولّد الذكاء الاصطناعي نحو 90% من الكود الجديد (Cursor وClaude وGitHub Copilot، غالباً مجتمعة)
• يكتب المهندسون القرارات المعمارية، وحدود التكامل، ومنطق الأعمال الشائك الذي يتطلب معرفة عميقة بالنظام
• 100% من الكود يراجعه إنسان قبل الدمج. كل تغيير. كل طلب سحب. بلا استثناءات.

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

طلب السحب النموذجي في eSimphony يتضمن:

• من 200 إلى 800 سطر كود متغير (مقابل نحو 100 إلى 200 تقليدياً في فرق حقبة 2024)
• مهندس واحد يراجع بالتفصيل
• غالباً اختبارات وحدة يولّدها الذكاء الاصطناعي بتغطية تتجاوز 80% على الكود الجديد
• ملاحظات المراجع تركز على المعمارية لا على الصياغة

5. الإطلاق (التكيّف في دقائق)

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

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

الأرقام

مقاييس تقريبية من الاثني عشر شهراً الماضية:

• دورة العمل: أسبوع واحد. الميزات الجديدة تُطلق أسبوعياً؛ والإصلاحات الصغيرة تُطلق يومياً.
• 5 مهندسين يعملون بدوام كامل على المنتج. ومهندس إضافي متعاقد بدوام جزئي.
• أكثر من 90% من الكود الجديد يولّده الذكاء الاصطناعي (Cursor وClaude أساساً).
• 100% من الكود المدموج خضع لمراجعة بشرية.
• الوسيط الزمني من مواصفة الميزة إلى الإنتاج: 5 إلى 10 أيام.
• حوادث الإنتاج لكل ربع سنة: 1 إلى 2. أقل من متوسط الصناعة لنطاقنا.
• تذاكر دعم العملاء المصعَّدة إلى الهندسة: نحو 5 أسبوعياً. ومعظمها يُحل في اليوم نفسه.

هذه الأرقام ليست نظرية. إنها وتيرة التشغيل الفعلية لفريقنا.

ما ليس هذا عليه

من المفيد التصريح بما لا يعنيه التطوير المبني على الذكاء الاصطناعي في eSimphony.

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

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

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

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

ما الذي يتطلبه

ثلاثة أمور، مرتبة حسب الأهمية.

1. مراجعة بشرية صارمة

كل سطر كود يولّده الذكاء الاصطناعي يمر بمراجعة مهندس خبير قبل الدمج. وإغراء تخطي المراجعة للتغييرات الصغيرة «الصحيحة بداهةً» حقيقي وخطر. وقد تمسكنا بخط المراجعة 100%.

2. حواجز معمارية محكمة

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

3. قبول ثقافي للذكاء الاصطناعي كخيار افتراضي

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

ما لا نستخدم الذكاء الاصطناعي فيه

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

والنمط واضح: الذكاء الاصطناعي يعزز التنفيذ؛ والبشر يملكون القرارات.

لماذا يهم هذا للمنتج

مخرجات سير العمل هذا ظاهرة في المنتج. فقد أطلقنا:

• معمارية شريحة eSIM مدى الحياة (مشروع يمتد أرباعاً عدة في معظم الشركات)
• Moza، رفيقة السفر الذكية، بخمس لغات
• الباقات الديناميكية بالذكاء الاصطناعي في ثلاث مناطق
• حل المشكلات بالذكاء الاصطناعي مع الإصلاح الذاتي
• تطبيقات أصلية على iOS وAndroid بإصدارات أسبوعية
• واجهة خلفية متعددة المناطق بجاهزية تتجاوز 99.9%
• توطين بخمس لغات عبر سطح المنتج كاملاً

هذه القائمة تتطلب عادةً من 30 إلى 50 مهندساً وأكثر من ثلاث سنوات. ونحن أطلقناها بخمسة مهندسين في 18 شهراً.

ملاحظة عن التوظيف

ننمّي الفريق بعناية. والمهندسون الذين ينجحون هنا يشتركون في ثلاث صفات:

1. حُكم عالٍ قبل إنتاج عالٍ. فالذكاء الاصطناعي يتولى الكتابة؛ ونحن نريد مهندسين يبرعون في المراجعة واتخاذ القرار وتشكيل الحلول.
2. مرتاحون للذكاء الاصطناعي كزميل. مهندسون يتعاملون معه كزميل عمل (يفوّضون إليه، ويراجعونه، ويعترضون عليه) لا كعرّاف سحري ولا كتهديد لهويتهم.
3. يهتمون بالمستخدم. فسير العمل المبني على الذكاء الاصطناعي سريع بما يكفي لإنتاج كثير من الكود الذي يعمل لكنه لا يهم. والمهندسون القادرون على ربط كل طلب سحب بسؤال «هل يساعد هذا المستخدم؟» ينتجون أفضل عمل.

إن كان هذا وصفك، فنحن نوظّف. تواصل معنا عبر صفحة الوظائف أو راسل ترونغ مباشرة.

ماذا سنطلق بعد ذلك

سير العمل نفسه الذي بنى المنتج الحالي هو الذي يطلق خارطة الطريق:

• إدارة شرائح eSIM متعددة (مايو 2026)
• الباقات العائلية (يونيو 2026)
• الولاء والمكافآت (أغسطس 2026)
• تغطية مباشرة مع المشغلين حول العالم (2027)

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

تلك هي الرافعة. وذلك هو الرهان. وهكذا يُنجز فريق صغير في مواجهة جمود صناعة بأكملها.

شاهد eSimphony على أرض الواقع، أو اقرأ عن موقعنا في السوق، أو اطّلع على عرضنا التقديمي من MVNO Nation Americas.