Claude Code مؤسس في مؤتمر سيلكون فالي يقدم 7 تقييمات مهمة

تنظيم: آيينغ

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

سأشارك ملخصي الخاص.

01 الكود لم يعد نادراً

بالنسبة للعديد من سيناريوهات التطوير السائدة، أصبح كتابة الكود يدويًا أمرًا غير فعال.

في السابق، عند تسليم وظيفة، يجلس المهندس، يفكر جيدًا في كيفية التنفيذ، ثم يكتب الكود سطرًا سطرًا. في هذه العملية، القيمة الكبرى للمهندس كانت: هل يستطيع الكتابة، هل يكتب بشكل جيد، هل يكتب بسرعة.

الطريقة الحالية للعمل مختلفة.

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

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

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

هذا التغيير يشبه الثورة الصناعية.

قبل الثورة الصناعية، كان الحداد يقوم بكل الأعمال من الحديد، الصب، التلميع، التجميع. كل العمل كان يقوم به شخص واحد. الحداد الماهر كان يُعتبر ثمينًا.

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

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

العمال لم يختفوا، لكن دورهم تغير.

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

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

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

تسليم هذا العمل للآلة، بالنسبة لكثيرين، ليس فقط تغيير في طريقة العمل، بل إعادة تشكيل للهوية.

لكن، الاتجاه هو الاتجاه.

02 مثل مطبعة غوتنبرغ

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

قبل اختراع الطباعة، كانت نسبة الأمية في أوروبا حوالي 10%. هؤلاء غالبًا كانوا يعملون لدى النبلاء غير المتعلمين، ويقرأون ويكتبون بشكل مخصص.

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

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

وفي النهاية، سيكون كتابة البرمجيات أمرًا طبيعيًا مثل إرسال الرسائل النصية.

03 ما هي القدرة الأهم؟

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

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

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

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

أي أن، بعد أن أزال الذكاء الاصطناعي عتبة التنفيذ، زاد الفارق في القدرة على الحكم.

هذا غير المعنى التقليدي لكلمة “عام” (generalist).

في الماضي، كان “العام” يشير إلى مهندس يستطيع برمجة iOS، وWeb، والخلفية. هذا النوع من “العام” كان في جوهره مطور شامل داخلي.

أما المستقبل، فـ"العام" هو متعدد التخصصات.

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

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

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

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

الموظف المالي يمكنه بناء أدوات تحليلية لنماذج مالية معقدة، دون الحاجة للانتظار من فريق ذكاء الأعمال.

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

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

04 تآكل الحصن المنيع للـ SaaS

على مدى السنوات العشر الماضية، كانت هناك بعض المبادئ التي تعتبر بمثابة حقائق في صناعة SaaS.

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

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

الثاني هو قفل تدفق العمل. العمليات اليومية للموظفين، التعاون بين الأقسام، نقاط الموافقة، كلها تعتمد على هذا SaaS.

تغيير النظام يعني إعادة بناء كل شيء، من البيانات إلى العمليات، وهو أمر مكلف ويستغرق وقتًا.

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

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

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

أما قفل تدفق العمل، فهو أكثر إثارة. كانت العمليات معقدة، غير مرئية، وتعتمد على البشر.

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

لذا، فإن الحصون التي بُنيت على تراكم البيانات والعمليات تتفكك الآن.

بالنسبة لمن يعمل في SaaS، قد يكون هذا خبرًا سيئًا. لكن، للعملاء الذين يستخدمون SaaS، وللفرق التي تستعد لبناء SaaS جديد، هذه فرصة حقيقية.

05 عصر رواد الأعمال الأفضل

خلال العشر سنوات القادمة، الشركات الناشئة التي ستغير الصناعة قد تتضاعف عشر مرات مقارنة بالعشر سنوات الماضية.

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

كيف؟

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

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

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

هذا الفارق في السرعة، كان موجودًا سابقًا، لكن الذكاء الاصطناعي ضاعفه بشكل كبير.

لماذا؟

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

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

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

06 MCP لن يموت

MCP لن يموت.

بعد أن أصبح Skill شائعًا، يعتقد الكثيرون أن MCP لم يعد ضروريًا. مؤسس OpenClaw لديه رأي مماثل.

لكن بوريس لا يوافق. يرى أن MCP سيصبح طبقة الربط البرمجية في عصر الذكاء الاصطناعي.

في السابق، كانت طريقة ربط البرمجيات عبر الإنترنت هي API.

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

أما MCP، فهي مختلفة. تتيح للنموذج الاتصال مباشرة، وقراءة البيانات وفهمها، دون الحاجة لمترجم برمجي.

لذا، يطلق بوريس على API اسم “واجهة المطور البشري”، وعلى MCP اسم “بروتوكول واجهة النموذج”. أحدهما للمستخدم، والآخر للنموذج.

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

07 استخدام الحاسوب لا يزال مهمًا

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

الأسباب معقولة: استهلاك كبير للرموز Token، بطء في التشغيل، وعدم استقرار. يبدو كأنه عرض تقني أكثر منه تطبيق عملي.

لكن بوريس يرى الأمر بشكل مختلف تمامًا.

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

خصوصًا في عالم الشركات.

داخل الشركات، الأنظمة القديمة كثيرة. ERP، OA، أنظمة مالية، موافقات داخلية، إدارة سلسلة التوريد، أنظمة مخصصة. كثير منها لا يملك واجهات، ولا وثائق، ولا قدرات أتمتة. وهي تعمل يوميًا يدويًا من قبل الموظفين.

لماذا لا نُنشئ لها API مباشرة؟

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

والموظفون في الأقسام لا يمكنهم التوقف لستة أشهر أو سنة. هذه الأنظمة لن تنتظر أبدًا وجود API مثالي لإنقاذها.

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