FDE: الحدود الجديدة في أدوار الهندسة المدعومة بالذكاء الاصطناعي

في الشهر الماضي، تقابلت مع أربعة أصدقاء يخططون للتحول — مطور واجهات أمامية، مهندس معماري للحلول، منتج، ومهندس خوارزميات تقليدي — بخلفيات وأعمار ومدن مختلفة، لكنهم جميعًا سألوا عن نفس الاختصار الإنجليزي: هل FDE [2] يستحق أن أذهب إليه؟

FDE، وهي اختصار لـ Forward Deployed Engineer [2]. كانت قبل عامين مصطلحًا داخليًا في دائرة Palantir، لكنها اليوم أصبحت بشكل هادئ مقدمة شائعة لدى وكلاء التوظيف، ووظيفة متكررة في إعلانات التوظيف، وأحد المرشحين لـ "أكثر الوظائف قيمة في عصر الذكاء الاصطناعي" على وسائل التواصل الاجتماعي. أنشأت OpenAI في مايو 2026 شركة تسمى Deployment Company [3] باستخدام هذا الاسم مباشرة، باستثمار أولي قدره 4 مليارات دولار، وأعلنت صراحةً عن نية إرسال مهندسين إلى مواقع عمل العملاء ودمجهم في سير عملهم؛ كما تقوم فرقة Applied AI في Anthropic بالتوظيف في أربع مناطق زمنية في آنٍ واحد للفَرَص المخصصة لـ FDE. وقد تحولت هذه الظاهرة من مصطلح داخلي إلى مصطلح واضح في أقل من عام ونصف.

في مقالتي السابقة، "إلى الأفراد الفائقين" [4]، ناقشت "محرك الإنسان" — الفضول، التعلم الذاتي، الدافع الذاتي، والقدرة على التطبيق — وكيفية إثارتها داخل حلقة مغلقة كاملة. لكن الإنسان ليس معلقًا؛ بل يحتاج إلى أن يُستقبل بواسطة نظام إحداثيات وظيفي ملموس. إذا كان الأفراد الفائقون هم "المادة الخام" لعلاقات الإنتاج في عصر الذكاء الاصطناعي، فإن FDE هي أكثر شكل وظيفي وضوحًا نما في السوق خلال هذا العام.

في رأيي، FDE لا تقع في خانة الاستشارة ولا في خانة التأجير الخارجي. إنها أقرب إلى الفرد الفائق، والفرق الوحيد هو أن FDE هي فرد فائق منظم في الفراغ بين "نموذج الشركة × العميل".

هل تعلم من أين جاء مصطلح "Forward Deployed"؟ كان في الأصل مصطلحًا عسكريًا أمريكيًا: "Forward Deployed Forces"، ويشير إلى القوات المُنشرة في الخارج أو على الجبهة، القادرة على الاستجابة عن قرب، على عكس القوات المُتمركزة في القواعد المحلية. استخدمت Palantir هذا المصطلح في أواخر عقد 2000 لوصف نموذج العمل "إرسال المهندسين خارج المقر الرئيسي للإقامة في مواقع العملاء"، حتى أن فرقها الداخلية سُميت بأسماء تستخدم الأحرف الصوتية العسكرية: ديلتا وإيتشو. والآن، استعادته OpenAI وAnthropic، وهذا ليس صدفة — فجوهر إرسال المهندسين إلى الخطوط الأمامية لم يتغير أبدًا.

الأسئلة الثلاثة المحددة التي طرحها عليّ الأصدقاء الأربعة مؤخرًا هي ما سيُجيب عليه هذا المقال:

هل FDE شركة استشارية ترتدي ملابس الذكاء الاصطناعي؟ وأين تقع حدودها مقارنة بالاستشارات التقليدية؟

هل FDE هو نوع أكثر تقدمًا من تطوير البرمجيات بالتعاقد؟ ما الفرق بينه وبين ما أقوم به كطرف ثالث؟

هل أنا مناسب لمهنة FDE؟ أي نوع من الأشخاص ستُضخمهم هذه الوظيفة، وأي نوع سيُستهلك؟

