في يناير 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 قائمة على 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. أرقام الأداء مبنية على بيئة المؤلف وتتطلب إعادة تحقّق في الواقع.

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

In the spring of 2026, an intriguing assessment began circulating in the tech investor community: “Jensen Huang might be the best stock picker on Wall Street — even though he never picks stocks himself.” This was not a statement Huang made. It was a label attached by market observers.

The evidence was specific. Companies Huang mentioned in public appearances and keynotes — Nebius (+840%), Applied Digital (+1,400%), TSMC (+135%), Micron (+770%) — surged after his remarks. He never once said “buy this company,” yet the moves happened.

Why does this story speak to decision-making culture? Huang’s words moved markets not because of luck or some special intuition. He was reading the data flows of the AI ecosystem — chip demand, cloud infrastructure investment, the beneficiary structure at the software layer — in an unusually systematic way. What looked like intuition was the judgment of someone who structures data rigorously.

That is the starting point for this article. The substance behind seemingly intuitive, outstanding judgment is data structuring.

Inheriting Moneyball: Is the Age of Intuition Over?

In our previous post (Building a Data-Driven Organizational Culture with Moneyball Thinking), we told the story of the 2002 Oakland Athletics. Billy Beane unearthed the undervalued metric of on-base percentage and produced 103 wins on one-third of a typical payroll.

That post rested on two core propositions: the metrics you have been using may be wrong; and undervalued resources found through data yield maximum efficiency.

In the age of AI, these propositions return as a much sharper question: how much room is left for intuition?

In baseball, a scout’s experience and eye were the gold standard of evaluation for decades. They were not wrong. But data controlled for more variables and produced better predictions. Decision quality was better explained by the quantity and structuring capacity of available data than by human experience.

Organizations in the AI era face this structural shift even more fundamentally. Models process thousands of variables simultaneously, discover patterns, and reduce their own prediction error. The traditional strengths of intuition — accumulated experience, pattern recognition, rapid judgment — are precisely the areas where AI is pulling ahead.

So how should an organization’s decision-making structure change?

Instrument Your Decisions: Turning Choices into Data

The core of Moneyball thinking is not changing performance metrics. It is making decisions themselves measurable.

The Oakland A’s chose on-base percentage not merely because they believed it was a more important metric. They proved the causal relationship between runs scored and OBP with numbers. Because the link between the metric and the outcome was data-backed, they could execute that judgment repeatedly.

Organizational decision-making follows the same structure.

How Do You Tell a Good Decision from a Bad One?

In most organizations, decision quality is reverse-engineered from outcomes. Things went well — good decision; things went badly — bad decision. But this approach carries two problems.

Good decisions can produce bad outcomes. Even when you decide as well as possible with the information available, external variables can defy your predictions. When you judge a decision by its result, hindsight bias — constructing a story after the fact to fit what happened — blocks organizational learning.

Bad decisions can produce good outcomes. This is even more dangerous. When baseless intuition happens to be correct, you start trusting that intuition, and it eventually leads to the next failure.

A data-driven decision culture begins by recording and evaluating the basis for a decision at the time it is made, not by the result.

The Decision Log: An Audit Trail for Judgment

The starting point is to explicitly record three things at the moment of decision:

• What are the assumptions underlying this decision?
• What data supports those assumptions?
• How will we know if this decision is wrong? (the falsification condition)

The third question is critical. “This feature will raise retention by 5%” is unverifiable as stated. But write it as: “If seven-day retention has not risen by at least 5% within eight weeks of launch, this assumption is wrong” — and the decision becomes measurable.

At GTC Taipei 2026, NVIDIA disclosed a model that allocates a portion of engineers’ base salaries as a token budget to measure productivity. This is not merely a change in compensation structure. It is a declaration to actually measure the outcomes of decisions about AI tool adoption. Organizations can only learn when decisions can be tracked numerically.

Where Intuition Wins: The Limits of Data

