تنظيم: آيينغ
شارك بوريس تشيرني، مؤسس Claude Code، في مؤتمر Sequoia، وكانت معلوماته غنية جدًا، وسمعت لأول مرة العديد من الآراء بشكل كامل. هذا الرجل فهم الذكاء الاصطناعي بشكل جيد حقًا.
أشارك ملخصي الخاص.
01 الكود لم يعد نادرًا
للمشاهدات الرئيسية الكبيرة، أصبح كتابة الكود يدويًا أمرًا غير فعّال.
في الماضي، عندما كان يجب تسليم ميزة، كان المهندس يجلس ويفكر أولاً في كيفية التنفيذ، ثم يكتب الشيفرة سطرًا سطرًا. خلال هذه العملية، كانت القيمة الأكبر للمهندس هي: هل يكتب أم لا، وهل يكتب جيدًا أم لا، وهل يكتب بسرعة أم لا.
الطريقة الحالية مختلفة.
نفس الوظيفة، ما يفعله المهندسون يشبه أكثر: أولاً توضيح المتطلبات، وتقسيم المهمة إلى أجزاء عدة وتكليفها للوكيل، وتحديد معيار قبول، ثم التحقق مما إذا كانت النتائج التي أنتجها الوكيل صحيحة، وإذا لم تكن، تعديل التوجيهات وإعادة تشغيله.
يمكن للذكاء الاصطناعي الآن التعامل مع معظم مهام البرمجة. بالطبع،这不是 100٪، فما زالت هناك مكتبات كود ضخمة ومعقدة، ولغات نادرة أو بيئات خاصة، حيث لا تزال أداء النماذج اليوم غير كافٍ.
بشكل عام، أصبحت قيمة المهندس تكمن ليس في قدرته على كتابة الكود، بل في قدرته على تقسيم المهام، وشرح الأهداف بوضوح، وقبول النتائج، وإدارة الوكلاء.
هذا التغيير يشبه إلى حد كبير الثورة الصناعية.
قبل الثورة الصناعية، كان الحداد يقوم بجميع المهام من السحب والتشكيل والصقل إلى التجميع بنفسه. كان الحدادون ذوو المهارة العالية يُقدَّرون كثيرًا.
ثم ظهرت خطوط الإنتاج. كل عامل كان مسؤولًا عن عملية واحدة فقط، لكن الإنتاج الكلي كان أعلى بعشرات إلى مئات المرات مقارنة بعصر الحرف اليدوية.
في هذه المرحلة، لم يعد الدور القيّم في المصنع هو الحرفي الذي يُتقن أفضل تنفيذ لخطوة واحدة، بل الشخص الذي يستطيع تصميم وإدارة خط الإنتاج بشكل جيد وضمان سيره بسلاسة.
لم يختفِ العمال، لكن دور العمال تغير.
يمر هندسة البرمجيات حاليًا بتحول مشابه. لم يعد الكود نفسه نادرًا. القدرة على كتابة الكود تصبح مهارة أساسية مثل القدرة على استخدام PPT.
ما هو نادر حقًا هو القدرة على تقسيم المتطلبات الغامضة إلى مهام واضحة، والقدرة على اختيار أفضل حل من بين الخيارات المتعددة التي يقدمها العامل، والقدرة على جعل مجموعة من الذكاءات الاصطناعية تعمل معًا لإكمال مهمة واحدة.
في الواقع، لم يكن العديد من المهندسين القدامى قادرين على قبول هذا الأمر في البداية. فكتابة الكود يدويًا كانت سببًا لحب الكثيرين لهذا المجال على مدار العقود الماضية.
إعطاء هذا للآلة، بالنسبة للكثيرين، ليس مجرد تغيير في طريقة العمل، بل إعادة تشكيل للهوية.
لكن الاتجاه هو الاتجاه.
02 مثل مطبعة غوتنبرغ
يتحول البرمجة من مهارة متخصصة إلى مهارة أساسية. يمكن مقارنة هذا الأمر بطباعة أوروبا في القرن الخامس عشر.
قبل اختراع الطباعة، كان حوالي 10% فقط من سكان أوروبا يجيدون القراءة والكتابة. وكان هؤلاء الأشخاص غالبًا يعملون لصالح النبلاء غير المتمكنين من القراءة والكتابة، ويتولون مهام القراءة والكتابة نيابةً عنهم.
ثم ظهرت طباعة الكتاب. في غضون 50 عامًا، زاد عدد الكتب المنشورة في أوروبا عن مجموع ما تم نشره في الألف سنة السابقة، وانخفض سعر الكتب بنحو 100 مرة. وبعد مئات السنين من التكيف (مع تطور نظام التعليم والبنية الاقتصادية تدريجيًا)، ارتفع معدل الإلمام بالقراءة والكتابة عالميًا إلى 70% كما هو اليوم.
يعتقد بوريس أن تأثير الذكاء الاصطناعي على البرمجيات هو ثورة طباعة متسارعة. ستُصبح البرمجيات مُدنَّسة تمامًا خلال عقود، وتصبح شيئًا يمكن لأي شخص التحكم فيه.
في النهاية، ستكون عملية إنشاء البرمجيات طبيعية تمامًا مثل إرسال رسالة نصية.
03 ما هي القدرة الأكثر أهمية؟
عندما تنخفض حواجز كتابة الكود إلى حدٍّ أدنى بفضل الذكاء الاصطناعي، فإن ما يميز قدرة الشخص حقًا هو حسّه للمنتج، وفهمه الحقيقي لمجال محدد.
على سبيل المثال. شخصان يرغبان في تطوير منتج موجه للأطباء. أحدهما مهندس يكتب الكود بسرعة، والآخر عمل لسنوات في قسم معلومات المستشفى.
في الماضي، كان احتمال أن يُنفّذ المهندس الفكرة أعلى، لأنه كان قادرًا على تحقيقها.
الآن الأمور انقلبت. أي شخص يمكنه تنفيذ الفكرة. في هذه المرحلة، يصبح الشخص الذي يفهم حقًا تدفق العمل اليومي في المستشفى أكثر قيمة، لأنه يعرف أي الميزات سيستخدمها الأطباء فعليًا وأيها تبدو منطقية فقط.
بمعنى آخر، بعد أن قلّص الذكاء الاصطناعي من عتبة التنفيذ، تضخّمت الفجوة في القدرة على التقييم.
هذا الأمر غيّر مباشرة معنى كلمة generalist.
في الماضي، عندما كنا نتحدث عن generalist، كنا نعني عادةً مهندسًا يمكنه كتابة تطبيقات iOS وWeb والخادم الخلفي على حد سواء. هذا النوع من generalist، في جوهره، لا يزال متخصصًا في جميع طبقات الهندسة داخل الفريق.
المتخصص العام المستقبلي هو متعدد التخصصات وشامل.
هناك أشخاص يفهمون المنتج والتصميم والهندسة معًا. هناك أشخاص يفهمون المنتج وعلم البيانات والهندسة معًا. كان هذا المزيج مستحيلًا تقريبًا في الماضي، لأن كل مهارة تتطلب تدريبًا متخصصًا لفترة طويلة.
لكن الآن خفض الذكاء الاصطناعي عتبة التنفيذ لكل بند، مما يسمح لشخص واحد بالعمل عبر عدة مجالات مع الحفاظ على العمق المهني.
هكذا يعمل فريق Claude Code. مدير الهندسة، ومدير المنتج، والمصمم، وعالم البيانات، والمالية، وبحث المستخدمين، الجميع يكتبون الكود.
يمكن للمصممين تشغيل نماذج التفاعل بأنفسهم لعرضها على الفريق، دون الانتظار فقط لرسم الصور وانتظار تنفيذ المهندسين.
يمكن للمالية أن تبني أداة تحليل خاصة بها لتشغيل النماذج المالية المعقدة داخل الشركة، دون الحاجة إلى الانتظار في طابور لفريق BI. بدأ زملاء البحث في المستخدمين بتشغيل البيانات بأنفسهم، وتأخذ على عاتقها الجزء الذي كان يتطلب تعاون فريق البيانات سابقًا.
لا يزال عمق خبرة كل شخص موجودًا. لكن بمساعدة الذكاء الاصطناعي، أصبح كتابة الكود لغة مشتركة للجميع.
04 حاجز SaaS ينهار
على مدار العقد الماضي، كان هناك عدة إجماعات في صناعة SaaS تُعامل كأُصول.
أولها تكلفة التحول. بمجرد أن تستخدم شركة نظامك، تتراكم فيه تدريجيًا بيانات وتكوينات وحقول وعلاقات صلاحيات تمتد لسنوات أو حتى عقود.
الانتقال إلى نظام آخر، مجرد نقل هذه الأشياء كما هي ثم إعادة نقلها، يكفي ليجعلك تشعر بالإرهاق لدرجة أنك لا ترغب في التحرك.
الثانية هي قفل سير العمل. جميع العمليات اليومية للموظفين، والتعاون بين الأقسام، ونقاط المراجعة، كلها تنمو حول هذا السااس.
تغيير النظام ليس مجرد نقل البيانات، بل هو تفكيك وإعادة بناء ذاكرة الشركة العضلية التي تراكمت على مدار السنوات الماضية.
معًا، هاتان الميزتان شكّلتا أعمق خندق حماية في صناعة SaaS في الماضي. لكن مع وجود نموذج قوي بما يكفي، بدأ منطق الأمور يتغير.
انظر أولاً إلى تكلفة التحويل. في الماضي، كان مجرد محاذاة الحقول ونسخ هيكل البيانات مرة أخرى كافيًا لجعل فريق الهندسة يعمل إضافيًا لعدة أشهر.
قم الآن بتمرير واجهات وهيكل البيانات من كلا الجانبين مباشرة إلى النموذج، واتركه يفهم علاقات التعيين بنفسه، ويتصاعد تدريجيًا نحو الحل الأمثل. ما كان سيستغرق أشهرًا قد يُنتج نسخة قابلة للاستخدام خلال أيام.
انظر الآن إلى جانب قفل سير العمل، فهو أكثر إثارة للاهتمام. في الماضي، كان سير العمل قادرًا على قفل العملاء لأنه كان معقدًا وضمنيًا ويعتمد على الأشخاص.
التفاهمات التي في أذهان الموظفين حول من يطلب الموافقة ومن يُراجع في أي خطوة، لا يمكن نقلها مباشرة.
لكن النماذج مثل Opus 4.7، فإن أقوى مهاراتها هي فهم عملية معقدة، وتفكيكها، وإعادة بنائها في بيئة جديدة. بل وقد يكون الإصدار المعاد بناؤه أكثر سلاسة من الأصل.
لذلك، فإن الخندق الذي بُني في الماضي على تراكم البيانات والعمليات، ينهار.
قد يكون هذا خبراً سيئاً لمن يطورون حلول SaaS. لكنه فرصة حقيقية لجميع العملاء الذين يستخدمون SaaS، وللفِرق التي تعدّ لتطوير جيل جديد من حلول SaaS.
05 أفضل عصر للرواد
ستكون الشركات الناشئة التي ستُحدث ثورة حقيقية في الصناعة خلال العقد القادم أكبر بعشر مرات من تلك التي حدثت خلال العقد الماضي.
السبب ليس معقدًا في الواقع.
يمكن للفِرق الصغيرة استخدام الذكاء الاصطناعي لإنتاج منتجات على مستوى الشركات الكبرى أو حتى أفضل منها. والعكس صحيح، فعندما ترغب الشركات الكبرى في استخدام الذكاء الاصطناعي فعليًا، يصبح عبئًا عليها.
How to say it?
شركة لديها أكثر من عقد ونصف من الخبرة، وقد طورت مجموعة كاملة من عملياتها التجارية، وتوزيع الوظائف، وعادات التعاون، ونظام التدريب، ومؤشرات الأداء الرئيسية. كانت هذه الأشياء في الماضي أصولًا وحاجزًا.
لكن دمج الذكاء الاصطناعي بشكل حقيقي يعني إعادة النظر في كل شيء: يجب إعادة هيكلة عمليات الأعمال، وإعادة تدريب جميع الموظفين، وكل خطوة للأمام ستواجه مقاومة داخلية هائلة، ويجب تنسيق N من الأقسام وN طبقات من الموافقات.
فريق ناشئ مكون من ثلاثة أشخاص، وضعوا الذكاء الاصطناعي كأساس افتراضي منذ اليوم الأول. فهم لا يحملون عبءً تاريخيًا يجب التخلص منه، ولا عادات يجب تغييرها، ولا أحد يحتاج إلى إقناعه. اليوم يتم التوصل إلى تفاهم واضح، وغدًا يتم إنتاج نموذج تجريبي، وبعد غد يمكن إطلاقه لاستخدام المستخدمين.
هذا الفرق في السرعة كان موجودًا أيضًا من قبل في مجال الذكاء الاصطناعي. فالمشاريع الناشئة لديها دائمًا ميزة سرعة على الشركات الكبرى. لكن الذكاء الاصطناعي وسّع هذا الفرق بمرات عديدة.
لماذا؟
بسبب قوة الذكاء الاصطناعي الأكبر، يصبح بإمكان الفرد تحريك رافعة أكبر في وحدة الزمن. فريق صغير يستخدم الذكاء الاصطناعي بشكل فعّال اليوم قد ينتج ما يعادل عشرة أشخاص في الماضي، وغدًا قد ينتج ما يعادل ثلاثين شخصًا في الماضي.
لكن وزن تنظيم الشركات الكبرى لم يخف، بل زاد بسبب ضرورة امتصاص الذكاء الاصطناعي. كلما أصبح الذكاء الاصطناعي أقوى، زاد الفرق بين تسارع الفرق الصغيرة وقوة السحب لدى الشركات الكبرى.
هذا ما يقصده بوريس بخصوص الأصول السالبة. ليس لأن الشركات الكبرى تفتقر إلى المال أو الأشخاص أو الرغبة، بل لأن العضلات التي كانت تدرّ عليها الأرباح في الماضي تعلق الآن على طريق تحقيق الذكاء الاصطناعي لقيمته الحقيقية.
06 MCP لن يموت
MCP لن تموت.
بعد أن أصبح Skill شائعًا، اعتقد الكثيرون أن MCP لم يعد ضروريًا. كما أن مؤسس OpenClaw لديه رأي مشابه.
لكن بوريس لا يرى الأمر بهذه الطريقة. فهو يعتقد أن MCP ستكون طبقة الاتصال البرمجية في عصر الذكاء الاصطناعي.
طريقة توصيل البرمجيات في الإنترنت السابق كانت عبر واجهة برمجة التطبيقات (API).
لكن المشكلة الأساسية في واجهة برمجة التطبيقات هي أنها مصممة للمهندسين. لاستخدام واجهة برمجة التطبيقات، يجب أولاً قراءة الوثائق، وطلب رمز مصادقة، وكتابة الكود، ومزامنة الحقول، ومعالجة الاستثناءات. باختصار، واجهة برمجة التطبيقات موجهة للمطورين البشريين.
MCP مختلف. إنه يسمح للنماذج بالاتصال مباشرة واستخدامها، حيث يمكن للنموذج قراءة نفسه وتشغيله، دون الحاجة إلى مبرمج ليترجم له في الوسط.
لذلك أطلق بوريس على واجهة برمجة التطبيقات اسم Human Developer Interface، وأطلق على MCP اسم Model Interface Protocol. الأول مخصص للبشر، والآخر مخصص للنماذج.
هذا يشبه إلى حد كبير ما كان يحدث في ذلك الوقت. في عصر الإنترنت المتنقل، كان يُفترض أن جميع الخدمات يجب أن تكون مُحَوَّلة إلى واجهات برمجة التطبيقات (API). في عصر الذكاء الاصطناعي، يُفترض أن جميع الخدمات يجب أن تكون مُحَوَّلة إلى MCP.
07 استخدام الكمبيوتر لا يزال مهمًا
يُشعر الكثير من الناس الآن أن هذا الاتجاه قد لا يعمل.
السبب أيضًا معقول: يستهلك الكثير من الرموز، يعمل ببطء، وغير مستقر. يبدو أكثر كأنه عرض تقني، ولا يزال بعيدًا عن أن يكون قابلاً للاستخدام فعليًا.
لكن البعد الذي رآه بوريس مختلف تمامًا.
ما يهتم به حقًا هو أن Computer Use حلّت أحد أكبر نقاط الألم في تطبيق الذكاء الاصطناعي: في العالم الحقيقي، هناك عدد كبير من الأنظمة التي لا تمتلك واجهات برمجة تطبيقات (API) ولا MCP.
وخاصة عالم الشركات.
من يدخل الشركة يدرك أن العديد من الأنظمة الأساسية فيها قديمة جدًا: أنظمة ERP وOA وأنظمة المحاسبة وعمليات الموافقة الداخلية وخلفيات سلسلة التوريد وجميع الأنظمة المخصصة. العديد منها لا تمتلك واجهات مفتوحة أو وثائق أو قدرات أتمتة. وهي موجودة هناك، ويتم تشغيلها يدويًا من قبل عدد لا يحصى من الموظفين يوميًا.
لماذا لا نقوم مباشرةً بإنشاء واجهة برمجة التطبيقات (API) لهما؟
لأنه لا يمكن تنفيذه. ربما لم يعد موردو تطوير هذه الأنظمة موجودين. قسم تكنولوجيا المعلومات لا يملك الدافع ولا الميزانية لإعادة بنائها.
لا يمكن لقسم الأعمال أن يتوقف وينتظر ستة أشهر أو عامًا. هذه الأنظمة لن تنتظر أبدًا واجهة برمجة تطبيقات مثالية لإنقاذ نفسها.
على المدى القصير، يجب أن تستمر النماذج الكبرى في تحسين قدرتها على استخدام الحاسوب.