الأدوار التي يدرّب عليها هذا الكتاب
يخترع السوق مسمّيات وظيفية أسرع مما يستطيع تعريفها. معظم هذه المسمّيات هو التخصص نفسه على أعماق مختلفة: التخصص الذي يدرّب عليه هذا الكتاب. هذه هي الخريطة، وهذا هو الحدّ الدقيق الذي يوصلك إليه الكتاب في كل دور.
نعرّف هنا أدوار عصر الذكاء الاصطناعي الوكيلي الجديد: الوظائف التي وُجدت لأن الشركات أصبحت تصنع AI Workers وتشغّلها وتحكمها. رتّبنا الإدخالات بحسب الطريقة التي يتجمّع بها العمل فعلياً، والحكم بجانب كل إدخال هو خط النطاق الصريح: إلى أي مدى يوصلك هذا الكتاب نحو ذلك الدور، وأين تتولى مسارات الشهادة الأمر بعده. الأحكام أهم من الأسماء. وحيث يتوقف الكتاب، يقول ذلك بوضوح.
يبدأ الجميع من Foundations نفسها، أي مهارات المتصفح التي يحتاج إليها كل قارئ قبل أي عمل وكيلي. وعلى هذا الطابق تقع نمطا استخدام الوكيل العام. Mode 1 هو استخدام وكيل عام لتنجز عملك أنت بسرعة أكبر، وهي كفاءة يحتاج إليها كل قارئ وليست مسمى وظيفياً. أما Mode 2 فهو تصنيع AI Workers تؤدي العمل نيابةً عنك، وهنا تظهر المسميات الوظيفية. تفتح الخريطة بطابق Foundations وبـ Mode 1 Practitioner، ثم تنتقل إلى أدوار Mode 2، وهي معظم الخريطة تقريباً.
إن كنت جديداً على المصطلحات (Digital FTE، SKILL.md، Agent Factory)، فابدأ بـ Thesis وGlossary؛ فهذه الصفحة تفترض معرفتها.
الخريطة كلها في لمحة واحدة: المسار الأساسي، وما يمدّه ويدعمه، وأين يتوقف الكتاب، والقاعدة التي تحته كله.
الأساس الذي يبدأ منه الجميع
Foundations: الطابق، قبل أي نمط. يبدأ كل قارئ بالطريقة نفسها، في تبويب متصفح، على Foundations: كيف تصوغ التعليمات، ولغتا التوثيق في العمل الوكيلي، وكيف تكلّف الوكيل بكتابة كود لن تكتبه بنفسك، والمهارات والموصلات، وكيف تفكر في عصر الذكاء الاصطناعي. لا نمط، لا دور، ولا شيء لتثبيته. هذا هو الطابق الذي تقف عليه الخريطة كلها. حيث يبدأ الجميع، لا لقباً تحمله.
Mode 1 Practitioner: ليس لقباً، بل كفاءة. على هذا الطابق تستخدم وكيلاً عاماً لتنجز عملك بسرعة أكبر: الاستدلال، والكتابة، والبرمجة، والتحليل، والتخطيط، وشحن نتيجة، وإغلاق الجلسة. هذا هو Mode 1، ويدرّب عليه الكتاب الجميع: المهندسين عبر Claude Code أو OpenCode، وخبراء المجال عبر Claude Cowork أو OpenWork، تحت المبادئ السبعة لحل المشكلات بالوكلاء العامين. إنه أول نمط يشغّله كل قارئ قبل أدوار Mode 2 أدناه، ويجعلك أقوى في العمل الذي تمارسه بالفعل بدلاً من أن يمنحك وظيفة جديدة. أول نمط يشغّله الجميع، لا لقباً تحمله.
النواة العامة
تعمل هذه الأدوار الأساسية كمسار واحد، من القصد إلى الإنتاج: Outcome Architect (ماذا) ← Digital FTE Builder (البناء) ← AI-Native Company Architect (النظام) ← Cloud AI Engineer (التشغيل). شغّل هذا داخل شركتك تكن هذه الأدوار الأربعة؛ وشغّله داخل شركة عميل، محمولاً من البداية إلى النهاية على مهندس مدمج ومحايد تجاه الموردين، يكن Forward Deployed Engineer. كل ما عدا ذلك في الخريطة يدعم هذا الخط أو يمدّه أو يضع له حدوداً.
تشغّل أربعة أدوار هذا الخط داخل شركتك؛ ويحمل مهندس مدمج الخط نفسه داخل شركة عميل.
Outcome Architect: يملك القصد، لا التنفيذ. ينقسم العمل في عصر الوكلاء إلى ثلاثة أشياء: القصد، والتنفيذ، والتحقق. يملك Worker التنفيذ؛ ويملك هذا الدور القصد. يقرر ما يجب أن يحققه Worker، ويكتب المواصفة التي تثبّت ذلك، ويحدد معنى "الصحيح"، ويرتّب أولويات Workers التي تستحق البناء أصلاً: الإنسان الذي يجيب عن ماذا ولماذا قبل أن يجيب Builder عن كيف. حيث يملك مسار Strategist اكتشاف العميل وROI، يملك Outcome Architect خارطة Workers الداخلية والمواصفات التي تستند إليها. يدرّب الكتاب على هذا مباشرةً: فالتطوير المدفوع بالمواصفات هو، في جوهره، تخصص كتابة قصد يمكن محاسبة Worker عليه. يدرّب عليه: التخصص الذي يستند إليه المنهج كله.
Digital FTE Builder: المنتج الوحدوي، مبني من البداية إلى النهاية. يسمي السوق هذا الدور AI Engineer، وهو تعبير واسع لمن يبني تطبيقات من مكونات الذكاء الاصطناعي ويقود وكلاء البرمجة بالذكاء الاصطناعي. اسم هذا الكتاب أدق، لأن الشيء الذي تبنيه أدق: Digital FTE، الوحدة التي تُجمّع منها الشركة كلها. هذا هو الخريج الأساسي للكتاب. يدرّب الكتاب العمود كاملاً: التطوير المدفوع بالمواصفات، وتأليف SKILL.md، وبنية الوكلاء، وواجهات الأدوات وMCP، والتقييم، والرقابة البشرية، مع ما يكفي من النشر للشحن، وترك العمق التشغيلي لـ Cloud AI Engineer. يدرّب عليه من البداية إلى النهاية.
AI-Native Company Architect: يصمم الشركة، لا Worker واحداً. المؤسسة كلها: Two-Layer Model، وطبقة الإدارة، والقوة العاملة، والجهاز العصبي الذي ينقل الأحداث بينها، ونظام السجل الذي تعمل كلها عليه. Agent Factory هو العملية التي يمارسها هذا المعماري؛ وAI-Native Company هي المنتج الذي يشحنه. هذا الكتاب مصدرها الموثوق. برنامج Certified Agentic AI Architect الممتد لخمسة أرباع هو شهادتها. يتدرّب عليه بالكامل؛ ويُعتمد عبر مسار Architect.
Cloud AI Engineer: من يشغّل AI Worker وAI-Native Company في الإنتاج. بناء Digital FTE نصف العمل؛ وتشغيله بموثوقية هو النصف الآخر، وكذلك تشغيل AI-Native Company التي ينتمي إليها. حيث يصمم AI-Native Company Architect المؤسسة، يشغّل هذا الدور المؤسسة: نشر Workers وطبقة الإدارة والجهاز العصبي وتوسيعها على بنية سحابية حقيقية، Azure Container Apps للشحن، وInngest للتنفيذ المتين، وDapr وKubernetes للتوسع. هنا يتوقف النظام عن كونه نموذجاً أولياً ويصبح شركة تستطيع المؤسسة الاعتماد عليها. يدرّب عليه من البداية إلى النهاية.
الدوران اللذان لا يكاد أحد غير هذا الكتاب يدرّب عليهما
Subject Matter Expert as Skill Author: الدور الذي لم يسمّه السوق بعد. المحاسب أو المحامي أو خبير سلسلة الإمداد الذي يرمّز حكمه المهني في SKILL.md ويصبح محرك المعرفة في Digital FTE. تفوّت معظم قوائم السوق هذا الدور لأنها لا تزال تتصور عمل الذكاء الاصطناعي كأنه هندسة فقط. يعامل هذا الكتاب الحكم المجالِي نفسه بوصفه شيئاً يمكن تأليفه واختباره ونشره. هذا أحد الدورين اللذين لا يكاد أحد غير هذا الكتاب يدرّب عليهما. يدرّب عليه بالكامل: يدخل الحكم المهني، ويخرج وكيل عامل.
Forward Deployed Engineer (FDE): النسخة المحايدة تجاه الموردين التي لا يجدها السوق
ما الذي يفعله FDE فعلياً. يبني معظم مهندسي البرمجيات منتجاً في المقر الرئيسي ولا يقابلون العميل الذي يستخدمه. يفعل FDE العكس. يذهب إلى مكان العمل الحقيقي لدى العميل، ويجلس إلى جانب الأشخاص الذين يؤدون العمل، ويفهم المشكلات الحقيقية التي يواجهونها، ويبني الحلول هناك، في الموقع، باستخدام منصة شركته. ليست عرضاً تجريبياً. ليست شرائح عرض. بل برمجيات عاملة تعمل في بيئة العميل الحقيقية.
تخيّل الفرق بين طبيب يقرأ ملفك من مدينة أخرى وطبيب يجلس في الغرفة، يفحصك، ويبدأ العلاج فوراً. FDE هو الطبيب الثاني.
أنشأت Palantir، وهي شركة كبرى لتحليلات البيانات تبني برمجيات للحكومات والمؤسسات الكبيرة، هذا الدور في أوائل العقد الثاني من القرن الحادي والعشرين، وسمّت أصحابه في البداية "Deltas".1 وحتى قرابة 2016، كان لدى Palantir عدد من FDEs أكبر من عدد مهندسي البرمجيات العاديين، لأن عملاءها، أي الوكالات الحكومية والمؤسسات التقليدية الكبيرة، احتاجوا إلى شخص في الموقع يستطيع اختراق البيروقراطية الداخلية بعقلية startup. طريقة Palantir في شرح الفرق هي الأوضح: يركّز المطور العادي على قدرة واحدة، عملاء كثر (يبني ميزة واحدة ويشحنها للجميع)، بينما يركّز FDE على عميل واحد، قدرات كثيرة (يندمج مع عميل واحد ويحُلّ ما يحتاج إليه). يلتقط وصف الوظيفة نطاقها: فهي تشبه عمل CTO في startup. تملك كل شيء من البداية إلى النهاية في مشاريع عالية المخاطر.
هذا ليس مثل Solutions Architect أو Sales Engineer. يقدم Solutions Architect المشورة: يشغّل العروض التجريبية، ويصمم الحلول على السبورة، ويبني نماذج إثبات مفهوم ببيانات عينة لإقناع العميل المحتمل بالتوقيع. وبعد إغلاق الصفقة، ينحسر دوره عادةً. يلتقط FDE العمل من حيث يتوقف Solutions Architect. يكتب كود إنتاج مباشرةً على بنية العميل التحتية، ببيانات حقيقية، ويبقى حتى يحصل العميل على قيمة حقيقية. والاختبار بسيط: إن كان الدور مسؤولاً عن جعل العمل الخاص بالعميل يعمل فعلاً في الإنتاج، فهو أقرب إلى FDE. وإن كان مسؤولاً عن إثبات المنتج أو شرحه، فهو أقرب إلى solutions architect.
مثال حقيقي: اندمج فريق النشر في OpenAI مع John Deere، شركة الزراعة التي تقارب 190 عاماً، لحل مشكلة في موسم الزراعة على الأرض. وبالعمل من سجل الاستخدام السابق لكل مزارع، ساعدوا في بناء توصيات مدعومة بالذكاء الاصطناعي حول كمية المادة الكيميائية الأقل التي سيحتاج إليها المزارع مع See & Spray، نظام John Deere للتحكم الموجّه في الأعشاب. وتنسب John Deere إلى هذا العمل خفض استخدام المواد الكيميائية بنحو 70% ورفع تفاعل العملاء ستة أضعاف.2 كان الموعد النهائي هو تقويم الزراعة، لا خارطة طريق المنتج. وهذه هي وظيفة FDE في سطر واحد: برمجيات إنتاج حقيقية، تُبنى في عالم العميل، وتُشحن حين يحتاج إليها العميل فعلاً.
FDE هو حيث يلتقي الكود والمنتج والعميل: قدرة software engineer على البناء، وغريزة platform engineer تجاه المنتج، وقراءة solutions architect للعميل، في شخص واحد يبني في عالم العميل، لا في المقر الرئيسي.
لماذا تريد كل شركة ذكاء اصطناعي الآن FDEs. زادت إعلانات وظائف FDE بأكثر من 800% في الأرباع الثلاثة الأولى من 2025.3 وأنشأت Salesforce فريق FDE مخصصاً لدعم منصة Agentforce.4 وأنشأت OpenAI "Deployment Company"، وهي شركة تابعة مملوكة بالأغلبية ومدعومة بنحو 4 مليارات دولار من تحالف مستثمرين، وبُنيت إلى حد كبير حول تزويد المؤسسات بـ FDEs.5 السبب وراء ذلك كله بسيط: وجدت دراسة أجراها MIT Media Lab في 2025، Project NANDA، أن نحو 95% من تجارب الذكاء الاصطناعي المؤسسية المخصصة لا تُظهر عائداً قابلاً للقياس.6 ليس لأن الذكاء الاصطناعي لا يعمل، بل لأن إدخاله في أنظمة الشركة الواقعية والفوضوية أمر بالغ الصعوبة. وُجد FDEs لإغلاق هذه الفجوة. وهم سبب من الأسباب التي جعلت Palantir تتجاوز قيمة سوقية قدرها 136 مليار دولار في أواخر 2024، متقدمةً على Lockheed Martin،7 والآن تريد كل شركة ذكاء اصطناعي تكرار النموذج.
مشكلة الارتهان للمورد. هنا تكمن العقدة. كل FDE في Palantir يبني على منصة Palantir. وكل FDE في OpenAI يبني على نماذج OpenAI. وكل FDE في Salesforce يبني على أدوات Salesforce. يدخل المهندس عميقاً في شركة العميل، ويربط منتج ذلك المورد الواحد بكل شيء، ثم يغادر. يصبح التبديل لاحقاً مؤلماً ومكلفاً، كسبّاك لا يركّب إلا نوعاً واحداً من الأنابيب: تعمل السباكة، لكنك لا تستطيع استئجار سبّاك آخر من دون هدم الجدران. وكما أشار Andrew Ng في The Batch،8 يعاني العملاء في العثور على FDEs غير مرتبطين بمورد واحد، لأن الهدف من الدور، بالنسبة إلى المورد، هو إغلاق العميل داخله.
يدرّب هذا الكتاب على FDE الذي يطلبه السوق ولا يجده. المنهج هنا غير مرتبط بأي مورد. يحمل خريج هذا الكتاب المسار الكامل، أي تحديد القصد، وبناء Worker، وتصميم النظام، وتشغيله في الإنتاج، داخل مؤسسة العميل من دون قفلها في منصة واحدة. إذا ظهر نموذج أفضل في الربع القادم، أو صدر runtime أرخص في العام القادم، يمكنك التبديل. يحتفظ العميل بحرية الاختيار، وتحتفظ أنت بالتخصص الذي يعمل على أي stack. ويجب ذكر مقايضة صريحة: FDE التابع للمورد مدعوم بشدة، وأحياناً يكون مجانياً، لأن المورد يسترد ذلك عبر الارتهان؛ أما FDE المحايد تجاه الموردين فيدفع له العميل أو شركة مستقلة. هذه ميزة، لا عيب: فالعميل يشتري الاختيار الآن بدلاً من دفع تكاليف التبديل لاحقاً.
هذا هو الدور الثاني الذي لا يكاد أحد غير هذا الكتاب يدرّب عليه. والدقة هنا مهمة: ما يدرّب عليه الكتاب هو النواة التقنية لـ FDE المحايد تجاه الموردين، أي النصف الذي لا يجده السوق. أما النصف الآخر، اكتشاف العميل، وترتيب الأولويات، وتأطير ROI، والانضباط اللازم لرفض طلب غير واقعي، فينتمي إلى مسار Certified Agentic AI Business Strategist. يدرّب على النواة التقنية؛ وتعيش طبقة الاستشارة في مسار Strategist.
الأدوار المساندة
يحتاج كل مسار إلى أشخاص يراجعون العمل، ويضعون القواعد، ويتحملون المسؤولية. هذه الأدوار الثلاثة تفعل ذلك.
Evals Engineer: الشخص الذي يختبر AI Workers بقسوة قبل دخولها الإنتاج. لن تشحن سيارة من دون اختبار تصادم. ولن تطلق دواءً من دون تجارب سريرية. ويحتاج AI Worker الذي يتخذ قرارات تؤثر في أشخاص حقيقيين وأموال حقيقية إلى الانضباط نفسه. يصمم Evals Engineer هذه الاختبارات: هل يعطي Worker الإجابة الصحيحة؟ هل يفشل بأناقة حين يرى شيئاً لم يره من قبل؟ هل يبقى داخل الحدود التي أُعطيت له؟ هذا ليس فكرة لاحقة تُثبت في النهاية. إنه مدمج في كل فصل. منهج أساسي، لا إضافة.
AI Governance Officer: يقرر ما يُسمح للذكاء الاصطناعي بفعله. لكل موظف في الشركة حدود. يستطيع محاسب مبتدئ اعتماد مصروفات حتى 500 دولار، لكنه يحتاج إلى توقيع مدير فوق ذلك. ويستطيع صرّاف مصرفي معالجة إيداع، لكنه لا يستطيع اعتماد قرض. يحتاج AI Workers إلى البنية نفسها. يكتب Governance Officer هذه القواعد على مستوى الشركة: ما الذي يستطيع الذكاء الاصطناعي أن يقرره وحده، وما الذي يجب أن يذهب إلى إنسان للموافقة، وما الذي يجب ألا يلمسه أبداً. ويتولى أيضاً مواءمة ذلك مع القوانين التي يجب على الشركة اتباعها: قواعد الإقراض العادل في بنك، وخصوصية المرضى في مستشفى، وقوانين إقامة البيانات في أوروبا. يبني AI-Native Company Architect النظام الذي يفرض هذه القواعد؛ ويقرر Governance Officer ما يجب أن تقوله القواعد. يدرّب الكتاب على انضباط إطار الحوكمة مباشرةً؛ أما لوائح صناعتك الخاصة فهي المدخلات التي تقدمها أنت. يدرّب على إطار الحوكمة؛ وقواعد ولايتك القضائية عليك أنت تقديمها.
Digital FTE Supervisor: الإنسان الذي يقع اسمه على خط المسؤولية. حين يعالج AI Worker مطالبة، أو يصوغ عقداً، أو يعلّم معاملة، يجب أن يكون هناك شخص مسؤول. هذا هو Supervisor. إنه الإنسان داخل الحلقة: المراجع الذي يفحص العمل، والمدير الذي يوافق على المخرج، والاسم الذي يشير إليه أثر التدقيق حين يحدث خطأ. هذا ليس الشخص الذي بنى Worker. إنه الشخص الذي يشغّله يومياً، كما يدير مشرف الوردية فريقاً. يدرّب عليه.
حيث يتوقف الكتاب عمداً
LLMOps Engineer: حتى النموذج، لا النموذج نفسه. تشغيل الوكلاء في الإنتاج هو عمل Cloud AI Engineer، ويدرّب عليه الكتاب. ويدرّب الكتاب أيضاً على الضبط الدقيق عملياً، لكن كملاذ أخير لا كخيار افتراضي. يربط الضبط الدقيق نظامك بلقطة نموذج واحدة ويكلّفك المرونة التي يحميها المنهج كله، لذلك لا تلجأ إليه إلا عندما تقصر التعليمات والسياق والأدوات والاسترجاع فعلاً. أما الحد الصارم فهو بناء النموذج نفسه: يبقى التدريب المسبق لنموذج أساسي من الصفر خارج النطاق، لأن هذه القدرة تتحول إلى سلعة عامة. يدرّب على الضبط الدقيق والعمليات حول النموذج، لا على بناء النماذج الأساسية.
Harness Engineer: runtime الذي تستخدمه، لا الذي تبنيه. Harness هو runtime الوكيل، مثل OpenAI Agents SDK ووكلاء Claude المُدارين وما شابه، وهو الذي يشغّل حلقة الوكيل ويدير الحالة وينفذ استدعاءات الأدوات. يدرّبك الكتاب على استخدام هذه الأشياء بطلاقة والبقاء قابلاً للنقل بينها، لأن تخصصك يبقى بعد أي runtime يفوز. بناء runtime نفسه ليس الوظيفة. يدرّب المشغّل الذي يستخدم أي runtime، لا المهندس الذي يبنيه.
AI Data Engineer: طبقة البيانات المواجهة للوكيل. يلامس عمل system of record طبقة البيانات المواجهة للوكيل: Postgres وpgvector وMCP بوصفها العمود الذي يقرأ منه الوكيل. أما هندسة المسارات والمستودعات التقليدية للبيانات فهي مجاورة، لا مركزية. يدرّب على طبقة البيانات المواجهة للوكيل، لا هندسة البيانات العامة.
النمط هو الدليل. يفتح عصر الوكلاء العمل إلى أدوار كثيرة، لا دور واحد: بناء Workers، وتشغيلها وحكمها، وتعليمها الحكم المهني. الخريطة هي المقصود: اعرف أين تقف الآن، وإلى أي مدى يحملك هذا الكتاب من هناك.