في يناير 2026، خلال منتدى دافوس الاقتصادي العالمي، ألقى داريو أمودي، الرئيس التنفيذي لشركة Anthropic، جملةً قصيرة في حوار أجرته معه رئيسة تحرير صحيفة وول ستريت جورنال إيما تاكر.

قال إن البرمجيات ستصبح “رخيصة”، وربما “مجانية في جوهرها”. ما يعني أن الفرضية الأساسية لنموذج البرمجيات كخدمة — استرداد تكاليف التطوير بتوزيعها على ملايين المستخدمين — قد لا تنطبق بعد الآن.

(الاقتباس الأصلي بالإنجليزية: “Software is going to become cheap, maybe essentially free” — «ستصبح البرمجيات رخيصة، وربما مجانية في جوهرها» — مقابلة WSJ/دافوس، يناير 2026)

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

في السياق ذاته، قال أمودي شيئاً آخر: إن الذكاء الاصطناعي سيضغط 100 عام من التغيير الاقتصادي في غضون 5 إلى 10 سنوات، وقد يكون الصدى “مؤلماً بشكل غير اعتيادي” (unusually painful). (CNBC، 27 يناير 2026)

مستقبل فرق الهندسة معلّق بين هذين التصريحين.

ماذا يحدث حين تقترب التكلفة الحدية من الصفر

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

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

البوادر موجودة بالفعل. أدوات مثل GitHub Copilot وCursor وClaude Code تخفض بسرعة تكلفة توليد الكود. بناء هياكل تطبيقات CRUD، وكتابة الاختبارات، واستخراج التوثيق — المهام المتكررة تزداد رخصاً يوماً بعد يوم.

حين تتقارب هذه التكاليف مع الصفر، أين تبقى الميزة التنافسية لما يبنيه المهندسون؟

ليس في القدرة على كتابة الكود. بل في القدرة على الحكم على ما يجب كتابته. هناك تبقى.

لماذا تغيّر موقف أمودي؟

يستحق الأمر الإشارة إلى أن تصريحات أمودي نفسها تحولت بشكل ملحوظ في غضون أشهر قليلة.

في مقالة على CNBC في يناير 2026، حذّر من أن صدمة سوق العمل ستكون “مؤلمة بشكل غير اعتيادي”. ثم في مايو 2026، وقبيل الطرح العام الأولي لـ Anthropic، أزاح ثقله نحو مفهوم “التعزيز” (augmentation). نقلت مجلة Fortune هذا التحول باعتباره تراجعاً عن نبوءات “نهاية الوظائف بسبب الذكاء الاصطناعي” (walking back). (Fortune، 26 مايو 2026)

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

في مقابلة مايو قال أيضاً: “there are jobs that took generations to build that may disappear” («ثمة وظائف استغرق بناؤها أجيالاً قد تختفي»). لم يكن هذا تحذيراً من فقدان الوظائف بل من اختفاء هياكل المسارات المهنية بأكملها.

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

ما يختفي وما يبقى

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

حتى مع انخفاض تكاليف توليد الكود، ثمة قيمة لا تختفي. ثلاث فئات تبرز:

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

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

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

ما الذي يحدث اقتصادياً

حين تتحرك منحنى العرض للبرمجيات نحو الأسفل، يحدث شيء مفارق.

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

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

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

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

الانتقال سيكون مؤلماً. حين قال أمودي في يناير إنه سيكون “مؤلماً بشكل غير اعتيادي”، كان يتحدث عن سرعة الانتقال. إذا استغرقت الثورة الصناعية عقوداً، فقد يحدث هذا الانتقال في بضع سنوات. وقد لا يتوفر الوقت الكافي لإعادة التدريب.

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

ما الذي يتغير لفرق الهندسة والمنظمات

هذه ليست مسألة فردية فحسب؛ إنها أيضاً مسألة كيفية بناء المنظمات.

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

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

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

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

منظور ثاكي كلاود: ما تقوله البنية التحتية

تبني شركة ThakiCloud بنية تحتية لتطوير البرمجيات بالذكاء الاصطناعي. إذا كانت نبوءة أمودي صحيحة، فإن معنى ما نبنيه يتغير هو الآخر.

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

بالنسبة لفريقنا، تصريحات أمودي هي تحذير واتجاه في آنٍ معاً. تحذير: بعض ما كان ذا قيمة حتى الآن سيفقد قيمته بسرعة. اتجاه: إذا كانت قيمتك مستمدة من التنفيذ المتكرر، فعليك الانتقال نحو الحكم والتصميم.

الخلاصة: حين يتقلص نصف عمر الخبرة

كون البرمجيات مجانية لا يعني أن صانعيها مجانيون. تكلفة توليد الكود تنخفض؛ قيمة الحكم المطلوب لبناء برمجيات جيدة لا تنخفض.

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

الجوهر في ذلك الدور شيء واحد: القدرة على الحكم على ما يجب بناؤه ولماذا. هذا شيء لا يستطيع محرر الكود إخبارك به.

هوية المهندس تنتقل من “شخص يكتب الكود” إلى “شخص يرى المشكلات”. الهوة بين الفرق التي تدرك هذا الانتقال وتستعد له وتلك التي لا تفعل ستظهر في غضون سنوات قليلة.

المصادر

• داريو أمودي / Anthropic، مقابلة WSJ-دافوس، يناير 2026 — «ستصبح البرمجيات مجانية في جوهرها»: تغطية The News.com.pk
• داريو أمودي، CNBC، 27 يناير 2026 — تحذير من صدمة وظيفية “مؤلمة بشكل غير اعتيادي”: النص الأصلي على CNBC
• داريو أمودي، مقابلة مايو 2026 — “ثمة وظائف استغرق بناؤها أجيالاً قد تختفي”: X @AnatoliKopadze RT (2026-05-26)
• Fortune، 26 مايو 2026 — تقرير عن تليين موقف أمودي: النص الأصلي على Fortune

في ربيع عام 2026، انتشر تقييم لافت في أوساط مستثمري التقنية: “ربما يكون جنسن هوانغ أبرع منتقي الأسهم في وول ستريت — حتى وإن لم ينتقِ سهماً بنفسه”. لم تكن هذه العبارة من تصريح هوانغ ذاته؛ بل كانت لقباً أطلقه مراقبو السوق من خارجه.

وكانت الأدلة محددة. الشركات التي ذكرها هوانغ في مناسباته العامة وكلماته الرئيسية — Nebius (إيرادات ارتفعت 840%)، وApplied Digital (1,400%)، وTSMC (135%)، وMicron (770%) — قفزت أسهمها بعد تصريحاته، دون أن يقول مرة واحدة “اشتروا هذه الشركة”.

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

هذه هي نقطة انطلاق هذا المقال: جوهر الحكم المتميز الذي يبدو حدسياً هو تهيكل البيانات.

وراثة Moneyball: هل انتهى عصر الحدس؟

في مقالنا السابق (بناء ثقافة تنظيمية قائمة على البيانات بتفكير Moneyball)، أوردنا قصة فريق أوكلاند أتلتيكس عام 2002. استخرج بيلي بين المؤشر المهمَل — نسبة الوصول إلى القاعدة — وحقق 103 انتصارات بثلث ميزانية الفريق المعتادة.

ارتكز ذلك المقال على مقدمتين أساسيتين: المقاييس التي تستخدمها الآن ربما تكون خاطئة؛ والموارد المقيَّمة بأقل من قيمتها التي تكتشفها عبر البيانات تمنحك أقصى كفاءة.

في زمن الذكاء الاصطناعي اليوم، تعود هاتان المقدمتان في صورة سؤال أكثر حدة: إلى أين تراجع الحدس؟

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

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

إذن كيف يجب أن تتغير بنية صنع القرار في المنظمة؟

قِس قراراتك: تحويل القرارات إلى بيانات

جوهر تفكير Moneyball ليس تغيير مؤشرات الأداء. بل هو جعل القرارات ذاتها قابلة للقياس.

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

صنع القرار التنظيمي يتبع البنية ذاتها.

كيف تميز القرار الجيد من القرار السيئ؟

في معظم المنظمات، يُقيَّم جودة القرار بالاستنتاج العكسي من النتائج: إن سارت الأمور حسناً فالقرار كان جيداً، وإن ساءت فهو كان سيئاً. غير أن هذا المنهج يحمل مشكلتين.

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

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

تبدأ ثقافة القرار القائمة على البيانات من تسجيل المبررات وقت اتخاذ القرار وتقييمها، لا من النتيجة.

سجل القرارات: أثر تدقيقي للحكم

نقطة البدء هي التسجيل الصريح لثلاثة عناصر لحظة اتخاذ القرار:

• ما الافتراضات التي يقوم عليها هذا القرار؟
• ما البيانات التي تدعم تلك الافتراضات؟
• كيف سنعرف أن هذا القرار كان خاطئاً؟ (شرط التفنيد)

السؤال الثالث هو المحوري. عبارة “هذه الميزة ستزيد الاحتفاظ بالمستخدمين 5%” لا يمكن التحقق منها كما هي. لكن إذا كتبت: “إذا لم يرتفع معدل الاحتفاظ خلال سبعة أيام بنسبة 5% على الأقل خلال ثمانية أسابيع من الإطلاق، فإن هذا الافتراض خاطئ” — يصبح القرار قابلاً للقياس.

في كلمة GTC Taipei 2026، كشفت NVIDIA عن نموذج يخصص جزءاً من الراتب الأساسي للمهندسين كميزانية للرموز الحسابية لقياس الإنتاجية. ليس هذا مجرد تغيير في بنية التعويض؛ بل إعلان عن قياس فعلي لنتائج قرارات استخدام أدوات الذكاء الاصطناعي. لا تتعلم المنظمات إلا حين يمكن تتبع القرارات بالأرقام.

حيث ينتصر الحدس: حدود البيانات

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

حيث تكون البيانات في أوج قوتها

في القرارات ذات الأنماط القابلة للتكرار، تطغى البيانات على الحدس:

• التوقعات ذات السجل التاريخي الكافي (معدلات التحويل، ومعدلات التراجع، وتوقعات الطلب)
• التجارب ذات مؤشرات النجاح الواضحة (اختبارات A/B، وعلامات الميزات)
• استخراج الإشارات من البيانات الضخمة (تقسيم المستخدمين، وكشف الشذوذ)

الحدس لا يتفوق هنا على البيانات. حتى مدير المنتج الخبير حين يقول “المستخدمون سيحبون هذه الميزة” يخطئ عند التجريب بوتيرة أعلى مما يتوقع. ما تُبلغ عنه شركات التقنية الكبرى بشكل مشترك من تجارب A/B هو أن ميزات اعتُبرت “مضمونة” داخلياً كثيراً ما خيّبت التوقعات في التجارب الفعلية.

حيث لا يزال الحدس ضرورياً

المجال الذي تضعف فيه البيانات هو الحالات التي لا سابقة لها.

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

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

فخ مسرح البيانات

ثمة فخ آخر يجب التحذير منه: نمط الظهور باستخدام البيانات بينما يجري في الواقع انتقاء بيانات تدعم نتيجة توصل إليها الشخص مسبقاً — يُعرَّف هذا بـ”مسرح البيانات”.

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

مسرح البيانات أشد خطورة من الحدس المجرد لسبب وجيه: حين يخطئ الحدس، يمكن الاعتراف بأن “حكمي كان خاطئاً”. لكن حين يخفق مسرح البيانات، تلجأ المنظمة إلى الدفاع بأن “البيانات التي رأيناها كانت معيبة”، فيُحجب التعلم.