موقف الكاتب هو تفاؤل حذر: FDE تنمو فعلاً، لكنها بعيدة كل البعد عن أن تكون مخرج التحول للجميع. من الأهمية بمكان توضيحها أكثر من جعلها تبدو مثيرة.

إذا كان يجب اختيار حدث واحد فقط لتحديد نقطة إعادة ظهور FDE في هذه الدورة، فسيختار الكاتب 11 مايو 2026 — اليوم الذي أعلنت فيه OpenAI عن تأسيس شركة التوزيع [5]، حيث غادر برايد ليتكاتب، الرئيس التنفيذي للعمليات، خط أعماله الأصلي وانتقل للعمل على مشاريع خاصة يُبلغ مباشرةً لسام ألتمان، ويُكرّس نفسه بالكامل لهذا المهمة. وفي نفس الأسبوع، استحوذت OpenAI على شركة الاستشارات البريطانية للذكاء الاصطناعي Tomoro، ونقلت فجأة 150 مهندسًا مُوزّعًا مُتقدّمًا ومتخصصًا في التوزيع إلى الشركة الجديدة.

جدير بالذكر أن صفحة توظيف OpenAI تُعرض في الوقت نفسه أكثر من عشرة وظائف FDE: في سان فرانسيسكو، نيويورك، واشنطن، بالإضافة إلى التخصصات الرأسية مثل العلوم الحيوية، أشباه الموصلات، والحكومة، حتى أن وظيفة مسؤول توظيف FDE [6] نفسها قيد التوظيف. وتشير التقديرات إلى أن هذا الفريق سيتوسع إلى 2000–4000 فرد خلال ثلاث سنوات. هذا ليس حجم فريق بحثي، بل هو جيش نظامي.

من ناحية Anthropic، فإن الإجراء يكاد يكون متماثلًا. وظيفة "Forward Deployed Engineer" تحت فريق Applied AI [7] معلنة في ستة مواقع: بوسطن، نيويورك، سياتل، سان فرانسيسكو، واشنطن، ولندن، مع متطلب بقضاء 25٪–50٪ من الوقت في زيارات ميدانية للعملاء. مثال حديث يُستشهد به بشكل متكرر هو شركة التكنولوجيا المالية FIS — التي كتبت صراحة في إعلانها: "لقد تم دمج فريق Applied AI ومهندسي Forward-deployed من Anthropic داخل FIS لتصميم وكيل AI للجرائم المالية ونقل المعرفة إلى FIS لتمكينها من توسيع المزيد من الوكلاء بشكل مستقل في المستقبل."

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

ارسم هذا كرسم توضيحي، وستصبح العلاقة الثلاثية واضحة جدًا:

لاحظ الخطين الأكثر إفادة في هذه الصورة، وهما التغذية المرتدة التي تُنقل من FDE في كلا الاتجاهين. نحو العملاء، لا تبيع FDE النموذج كخدمة SaaS، بل تدمج بيانات العميل وصلاحياته وامتثاله وأنظمته الداخلية في أنبوب واحد قادر على تشغيل النموذج. نحو شركات النماذج، تعيد FDE نقاط الألم الحقيقية وعينات الفشل الخاصة بالعملاء إلى فرق المنتج والبحث، مما يؤثر على خارطة الطريق — فقد يصبح نمط خطأ متكرر في استدعاء الأداة مجرد تجريد مدمج في الإصدار التالي من SDK.

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

الإجابات التالية ستتناول أكثر سؤالين شائعين مقارنةً: أين تكمن الحدود بين FDE والاستشارات التقليدية (مثل ماكنزي وأيسينسير)؟ وهل هو نفس شيء تفويض البرمجيات الذي نعرفه؟

عندما يسمع الكثيرون وصف وظيفة FDE لأول مرة، يكون رد فعلهم الأول: "أليس هذا مجرد إصدار جديد من ماكينزي أو إيسنجر؟"

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

عند وضع هذين العنصرين جنبًا إلى جنب في جدول، ستظهر الفروق على الفور.

السطر الأكثر استحقاقًا لل停下来 في هذا الجدول هو "استهلاك الأصول".

