a16z أحدث وجهة نظر: عندما يصبح وكيل الذكاء الاصطناعي المستخدم الرئيسي للبرمجيات

مقالة: التفكير العميق في الدوائر

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

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

البرمجيات يجب أن تُبنى من أجل وكيل الذكاء الاصطناعي

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

المنطق وراء ذلك بسيط جدًا. عندما يصبح وكيل الذكاء الاصطناعي هو المستخدم الرئيسي، فإنه يتفاعل مع النظام عبر بروتوكولات مثل API، أو CLI (واجهة سطر الأوامر)، أو MCP (بروتوكول سياق النموذج). وما هو النموذج الأكثر فاعلية حاليًا؟ هو تزويد وكيل يكتب الكود أو يستخدم API للوصول إلى أدوات SaaS، مع القدرة على الوصول إلى سير العمل والمعرفة والسياق الخاص بك. هذا الوكيل لا يقرأ ويفهم المعلومات فحسب، بل والأهم أنه يستطيع إتمام المهام عبر كتابة الكود أو استخدام API.

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

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

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

حاجز التفكير الخوارزمي: ليس كل شخص يستطيع توجيه وكيل الذكاء الاصطناعي

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

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

رد آرون ليفي كان: هذا مجرد ترقية للعمل، أنت بحاجة لتعلم مهارات جديدة. وهذا لا يختلف عن كل ثورة تكنولوجية سابقة. ذكر مثالًا مثيرًا: أحد مسوقي شركة Anthropic، استخدم Claude Code لإنجاز عمل كان يتطلب خمسة إلى عشرة أشخاص. هذا المثال مهم لأنه يُظهر أن هذا الشخص هو بالفعل مَن يمتلك التفكير المنهجي، ويفهم التقنية بشكل كافٍ ليقوم بذلك.

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

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

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

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

خوف الشركات: الفوضى في التكامل والأذونات الكابوسية

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

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

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

شركة بوكس أطلقت مؤخرًا CLI رسمي، ووصف آرون سيناريو: يمكنك تزويد Claude Code بـ Box CLI، والآن يمكنك التفاعل مع نظام بوكس بالكامل باستخدام اللغة الطبيعية، وتنسيق عمليات عبر نماذج قوية مثل Opus 4.6. يبدو الأمر رائعًا، يمكنك أن تقول: “قم برفع هذا المجلد كاملًا على سطح المكتب إلى بوكس”، أو “عالج جميع المستندات في هذا المجلد”، وهو ينفذ.

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

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

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

هل نعامل وكيل الذكاء الاصطناعي كموظف؟ الأمر ليس بهذه البساطة

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

مارتن كاسادو شارك تجربة: أعطِ وكيلك رقم هاتفه، وبطاقة ائتمان (يفضل أن تكون مسبقة الدفع من CVS)، وحساب Gmail الخاص به. في الواقع، لدى Gmail العديد من آليات التحكم في الوصول المبني على الأدوار (RBAC). يمكن أن تقول: “لقد أنشأنا أنظمة صلاحيات كثيرة، ويجب أن نعامل الوكيل كإنسان مستقل.”

لكن آرون ليفي أشار فورًا إلى مشكلة هذا النموذج: في فريق مكون من 50 شخصًا، هل سيكون هناك 100 “شخص” يتعاونون — 50 إنسانًا و50 وكيلًا — في نفس المساحة المشتركة؟ من الواضح أنني أمتلك رقابة كاملة على وكيلتي، لكن ماذا لو تعاون وكيلك مع آخرين، وبدون قصد، وصل إلى موارد لا ينبغي له الوصول إليها؟ الآن، هذا الوكيل المستقل ذو الحالة يتعامل مع معلومات الآخرين.

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

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

آرون ليفي طرح أيضًا مشكلة أمان أعمق: نحن لا نعرف بعد كيف نجعل الوكيل يحفظ الأسرار. إذا أخبرته “لا تكشف عن المعلومات الموجودة في سياق الحوار”، فحل هذه المشكلة صعب جدًا. إذا كانت كل المعلومات يمكن أن تدخل إلى سياق الوكيل، لأنه يملك صلاحية الوصول إلى الموارد، فافترض أن هذه المعلومات قد تتعرض للاختراق عبر هجمات حقن التعليمات (prompt injection).

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

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

ميزة الشركات الناشئة: احتضان الذكاء الاصطناعي بلا قيود

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

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

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

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

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

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

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

ميزانية الرموز: ساحة معركة إدارة الهندسة

هناك جزء من الحوار حول ميزانية الرموز (token) أراه واقعيًا جدًا، لكنه غريب أيضًا. قال آرون ليفي: “محادثات ميزانية الحسابات الهندسية ستكون من أكثر النقاشات جنونًا في السنوات القادمة.”

