من المساعدة بالذكاء الاصطناعي إلى اعتماده كلياً: بناء فريق تطوير رائد — كلير ليغوري، AWS
AAI Engineer
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00كلير ليغوري: اسمي كلير ليغوري، وأنا مهندسة رئيسية أولى في شركة إيه دبليو إس.
00:00:17أعمل غالباً على Kiro، مساعد فك ترميز الوكلاء لدينا، ولكنني أردت اليوم التحدث عن
00:00:23بعض الممارسات التي لاحظناها داخل أمازون وفي فرق عملها، حيث شهدنا
00:00:28نتائج مذهلة حقاً لزيادة الإنتاجية والتي تعتبر تحسينات ذات دالة درجية مقارنة بما
00:00:35رأيناه مع الذكاء الاصطناعي حتى الآن. لقد كنت أعمل على الذكاء الاصطناعي للوكلاء لأكثر من ثلاث سنوات حتى الآن،
00:00:43ولقد شهدت نوعاً ما التطور الذي حدث في صناعتنا عندما يتعلق الأمر بمساعدات البرمجة
00:00:48باستخدام الذكاء الاصطناعي. أولاً، كان لدينا إكمال الكود المضمن الذي يساعدنا على كتابة السطر التالي،
00:00:55وربما الدالة التالية. وانتقلنا إلى الدردشة، وطرح الأسئلة حول الكود الخاص بنا. بدأ الجميع في ممارسة
00:01:02البرمجة الحدسية في وقت ما من العام الماضي، ولكننا نبدأ الآن في رؤية مرحلة تبني مبكرة لما
00:01:08كنا نسميه التطوير الرائد. وبشكل مجرد تماماً، بناءً على تجربتي الخاصة،
00:01:14شعرت حقاً بزيادة في الإنتاجية بنسبة 10 إلى 20% فقط مع كل هذه المراحل التي مرت
00:01:20سابقاً. ولكن الآن داخل أمازون، قمنا بإجراء تجارب مع فرق مختلفة عبر الشركة،
00:01:27وقد لاحظنا متوسط تحسن في الإنتاجية بمقدار 4.5 أضعاف وفي بعض الأحيان أكثر من 10 أضعاف. إذن،
00:01:34لقد تغير شيء ما حقاً الآن بعد أن شهدنا هذه التحسينات ذات الدالة الدرجية في الإنتاجية.
00:01:40وأود أن أعرّف ما أطلقنا عليه اسم المطورين الرائدين داخل أمازون
00:01:47من خلال ثلاثة سلوكيات لاحظتها. الأول هو البرمجة دون تدخل يدوي. يكتب المطورون الرائدون ربما
00:01:541 إلى 2% فقط من الكود الذي ينتجونه. والباقي يتم بواسطة الوكلاء. والثاني هو أنهم يتفاعلون مع
00:02:01وكلاهم بشكل غير متكرر. ويهدفون إلى جعل مساعد البرمجة الخاص بهم يعمل لمدة تصل إلى ساعات متواصلة دون
00:02:08تدخل منهم. والثالث هو تقليل وقت الخمول إلى أدنى حد ممكن. يميل هؤلاء المطورون الرائدون إلى تشغيل
00:02:15عدة وكلاء بالتوازي، لإنجاز قائمة مهام متراكمة. المرة الأولى التي رأيت فيها فريقاً من المطورين
00:02:24الرائدين كانت فريق Bedrock Mantle. Bedrock هي خدمة استضافة النماذج الخاصة بنا. وهي تستضيف نماذج لغوية كبرى مثل Claude
00:02:34وGPT. وفي وقت ما من العام الماضي كنا نعلم، أو أقول نحن، لكن فريق Bedrock كان يعلم أنه سيتعين عليهم
00:02:43بناء مستوى بيانات استدلال جديد. لكنهم قدروا أن ذلك سيحتاج إلى 30 شخصاً على مدى 18 شهراً. هذه خدمة
00:02:52كبيرة جداً. وسوف يستغرق بناء الخدمة الجديدة، وترحيل العملاء، وترحيل النماذج وقتاً طويلاً.
00:02:58وقرروا التراجع خطوة إلى الوراء. استعانوا بستة أشخاص وبנוها في 76 يوماً باستخدام Kiro.
00:03:06لذا كان هذا إنجازاً ضخماً. وكانت هذه المرة الأولى التي نشهد فيها شيئاً من هذا القبيل داخل أمازون.
00:03:12لذا كان هذا حقاً فريق الاستطلاع الذي أثبت أنه من الممكن تحقيق تحسن يصل إلى 20 ضعفاً. والآن نظروا إلى
00:03:21عمليات الالتزام (Commits)، وسأتحدث عن بعض الطرق الأخرى التي نقيس بها تحسينات الإنتاجية. ولكن
00:03:27كانت هناك مشكلة واحدة في هذه القصة، وهي أنه نعم، تم بناء النظام بستة أشخاص. وقد تم بناؤه
00:03:34باستخدام بعض من أفضل المهندسين حرفياً في الشركة، بما في ذلك مهندسان متميزان. لذا فلم يكن هذا
00:03:40مجرد أي فريق مكون من ستة أشخاص. بل كان هؤلاء خبراء في الأنظمة الموزعة، وخبراء في النماذج اللغوية الكبرى وهندستها.
00:03:49لذا كانت هذه القصة مذهلة وانتشرت كالنار في الهشيم في جميع أنحاء أمازون. ولكنها كانت أيضاً
00:03:57صعبة المنال بالنسبة للعديد من الفرق. وكان هناك الكثير من التساؤلات حول ما إذا كان من الممكن حقاً إعادة إنتاج هذا
00:04:03النجاح في فريق آخر؟ لذا فإن تجربة أخرى أود التحدث عنها هي سباق تجريبي تم إجراؤه
00:04:10في منظمة Prime Video. لقد قاموا بسباق مدته 10 أيام وأجروا تجربة وضعوا فيها، مرة أخرى، ستة مهندسين
00:04:19في غرفة واحدة وتركوه يطلقون العنان لإبداعهم باستخدام Kiro. لقد خفضوا تقدير وقت تسليم المشروع مما كان
00:04:29سيكون 90 أسبوعاً إلى 24 أسبوعاً بناءً على كل التقدم الذي أحرزوه في هذا السباق الذي استمر 10 أيام.
00:04:36وقد نظروا في سجل الالتزامات الخاصة بهم وما اعتادوا فعله قبل هذا
00:04:42السباق الذي استمر 10 أيام وعدد الالتزامات التي أنتجوها في هذه الأيام العشرة وحدها. وهكذا أثبت هذا السباق حقاً
00:04:49أنه يمكننا تحقيق، مرة أخرى، شيئاً قريباً على الأقل مما حققه فريق Bedrock Mantle
00:04:58باستخدام مجموعة مختلفة من المهندسين. ولكن مرة أخرى، كانت هناك تحدٍ في هذه القصة، وهو أنهم كانوا ستة
00:05:05مهندسين في غرفة واحدة بلا واجبات مناوبة، واجتماعات محدودة، وقليل جداً من المشتتات، وهي أمور نعلم جميعاً أنها مألوفة
00:05:12في حياة المهندس. وكان المهندس الرئيسي في الفريق قد قضى الأسابيع الثلاثة الماضية
00:05:20في إنشاء مهام مفصلة وصغيرة ومحددة النطاق بدقة مع متطلبات تفصيلية لهؤلاء المهندسين الستة
00:05:28ليقوموا بتنفيذها طوال هذين الأسبوعين. إذن لم يكن هذا، مرة أخرى، بالضرورة واقع الحياة الحقيقي.
00:05:35لقد كان سباقاً منظماً، ونقطة زمنية تمكنوا فيها من تحقيق ذلك. ولكن مرة أخرى،
00:05:41السؤال هو: هل هذا قابل للتحقيق في الفرق الحقيقية للعمل اليومي؟ لذا قامت أمازون ستورز، التي تضم
00:05:51Amazon.com، وجميع مواقع البيع بالتجزئة الخاصة بنا، بالإضافة إلى متاجرنا الفعلية، بإجراء تجربة أكثر تنظيماً.
00:05:59لقد راقبوا 50 فريقاً طبيعياً تماماً، يضمون توزيعاً طبيعياً للأشخاص في بداية حياتهم المهنية، والمهندسين في منتصفها،
00:06:07والمهندسين الكبار، والذين عملوا على أنظمة قائمة. لم تكن أنظمة جديدة كلياً مثل تلك التي أتيحت لفريق Mantle
00:06:14مع الأنظمة الحالية وقواعد البيانات الموجودة. وقد راقبوهم طوال
00:06:21معظم العام الماضي، ووجدوا شيئاً مثيراً للاهتمام للغاية. وجدوا أن هناك فرقاً كبيراً
00:06:28في مكاسب الإنتاجية التي لاحظواها بين نصف الفرق والنصف الآخر. وفي
00:06:34هذه الحالة، استخدموا مقياساً للإنتاجية يتمثل في سرعة نشر التحديثات إلى بيئة الإنتاج. لذا، ليس فقط عمليات الدمج، بل كم عدد
00:06:41عمليات الدمج التي ينتجونها، بل مدى سرعة إيصال التغييرات إلى العملاء؟ ومدى سرعة
00:06:48قدرتنا على طرح الأشياء؟ وقد لاحظوا أن نصف الفرق حققت زيادة أقل من 3 أضعاف. وما وجدوه
00:06:56كان أن الفارق بين رؤية زيادة في الإنتاجية أقل من 3 أضعاف، وبين تلك الفرق التي شهدت
00:07:01متوسطاً بـ 4.5 أضعاف، وفي بعض الحالات أكثر من 10 أضعاف، كان في كيفية استخدامهم للأدوات. 90% من هذه الفرق استخدمت أدوات Kiro، من بين
00:07:11أدوات داخلية أخرى لدينا. وما وجدوه هو أن الأمر لم يكن يتعلق بالأدوات، بل كان يتعلق بالطريقة التي
00:07:18يعملون بها. الفرق التي حققت تحولات جذرية غيرت عن قصد الطريقة التي تعمل بها،
00:07:26بينما اكتفى الآخرون بنوع من رش أدوات Kiro وبعض الأدوات الأخرى التي لدينا فوق
00:07:31طريقتهم الحالية في العمل. وبالنسبة لي على الأقل، كانت هذه هي اللحظة الحاسمة الكبرى، وهي السبب وراء عدم شعوري
00:07:39بالمكاسب الهائلة المحتملة في الإنتاجية التي وعد بها الذكاء الاصطناعي، فالأمر يتعلق بتغيير الطريقة التي
00:07:47نعمل بها. لذا، عبر هذا البرنامج التجريبي، قاموا بمقابلة الفرق المشاركة في التجربة، بالإضافة إلى بعض
00:07:55هذه الفرق الأخرى في فريق Bedrock Mantle، وPrime Video، ووجدوا خمس عادات. وأنا استخدم
00:08:03كلمة عادات بشكل مقصود للغاية، لأنه مرة أخرى، لا يتعلق الأمر بذلك السباق السريع الواحد، بل يتعلق بالقيام بذلك يومياً
00:08:09بشكل مستمر. وما وجدوه عندما أجروا مقابلات مع هذه الفرق هو أنها كانت حقاً عادات كان عليهم
00:08:15بناؤها يوماً بييوم. عندما نغير طريقة عملنا، يصعب بناء هذه العادات، ويستغرق بناء
00:08:22هذه العادات وقتاً. لذا دعونا نمر على كل واحدة منها واحدة تلو الأخرى. العادة الأولى هي الاستثمار في سياق الوكيل.
00:08:30لدينا الكثير من الأشياء في رؤوسنا، ونحن נוטים لنقل كل تلك الأشياء التي في رؤوسنا إلى أشخاص آخرين
00:08:35من خلال محادثات Slack، ومن خلال توجيه الموجهين الجدد، وأشياء من هذا القبيل من خلال مراجعات الكود،
00:08:42من خلال الاجتماعات اليومية وتخطيط الدورات، وكان عليهم كتابة كل ذلك. والعادة التي
00:08:50بنوها هي أنه في كل مرة يرتكب فيها الوكيل خطأً أو يفعل شيئاً ليس بالطريقة التي كنت ستفعل بها
00:08:55أنت. ما الذي أفتقده في ملفات مهاراتي؟ وما الذي أفتقده في ملفات توجيهي والتي كان يحتاجها الوكيل؟
00:09:01ولكن كما نعلم، طوال العام الماضي، شهدنا قفزات هائلة في قدرات النماذج وسلوكياتها.
00:09:09نموذج Sonnet 3.7 في منتصف العام الماضي كان يحتوي على الكثير من الخסיائص الغريبة التي اضطرتنا لوضع الكثير من الممنوعات
00:09:16في ملفات التوجيه الخاصة بنا. والآن لم نعد بحاجة إلى فعل ذلك كثيراً مع نموذج Opus 4.5 اعتباراً من نوفمبر الماضي،
00:09:23ومن ثم كان لدينا ستة أشهر، وأكثر من ستة أشهر من التحسينات منذ ذلك الحين، مع جميع الإصدارات
00:09:29الجديدة من النماذج التي صدرت منذ ذلك الحين. ولذا فإن السؤال، العادة الجديدة مرة أخرى هي، هل ما زلت
00:09:35بحاجة إلى هذا في ملفات التوجيه الخاصة بي؟ أم أن هذا مجرد تضخم للسياق؟ والثانية هي الإبطاء من أجل
00:09:41التسريع. في كل فريق تقريباً تم إجراء مقابلة معه، أفادوا بأن إنتاجيتهم قد انخفضت في الواقع
00:09:48عندما تبنوا عن قصد طريقة جديدة في العمل. يبدو هذا مناقضاً للمنطق،
00:09:53أليس كذلك؟ عليك القيام بعمل هندسي مقصود قبل أن ترى هذا
00:09:59المنحنى الصاعد في تحسين الإنتاجية. لأننا يجب أن نقوم بعمل حقيقي في قواعد الكود الخاصة بنا
00:10:05أولاً لكي تكون الوكلاء ناجحين هناك، خاصة في قواعد الكود الحالية والقديمة. لذا كان عليهم
00:10:11بناء سياق الوكيل هذا، وكان عليهم تحسين رسائل خطأ الأدوات الحالية لكي يعرف النموذج
00:10:17ما كان يجري عندما يفشل، وقاموا بناء أدوات جديدة، وخوادم MCP جديدة لمساعدة النموذج على إنجاز
00:10:24ما يحتاج إلى إنجازه حقاً. انتهى المطاف بالعديد من الفرق بإعادة هيكلة قاعدة الكود الخاصة بها بحيث تستطيع الوكلاء
00:10:29التنقل فيها بسهولة أكبر. ولقد رأيت حتى تغييرات جذرية مثل تغيير لغة البرمجة
00:10:36لقاعدة الكود. غالباً ما رأيت فرقاً تعاني مع Python، ومع JavaScript لأنهما
00:10:43لغتان غير محددتا الأنواع. يصعب اختبارها. لا توجد أخطاء مترجم. لذا يخمن النموذج
00:10:50ويعيدها إليك. ولذا فقد رأيت فرقاً تنتقل إلى TypeScript. وأصبح Rust شائعاً للغاية
00:10:56داخل أمازون. يقدم المترجم رسائل خطأ رائعة. لسنا مضطرين للقيام بذلك. لكني رأيت العديد من
00:11:03الفرق تقوم بهذه التغييرات المتعمدة لتحقيق مكاسب الإنتاجية التي تتمكن من رؤيتها.
00:11:09العادة الثالثة هي تغذية الوكلاء، وليس مجالستهم. وبالنسبة لي، كانت هذه واحدة من تلك اللحظات الحاسمة
00:11:16التي تفسر سبب رؤيتنا لهذا التحسن الجذري في الإنتاجية. إذا كنت تبرمج بالحدس، إذا كنت
00:11:23تجري محادثة ذهاب وإياب مع وكيلك طوال اليوم، بالطبع لن ترى
00:11:30تحسينات في الإنتاجية بمقدار 4 إلى 5 أضعاف لأنك في صلب العملية طوال الوقت. وربما تكون
00:11:36جالساً هناك لمدة تتراوح بين 30 ثانية إلى دقيقة في انتظار أن يقوم بتوليد الكود والعودة إليك
00:11:42بالكود لمراجعته. إذا كنت جالساً هناك تنتظره، فلن تتمكن من الذهاب للقيام بأشياء أخرى.
00:11:48للغات غير المكتوبة. من الصعب اختبارها. لا توجد أخطاء في المترجم. لذا فإن النموذج يخمن نوعاً ما و
00:11:55يقوم بتسليمها إليك. لذا فقد رأيت الفرق تنتقل إلى استخدام TypeScript. وأصبح Rust شائعاً جداً
00:12:01داخل أمازون. يقدم المترجم رسائل خطأ رائعة. لسنا مضطرين للقيام بذلك، لكنني رأيت العديد من
00:12:08الفرق التي تقوم بهذه التغييرات المتعمدة لتحقيق مكاسب الإنتاجية التي تتمكن من رؤيتها.
00:12:14العادة الثالثة هي تغذية الوكلاء، وليس جليستهم. وبالنسبة لي، كانت هذه إحدى تلك اللحظات الحاسمة
00:12:20لفهم سبب رؤيتنا لهذا التحسن الهائل في الإنتاجية. إذا كنت تقوم بالبرمجة العشوائية (vibe coding)، إذا كنت
00:12:26تجري محادثة ذهاب وإياب مع وكيلك طوال اليوم، بالطبع لن ترى
00:12:33تحسناً بأربعة أو خمسة أضعاف في الإنتاجية لأنك متورط في حلقة العمل طوال الوقت. ربما تكون
00:12:40جالساً هناك لمدة تتراوح بين 30 ثانية إلى دقيقة في انتظار أن يقوم بتوليد الكود ويعود إليك بـ
00:12:46الكود لمراجعته. إذا كنت جالساً هناك في انتظاره، فلن يمكنك الذهاب للقيام بأشياء أخرى.
00:12:54من الصعب حقاً تشغيل الوكلاء بشكل متوازٍ. ومن الصعب جداً استنساخ نفسسك إلى وكلاء متعددين.
00:13:02لذا، إذا كانت محادثاتك تشبه إلى حد ما ما على الجانب الأيسر، فأنت تجلس لمراقبة هذا الوكيل كـ
00:13:10مربية أطفال بدلاً من الجانب الأيمن حيث تغذيه بما يحتاج إلى فعله وكيف يمكنه التحقق من صحة عمله بنفسه.
00:13:17وهذا هو المفتاح حقاً حتى يتمكن الوكلاء من تصحيح أخطائهم بأنفسهم والعودة إليك فقط عندما يصلون إلى مستوى معين من الجودة،
00:13:26وعندما يعمل الكود ويُترجم ويجتاز الاختبارات، وعندما يكون قابلاً للاختبار ويتمتع بتغطية عالية. وبالطبع، المستوى التالي هو وضع كل هذا
00:13:34المحتوى في ملف التوجيه الخاص بك. لكي يقوم بذلك في كل مرة دون الحاجة إلى دفع الأوامر يدوياً.
00:13:39العادة الرابعة هي جعل النية صريحة. في أمازون، نمارس الكثير من التطوير القائم على المواصفات.
00:13:46لقد قمنا ببناء ذلك في منتج Kiro. ولذا يبدو من الطبيعي جداً أن يتبنى مهندسو أمازون ذلك في Kiro.
00:13:56ما رأيته عادةً في البرمجة العشوائية مقابل الهندسة المتقدمة هو إعطاء أمر عالي المستوى جداً،
00:14:04وترك الوكيل يولد طوفاناً من التعليمات البرمجية، ثم الدخول في محادثة ذهاب وإياب بالقول: “أوه، ليس هذا ما كنت أعنيه حقاً.
00:14:12لم تقم بتحديد المتطلبات بدقة”. لا، لم أكن أريد في الواقع بناءه بهذه الطريقة. إليك تصميماً تقنياً.
00:14:20وأجد أنه من الأقل إنتاجية التكرار مع الوكيل بشأن التعليمات البرمجية عندما تكون النية نفسها غير صحيحة.
00:14:24لذا غالباً ما نرى مهندسي أمازون يمرون بهذه العملية للميزات المعقدة الغامضة المتمثلة في كتابة المواصفات.
00:14:32وفي Kiro، بالطبع، ليس عليك كتابة هذه المواصفات بالكامل، بل يمكنك جعل النموذج يولدها.
00:14:40ولكن من الأسهل بكثير التكرار مع النموذج في نوع من محادثة الأخذ والعطاء حول مستند ما
00:14:46مقارنة بالكود وتغييرات الأكواد المنتشرة عبر قاعدة أكواد كاملة. العادة الخامسة هي تحريك الاختبارات
00:14:52إلى اليسار (مبكراً). أحد المفاتيح هنا هو منح الوكيل حلقة تغذية مرتدة سريعة، لأن ذلك ما يسمح له بالعمل لساعات
00:15:01طويلة وتصحيح أخطائه بنفسه. سيرتكب الوكيل أخطاء، وهذا أمر جيد. ولكن إذا أعطيته الإشارات الصحيحة، فيمكنه
00:15:07تصحيح أخطائه وقضاء بعض الوقت في فعل ذلك. لذا رأيت فرقاً تضيف أدوات تدقيق اللينتر، اختبارات الوحدات،
00:15:14اختبارات التكامل، اختبارات الأداء، اختبارات الأمان. هذه كلها أشياء نعلم جميعاً أنه كان يجب أن
00:15:21نقوم بها طوال الوقت. هذه هي ممارسات النظافة الهندسية الجيدة. ولكن الآن أصبح عائد الاستثمار، كما أعتقد، مرتفعاً بما يكفي
00:15:28للاستثمار فيه فعلياً. وهناك شيء واحد رأيت الكثير من الفرق تفعله وهو محاكاة الخدمات (Mocking).
00:15:35غالباً مع اختبارات التكامل، كنا نختبر نظاماً كاملاً من البداية إلى النهاية، بما في ذلك الخدمات الحية.
00:15:42ولكننا استثمرنا كثيراً في خدمات محاكاة تعمل بالكامل محلياً مع استجابات حتمية ومحددة سلفاً،
00:15:48لأن ذلك يتيح للوكيل القيام بكل شيء محلياً. إن تنفيذ كل شيء على حاسوبك المحمول دون
00:15:56الاضطرار إلى تشغيل مجموعة من الخدمات الأخرى والاتصال بالخدمات السحابية يجعل كل شيء أسرع بكثير.
00:16:03ولأن كلما زادت سرعة حصول وكيلك على التغذية المرتدة، زادت الدورات التي يمكنه
00:16:09إنجازها وزادت إنتاجية وكيلك الخاص. إذن، هذه بعض العادات التي شهدناها.
00:16:15ولكن بالطبع، سيكون من التقصير ألا أخبرك أنه حتى لو تبنيت كل هذه العادات،
00:16:22لن تبلغ مرحلة النقاء التام ولن تصبح المنظمة الهندسية الأكثر إنتاجية التي عرفها العالم.
00:16:29الأمور لا تزال صعبة. ما زلنا في مرحلة التبني المبكر ولا تزال الفرق تحاول استكشاف الأمور.
00:16:37لذا فإن أحد الأمور التي لاحظناها عبر فرقنا على المستوى التنظيمي هو خطر الاحتراق النفسي.
00:16:44لم أقم بابتكار هذا المصطلح، وأنسى من قاله في أي مؤتمر، لكن الخوف من تفويت التكنولوجيا المتقدمة (FOMAT) حقيقي.
00:16:52لقد رأينا مهندسين يسهرون حتى وقت متأخر من الليل، محاولين الحصول على ذلك الأمر (Prompt) المثالي الذي سيجعل
00:16:58وكيلهم يعمل لساعات طوال الليل حتى يستيقظوا في الصباح وقد تم إنجاز تغيير الكود. العبء المعرفي
00:17:07يزداد كلما شغلت هؤلاء الوكلاء المتعددين بالتوازي، وأنت تنتقل باستمرار بين
00:17:14علامات تبويب الطرفية (Terminal). ونلاحظ فعلياً أن مراجعة مخرجات الذكاء الاصطناعي غالباً ما تكون أصعب بالنسبة للبعض من
00:17:22كتابتها فعلياً، خاصة في بداية حياتهم المهنية. لقد أمضى المهندسون الكبار جزءاً كبيراً من
00:17:29مسيرتهم المهنية في مراجعة أكواد الآخرين. لكن المهندسين في بداية حياتهم المهنية ليس لديهم هذه العضلات بعد. لذا فإن مراجعتها
00:17:38قد تماثل عبئاً معرفياً أكبر بكثير مما اعتادوا عليه في كتابتها الفعلية. والأمر الآخر
00:17:44هو التغيير التنظيمي. فمن الصعب أصلاً تغيير طريقة عملنا كمهندسين. الطريقة التي نقضي بها يومنا بالكامل تتغير تماماً عندما نصبح مهندسين متقدمين.
00:17:54ولكن يجب على المنظمات أيضاً أن تتغير لتمكين فرق الهندسة المتقدمة. وأحد الأمور التي رأيتها بشكل شائع جداً
00:18:01هو قبول إبطاء السرعة من أجل التسارع لاحقاً. وأنا نفسي كنت مذنبًا في هذا.
00:18:08وزملائي القادة كانوا مذنبين في ذلك بالقول: حسنًا، لديك أدوات الذكاء الاصطناعي الآن والنماذج مذهلة جداً الآن. لماذا لا تتحرك بشكل أسرع؟
00:18:16داخل أمازون. والآن التحدي بالنسبة لنا هو كيف نوسع نطاق ذلك؟ وهذا ما يدور حوله عام 2026.
00:18:22بالنسبة لأمازون هو كيف نوسع نطاق هذا ليشمل المزيد والمزيد من الفرق، إلى الألفي فريق القادمة بدلاً من 50 فريقاً.
00:18:31شحن الميزات كل شهر، نظراً لأننا نملك الآن هذه النماذج المذهلة، ونرى
00:18:37جميع هذه الشركات على منصة X تتحدث عن كيفية شحن 20 طلب سحب (PR) يومياً، فيجب علينا أن نبطئ السرعة لكي نسرع لاحقاً.
00:18:43والنقطة الأخيرة هي أنكم ستكتشفون اختناقات جديدة.
00:18:49سابقاً، كانت كتابة الكود يدوياً هي نقطة الاختناق. أجد أنه داخل أمازون، وجدنا أن
00:18:58سرعة اتخاذ القرار تصبح نقطة اختناق جديدة. وكلما قضيت وقتاً أطول في مراجعة القرار
00:19:05لبناء منتج جديد فعلياً، أصبح بناء المنتج أبطأ الآن لأن كتابة الكود تستغرق شهراً إلى شهرين فقط.
00:19:12جميع عمليات المراجعة المرتبطة بإطلاق المنتجات تصبح هي نقطة الاختناق.
00:19:20عندما كان بناء منتج جديد يستغرق من تسعة إلى اثني عشر شهراً، لم يكن الأمر يمثل فارقاً كبيراً
00:19:27في المجمل. إذا استغرق اتخاذ قرار بناء المنتج شهرين ثم شهرين
00:19:33ل الموافقة على الإطلاق. لكن الآن أصبحت تلك هي نقاط الاختناق والعقبات الكبرى. ولذلك تجدون أن كل
00:19:40هذه الأمور تبطئ من سرعة عملكم. غالباً ما أجد أن فرق الهندسة المتقدمة تقضي وقتاً في
00:19:48اتخاذ القرارات أكثر مما تقضيه في كتابة الكود. ولذلك، وكلما تمكنتم من اتخاذ قرارات سريعة، خاصة تلك
00:19:54التي يسهل التراجع عنها، كان ذلك أفضل. لذا، فإن خلاصتي الكبرى لكل الموجودين هنا هي أن الهندسة المتقدمة
00:20:03تقوم على تغيير طريقة عملكم بشكل متعمد. وهذا أمر صعب ويستغرق وقتاً.
00:20:10إنه بناء عادات جديدة وطريقة عمل جديدة. وهذا ينطبق على أي فريق هندسي وكذلك على
00:20:18مؤسستكم. لذا أشرككم في التفكير في كيفية تفاعلكم مع أدوات الذكاء الاصطناعي وكيف يمكن لذلك
00:20:27أن يتغير لتحرير أنفسكم من البقاء عالقين في الحلقة. شكراً لكم. سأبقى لفترة قصيرة إذا كان لدى أي شخص
00:20:34أسئلة في الخلف. وشكراً لكم على وقتكم اليوم.