الترميز المستند إلى الذكاء الاصطناعي الوكيل: جلسة نقاش مع قادة المجال

مرحبًا بالجميع.

لقد استمعتم إلى الكثير من موظفي Google في Android هذا الأسبوع، أو في اليومين الأخيرين.

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

سنتحدث عن الترميز المستند إلى الوكلاء وتأثيره في العالم الواقعي.

لذا سنبدأ بتقديم أنفسنا.

اسمي "بن"، وأنا مسؤول عن علاقات مطوّري برامج Android.

لقد سمعتم مني مرة واحدة في هذا المؤتمر، ولكن دعونا ننتقل إلى اللجنة.

مرحبًا،

اسمي "فيناي"، وأنا مسؤول عن دعم جهود أدوات الذكاء الاصطناعي في Databricks.

يسرّني أن أكون هنا.

مرحبًا، أنا "لويس أرتولا".

أعمل في "خرائط Google".

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

مرحبًا، أنا "أنيس ديفيس".

أعمل في شركة Ford.

أقود بعض الفِرق الهندسية التي تطوّر منتجات الاشتراكات والولاء.

مرحبًا،

اسمي "تاي سميث".

أعمل في شركة Uber وأقدّم الدعم للمطوّرين.

هذا هو الحال على الأجهزة الجوّالة منذ فترة طويلة جدًا.

في العامين الماضيين، كان هناك تركيز كبير على هذه الفترة الجديدة والمثيرة التي نعيشها مع أدوات الذكاء الاصطناعي.

مرحبًا،

اسمي "كوشيك غوبال".

أعمل كمهندس رئيسي في Instacart، وقد بدأت هذا البودكاست حول تطوير Android باسم Fragmented.

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

حسنًا.

لدينا 30 دقيقة.

أعتقد أنّ الوقت سيمرّ بسرعة، لذا سننتقل مباشرةً إلى الأسئلة الصعبة.

في فريق Android DevRel، نسعى دائمًا إلى تسهيل وتسريع عملية إنشاء التطبيقات.

والآن، ظهر الذكاء الاصطناعي، وكما سمعتمونا نقول، "إنّه بالفعل

ونعتقد أنّ إنشاء التطبيقات أصبح أسرع وأسهل".

ولكن أودّ طرح هذا السؤال: هل نطلق التطبيقات بشكل أسرع، أم أنّنا ننشئ مجموعة كبيرة من الرموز البرمجية التي لا تؤدي إلى أي نتيجة؟

لنبدأ يا "فيناي".

حسنًا

نعم، نحن جميعًا ننظر إلى بعضنا البعض.

رائع.

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

وهذا التسارع حقيقي جدًا.

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

لكنني أراها بالتأكيد في العمل.

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

ونتيجة لذلك، أعتقد أن استراتيجيتنا قد تغيرت حول كيفية قياس الإنتاجية، أليس كذلك؟

لأنّ هناك طرقًا مختلفة للتفكير في الأمر.

نحاول معرفة كيفية رفع المتوسط، أليس كذلك؟

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

نرى مجموعة من الأدوار.

يتحرك بعض الأشخاص بشكل أسرع بكثير.

هناك أشخاص يقدّمون مئات طلبات الدمج يوميًا ويؤدون عملاً رائعًا.

لكن هذا هو نوع المجال الذي يعملون فيه.

قد يكون ذلك أكثر سهولة، أو قد يكونون أكثر طلاقة في استخدام الأدوات.

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

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

هذا هو المجال الذي استثمرنا فيه خلال العام الماضي لنفهم حقًا ما إذا كنا نشحن الميزات بشكل أسرع، وليس فقط شحن الرمز بشكل أسرع؟

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

أعتقد أنّ ما حدث هو أنّ المستخدمين يرسلون بوضوح عددًا أكبر من طلبات الدمج، وقد زاد عددها.

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

أليس كذلك؟

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

لكن أعتقد أنّ ما نراه الآن هو أنّ هذه الطريقة فعّالة.

نحن بصدد شحن المزيد.

لكننا نواجه كل عقبة لم تكن لتظهر لك في العالم السابق، أليس كذلك؟

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

نحن نقدّم المزيد، ولكن الآن أصبح الأمر أشبه بخرطوم إطفاء من المؤثرات".

