WEBVTT

00:00:00.000 --> 00:00:03.900
ماذا لو كان لدى فريق تطوير البرمجيات لديك زميل إضافي لا يتعب أبداً

00:00:03.900 --> 00:00:07.380
ويتعلم أسرع من أي شخص تعرفه ويتولى الأعمال المملة دون تذمر

00:00:07.380 --> 00:00:10.140
هذا هو جوهر ما يتحول إليه الذكاء الاصطناعي الوكيل

00:00:10.140 --> 00:00:14.420
في هذا الفيديو سنحدد أولاً المعنى الفعلية للذكاء الاصطناعي الوكيلي

00:00:14.420 --> 00:00:18.000
ثم نوضح كيف يعمل في مسارات عمل نيت وأشر الحقيقية

00:00:18.000 --> 00:00:20.460
وأخيراً نستكشف تأثيره على إنتاجية فريقك

00:00:20.460 --> 00:00:25.300
بحلول النهاية ستعرف تجربة صغيرة وحدة يمكنك تجربتها في مسار عمل نيت الخاص بك هذا الأسبوع

00:00:25.300 --> 00:00:27.320
لكن قبل أن ننتقل إلى التطبيقات والنتائج

00:00:27.320 --> 00:00:32.420
نحتاج إلى النظر فيما يجعل الذكاء الاصطناعي الوكيل مختلفاً حقاً عن أدوات الإكمال التلقائي التي رأيتها من قبل

00:00:32.420 --> 00:00:35.380
ما الذي يجعل الذكاء الاصطناعي الوكيل مختلفاً

00:00:35.380 --> 00:00:38.940
ما يميز الذكاء الاصطناعي الوكيل ليس فقط قدرته على إنشاء الكودي

00:00:38.940 --> 00:00:41.980
بل عمله كنظام من الزملاء ذوي القدرات المتميزة

00:00:41.980 --> 00:00:44.760
لفهم هذا يمكننا تقسيمه إلى ثلاث سمات رئيسية

00:00:44.760 --> 00:00:47.640
الطريقة التي يحتفظ بها كل وكيل بالسياق والذاكرة

00:00:47.640 --> 00:00:49.980
وكيفية تنسيق وكلاء متعددين كفريق

00:00:49.980 --> 00:00:53.140
والفرق بين الأتمتة البسيطة والاستقلالية التكيفية الحقيقية

00:00:53.140 --> 00:00:56.360
أولاً لنلقي نظرة على ما يجعل الوكيل الفردي متميزاً

00:00:56.360 --> 00:00:58.440
السياق والذاكرة وتوجيه الأهداف

00:00:58.440 --> 00:01:01.600
يعمل الإكمال التلقائي التقليدي على توقع الكلمة أو السطر التالي

00:01:01.600 --> 00:01:04.280
لكنه ينسى كل شيء آخر بمجرد إجراء التوقع

00:01:04.280 --> 00:01:08.200
في المقابل يحمل وكيل الذكاء الاصطناعي فهماً أوسع للمشروع ككل

00:01:08.200 --> 00:01:10.240
فهو يتذكر ما تم تجربته بالفعل

00:01:10.240 --> 00:01:13.840
ويعرف مكان وجود الكود ويعدل مخرجاته عند حدوث أي تغيير

00:01:13.840 --> 00:01:16.700
هذا الاستمرار يجعله أقرب إلى العمل مع مطور مبتدئ

00:01:16.700 --> 00:01:20.600
شخص يتعلم بمرور الوقت بدلاً من مجرد تخمين ما تريده في اللحظة الراهنة

00:01:20.600 --> 00:01:23.260
الفرق الرئيسي هنا يكمن بين التوقع والتخطيط

00:01:23.260 --> 00:01:26.120
بدلاً من التفاعل مع كل ضغطة مفتاح بمعزل عن غيرها

00:01:26.120 --> 00:01:28.700
يتابع الوكيل الأهداف ويتكيف مع تطور المواقف

00:01:28.700 --> 00:01:31.480
التالي هو كيفية عمل وكلاء متعددين معاً

00:01:31.480 --> 00:01:33.740
من المفاهيم الخطيئة الكبيرة اعتبار الذكاء الاصطناعي الوكيل

00:01:33.740 --> 00:01:36.680
مجرد برنامج نصي سكريبت أو ماكر لأتمتة المهام المتكررة

00:01:36.680 --> 00:01:38.480
ولكن في مشاريع البرمجيات الحقيقية

00:01:38.480 --> 00:01:40.500
يتم تقسيم العمل عبر أدوار مختلفة

00:01:40.500 --> 00:01:43.480
المهندسون المعمريون والمراجعون والمختبرون والمشغلون

00:01:43.480 --> 00:01:45.080
يمكن للوكلاء محاكاة هذا التقسيم

00:01:45.080 --> 00:01:48.300
حيث يتولى كل منهم جزءاً من دورة حياة المشروع بدقة واتساق تامين

00:01:48.300 --> 00:01:50.440
تخيل وكيلاً مخصصاً لتصميم النظام

00:01:50.440 --> 00:01:54.740
يقترح أماط الهندسة المعمارية وأطر العمل التي تناسب أهداف العمل

00:01:54.740 --> 00:01:56.400
وآخر يراجع تغييرات الكودي

00:01:56.400 --> 00:01:59.880
ويكتشف المشكلات مع البقاء على اطلاع بتاريخ المشروع بأكمله

00:01:59.880 --> 00:02:03.460
وثالث يمكنه توسيع نطاق تغطية الاختبار بناء على بيانات المستخدم

00:02:03.460 --> 00:02:06.140
وإنشاء حالات اختبار دون الحاجة إلى طلبها منه

00:02:06.140 --> 00:02:08.540
كل وكيل متخصص لكنهم ينسقون كفريق واحد

00:02:08.540 --> 00:02:10.460
متاحون دائماً متسقون دائماً

00:02:10.460 --> 00:02:12.580
وقابلون للتوسع بسهولة اعتماداً على عبء العمل

00:02:12.580 --> 00:02:15.220
حيث يفقد البشر طاقتهم أو تركيزهم أو سياق العمل

00:02:15.220 --> 00:02:18.280
تظل الوكلاء ثابتين ويستحضرون التفاصيل بدقة متناهية

00:02:18.280 --> 00:02:21.260
الجزء الأخير هو التمييز بين الأتمتة والاستقلالية

00:02:21.260 --> 00:02:23.980
لقد كانت الأتمتة موجودة منذ زمن طويل في مجال التطوير

00:02:23.980 --> 00:02:27.140
فكر في النصوص البرمجية وخطوط أنابي بي سي سي دي والقوالب

00:02:27.140 --> 00:02:29.140
هذه الأدوات جامدة بطبيعتها التصميمية

00:02:29.140 --> 00:02:31.140
إنها تتبع تعليمات دقيقة خطوة بخطوة

00:02:31.140 --> 00:02:33.720
لكنها تتعطل عندما تتغير الظروف بشكل غير متوقع

00:02:33.720 --> 00:02:35.980
تتبنى الاستقلالية نجناً مختلفاً

00:02:35.980 --> 00:02:38.880
يمكن لوكلاء الذكاء الاصطناعي الاستجابة للتغيرات فور حدوثها

00:02:38.880 --> 00:02:41.480
وتكيفه عند تغير إصدار التبعيات أو إعادة النظر