الشروط التي تتغلب فيها البيانات على الحدس في المنظمة

حتى حين تتوفر بيانات جيدة، كثيراً ما تظل قرارات المنظمة دون تغيير. تغلّب البيانات على الحدس ليس مسألة تقنية — بل مسألة ثقافة وبنية.

الشرط الأول: أن يكون التفنيد آمناً

تحتاج إلى بيئة يمكن فيها قول: “هذه البيانات تدحض فرضيتنا.”

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

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

الشرط الثاني: أن تكون وحدة القرار صغيرة

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

تفتيت القرارات هو البنية العملية الحقيقية للثقافة القائمة على البيانات. “هل نطور هذه الميزة لثلاثة أشهر؟” سؤال أدنى من “هل يمكننا في أسبوعين التحقق من الافتراض الجوهري بنموذج أولي؟” القرارات الصغيرة تُتيح التعلم السريع وتُمكّن البيانات من تغيير الاتجاه فعلاً.

تتعمق هنا الفكرة التي طرحناها في مقال Moneyball: “الفريق الذي يستغرق ثلاثة أسابيع لإجراء اختبار A/B مقابل فريق يستغرق ثلاثة أيام سيتفاوت تعلّمُهما عشرة أضعاف بعد عام.” الفارق في سرعة التعلم ليس فارقاً في كمية البيانات، بل هو فارق في حجم وحدة القرار وتكرارها.

الشرط الثالث: أن تكون القرارات الماضية قابلة للتتبع

يجب أن تكون قادراً على الإجابة عن “لماذا أسفر الأمر عن هذه النتيجة؟”

في كثير من المنظمات، تضيع مبررات القرارات المهمة. من كان في الاجتماع يغادر الشركة، وتُؤرشَف قنوات Slack، ولا تُحفظ البيانات من تلك اللحظة. يرى الأعضاء الجدد نتيجة القرار فحسب دون أن يعرفوا لماذا اتُخذ.

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

عملاء الذكاء الاصطناعي والتحول في بنية صنع القرار

قال هوانغ في كلمة GTC Taipei 2026: “كل مهندس سيمتلك مئات العملاء ويُديرهم.” هذا ليس مجرد تغيير في الأدوات؛ إنه تغيير في البنية الجوهرية لصنع القرار.

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

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

كما بنى بول ديبوديستا النماذج الإحصائية في Moneyball، يجب على المنظمات التي تُشغّل العملاء أن تصمم بشكل صريح أي القرارات يُفوَّض للعملاء وعلى أي أساس تُوثق الثقة في تلك القرارات.

تداعيات على المنظمة: ثلاث خطوات قابلة للتطبيق

ثقافة القرار القائمة على البيانات ليست بناء لوحات متابعة أكثر. إنها تغيير في بنية القرارات.

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

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

ثالثاً، صمّم قرارات العملاء بحيث تكون قابلة للمراجعة. تحتاج إلى بنية يمكن فيها الإجابة لاحقاً عن “على أي بيانات استند هذا العميل في هذا الحكم؟” في اللحظة التي يصبح فيها تفكير العميل صندوقاً أسود، تكف تلك المنظمة عن كونها قائمة على البيانات وترجع إلى حدس قائم على العملاء.

يمكن قراءة عمل ThakiCloud في بناء بنية تحتية لجدولة العملاء القائمة على Kueue في هذا السياق. كيف يوزع العملاء الأعباء التشغيلية، وهل يظل مبرر ذلك القرار محفوظاً في سجلات — هذا هو أساس الثقة بالمنصة.

خلاصة: الحدس لا يختفي، بل يجد مكاناً جديداً

سؤال “إذا كان الذكاء الاصطناعي أفضل صانع قرار” ينطلق من مقدمة خاطئة. ثمة قرارات يتفوق فيها الذكاء الاصطناعي والبيانات، وقرارات يتفوق فيها الحكم الإنساني والخبرة. المهم ليس أيهما أفضل مطلقاً، بل تصميم مَن يتخذ كل قرار وفق طبيعة ذلك القرار.

بيلي بين في Moneyball لم يتخلَّ عن حدس الكشافين. ظل الحكم الإنساني ضرورياً لما لا تفسره البيانات — روح اللاعب، وتناغم الفريق، والتمركز في أسواق جديدة. ما بناه لم يكن “منظمة أزالت الحدس” بل “منظمة أوضحت أين ينبغي للحدس أن يتدخل”.

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

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

المصادر

• Jensen Huang, “Every engineer is going to have and manage hundreds of agents.” — كلمة NVIDIA GTC Taipei 2026، 2026-05-20 / 2026-06-01. مدونة NVIDIA الرسمية: https://blogs.nvidia.com/blog/nvidia-gtc-taipei-computex-2026-news/
• “Jensen Huang might be the best stock picker on Wall Street and he does not even pick stocks.” — تقييم خارجي من مراقبي السوق (ليس تصريحاً لهوانغ نفسه). سلسلة تغريدات @InTheAssembly على X: https://x.com/InTheAssembly/status/2053801122632958342
• Jensen Huang، تصريحات عن ميزانية الرموز الحسابية لمهندسي NVIDIA — نسخة كلمة GTC Taipei Computex 2026. Semiconalpha Substack: https://semiconalpha.substack.com/p/nvidia-keynote-computex-2026-key
• بيانات أسعار أسهم Nebius وApplied Digital وTSMC وMicron — سلسلة تغريدات @InTheAssembly على X (نفس المصدر أعلاه)
• مدونة ThakiCloud، “بناء ثقافة تنظيمية قائمة على البيانات بتفكير Moneyball” (المقال الأصل الذي يتابعه هذا): https://thakicloud.github.io/culture/moneyball-data-driven-culture/

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

لكن هاسابيس قال غير ذلك.

“أنظمة اليوم ليست قريبة على الإطلاق من [الذكاء الاصطناعي العام]. لا يهم كم مسألة من مسائل إيردوش تحلّ.” (النص الأصلي بالإنجليزية: “Today’s systems are nowhere near [AGI]” — Fortune، 23 يناير 2026)

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

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

الخط الذي رسمه هاسابيس: “الفهم” مقابل “مطابقة الأنماط”

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

فأين تقف النماذج اللغوية الكبيرة اليوم؟ مهما اتسع نطاق بيانات التدريب واتقن النموذج محاكاة الاستدلال، يبقى السؤال مفتوحًا: هل هذا “فهم” أم “إعادة إنتاج أنماط إحصائية”؟ وقد قال هاسابيس نفسه في الجلسة ذاتها بدافوس: “لا يزال ثمة حاجة لاختراق أو اثنين”. وكان تقديره الزمني حينئذ “5 إلى 10 سنوات”.

لكن القصة لم تنتهِ عند هذا الحد.

تغيّر في الجدول الزمني خلال أربعة أشهر: الاستخدام المتعمد للغة الاستفزازية

بعد نحو أربعة أشهر من تصريحات دافوس، وتحديدًا في 26 مايو 2026، وفي مقابلة مع Axios عقب مؤتمر Google I/O، تحدّث هاسابيس بنبرة مختلفة، مشيرًا إلى أن “الذكاء الاصطناعي العام سيتحقق على الأرجح في غضون السنوات الخمس المقبلة”. لخّص بعض المنابر هذا القول بـ”الذكاء الاصطناعي العام خلال 3 إلى 4 سنوات”، وانتشر التصريح على نطاق واسع.

بيد أن هاسابيس أضاف في المقابلة ذاتها: “بعض المصطلحات التي استخدمتها كانت استفزازية بعض الشيء عمدًا.” (النص الأصلي: “some of the terms I used were a little bit provocative” — Axios، 2026-05-26)

التصريح الحذر في يناير، والجدول الزمني المُقدَّم في مايو. الشخص نفسه، في العام نفسه، في سياقين مختلفين. فأيهما يعكس الفكر “الحقيقي” لهاسابيس؟

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

الندوب التي تتركها دورة الضجيج في المنظمات

يتسم قطاع الذكاء الاصطناعي بسرعة استثنائية في دورات المبالغة. دون الحاجة إلى مراجعة دورة ضجيج غارتنر، يكفيك أن تتذكر كم مرة تكررت عبارة “هذه المرة مختلفة” خلال العقد الماضي: ثورة التعلم العميق، عصر روبوتات المحادثة، GPT-3، ChatGPT، الذكاء الاصطناعي الوكيل… في كل دورة، تستثمر المنظمات في حالة الحماس، تصطدم بجدار الواقع، تشعر بخيبة الأمل، ثم تنتظر الموجة التالية.

يترك هذا النمط ثلاثة أنواع من الندوب في المنظمات.

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

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

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

ما يمارسه هاسابيس: فلسفة خارطة الطريق

تكشف مسيرة DeepMind عن كيفية تطبيق إدارة التوقعات فعليًا.

استهدف AlphaGo (2016) مشكلة محددة بوضوح: لعبة الغو. وحلّ AlphaFold (2020) مشكلة علمية قابلة للتحقق: التنبؤ بتراكيب البروتين. أما الذكاء الاصطناعي العام فهو بالنسبة لهاسابيس تحدٍّ مستقبلي لا يزال يستلزم “اختراقًا أو اثنين”.

النمط في هذه الخارطة ثابت: تُحدَّد أهداف بلوغها ممكن بالقدرات الراهنة، تُحقَّق فعلًا، ثم يُستعد للمرحلة التالية. بدلًا من شعار “الذكاء الاصطناعي العام في خمس سنوات”، يُطرح السؤال: “ماذا سنُثبت في هذه المرحلة؟”

لا ينبغي قراءة هذا على أنه تحفظ أو جبن. أن يعترف هاسابيس في مايو 2026 بأنه “استخدم عن قصد بعض المصطلحات الاستفزازية” يدل أيضًا على أنه يعرف قيمة اللغة الطموحة في رفع سقف التوقعات. المفتاح هو كلمة “عن قصد”: فهو يعرف تمامًا أين تنتهي اليقينيات وأين تبدأ الاستفزازات المدروسة.

ما معنى ثقافة إدارة التوقعات؟

في منظمات الذكاء الاصطناعي، كثيرًا ما يبدو “إدارة التوقعات” مصطلحًا سلبيًا، يُفهم خطأً على أنه موقف دفاعي من قبيل “خفّض توقعاتك” أو “اِستبق خيبة الأمل”. نهج هاسابيس ليس كذلك على الإطلاق.

تتلخص إدارة التوقعات الصادقة في ثلاثة محاور.

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

ثانيًا: حدّد معايير النجاح بصورة قابلة للقياس. هدف “تحسين الكفاءة التشغيلية عبر الذكاء الاصطناعي” لا يتيح معرفة ما إذا تحقق النجاح. أما هدف “تقليص وقت معالجة المهمة X بنسبة 30% بعد ستة أشهر من تبني الذكاء الاصطناعي” فله إجابة واضحة. وكما قاست AlphaFold دقة التنبؤ بالبروتين رقميًا قياسًا بأفضل ما سبقها، كذلك ينبغي لمشاريع الذكاء الاصطناعي.

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

كيف تكسر دورة خيبة الأمل؟

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

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

هذا لا يعني “فكّر بأفق محدود”. DeepMind بدأت بـAlphaGo وأنتجت AlphaFold، وهي الآن في طريقها نحو الذكاء الاصطناعي العام. الهدف كبير، لكن كل مرحلة مصممة بواقعية.