لذلك، نواجه تحديات أخرى.

هذه نقطة مثيرة للاهتمام، أليس كذلك؟ لأنّه عند التفكير في الأمر، هناك العديد من الخطوات المختلفة، ولكن من منظور عام، يمكنك تقسيمها إلى ثلاث مراحل، أليس كذلك؟

هناك الترميز، والذي يتم تسريعه بوضوح.

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

ويختلف معنى الشحن حسب البلد.

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

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

"أنا أتحرك بسرعة كبيرة"، ولكنك الآن تصل إلى نقطة الاختناق التالية.

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

بل يتعلّق بالعمليات والأشخاص وكيفية تحسين ذلك باستخدام الذكاء الاصطناعي.

هذا تحدٍّ مثير للاهتمام حول كيفية تبسيط العملية من البداية إلى النهاية.

من الطرق المثيرة للاهتمام التي نفكّر فيها بشأن هذا المجال قليلاً هي: ما مدى قدرة الشخص أو الفريق على إطلاق المنتج بالكامل؟

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

يتم شحنها بشكل أسرع بكثير، أليس كذلك؟

لديهم وكالة كاملة لإيصال ذلك إلى عملائهم على الفور.

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

وبالتالي، فإنّهم يواجهون بقية المشاكل في النظام.

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

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

أنا أقول هذا منذ سنوات.

تتّبع الهندسة طريقة منظّمة جدًا في تنفيذ المهام، وكان السؤال دائمًا من جانب النشاط التجاري: "ما هي المشكلة؟"

ستحصل على 10 إجابات مختلفة لذلك.

وبعد ذلك، "حسنًا.

والآن، لنترجم ذلك إلى بعض الحلول المتعلّقة بالمنتج.

والآن، لنفكّر في ذلك لبعض الوقت.

لنتحدّث قليلاً عن التصميم.

اركلها هناك".

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

بعد ذلك، نحاول الانتقال إلى Stack Overflow، ونسخ بعض العناصر ولصقها، ثم إرسالها.

لذلك، مع الذكاء الاصطناعي، أرى أنّ أكبر تسريع في العمل يتمثّل في عمل الامتثال.

تلك الأشياء التي أردنا دائمًا تحديث XYZ، أو أردنا دائمًا ترقية إصدار Spring Boot بسرعة.

نحن نعمل على ذلك بسرعة كبيرة.

ولكن بالنسبة إلى توفير الميزات الفعلية، لا يمكنني القول إنّني لاحظت تحسّنًا كبيرًا.

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

باستثناء تلك العمليات التي ربما جاءت من دروس صعبة في الماضي، أليس كذلك؟

هل تشعر بالضغط لتغيير هذه الممارسات؟ أعتقد أنّ مراجعة الرمز البرمجي هي المثال الأبرز.

ما هو مستقبل مراجعة الرموز البرمجية برأينا؟

ما هي الإجراءات التي نتّخذها حاليًا؟

لذا، يسرّني معرفة رأيك.

هذا يعيدنا إلى النقطة التي ذكرتها سابقًا

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

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

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

لدينا الذكاء الاصطناعي لكتابتها، لا بأس.

لا، مثل ربما، كما تعلم، هل ستقوم بعمل أفضل بكثير من ذلك الوكيل؟

لا أعرف، ربما لا أقضي الوقت في مراجعة ذلك.

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

هذا ليس مجالًا بالغ الأهمية"، ثم حاول إعادة التخيل.

لا أعتقد أنّنا نعمل بهذه الطريقة اليوم، أليس كذلك؟

أما اليوم، فيمكننا القول: "هناك علاقات عامة.

أنا المهندس.

أنا أركّز على هذا الأمر.

سيرتفع السعر.

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

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

أوافق تمامًا، وأعتقد أنّ مراجعة الرمز البرمجي هي مشكلة في التحقّق، وأعني بذلك أنّه في عالم أثق فيه تمامًا بقدرتي على التحقّق من شيء ما، هل سأظل أراجع الرمز البرمجي لـ %100 من طلبات المراجعة؟

على الأرجح لا، أليس كذلك؟

إذًا، هناك غرضان تخدمهما مراجعات الرموز البرمجية.