00:02:41.480 --> 00:02:43.600
في اختيار خدمة مع عند ظهور قيود في التكلفة

00:02:43.600 --> 00:02:45.880
بدلاً من تنفيذ مسارات محددة مسبقاً

00:02:45.880 --> 00:02:48.180
فإنهم يتخذون قرارات في ظل ظروف ديناميكية

00:02:48.180 --> 00:02:51.580
إنه تحول من التنفيذ الثابت إلى حل المشكلات التكيفي

00:02:51.580 --> 00:02:55.800
الأثر المترتب على ذلك هو أن هؤلاء الوكلاء يتجاوزون مجرد انتظار الأوامر

00:02:55.800 --> 00:02:57.820
يمكنهم اقتراح حلول عند ظهور المشكلات

00:02:57.820 --> 00:03:00.660
وتسليط الضوء على المخاطر قبل وصولها إلى مرحلة الإنتاج

00:03:00.660 --> 00:03:03.040
وصياغة خطط توفر ساعات من عمل الإعداد

00:03:03.040 --> 00:03:05.820
إذا كان بيتهاب كوبايلوت اليوم يكمل مقتطفات برمجية

00:03:05.820 --> 00:03:08.340
فإن نسخة الغد ستعمل كعضو مساهم في المشروع

00:03:08.340 --> 00:03:11.200
حيث تضع خارطة طريق وتقترح استراتيجيات إصدار

00:03:11.200 --> 00:03:14.460
بل وتحدد القرارات المعمرية التي قد تسبب مشاكل لاحقاً

00:03:14.460 --> 00:03:17.360
هذا لا يعني أن كل عملية نشر ستتم دون تدخل بشري

00:03:17.360 --> 00:03:20.400
لكنها قد تقلل بشكل كبير من التدخلات المتكررة

00:03:20.400 --> 00:03:24.960
وتمنح المطورين مزيداً من الوقت للتركيز على الجوانب الإبداعية عالية القيمة في المشروع

00:03:24.960 --> 00:03:27.300
لتوضيح صياغة سابقة في هذا المجال

00:03:27.300 --> 00:03:28.440
بدلاً من قولي

00:03:28.440 --> 00:03:33.260
ماذا يحدث عندما لا تتطلب توفير موارد أشر أي تدخل بشري على الإطلاق؟

00:03:33.260 --> 00:03:34.800
سيكون القول الأكثر دقة هو

00:03:34.800 --> 00:03:38.000
يمكن لهذه الأدوات تقليل حجم الأعداد اليدوي المطلوب

00:03:38.000 --> 00:03:41.020
مع الحفاظ على ضوابط الأمان الرئيسية تحت سيطرة البشر

00:03:41.020 --> 00:03:46.020
تظل النتيجة تحويلية دون الإحاء باختفاء الرقابة البشرية تماماً

00:03:46.020 --> 00:03:48.480
الإدراك الأكبر هو أن الذكاء الاصطناعي الوكيل

00:03:48.480 --> 00:03:51.600
ليس مجرد إضافة أخرى تسرع مهمة هنا أو هناك

00:03:51.600 --> 00:03:53.760
إنه يبدأ في العمل كعضواً فعلياً في الفريق

00:03:53.760 --> 00:04:00.120
حيث يتولى الأعمال الخلفية حتى لا يضطر المطورون إلى تتبع تفاصيل كان يمكن مراقبتها بواسطة نظير يعمل دون انقطاعاً

00:04:00.120 --> 00:04:06.020
تتعزز قدرة الفريق بالكامل لأن المجالات الرئيسية بها وكلاء رقميون يعملون جناً إلى جنب مع المتخصصين من البشر

00:04:06.020 --> 00:04:07.180
فهم النظرية مهم

00:04:07.180 --> 00:04:10.740
ولكن الأهم هو كيف يتجسد ذلك في بيئات العمل المألوفة

00:04:10.740 --> 00:04:12.560
إذن إليكم فجوة الفضول

00:04:12.560 --> 00:04:17.020
ما الذي يتغير فعلياً في اليوم الأول من مشروع جديد عندما يكون الوكلاء نشطين منذ البداية

00:04:17.020 --> 00:04:20.320
بعد ذلك سننظر في سيناريو ملموس داخل بيئة نيت

00:04:20.320 --> 00:04:24.580
حيث تبدأ هذه التحولات في الظهور قبل أن تكتب حتى السطر الأول من الكودي

00:04:24.580 --> 00:04:27.300
إعادة تصور سير عمل المطور في نيت

00:04:27.300 --> 00:04:28.380
في تطوير نيت

00:04:28.380 --> 00:04:32.080
يبدأ التحول الأكثر وضوحاً بكيفية انطلاق المشاريع

00:04:32.080 --> 00:04:36.020
تتمحور إعادة تصور سير عمل المطور هنا حول ثلاث مزايا تكتيكية

00:04:36.540 --> 00:04:37.880
بناء هيكل أسرع

00:04:37.880 --> 00:04:40.100
ونقد على مستوى المشروع أثناء العمل

00:04:40.100 --> 00:04:42.300
وانخفاض ملحوظ في إجهاد الإعداد

00:04:42.300 --> 00:04:44.620
أولاً هو تسريع عملية البناء الهيكلي

00:04:44.620 --> 00:04:47.140
بدلاً من فتح فيشول ستوديو والتحديق في حل فارغ

00:04:47.140 --> 00:04:51.700
يمكن لوكيل الذكاء الاصطناعي اقتراح خيارات معمارية تناسب حالة استخدامك المحددة

00:04:51.700 --> 00:04:54.360
عند تخطيط لواجهة برمجة تطبيقات ويب بتحديثات فورية

00:04:54.360 --> 00:04:56.280
يقترح الوكيل تصميماً طبقياً نظيفاً

00:04:56.280 --> 00:04:58.820
ويوضح كيف يتناسب سيبنالور بشكل طبيعي مع تدفق العمل

00:04:58.820 --> 00:05:00.000
بالنسبة لتطبيق مالي

00:05:00.000 --> 00:05:05.980
يقوم الوكيل بتهيئة Entity Framework مع أمان قوي للأنواع وتكامل مع أشر Active Directory قبل أن تنشئ مجلداً وحداً

00:05:05.980 --> 00:05:10.540
ما يستغرق عادة جولات من النقاش أو ساعات من البحث يتم اختصاره في بضع نقاط بداية مصممة خصيصاً لك

00:05:10.540 --> 00:05:12.640
هذه ليست مخططات نهائية على أي حال

00:05:12.640 --> 00:05:14.020
إنها مجرد مسودات

00:05:14.020 --> 00:05:17.180
يجب على الفرق التحقق من كل اقتراح من خلال تشغيل قائمة مرجعية سريعة

00:05:17.180 --> 00:05:19.060
هل تلبي المصادقة المتطلبات؟

00:05:19.060 --> 00:05:21.220
هل تم ربط سجلات لوبين بشكل صحيح؟

00:05:21.220 --> 00:05:23.300
هل تم وضع حالات الاختبار الأساسية في مكانها؟

00:05:23.300 --> 00:05:26.540
تضمن هذه الرقابة الخفيفة ألا تأتي السرعة على حساب الاستقرار

00:05:26.540 --> 00:05:28.760
الميزة الثانية هي النقد المستمر