المنظمات التي تنجح في هذا النهج تشترك في عادة واحدة: حين تشرع في مبادرة ذكاء اصطناعي جديدة، تسأل أولًا: “كيف يبدو النجاح في هذه المرحلة؟” وبعد ستة أشهر تتحقق من إمكانية الإجابة على هذا السؤال. وحين تقصر عن التوقعات، تسجّل “لماذا جاء الواقع مختلفًا؟” ويجعل ذلك التسجيل توقعات المشروع التالي أكثر واقعية.

ما يعنيه هذا للمنظمات: اجعل الواقعية نظامًا

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

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

من الممارسات التي نجرّبها: في بداية كل مشروع، نكتب صراحةً قائمة بـ”ما لن نحققه في هذه المرحلة”، لا قائمة ما سنفعله فحسب. علّمتنا التجربة أن قائمة “ما لن نفعله” أكثر فاعلية في مواءمة التوقعات مع الواقع من قائمة “ما سنفعله”.

أن يستطيع هاسابيس القول “أنظمة اليوم ليست قريبة على الإطلاق من الذكاء الاصطناعي العام” لا يعني أنه متشائم حيال مستقبل الذكاء الاصطناعي. فهو الشخص الذي أعاد رسم خريطة علم الأحياء بفضل AlphaFold. التصريح الصريح بحدود الأنظمة الراهنة هو في حقيقته تحديد اتجاه نحو الاختراق التالي.

الواقعية ليست تخليًا عن الحلم، بل قياس المسافة إليه بدقة.

خاتمة: الصدق أقوى الأصول الثقافية

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

أصعب شيء هو القول، وسط كل هذا الحماس: “لكن هذا لم يصبح ممكنًا بعد”.

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

حين يعمل هذان الموقفان معًا، تتراكم ثقة المنظمة. الصراحة في التعبير عن الحدود. الاعتراف حين تتجاوز في التعبير. التراكم التدريجي للصدق أصل ثقافي أعمق بكثير من الاهتمام الآني الذي تجنيه من مبالغة واحدة.

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

المصادر

• Fortune (2026-01-23): “DeepMind’s Demis Hassabis, Anthropic’s Dario Amodei, Yann LeCun at AI Davos” — https://fortune.com/2026/01/23/deepmind-demis-hassabis-anthropic-dario-amodei-yann-lecun-ai-davos/
• WEF Radio Davos Podcast (2026-01): “AI & AGI — Dario Amodei, Demis Hassabis” — https://www.weforum.org/podcasts/radio-davos/episodes/ai-agi-dario-amodei-demis-hassabis/
• Axios (2026-05-26): “DeepMind CEO Demis Hassabis on AGI timeline” — https://www.axios.com/2026/05/26/deepmind-ceo-demis-hassabis
• Sherwood News: “Google DeepMind’s Hassabis: AGI is 3 to 4 years away” — https://sherwood.news/tech/google-deepminds-hassabis-agi-is-3-to-4-years-away/
• CryptoBriefing: “DeepMind Hassabis AGI Einstein Test” — https://cryptobriefing.com/deepmind-hassabis-agi-einstein-test/

في مايو ويونيو من عام 2026، كرّر جنسن هوانغ الرسالة ذاتها من على مسارح Computex وGTC Taipei: “Every engineer is going to have and manage hundreds of agents” (كل مهندس سيمتلك مئات الوكلاء ويديرهم). لمن اعتقد أن كتابة الكود مباشرةً هي جوهر عمل المهندس، فإن هذا الإعلان يمسّ أسس مسيرته المهنية.

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

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

الوحدة التنظيمية الجديدة: 100 إلى 1

في مقابلة مع مجلة Fortune في مارس 2026، وضع جنسن هوانغ أرقاماً محددة على رؤيته. تستعد NVIDIA لمستقبل تتعايش فيه 7.5 مليون وكيل ذكاء اصطناعي مع 75,000 موظف. بحساب بسيط: 100 وكيل لكل إنسان.

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

من منظور تصميم التنظيمات، هذا ليس مجرد تحسين للإنتاجية — إنه يُزعزع بنية الإدارة ذاتها. كانت الفرق التقليدية تُبنى وفق عدد الأفراد، وكان القادة يُحقّقون النتائج بإدارة الناس. لكن كيف يُدير مدير تقليدي مهندساً يُشغّل مئة وكيل؟ ربما لم يعد السؤال “ماذا أنجزت هذا الأسبوع؟” بل “ما الذي تعالجه وكلاؤك الآن؟”

ما معنى إدارة الوكلاء؟

في الفترة ذاتها، شرح هوانغ في تصريح آخر سبب عدم موت شركات البرمجيات: “AI agents still need an application layer to convert tokens into actual workflows” (وكلاء الذكاء الاصطناعي لا يزالون بحاجة إلى طبقة تطبيقية لتحويل الرموز إلى سير عمل فعلية). المنطق هو أنه كلما تكاثرت الوكلاء، ازدادت أهمية الطبقة التي تُنسّق بينها — أي قدرة التنسيق.

العمل الذي يتبقى بعد الأتمتة ليس التكراراً البسيط، بل الحكم والتنسيق. ماذا تُكلّف الوكيل؟ كيف تتحقق من نتائجه؟ بأي معيار تُحكّم حين يتعارض وكيلان؟ كل هذا يبقى من مهام الإنسان.

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

هذا يُغيّر معايير التوظيف والتقييم. “هل تُتقن Python؟” أصبح أقل أهمية من “كيف تكتشف خطأ الوكيل؟” ولا مبالغة في القول إن التوظيف على أساس طريقة التفكير لا على أساس المهارات التقنية قد بدأ بالفعل.

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

ما يحدث حين يُصبح نصف راتبك من رصيد الرموز (Tokens)

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

حتى الآن، كانت مقاييس قياس إنتاجية المطوّر ناقصة دائماً. عدد الـ commits وPRs وأسطر الكود لها صلة ضعيفة بالأثر الفعلي على الأعمال. مقاييس DORA (وتير النشر، وقت تحضير التغيير، وقت التعافي من الأعطال، معدل فشل التغيير) تُكمّل الصورة لكنها مؤشرات غير مباشرة.

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

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

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

حين يصبح المصنع روبوتاً: التداعيات التنظيمية

في مقابلة مع Fortune في مايو 2026، وسّع هوانغ نظرته إلى العالم المادي: عالم تُديره الوكلاء، وتديره روبوتات أكثر، ويُصبح فيه المصنع بأكمله روبوتاً واحداً. هذا ليس خيالاً علمياً — إنه جارٍ بالفعل في مصانع أشباه الموصلات ومستودعات الخدمات اللوجستية.

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

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

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

تظهر هذه المسألة خارج فرق البرمجيات أيضاً في وحدات تنظيمية أوسع. حين يقترح وكيل مبيعات على عميل سعراً خاطئاً، أو حين يُفسّر وكيل قانوني عقداً نمطياً بشكل خاطئ ويُرشد أحداً للتوقيع — هذه سيناريوهات بات فيها “خطأ الوكيل” خطراً على الشركة. لهذا فإن تبني الوكلاء هو قرار تقني وقرار حوكمة في آنٍ معاً. تحديد أيّ وكلاء تمنح أيّ صلاحيات، وأيّ مهام يجب أن يُؤكّدها إنسان دائماً، ليس قرار CTO وحده — يجب أن يكون قرار الفريق التنفيذي بأكمله.

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

الخاتمة: ثلاثة أشياء يجب على المنظمات اكتسابها في عصر الوكلاء

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

ثلاثة أشياء يجب على المنظمات اكتسابها في عصر الوكلاء:

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

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

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

العالم الذي رسمه هوانغ لم يكتمل بعد. لكن ذلك الاتجاه في حركة بالفعل. يمكن شراء الأدوات، لكن لا يمكن استيراد الثقافة التي تُمكّن من استخدامها.

المصادر

• Jensen Huang, “Every engineer is going to have and manage hundreds of agents” — تصريحات خطاب GTC Taipei / Computex 2026. وردت في المدونة الرسمية لـ NVIDIA: NVIDIA GTC Taipei Computex 2026
• Jensen Huang, رؤية 75,000 موظف + 7.5 مليون وكيل ذكاء اصطناعي — Fortune, 2026-03-19: Jensen Huang on NVIDIA AI Agents Future of Work
• Jensen Huang, “operated by robots, managed by more robots” — Fortune, 2026-05-06: Agentic AI Robots
• Jensen Huang, “software companies aren’t dead because AI agents still need an application layer” — Yahoo Finance: NVIDIA CEO Jensen Huang AI Stock Boom
• Jensen Huang، هدف دفع نصف راتب المهندس كرصيد رموز — Semiconalpha Substack، نص خطاب GTC Taipei 2026: NVIDIA Keynote Computex 2026 Key

في يناير 2026 في المنتدى الاقتصادي العالمي بدافوس، جلس شخصان من صناعة الذكاء الاصطناعي على طاولة النقاش ذاتها: ديميس هاسابيس من Google DeepMind وداريو أموداي من Anthropic. المقاعد كانت واحدة، لكن الكلمات كانت مختلفة تماماً. كان هاسابيس صريحاً: “الأنظمة اليوم ليست قريبة من الذكاء الاصطناعي العام إطلاقاً. حل بعض مسائل إردوش الرياضية العسيرة لا يغيّر ذلك” (Fortune، 2026-01-23). أما أموداي، فقد حذّر في مقال نشره قبل أيام من أن مئة عام من التغيير الاقتصادي ستنضغط في 5 إلى 10 سنوات (CNBC، 2026-01-27).

أما جنسن هوانغ، فكان على مسرح GTC يتحدث عن شيء مختلف كلياً — ليس عن جداول زمنية للذكاء الاصطناعي العام، بل عن البنية التحتية والوكلاء الآن وفي اللحظة الراهنة. صورة من 75,000 موظف في NVIDIA يعملون جنباً إلى جنب مع 7.5 مليون وكيل ذكاء اصطناعي؛ مهندس واحد يدير مئات الوكلاء (Fortune، 2026-03-19؛ المدونة الرسمية لـ NVIDIA GTC Taipei، 2026-06).

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

ديميس هاسابيس: بدون فهم حقيقي، لا يوجد ذكاء اصطناعي عام

يمكن تلخيص رؤية هاسابيس بكلمة واحدة: الفهم (understanding).

المثال الذي ضربه في دافوس في يناير 2026 كان بسيطاً. حل مسائل الأولمبياد الرياضي أو كسر معضلات نظرية الأعداد عند إردوش لا يؤهل نظاماً لأن يُسمى ذكاءً اصطناعياً عاماً. المعيار الحقيقي هو القدرة على اقتراح نظريات فيزيائية جديدة باستقلالية — ما يسميه “اختبار أينشتاين” (CryptoBriefing). وهو يرسم خطاً حاسماً بين مطابقة الأنماط والفهم الحقيقي.

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

في دافوس يناير 2026 قدّم 5 إلى 10 سنوات، قائلاً “لا يزال هناك حاجة إلى واحد أو اثنين من الاختراقات الجوهرية”. ثم بعد أربعة أشهر، في مقابلة Axios في مايو 2026، قدّم الجدول الزمني. ظهرت عبارة “الذكاء الاصطناعي العام آتٍ، ربما في غضون خمس سنوات”، مع اعترافه بأنه “تعمّد استخدام لغة استفزازية” (Axios، 2026-05-26). وفي الشهر ذاته، عند الإعلان عن Gemini Omni، كانت الكلمات التي اختارها “قفزة كبرى في فهم العالم” (major leap in world understanding).

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