الأول هو التأكّد من أنّنا نتّخذ الإجراءات الصحيحة، والثاني هو التثقيف، أليس كذلك؟

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

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

قد لا ينطبق ذلك على جميع الحالات، ولكن أعتقد أنّه ينطبق على نسبة عالية جدًا من الحالات.

وأعتقد أنّنا نستعد لإجراء هذه التغييرات، وعلينا جميعًا كمنتدى التأكّد من أنّ أنظمتنا جاهزة لذلك، لأنّها قادمة.

ما مِن طريقة لتجنّب ذلك.

تتضمّن المرحلة الأولى من مسار الإحالة الناجحة مساحات عرض متنوّعة تتيح لك إنشاء المزيد من العلاقات العامة.

وتكون سرعتك بقدر أبطأ خطوة في العملية.

بالنسبة إلى العديد من الفِرق، يتمثّل ذلك في مراجعات الرموز البرمجية، وقد أدركت الفِرق التي تتقدّم بشكل أسرع هذه الحقيقة وقبلتها.

نعم، وإذا كنا صادقين مع أنفسنا، أود أن أقول إنّ %70 من طلبات الدمج التي رأيتها تبدو جيدة بالنسبة لي.

على سبيل المثال، إذا بحثنا في جميع قواعد الرموز البرمجية في العالم، ستكون تعليقات طلبات الدمج "يبدو جيدًا بالنسبة إليّ" (LGTM) في كل مكان.

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

نعتقد حقًا أنّنا في هذا المكان.

"هل استخدموا نمط الأمر؟"

لا، نحن فقط نقول: "حسنًا.

نعم، يبدو جيدًا بالنسبة لي".

إذًا، لماذا لا يمكنني أن أطلب من وكيل تنفيذ ذلك؟

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

وبعد ذلك، لنتأكّد من أنّ الوكيل يبحث عن الشيء نفسه.

أو من ناحية أخرى، حاوِل أيضًا التفكير في طرق مختلفة للمراجعة.

مثلاً، أعرف أشخاصًا على Twitter يقولون هذا الشيء، أليس كذلك؟

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

أريد رؤية صورة "قبل".

أريد رؤية صورة بعد التعديل.

أرِني الاختبارات التي كتبتها بدلاً من مراجعة الرمز سطرًا بسطر.

ولكنه يمثل تحديًا، كنت ستقول شيئًا يا عادل؟

لا، أعتقد أنّها فكرة مثيرة للاهتمام، أليس كذلك؟

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

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

وأعتقد أنّ المراجعات لا تزال تندرج ضمن فئة الاحتكاك الجيد.

يتعلّق الأمر بكيفية جعلها أقل صعوبة على المطوّرين، أليس كذلك؟

وأحيانًا لا يتعلق الأمر بكيفية إجراء هذه المراجعة، في تلك المرحلة الزمنية، بشكل أفضل أو أكثر كفاءة؟

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

لأنّك إذا اعتمدت على طريقة استخدامك للذكاء الاصطناعي، مثل المدخلات الجيدة تنتج مخرجات أفضل، ولكن المدخلات السيئة تنتج مخرجات سيئة حقًا، أليس كذلك؟

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

وبالتالي، تكون المراجعات أقل صعوبة بالنسبة إلى المطوّرين.

أعتقد أنّ النتيجة النهائية التي لن تثير الكثير من الجدل هي أنّ معظم الأشخاص يرون أنّ كل هذه الرموز البرمجية ستصل في النهاية بدون مراجعة يجريها فريق.

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

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

مثلاً، هل يجب أن نراجع طلبات الدمج سطرًا بسطر أم نراجع الغرض الذي يحاولون تحقيقه؟

نحن نفكّر في هذا الأمر بطرق مختلفة.

الأول هو كيف نقدّم معلومات أكثر صلة بالموضوع للمستخدم حتى يتمكّن من البدء في تحديد أولويات ذلك؟

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

كما قال كوشيك، لا تحتاج جميع المجالات إلى نفس القدر من الدقة.

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

كانت القرارات الصحيحة.

مثل إعادة تصميم وحدة Android جديدة في تطبيق Uber، ربما يكون ذلك جيدًا.

أقدّم رحلات مجانية لجميع مطوّري برامج Android، لذا من الأفضل التحقّق من هذا الرمز.

