بول غراهام وأمجد مسعد عن Replit: قرارات لا تتضح قيمتها إلا لاحقًا

آخر تحديث: ١٢ نوفمبر ٢٠٢٦

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

شاهد الحوار كاملًا على يوتيوب (Y Combinator، ٤٤ دقيقة، بالإنجليزية).

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

الشركة كانت تحتاج أن تبني شيئًا جديدًا، هذا أكيد. لكن كان عندها شيء مفيد تبني عليه. ويذكر مسعد أن فرق البنية التحتية والسحابة وبيئة التطوير (IDE) بقي لها دور، وأُضيف إليها فريق جديد للوكيل.

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

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

ماذا قال مسعد بالضبط عن عمل Replit القديم؟

الجزء الذي أقصده تقريبًا من الدقيقة ١٧ إلى ١٨ في فيديو Y Combinator. كانت Replit قد بنت طريقة تسمح لعدة أشخاص أن يعدّلوا الكود ويشغّلوه في البيئة نفسها وفي الوقت نفسه. وحين بنت الشركة وكيلها، يقول مسعد إن هذا التصميم نفسه سمح للوكيل أن يشارك كمستخدم إضافي في الجلسة.

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

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

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

ماذا يبقى مفيدًا حين يتغيّر المنتج؟ درس من حوار بول غراهام وأمجد مسعد

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

في ورقتهما عن الابتكار المعماري سنة ١٩٩٠، قسمت ريبيكا هندرسون وكيم كلارك معرفة المنتج إلى نوعين. معرفة المكونات، أي أن تعرف كل جزء جيدًا. والمعرفة المعمارية، أي أن تعرف كيف ترتبط الأجزاء ببعضها لتصنع كلًّا واحدًا (ص ١١). وفكرتهما أن مكونات مألوفة يمكن أن تُربط بطريقة مختلفة، فيخرج منتج يحتاج فهمًا مختلفًا للنظام كله.

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

ثم قالا شيئًا أتمنى أن يقرأه كل رئيس تنفيذي مرتين. المنشأة تبني هيكلها حول بنية المنتج. شركة المراوح تنشئ فريقًا للشفرات وفريقًا للمحركات، والذين يعملون على المحرك والشفرة يتبعون نفس المدير ويجتمعون كل أسبوع (ص ١٥). ومع الوقت، يصير الهيكل التنظيمي وقنوات التواصل نسخة من التصميم القديم. ولهذا قد يصعب أن ترى البنية الجديدة من داخل شركة تعرف كل مكوّن معرفة ممتازة.

وبحثهما لم يقف عند هذا المثال. على مدى أربعة عشر شهرًا، من مارس ١٩٨٧ إلى مايو ١٩٨٨، قابلا أكثر من مئة شخص في صناعة معدات المحاذاة الضوئية لأشباه الموصلات، ودعما المقابلات بسجلات الشركات الداخلية حيث أمكن (ص ١٩). الورقة درست معدات صناعية، لا وكلاء ذكاء اصطناعي يكتبون الكود، ولا تثبت ما حدث داخل Replit. لكنها تعطينا تمييزًا واضحًا لفهم رواية مسعد: قيمة القدرة الموجودة سؤال، وشكل المنتج القادم سؤال آخر.

رسم توضيحي مبني على رواية مسعد في حوار YC، تقريبًا من الدقيقة ١٧ إلى ١٨. هو رابط مفاهيمي، وليس البنية التقنية لـ Replit.

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

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

لماذا صار هذا السؤال أهم مع وصول الذكاء الاصطناعي؟

لأن كل نظام قديم تقريبًا على وشك أن يلتقي باستخدام جديد، أو بمنافس جديد. في استطلاع المنتدى الاقتصادي العالمي، قال ٨٦٪ من أصحاب العمل إن تقنيات الذكاء الاصطناعي ومعالجة المعلومات ستغيّر أعمالهم جذريًا بحلول ٢٠٣٠ (WEF، تقرير مستقبل الوظائف ٢٠٢٥، ص ١١، الشكل ١٫٢).

والقرارات القديمة تأتي معها فاتورة. معهد IBM لقيمة الأعمال استطلع ١٣٠٠ من كبار صنّاع قرار الذكاء الاصطناعي في منشآت كبيرة في ١٧ دولة (ص ٢ و١٨). ويعرّف الدين التقني بأنه النتيجة المتراكمة لقرارات تقنية سابقة، ويقول إن مشاريع الذكاء الاصطناعي ترث أوضاع البيئة التقنية التي تدخلها (تقرير IBM IBV عن الدين التقني، ص ٤).

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

هذا ما تقوله الأبحاث، في مكان واحد:

أقرأ أرقام IBM على أنها ما قاله التنفيذيون لـ IBM، لا نتائج مقاسة. وIBM تبيع أيضًا خدمات التحديث، فأتعامل مع طريقة طرحها ببعض الحذر. لكن الاتجاه نفسه يظهر عند PwC التي سألت ٤٤٥٤ رئيسًا تنفيذيًا. نصيحة PwC أن تبني أسس الذكاء الاصطناعي، وأول أساس تذكره هو بيئة تقنية تسمح بدمج الذكاء الاصطناعي (PwC، الاستطلاع العالمي التاسع والعشرون للرؤساء التنفيذيين، ص ٧).