جنسن هوانغ: متفائل بالبنية التحتية يتحاشى جدل الذكاء الاصطناعي العام

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

في مقابلة Fortune في مارس 2026، قدّم هوانغ صورة من 75,000 موظف في NVIDIA يعملون جنباً إلى جنب مع 7.5 مليون وكيل ذكاء اصطناعي — 100 وكيل لكل إنسان. وفي الخطاب الرئيسي لـ GTC Taipei في مايو من العام ذاته، قال: “كل مهندس سيُعيَّن ليدير مئات الوكلاء.” المنطق: الوظائف لا تختفي؛ إنها تتحول إلى دور توجيه الوكلاء.

ومن أبرز تصريحات هوانغ رده على ادعاء أموداي بـ”تحرير البرمجيات”. ففي يونيو 2026 قال: “شركات البرمجيات لن تموت، لأن وكلاء الذكاء الاصطناعي أيضاً بحاجة إلى طبقة تطبيقات لمعالجة الرموز المميزة في سير عمل فعلية وتنسيقها” (Yahoo Finance). قيمة البرمجيات لا تتلاشى — الطبقة هي التي تتغير.

ما يميّز عالم هوانغ هو طريقة القياس. في GTC Taipei في يونيو 2026، كشف عن خطة لتخصيص نصف الراتب الأساسي للمهندس كميزانية رموز مميزة (tokens) لتحقيق كفاءة عشرة أضعاف (Semiconalpha Substack، نسخة خطاب GTC Taipei الرئيسي). إنه إعلان لقياس الإنتاجية ليس بالحدس بل باستهلاك الرموز المميزة.

يركّز هوانغ على كيفية تغيير البنية التحتية للذكاء الاصطناعي للعالم الآن أكثر من توقيت وصول الذكاء الاصطناعي العام. اهتماماته تكمن في الأجهزة والمنصة، ومن هذا المنظور العالم يتغير بما يكفي بالفعل.

داريو أموداي: التغيير سريع والصدمة ستكون غير متساوية

أموداي هو الأكثر صراحةً بين الثلاثة في الحديث عن صدمة سوق العمل.

في مقال مطوّل يناهز 20,000 كلمة نشره في يناير 2026، حذّر من أن الذكاء الاصطناعي سيتسبب في اضطراب “مؤلم بشكل غير عادي” (“unusually painful”)، وأن مئة عام من التغيير الاقتصادي ستنضغط في 5 إلى 10 سنوات (CNBC، 2026-01-27). وفي مايو من العام ذاته قال إن “وظائف بُنيت عبر أجيال قد تختفي” — ليس مجرد وظائف فردية، بل مسارات مهنية كاملة قد تزول، وهو بُعد زمني أطول للصدمة.

مع تصاعد استعدادات Anthropic للطرح العام الأولي (IPO) في مايو 2026، خفّف أموداي نبرته بعض الشيء. ذكرت Fortune أنه انتقل إلى إطار “التعزيز” (augmentation) (Fortune، 2026-05-26)، مع التركيز على التعاون بدلاً من استبدال العمالة. هذا التحول في التوقيت يستحق الانتباه. المخاوف الهيكلية لم تختفِ؛ القراءة الأدق هي أن استراتيجية التواصل هي التي تغيّرت.

أكثر تصريحات أموداي استفزازاً تتعلق باقتصادات البرمجيات. “البرمجيات ستصبح مجانية في جوهرها. قد يتبيّن أن الافتراض القائل بضرورة توزيع تكاليف تطوير البرمجيات على ملايين المستخدمين هو افتراض خاطئ” (WSJ/Davos 2026، The News.com.pk). قضية تهزّ أساس نموذج البرمجيات كخدمة (SaaS)، وتصطدم مباشرةً بادعاء هوانغ “طبقة التطبيقات ستنجو”.

أموداي يقود منظمة تسعى في آنٍ واحد إلى سلامة الذكاء الاصطناعي وتحقيق التجاري. تحذيراته صادقة، لكن حدّتها يتم معايرتها وفقاً للجمهور والتوقيت.

مقارنة الرؤى الثلاث: إطار المحاور الثلاثة

بوضع وجهات النظر الثلاث على المحاور ذاتها:

شيء واحد يظهر من هذا الجدول: ثمة إمكانية أن يكون الثلاثة على حق في الوقت ذاته. كل منهم يصف وجهاً مختلفاً من الواقع ذاته. هاسابيس يرسي معياراً معرفياً، وهوانغ يشرح التحول الهيكلي الجاري، وأموداي يتحدث عن التكلفة الاجتماعية. إن كانت الرؤى الثلاث صحيحة في آنٍ واحد، فماذا ينبغي للمنظمات البانية أن تفعل؟

ما ينبغي للمنظمات البانية أن تأخذه من كل منهم

من هاسابيس: أسّس “معيار الفهم” داخل منظمتك

واقعية هاسابيس هي مرشّح لتنقية المبالغات حول الذكاء الاصطناعي العام. “اختبار أينشتاين” الذي يطرحه هو معيار يمكن تطبيقه داخل أي منظمة.

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

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

تحوّل هاسابيس في الجدول الزمني أيضاً يستحق المراجعة. الانتقال من “5–10 سنوات” في يناير إلى “ممكن في 5 سنوات” في مايو يعكس تحسناً فعلياً في القدرات لا انفعالاً بحمى السوق. بدلاً من مراقبة جدل الجداول الزمنية للذكاء الاصطناعي العام من بعيد، من الأجدى للمنظمات أن تضع معاييرها الخاصة وتعيد النظر فيها دورياً.

من هوانغ: ابنِ الكفاءة الجديدة لإدارة الوكلاء — الآن

أسرع ما تستطيع المنظمات البانية أخذه من رؤية هوانغ هو كفاءة تنسيق الوكلاء.

إن صحّت مقولة “كل مهندس سيدير مئات الوكلاء”، فإن الفجوة تتسع الآن بين المنظمات التي تبني هذه الكفاءة والمنظمات التي لا تفعل. مدى جودة توجيهك للوكلاء والتحقق منهم وتنسيقهم هو شكل جديد من الكفاءة التقنية.

اقتراح ميزانية الرموز المميزة (token budget) الذي طرحه هوانغ في GTC Taipei مثير للاهتمام من منظور الثقافة التنظيمية. إنه إعلان لقياس الإنتاجية ليس بالحدس أو الجهد المُدرَك، بل بيانات استخدام الذكاء الاصطناعي — عقلية Moneyball. المنظمات التي تقيّم المطورين بعدد الالتزامات (commits) أو ليالي العمل المتأخرة، في مقابل المنظمات التي تقيس كفاءة استخدام الذكاء الاصطناعي بالبيانات، ستكون في موقعين مختلفين تماماً بعد سنة أو سنتين.

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

من أموداي: واجه عدم تساوي الصدمة واستجب لها استباقياً

ما ينبغي للمنظمات البانية أن تأخذه من تحذيرات أموداي هو عادة إدراج بند التكاليف الاجتماعية في خارطة الطريق المتفائلة.

حتى بعد تخفيف نبرته في مايو، إن ظلّ “مسارات مهنية بُنيت عبر أجيال قد تختفي” سارياً، فإن المشكلة الأولى التي تواجهها المنظمات هي القلق من الأدوار داخل الفريق. كلما تسارع تبني الذكاء الاصطناعي، تحوّل سؤال “هل سيُستبدل دوري؟” من قلق فردي إلى مشكلة إنتاجية تنظيمية.

الاستجابة الاستباقية تسير في اتجاهين. الأول: إعادة التدريب — تنسيق الوكلاء، التحقق من جودة الذكاء الاصطناعي، التعمق في المجالات التي تستلزم الحكم الإنساني. الثاني: تحديد الحدود — حين تعرّف منظمة ما علناً “ما يستبدله الذكاء الاصطناعي” و”ما يعززه الذكاء الاصطناعي”، يفسح القلق المجال لإعادة تصميم الأدوار.

أن يُخفّف أموداي مستوى الإنذار خلال استعدادات الطرح العام هو تغيير في استراتيجية التواصل الخارجي. ينبغي للمنظمات البانية أن تتخذ التحذير ذاته — لا الاستراتيجية — معياراً لقرارها الداخلي. منظمة لديها خطط توظيف متفائلة ولا ميزانية لإعادة التدريب ستواجه أولاً النسخة الداخلية من الصدمة التي حذّر منها أموداي.

الاستراتيجية التنظيمية حين تصحّ الرؤى الثلاث في آنٍ واحد

إن كانت وجهات نظر الثلاثة صحيحة جزئياً، كيف ينبغي أن تتغير الاستراتيجية التنظيمية؟

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

إن صحّ هوانغ: الوكلاء يعيدون تشكيل المنظمات الآن بالفعل. ابنِ كفاءات وأنظمة قياس الآن، أو ستتأخر.

إن صحّ أموداي: اقتصادات البرمجيات تتغير جوهرياً والصدمة ستكون غير متساوية. حدّد الأدوار الأكثر هشاشة داخل المنظمة وأوجد مسارات تحول.

المبادئ التنظيمية التي تستوعب الرؤى الثلاث في آنٍ واحد:

أولاً، لا تراهن على جدل الذكاء الاصطناعي العام. سواء كانت 5–10 سنوات لهاسابيس أو “قد يكون قريباً” لأموداي، فإن الاستراتيجية التنظيمية المرتبطة بجدول زمني للذكاء الاصطناعي العام ستكون دائماً عرضة للخطأ. بمعزل عن جدل الجداول الزمنية، دمج أقصى ما هو ممكن من قدرات الذكاء الاصطناعي الحالية في المنظمة هو موقف أكثر استقراراً.

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

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

رابعاً، أدِر القلق من الأدوار داخل المنظمة بالبيانات. إن صحّ تحذير أموداي، ستكون الصدمة داخل المنظمات غير متساوية. قياس الأدوار الأسرع تغيّراً وتوفير مسارات تحول هو المهمة القيادية الجديدة.

خاتمة: عدم اليقين كمادة خام للاستراتيجية

تبدو رؤى العمالقة الثلاثة متعارضة، لكنها في الحقيقة تنظر كل واحدة إلى أفق زمني مختلف وطبقة مختلفة. هاسابيس يتحدث عن معيار معرفي، وهوانغ عن التحول الهيكلي الجاري، وأموداي عن انضغاط التكلفة الاجتماعية عبر الزمن.

الرهان على واحد منهم فقط خطر. الأخذ بحذر هاسابيس وحده يعني تفويت التغيير الجاري اليوم. اتباع تفاؤل هوانغ وحده يتركك أعزل أمام الصدمة. الإيمان بتحذير أموداي وحده يعني التخلي عن الفرص المتاحة الآن.

دور المنظمة البانية هو استخلاص مبادئ الثقافة التنظيمية من تقاطع الرؤى الثلاث. احمِ المجالات التي تستلزم فهماً حقيقياً. ابنِ الكفاءة اللازمة لإدارة الوكلاء — الآن. سبق الصدمة غير المتساوية بالاستعداد لها.

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

المصادر