عليّ مراجعة ذلك مع الرئيس التنفيذي.

عذرًا، كوشيك.

لكنّني أعتقد أيضًا أنّ هذه المشكلة تم حلّها.

لدينا بالفعل علامات ميزات.

لدينا بالفعل نشر أزرق-أخضر.

لدينا بالفعل الكثير من القطع.

التحدي هو أنّنا كنّا مشغولين جدًا لدرجة لم نتمكّن من تنفيذها.

لدينا بالفعل تتبُّع سلوكي.

لدينا كل هذه البيانات، ولكنّها موزّعة على أنظمة مختلفة.

نحن نتتبّع الحوادث حاليًا.

لدينا الكثير من البيانات، ولكنّنا نفتقد إلى طريقة لجمعها معًا في تتبُّع شامل واحد.

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

لأنّنا نعلم أنّنا وضعنا هذه الميزة خلف علامة ميزة.

لدينا نشر أزرق-أخضر.

لدينا جميع إمكانات تتبّع البيانات.

وبعد ذلك، يمكنك أن تشعر بثقة فائقة بمجرد قول، "أوه، ضعه في المسار".

يحدث شيء سيء، لدينا كل هؤلاء الحراس والبوابات على طول الطريق.

أعتقد أنّ سرعة الردّ مهمة جدًا أيضًا، أليس كذلك؟

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

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

أعلم أنّ الكثير منكم يعملون على تطبيقات ضخمة، أليس كذلك؟

لذلك، يهمني معرفة رأيك في هذا الموضوع.

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

أجل

لا يفعلون ذلك على أي حال.

لا أعتقد ذلك.

أعني أن معظم الشركات لن تتمتع بهذا الترف أبدًا.

أعتقد أنّه علينا تخصيص الوقت نفسه الذي كنّا نخصّصه للديون التقنية، مثلاً، تخصيص %20 من الوقت لذلك، أو %5 من الوقت لتحسين طلب.

ويمكنه أيضًا فهم ما يفعله الطلب وتحسين السياق.

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

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

لذلك، أعتقد أنّه يجب أن يصل القادة إلى مرحلة يتساءلون فيها: "ما الذي نحتاج إلى فعله لرفع مستوى فريقنا حتى يتمكّنوا من فهم طريقة عمل هذه التكنولوجيا، ومن ثم يمكننا تحقيق المزيد؟"

وهو أيضًا استمرار له.

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

لذلك، يجب أن يكون هذا كل ما نفعله، كما تعلمون، نحن نبني الطائرة أثناء تحليقها، حيث نضع الحواجز، ونتعلم، ونعدّل الأمور أثناء حدوثها، ويجب أن تظل الفرق على دراية بذلك.

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

ولكن هذا يمثّل تحديًا للجميع في المجال في الوقت الحالي.

أودّ أن أضيف لمسة خاصة عليها.

يعمل الكثير منكم في البنية الأساسية للمطوّرين.

آلاف طلبات الدمج، هل البنية الأساسية للاختبار والخوادم وكل شيء ينهار؟

وأودّ سماع بعض قصص المعارك.

Ty?

نعم.

إنّها رائعة.

‫CI يبكي كل ليلة حتى ينام

Pretty much all of our developer infrastructure teams right now are are battling scaling problems in compute and efficiency problems.

هناك، كما تعلمون، رموز حمراء مستمرة.

ويلاحظون هذه الزيادة الهائلة في حجم المبيعات.

نحن نُجري تغييرات في بنية الوكلاء.

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

ولكنّها مهمة صعبة للغاية.

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

بالنسبة إلى معظم الأشخاص، الإجابة هي على الأرجح لا.

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

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

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

وفي الواقع، نحاول تجنُّب المفاجآت.

صحيح، طالما نشعر بأنّنا نتحكّم في الأمور، سيكون الجميع سعداء.

في اللحظة التي نواجه فيها مفاجأة، أعلم أنها أخبار سيئة للجميع.

أليس كذلك؟

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

هذا أمر حتمي.

نريد فقط أن نكون سبّاقين في هذا المجال.

هناك اقتباس مثير للاهتمام سمعته من الرئيس التنفيذي لشركة Inflow.

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