The claim that data-driven decision-making replaces intuition is only half right. There are domains where data does better, and domains where intuition is still needed.

Where Data Is Strong

In decisions where repeatable patterns exist, data overwhelms intuition.

• Predictions with sufficient history (conversion rates, churn rates, demand forecasting)
• Experiments with clear success metrics (A/B tests, feature flags)
• Extracting signals from large-scale data (user segmentation, anomaly detection)

In these areas, intuition does not beat data. Even an experienced PM saying “users will love this feature” turns out to be wrong far more often than expected once you run the experiment. A finding commonly reported across large tech companies’ A/B testing experience is that features considered “certain wins” internally frequently fail to perform as well as hoped in actual experiments.

Where Intuition Is Still Needed

The domain where data is weak is situations without precedent.

New markets, new technology paradigms, early-stage decisions where data has not yet accumulated — in these situations there is simply no data from which patterns can be learned. The Oakland A’s could surface on-base percentage because decades of baseball records existed. If it were an entirely new sport, you would have to invent the concept of on-base percentage itself.

Here, intuition’s role is to set the direction of data collection. Deciding “what data should we gather?” remains a human judgment. Huang’s ability to read the flow of AI infrastructure demand came from decades of direct experience in the semiconductor and software ecosystem. When that judgment is validated by data, it becomes “systematic insight that looks like intuition.”

The Data Theater Trap

There is one more pitfall to guard against. The pattern of appearing to use data while actually selecting data to justify a conclusion already reached — this is called “data theater.”

The symptoms look like this. A decision is made first. Then only the data supporting that decision appears in the report. Contradicting data is excluded on grounds that “the context is different” or “the sample is too small.” The form is data-driven; in substance it is intuition with a data wrapper.

There is a reason data theater is more dangerous than pure intuition. When intuition is wrong, you can admit “my judgment was wrong.” When data theater is wrong, it leads to the defense “the data we looked at was faulty,” and learning is blocked.

The Conditions Under Which Data Beats Intuition in an Organization

Even with good data, an organization’s decisions often do not change. Data beating intuition is not a technology problem — it is a culture and structure problem.

Condition 1: Falsification Must Be Safe

You need an environment where it is possible to say “this data refutes our hypothesis.”

In many organizations, when an experiment shows that a feature proposed by an executive is ineffective, it is difficult to report that result as-is. Hierarchical structure distorts data. When a leader first demonstrates that “my hypothesis could be wrong,” the rest of the organization follows.

Amazon’s “disagree and commit” culture addresses exactly this point. Executing a decision you disagree with, and continuing to validate it with data while executing it, are not contradictions. When these two things work together, data becomes meaningful.

Condition 2: The Unit of Decision Must Be Small

In a structure where big decisions are made all at once, it is hard for data to influence decision-making. A company that sets its roadmap every six months cannot easily change direction even when data comes in mid-cycle.

Breaking decisions down is the practical structure of a data-driven culture. “Should we spend three months developing this feature?” is a worse question than “Can we validate the core assumption with a two-week prototype?” Small decisions enable rapid learning and allow data to actually change direction.

The proposition we raised in the Moneyball article — “a team that takes three weeks to run an A/B test versus one that takes three days will have ten times the learning one year later” — goes deeper here. The difference in learning speed is not a difference in the amount of data; it is a difference in the size and frequency of the decision unit.

Condition 3: Past Decisions Must Be Traceable

You must be able to answer “why did it turn out this way?”

In many organizations, the reasoning behind important decisions disappears. The people in the room at the time leave the company; Slack channels get archived; the data from that moment was never saved. New team members see only the outcome of a decision and cannot know why it was made.

When decision logs become as natural a practice as code review, an organization can learn from its own patterns of judgment. What kinds of decisions do we get wrong repeatedly? What assumptions keep collapsing? When these become visible, you can use data to correct the biases of intuition.

AI Agents and the Changing Structure of Decision-Making