لماذا؟ لأن تكاليف الحوسبة تمثل بين 14% و30% من إيرادات أي شركة تكنولوجيا عامة. تكلفة الحوسبة ضعف تكلفة فريق الهندسة، أو ثلاثة أضعاف، والفرق بينهما قد يكون هو ربحية السهم (EPS).

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

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

هذا يشبه تحول الحوسبة السحابية في أوائل العقد الأول من الألفية، حين انتقلنا من النفقات الرأسمالية (CapEx) إلى النفقات التشغيلية (OpEx)، ثم إلى الإنفاق غير المحدود. يتذكر آرون أن مسؤولي المالية في شركة بوكس كانوا يقولون: “أنت لا تفهم، نحن شركة زراعية، نحن فقط نفهم النفقات الرأسمالية”، أو “نحن شركة نحب السحابة، نحن OpEx”. الفروقات في قواعد المحاسبة تؤثر بشكل كبير على تبني التقنية.

لكن مشكلة ميزانية الرموز أكثر دقة. كمشرف هندسي، عليك الآن أن تقرر: هل تسمح للمهندسين بحساب تكلفة الحوسبة عند كل طلب؟ هل تريد أن يكون الطلب طويل الأمد، أم قصيرًا؟ هل تريد التوازي في التجارب؟ وما هو مستوى التسامح مع إهدار الرموز (tokens)؟

قال آرون إنه يعتقد أنه يجب أن يُهدَر الكثير من الرموز، لأن ذلك يعني أننا نجرب أشياء جديدة. هل يجب أن يكون قائد الفريق سعيدًا بتشغيل 10 تجارب متوازية؟ حتى لو أهدرت 90% من الرموز، هل تختار مسار النجاح؟ أم يجب أن يخطط الفريق بشكل دقيق قبل التنفيذ؟

عندما تم تسجيل هذه المناقشة، كان الناس يشعرون بالهلع من خطة Max الجديدة لـ Claude Code، حيث تم تقييدهم بثلاثة طلبات. سيكون هذا موضوعًا واقعيًا جدًا، حتى نتمكن من بناء قدرات مركز البيانات بشكل حقيقي.

لكنني أوافق على وجهة نظر سينوفسكي طويلة المدى: ستختفي هذه المشكلة في النهاية. السبب الأكبر هو أن عليك أن تقوم بحسابات رياضية من نوع بينيوف (Benioff). إذا دفعت لموظف مبيعات شركة 1 مليون دولار سنويًا، فكم تساوي أدواته؟ وإذا دفعت لمهندس X دولار، فسيكون من الواضح أن أدواته تستحق هذا الاستثمار في مرحلة معينة.

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

مستقبل أنظمة SaaS: عودة قيمة طبقة البيانات

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

هذه مشكلة طويلة الأمد مع أنظمة مثل Workday وSAP — كم من الوصول عبر API يُسمح به؟ شركة Salesforce مرت بثلاثة إعادة تصميمات ضخمة للمنصة. هذا سؤال تقني مثير: ماذا يعني سجل النظام (system of record) عندما يرغب الناس في الوصول إلى البيانات؟

قال ستيفن سينوفسكي بشكل مباشر: “محاولة بناء أنظمة مثل SAP باستخدام برمجة Vibe coding أمر سخيف.” المعرفة في SAP لا توجد فقط في طبقة البيانات المنظمة، بل في الواجهات، وفي الوسيط، وفي طريقة استخدامك لها.

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

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

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

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

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

فكرتي: نحن نُقلل من حجم هذه الثورة

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

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

نفس الشيء حدث مع الحوسبة السحابية. اعتقد الناس أن الأمر مجرد نقل أعمال الخوادم (حوالي 60,000 خادم سنويًا) إلى مراكز البيانات الخارجية، ولم يتوقعوا أن ينمو الاستخدام بمقدار ألف مرة.

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

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

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

أعتقد أننا نمر الآن بـ"لحظة الترانزستور". استخدم ستيفن سينوفسكي مثال الأنابيب الفراغية: في وقت من الأوقات، اعتقد الناس أن ولاية داكوتا بأكملها ستُغطى بمخازن أنابيب فراغية، وأن الناس يغيرون الأنابيب وهم يرتدون زلاجات في الممرات، فقط من أجل الحرب العالمية الثانية. ثم قال أحدهم: “دعونا نستخدم الترانزستور بدلًا من ذلك.”

ربما تكون الرموز (tokens) مثل MIPS التي كانت تبيعها IBM بسعر أقل، وتزيد من مبيعاتها، لكن في النهاية، كانت تُسعر حسب MIPS، حتى أدركوا أن منحنى التكاليف ينخفض، لأنهم يصنعون MIPS بسرعة أكبر من أن يبيعوها. نفس الشيء سيحدث مع الرموز.

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

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

هذه الثورة بدأت للتو.