أبسط منطق ربحي في الاستشارات التقليدية هو إعادة استخدام الأصول — خطة مقدمة لبنك معين يمكن تعديلها قليلاً وبيعها مرة أخرى للبنك التالي؛ ويمكن تطبيق دليل رقمي لقطاع التجزئة مرارًا وتكرارًا على ثلاثين عميلًا. هذا هو النموذج الاقتصادي الأساسي الذي بُني عليه نمو Accenture وDeloitte وMcKinsey Digital على مدار الثلاثين عامًا الماضية.

FDE لا تمتلك هذا الأصل. قدرات النموذج لا تزال تتحرك بسرعة كبيرة — اليوم لا يزال يتطلب سلسلة موجهات مصممة بدقة، لكن النموذج في الإصدار التالي قد يحلّ المشكلة بجملة واحدة فقط. سيتدهور بسرعة "تراكم منهجية الاستشارة" أمام هذا السرعة. لذا لا يمكن لـ FDE استخدام نموذج إعادة استخدام الأصول، بل يجب إعادة تشغيل الحلقة الكاملة في كل مرة — إعادة تقييم حدود النموذج، وإعادة اختيار مجموعة الأدوات، وإعادة تجميع شكل المنتج. يبدو هذا غير فعّال، لكنه الطريقة الوحيدة التي يمكنها مواكبة سرعة النموذج.

هل تعلم ما هو Product Overhang؟ شرحتُ هذا المصطلح في المقال السابق "إلى الأفراد الفائقين" [4]: إن قدرات النموذج تفوق شكل المنتج الحالي، لكنها تفتقر إلى نقطة دخول للمنتج أو صلاحيات أو سياق لتحويلها إلى واقع. إن قيمة دور FDE تكمن جوهرًا في تحويل هذه الـ Overhang المعلقة في سيناريوهات العملاء إلى منتج عملي قابل للتنفيذ. لا يشتري العملاء كمية طلبات واجهة برمجة التطبيقات الخاصة بالنموذج، بل يشترون "القدرة على تنفيذ هذه الـ Overhang فعليًا ضمن أعمالهم".

وهذا يفسر أيضًا الاختلاف في سطر "هيكل المشروع". الهيكل القياسي لمشروع الاستشارة هو WOS (بيان العمل) + WBS (هيكل تقسيم العمل) + المراحل المقبولة: يتم تحديد ما سيتم تسليمه ومتى سيتم تسليمه وأي معايير سيتم قبوله وفقًا لها في العقد. هذا الهيكل يفترض أن الهدف تم تعريفه بوضوح قبل توقيع العقد.

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

يُستحق أيضًا تفصيل سطر "المخرجات". بعد مغادرة FDE، ما يبقى في نظام العميل هو وظيفة تعمل — قد تكون صغيرة، أو قبيحة، أو خالية من واجهة مستخدم، لكنها تُستدعى يوميًا وتُعدّل وتُنتقد. أما مخرجات الاستشارات فهي عبارة عن عروض PowerPoint وتقارير إدارة التغيير، حتى لو تم كتابة أكواد أو تكوين أنظمة ERP ضمن المشروع، فإن ما يبقى في أيدي كبار المسؤولين في العميل لا يزال وثيقة منهجية.

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

لذلك، عندما يقول لك أحدهم لاحقًا: "أليس FDE مجرد نسخة محدثة من Accenture؟" يمكنك الرد بهذه الطريقة: مهندسو Accenture يعيدون تصميم عمليات العملاء، بينما FDE تعيد استكشاف حدود النموذج. أصول الأول يمكن أن تتراكم لمدة عشر سنوات، بينما أصول الثاني يجب إعادة نموها بعد 90 يومًا.

إذا كان اعتبار "FDE هي نسخة جديدة من Accenture" هو التفسير الخاطئ الأول، فإن اعتبار "FDE هي استعانة بمصادر خارجية للبرمجيات باهظة الثمن" هو التفسير الخاطئ الثاني. هذا التفسير أكثر إرباكًا، لأن الأدلة الظاهرة تبدو مقنعة جدًا: FDE فعلاً تذهب إلى مواقع العملاء لكتابة الكود، وفعلاً تُصمم الميزات وفقًا لعمليات العميل، وفعلاً تتبع ساعات عمل العميل. عند النظر السريع، لا تختلف عن مهندسي الاستعانة بمصادر خارجية.