• Fortune / WEF Davos 2026: https://fortune.com/2026/01/23/deepmind-demis-hassabis-anthropic-dario-amodei-yann-lecun-ai-davos/
• بودكاست WEF Radio Davos: https://www.weforum.org/podcasts/radio-davos/episodes/ai-agi-dario-amodei-demis-hassabis/
• Axios — مقابلة هاسابيس 2026-05-26: https://www.axios.com/2026/05/26/deepmind-ceo-demis-hassabis
• Sherwood News — هاسابيس: الذكاء الاصطناعي العام بعد 3–4 سنوات: https://sherwood.news/tech/google-deepminds-hassabis-agi-is-3-to-4-years-away/
• CryptoBriefing — هاسابيس واختبار أينشتاين: https://cryptobriefing.com/deepmind-hassabis-agi-einstein-test/
• Fortune — هوانغ: الوكلاء والموظفون 2026-03-19: https://fortune.com/2026/03/19/jensen-huang-nvidia-ai-agents-future-of-work-autonomous/
• Fortune — هوانغ: روبوتات المصانع 2026-05-06: https://fortune.com/2026/05/06/jensen-huang-servicenow-bill-mcdermott-agentic-ai-robos/
• المدونة الرسمية لـ NVIDIA GTC Taipei: https://blogs.nvidia.com/blog/nvidia-gtc-taipei-computex-2026-news/
• Yahoo Finance — هوانغ “شركات البرمجيات لن تموت”: https://finance.yahoo.com/markets/article/nvidia-ceo-jensen-huang-just-perfectly-explained-the-ai-stock-boom-130835624.html
• Semiconalpha Substack — نسخة خطاب GTC Taipei الرئيسي: https://semiconalpha.substack.com/p/nvidia-keynote-computex-2026-key
• CNBC — أموداي “unusually painful” 2026-01-27: https://www.cnbc.com/2026/01/27/dario-amodei-warns-ai-cause-unusually-painful-disruption-jobs.html
• The News.com.pk — أموداي “البرمجيات ستصبح مجانية”: https://www.thenews.com.pk/latest/1402953-software-will-become-essentially-free-warns-anthropic-ceo-amodei
• Fortune — تخفيف نبرة أموداي 2026-05-26: https://fortune.com/2026/05/26/sam-altman-dario-amodei-walking-back-ai-jobs-apocalypse-prophecies-ipo/

في ThakiCloud نشغّل أحمال التدريب وتنسيق وحدات معالجة الرسومات على منصة SaaS للذكاء الاصطناعي وتعلّم الآلة قائمة على K8s. إن نشر “كيف دُرّب النموذج الرائد” بالكامل مرجع نادر لمن يصمم بنية تدريب داخل المؤسسة. يفحص هذا المقال ما هو التدريب اللاحق OPD، وما الذي يتغيّر حين يصبح مكدّس RL بأكمله مفتوحاً.

تناولنا نظرة عامة على إطار التدريب اللاحق slime نفسه في مقال منفصل، التدريب اللاحق بوصفه بنية تحتية: إطار slime مفتوح المصدر وتوسيع التعلّم المعزّز. يركّز هذا المقال على التدريب اللاحق OPD ودمج النماذج الخبيرة الذي يعمل فوقه.

ما نوع نموذج GLM-5.2

أولاً، النموذج المستهدف. GLM-5.2 نموذج مفتوح الأوزان بحجم 753B. يستهدف المهام طويلة الأفق ويدعم سياقاً بطول مليون رمز (1M). تذكر Z.ai أن تقنية تُسمى IndexShare تخفض عدد عمليات FLOPs لكل رمز بمقدار 2.9 مرة عند طول سياق يبلغ مليون رمز. أي أن التصميم يهدف إلى التعامل مع السياقات الطويلة مع كبح كلفة الاستدلال.

تُظهر أرقام القياس موضعه. في Terminal-Bench 2.1 الذي يقيّم مهام البرمجة، سجّل 81.0 ملاحقاً 85.0 لـ Claude Opus 4.8. وفي SWE-bench Pro بلغ 62.1 مرتفعاً عن 58.4 في الإصدار السابق GLM-5.1. وفي FrontierSWE الذي يقيس العمل طويل الأفق، تقلّصت الفجوة مع Opus 4.8 إلى نحو 1%. النقطة الأساسية هي نموذج مفتوح الأوزان قلّص الفجوة مع النماذج الرائدة المغلقة إلى خانة الآحاد. الترخيص MIT، وهو متاح على HuggingFace و ModelScope.

ثقل هذه الحالة أن “كيف دُرّب نموذج بهذا المستوى” أصبح متاحاً للعموم.

ما هو التدريب اللاحق OPD

OPD هو طريقة التدريب والدمج المتوازي المستخدمة في مرحلة التدريب اللاحق لـ GLM-5.2. الفكرة بسيطة لكنها متطلّبة على مستوى البنية التحتية. فبدلاً من تدريب نموذج عملاق واحد على كل القدرات دفعة واحدة بالتعلّم المعزّز، تدرّب عدة نماذج خبيرة لكل قدرة على حدة بالتعلّم المعزّز ثم تدمجها في نموذج نهائي واحد.

وفق تقرير Z.ai، استخدم التدريب اللاحق لـ GLM-5.2 إطار slime لتشغيل تدريب OPD متوازٍ، ودمج أكثر من عشرة نماذج خبيرة في النموذج النهائي، واستغرقت عملية OPD كاملةً نحو يومين. هنا يبرز رقمان. أكثر من عشرة نماذج خبيرة يعني أن قدرات مثل البرمجة والسلوك الوكيلي والاستدلال فُصلت ورُفع مستوى كلٍّ منها بالتعلّم المعزّز. ونحو يومين يعني أن تدريب هذا العدد من الخبراء ودمجهم جرى في زمن عملي وليس طويلاً على نحو غير واقعي. (لم يُؤكَّد التفسير الدقيق لاختصار OPD صراحةً في المادة الرسمية، لذا لا نجزم به هنا. الحقائق المتحقَّقة هي سلوك “تدريب الخبراء بالتوازي ثم الدمج” والأرقام أعلاه.)

المزايا العملية لهذا النهج واضحة.

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

وتأتي الصعوبات معها. فعند دمج عدة خبراء في واحد قد تتداخل القدرات أو يلغي بعضها بعضاً. وإذا لم يكن الدمج متوسطاً بسيطاً للأوزان بل تضمّن عملية تدريب منفصلة، فإن الدمج نفسه يصبح مرحلة تدريب لاحق أخرى. ولعلّ سبب وصف Z.ai له بـ “تدريب OPD المتوازي” هو أن الدمج يتجاوز المتوسط الحسابي البسيط.

slime: البنية التحتية مفتوحة المصدر للتعلّم المعزّز خلف OPD

الأساس الذي جعل OPD ممكناً هو slime. وهو إطار تدريب لاحق لنماذج اللغة من أجل توسيع التعلّم المعزّز، صادر برخصة Apache-2.0. ينقسم هيكله إلى ثلاثة أجزاء.

• التدريب (Megatron): يتولّى حلقة تدريب السياسة، ويقرأ من مخزن البيانات (Data Buffer).
• التوليد (SGLang + موجّه): يولّد بيانات جديدة ويخزّنها مجدداً في المخزن.
• مخزن البيانات (Data Buffer): يدير تهيئة المطالبات وتدفقات توليد البيانات المخصّصة.

المبدأ التصميمي الذي يؤكّد عليه slime هو كونه غير متزامن ومفكوك الارتباط. تتدفّق عمليات تدريب Megatron وتوليد SGLang وتوليد البيانات المخصّص وحساب المكافأة وتغذية المدقّق والتفاعل مع البيئة كلها عبر المسار نفسه للتدريب والتوليد. يصعب التدريب اللاحق بالتعلّم المعزّز على مستوى البنية التحتية تحديداً لأن الاستدلال (التوليد) والتدريب (التحديث) يتناوبان في حلقة واحدة. يفصل slime بينهما ليُجدوَل كلٌّ بما يلائم ملف موارده.

ونطاق النماذج المدعومة واسع. يدعم سلسلة Qwen (Qwen3.6، Qwen3.5، Qwen3Next، Qwen3MoE، Qwen3، Qwen2.5)، وسلسلة DeepSeek V3 (V3، V3.1، R1)، و Llama 3. واستخدامه في تدريب نماذج رائدة فعلية من GLM 4.5 حتى 5.2 يمنح ثقة بأنه شيفرة مجرّبة ميدانياً.

يتبع التثبيت أسلوب حزم بايثون القياسي. يتضمّن المستودع requirements.txt وsetup.py وpyproject.toml، ويوفّر بيئة حاويات عبر مجلد /docker. غير أن تشغيل تدريب لاحق حقيقي بالتعلّم المعزّز يتطلّب وحدات معالجة رسومات كثيرة، لذا لا يعيد هذا المقال إنتاج التدريب مباشرةً بل يركّز على تحليل الحقائق المنشورة والهيكل. إن تلفيق أرقام على محطة عمل واحدة سيكون تشويهاً، لذا لم نفعل.

ماذا يعني أن يكون مكدّس RL بأكمله مفتوحاً

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

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

النقطة الجوهرية أن “كيف تُصنع النماذج الرائدة” لم يعد معرفة مغلقة بل هندسة منشورة. وهذا يخفض بشدة حاجز الدخول للمؤسسات التي تريد صقل النماذج ببنيتها الخاصة.

التطبيق على منصة ThakiCloud SaaS على K8s

الصورة التي يرسمها OPD و slime تتطابق تماماً مع مشكلات بنية التدريب التي نتعامل معها على K8s.

الأول هو تنسيق وحدات المعالجة. لتدريب أكثر من عشرة خبراء بالتوازي مثل OPD، عليك جدولة مهام تدريب كثيرة في آن واحد، وداخل كل مهمة وضع أحمال مختلفة الطابع، التوليد (استدلال) وتحديث السياسة (تدريب)، على مجمّع الوحدات نفسه. تدير ThakiCloud طوابير مهام وحدات المعالجة وحصصها عبر Kueue، لذا فإن بنية إطلاق تدريب كل خبير كمهمة مستقلة بأولوية وسقوف موارد محدّدة تتلاءم بطبيعتها. ويتطابق تصميم slime غير المتزامن مفكوك الارتباط جيداً مع نمط K8s لتوسيع حاضنات (pods) التوليد وحاضنات التدريب كلٍّ على حدة.

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

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

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

القيود والاعتراضات

من باب التوازن، نذكر نقاط الضعف أيضاً.

أكبر قيد هو حدود التحقق. فرقما “أكثر من عشرة خبراء” و”نحو يومين” تقرير Z.ai الذاتي، وليسا نتائج أعاد إنتاجها طرف خارجي مستقل. والتعريف الدقيق لاختصار OPD وتفاصيل خوارزمية الدمج لا تتكشّف بالكامل بالمادة العامة وحدها. لذا فهذا التحليل تفسير مبني على السلوك والأرقام المنشورة، وقد تجنّبنا الجزم بالآلية الداخلية.

وجدار الحجم واضح أيضاً. كون البنية مفتوحة لا يعني أن أي أحد يمكنه التدريب اللاحق لنموذج بحجم 753B. فتدريب الخبراء بالتوازي ودمجهم يتطلّب وحدات معالجة وبيانات وخبرة في تصميم المكافأة بقدر كبير. تخفض المصادر المفتوحة حاجز الدخول لكنها لا تزيل حاجز الموارد.

والدمج نفسه يحمل مخاطرة. فعند دمج خبراء كل بحسب قدرته قد تتآكل قدرة لصالح أخرى، وقد تنحرف درجات القياس عن قابلية الاستخدام الفعلية. وقد يُظهر نموذج مدموج من عدة خبراء سلوكاً يصعب التنبؤ به في تركيبات معيّنة.

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

المصادر