00:05:28.760 --> 00:05:31.300
فكر في الأمر ليس كأداة لإكمال الكود

00:05:31.300 --> 00:05:33.880
بل كمستشار يراقب توفق التصميم

00:05:33.880 --> 00:05:36.500
إذا أنشأت نمط مستودع للوصول إلى البيانات

00:05:36.500 --> 00:05:39.760
ينبهك الوكيل إذا كنت تحيد عن مبدأ فصل الاهتمامات

00:05:39.760 --> 00:05:41.460
عند إضافة وحدة تحكم جديدة

00:05:41.460 --> 00:05:43.460
يقترح الوكيل اختبارات وحدة مطابقة

00:05:43.460 --> 00:05:45.900
أو يسلط الضوء على أي تناقضات مع بقية المشروع

00:05:45.900 --> 00:05:47.600
بدلا من تركك مع كود متكرر

00:05:47.600 --> 00:05:50.700
فإنه يوجه هيكل نظامك نحو أنماط قابلة للصيانة

00:05:50.700 --> 00:05:51.900
مع كل عملية إداعا

00:05:51.900 --> 00:05:53.360
كتجربة عملية

00:05:53.360 --> 00:05:55.760
حاول تفعيل كوبيلوت في فيشول ستوديو

00:05:55.760 --> 00:05:57.180
على نموذج أولي صغير

00:05:57.180 --> 00:06:01.160
ثم قارن الوقت الذي تستغرقه لخدمة أول طلب مفيد

00:06:01.160 --> 00:06:04.000
بنقطة نهاية واحدة مع المصادقة وحفظ البيانات

00:06:04.000 --> 00:06:05.840
مقابل القيام بكل شيء يدويا

00:06:05.840 --> 00:06:07.540
إنه ليس ضمانا لتوفير الوقت

00:06:07.540 --> 00:06:10.460
لكن إجراء مقارنة جنبنا إلى جنب في بيئتك الخاصة

00:06:10.460 --> 00:06:14.440
هو غالبا أسرع طريقة لتقييم ما إذا كانت هذه الوكلاء تحدث تأثيرا ملموسا

00:06:14.440 --> 00:06:17.480
الميزة الثالثة هي تقليل الأعداد والعبء الإدراكي

00:06:17.480 --> 00:06:21.000
الكثير من عمل المشروع المبكر متكرر مثل ربط وسيط المصادقة

00:06:21.000 --> 00:06:24.340
وجلب حزم نوجت وأعداد التسجيل باستخدام Application Insights

00:06:24.340 --> 00:06:26.420
وكتابة خطوط أنابيبا وي AML

00:06:26.420 --> 00:06:28.520
يمكن للوكيل هيكلة تلك الأجزاء فورا

00:06:28.520 --> 00:06:32.100
بما في ذلك اختبارات التكامل الأساسية التي تدرك التبعيات الموجودة

00:06:32.100 --> 00:06:33.440
هذا لا يلغي سيطرتك

00:06:33.440 --> 00:06:35.420
بل يغير وجهة تركيز طاقتك

00:06:35.420 --> 00:06:37.920
بدلا من مصارعة ملفات التكوين ليوم كامل

00:06:37.920 --> 00:06:41.220
تقضي ذلك الوقت في تنفيذ منطق العمل الذي يهم حقا

00:06:41.220 --> 00:06:42.720
يتلاشى تعب أعمال الأعداد

00:06:42.720 --> 00:06:46.860
مما يترك مساحة لقرارات التصميم الإبداعية بدلا من المهام الميكانيكية

00:06:46.860 --> 00:06:50.380
حيث يبدو هذا مختلفا عن الأتمتة التقليدية هو في المرونة

00:06:50.380 --> 00:06:53.200
قالب المشروع يمنحك إعدادات افتراضية ثابتة

00:06:53.200 --> 00:06:56.780
بينما يقوم الوكيل بتكييف هيكلته بناء على هدف عملك المذكور

00:06:56.780 --> 00:06:58.240
إذا كنت تبني تطبيق تعاون

00:06:58.240 --> 00:07:02.020
ستظهر استراتيجيات التخزين المؤقت مثل ريدس والتصميم القائم على الأحداث

00:07:02.020 --> 00:07:03.860
مع أشر سيرفيس بس في الخطة الهيكلية

00:07:03.860 --> 00:07:05.800
إذا انتقلت نحو أحمل العمل المجدولة

00:07:05.800 --> 00:07:08.800
ستظهر بدلا من ذلك خدمات الخلفية ومعالجة الطوابير

00:07:08.800 --> 00:07:12.480
هذه الاستجابة هي ما يميز الذكاء الاصطناعي الوكيل عن البرمجة البسيطة

00:07:12.480 --> 00:07:16.300
إذ يقدم توصيات تحاكي دور عضو الفريق الأقدم في توجيه القرارات الأولية

00:07:16.300 --> 00:07:19.220
التباين مع استخدام كوبايلوت اليوم واضح تماما

00:07:19.220 --> 00:07:24.200
في الوقت الحالي يرى معظم المطورين أنه وسيلة لتسريع كتابة الصياغ البرمجية الشائعة أو النصوص الجاهزة

00:07:24.200 --> 00:07:27.060
يطرحون سؤالا فيقوم الأداة بتكملة السطر

00:07:27.060 --> 00:07:30.600
مع قدرات الوكلاء تبدأ الأداة بتقديم المشورة على مستوى النظام

00:07:30.600 --> 00:07:34.960
وتوفر بدائل وعية بالسياق وتكشف المقايضات في وقت مبكر من الدورة

00:07:34.960 --> 00:07:39.400
القفزة هنا هي الانتقال من توليد مقتطفة برمجية إلى تنسيق تصميمات عملية

00:07:39.400 --> 00:07:42.040
وهذا لا يغير فقط كيفية كتابة الكودي

00:07:42.040 --> 00:07:45.680
بل كيف تصيغ الفرق الحل بأكمله قبل الالتزام بمسار واحد

00:07:45.680 --> 00:07:48.520
لا شيء من هذا يلغي الحاجة إلى التقدير البشري

00:07:48.520 --> 00:07:51.420
يمكن للوكلاء اقتراح أطور العمل والتبعيات والممارسات

00:07:51.420 --> 00:07:53.640
لكن التحقق منها يظل مسئولية الفريق

00:07:53.640 --> 00:07:56.320
تعامل مع كل توصية كأنها مسودة مقترح

00:07:56.320 --> 00:07:59.960
أقبل الأجزاء التي تتوافق مع معاييرك وراجع ما لا يتوافق

00:07:59.960 --> 00:08:02.480
وسجل الدروس المستفادة لتكرار المشروع القادم

00:08:02.480 --> 00:08:04.740
يتولى الذكاء الاصطناعي المهام الشاقة والمتكررة

00:08:04.740 --> 00:08:08.040
بينما يركز أعضاء الفريق على مواءمة الخيارات التقنية مع الاستراتيجية

00:08:08.040 --> 00:08:12.860
حتى الآن نظرنا إلى كيفية إعادة تشكيل الوكلاء لتجربة البرمجة داخل النيل

00:08:12.860 --> 00:08:16.640
لكن مشاركتهم لا تنتهي عند تصميم الحل أو هيكلة المشروع

00:08:16.640 --> 00:08:18.060
بمجرد وضع الأساسي