لكن بمجرد النظر إلى دورة التغذية الراجعة، لا يمكن إخفاء الفرق.

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

الأشياء المُستلمة مختلفة. يتم استلام SOW من قبل المتعاقدين الخارجيين — قائمة متطلبات مُعرّفة بوضوح قبل توقيع العقد: ما هي الوظائف المطلوبة، وما هي مجموعة التقنيات المستخدمة، وما هي معايير القبول، وكيفية التعويض في حالة المخالفة. أما FDE فيتلقى مهمة — العميل نفسه لا يدرك تمامًا ما يريده، بل يعرف فقط أن "الذكاء الاصطناعي يجب أن يساعدني في فعل شيء ما". أساس SOW هو اليقين، بينما أساس المهمة هو الاستكشاف. إنهما موقفان مختلفان تمامًا لبدء المشروع.

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

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

وجهات التغذية الراجعة مختلفة. هذه المجموعة هي الأعمق بين المجموعات الأربع. في المشاريع المُستَنْدَة، لا تتجاوز التغذية الراجعة من العميل حدود شركة التصنيع الخارجي، ولا تؤثر على المنتجات التي ستبيعها الشركة الخارجة لعملاء آخرين في المستقبل. أما تغذية FDE الراجعة فتعود إلى خارطة طريق شركة النموذج — فكل عقبة يواجهها العميل في السيناريوهات الواقعية، وكل فشل في Prompt، وكل خطأ في استدعاء الأداة، تصبح مدخلات لبيانات التدريب الإصدار التالي، ولتصميم الأداة الإصدار التالي، ولوظيفة المنتج الإصدار التالي. بمعنى آخر، كل عميل يتم نشره عبر FDE هو، بالنسبة لشركة النموذج، شريك تصميم طبيعي.

هذا هو السبب الحقيقي وراء رغبة شركات النماذج في دفع رواتب عالية لتوظيف FDE. إنهم لا يبيعون مجرد خدمة، بل يجمعون إشارات حول شكل المنتج في العالم الحقيقي من مواقع العملاء. هذه الإشارات لا يمكن شراؤها أو التقاطها أو استخلاصها من استبيانات — فهي تُجمع فقط من قبل مهندس محدد، داخل تدفق عمل عميل محدد، بعد أن يصطدم بجدران عدة مرات.

هل تعلم؟ ما هو إجمالي تعويض FDE لـ OpenAI وAnthropic؟ وفقًا للبيانات العامة على Levels.fyi لمهندسي البرمجيات في Anthropic [8]، بلغ الوسيط الإجمالي للتعويض لمهندسي SDE ذوي الخبرة 710,000 دولار. إن وظيفة FDE تحمل مخاطر أعلى — فهي تتطلب مواجهة عدم اليقين في قدرات النموذج، وعدم اليقين في أعمال العميل، بالإضافة إلى تحمل عدم اليقين في شكل المنتج، لذا وفقًا للتجميع الصناعي [9]، فإن إجمالي تعويض FDE في المختبرات الرائدة للذكاء الاصطناعي يتراوح عادة بين 350,000 و550,000 دولار، ويمكن أن يصل إلى أكثر من 630,000 دولار للمستوى Staff وما فوق. هذا السعر لا يُدفع مقابل "ساعات العمل المُستَخرَجة"، بل مقابل من يتحمل مزيج المخاطر الثلاثة: "المنتج + العميل + النموذج". > تذكّر عام 2006، عندما بدأت عملي في شركة حكومية صينية، حيث كانت الشركة تمر بمرحلة التحول الرقمي، وكان مستشارو Accenture الذين دعتهم الشركة يقيمون في الموقع، وكانت الشركة تدفع 3500 يوان صيني يوميًا لـ Accenture، واستمر ذلك لسنوات عديدة، ووصفته وسائل الإعلام آنذاك بـ"الطبقات الذهبيّة". لاحقًا انتقلت إلى شركة SAP الألمانية، التي عرّفت مصطلحًا جديدًا في مجال الاستشارات، وأصبح مستشارو SAP رمزًا للطبقات الذهبيّة. ومن هذا المنظور، فإن رواتب FDE ستستمر في الارتفاع على مدى 24 إلى 36 شهرًا على الأقل، كما أن الطلب عليها في تزايد مستقر.

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

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