ولا أعتقد أنّ جميع الشركات مستعدة لاستخدام بنية أساسية على مستوى Google للتطوير.

في هذا الصدد، هل تفرض شركاتكم حدًّا أقصى للإنفاق؟

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

هل هناك أي استراتيجيات وجدتها أم من الأفضل تركهم أحرارًا لأن التجربة تؤدي إلى نتائج رائعة؟

أعتقد أنّ العام الماضي كان عام التجربة.

أنجِز كل المهام.

وربما حتى النصف الأول من هذا العام كان مجرد استخدامه بشكل معقول.

ومنذ سبتمبر، أصبح لدينا حدود قصوى للرموز المميّزة.

لذلك، نضع حدودًا للمطوّرين على استخدام الرموز المميّزة.

ولدينا أيضًا أدوات قياس، لكي يفهموا مثلاً ما إذا كانت جلساتك جيدة وصحية.

ماذا يعني أن تكون الجلسة سليمة؟

هل لديك هذا العدد من الأدوار في كل جلسة؟

ما هو الدور؟

لذلك، نحاول حقًا استخدام الأدوات لتثقيف المطوّرين أيضًا.

أعتقد أنّ هذه مجرد خطوة أولى.

كما تعلم، عليك أن تعرف أنّ لديك مشكلة قبل أن تتمكّن من حلّها.

وبالتالي، فإنّ رؤية هذه الميزة على الأقل ليست مجانية.

في السابق، كان يبدو أنّ الذكاء الاصطناعي مجاني.

وكان الناس يستخدمونه فقط.

أود أن أقول، "تغيير فرعي"، كما تعلم، مثل، "أوه، لا مشكلة يا أنيس، سأغير هذا الفرع لك، 5 دولارات"، أليس كذلك؟

لذا، نحن الآن نصل إلى المكان الذي نقول فيه، "حسنًا، يمكنني فقط الانتقال إلى سطر الأوامر والقيام بذلك بنفسي، أليس كذلك؟"

لذلك أعتقد أنّنا سنبدأ بتثقيف المهندسين حول التكلفة الفعلية.

بل إنّني لن أقوم فقط بتشغيل مثيلات ECS ثم أتركها.

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

وكنا نكلّف الشركة الكثير من المال.

أعتقد أنّ الأمر نفسه يحدث الآن مع الرموز المميّزة.

أعتقد أنّ القيود العملية تتيح أيضًا فرصًا مثيرة للاهتمام، أليس كذلك؟

لأنّنا في البداية، عندما بدأنا استخدام النماذج اللغوية الكبيرة، كنّا نقدّم لها كل شيء، أليس كذلك؟

كانت هذه الأدوات تفحص الرمز البرمجي وتكتشف الأخطاء وتصلحها، أليس كذلك؟

ولكن ذلك كان له ثمن.

ونحن في الواقع حقيقيون، كما تعلمون، يدرك المجال ذلك.

وهذا يدفع المطوّرين والمؤسسات إلى التفكير في كيفية تحسين ذلك.

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

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

نعم، وفي ما يتعلّق بهذه المواضيع، وضعنا بالتأكيد حدودًا، على الأقل في Instacart.

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

مثل متى يجب استخدام نماذج معيّنة بدلاً من نماذج أخرى.

لا تحتاج على الأرجح إلى Fable أو Astra لمعرفة الوقت أو تغيير فرع Git.

أليس كذلك؟

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

وبالتالي، لن يتم إهدار أي رموز مميّزة.

أليس كذلك؟

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

أليس كذلك؟

أعجبني ما قلته، فقد كان العام الماضي عامًا للتجربة.

هذا العام، يبدو أنّنا نتساءل عن كيفية استخدام هذه الأداة بفعالية.

أجل

القصص هنا تهمّنا كثيرًا أيضًا.

خاصةً عند الانتقال من المزيد من التجريب إلى، كما تعلم، مجموعة متوازنة من الكفاءة والمساءلة.

ويأتي ذلك من مجموعة متنوعة من الاستثمارات.

هناك أمور مثل تثقيف المطوّرين وإبراز المحتوى.

كما ذكرت "أنيس" في ما يتعلّق بتكلفة الجلسة النشطة ومعلوماتها.

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

وتحميلهم مسؤولية التكاليف التي ينفقونها