• GLM-5.2: Built for Long-Horizon Tasks (مدونة Z.ai)
• THUDM/slime: إطار التدريب اللاحق بالتعلّم المعزّز (GitHub)
• zai-org/GLM-5 (HuggingFace)
• GLM-5 مفتوح المصدر من z.ai وتقنية slime للتعلّم المعزّز (VentureBeat)
• مقال ذو صلة: التدريب اللاحق بوصفه بنية تحتية: إطار slime مفتوح المصدر وتوسيع التعلّم المعزّز

في ThakiCloud نتخصص في تقديم النماذج ضمن منصة AI/ML SaaS مبنية على Kubernetes. إن إمكانية تشغيل نموذج برمجة من الصف الأول دون الاعتماد على واجهات برمجية مغلقة أمرٌ ذو قيمة استثنائية للشركات التي تجعل من الذكاء الاصطناعي المحلي (on-premise) والسيادي محوراً تجارياً. في هذا المقال نوضح ما هو GLM-5.2 فعلياً، وما يستلزمه تشغيله ذاتياً، والفرص والقيود التي يطرحها على مزودي خدمات GPU مثلنا.

ما هو GLM-5.2

GLM-5.2 هو أحدث نموذج رائد في سلسلة GLM من Z.ai، مُصمَّم للمهام العميقة ذات الأفق الزمني الطويل والبرمجة. يعتمد معمارية Mixture-of-Experts (MoE) بإجمالي معاملات يبلغ نحو 744B، غير أن المعاملات الفعّالة عند معالجة كل رمز (token) تبلغ نحو 40B فحسب. يضم كل طبقة MoE 256 خبيراً (expert)، يُنشَّط منهم 8 فقط لكل رمز. والنتيجة: سعة معرفية هائلة مع حجم حسابي أثناء الاستدلال يضاهي نموذجاً كثيفاً (dense) من فئة 40B.

يمتد نافذة السياق (context window) حتى نحو مليون رمز (1,048,576) للمدخلات، مع حدّ أقصى للمخرجات يبلغ نحو 128K (131,072) رمزاً. والمليون رمز ليس شعاراً تسويقياً؛ فالنموذج مُصمَّم تحديداً لسيناريوهات “الأفق الطويل” التي تستلزم تحميل قاعدة الشيفرة بأكملها أو سجلات عمل مطوّلة في سياق النموذج دفعةً واحدة مع استمرار المهمة عبر خطوات متعددة. يُضاف إلى ذلك أن GLM-5.2 يوفر تعديل شدة الاستدلال (reasoning intensity) على عدة مستويات، مما يتيح تحقيق التوازن المطلوب بين الجودة وزمن الاستجابة بحسب طبيعة العمل.

الأهم من كل ذلك هو الترخيص. الأوزان الأساسية لـ GLM-5.2 متاحة بترخيص MIT الحر تماماً. يمكن للمؤسسات تنزيل الأوزان بحرية من مستودع zai-org/GLM-5.2 على Hugging Face، وضبطها الدقيق (fine-tuning)، وتشغيلها على خوادمها الخاصة أو في بيئات الشبكات المعزولة. خلافاً لبعض النماذج “المفتوحة” التي تتضمن شروطاً للاستخدام التجاري، يمثّل MIT عملياً أرحب صور الترخيص.

المعايير المرجعية: نموذج مفتوح يتجاوز GPT-5.5

جوهر الاهتمام بـ GLM-5.2 هو أرقام الأداء. أبرز المقاييس المُستشهَد بها هو SWE-bench Pro، الذي لا يقيس إصلاحات الشيفرة المنفردة، بل يقيس قدرة العامل الآلي (agent) على إنجاز مهام هندسة برمجيات حقيقية متشعبة عبر ملفات متعددة وتستغرق وقتاً طويلاً.

سجّل GLM-5.2 نتيجة 62.1 في SWE-bench Pro، متفوقاً بفارق واضح على GPT-5.5 (58.6) والإصدار السابق GLM-5.1 (58.4). وفي FrontierSWE (Dominance) الذي يقيس البرمجة بالأفق الطويل، بلغ 74.4% متجاوزاً GPT-5.5 (72.6%)، وعلى مقربة شديدة من Claude Opus 4.8 (75.1%).

ما هو أكثر ثقلاً من الأرقام هو التكلفة. وفقاً لتقرير VentureBeat، يحقق GLM-5.2 هذا التفوق في معايير البرمجة ذات الأفق الطويل بتكلفة تُقدَّر بسُدس تكلفة GPT-5.5. لا يتعلق الأمر بـ”أداء مماثل بسعر أرخص”، بل بـ”أداء أفضل وتكلفة أقل بكثير”. غير أن هذه المقارنة بالسُدس مبنية على أعباء عمل وافتراضات تسعير محددة، وقد تتفاوت الميزة الفعلية من حيث التكلفة تبعاً لبيئة التشغيل.

نادراً ما يلحق نموذج مفتوح الأوزان بالنماذج المغلقة في مجالات متطلبة كالبرمجة وينافسها من حيث السعر في آنٍ واحد. هذا هو السياق الذي فاضت فيه تجارب الاستخدام الفعلي للنموذج بعد خمسة أيام فحسب من إصداره.

الاستضافة الذاتية: تقديم GLM-5.2 باستخدام vLLM

مهما كانت الأداء والترخيص جذّابَين، فإن تشغيل نموذج MoE بحجم 744B فعلياً مسألة مستقلة. دعونا نتأمل واقع الاستضافة الذاتية بالأرقام.

نبدأ بذاكرة الأوزان. بدقة FP8 تحتاج الأوزان بايتاً واحداً لكل معامل، أي نحو 744GB إجمالاً. بدقة BF16 تتضاعف هذه القيمة لتبلغ نحو 1,488GB. ومع احتساب KV cache والعمليات الإضافية في وقت التشغيل، يغدو التكوين الواقعي للعقدة الواحدة هو 8 وحدات H200 بدقة FP8. تبلغ ذاكرة H200 الواحدة 141GB، فمجموع 8 وحدات نحو 1,128GB من VRAM، وهو ما يكفي لاستيعاب الأوزان البالغة 744GB مع هامش للـ KV cache وزيادة 10-20% للعمليات الإضافية. لأعباء عمل سياق المليون رمز، يُوصى بتكوين 8xH200 أو 8xB200.

vLLM هو معيار محركات التقديم de facto. يدعم vLLM 0.19.0 وما فوق نماذج GLM من فئة MoE، وأبرز المعاملات المطلوبة هي:

vllm serve zai-org/GLM-5.2 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --quantization fp8 \
  --kv-cache-dtype fp8_e5m2 \
  --max-model-len 131072 \
  --enable-chunked-prefill

المعامل --enable-expert-parallel يوزّع الخبراء في MoE على وحدات GPU لتقسيم الذاكرة والحسابات، وهو أمر حيوي عند تحميل هذا النوع من النماذج الضخمة على عقدة واحدة. يُضبط --max-model-len عند 131072 للأعباء الاعتيادية، مع إمكانية رفعه إلى 1048576 عند الحاجة لسياق مليون رمز. منذ vLLM 0.23.0 صار بالإمكان الاستفادة من speculative decoding المبني على MTP (multi-token prediction) لرفع معدل الإنتاجية أكثر.

إذا كانت ذاكرة GPU محدودة، تتوفر أيضاً أشكال مُكمَّمة (quantized variants): نسخة NVFP4 المُصدَرة من المجتمع وNVIDIA، ونسخة GGUF، كلاهما متاح على Hugging Face، مما يوفر مساراً للبيئات ذات الميزانيات المحدودة بقبول بعض التراجع في الدقة مقابل توفير الذاكرة.

التطبيق والانعكاسات على منصة ThakiCloud K8s AI/ML SaaS

نموذج كـ GLM-5.2 ينسجم تماماً مع التوجه الذي نؤكد عليه في ThakiCloud. نحن نضع قيمتنا الجوهرية في تشغيل أعباء الذكاء الاصطناعي داخل بيئة العميل بلا اعتماد على واجهات برمجية مغلقة. القدرة على تنزيل نموذج برمجة من الصف الأول بترخيص MIT وتشغيله على وحدات GPU الخاصة تعني أن المادة الخام لتحقيق هذه القيمة باتت في متناول اليد.

تتجلى الصلة عملياً في ثلاثة محاور: أولاً، جدولة وحدات GPU. تشغيل عقد 8xH200 بكفاءة في بيئة متعددة المستأجرين (multi-tenant) يستلزم قوائم انتظار للمهام وتوزيعاً عادلاً للموارد. نحن ندير عقد GPU بجدولة دُفعية مبنية على Kueue، مما يتيح توزيع أعباء التقديم الضخمة كـ GLM-5.2 وأعباء التدريب والضبط الدقيق على الكلستر ذاته وفق أولويات محددة. ثانياً، العزل في البيئات متعددة المستأجرين. تشغيل عوامل برمجة تتعامل مع سياقات وبيانات مختلفة لكل عميل يستدعي عزل مثيلات النماذج ومسارات البيانات، وهو مجال نعالجه بالفعل عبر K8s namespaces وسياسات الشبكة. ثالثاً، حزمة التقديم. تكوين vLLM مع expert-parallel الموضّح أعلاه ينتمي إلى النمط ذاته الذي نستخدمه لتقديم نماذج مفتوحة الأوزان أخرى، مما يقلص العوائق الهيكلية أمام إضافة GLM-5.2 كنموذج جديد.

أكثر ما يحمل أهمية استراتيجية هو الذكاء الاصطناعي السيادي. في القطاعات الحكومية والمالية والدفاعية التي لا يمكن فيها للبيانات مغادرة الشبكة الداخلية، وفي البيئات الخاضعة لأنظمة سيادة البيانات، تُصبح عبارة “تشغيل نموذج أداؤه عالٍ داخل شبكتنا” نقطة انطلاق المفاوضات. GLM-5.2 يُجسّد هذا الطرح: يمكن نشره في الشبكات المعزولة، وترخيصه حر، وأداؤه مقارن بالنماذج المغلقة، وتكاليف تشغيله أدنى بحسب ما يُقال. بالنسبة لنا، هذا دليل ملموس يدعم رسالة “البنية التحتية المحلية وحدها كافية”.

بطبيعة الحال، لا يصنع نموذج واحد أعمالاً تجارية. القيمة الحقيقية تكمن في طبقة المنصة التي تُقدّم هذه النماذج باستقرار، وتُوزّع موارد GPU بكفاءة، وتعزل بيانات العملاء، وتجعل التشغيل قابلاً للرصد. GLM-5.2 محتوى جذاب يمكن تحميله على تلك المنصة، والمحتوى والمنصة معاً شرط لا غنى عنه.

القيود والاعتراضات

ثمة نقاط ضعف ينبغي مراجعتها قبل تبنّي GLM-5.2 دون تحفظ.

أولاً، حاجز الدخول لا يزال مرتفعاً. تكاليف توفير عقدة 8xH200 وتشغيلها ضخمة. ادعاء “السُدس من التكلفة” يعكس تكلفة الوحدة عند نسبة استخدام عالية للنموذج؛ أما عند تشغيله بنطاق محدود فقد يكون أغلى من الاعتماد على واجهات برمجية مغلقة. وحدات GPU غير المُستغَلة جيداً هي في حد ذاتها الموارد الأكثر كلفة.