انظر أولاً إلى خط زمني.

الجذر الأول هو Palantir.

تأسست Palantir في عام 2003 من قبل بيتر ثيل وأليكس كارب وجو لونسديل وغيرهم، وكان أول عملائها هي الوكالات الاستخباراتية الأمريكية. لا يمتلك كارب خلفية في علوم الحاسوب — فقد أجرى أبحاثه للدكتوراه في فرانكفورت مع الفيلسوف يورغن هابرماس، ثم تم جره من قبل ثيل للانضمام كرئيس تنفيذي بعد عودته إلى الولايات المتحدة. لقد نشأ دور FDE بالضبط من هذا المزيج "الرئيس التنفيذي غير النموذجي + عملاء شديدو السرية" — حيث كُتب بوضوح في مراجعة 36Kr [10] أن Palantir تعرضت لانتقادات شديدة من قبل الوكالات الاستخباراتية في مراحلها المبكرة، وذلك لأن المهندسين لم يكونوا قادرين على الوصول إلى سيناريوهات عمل حقيقية، وكانت المتطلبات تتشوّه عبر سلسلة من الترجمات المتعددة. لاحقًا، نجحت Palantir في التوصل إلى اتفاق — يسمح للمهندسين الخاصين بها بالدخول مباشرة إلى مواقع العملاء والعمل جنبًا إلى جنب مع محللي الاستخبارات. وقد قام شيم سانكار بتوحيد هذا النموذج لاحقًا، ليصبح نواة FDE.

بحلول عام 2009، امتدت FDE إلى المجال التجاري. عندما نشرت JPMorgan منصة Palantir Metropolis، تواجد 120 من FDE لمراقبة التهديدات الداخلية. ومنذ ذلك الحين، لم تعد FDE مجرد "إرسال مهندسين في رحلات عمل"، بل أصبحت استراتيجية متكاملة للدمج مع العملاء: حيث يتم دمج Foundry / Gotham فعليًا في تدفق أعمال العميل، وليس مجرد توزيع ترخيص ثم المغادرة.

يوجد معيار غير بديهي في توظيف FDE لشركة Palantir — لا يشترط شهادة في علوم الحاسوب. يمكن إدراج هذا الأمر في "هل تعلم؟"

هل تعلم أن Palantir FDE لا تشترط شهادة في علوم الحاسوب؟ وفقًا لمعايير التوظيف التي جمعتها SkillScouter [11] وصفحة Palantir الرسمية للوظائف [12]، فإن Palantir ترحب صراحةً بالمرشحين غير المتخصصين في علوم الحاسوب، حيث جاء أحدث موظفي FDE من تخصصات مثل الهندسة الميكانيكية، والاقتصاد، والفلسفة. إن الأمرين الحقيقيين اللذين تركز عليهما هما: القدرة على اتخاذ إجراءات في ظل معلومات غير كاملة، والقدرة على التواصل المباشر مع عملاء من المستوى التنفيذي. إن شهادة علوم الحاسوب هي ميزة إضافية، وليست شرطًا للقبول. كارب نفسه هو أول نموذج لهذه المعايير — رئيس تنفيذي درس الفلسفة، وقاد فريقًا من FDE متخصصين في الفيزياء والرياضيات والفلسفة.

الجذر الثاني هو شركة نموذج جديدة بعد عام 2023.