وصراحة، القراءة المنصفة لكل هذا تمشي في الاتجاهين. الأنظمة القديمة قد تبطّئ الذكاء الاصطناعي، وقد تكون أيضًا سبب نجاحه. IBM تذكر مثالًا من مواردها البشرية: تقول إن أطر السحابة القابلة لإعادة الاستخدام التي بناها فريق تقنية المعلومات عندها أثناء توسيع مساعد AskHR صارت القالب لتطبيق الذكاء الاصطناعي في وظائف مثل المالية والمشتريات، ومهّدت لمساعد تقنية المعلومات AskIT (ص ١٦). هذه IBM تحكي قصتها هي، فأتعامل معها كما أتعامل مع رواية مسعد: رواية مفيدة، لا دليل قاطع.

لماذا يبدو الماضي أوضح مما كان؟

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

عالم النفس باروخ فيشهوف درس هذه المشكلة في بحثه عن الحكم بأثر رجعي سنة ١٩٧٥. قرأ المشاركون، وأغلبهم طلاب جامعيون، قصصًا قصيرة عن أحداث تاريخية أو حالات علاجية (ص ٢٩٠). بعضهم قرأ القصة بدون نتيجة. وآخرون قرأوا نفس الخلفية مع نتيجة مذكورة في آخرها.

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

وفي تجربة أخرى، طُلب من المشاركين أن يجيبوا «كما كانوا سيجيبون لو لم يعرفوا ما حدث» (ص ٢٩٣). ومع ذلك بقيت أحكامهم متأثرة بالنتيجة. الناس بالغوا في تقدير ما كانوا سيعرفونه بدونها (ص ٢٨٨). وهذا يعني أن نقول لأنفسنا «كن منصفًا» قد لا يكفي لنستعيد شعور عدم اليقين كما كان.

ملخص مفاهيمي لتصميم تجارب فيشهوف ونتائجها. الرسم لا يعرض حجم الأثر.

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

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

كيف نحكم على القرار نفسه قبل أن نعرف نتيجته؟

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

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

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

حين أناقش مشروعًا قديمًا، أحب أن أفصل هذه الأسئلة عن بعضها:

هذه طريقة لإبقاء النقاش صادقًا، وليست نظام تقييم بالدرجات. والإجابات قد تختلف من جزء لآخر في نفس المنتج.

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

ماذا تراجع قبل أن تُبقي نظامًا قديمًا أو توقفه؟

هذه المراجعة التي أعملها، وبهذا الترتيب، قبل أن تقرر مبادرة ذكاء اصطناعي مصير شيء أقدم منها.

1. اكتب لماذا بُني، من سجلات وقتها. افعل ذلك قبل أن يتكلم أحد عن خطط الذكاء الاصطناعي اليوم. وإلا ستكتب النهاية التاريخ بدلًا منك.
2. سمِّ القدرة، لا النظام. «نظام الموارد البشرية» أكبر من أن يُحكم عليه. أما «سجلات موظفين تطابق التأمينات الاجتماعية والرواتب كل شهر» فشيء تستطيع أن تختبره.
3. اسأل ماذا تغيّر فعلًا. هل ظهرت إمكانية تقنية جديدة، مثل وكيل يستطيع أن يعمل كمستخدم؟ أم حاجة جديدة عند الإدارة؟ كن محددًا بما يكفي ليُري الفريق الرابط بنفسه.
4. احسب الدين لاستخدام واحد. نصيحة IBM أن تحمل كل مبادرة ذكاء اصطناعي بندًا لتكلفة الدين الذي يجب أن تعالجه لتنجح (ص ١٠). ليس تنظيف كل شيء. فقط ما يحتاجه هذا الاستخدام.
5. افصل القدرة عن طريقة العمل حولها. البيانات والقواعد تحت قد تستحق أن تبقى. والموافقات والتسليمات فوقها قد تحتاج إعادة تصميم رغم ذلك، وهذا ما فعله الأعلى أداءً في استطلاع McKinsey.

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

هل هذا سبب للاحتفاظ بكل مشروع قديم؟

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

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

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

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

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

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

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

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

الأسئلة الشائعة

ماذا قال أمجد مسعد لبول غراهام عن البنية القديمة في Replit؟

في حوار Y Combinator، تقريبًا من الدقيقة ١٧ إلى ١٨، يقول مسعد إن Replit كانت قد بنت طريقة تسمح لعدة أشخاص بكتابة الكود معًا في البيئة نفسها. وحين بنت وكيلها الذكي، سمح هذا التصميم للوكيل أن ينضم كمستخدم إضافي. ويضيف أن فرق البنية التحتية والسحابة وبيئة التطوير بقي لها دور، مع فريق جديد للوكيل. هذه روايته هو.