ثانياً، المعايير المرجعية ليست الاستخدام الفعلي. التفوق على GPT-5.5 في SWE-bench Pro أو FrontierSWE لا يعني التفوق في كل مهام البرمجة. مؤشرات عملية مثل أداء لغات معينة أو أطر عمل بعينها، وموثوقية استدعاء الأدوات، والاتساق في جلسات العمل الطويلة تستوجب التحقق المستقل بمعزل عن درجات المعيار. الحماس اللحظي عقب الإصدار يختلف عن الموثوقية على المدى الطويل.

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

رابعاً، مخاطر الكَمّ (quantization). تنزيل NVFP4 أو GGUF لملاءمة ميزانية VRAM يوفّر الذاكرة، لكن في مهام حساسة للدقة كالبرمجة قد يُفضي إلى تدهور جودة قابل للقياس. ثمة فارق جوهري بين “النموذج يعمل” و”النموذج يعمل بجودة إنتاجية”.

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

المصادر

• zai-org/GLM-5.2 · Hugging Face
• GLM-5.2: Built for Long-Horizon Tasks (المدونة الرسمية لـ Z.ai)
• zai-org/GLM-5.2 · vLLM Recipes
• Z.ai’s open-weights GLM-5.2 beats GPT-5.5 … for 1/6th the cost (VentureBeat)
• Self-Host GLM 5.2: Hardware, vLLM Setup, and Cost vs Cloud (ofox.ai)

في ThakiCloud نتعامل مع خدمة النماذج على منصة AI/ML SaaS قائمة على K8s. وفيما يلي ما تعنيه الرسالة الجوهرية لهذا الدليل لمزوّدي سحابة GPU والذكاء الاصطناعي داخل المؤسسة مثلنا.

ما هو هذا الدليل

دليل Ahmad Osman ليس درساً بسيطاً للتثبيت. إنه أشبه بكتاب مرجعي ينظّم الاستدلال المحلي من البداية إلى النهاية. ورسالته الجوهرية واضحة. أنت لا تختار محرّك الاستدلال أولاً، بل تحدّد استراتيجية العتاد أولاً، ثم يتبعها المحرّك المناسب.

تهمّ هذه الزاوية لأن اختيار المحرّك أولاً يدفعك إلى تجاهل قيود العتاد الذي تملكه فعلاً. فالنموذج الذي تشغّله على حاسوب محمول واحد والنموذج الذي تشغّله على خادم بأربعة معالجات رسومية هما خياران مختلفان منذ البداية. يقرّ الدليل بهذا ويقسّم النقاش عبر بيئات تشغيل متعددة: الأجهزة المقيّدة كالحواسيب المحمولة والحافة، تدفقات العمل المتمحورة حول Mac، معالج RTX رسومي واحد، تكوينات NVIDIA CUDA متعددة المعالجات من اثنين إلى أربعة أو أكثر، الخدمة الإنتاجية العامة، السياق الطويل وتوجيه MoE، استخراج أقصى أداء من NVIDIA، وأخيراً تنسيق العناقيد. ولكل سيناريو يشير إلى الأدوات المناسبة.

يلخّص المخطط أدناه المنطق الجوهري للدليل بوصفه ربطاً بين سيناريوهات العتاد ومحركات الاستدلال.

flowchart TD
    A[تعريف عبء عمل الاستدلال] --> B{حدّد استراتيجية العتاد أولاً}
    B -->|أجهزة مقيّدة: محمول / حافة| C[llama.cpp]
    B -->|Apple Silicon Mac| D[MLX / MLX-LM]
    B -->|معالج RTX استهلاكي واحد| E[ExLlamaV2 / ExLlamaV3]
    B -->|خدمة إنتاجية عامة| F[vLLM / SGLang]
    B -->|أقصى أداء من NVIDIA| G[TensorRT-LLM]
    B -->|خدمة موزّعة متعددة العُقد| H[NVIDIA Dynamo]
    C --> I[شواغل مشتركة: التكميم، حساب الذاكرة، الموازنة بين الإنتاجية والكمون]
    D --> I
    E --> I
    F --> I
    G --> I
    H --> I

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

مشهد محركات الاستدلال

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

• llama.cpp: قوته في تعدد الاستخدامات، إذ يعمل على المعالج المركزي والرسومي معاً حين تكون ذاكرة VRAM ضيقة وذاكرة RAM وافرة. وهو نقطة الانطلاق الأقل حاجزاً.
• MLX وMLX-LM: منظومات مُحسّنة لمعالجات Apple Silicon. تناسب من يريد تشغيل الاستدلال على MacBook أو Mac Studio باستخدام الذاكرة الموحّدة.
• ExLlamaV2 وExLlamaV3: يهدفان إلى استدلال مُكمَّم سريع على معالجات الرسوميات الاستهلاكية، ويناسبان حالات الرغبة في أقصى سرعة من بطاقة RTX واحدة.
• vLLM وSGLang: المعيار الفعلي للخدمة الإنتاجية. يرفع كلٌّ من PagedAttention والدفعات المستمرة إنتاجية الطلبات المتعددة.
• TensorRT-LLM: محرّك يستخرج أداءً أقصى من عتاد NVIDIA. يخفض التحسين على مستوى النواة الكمون، لكن صعوبة البناء والتشغيل أعلى.
• NVIDIA Dynamo: يستهدف الخدمة الموزّعة عبر عُقد متعددة، ويُستخدم حين توزّع الاستدلال خارج خادم واحد.

يتضح أمر واحد من هذه القائمة. لا وجود لشيء اسمه “أفضل محرّك استدلال”. قد يكون llama.cpp هو الجواب الصحيح على جهاز مقيّد، بينما قد يكون vLLM أو TensorRT-LLM هو الجواب الصحيح لخدمة تتلقى آلاف الطلبات المتزامنة. المعيار ليس تفوّق المحرّك بل تركيبة عبء العمل والعتاد.

لماذا الاستدلال المحلي الآن

أسباب تنامي الاهتمام بالاستدلال المحلي واضحة. ويذكر الدليل ونقاشات المجتمع أربعة دوافع مشتركة.

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

مع انتقال مركز الثقل من الاعتماد الكلّي على واجهات السحابة نحو داخل المؤسسة والحافة، يستمر تنامي الطلب على مادة تتيح مقارنة أي محرّك يُوضع على أي عتاد دفعة واحدة. هذه هي خلفية الاهتمام الذي ناله دليل Ahmad Osman.

تطبيق ذلك على منصة ThakiCloud K8s AI/ML SaaS

تقع الخدمة المحلية وداخل المؤسسة لنماذج LLM التي يغطّيها هذا الدليل في قلب أعمال ThakiCloud تماماً. فموقعنا كمنصة AI/ML SaaS قائمة على K8s، وذكاء اصطناعي سيادي وداخل المؤسسة، وسحابة GPU، وMSP، وذكاء اصطناعي للمؤسسات، هو بالضبط عمل حلّ المشكلات التي تصفها هذه المادة.

منطق الدليل الجوهري، “استراتيجية العتاد أولاً ثم يتبعها المحرّك”، إطار يمكننا استخدامه مباشرة عند اقتراح موارد GPU ومنظومات الاستدلال للعملاء. الطيف الممتد من بطاقة RTX واحدة إلى تعدد المعالجات وتنسيق العناقيد يتداخل تماماً مع المجال الذي تغطّيه فعلاً جدولة أعباء العمل القائمة على Kueue وإدارة دورة حياة GPU لدينا. تحديد مستوى عتاد العميل أولاً ومطابقة تكوين الخدمة المناسب له هو ما نفعله كل يوم.

على صعيد الفرص، إذا جمعنا منظومات الخدمة الإنتاجية مثل vLLM وSGLang وTensorRT-LLM وNVIDIA Dynamo في عروض مُدارة على K8s، يمكننا استيعاب عبء اختيار العملاء للمحركات وضبطها بأنفسهم. قراءة دليل واحد وبناء محرّك يدوياً يختلف تشغيلياً اختلافاً كبيراً عن تلقّي منظومة خدمة مُتحقَّق منها مع اتفاقية مستوى خدمة. وللمؤسسات وعملاء القطاع العام الراغبين في سيادة البيانات والتحكّم في التكلفة، يمكن لهذا الدليل أن يكون أيضاً دليلاً لعرض ميزة التكلفة الإجمالية للملكية للاستدلال داخل المؤسسة مقابل واجهات السحابة بشكل كمّي.

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

القيود والحجج المضادة

ومع ذلك، علينا أيضاً النظر إلى التهديد. الأدلة المجانية بمستوى “الإنجيل” مثل هذا ونضج أدوات مثل llama.cpp وMLX تخفض حاجز الدخول، ما يسهّل على العملاء الذهاب مباشرة إلى الاستضافة الذاتية. وحين يكون محرّك الاستدلال نفسه مفتوح المصدر والمادة التي تنظّم كيفية تثبيته منشورة مجاناً، فإن مجرد تقديم “سنثبّت لك المحرّك” لا يشكّل أي تمايز.

لذا يجب أن يكمن تمايزنا لا في المحرّك نفسه بل في عزل المستأجرين المتعددين، وتعظيم كفاءة GPU، وأتمتة التشغيل، واتفاقية مستوى الخدمة. علينا إثبات القيمة لا بما تشغّله بل بمدى استقرار تشغيلنا له نيابةً عنك. ما يعلّمه الدليل يصل إلى “أي محرّك يناسب أي عتاد”، أما “ما الذي تحتاجه أكثر لخدمته باستقرار لمستأجرين كثر على مدار الساعة” فهو الأرض التي تتجاوز الدليل. تلك الأرض هي حيث نتحمّل المسؤولية.

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

الخاتمة

يقدّم دليل Ahmad Osman للاستدلال المحلي إطاراً بسيطاً لكنه عملي: “العتاد قبل المحرّك”. وبعرضه المشهد من llama.cpp إلى NVIDIA Dynamo دفعة واحدة، يصبح نقطة انطلاق جيدة لكل من يبدأ بالاستدلال المحلي. ولمزوّدي الخدمة مثلنا، هذه المادة إطار لمقترحات العملاء وتذكير في الوقت نفسه بالضغط التنافسي للاستضافة الذاتية. وللمهندسين المهتمين بإثبات القيمة عبر التشغيل بما يتجاوز المحرّك، هذا مكان تكون فيه مثل هذه المشكلات هي المهمة اليومية.

المصادر: الدليل الشامل للاستدلال المحلي لنماذج LLM بقلم Ahmad Osman (@TheAhmadOsman، مشرف GPU في r/LocalLLaMA). موقع المؤلف ahmadosman.com، التغريدة الأصلية، ومرجع مقارنة محركات الاستدلال مقارنة محركات الاستدلال المحلي 2026. أرقام الأداء مبنية على بيئة المؤلف وتتطلب إعادة تحقّق في الواقع.

اليوم هو الموعد النهائي. نموذج Fable 5، وهو النموذج الأعلى مستوى من Anthropic، مُدرَج في خطط الاشتراك مجاناً حتى 22 يونيو فقط، ثم يُستثنى من الحصة المشمولة ابتداءً من 23 يونيو. بعد ذلك، يستلزم استخدام Fable 5 شراء رصيد منفصل بنظام الدفع حسب الاستخدام. انتشر هذا الخبر بسرعة في مجتمعات المطوّرين، ورأينا فيه إشارة لا يمكن تجاهلها.

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

ما الذي جرى

لنبدأ بالوقائع.

• يُدرَج Fable 5 دون تكلفة إضافية في خطط Pro وMax وTeam وEnterprise المعتمدة على المقاعد حتى 22 يونيو.
• ابتداءً من 23 يونيو، يُستبعد من الحصة المشمولة، ويستلزم الاستمرار في استخدامه رصيداً للاستخدام.
• يُخصم الرصيد وفق أسعار API القياسية. يبلغ سعر Fable 5 نحو $10 لكل مليون رمز مدخل، و$50 لكل مليون رمز مُخرَج، مع خصم 90% على القراءات المخزّنة مؤقتاً.