لذا، لدينا حدود قصوى لعدد الرموز المميّزة.

وعندما يصل المطوّر إلى هذه الحدود، يمكنه النقر على زر وإدخال مبرر ويمكن لمديره الموافقة.

لذا، إذا كان هناك عمل رائع، فنحن نريدهم أن يمروا به.

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

وهذا لا يؤدي فقط إلى عدم القيام بالعمل، بل إلى النظر والقول، هل هذا هو اختيار النموذج الصحيح؟

هل هذا هو الوزن الصحيح؟

كما تعلمون، بدأت تكلفة هذه الرموز المميزة في الانخفاض بسبب بعض الضغوط التنافسية.

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

وعلى المدى الطويل، نأمل أن نتمكّن من إزالة هذا القرار بالكامل.

أليس كذلك؟

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

ولكن في هذه الأثناء، هذه حالة صحية.

أجل

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

ولكن الأمر يتعلّق أيضًا بوضع الإجراءات المناسبة.

لذلك، نأخذ في الاعتبار حدود الرموز المميّزة بعدة طرق.

لا نريد أبدًا حظر المطوّر.

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

لذلك، هناك الحد اليومي على سبيل المثال، وهي مجرد إجراء وقائي يمكن للمطوّر إلغاء حظره بنفسه.

كل ما عليهم فعله هو الانتقال إلى البوابة والنقر على زر وقول "مرحبًا، لم يحدث شيء مفاجئ.

أنا من يتحكّم في الأمر".

أليس كذلك؟

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

لذا، هذا معقول جدًا.

من ناحية أخرى، نريد أيضًا التأكّد من أنّ المطوّرين لديهم أفضل النماذج المتاحة.

ولكن بالنسبة إلى هذه الفئة من النماذج، أنشأنا ميزانية مخصّصة للنماذج الرائدة.

لذلك، هناك ميزانية شهرية محدّدة.

هذا الارتفاع كافٍ.

لم يتم حظرك.

إذا كنت بحاجة إلى إزالة الحظر، يمكنك اتّباع عملية الاستثناء.

يتم إرسالها إلى مديرك.

إنّها لحظة تصف فيها ما تفعله.

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

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

والسبب في نجاح ذلك هو أنّ هذه الطريقة تتيح إمكانية توقّع النتائج في العملية.

أليس كذلك؟

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

هل تعرف ما الذي أجده رائعًا في هذه المحادثات؟

أعتقد أنّ السبب هو أنّنا جميعًا نعمل في شركات.

وهكذا، المؤسسات.

لذلك، علينا الدفع مقابل كل رمز مميز.

أليس كذلك؟

ولكن هناك جانب كامل من الإنترنت حيث يعتمد المستخدمون على أسعار الاشتراك.

لذلك، بالنسبة إليهم، هذه عملية حسابية مختلفة تمامًا.

أليس كذلك؟

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

وعندها، قد تظهر عواقب أخرى من حيث تحمّل المزيد من المسؤولية، كما هو الحال الآن في الشركات.

أو أنك تعمل في مختبر رائد حيث تحصل على ميزانية غير محدودة.

وبعد ذلك، تواصلون العمل وتنشئون الكثير من طرق العمل الرائعة المستندة إلى الذكاء الاصطناعي والمنتشرة على Twitter.

تريد جميع شركاتنا محاكاة ذلك، لكنّها لا تريد إنفاق الرموز المميّزة التي…

لدينا أشخاص يعملون في Google هنا.

أنا فضولي للغاية.

كيف يعمل هذا الزر؟

ما هي الميزانية التي تقدّمها Google؟

هل تريد الإجابة عن هذا السؤال يا لويس؟

لا أعتقد أنّني الشخص المناسب للحديث عن الجوانب الاقتصادية لهذا الموضوع.

‫Google هي شركة كبيرة جدًا تضم العديد من المؤسسات المختلفة.

لكن هذا في الواقع يختتمنا بشكل مثالي، لأننا في الوقت المحدد.

كان ذلك مريحًا.

تم إنقاذك في اللحظة الأخيرة.

هذا هو الإشراف الممتاز.

موظفو العلاقات العامة…

على أي حال، شكرًا للجنة التحكيم وشكرًا لحضوركم "قمة مطوّري التطبيقات".