00:08:18.060 --> 00:08:22.080
يبدأ نفس الذكاء بالتوسع نحو توفير ونشر وإدارة البنية التحتية

00:08:22.080 --> 00:08:24.020
التي تعتمد عليها تلك التطبيقات

00:08:24.020 --> 00:08:26.400
هنا تتشكل تحولات كبرى أخرى

00:08:26.400 --> 00:08:28.840
وهي لا تقتصر على سير عمل المطور المحلي

00:08:28.840 --> 00:08:31.660
بل تتعلق ببيئة السحابة التي تحيط به

00:08:31.660 --> 00:08:34.440
وكلاء السحابة يديرون أشر بنظام الطيار الآلي

00:08:34.440 --> 00:08:39.720
لذا دعونا نحول تركيزنا إلى ما يحدث عندما تبدأ إدارة أشر نفسها بالعمل بنظام الطيار الآلي بمساعدة الوكلاء

00:08:39.720 --> 00:08:43.000
الطريقة الأصلية لطرح هذا النقاش تبدو غالبا كخيال علميا

00:08:43.000 --> 00:08:47.380
ماذا يحدث عندما لا يحتاج توفير موارد أشر إلى أي تدخل بشري على الإطلاق

00:08:47.380 --> 00:08:50.120
طريقة أفضل للتفكير في الأمر هي هذه

00:08:50.120 --> 00:08:55.020
ماذا يحدث عندما يتطلب التوفير الروتيني واكتشاف الانحراف تدخلا يدويا أقل

00:08:55.020 --> 00:08:58.560
لأن الوكلاء يديرون المهام المتكررة ضمن ضوابط محددة

00:08:58.560 --> 00:09:01.940
هذا التحول مهم لأنه لا يتعلق بإلغاء دور البشر

00:09:01.940 --> 00:09:04.800
بل بتخفيف العبء عنهم مع الحفاظ على الرقابة

00:09:04.800 --> 00:09:07.160
إذا سبق لك بناء بيئة أشر حقيقية

00:09:07.160 --> 00:09:09.440
فأنت تعلم بالفعل مدى فوضويتها

00:09:09.440 --> 00:09:11.520
أن توفق بين القوالب والنصوص البرمجية

00:09:11.520 --> 00:09:13.360
وملفات يمل الخاصة بخطوط الأنابيب

00:09:13.360 --> 00:09:16.740
مع التنقل بين أوامر CLA للسرعة والبوابة الإلكترونية للاستثناءات

00:09:16.740 --> 00:09:19.900
كل طريق مختصر يتحول إلى دين تقني ينتظر الظهور

00:09:19.900 --> 00:09:22.060
جهاز افتراضي يترك يعمل خارج ساعات العمل

00:09:22.060 --> 00:09:23.700
أو تكاليف تتزايد دون ملاحظة

00:09:23.700 --> 00:09:25.600
أو حساب تخزين مكشوف في غير محله

00:09:25.600 --> 00:09:29.540
وفي عمليات السحابة حتى الأخطاء الصغيرة تسبب صداعا كبيرا

00:09:29.540 --> 00:09:32.260
فواتير مرتفعة أو مناطق تقوض المرونة

00:09:32.260 --> 00:09:35.020
أو ثغرة امتثال تكتشفها في أسوأ وقت ممكن

00:09:35.020 --> 00:09:38.040
هذا هو العبء الذي ترغب معظم الفرق في التخلص منه

00:09:38.040 --> 00:09:40.740
وهنا يبدأ الوكيل في العمل كمهندس نشر مستقل

00:09:40.740 --> 00:09:43.900
الفكرة بسيطة أن تقدم أهدافا على مستوى الأعمال

00:09:43.900 --> 00:09:46.080
ومتطلبات الأداء واحتياجات التعافي

00:09:46.080 --> 00:09:48.260
وقواعد الامتثال وميزانية محددة

00:09:48.260 --> 00:09:51.600
ويقوم الوكيل بترجمة هذا القصد إلى تكوينات للبنية التحتية

00:09:51.600 --> 00:09:54.980
بدلا من التنقل بين وحدات تحكم متعددة أو ربط المعرفات يدويا

00:09:54.980 --> 00:09:58.300
ترى قوالب البنية التحتية ككود متوافقة بالفعل مع أهدافك المعلنة

00:09:58.300 --> 00:10:01.980
من هناك يواصل الوكيل نفسه المراقبة وتشغيل فحوصات الامتثال

00:10:01.980 --> 00:10:04.000
ومحاكاة التكوينات الخاطئة المحتملة

00:10:04.000 --> 00:10:07.660
وتطبيق الإصلاحات المقترحة قبل أن تتفاقم المشكلات في بيئة الإنتاج

00:10:07.660 --> 00:10:10.960
يكمن الاختلاف عن الأتمتة الحالية في القدرة على التكيف

00:10:10.960 --> 00:10:15.740
تتعامل خطوط أنابيبي سي سيدي العادية مع تعرفات يمل الخاصة بكك حقائق مطلقة

00:10:15.740 --> 00:10:18.940
إنها تعمل حتى تتغير الواقع أو يحدث تحديث للمتطلبات

00:10:18.940 --> 00:10:22.060
أو زيادة مفاجئة في الطلب أو صدور تفويض امتثال جديد

00:10:22.060 --> 00:10:25.320
وعندها تتعطل تلك التعليمات الثابتة أو تمرر شيئا يبدو صحيحا

00:10:25.320 --> 00:10:26.680
ولكنه لا يلبي احتياجات العمل

00:10:26.680 --> 00:10:29.580
تتصرف خطوط الأنابيبي التي يقودها الوكيل بشكل مختلف

00:10:29.580 --> 00:10:33.900
فهي تتعامل مع تلك التعريفات كنقاط أساسية لكنها تحدثها عندما تتغير الظروف

00:10:33.900 --> 00:10:37.840
بدلا من انتظار شخص ما لتوسيع نطاق خدمة أو تعديل التوزيع الإقليمي

00:10:37.840 --> 00:10:41.200
يلاحظ الوكيل أنماط التحميل ويتوقع الحدود المحتملة

00:10:41.200 --> 00:10:43.300
ويوفر سعة إضافية مسبقا

00:10:43.300 --> 00:10:46.980
هذه القدرة على تكيف تجعل السيناريوهات أقل عرضة للخطأ من الناحية العملية

00:10:46.980 --> 00:10:50.320
تخيل تطبيق نيت يخدم حركة مرور في الغالب داخل الولايات المتحدة

00:10:50.320 --> 00:10:52.940
بعد أسبوع يظهر مستخدمون جدد في أوروبا

00:10:52.940 --> 00:10:56.720
يزداد زمن الاستجابة لكن لم يأخذ أحد في الاعتبار منطقة أخرى في ملف يمل الأصلي

00:10:56.720 --> 00:10:58.660
تتجاهل الأتمتة التقليدية ذلك

00:10:58.660 --> 00:11:01.300
لا تلاحظ الأمر إلا بعد تراكم الشكاوى والسجلات

00:11:01.300 --> 00:11:04.560
على النقيد من ذلك يحدد الوكيل النمط وينشر نسخة أوروبية

00:11:04.560 --> 00:11:06.820
ويهيئ التوجيه عبر أشر فرانت دور على الفور

00:11:06.820 --> 00:11:08.820
إنه لا يقوم بالنشر ثم ينسحب