السبب الذي أعلنته Anthropic هو الطاقة الاستيعابية. “نتوقع أن يكون الطلب على Fable 5 مرتفعاً جداً، ويصعب التنبؤ به.” وأعلنت الشركة أنها ستمدّد فترة الإدراج إذا سمحت الطاقة بذلك، وأن هدفها إعادة Fable 5 إلى الاشتراكات القياسية في أقرب وقت ممكن.

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

لماذا يحدث هذا

هذا ليس خاصاً بـ Anthropic، بل هو سمة هيكلية لنماذج الذكاء الاصطناعي الحدية عموماً.

تصطحب النماذج الأقوى تكاليف استدلال أعلى. أسعار رموز Fable 5 ضعف أسعار Opus 4.8 من الشركة ذاتها (مدخل $5، مُخرَج $25). حين يتيح مزوّد نموذجاً كهذا باشتراك ثابت مع استخدام شبه مفتوح، تتصاعد تكاليف GPU بصورة غير خطية حين يرتفع استخدام المستخدمين المكثّفين. وكلّما كان الطلب أقل قابليةً للتنبؤ، كان نموذج الاشتراك الثابت أكثر خطورة على المزوّد.

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

الدروس لاستراتيجية الحصول على نماذج اللغة الكبيرة

الخلاصة التي يجب أن يأخذها المشغّلون واضحة. ربط أحمال العمل الأساسية باشتراك تجاري واحد يعني تفويض تكلفة تلك الأحمال وتوافرها إلى سياسة المزوّد.

ما هو مجاني اليوم قد يصبح مدفوعاً غداً. تُعدَّل الحدود، وتُعلَن عزلة النماذج، ويتفاوت التوافر الإقليمي. لا يعني هذا أن هذه التغييرات خاطئة، بل يعني أنها متغيّرات خارج سيطرتنا. لأي عمل يحتاج إلى تكاليف قابلة للتنبؤ، هذا التقلّب في حد ذاته خطر.

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

منظور ThakiCloud: لماذا يصلح الخادم المحلي تحوّطاً

في ThakiCloud، نتعامل مع خدمة النماذج على منصة AI/ML SaaS مبنية على K8s. في كل مرة يقع حدث كهذا، ما نؤكده بسيط: حين تكون الأوزان في بنية تحتية نتحكّم فيها، نحن من يحدّد السعر والتوافر.

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

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

التحفّظات والحجج المضادة

سنكون صادقين بشأن الجانب الآخر أيضاً.

• لكثير من الفرق، تبقى نماذج الاشتراك التجاري الخيار الأكثر عقلانية. فتكلفة امتلاك بنية تحتية GPU خاصة وكوادر تشغيلية قد تتجاوز رسوم الدفع حسب الاستخدام. حتى يتجاوز الاستخدام حجماً معيّناً، قد يكون الاستثمار المحلي مُبالَغاً فيه.
• قد يكون هذا التغيير مؤقتاً. أعلنت Anthropic نيّتها إعادة Fable 5 إلى الاشتراكات حال توفّر الطاقة. قد يكون تعميم تعديل سياسة واحد إلى خطر هيكلي مبالَغة.
• خدمة نماذج الأوزان المفتوحة بنفسك لا تُلغي التقلّب. أعطال الأجهزة، وتحديثات النماذج، وتناقص الكوادر البشرية، كلها أشكال مختلفة من المخاطر. التحوّط يوزّع المخاطر ولا يُلغيها.

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

المصادر

• التغريدة الأصلية: إشعار انتهاء الوصول المجاني إلى Fable 5 في الاشتراك
• gHacks: Anthropic Releases Claude Fable 5 to Pro, Max, and Enterprise Users Free Until June 22
• Hacker News: نقاش حول Fable 5 free until June 22
• Anthropic: Claude Fable

At the World Economic Forum in Davos in January 2026, Anthropic CEO Dario Amodei dropped a short sentence during a conversation with WSJ Editor-in-Chief Emma Tucker.

Software is “going to become cheap,” he said, and “maybe essentially free.” The foundational premise of SaaS — recover development costs by distributing them across millions of users — might no longer hold.

(Original quote: “Software is going to become cheap, maybe essentially free” — WSJ/Davos interview, January 2026)

The model of hiring dozens of engineers, building a product over years, and selling it to millions of users: that economic foundation, he warned, could be shaking.

In the same conversation, Amodei said something else. AI would compress 100 years of economic change into 5 to 10 years, and the disruption could be “unusually painful.” (CNBC, January 27, 2026)

The future of engineering teams hangs between those two statements.

What Happens When Marginal Cost Approaches Zero

In economics, marginal cost is the cost of producing one additional unit. The software industry has long benefited from the near-zero cost of copying digital products — write code once, replicate it millions of times at no additional cost.

What Amodei is describing is the next step: what happens when the cost of creating software itself approaches zero.

The signs are already here. Tools like GitHub Copilot, Cursor, and Claude Code are rapidly lowering the cost of code generation. Scaffolding CRUD apps, writing tests, extracting documentation — repetitive tasks are getting cheaper by the day.

When those costs converge toward zero, where does the competitive advantage of what engineers build remain?

Not in the ability to write code. In the ability to judge what to write. That is where it remains.

Why Did Amodei’s Position Change?

It is worth noting that Amodei’s own statements shifted significantly in just a few months.

In a January 2026 CNBC essay, he warned that the job disruption would be “unusually painful.” Then in May 2026, ahead of Anthropic’s IPO, he shifted his emphasis toward “augmentation.” Fortune reported this shift as a move toward “walking back” his AI jobs apocalypse prophecies. (Fortune, May 26, 2026)

The two statements are not contradictory — they must be read together. Pain will come in the short term; roles will be redefined over the medium and long term. But that redefinition will not happen on its own. That is the point.

In the May interview, he also said: “there are jobs that took generations to build that may disappear.” This was not a warning about individual jobs but about the structure of careers — entire professional lineages that could cease to exist.

This is not the fear scenario where “all developers become unnecessary.” It is a more uncomfortable story. The half-life of expertise accumulated so far is shortening dramatically.

What Disappears and What Remains

When the marginal cost of software falls, what is threatened first is repetitive implementation work. Translating known patterns into code, combining existing components, implementing specs verbatim — AI tools handle these tasks increasingly well.

Even as code-generation costs fall, some value does not disappear. Three categories stand out.

The ability to choose the right problem. Knowing what to build is far harder than knowing how to build it. Catching the gap between what users say and what they actually want, choosing from among hundreds of candidate features the one that must be built right now — these judgments are hard for algorithms to replace. The lower the cost of building, the greater the relative weight of deciding what to build.

Validation and taste. As AI-generated code proliferates, the ability to judge whether it is correct becomes a core competency. Not simply bug detection. Will this design still be maintainable six months from now? Does this API behave predictably? Does this codebase reduce the team’s cognitive load? These are products of taste and experience that only a seasoned engineer possesses.

Human-system boundary design. Distinguishing what AI cannot automate from what it should automate, and designing how humans intervene at that boundary. Just as the expansion of autonomous driving makes the design of driver-intervention moments more important, as AI writes more code, the role of designing where humans must exercise judgment grows more critical.

What Happens Economically

When the supply curve of software shifts downward, something paradoxical occurs.

More supply lowers prices. Lower prices cause demand to explode. Problems that were previously too expensive to solve with software become feasible — patient management for small clinics, inventory optimization for a neighborhood restaurant, data analysis pipelines for individual researchers.

Engineering demand does not shrink; its structure changes. Positions focused on repetitive implementation inside large software companies may contract. In their place, demand grows for roles that use AI to solve real problems across countless domains.

Amodei’s point about the SaaS “millions-of-users distribution model” cracking fits the same logic. Software companies have historically achieved economic viability by recovering development costs across many users. If the cost of building software approaches zero, there is less reason to build generic solutions for millions. Customized software for a specific organization, a specific team, even a specific individual becomes economically viable.

The beneficiaries of this shift are domain experts. Physicians, lawyers, accountants, logistics specialists — people who deeply understand their own work will be able to build their own software using AI tools. Engineers’ roles move toward collaborating with these experts to handle what AI tools struggle to produce: design, validation, and integration.

The transition will be painful. When Amodei said in January that it would be “unusually painful,” he was speaking about the speed of the transition. If the Industrial Revolution unfolded over decades, this one could happen in a few years. There may not be enough time for retraining.

It is also worth noting that Amodei did not walk back his warning. Even as he softened his tone in May, he also said — in the same period — “there are jobs that took generations to build that may disappear.” The tension between these two statements must be confronted directly. The possibility of augmentation and the fundamental disruption of career structures are not contradictory — both can be simultaneously true.

What Changes for Engineering Teams and Organizations

This is not only a personal matter; it is also a question of how organizations should be structured.

Role boundaries blur. Product managers, data analysts, and domain experts emerge who can build prototypes using AI tools without writing code directly. Engineers must understand business context more deeply and collaborate more closely with domain experts. The definition of “engineers just need to write good code” is no longer stable.

Validation culture matters more. Organizations that push AI-generated code directly to production may move fast in the short term but become fragile over time. The ability to validate becomes more of a competitive advantage than the speed of generation. Code review must be a substantive act of judgment, not a procedural formality.

Problem definition becomes a core competency. The ability to build prototypes quickly means, paradoxically, that the decision of what to build must be made more carefully. The lower the cost of building, the greater the risk of building the wrong thing. Investment in user interviews, problem discovery, and hypothesis validation must increase.

The basis of trust changes. The standard shifts from who writes more code faster to who can define and validate better problems. This does not mean senior engineers’ value falls — it means that value must now be expressed in a different form.

ThakiCloud’s Perspective: What Infrastructure Tells Us

ThakiCloud builds AI-based software development infrastructure. If Amodei’s prophecy is correct, the meaning of what we build changes too.

Just because the marginal cost of software falls does not mean the marginal cost of infrastructure falls. GPUs, multi-tenancy, data governance, security, availability — AI tools do not generate these. As the number of AI-built software applications explodes, demand for the infrastructure that runs them grows in parallel.

For our team, Amodei’s remarks are both a warning and a direction. Warning: some things that have been valuable until now will rapidly lose value. Direction: if your value has come from repetitive implementation, you must move toward judgment and design.

Conclusion: When the Half-Life of Expertise Shortens

Software becoming free does not mean the people who make software become free. The cost of generating code falls; the value of the judgment required to build good software does not.

Amodei’s shift in emphasis between January and May is readable in this light. The disruption AI brings is real. On the other side of that disruption lies a different role.

The core quality of that role is one thing: the ability to judge what should be built and why. That is something a code editor cannot tell you.

The identity of an engineer is moving from “someone who writes code” to “someone who sees problems.” The gap between teams that recognize and prepare for that shift, and those that do not, will become visible within a few years.

Sources

• Dario Amodei / Anthropic, WSJ-Davos interview, January 2026 — “Software will become essentially free”: The News.com.pk coverage
• Dario Amodei, CNBC, January 27, 2026 — “unusually painful” job disruption warning: CNBC original
• Dario Amodei, May 2026 interview — “there are jobs that took generations to build that may disappear”: X @AnatoliKopadze RT (2026-05-26)
• Fortune, May 26, 2026 — Amodei’s softened position: Fortune original