At GTC Taipei 2026, Huang said “every engineer is going to have and manage hundreds of agents.” This is not simply a change in tools. It is a change in the very structure of decision-making.

When agents handle repetitive and pattern-based tasks, the domain where human judgment needs to concentrate shifts. Distinguishing between decisions that can be delegated to agents and decisions that humans must make directly — this distinction itself becomes a new core competency.

Adopting agents is not the completion of a data-driven decision culture. Rather, the more important question is how humans audit and validate the premises and outcomes of the decisions agents make. Agents also make biased decisions when trained on biased data. For agent decisions too, you must ask: “What are the premises of this decision? What are the falsification conditions?”

Just as Paul DePodesta built statistical models in Moneyball, organizations that operate agents must explicitly design which decisions are delegated to agents and on what basis those decisions are trusted.

Implications for Organizations: Three Actionable Steps

A data-driven decision culture is not about building more dashboards. It is about changing the structure of decisions.

First, write down the falsification conditions for a decision in advance. Before launching a feature, the team agrees together on what data would mean the decision was wrong. Narrowing the room for interpretation before the results come in is the most practical way to prevent data theater.

Second, turn wrong decisions into learning assets. Failed experiments should not disappear — they must remain accessible to the whole team. A post-mortem that documents “why did this feature not work?” becomes an input to the next planning cycle. Past failures correct future intuition.

Third, design agent decisions so they are auditable. There needs to be a structure in which it is possible to explain after the fact “on what data did this agent make what judgment?” The moment an agent’s reasoning becomes a black box, that organization has ceased to be data-driven and has regressed to agent-based intuition.

ThakiCloud’s work building a Kueue-based agent scheduling infrastructure can be read in this context. How agents distribute workloads, and whether the reasoning behind those decisions is preserved in logs — this is the foundation of platform trust.

Conclusion: Intuition Does Not Disappear, It Just Finds a New Place

The question “if AI were the best decision-maker” starts from a false premise. There are decisions where AI and data do better, and decisions where human experience and judgment do better. What matters is not which is superior overall, but designing who makes each decision based on the nature of that decision.

Billy Beane of Moneyball did not discard the scouts’ intuition. Human judgment was still needed for what data could not explain — a player’s mentality, team chemistry, positioning in a new market. What he built was not “an organization that eliminated intuition” but “an organization that was clear about where intuition should intervene.”

The reason Huang came to be called “the best stock picker” in the market is not that he lacks intuition. It is that decades of reading the semiconductor ecosystem through data accumulated, making his judgment look like pattern recognition. Ultimately, outstanding intuition is the product of long-term data structuring.

A decision culture where data beats intuition is one that creates a loop in an organization — a loop that starts with data and in which intuition reflects and revises itself. Organizations that keep that loop running continuously make better decisions over the long term.

Sources

• Jensen Huang, “Every engineer is going to have and manage hundreds of agents.” — NVIDIA GTC Taipei 2026 keynote, 2026-05-20 / 2026-06-01. NVIDIA official blog: 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.” — External market-observer assessment (not a statement by Huang himself). @InTheAssembly X thread: https://x.com/InTheAssembly/status/2053801122632958342
• Jensen Huang, NVIDIA engineer token budget remarks — GTC Taipei Computex 2026 keynote transcript. Semiconalpha Substack: https://semiconalpha.substack.com/p/nvidia-keynote-computex-2026-key
• Nebius, Applied Digital, TSMC, Micron stock price data — @InTheAssembly X thread (same source as above)
• ThakiCloud blog, “Building a Data-Driven Organizational Culture with Moneyball Thinking” (the article this one continues): https://thakicloud.github.io/culture/moneyball-data-driven-culture/

In January 2026, two figures sat side by side at the World Economic Forum in Davos: Demis Hassabis of DeepMind and Dario Amodei of Anthropic. The atmosphere was electric. This was an era in which large language models were solving mathematical olympiad problems, dominating humans at Go, and predicting protein structures. Voices from across the industry were declaring AGI just around the corner.