00:11:08.820 --> 00:11:11.260
إنه يوافق الموارد باستمرار مع الأهداف المرجوة

00:11:11.260 --> 00:11:14.420
تقريبا مثل مشغل يعمل على مدار ساعة طوال أيام الأسبوع ولا يكل أبدا

00:11:14.420 --> 00:11:17.100
تمتد الفائدة الحقيقية إلى ما هو أبعد من مجرد التوسع

00:11:17.100 --> 00:11:19.500
يتم دمج الأمن والامتثال في حلقة العمل

00:11:19.500 --> 00:11:22.980
قد يبدو ذلك كأن يلاحظ الوكيل حاوية تخزين مكشوفة دون قصد

00:11:22.980 --> 00:11:28.860
فيقوم بقفلها تلقائيا أو يلاحظ انحرافا في خط أساس تصحيح الجهاز الافتراضي ويعيده إلى التوافق

00:11:28.860 --> 00:11:34.200
هذه مهام متكررة ومنخفضة الرؤية يكتشفها البشر عادة لاحقا وبعد بذل جهد

00:11:34.200 --> 00:11:39.100
من خلال دفعها إلى الدورة المستمرة أنت لا تستغني عن المشغلين بل تحررهم

00:11:39.100 --> 00:11:43.480
بدلا من قضاء طاقتهم في مكافحة الحرائق التقنية يركزون على التخطيط والاستراتيجية على مستوى أعلى

00:11:43.480 --> 00:11:45.380
وهذه نقطة دقيقة ومهمة

00:11:45.380 --> 00:11:47.160
الإشراف البشري لا يتلاشى

00:11:47.160 --> 00:11:51.500
يتغير دورك من فحص المربعات سطرا بسطر إلى تحديد المبادئ التوجهية في البداية

00:11:51.500 --> 00:11:56.980
أي المناطق مسموح بها وأي التكاليف مقبولة وأي معايير امتثال لا يمكن تجاوزها

00:11:56.980 --> 00:12:01.680
خطوة عملية لأي فريق يرغب في تجربة هذا هي تحديد حدود السياسات في وقت مبكر

00:12:01.680 --> 00:12:05.980
حدد سقفنا للتكاليف وعين المناطق المعتمدة وأضف حدود الامتثال

00:12:05.980 --> 00:12:09.580
يعمل الوكيل بعد ذلك كمنفذ وليس كمشغل غير مقيد

00:12:09.580 --> 00:12:11.180
هذا هو المبدأ الحاكم

00:12:11.180 --> 00:12:13.260
تظل أنت المتحكم في التوجيه الاستراتيجي

00:12:13.260 --> 00:12:15.920
بينما ينفذ الوكيل مهام الحماية على نطاق واسع

00:12:15.920 --> 00:12:19.340
هذا لا يعني أيضا أن تسلم بيئة الإنتاج بالكامل للوكيل في اليوم الأول

00:12:19.340 --> 00:12:20.700
إذا كنت تتجنب المخاطر

00:12:20.700 --> 00:12:22.900
ابدأ في بيئة اختبار خاضعة للرقابة

00:12:22.900 --> 00:12:25.400
أمنح الوكيل صلاحية التعامل مع أحمل غير حرجة

00:12:25.400 --> 00:12:28.380
أو اختر خدمة واحدة كالبنية التحتية للتخزين أو السجلات

00:12:28.380 --> 00:12:30.260
ودعه يدير الانحراف والتوفير فيها

00:12:30.260 --> 00:12:34.840
بهذه الطريقة تبني الثقة في كيفية تفسيره لضوابط الأمان قبل توسيع نطاق عمله

00:12:34.840 --> 00:12:38.800
اعتبر الأمر بمثابة تنفيذ مشروع تجريبي بنطاق محدد ومخاطر منخفضة

00:12:38.800 --> 00:12:42.180
وهو بالضبط كيف تندج معظم ممارسات ديف أوبيسي الموثوقة

00:12:42.180 --> 00:12:46.900
في جوهره يبدو النهج الوكيلي لم أشر أي آر سي أشبه بإدارة قائمة مراجعة ديناميكية

00:12:46.900 --> 00:12:49.420
بدلا من كتابة عشرات النصوص البرمجية الثابتة

00:12:49.420 --> 00:12:52.000
إنشاء القوالب وتشغيل فخصات ما قبل النشر

00:12:52.000 --> 00:12:53.220
ومراقبة الانحراف

00:12:53.220 --> 00:12:54.400
واقتراح الإصلاحات

00:12:54.400 --> 00:12:56.400
كل ذلك ضمن الحدود التي تضعها

00:12:56.400 --> 00:12:58.240
إنه منظم بما يكفي لكسب الثقة

00:12:58.240 --> 00:13:00.800
ومرن بما يكفي للتطور عند تغير الظروف

00:13:00.800 --> 00:13:05.180
بالطبع توفير البنية التحتية وتوسيع نطاقها هو جانب واحد فقط من الموثقية

00:13:05.180 --> 00:13:07.300
المشكلة الأكثر صعوبة تظهر لاحقا

00:13:07.300 --> 00:13:11.760
وهي ضمان أن الكودة الذي تنشره في تلك البيئة يصمد بالفعل في ظروف العالم الحقيقي

00:13:11.760 --> 00:13:13.460
وهنا يبدأ التحدي التالي في الظهور

00:13:13.460 --> 00:13:18.300
وهو مسألة اكتشاف الأخطاء التي لا يلحظها البشر ببساطة إلا بعد وصولها إلى بيئة الإنتاج

00:13:18.300 --> 00:13:19.340
الاختبار الذاتي

00:13:19.340 --> 00:13:21.160
الأخطاء التي يغفل عنها البشر

00:13:21.160 --> 00:13:23.760
الاختبارات تغطي فقط ما يمكن للبشر التفكير فيه

00:13:23.760 --> 00:13:25.500
وتلك هي نقطة القصور الأساسية

00:13:25.500 --> 00:13:28.160
معظم أعطال الإنتاج لا تأتي مما هو متوقع

00:13:28.160 --> 00:13:30.440
بل مما يخرج عن نطاق الخيال البشري

00:13:30.440 --> 00:13:35.080
تتدخل وكلاء الاختبار الذاتي لسد هذه الفجوة من خلال التركيز على الحالات النادرة والظروف الديناميكية

00:13:35.080 --> 00:13:37.360
التي لن تصل أبدا إلى مجموعة اختبار نموذجية

00:13:37.360 --> 00:13:39.920
فكر في حالة السباق أثناء توسيع النطاق

00:13:39.920 --> 00:13:44.440
قد يعمل تطبيق نيت على أشر بشكل مثالي تحت حمل ثقيل أثناء اختبار ضغط مخطط له

00:13:44.440 --> 00:13:48.140
ولكن عند حدوث توسيع للنطاق وإطلاق مثلات جديدة أثناء حركة المرور

00:13:48.140 --> 00:13:50.120
تظهر فجأة أخطاء في معالجة الجلسة

00:13:50.120 --> 00:13:52.680
ما لم يصمم شخص ما اختبارا خصيصا لهذا التداخل

00:13:52.680 --> 00:13:54.340
فإنه سيمر دون ملاحظة

00:13:54.340 --> 00:13:56.160
يكتشف الوكيل المستقل هذا الشدود