بعد إطلاق ChatGPT في أواخر عام 2022، أدركت OpenAI شيئًا واحدًا بسرعة: توصيل واجهة برمجة التطبيقات للنموذج على الوثائق وترك العملاء يتصلون بهم بأنفسهم كان أمرًا غير قابل للتنفيذ. لم يكن العملاء غير راغبين في الاستخدام، بل كانوا لا يعرفون كيف يستخدمونه — فلديهم مشكلات تجارية، لكنهم لا يملكون شكلًا منتجًا. لذلك، بدأت هذه المجموعة من الشركات — OpenAI وAnthropic وCohere وScale وGlean وSierra وHebbia وDecagon — في توظيف عدد كبير من FDE.

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

في المقال المتخصص لـ Pragmatic Engineer حول FDE [13]، يُطلق على هذا الإصدار الجديد اسم "مدمج مع المؤسسات لجعل Claude يحل مشكلات حقيقية وملحة وذات قيمة عالية" — وهي صيغة تشبه تمامًا ما استخدمته Palantir في ذلك الوقت، مع استبدال كلمة "البيانات" بـ "النموذج".

عند النظر إلى هذين الجذرين معًا، يمكنك رؤية مجموعة من أوجه التشابه والاختلاف الواضحة.

النقطة المشتركة: العملاء لا يشترون برنامجًا. العملاء يشترون "مهندسًا قادرًا على حل مشكلاتهم + مجموعة أدوات". كان هذا غير معتاد في تاريخ برامج الشركات على مدار الثلاثين عامًا الماضية. كانت SAP وOracle وSalesforce تبيع البرمجيات نفسها — حيث كان المهندسون موارد داعمة فقط من أجل "جعل هذا البرنامج في متناول العملاء". بالمقابل، تتعامل Palantir بشكل عكسي: الأدوات موجودة كرافعة لتمكين FDE من حل المشكلات لدى العملاء. ورثت شركات النموذج الجديد هذه العلاقة المعكوسة — فـ OpenAI لا تبيع ترخيص GPT-4، بل تبيع "قدرة مهندسينا على استخدام GPT-4 لمساعدتك في أتمتة خدمة العملاء".

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

حقيقة مثيرة أخرى: العديد من مهندسي Palantir في المراحل المبكرة أصبحوا رواد أعمال، أو انضموا مباشرة إلى شركات النماذج الجديدة. يمكن أن تعدد قائمة طويلة من أسماء خريجي Palantir ضمن الفرق المبكرة لـ Anthropic و OpenAI و Sierra و Hebbia.这不是巧合——FDE هذا المنصب يجبر الشخص على تحمل مخاطر المنتج ومخاطر العميل ومخاطر الهندسة في آنٍ واحد، وهو تقريبًا تدريب على ريادة الأعمال. يفضل الكاتب اعتبار Palantir كمعسكر تدريب ريادي خفي: فهي لا تُنتج فقط مهندسين، بل مجموعة من الأشخاص الذين يعرفون كيف يدفعون مشروعًا من الصفر إلى الواحد في ظل معلومات غير كاملة. جذران، اجتمعا في النهاية بعد عام 2023.

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

سابقتان محليتان

كان أول سلفه مهندس حلول من مزود سحابي. فقد نمت على مدى العقد الماضي فرق كاملة من مهندسي الحلول (SA) لدى علي بابا كلاود وتيان تين كلاود وهواوي كلاود، حيث كانوا يشرحون البنية للعملاء، ويكتبون نماذج إثبات المفهوم، ويعدون خطط الهجرة، ويدعمون عملية التسليم حتى التشغيل. كما توجد داخل هواوي سلسلة مخصصة تُسمى "مهندسي التسليم" مسؤولة عن تنفيذ المشاريع في مراكز بيانات العملاء. وقد غطت هذه المنظومة بالفعل 80% من مهام FDE، لكن تركيزها لا يزال على ما قبل البيع والنشر — فمسؤولية التكرار الكامل للمنتج لا تقع على عاتق مهندس الحلول، وفي حال تغيّر المتطلبات يجب اتباع إجراءات التغيير، وإذا تم تغيير النموذج، فيجب الانتظار حتى يتم تحديد جدول زمني من المقر الرئيسي.