ما هو الحكم بأثر رجعي؟

هو ميلنا إلى أن نرى النتيجة متوقعة أكثر بعد أن نعرف أنها حدثت. في تجارب باروخ فيشهوف سنة ١٩٧٥، الذين أُخبروا بالنتيجة رأوها أكثر احتمالًا، وتغيّر عندهم أي الحقائق مهم. وحتى حين طُلب منهم تجاهل النتيجة، لم يستطيعوا تمامًا. وبالنسبة للقادة، يعني هذا أن القرارات القديمة كثيرًا ما تبدو أحكم أو أسخف مما كانت.

ما هو الابتكار المعماري؟

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

هل نستبدل نظام الموارد البشرية القديم قبل إضافة الذكاء الاصطناعي؟

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

كيف أعرف أن نظامًا قديمًا يستحق أن يبقى؟

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

المراجع

• Y Combinator، Paul Graham in conversation with Amjad Masad (بالإنجليزية)، فيديو على X (وعلى يوتيوب) (تقريبًا من الدقيقة ١٧ إلى ١٨: عمل البرمجة المشتركة سمح للوكيل أن يعمل كمستخدم آخر، وبقيت فرق البنية التحتية والسحابة وبيئة التطوير مع فريق جديد للوكيل. رواية مسعد نفسه، ولم يُتحقق منها بشكل مستقل).
• Rebecca Henderson وKim Clark، Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms (PDF) (بالإنجليزية)، Administrative Science Quarterly، المجلد ٣٥، العدد ١، ١٩٩٠، ص ٩ إلى ٣٠ (ص ١١ معرفة المكونات والمعرفة المعمارية؛ ص ١٢ و١٣ مثال المروحة؛ ص ١٥ قنوات التواصل تحمل المعرفة المعمارية؛ ص ١٩ مقابلات مع أكثر من مئة شخص من مارس ١٩٨٧ إلى مايو ١٩٨٨).
• Baruch Fischhoff، Hindsight ≠ Foresight: The Effect of Outcome Knowledge on Judgment Under Uncertainty (PDF) (بالإنجليزية)، Journal of Experimental Psychology: Human Perception and Performance، المجلد ١، العدد ٣، ١٩٧٥، ص ٢٨٨ إلى ٢٩٩ (ص ٢٨٨ ملخص النتائج؛ ص ٢٩٠ عينات الطلاب؛ ص ٢٩٣ التجربة الثانية).
• المنتدى الاقتصادي العالمي (WEF)، Future of Jobs Report 2025 (PDF) (بالإنجليزية)، يناير ٢٠٢٥ (ص ١١، الشكل ١٫٢: ٨٦٪ من أصحاب العمل يتوقعون أن تغيّر تقنيات الذكاء الاصطناعي ومعالجة المعلومات أعمالهم بحلول ٢٠٣٠).
• معهد IBM لقيمة الأعمال، The tech debt reckoning: A practical approach to boosting your AI ROI (PDF) (بالإنجليزية)، نوفمبر ٢٠٢٥ (ص ٢: استطلاع ١٣٠٠ من كبار صنّاع قرار الذكاء الاصطناعي، و١٧ دولة؛ ص ٤: تعريف الدين التقني ووراثة المشاريع للأوضاع القائمة؛ ص ٧: من ١٨٪ إلى ٢٩٪ من تكلفة التنفيذ حتى ٢٠٢٧، و٦٩٪ يتوقعون أن تصبح بعض المبادرات غير مجدية ماليًا؛ ص ٨: مثال مساعد الموارد البشرية؛ ص ٩: ٢٩٪ فقط حسبوا التكلفة الكاملة؛ ص ١٠: بند لكل مبادرة؛ ص ١٣: ٨٠٪ يرون أن معالجة الدين في مبادرة تفيد المبادرات المرتبطة؛ ص ١٦: رواية IBM عن AskHR وAskIT؛ ص ١٨ (صفحة الملف ٢٠): المنهجية و١٧ دولة. أرقام الصفحات هي المطبوعة؛ أضف ٢ لرقم صفحة الملف).
• PwC، 29th Global CEO Survey: Leading through uncertainty in the age of AI (PDF) (بالإنجليزية)، يناير ٢٠٢٦ (ص ٥: ٥٦٪ لم يروا زيادة إيرادات ولا خفض تكاليف من الذكاء الاصطناعي، و١٢٪ رأوا الاثنين؛ ص ٧: أسس الذكاء الاصطناعي ومنها بيئة تقنية تسمح بدمجه؛ ص ٢٣: ٤٤٥٤ رئيسًا تنفيذيًا في ٩٥ دولة وإقليمًا).
• McKinsey & Company، QuantumBlack، The state of AI in 2025: Agents, innovation, and transformation (PDF) (بالإنجليزية)، نوفمبر ٢٠٢٥ (ص ١٦، الشكل ١١: ٥٥٪ من الأعلى أداءً أعادوا تصميم مسارات العمل من الأساس مقابل ٢٠٪ من البقية؛ ١٩٩٣ مشاركًا).