00:13:56.160 --> 00:13:59.380
ويعزله وينشئ اختبار تراجعا جديدا حول هذه الحالة

00:13:59.380 --> 00:14:01.480
في المرة القادمة التي يحدث فيها توسيع للنطاق

00:14:01.480 --> 00:14:02.840
يكون هذا الضمان موجودا بالفعل

00:14:02.840 --> 00:14:05.080
مما يحول مكان خطرا خفيا إلى سيناريو مراقبا

00:14:05.080 --> 00:14:06.940
مثال آخر هو تحوير المدخلات

00:14:06.940 --> 00:14:10.760
عادة ما يصمم المختبرون البشر اختباراتهم واضعين في اعتبارهم بيانات آمنة أو متوقعة

00:14:10.760 --> 00:14:13.340
أسماء مستخدمين صالحة أو حمولات اي بي أي صحيحة

00:14:13.340 --> 00:14:15.840
أو حالات نادرة واضحة مثل سلاسل النصية الفارغة

00:14:15.840 --> 00:14:20.240
في المقابل يبدأ الوكيل في تجربة متغيرات لن يفكر المطورون في تغطيتها

00:14:20.240 --> 00:14:24.940
طلبات ذات حجم ضخم ترميزات غريبة تأخيرات طفيفة بين المكالمات متعددة الخطوات

00:14:24.940 --> 00:14:29.080
من خلال القيام بذلك يمكنه إثارة إخفاقات قد تغفل عنها مجموعات الاختبار اليدوية تماما

00:14:29.080 --> 00:14:31.620
القيمة لا تكمن فقط في السرعة بل في التنوع

00:14:31.620 --> 00:14:36.860
يستكشف الوكلاء زوايا غريبة في مساحات المدخلات أسرع مما يمكن لأي حالات مكتوبة من قبل البشر القيام به

00:14:36.860 --> 00:14:40.860
ما يميز هذا التحول عن الأتمتة التقليدية هو كيفية تطور مجموعة الاختبارات

00:14:40.860 --> 00:14:44.300
تظل خزمة اختبارات الانحدار التي يصممها البشر ثابتة نسبيا

00:14:44.300 --> 00:14:47.800
فهي تعكس معرفة وافتراضات الفريق في لحظة زمنية معينة

00:14:47.800 --> 00:14:50.580
بينما تحولها الوكلاء الذكية إلى عملية مستمرة

00:14:50.580 --> 00:14:55.140
حيث توسع المجموعة مع تغير النظام وتستكشف دائما للحالات غير المتوقعة

00:14:55.140 --> 00:14:59.080
بدلا من تحديث المطورين للنصوص البرمجية الهشة بشق الأنفس بعد كل تكرار

00:14:59.080 --> 00:15:02.980
يتم إنشاء حالات جديدة ديناميكيا من ملاحظات حقيقية لسلوك النظام

00:15:02.980 --> 00:15:08.640
ومع ذلك هناك تحذير هام لا يستحق كل اختبار ينشئه الوكيل أن يبقى في مجموعتك الدائمة

00:15:08.640 --> 00:15:11.480
فالاختبارات غير المستقرة أو غير ذات السلة قد تتراكم بسرعة

00:15:11.480 --> 00:15:13.500
مما يهدر الوقت ويقوض ثقة في الأتمتة

00:15:13.500 --> 00:15:15.500
ولهذا السبب تبرز أهمية الحوكمة

00:15:15.500 --> 00:15:17.460
تحتاج الفرق إلى عملية مراجعة

00:15:17.460 --> 00:15:21.700
يجب على المطورين أو مهندسي ضمان الجودة التحقق من استقرار كل اختبار مقترح

00:15:21.700 --> 00:15:24.700
وأهميته للأعمال قبل دمجه في حزمة الاختبارات المستقرة

00:15:24.700 --> 00:15:26.560
وكما هو الحال مع أي أتمتة

00:15:26.560 --> 00:15:31.020
تضمن الرقابة أن تعزز هذه الأدوات الموثقية بدلا من إغراق الفرق بالضجيج

00:15:31.020 --> 00:15:35.300
هناك اعتقاد خاطئ آخر يستحق التصحيح وهو أن الوكلاء يقومون بإصلاح الأخطاء

00:15:35.300 --> 00:15:38.500
فهم لا يعيدون كتابة كود الإنتاج أو يصححون العيوب بأنفسهم

00:15:38.500 --> 00:15:43.180
ما يبرعون فيه بشكل أستثنائي هو إظهار سيناريوهات قابلة للتكرار مع تفاصيل تشخيصية واضحة

00:15:43.180 --> 00:15:48.740
بالنسبة للمطور فإن الخصول على خطوات مسجلة بواسطة الوكيل يختصر ساعات من التخمين ويسرع الإنجاز

00:15:48.740 --> 00:15:52.780
في بعض الحالات يمكن للوكلاء اقتراح حل محتمل بناء على أنماط معروفة

00:15:52.780 --> 00:15:55.300
لكن القرار النهائي والتغيير يظلان بيد البشر

00:15:55.300 --> 00:15:58.180
بهذه الطريقة يصبح تقسيم العمل أكثر وضوحا

00:15:58.180 --> 00:16:01.360
الآلات تقوم بالاكتشاف والبشر يقومون بالتقييم والإصلاح

00:16:01.360 --> 00:16:04.100
الأثر التجاري هنا هو تقليل العمليات الطارئة

00:16:04.100 --> 00:16:07.080
تشهد الفرق عددا أقل من التذاكر في وقت متأخر من الليل

00:16:07.080 --> 00:16:09.100
وقلة في عودة الأخطاء بعد الإصدارات

00:16:09.100 --> 00:16:11.940
وانخفاضا ملحوظا في الوقت الضائع في إعادة إنتاج الخطوات

00:16:11.940 --> 00:16:17.380
يتم اتشاف مشاكل الأداء في بيئات خاضعة للرقابة بدلا من ظهورها أمام المستخدمين النهائيين أولا

00:16:17.380 --> 00:16:19.940
تظهر الأخطاء الأمنية تحت الاختبار الداخلي

00:16:19.940 --> 00:16:22.880
وليس بعد إجراء مسح للامتثال أو اختبار اختراق

00:16:22.880 --> 00:16:27.260
هذا التحول يتيح مجالا لفريق ضمان جودة للتركيز على أسئلة رفعة المستوى مثل سهولة الاستخدام

00:16:27.260 --> 00:16:29.160
وسلاسة سير العمل وإمكانية الوصول

00:16:29.160 --> 00:16:32.320
وهي مجالات لا يمكن لأي محرك ذاتي التقييم الحكم عليها بشكل هادف

00:16:32.320 --> 00:16:34.500
بالنسبة للممارسين المهتمين بتجربة الأمر

00:16:34.500 --> 00:16:35.800
ابدأوا على نطاق صغير

00:16:35.800 --> 00:16:40.680
شغل وكيل اختبار ذاتي مقابل بيئة تجريبية أو ما قبل الإنتاج لفترة محددة

00:16:40.680 --> 00:16:44.200
قارن قائمة المشكلات التي يكشف عنها مع قائمة المهام الحالية لديك

00:16:44.200 --> 00:16:46.380
تعامل مع هذه التجربة كعملية جمع بيانات