السابق الثاني هو سلسلة نشأت حديثًا في شركات ناشئة للذكاء الاصطناعي. تُعلن MiniMax عن وظيفة "خبير حلول ما قبل البيع للذكاء الاصطناعي" على منصة BOSS Zhipin، كما تُعلن شركات النماذج مثل Yueqi Anmian و Zhipu و Tongyi و Hunyuan عن وظائف مشابهة. تختلف الأسماء قليلاً، لكن محتوى وصف الوظيفة متماثل إلى حد كبير: فهم سيناريوهات العملاء، وإجراء عروض توضيحية، وضبط الأوامر، وتشغيل RAG، وكتابة خطط التسليم، والتنسيق مع فرق الهندسة الخاصة بالعملاء حتى الإطلاق. هذه المجموعة من الوظائف هي بالفعل "FDE المحلية" بمعنى دقيق.

Three water and soil differences

النشر الخاص + الامتثال للبيانات يُثقل نموذج الاستدعاء النقي. متطلبات العملاء المحليين من الفئة B فيما يتعلق بعدم خروج البيانات من الحدود، والتحكم في أوزان النموذج، وإمكانية تتبع المراجعة أعلى بكثير من السوق الأمريكي. في مشروع FDE، قد لا تمثل كمية العمل المتعلقة بالاستدعاء النقي للـ API وتشغيل الـ Prompt سوى 30٪، بينما تمثل الـ 70٪ المتبقية نقل النموذج إلى مقر العميل، وتشغيل المصادقة، وربط منصة البيانات، وإجراء التسجيلات الامتثالية.

ما زالت قدرات النموذج تسعى للحاق بالمستوى الأعلى (SOTA)، وقد تقلص مجال التفوق إلى المستوى الهندسي. يمكن لشركات الولايات المتحدة مثل OpenAI وAnthropic إثارة اهتمام العملاء من خلال قدرات النموذج نفسها؛ أما الشركات المحلية مثل Tongyi وDoubao وKimi وGLM وDeepSeek، فالفروق في قدراتها أقل وضوحًا، لذا يركز عملاءها أكثر على القدرات الهندسية مثل ترتيب الوكلاء (Agent编排)، وجودة استرجاع المعلومات (RAG)، تكامل الأدوات، وتصميم سير العمل (Workflow). في الصين، لا يعتمد FDE على "كم هي قوية نماذجنا"، بل على "هل يمكنني تنفيذ هذا العمل فعليًا؟"

رغبة الجانب B في الدفع ووتيرة التسعير تختلف عن الولايات المتحدة. من الصعب نسخ نموذج Palantir "إدخال FDE أولاً، ثم فرض اشتراكات بأسعار عالية". ميزانيات العملاء المحليين تتبع المشتريات السنوية، وتركز الدفع على أساس المشاريع، وغالبًا ما يكون نموذج عمل FDE مزيجًا من الاشتراك والترخيص الخاص وتسليم المشروع.

موقع فريد: FDE داخلي

تبدأ فرق الذكاء الاصطناعي داخل شركات كبيرة باستخدام نموذج FDE لخدمة "العملاء الداخليين". فقد أرسلت Alibaba Cloud PAI مهندسين للعمل داخل Taobao، كما تمتلك Tencent Hunyuan آلية مشابهة للربط مع WeChat وفريق الإعلانات. على JD، تُعرض المسميات الوظيفية مثل "مهندس تنفيذ صناعي" و"مهندس تطبيقات الذكاء الاصطناعي" و"خبير أعمال ذكي"، وهي في جوهرها فرق FDE داخلية — تُنقل قدرات فرق النماذج بشكل كامل إلى جانب الأعمال. وهذا يمنح قادة الشركات الكبرى فكرة جديدة: بضع فرق FDE داخلية تُرسَل للعمل مباشرة مع فرق الأعمال، وتقديم أول نموذج تجريبي، وتقديم بيانات العائد على الاستثمار إلى مدراء الأعمال، سيؤدي إلى تذويب جدران الأقسام أسرع بكثير من عقد عشر اجتماعات مواءمة.

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

السمات الخمسة المناسبة لـ FDE

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

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

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

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