Hassabis said otherwise.

“Today’s systems are nowhere near [AGI]. It doesn’t matter how many Erdős problems they solve.” (Original quote: “Today’s systems are nowhere near [AGI]” — Fortune, January 23, 2026)

Erdős problems are among the most fiendishly difficult mathematical puzzles in the world. If AI can solve them, that is certainly impressive. But Hassabis was categorical: that is not the benchmark for AGI. Why?

This question is the starting point of this post. It isn’t only a conversation for AI researchers. It concerns every organization that adopts AI, builds AI teams, or ships AI products.

The Line Hassabis Drew: “Understanding” vs. “Pattern Matching”

The benchmark Hassabis proposed for AGI is not “solve Erdős problems.” His standard is higher. Multiple outlets reported the so-called “Einstein Test”: the ability to independently propose a genuinely novel physical theory — a system with real understanding, not statistical pattern reproduction.

So where do today’s LLMs stand? No matter how vast the training data or how sophisticated the simulated reasoning, whether that constitutes “understanding” or merely “statistical pattern reproduction” remains an open question. Hassabis himself, in the same Davos panel, said “one or two more breakthroughs are still needed.” His timeline: “5 to 10 years.”

The story did not end there.

A Timeline Shift in Four Months: The Intentional Use of Provocative Language

About four months after the Davos remarks — on May 26, 2026, in an interview with Axios shortly after Google I/O — Hassabis struck a different tone. He suggested “AGI will probably arrive within the next five years.” Some outlets summarized this as “AGI in 3 to 4 years,” and the statement spread quickly.

Yet in the same interview, Hassabis added: “some of the terms I used were a little bit provocative.” (Original: “some of the terms I used were a little bit provocative” — Axios, 2026-05-26)

The careful January statement and the upgraded May timeline. The same person, in the same year, speaking in different contexts. Which reflects the “real” Hassabis?

Probably both. That very tension illustrates exactly why expectation management must become a cultural practice.

The Scars a Hype Cycle Leaves on Organizations

AI is an industry unusually prone to rapid hype cycles. You don’t need to consult Gartner’s Hype Cycle to recall how many times “this time is different” has been proclaimed over the past decade: the deep learning revolution, the chatbot era, GPT-3, ChatGPT, agentic AI. With every cycle, organizations invest in excitement, collide with reality, feel disappointed, and wait for the next wave.

This pattern leaves three kinds of scars on organizations.

First, the erosion of trust capital. If you announce “AI will solve this problem in six months” and then fail, the next time you bring a genuinely meaningful AI proposal, people will stop listening. Once leadership credibility is chipped away, it is hard to restore.

Second, the distortion of how failure is defined. When you start from exaggerated expectations, even genuinely substantial progress gets stamped as “failure.” Teams carry a sense of defeat into the next project rather than legitimate pride in achievement. Burnout and attrition follow.

Third, loss of direction. Projects launched by riding hype are hard to steer. “Build AI that’s like AGI” tells your team nothing. What should it build? How should success be measured? When is “enough” enough? Without answers to these questions, teams drift.

What Hassabis Practices: A Philosophy of Roadmaps

DeepMind’s trajectory reveals how expectation management is actually practiced.

AlphaGo (2016) targeted a clearly defined problem: Go. AlphaFold (2020) solved a verifiable scientific problem: protein structure prediction. AGI? For Hassabis, it remains a future challenge that still requires “one or two more breakthroughs.”

The pattern in this roadmap is consistent. Each stage first defines a goal achievable with current capabilities, actually achieves it, then prepares for the next. Rather than the slogan “AGI in five years,” the question is: “What will we prove at this stage?”

This should not be read as a conservative posture. That Hassabis admitted in May 2026 that “some of the terms I used were a little bit provocative” also signals that he understands the value of ambitious language in raising expectations. The key word is “intentional.” He knows precisely where the certainty ends and the deliberate provocation begins.