00:16:46.380 --> 00:16:48.380
هل النتائج الجديدة مفيدة حقا؟

00:16:48.380 --> 00:16:50.260
هل تتداخل مع الاختبارات الموجودة؟

00:16:50.260 --> 00:16:52.500
هل تكشف عن نقاط عمياء تهم عملك؟

00:16:52.500 --> 00:16:55.020
من خلال هذا المنظور أن تقيس العائد على الاستثمار

00:16:55.020 --> 00:16:57.860
ولا تراهن بجودة إصدارك على تقنية غير مثبتة

00:16:57.860 --> 00:17:00.920
وعندما تقوم الفرق بتنفيذ هذه الأنواع من المشاريع التجريبية

00:17:00.920 --> 00:17:02.020
يظهر نمط معين

00:17:02.020 --> 00:17:05.980
لا تقتصر الفائدة الحقيقية طويلة الأمد على اكتشاف المزيد من الأخطاء فحسب

00:17:05.980 --> 00:17:08.940
بل في مدى سرعة دمج تلك الدروس في دورة التطوير الأوسع

00:17:08.940 --> 00:17:10.120
كل شدود يتم رصده

00:17:10.120 --> 00:17:11.620
وكل رؤية يتم تسجيلها

00:17:11.620 --> 00:17:14.180
تمثل معرفة لا ينبغي أن تتلاشى بانتهاء دورة العمل

00:17:14.180 --> 00:17:18.840
يصبح السؤال هو كيف يتم تخزين هذه المعلومات ومشاركتها ونقلها للأمام

00:17:18.840 --> 00:17:21.980
حتى لا تتكرر نفس الأخطاء تحت مسميات مشاريع مختلفة

00:17:21.980 --> 00:17:24.600
إغلاق حلقة المعلومات في بيئة دايف أوبس

00:17:24.600 --> 00:17:25.480
في بيئة دايف أوبس

00:17:25.480 --> 00:17:29.360
تعد سرعة تلاشي المعرفة بين دورات العمل واحدة من أصعب المشكلات التي يجب خلها

00:17:29.360 --> 00:17:31.500
تسجل المشكلات وتكتب تقارير ما بعد الوفاة

00:17:38.940 --> 00:17:42.240
هذه والتأكد من أن ما تتعلمه الفرق يحسن بالفعل ما سيأتي لاحقا

00:17:42.240 --> 00:17:43.540
يدعم الذكاء الاصطناعي الوكيل

00:17:43.540 --> 00:17:47.120
هذا الأمر من خلال الاتصال بالمواضع التي تتدفق فيها المعرفة بالفعل

00:17:47.120 --> 00:17:50.340
نقطة التكامل الأولى هي استيعاب السجلات والبيانات التشخصية

00:17:50.340 --> 00:17:54.280
بدلا من مطالبة المهندسين بالبحث في لوحات المعلومات أو الحوادث المؤرشفة

00:17:54.280 --> 00:17:58.120
تقوم الوكلاء بمسح المقاييس ومعدلات الخطأ ومسارات الأداء باستمرار

00:17:58.120 --> 00:17:59.780
وربط الشذوذ عبر الإصدارات

00:17:59.780 --> 00:18:02.020
النقطة الثانية هي تحليل سجل طلبات الدمج

00:18:02.020 --> 00:18:03.700
ومراجعة الكود

00:18:03.700 --> 00:18:07.540
غالبا ما تحتوي القرارات المتخدة في التعليقات على سياق حول المقاييضات أو المخاطر

00:18:07.540 --> 00:18:09.360
التي لا تصل أبدا إلى الوثائق الرسمية

00:18:09.360 --> 00:18:13.140
من خلال معالجة تلك المحادثات تحافظ الوكلاء على معرفة سبب حدوث شيء ما

00:18:13.140 --> 00:18:14.400
وليس فقط ما تم دمجه

00:18:14.400 --> 00:18:17.980
النقطة الثالثة هي ربط الإخفاقات المرسودة بتوصيات البنية التحتية

00:18:17.980 --> 00:18:22.100
إذا كانت استراتيجيات تخزين مؤقت معينة تسبب تضخما متكررا في الذاكرة

00:18:22.100 --> 00:18:24.340
أو إذا كانت أماط القياس تؤدي إلى انتهاء المهلة

00:18:24.340 --> 00:18:27.560
تظهر هذه الرؤى أثناء التخطيط قبل تكرار الأخطاء في نظام جديد

00:18:27.560 --> 00:18:32.300
تعمل نقاط التكامل هذه مجتمعة على تحسين الذاكرة المؤسسية دون الوعد بالكمال

00:18:32.300 --> 00:18:35.680
لا تكمن القيمة في أن الوكلاء يتذكرون كل التفاصيل بلا أخطاء

00:18:35.680 --> 00:18:38.880
بل في أنهم يزيدون من فرص ظهور دروس الماضي في الوقت المناسب

00:18:38.880 --> 00:18:41.180
تظل الرقابة البشرية أمرا مهما

00:18:41.180 --> 00:18:44.120
يجب على المطورين التحقق من سلة الرؤى المطروحة

00:18:44.120 --> 00:18:50.440
وينبغي للمؤسسات جدولة عمليات تدقيق منتظمة لما تلتقطه الوكلاء لتجنب الانحراف أو الضوضاء في النظام

00:18:50.440 --> 00:18:54.780
مع المراجعة الدقيقة تصبح المعلومات قابلة للتنفيذ بدلا من أن تكون مربكة

00:18:54.780 --> 00:18:57.340
الحوكمة هي جزء آخر لا يمكن تجاهله

00:18:57.340 --> 00:19:02.140
انتغذية السجلات وطلبات الدمج ونتائج النشر في نظام وكيل يطرح تساؤلات حول الخصوصية

00:19:02.140 --> 00:19:04.120
والاحتفاظ بالبيانات والامتثال

00:19:04.120 --> 00:19:06.380
لا ينبغي لكل مخرجات العمل أن تبقى للأبد

00:19:06.380 --> 00:19:09.180
ولا ينبغي لجميع البيانات أن تكون متاحة لكل الأدوار

00:19:09.180 --> 00:19:10.900
قبل طرح طبقة الذاكرة هذه

00:19:10.900 --> 00:19:14.260
تحتاج الفرق إلى تحديد حدود واضحة للاحتفاظ بالبيانات

00:19:14.260 --> 00:19:18.360
ووضع سياسات الوصول والتأكد من تنقية البيانات الحساسة أو حجبها

00:19:18.360 --> 00:19:23.180
بدون هذه الحدود تخاطر بإنشاء مستودع خفي غير خاضع للحوكمة لتاريخ الشركة

00:19:23.180 --> 00:19:25.640
مما يعقد عمليات التدقيق بدلا من دعمها

00:19:25.640 --> 00:19:29.220
بالنسبة للمطورين يظهر التأثير الأكثر وضوحا أثناء انطلاق المشروع

00:19:29.220 --> 00:19:32.040
بدلا من الذكريات الغامضة لما حدث خطأ في المرة السابقة

00:19:32.040 --> 00:19:33.880
تظهر الرؤى مباشرة في سياق العمل

00:19:33.880 --> 00:19:36.460
ابدأ واجهة برمجة تطبيقات نيل جديدة

00:19:36.460 --> 00:19:38.460
وقد ينبيك النظام قائلا في العام الماضي