حساس لحدود النموذج. هذه هي الأكثر تقنية والأكثر خفية. يجب على FDE أن يُحدّد المهام المناسبة لـ LLM والمهمات غير المناسبة، وكيفية التحول إلى حل بديل — هذه الحساسية لا يمكن استخلاصها من الأوراق البحثية، بل تُكتسب فقط من خلال حالات الفشل. مع تراكم عينات الفشل، يطور FDE ذاكرة عضلية لحدود النموذج: متى يستخدم RAG، ومتى يتبع قواعد ثابتة، ومتى يجب توفير مدخل بديل للإنسان.

الأربعة أنواع غير المناسبين لـ FDE

شخص تقني يحب الاختباء في الكود. FDE يقضي حوالي 50% من وقته خارج كتابة الكود — في اجتماعات العملاء، والتنسيق الداخلي، ومناقشات المنتج، ودفع العقود. إذا كان مصدر سعادتك هو كتابة الكود دون أي مقاطعة لمدة أربع ساعات متواصلة، فسيجعلك FDE تعاني من إرهاق نفسي طويل الأمد.

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

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

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

قائمة التحقق الذاتي

7 أسئلة، كل منها يتوافق مع سيناريو عمل حقيقي لـ FDE. إذا أجبت بـ "نعم" على خمسة أسئلة أو أكثر، فكر بجدية في FDE؛ إذا أجبت بـ "نعم" على ثلاثة أسئلة أو أقل، يُوصى بالحذر.

هل أنت مستعد لنقل 50% من وقتك اليومي من الكود إلى اجتماعات العملاء، والرد على الرسائل والمكالمات؟

عندما يخبرك العميل "هذا لا يعمل، ولا أستطيع توضيح السبب"، هل رد فعلك الأول هو الفضول أم الإحباط؟

3. لا أحد كتب لك PRD، هل يمكنك في غضون أسبوع تشغيل نموذج أولي يمكن عرضه للعملاء مع Claude Code؟

4. هل يمكنك الحفاظ على قدرتك على التقييم، وليس التنفيذ الآلي، عندما يطلب العميل تعديل نفس التسليم 8 مرات؟

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

6. هل أنت مستعد للتوقيع على العقود، وكتابة التقارير، ومرافقة العملاء للحصول على قبولهم، والتعاون مع القسم القانوني بشأن الشروط الامتثالية؟

7. هل يمكنك قبول النماذج الأولية السريعة والفشل السريع؟

خمسة صفات، وأربع صور عكسية، وسبعة أسئلة ذاتية، في النهاية جميعها تُجيب على نفس السؤال: هل أنت مستعد لصقل حس منتجك وقدراتك الهندسية وحكمك التجاري في نفس سير العمل؟

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

FDE ليس النهاية. رأي الكاتب هو أن FDE هو فقط أول شكل يكتسب اسماً في التقسيم الجديد. سيظهر لاحقاً Forward Deployed PM وForward Deployed Designer وForward Deployed Researcher—جميع المهن المرتبطة ارتباطاً وثيقاً بسيناريوهات العملاء والتي تتطلب نمو المنتج في المناطق الضبابية، ستُنتج نسخاً "مُقدَّمة" خاصة بها. ستتغير أسماء الوظائف، لكن المنطق الأساسي هو نفسه: قدرات النموذج تسير في المقدمة، بينما تسعى أشكال المنتج للحاق بها، وتُعاد تقسيم هيكل الوظائف وفقاً لتدفق العمل.

اترك جملة واحدة لكل فئة من القراء الثلاث.

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

لـ HR و OD: كونوا حذرين من "الانفصال بين الاسم والواقع". قد يكون لديك بالفعل مجموعة من FDE يعملون في شركتك، لكن وظائفهم مسجلة تحت مسميات مثل "خبير حلول" أو "مهندس معماري صناعي" أو "مهندس تطبيقات الذكاء الاصطناعي". حدد هؤلاء الأفراد، وأعد تصنيفهم، ووفر لهم مسار نمو يتوافق مع محتوى عملهم — فهذا أكثر كفاءة من توظيف أشخاص جدد من الصفر.

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

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

👦🏻 المؤلف: هنري (فريق DeerFlow) [1]