What Expectation Management Culture Actually Means

In AI organizations, “expectation management” often sounds negative — misread as a defensive posture of “lower your expectations” or “preempt disappointment.” Hassabis’s approach is nothing of the sort.

Honest expectation management comes down to three things.

1. Use language that distinguishes current capability from future possibility. “This model can do X” and “If we go this direction, X will become possible” are different statements. Clearly separating these two for teammates, boards, and customers is the foundation of trust — just as Hassabis distinguished “today’s systems” from “systems after one or two more breakthroughs.”

2. Define success criteria measurably. “Improve operational efficiency through AI” cannot tell you whether you succeeded. “Reduce processing time for task X by 30% six months after AI adoption” has a clear answer. Just as AlphaFold defined protein structure prediction accuracy numerically against the previous state of the art, AI projects must do the same.

3. Build a culture where not knowing is sayable. That Hassabis could admit “some of my terms were a bit provocative” is itself evidence that such admissions raise rather than lower trust. If no one inside an organization can say “we don’t know yet,” “this is harder than expected,” or “we need to adjust the timeline,” people will only pass good news upward and hide the bad. Those hidden problems will eventually detonate all at once.

Breaking the Disillusionment Cycle

The most common failure pattern in AI adoption is simple: start with excitement → over-promise → hit the wall of reality → feel disappointed → “AI turns out to be nothing special” → suspend investment until the next hype wave.

Breaking this cycle requires an intermediate step. Start with excitement, but define an achievable first stage; actually achieve that stage; make the results visible; then move to the next.

This is not the same as “think small.” DeepMind started with AlphaGo, built AlphaFold, and is now moving toward AGI. The destination is large, but each stage is designed realistically.

Organizations that make this work share a common habit. When they begin a new AI initiative, they first ask: “What does success look like at this stage?” They check at six months whether that question can be answered. When things fall short, they record “why did reality diverge from expectation?” That record makes the next project’s expectations slightly more grounded.

Implications for Organizations: Turn Realism into a System

If Hassabis’s realism remains a personal virtue, it disappears when that person leaves. Turning expectation management into organizational culture requires systems.

At ThakiCloud, we encounter this challenge frequently. As a company building an AI platform, we feel the tension every day between explaining AI’s possibilities to customers and honestly describing its limits. Tilt too far one way and you over-promise; tilt too far the other and you miss the opportunity.

One practice we have been trying: at the start of a project, explicitly writing a list of “what we will not achieve in this stage” — not just what we intend to do, but what we explicitly will not do. Experience has taught us that the “will not” list is more effective at calibrating expectations to reality than the “will do” list.

That Hassabis can say “today’s systems are nowhere near AGI” is not because he is pessimistic about the future of AI. He is the person who reshaped the landscape of biology with AlphaFold. Stating clearly the limits of current systems is a way of setting direction toward the next breakthrough.

Realism is not abandoning the dream. It is measuring the distance to that dream precisely.

Conclusion: Honesty Is the Strongest Cultural Asset

In the AI field, the easiest thing to do is excite people. “AGI is coming in three years,” “this model changes everything,” “if you don’t get on board now, you’re too late.” Words like these attract investment, increase recruiting inquiries, and generate media attention.

The hardest thing is to say, inside that excitement: “But this is not yet possible right now.”

Hassabis said that hard thing at Davos in January 2026. Solving Erdős problems is not AGI. One or two more breakthroughs are still needed. And in May, he freely admitted he had intentionally used provocative language.

When these two postures work together, organizational trust accumulates. Stating limits clearly. Admitting when you have overstated. The slow accumulation of honesty is a far stronger cultural asset than the short-term attention won by a single piece of hype.

For those leading AI organizations, Hassabis’s approach offers a useful benchmark. What can current AI do? What can it not yet do? What is the next stage, and what breakthrough does it require? A culture that answers these three questions honestly is the foundation of a sustainable AI organization — whether or not AGI ever arrives.

Sources

• 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/