00:19:38.460 --> 00:19:41.420
تسببت مكتبة التخزين المؤقت هذه في تسريب ذاكرة تحت ضغط العمل

00:19:41.420 --> 00:19:43.860
فكر في استخدام بديل أو أثناء التخطيط

00:19:43.860 --> 00:19:47.800
قد يشير النظام إلى أن أماطا معينة لحقن التبعية تسببت في عدم الاستقرار

00:19:47.800 --> 00:19:50.220
هذه التنبيهات تأتي في الوقت المناسب لا بأثر رجعي

00:19:50.220 --> 00:19:53.140
مما ينقل التركيز من رد الفعل تجاه المشكلات إلى منع حدوثها

00:19:53.140 --> 00:19:57.400
هكذا تتراكم معرفة المشروع بدلا من إعادة ضدها في كل مرة تبدأ فيها دورة عمل جديدة

00:19:57.400 --> 00:19:59.960
وهذا يغير إيضا طبيعة جلسات المراجعة

00:19:59.960 --> 00:20:03.660
تجمع المراجعات التقليدية الملاحظات في لحظة معينة ثم تنضي قدما

00:20:03.660 --> 00:20:05.320
مع وجود الوكلاء في الحلقة

00:20:05.320 --> 00:20:07.500
لا يتم ركن تلك المعرفة جانبا

00:20:07.500 --> 00:20:10.240
بل يتم دمجها باستمرار في دورة التطوير

00:20:10.240 --> 00:20:13.500
سجلات هذا الشهر وشذوذ القياس من الربع الماضي

00:20:13.500 --> 00:20:15.780
أو تراجع الأداء المسجل قبل عامين

00:20:15.780 --> 00:20:17.760
كلها تساهم في توصيات اليوم

00:20:17.760 --> 00:20:20.860
من خلال جعل كل إصدار جزءا من حلقة تدريب مستمرة

00:20:20.860 --> 00:20:23.840
تقلل الفرق من احتمالية تكرار الإخفاقات السابقة

00:20:23.840 --> 00:20:26.780
ومع ذلك يجب قياس النتائج لا افتراضها

00:20:26.780 --> 00:20:29.680
خطوة أولى بسيطة هي دمج الوكيل مع مصدر بيانات واحد

00:20:29.680 --> 00:20:32.840
مثل سجلات التطبيق أو تغذية APM وتشغيله لدورة عمل

00:20:32.840 --> 00:20:33.720
ثم قارن

00:20:33.720 --> 00:20:36.260
هل كشف الوكيل عن أنماط لم تكن قد لاحظتها

00:20:36.260 --> 00:20:39.560
هل أدت تلك الأنماط إلى تغييرات حقيقية في الكود أو البنية التحتية

00:20:39.560 --> 00:20:41.940
وهل تحسنت جودة الإصدار بشكل ملموس

00:20:41.940 --> 00:20:43.100
إذا كانت الإجابة نعم

00:20:43.100 --> 00:20:45.680
فمن المنطقي التوسع ليشمل سجل طلبات السحب PR

00:20:45.680 --> 00:20:47.000
أو رسم خرائط البنية

00:20:47.000 --> 00:20:47.960
وإن لم تكن كذلك

00:20:47.960 --> 00:20:50.240
فإن التجربة نفسها تكشف ما يحتاج إلى تعديل

00:20:50.240 --> 00:20:53.360
سواء في مصادر البيانات أو الحوكمة أو عمليات المراجعة

00:20:53.360 --> 00:20:55.900
مع مرور الوقت تكون العوائد تراكمية

00:20:55.900 --> 00:20:58.000
من خلال تحسين الذاكرة المؤسسية

00:20:58.000 --> 00:20:59.500
تستقر سرعة الإصدار

00:20:59.500 --> 00:21:01.420
وتصبح البنية أكثر مرونة

00:21:01.420 --> 00:21:04.880
ويقل هدر جهد المهندسين في إعادة اكتشاف الأخطاء القديمة

00:21:04.880 --> 00:21:06.380
تتوقف المعرفة عن الضياع

00:21:06.380 --> 00:21:09.880
وتتراكم بدلا من ذلك كمورد قابل للاستخدام تثق به الفرق

00:21:09.880 --> 00:21:10.880
وعند هذه النقطة

00:21:10.880 --> 00:21:12.900
يبدو دور ذكاء الاصطناعي الوكيل مختلفا

00:21:12.900 --> 00:21:15.600
فهو ليس مجرد مساعد في مرحلة واحدة من التطوير

00:21:15.600 --> 00:21:17.660
إنه يبدأ في ربط العملية بأكملها

00:21:17.660 --> 00:21:20.360
وتمرير الدروس المستفادة بدلا من تركها تندثر

00:21:20.360 --> 00:21:25.340
هذا الاستمرار هو ما يحول ديف أوكس من مجموعة مهام معزولة إلى دورة حياة أكثر ترابطا

00:21:25.340 --> 00:21:29.300
مما يمهد الطريقة للتحول الأوسع الذي يحدث الآن في فرق البرمجيات

00:21:29.300 --> 00:21:33.160
يعد الذكاء الاصطناعي الوكيل مؤشرا على تحول عملي في التطوير

00:21:33.160 --> 00:21:35.800
المفهوم إنه ليس مساعدا للكتابة البرمجية

00:21:35.800 --> 00:21:39.280
بل نظام يحمل الذاكرة والسياق والأهداف عبر دورة الحياة الكاملة

00:21:39.280 --> 00:21:41.480
التطبيق أوضح نقاط الدخول لفرق

00:21:41.480 --> 00:21:43.740
نيت وأشر هي هي هيكلة المشاريع الجديدة

00:21:43.740 --> 00:21:48.360
والسماح للوكلاء بالتعامل مع التزويد الروتيني وتجربة توليد الاختبارات المؤتمتة

00:21:48.360 --> 00:21:51.820
الأثر إذا تم تنفيذه بعناية فإنه يبسط سير العمل

00:21:51.820 --> 00:21:56.240
ويقلل من أعباء الإعداد ويخفض فرص تكرار الإخفاقات السابقة عبر المشاريع

00:21:56.240 --> 00:21:59.240
أفضل خطوة تالية هي اختباره في بيئتك الخاصة

00:21:59.240 --> 00:22:02.740
جرب تفعيل كوبيلوت في نموذج أولي صغير أو شغل عاملا برمجيا في بيئة الاختبار

00:22:02.740 --> 00:22:06.900
ثم تتبع مقياسا وحدا الوقت الموفرة أو الأخطاء المكتشفة أو الانحرافات التي تم منعها

00:22:06.900 --> 00:22:10.020
إذا كنت تواجه تحديا متكررا في ديف أوبس يبطئ عمل فريقك

00:22:10.020 --> 00:22:12.320
شاركه في التعليقات ليتسنى للآخرين المقارنة

00:22:12.320 --> 00:22:16.380
وإذا كنت ترغب في نصائح أكثر واقعية حول نيت وأشر وتبني الذكاء الاصطناعي

00:22:16.380 --> 00:22:18.200
اشترك لمتابعة التحليلات المستقبلية

00:22:18.200 --> 00:22:19.860
قد تبدو المكاسب صغيرة في البداية

00:22:19.860 --> 00:22:22.940
لكنها تتضاعف مع الحوكمة والرقابة والتطوير المستمر