WEBVTT

00:00:00.000 --> 00:00:07.520
هل أنت مستعد لعشرة أيام من مايكروسوفت 365 وكو بايلوت والذكاء الاصطناعي وأشر ومن يصيغون مستقبل العمل؟

00:00:07.520 --> 00:00:12.500
في يناير القادم يعود مؤتمر M365 وسنقدم لكم نسخة أكبر

00:00:12.500 --> 00:00:18.260
انضم إلينا في جلسات مباشرة وعروض واقعية ومعرفة عملية من خبراء مايكروسوفت وأبرز المتخصصين حول العالم

00:00:18.260 --> 00:00:22.140
لا شرائح عرض تقليدية لا مصطلحات جوفاء لا تنتهي

00:00:22.140 --> 00:00:29.320
نحن نعالج التحديات الحقيقية كو بايلوت ستوديو ووكلاء الذكاء الاصطناعي وفابريك والأمن والحوكمة والأتمتة

00:00:29.320 --> 00:00:33.300
سواء كنت متخصصا في تقنية المعلومات أو مطورا أو قائدا للأعمال

00:00:33.300 --> 00:00:35.200
هناك جلسات مصممة خصيصا لك

00:00:35.200 --> 00:00:40.540
عبر عشر أيام كاملة يمكنك استكشاف تقنيات متعددة والتواصل مع مجتمع عالميا

00:00:40.540 --> 00:00:44.640
شاهد الفعاليات مباشرة وانقل رؤى عملية إلى مؤسستك

00:00:44.640 --> 00:00:49.380
يناير 2027 عشر أيام مجتمع مايكروسوفت واحد

00:00:49.380 --> 00:00:51.240
التسجيل مفتوح الآن

00:00:51.240 --> 00:00:55.940
توجه إلى M365.net وحجز مقعدك اليوم

00:00:55.940 --> 00:00:59.720
الموقع هو M365.net

00:00:59.720 --> 00:01:02.540
انضم الآن عبر M365.net

00:01:02.540 --> 00:01:04.980
وسنلتقي بكم مباشرة في يناير

00:01:04.980 --> 00:01:10.580
إذا سبق لك فتح حل برمجي وشعر تفورا بالإرهاق من كثرة الملفات والمراجع والأخطاء الكامنة بانتظارك

00:01:10.580 --> 00:01:11.640
فأنت لست وحدك

00:01:11.640 --> 00:01:15.660
يعمل معظم المطورين بطريقة تفاعلية حيث يقومون بالتصحيح هنا وإصلاح الأخطاء هناك

00:01:15.660 --> 00:01:20.260
يهدف وضع الوكيل agent mood في بيتهب كوبايلوت إلى استيعاب سياق أوسع وتنسيق التغييرات عبر الملفات

00:01:20.260 --> 00:01:25.160
في هذا الفيديو سنعرض كيف يبدو سير العمل هذا داخل مشروع حقيقي لمبودكاست.net وأشر

00:01:25.160 --> 00:01:28.700
سنستعرض حلا برمجيا مباشرا ونقارن التغييرات قبل وبعد استخدام الوكيل

00:01:28.700 --> 00:01:31.520
سترى كيفية إنشاء قود لملفات متعددة بجهد أقل

00:01:31.520 --> 00:01:33.540
وحل أخطاء الملفات المتقطعة بسرعة

00:01:33.540 --> 00:01:36.320
وحتى استخدام مواصفات باللغة الطبيعية لهيكلة الميزات

00:01:36.320 --> 00:01:37.540
وقبل أن نصل إلى ذلك

00:01:37.540 --> 00:01:41.260
دعونا نبدأ بالتكلفة الخفية لحلقة تصحيح الأخطاء التي يعيشها الكثير من يوميا

00:01:41.260 --> 00:01:43.840
التكلفة الخفية لتصحيح الأخطاء المجزئي

00:01:43.840 --> 00:01:46.360
تجلس لإصلاح خطأ يبدو بسيطا بما يكفي

00:01:46.360 --> 00:01:50.580
لا يتم بناء التطبيق وتشير وحدة التحكم إلى سطر في ملف المشروع الرئيسي الخاص بك

00:01:50.580 --> 00:01:52.360
تعدل الطريقة وتعيد الترجمة

00:01:52.360 --> 00:01:56.140
وتظن أنك حللت الأمر حتى تظهر رسالة نفسها بشكل مختلف قليلا

00:01:56.140 --> 00:01:59.400
يمضي نصف ساعة أخرى قبل أن تكتشف المشكلة الحقيقية

00:01:59.400 --> 00:02:02.420
اعتمادية مفقودة مخبأة في مجلد مشروع آخر

00:02:02.420 --> 00:02:04.780
بحلول الوقت الذي يتم فيه تصحيح المرجع وإعادة النشر

00:02:04.780 --> 00:02:07.320
تكون معظم فترة بعد الظهر قد ضعت في الإصلاحات المتقطعة

00:02:07.320 --> 00:02:09.920
يتم تأجيل عمل الميزات الذي خطط له إلى الغد

00:02:09.920 --> 00:02:12.400
هذا النمط شائع جدا لدرجة أنه يبدو طبيعيا

00:02:12.400 --> 00:02:15.620
ظاهريا أن تتقدم لأن كل خطأ تقضي عليه يبدو وكأنه انتصار

00:02:15.620 --> 00:02:17.720
عمليا أن تدور في حلقات مفرغة

00:02:17.720 --> 00:02:21.280
الحلقة هي كتابة الكود الترجمة ظهور الخطأ الإصلاح ثم التكرار

00:02:21.280 --> 00:02:23.660
تضيع الساعات في مطاردة سلسلة من الأسباب والنتائج

00:02:23.660 --> 00:02:26.780
والنتيجة النهائية هي تقدم تفعلي بدلا من تحسينات ذات مغزا

00:02:26.780 --> 00:02:29.560
كم منكم أضاع فترة بعد الظهر في هذه الحلقة تحديدا

00:02:29.560 --> 00:02:31.020
أترك تعليقا من سطر واحد

00:02:31.020 --> 00:02:32.720
وسأقرأ الردود الأكثر تفاعلا

00:02:32.720 --> 00:02:37.420
ما يجعل هذه الدورة مرهقة هو أن الأدوات من حولنا تتطور بينما يظل النمط كما هو

00:02:37.420 --> 00:02:38.880
تضيف المحررات ميزات جديدة

00:02:38.880 --> 00:02:41.560
وتتطور الأطور البرمجية وتزداد التكاملات عمقنا

00:02:41.560 --> 00:02:43.800
لكن التصحيح لا يزال يتطلب نجنا رد فعلا

00:02:43.800 --> 00:02:47.060
الأمر أشبه بمحاولة إخماد حريق متزايد بدلو من الماء

00:02:47.060 --> 00:02:48.780
يتم التعامل مع كل دلاع في لحظته

00:02:48.780 --> 00:02:51.040
لكن الظروف الكامنة التي أوقدته تضل قائمة

00:02:51.040 --> 00:02:52.640
مما يضمن تقريبا الحريق التالي

00:02:52.640 --> 00:02:54.300
ومع كل تبديل لعلامة التبويب

00:02:54.300 --> 00:02:55.600
ترتفع التكلفة الخفية

00:02:55.600 --> 00:02:57.720
تنتقل من فئة الخدمة إلى ملف التكوين

00:02:57.720 --> 00:02:59.940
ثم تقفز عبر رسم بياني للتبعية

00:02:59.940 --> 00:03:02.720
كل تحول يسحبك بعيدا عن أي خيط منطقي تتبعه

00:03:02.720 --> 00:03:04.400
مما يفرد إعادة تعيين ذهنية

00:03:04.400 --> 00:03:06.860
ليس الأمر مجرد ثوان تقضيها في تنقل بين النوافذ

00:03:06.860 --> 00:03:09.620
بل هو الضريبة الذهنية لإعادة بناء السياق مرارا وتكرارا

00:03:09.620 --> 00:03:10.320
على مدار اليوم

00:03:10.320 --> 00:03:13.200
تتراكم عمليات إعادة تعيين صديرة هذه لتصبح عبنا ثقيلا

00:03:13.200 --> 00:03:14.580
بالنسبة للمطورين الأفراد

00:03:14.580 --> 00:03:16.780
يظهر التعب في شكل إحباط ووقت ضائع

00:03:16.780 --> 00:03:19.420
بالنسبة للفرق التي تعمل على مشاريع مؤسسية

00:03:19.420 --> 00:03:20.520
يتضاعف التأثير

00:03:20.520 --> 00:03:22.780
حلقات التصحيح تخرج أهداف السبرينت عن مسارها

00:03:22.780 --> 00:03:24.160
وتؤخر إطلاق الميزات

00:03:24.160 --> 00:03:26.560
وتفتح تراكم عمل ينمو أسرع مما يتقلص

00:03:26.560 --> 00:03:29.240
تفاقم الديون التقنية ليس سوى تأثير جانبي آخر

00:03:29.240 --> 00:03:31.160
للساعات المفقودة في مكافحة الحرائق

00:03:31.160 --> 00:03:33.440
تشير العديد من الفرق إلى أن جزءا كبيرا

00:03:33.440 --> 00:03:35.640
من وقت تطويرها يستنزف في التصحيح التفاعلي

00:03:35.640 --> 00:03:37.720
إنه ليس الجزء المثير في الهندسة

00:03:37.720 --> 00:03:41.500
لا أحد يخطط لخريطة طريق تعتمد على ملاحقة نفس عدم تطابق التبعيات خمس مرات

00:03:41.500 --> 00:03:44.120
ومع ذلك هذا هو المكان الذي تذهب إليه الموارد

00:03:44.120 --> 00:03:44.900
أسبوعا تلو الآخر

00:03:44.900 --> 00:03:47.240
عندما يصبح إصلاح الأخطاء هو تعريف التقدم

00:03:47.240 --> 00:03:51.360
تصبح بناء الميزات الجديدة ثانوية وتعاني البنية التحتية بصمت في الخلفية

00:03:51.360 --> 00:03:55.300
الحقيقة المزعجة هي أن التصحيح الترقيعي لا يبطئ الأمور فحسب

00:03:55.300 --> 00:03:58.520
إنه يعزز ثقافة رد الفعل بدلا من التصميم

00:03:58.520 --> 00:04:01.960
أن تقضي وقتك في إخماد النيران لا في بناء الأنظمة

00:04:01.960 --> 00:04:04.140
قد يبقي ذلك المنتج حيا على المدى القصير

00:04:04.140 --> 00:04:07.340
لكنه يحد من مدى توسع الفريق ومدى ثقتهم في التسليم

00:04:07.340 --> 00:04:09.980
لذا دعونا نتوقف عند هذه الصورة مكافحة الحرائق

00:04:09.980 --> 00:04:12.740
أن دفع إلى بؤرة الاشتعال أسكب الماء ثم انتقل لما بعده

00:04:12.740 --> 00:04:15.020
المشكلة ليست في أن المطورين ليسوا بارعين في ذلك

00:04:15.020 --> 00:04:16.100
إنهم بارعون

00:04:16.100 --> 00:04:18.500
المشكلة هي أن النيران لا تتوقف حقا

00:04:18.500 --> 00:04:20.720
إنها تتحرك فقط تندلع في ملفات جديدة

00:04:20.720 --> 00:04:22.520
مشاريع جديدة تكوينات جديدة

00:04:22.520 --> 00:04:24.940
مما يبقي الجميع في وضع الاستجابة بدلا من وضع الإبداع

00:04:24.940 --> 00:04:25.940
هذا يطرح السؤال

00:04:25.940 --> 00:04:29.300
ماذا يحدث لو لم تكن هذه الدورة ملقاة على عاتقك وحدك

00:04:29.300 --> 00:04:31.460
ماذا لو أمكن إدارة الأجزاء المتكررة

00:04:31.460 --> 00:04:36.260
حلقة التتبع والتبديل والتصحيح بشكل مختلف بينما تظل أنت مركزا على البناء

00:04:36.260 --> 00:04:38.700
لأنه بينما يبدو ضغط مكافحة الحرائق واضحا

00:04:38.700 --> 00:04:40.940
هناك نقطة ضغط أخرى لم نتطرق إليها بعد

00:04:40.940 --> 00:04:44.800
تأتي الصعوبة الحقيقية عندما لا يقتصر مشروعك على ملف واحد أو وحدة واحدة

00:04:44.800 --> 00:04:48.480
تحدث عندما يمتد الإصلاح الذي تحتاجه ليشمل طبقات متعددة في وقت واحد

00:04:48.480 --> 00:04:54.380
تخيل أنك تجلس لفتح حل برمجي تتوزع منطقياته عبر مشاريع وخدمات ومكتبات مختلفة

00:04:54.380 --> 00:04:57.300
الجزء الذي تحتاجه موجود في ثلاثة أماكن في آن واحد

00:04:57.300 --> 00:05:00.500
والحفاظ على تركيزك في هذا التشتت هو معركة بحد ذاتها

00:05:00.500 --> 00:05:04.040
فوضى الملفات المتعددة مقابل التحكم في السياق عبر الذكاء الاصطناعي

00:05:04.040 --> 00:05:08.320
عندما تمتد المشاريع عبر طبقات متعددة لا تكمن التحدي الحقيقي في كتابة الكودي

00:05:08.320 --> 00:05:11.100
بل في الحفاظ على ترابط كل تلك الأجزاء المتحركة معا

00:05:11.100 --> 00:05:15.820
هنا يظهر بوضوح التوتر بين فوضى الملفات المتعددة والتحكم في السياق المدعوم بالذكاء الاصطناعي

00:05:15.820 --> 00:05:19.200
خذ على سبيل المثال حل نيت كبيرا يضم عشرة مشاريع أو أكثر

00:05:19.200 --> 00:05:22.480
عادة ما تؤثر أي ميزة جديدة على طبقات مختلفة في وقت واحد

00:05:22.480 --> 00:05:27.620
متحكم في مكان وخدمة في آخر ومجموعة من ملفات الإعدادات في مكان ثالث

00:05:27.620 --> 00:05:31.600
قبل أن تكتب سطرا وحدا تقضي وقتا في تتبع المراجع وفحص التبعيات

00:05:31.600 --> 00:05:35.420
على أمل أن لا يؤدي تغيير بسيط إلى أعطال غير متوقعة في السلسلة

00:05:35.420 --> 00:05:37.440
هذا النمط في العمل ليس استثناء

00:05:37.440 --> 00:05:42.620
بل هو الوضع الطبيعي في تطبيقات المؤسسات خاصة عند دخول خدمات أشر والتكاملات في الصورة

00:05:42.620 --> 00:05:45.000
هيكلية هذه الأنظمة ليست مصطحة

00:05:45.000 --> 00:05:50.000
تلعب الواجهات وتعينات حقن التبعية دي والمراجع العابرة للمشاريع أدوارا محورية

00:05:50.000 --> 00:05:53.620
مع وجود أشر تخرج بعض التبعيات تماما عن نطاق مجلد الحل

00:05:53.620 --> 00:05:58.380
مثل تطبيقات الوظائف وربط ناقل الخدمة وإعدادات الموارد واتصالات التخزين

00:05:58.380 --> 00:06:03.820
أن تنسق بين الكود في بيئة التطوير وملفات الإعدادات على القرص والخدمات المعرفة في السحابة

00:06:03.820 --> 00:06:06.500
لا أحد منها يهتم برغبتك في تقليل عدد النقارات

00:06:06.500 --> 00:06:10.200
في كل مرة تغير فيها السياق تستهلك طاقتك في إعادة بناء الصورة الكبيرة

00:06:10.200 --> 00:06:12.980
يحاول معظمنا التوفيق بين هذا السياق في ذاكرة العمل الخاصة به

00:06:12.980 --> 00:06:14.880
في البداية يكون الأمر قابلا للإدارة

00:06:14.880 --> 00:06:16.820
ولكن مع نمو المشروع تتسلل الأخطاء

00:06:16.820 --> 00:06:20.260
تضيف طريقة جديدة في الخدمة لكنك تنسى تسجيلها في حقن التبعية دي

00:06:20.260 --> 00:06:24.920
تكتب كود وظيفة أشر ثم تكتشف لاحقا أن الربط لم يضيف إلى ملف هوست جيسون أو قالب النشر

00:06:24.920 --> 00:06:28.480
لا شيء ينبهك حتى وقت التشغيل حيث تجد نفسك في مرحلة التصحيح بدلا من البناء

00:06:28.480 --> 00:06:30.320
الكود بحد ذاته ليس الجزء الصعب

00:06:30.320 --> 00:06:32.640
الجزء الصعب هو التنسيق بين الملفات المختلفة

00:06:32.640 --> 00:06:36.080
يعرف الجميع شعور التنقل بين علامات التبويب من متحكم إلى خدمة

00:06:36.080 --> 00:06:38.380
ثم إلى نموذج ثم إلى ملفات الإعدادات

00:06:38.380 --> 00:06:41.760
ثم العودة مجددا فقط لتفقد سبب فتحك لهذا الملف من الأساس

00:06:41.760 --> 00:06:44.780
إنهم قطاع بسيط يتكرر عشرات المرات في اليوم

00:06:44.780 --> 00:06:48.740
تتراكم تلك التفاعلات مما يخلق احتكاكا يعيق التقدم الحقيقية

00:06:48.740 --> 00:06:51.440
النتيجة هي بطء في التسليم ليس لأن الكتابة بطيئة

00:06:51.440 --> 00:06:54.000
بل لأن الحفاظ على مزامنة كل شيء يشتط التركيز

00:06:54.000 --> 00:06:57.180
تتزايد هذه الأعباء في المشاريع المعتمدة على السحابة أولا

00:06:57.180 --> 00:06:59.940
توزع أشر الأعدادات الرئيسية في أماكن متعددة

00:06:59.940 --> 00:07:01.800
مثل ملفات التكوين المحلية

00:07:01.800 --> 00:07:04.920
ومتغيرات البيئة وقوالب أرم أو بي سيب

00:07:04.920 --> 00:07:06.640
وخطوط أنا بي بي سي سي دي

00:07:06.640 --> 00:07:08.700
ما يبدو كطلب ميزة واحد غالبا

00:07:08.700 --> 00:07:10.760
ما يمتد عبر أربع طبقات من التجريد

00:07:10.760 --> 00:07:12.460
هذا التعقيد ليس اختياريا

00:07:12.460 --> 00:07:15.220
إنه جزء لا يتجزأ من طريقة عمل النظام البيئي

00:07:15.220 --> 00:07:16.640
هنا يأتي دور وضع الوكيل

00:07:16.640 --> 00:07:18.280
أيجنت مود كتحول محتمل

00:07:18.280 --> 00:07:20.080
بدلا من ترك كل هذا التنسيق لك

00:07:20.080 --> 00:07:22.820
فقد صم ما ليمتلك سياقا أو سع عبر ملفات متعددة

00:07:22.820 --> 00:07:25.540
هذا يعني أنه عندما تطلب تغييرا في طبقة واحدة

00:07:25.540 --> 00:07:27.320
فإنه لا يتجاهل الطبقات الأخرى

00:07:27.320 --> 00:07:29.840
في العرض التوضيحي سأنشئ وظيفة أشر جديدة

00:07:29.840 --> 00:07:32.360
وأعرض كيف يساعد الوكيل عبر إنشاء متن الطريقة

00:07:32.360 --> 00:07:35.260
وإعداد تكوين الربط وتحديث هوست جيسا

00:07:35.260 --> 00:07:37.820
وحتى اقتراح تسجيل حقن التبعية دي المناسب

00:07:37.820 --> 00:07:41.320
عادة ما تكون هذه عملية متعددة الخطوات ومشتتة عبر ملفات مختلفة

00:07:41.320 --> 00:07:43.820
يمكن للوكيل تبسيطها في تدفق عمل واحد

00:07:43.820 --> 00:07:45.640
لا يتعلق الأمر باستبدال حكمك

00:07:45.640 --> 00:07:47.660
بل بإزالة المهام الإدارية المتكررة

00:07:47.660 --> 00:07:50.260
حتى تتمكن من التركيز على خيارات التصميم الفعلية

00:07:50.260 --> 00:07:54.320
يمكن للبشر الاحتفاظ بمخطط تقريبي في أذهانهم أو رسمه على سبورة بيضاء

00:07:54.320 --> 00:07:58.080
يمكن للذكاء الاصطناعي تتبع التفاصيل ملفا تلو الآخر دون فقدان الخيط

00:07:58.080 --> 00:08:01.820
ما يبدو عبنا ذهنيا كبيرا بالنسبة لنا هو مجرد سياق أساسي للوكيل

00:08:01.820 --> 00:08:06.420
الفرق في الممارسة العملية هو الانتقال من التبديل المشتت بين علامات التبويب إلى تغييرات منسقة تبقى متزامنة

00:08:06.420 --> 00:08:07.540
سأعرض أيضا طلب السحب

00:08:07.540 --> 00:08:08.820
أو الاختلافات

00:08:08.820 --> 00:08:13.120
التي أنشأها الوكيل خلال العرض التوضيحي حتى تتمكن من رؤية التعديلات التي تم إجراؤها بدقة

00:08:13.120 --> 00:08:14.460
تلك الرؤية مهمة

00:08:14.460 --> 00:08:19.140
تحصل على تحكم كامل للمراجعة والموافقة بينما يتم إنجاز العمل الشاقي لتحديث ملفات متعددة نيابة عنك

00:08:19.140 --> 00:08:21.460
بدلا من قضاء فترة بعد الظهر في ربط الأجزاء ببعضها

00:08:21.460 --> 00:08:26.260
تقوم بتوجيه التغيير مرة واحدة وتأكيد التحديثات التي تم إنشاؤها والانتقال إلى تصميم عالي المستوى

00:08:26.260 --> 00:08:29.060
الراحة ليست فقط في توفير النقرات أو ضغطات المفاتيح

00:08:29.060 --> 00:08:34.100
بل في البقاء مركزا على حل المشكلات الفعلية بدلا من تتبع كيفية اتصال عشرات الملفات

00:08:34.100 --> 00:08:36.440
تظهر هذه الميزة بوضوح أكبر عند تعطل الأمور

00:08:36.440 --> 00:08:42.220
لأنه حتى مع معالجة سياق أقوى تفشل الأنظمة وتنحرف التكوينات وتتسلل المراجع غير المتطابقة مجددا

00:08:42.220 --> 00:08:43.980
وهنا يبدأ الاختبار التالي

00:08:43.980 --> 00:08:47.040
كيفية تتبع الأخطاء وحلها بمجرد ظهورها

00:08:47.040 --> 00:08:49.500
من البحث عن الأخطاء إلى الإصلاحات الذاتية

00:08:49.500 --> 00:08:53.340
فكر في عدد المرات التي واجهت فيها رسالة خطأ تشير مباشرة إلى ملف واحد

00:08:53.340 --> 00:08:56.280
تتبع تتبع المكدس إلى الطريقة التي يسميها

00:08:56.280 --> 00:08:58.720
وتقوم بتعديل صغير ثم تضغط على إعادة البناء

00:08:58.720 --> 00:09:03.300
يبدو الأمر حلا بديهينا حتى يظهر نفس الخطأ مرة أخرى بشكل مختلف قليلا

00:09:03.300 --> 00:09:06.280
عندها تدرك أن تتبع المكدس أظهر العرض فقط

00:09:06.280 --> 00:09:08.380
المشكلة الحقيقية تكمن في مكان آخر تماما

00:09:08.380 --> 00:09:11.820
ربما في فئة داعمة أو مخفية داخل ملف تكوين لم تفتحه طوال الأسبوع

00:09:11.820 --> 00:09:14.100
كل مطور واجه هذا النوع من التضليل

00:09:14.100 --> 00:09:16.700
ما يبدو أنه المشكلة ليس هو في الواقع مكان الحل

00:09:16.700 --> 00:09:18.280
هذا يستهلك الوقت بسرعة

00:09:18.280 --> 00:09:20.900
تعدل شيئا وحدا ثم تعيد البناء وتنتظر

00:09:20.900 --> 00:09:24.020
ثم يواجهك خطأ جديد يقودك إلى ملف آخر وتعديل آخر

00:09:24.020 --> 00:09:25.160
وإعادة بناء أخرى

00:09:25.160 --> 00:09:28.960
تبدو الحلقة الإنتاجية وكأنها عمل مستمر لأنك تتحرك وتكتب وتعيد التجميع

00:09:28.960 --> 00:09:32.100
لكنها في جوهرها تجربة وخطأ أكثر من كونها حلا فعليا

00:09:32.100 --> 00:09:38.520
هذه الدورة يمكن أن تلتهم الساعات تاركة إياك مع إصلاحات سطحية بسيطة دون أي تقدم حقيقي في الميزة التي بدأت بها

00:09:38.520 --> 00:09:40.880
التكلفة الحقيقية هنا هي ضياع الفرص

00:09:40.880 --> 00:09:43.760
بينما أنت عالق في وطيرة إعادة البناء والمحاولة

00:09:43.760 --> 00:09:47.780
فأنت لا تحل مشاكل العمل ولا تقدم الوظائف التي ينتظرها المستخدمون

00:09:47.780 --> 00:09:50.300
يضيع الزخم في التخمين بدلا من التصميم

00:09:50.300 --> 00:09:52.280
يبدو الأمر نشطنا في تلك اللحظة

00:09:52.280 --> 00:09:55.960
لكن تلك الساعات لا تضيف الكثير سوى منع النظام من التعطل

00:09:55.960 --> 00:10:01.820
على مستوى الفريق تقطئ هذه الحركة السطحية كل شيء وتخلق تراكما في الميزات التي تستمر في التأجيل

00:10:01.820 --> 00:10:04.840
هنا يبدأ سير عمل الوكيل في الاختلاف

00:10:04.840 --> 00:10:08.620
الفكرة ليست التوقف عند السطر الواحد الذي يبزه تتبع المكدس ستاك تريس

00:10:08.620 --> 00:10:11.900
بدلا من ذلك تم تصميمه ليحتفظ بسياق على مستوى النظام

00:10:11.900 --> 00:10:14.180
لا يسأل فقط عما يجب أن يفعله هذا الملف

00:10:14.180 --> 00:10:17.940
بل ما هي سلسلة التغييرات المطلوبة عبر الأجزاء المتصلة لاستعادة الاتصاق

00:10:17.940 --> 00:10:22.380
من الناحية العملية هذا يعني أنك قد تراه يقترح تعديلات تمتد عبر ملفات متعددة

00:10:22.380 --> 00:10:25.900
على سبيل المثال سترى في العرض التوضيحي أنه عندما تتطلب إحدى الطرق تغييرات

00:10:25.900 --> 00:10:29.280
يمكنه اقتراح تعديلات مطابقة في ملفات التكوين ذات السلة أو قوالب النشر

00:10:29.280 --> 00:10:30.800
بدلا من تركك تبحث عنها بنفسك

00:10:30.800 --> 00:10:33.740
تلك هي القفزة من الإكمال التلقائي إلى شيء أوسع

00:10:33.740 --> 00:10:36.740
الإكمال التلقائي ينهي الأسطرة أما الوكيل فينسق عبر الملفات

00:10:36.740 --> 00:10:40.520
وهذا التنسيق يهم أكثر عندما لا تكون الأخطاء موجودة في مكان واحد بوضوح

00:10:40.520 --> 00:10:42.600
لنأخذ سيناريو شائعا في أشر

00:10:42.600 --> 00:10:44.160
لقد أنشأت تطبيق وظيفة جديدا

00:10:44.160 --> 00:10:48.300
ولكن بمجرد نشره يفشل مشغل قائمة الانتظار لأن الربط لا يتطابق مع توقيع الطريقة

00:10:48.300 --> 00:10:51.500
عادة تقوم بالتنقيب في السجلات ومعرفة أي ربط هو الخاطئ

00:10:51.500 --> 00:10:53.120
وتعديل جايسون الوظيفة يدويا

00:10:53.120 --> 00:10:57.320
وربما حتى تغيير قالب البنية التحتية الخاص بك إذا كانت القيمة غير متطابقة هناك أيضا

00:10:57.320 --> 00:11:01.640
كل خطوة هي مطاردة منفصلة وكل إصلاح يؤدي إلى تشغيل اختبار آخر

00:11:01.640 --> 00:11:04.060
مع وضع الوكيل يختلف سير العمل

00:11:04.060 --> 00:11:07.260
يمكنه اقتراح تغيير الكود وإنشاء ربط جايسون الوظيفة المناسب

00:11:07.260 --> 00:11:10.340
وإظهار التعديلات لنصوص المشر البرمجية إذا كانت غير متوافقة

00:11:10.340 --> 00:11:14.400
أن تراجع وتؤكد وتمضي قدما دون قضاء ساعات في تجميع كل طبقة معا

00:11:14.400 --> 00:11:15.800
والثقة هي المفتاح هنا

00:11:15.800 --> 00:11:18.620
لا ينبغي لأحد أن يشعر بأن تعديلات غير مرئية تحدث في الخلفية

00:11:18.620 --> 00:11:20.580
لهذا السبب فإن عملية المراجعة مهمة

00:11:20.580 --> 00:11:22.820
في هذا العرض التوضيحي سنستعرض ذلك معا

00:11:22.820 --> 00:11:24.740
يقترح الوكيل التغييرات المنسقة

00:11:24.740 --> 00:11:27.720
سنفتح ملف الفرق دف لنفحص بدقة ما تم إنشاؤه

00:11:27.720 --> 00:11:30.860
ونشغل اختباراتنا الوحدوية ونتحقق من البناء محليا

00:11:30.860 --> 00:11:33.080
وعندها فقط نختار قبول التعديلات أو رفضها

00:11:33.080 --> 00:11:37.000
حلقة التحقق هذه تبقي كفي كامل السيطرة بينما تتخلص من الأعمال الشاقة

00:11:37.000 --> 00:11:39.640
تجدر الإشارة إلى أن الوكلاء يمكنهم المساعدة في تسريع العمل

00:11:39.640 --> 00:11:41.640
لكنهم لا يغنون عن ممارسات الهندسة الجيدة

00:11:41.640 --> 00:11:44.160
يجب أن تظلت عمل مراجعات الكود وعمليات التكامل المستمر

00:11:44.160 --> 00:11:46.280
سي كحراس بوابة لا يمكن التنازل عنهم

00:11:46.280 --> 00:11:48.720
داع ذكاء الاصطناعية يقلل الوقت الذي تقضيه في أعمال التحري

00:11:48.720 --> 00:11:51.400
لكن احتفظ بالفحوصات الآلية والمراجعة البشرية كشبكة أمان

00:11:51.400 --> 00:11:55.720
هذا التوازن يحل مشكلة الثقة ويضمن أن مكاسب السرعة لا تقود الاستقرار

00:11:55.720 --> 00:11:57.800
فرق السرعة ليس نظريا فحسب

00:11:57.800 --> 00:12:00.700
حيث قد تستهلك ملاحقة الأخطاء والتصحيح اليدوي نصف يوم

00:12:00.700 --> 00:12:03.380
يمكن للاقتراحات المناسقة اختصار ذلك إلى دقائق

00:12:03.380 --> 00:12:07.340
والوقت المسترد يتدفق ليعود إلى العمل الذي ترغب حقا في تكريس طاقتك له

00:12:07.340 --> 00:12:08.920
الميزات التي يلاحظها مستخدمك

00:12:08.920 --> 00:12:11.620
وقرارات الهندسة المعمارية التي تحسن قاعدة الكود الخاصة بك

00:12:11.620 --> 00:12:13.480
بدلا من إطفاء الحرائق وقت التشغيل

00:12:13.480 --> 00:12:15.220
يمكنك التصميم بثقة مسبقة

00:12:15.220 --> 00:12:18.420
لذا لا يجب أن تحدد حلقة تصحيح الأخطاء يومك بعد الآن

00:12:18.420 --> 00:12:20.680
مع وكيل يقترح تحديثات عبر الملفات

00:12:20.680 --> 00:12:23.800
تتحول من البحث العشوائي إلى إيقاع المراجعة والموافقة

00:12:23.800 --> 00:12:26.420
تتوقف عن الدوران في حلقات مفرغة حول الأخطاء

00:12:26.420 --> 00:12:30.120
وتبدأ في التعامل مع التصحيح كخطوة منظمة وشبه آلية في سير عملك

00:12:30.120 --> 00:12:33.320
هذا التحول يفرغ مساحة دهنية وساعات عمل لبناء الميزات

00:12:33.320 --> 00:12:34.680
وليس فقط إصلاح العيوب

00:12:34.680 --> 00:12:37.980
وبمجرد أن يصبح إصلاح الأخطاء أقل تركيزا على ملاحقة الأعراض

00:12:37.980 --> 00:12:39.620
يفتح ذلك الباب لشيء أكبر

00:12:39.620 --> 00:12:42.840
كيف يمكنك بدء ميزات كاملة بنفس الطريقة المنظمة

00:12:42.840 --> 00:12:46.320
تخيل لو أن نفس سير العمل الذي يقترح إصلاحات منسقة

00:12:46.320 --> 00:12:50.520
يمكنه أيضا أخذ مواصفات بلغة واضحة وتشكيل هيكل عمل حولها

00:12:50.520 --> 00:12:52.960
هنا تبدأ المرحلة التالية من التطوير

00:12:52.960 --> 00:12:55.940
التطوير القائم على المواصفات بدون أعباء إضافية

00:12:55.940 --> 00:13:00.280
أحد أكثر التحولات إثارة للاهتمام يأتي عندما تتوقف عن التفكير فقط من حيث الملفات والأساليب

00:13:00.280 --> 00:13:02.720
وتبدأ في صياغة العمل بلغة بسيطة بدلا من ذلك

00:13:02.720 --> 00:13:06.080
وهنا يأتي دور التطوير القائم على المواصفات بدون تعقيدات زائدة

00:13:06.080 --> 00:13:08.280
تخيل كتابة طلب ميزة بسيط

00:13:08.280 --> 00:13:11.860
أضف سير عمل للتقارير ينشئ ملخصات شهرية ويخزنها

00:13:11.860 --> 00:13:14.240
ويجعلها متاحة من خلال صفحة إدارية

00:13:14.240 --> 00:13:16.940
بدلا من الخصول على بضع مقتطفات معزولة فقط

00:13:16.940 --> 00:13:19.840
تحصل على هيكل عمل تم تعيينه بالفعل عبر تطبيقك

00:13:19.840 --> 00:13:21.080
يتم إنشاء المتحكمات

00:13:21.080 --> 00:13:22.380
والنماذج

00:13:22.380 --> 00:13:23.820
وتسجيل الخدمات

00:13:23.820 --> 00:13:24.720
وربط الإعدادات

00:13:24.720 --> 00:13:28.220
هذا الانتقال من وصف القصد إلى رؤية هيكل ملموس يظهر في مشروعك

00:13:28.220 --> 00:13:31.860
هو المكان الذي يشعر فيه هذا النهج أخيرا بأنه عملي وليس نظريا

00:13:31.860 --> 00:13:33.040
في الإعدادات التقليدية

00:13:33.040 --> 00:13:35.820
يتمتع التطوير القائم على المواصفات بسمعة ثقيلة

00:13:35.820 --> 00:13:36.800
في المؤسسات الكبيرة

00:13:36.800 --> 00:13:38.860
يعني هذا عدتا مستندات متطلبات طويلة

00:13:38.860 --> 00:13:40.480
وأوراق تصميم متعددة صفحات

00:13:40.480 --> 00:13:42.120
ومخططة جامدة تبطئ الجميع

00:13:42.120 --> 00:13:44.960
إنها منطقية في الصناعات الخضعة للتنظيم أو الفرق الموزعة عالميا

00:13:44.960 --> 00:13:46.460
ولكن بالنسبة للبرمجة اليومية

00:13:46.460 --> 00:13:47.700
يتجاوزها معظم المطورين

00:13:47.700 --> 00:13:52.020
إن كتابة المواصفات التفصيلية والحفاظ عليها يضيف تكلفة لا يملك أحد الوقت أو الصبر لها

00:13:52.020 --> 00:13:54.080
إنه عمل إضافي فوق مهام تسليم الميزات

00:13:54.080 --> 00:13:55.600
ومع اقتراب الموعيد النهائية

00:13:55.600 --> 00:13:57.860
عادة ما يتم التضحية بهذه الجهود الإضافية

00:13:57.860 --> 00:13:58.900
المفارقة واضحة

00:13:58.900 --> 00:14:01.540
فالمطورون يحبون في الواقع التفكير في الخطوط العريضة

00:14:01.540 --> 00:14:03.900
معرفة الهيكل مسبقا يبعث على الطمأنينة

00:14:03.900 --> 00:14:05.120
المشكلة ليست في النية

00:14:05.120 --> 00:14:06.620
بل في المتابعة والصيانة

00:14:06.620 --> 00:14:09.400
بمجرد أن تبدأ المواصفات في فقدان التزامن مع الواقع

00:14:09.400 --> 00:14:10.700
تصبح صيانتها عبئا

00:14:10.700 --> 00:14:14.660
لهذا السبب يميل الكثير من العمل الواقعي نحو الارتجال بدلا من التصميم الكامل

00:14:14.660 --> 00:14:17.540
حتى في الشركات التي تؤيد تقنيا التخطيط المكثفة

00:14:17.540 --> 00:14:18.820
يوفر سير عمل الوكيل

00:14:18.820 --> 00:14:20.320
بديلا لذلك

00:14:20.320 --> 00:14:22.380
بدلا من المطالبة بوثيقة تصميم مسكولة

00:14:22.380 --> 00:14:26.360
يمكنه المساعدة في ترجمة مواصفات باللغة العادية إلى هيكل أساسي يمكنك تحسينه

00:14:26.360 --> 00:14:29.820
لا تحتاج إلى مخططات UML أو خرائط واجهات مكتوبة بخط اليد

00:14:29.820 --> 00:14:33.860
يمكنك ببساطة أن تطلب إنشاء وحدة تقارير مع نقطة نهاية APA جديدة

00:14:33.860 --> 00:14:34.960
وربطها بالتخزين

00:14:34.960 --> 00:14:37.020
وتأمينها بوصول يعتمد على الأدوار

00:14:37.020 --> 00:14:39.600
ليقوم النظام بتوليد أساس عبر الملفات في حل

00:14:39.600 --> 00:14:40.540
نيث الخاص بك

00:14:40.540 --> 00:14:41.420
في العرض التوضيحي

00:14:41.420 --> 00:14:43.520
سأقرأ مواصفات باللغة العادية بصوت عال

00:14:43.520 --> 00:14:45.520
ثم سأعرض الملفات التي أنتجها الوكيل

00:14:45.520 --> 00:14:47.680
من وحدات تحكم ونماذج وتسجيل خدمات

00:14:47.680 --> 00:14:50.660
وسأشير إلى النقاط التي لا تزال بحاجة إلى تحسين يدويا

00:14:50.660 --> 00:14:53.420
بهذه الطريقة يمكنك الحكم على الجودة بنفسك

00:14:53.420 --> 00:14:56.460
هذا يضع أرضية مشتركة بين أسلوب عمل للمطورين

00:14:56.460 --> 00:14:59.600
من جهة هناك البرمجة العفوية فيب كود سريعة وحرة الشكل

00:14:59.600 --> 00:15:01.320
لكنها هشة للأنظمة طويلة الأمد

00:15:01.320 --> 00:15:04.480
ومن جهة أخرى هناك التصميم المعتمد على المواصفات موثوق

00:15:04.480 --> 00:15:06.020
لكنه بطيء بشكل مؤلم

00:15:06.020 --> 00:15:08.700
مع دعم الوكيل توضح فكرتك بكلمات طبيعية

00:15:08.700 --> 00:15:10.060
فيظهر الهيكل الأساسي

00:15:10.060 --> 00:15:12.480
ويمكنك التكرار بسرعة تقارب البرمجة العفوية

00:15:12.480 --> 00:15:14.100
مع الحفاظ على ميزة الهيكل المنظم

00:15:14.100 --> 00:15:16.440
لنأخذ سير عمل التقارير مرة أخرى

00:15:16.440 --> 00:15:18.320
عادة يتعين عليك إنشاء النموذج

00:15:18.320 --> 00:15:19.560
وبناء خدمة البيانات

00:15:19.560 --> 00:15:21.740
وتوصيل وحدة التحكم وتكوين الأمان

00:15:21.740 --> 00:15:23.400
وربط كل شيء في ملف البدء

00:15:23.400 --> 00:15:25.440
وهذا يعني التنقل بين ملفات متعددة

00:15:25.440 --> 00:15:26.840
والأمل في الحفاظ على الاتساق

00:15:26.840 --> 00:15:30.060
مع هذا النهج يضع الهيكل الأساسي في مكانه دفعة واحدة

00:15:30.060 --> 00:15:32.400
التوفير الحقيقي لا يأتي من كتابة عدد أقل من الأسطر

00:15:32.400 --> 00:15:34.060
بل من تجنب أخطاء الملفات المتداخلة

00:15:34.060 --> 00:15:36.740
مثل نسيان تسجيل خدمة جديدة بعد أن قمت ببنائها بالفعل

00:15:36.740 --> 00:15:39.060
بالطبع هناك دائما تساؤل حول الأسلوب

00:15:39.060 --> 00:15:42.320
هل سيفرض الذكاء الاصطناعي قوالب جاهزة أو يتجاهل الاتفاقيات المتبعة

00:15:42.320 --> 00:15:46.300
من الناحية العملية غالبا ما تعكس الوكلاء أن ماط المشروع الحالية في اقتراحاتهم

00:15:46.300 --> 00:15:48.580
في العرض التوضيحي سترى كلا الجانبين

00:15:48.580 --> 00:15:51.620
مواضع تطابق فيها هيكل وحدة التحكم الخاصة بنا تماما

00:15:51.620 --> 00:15:54.180
ومواضع أخرى تعدد فيها تخميناته عن المساري

00:15:54.180 --> 00:15:55.180
هذا المزيج مهم

00:15:55.180 --> 00:15:58.300
ستعرف ما يمكنك الوثوق به وما لا تزال بحاجة إلى تعديله

00:15:58.300 --> 00:16:00.520
النتيجة النهائية ليست كودا نمطيا مكررا

00:16:00.520 --> 00:16:04.220
لا يزال المشروع يبدو كأنه مشروعك الخاص فقط بجهد أقل في أعداد الهيكل اليدوي

00:16:04.220 --> 00:16:08.940
يمكنك الحفاظ على السرعة مع الاستناد إلى أساس قابل للتطوير من أجل النمو المستقبلي

00:16:08.940 --> 00:16:13.680
بدلا من أن يقتصر العمل على المواصفات على المهندسين الذين يتحلون بالصبر لرسم المخططات

00:16:13.680 --> 00:16:17.460
يصبح أداة لأي مطور يريد التجربة بسرعة دون التضحية بالنظام

00:16:17.460 --> 00:16:19.980
وعندما يصبح هذا جزءا من تدفق عملك اليومي

00:16:19.980 --> 00:16:24.960
تتوقف المواصفات عن كونها خطوة رسمية معقدة وتصبح أقرب إلى أسلوب مختصر وخفيفا

00:16:24.960 --> 00:16:27.340
أنت تصف نيتك والنظام يضع الأساس

00:16:27.340 --> 00:16:29.460
وأنت تركز على تشكيل التفاصيل

00:16:29.460 --> 00:16:32.340
التأثير الأكبر لا يأتي فقط من الكود الذي تنشئه

00:16:32.340 --> 00:16:34.940
بل مما تعنيه وفرة الوقت أسبوعا بعد أسبوع

00:16:34.940 --> 00:16:38.000
ساعات أكثر للميزات وجهد أقل في الإعداد

00:16:38.000 --> 00:16:41.980
هذا يقودنا مباشرة إلى السؤال الذي يهتم به كل مطور أكثر من غيره

00:16:41.980 --> 00:16:45.500
ما الذي تضيفه هذه التغييرات فعليا من حيث الإنتاجية

00:16:45.500 --> 00:16:46.860
عائد الإنتاجية

00:16:46.860 --> 00:16:50.440
السؤال الحقيقي ليس ما إذا كنت ستوفر بضع دقائق هنا وهناك

00:16:50.440 --> 00:16:54.640
بل كيف تتراكم تلك التحولات الصغيرة لتصبح ساعات ذات قيمة طوال الأسبوع

00:16:54.640 --> 00:16:56.420
هذا هو عائد الإنتاجية

00:16:56.420 --> 00:16:59.620
استعادة الوقت الذي يضيع عادة دون ملاحظة بسبب تبديل السياق

00:16:59.620 --> 00:17:02.040
ودورات البناء المتكررة والتصحيحات اليدوية

00:17:02.040 --> 00:17:05.500
معظم المطورين يتقبلون تلك الخسائر الصغيرة كجزء طبيع من العمل

00:17:05.500 --> 00:17:07.320
عشر دقائق هنا للبحث عن قيمة إعداد

00:17:07.320 --> 00:17:09.920
وخمسة عشر دقيقة أخرى لإعادة التشغيل بعد مرجع مفقود

00:17:09.920 --> 00:17:11.920
أو التنقل بين الملفات للتحقق من الروابط

00:17:11.920 --> 00:17:14.040
بحد ذاتها تبدو هذه الأمور بسيطة

00:17:14.040 --> 00:17:15.840
ولكن عند جمعها خلال دورة عمل كاملة

00:17:15.840 --> 00:17:18.640
فهي تحدد حجم القيمة الفعلية التي يتم تسليمها

00:17:18.640 --> 00:17:22.140
ما يبدو كحركة روتينية يخفي عقا حقيقيا أمام جداول التسليم

00:17:22.140 --> 00:17:25.080
العبء الخفي ليس في أوقات التجميع أو سرعة الكتابة

00:17:25.080 --> 00:17:27.800
بل في إيقاع التوقف والبدء الذي يفرض على تركيزك

00:17:27.800 --> 00:17:29.660
في كل مرة تنتقل فيها من ملف إلى آخر

00:17:29.660 --> 00:17:30.960
يقوم عقلك بإعادة الضبط

00:17:30.960 --> 00:17:32.740
إعادة الضبط تلك لها تكلفة

00:17:32.740 --> 00:17:36.100
إسناد التصحيحات المتكررة إلى وكيل ذكي يخفف من ذلك العبء

00:17:36.100 --> 00:17:38.160
بدلا من إعادة بناء السياق باستمرار

00:17:38.160 --> 00:17:42.000
يمكنك توجيه تركيزك حيث يهم لحل مشكلة التصميم الكبرى

00:17:42.000 --> 00:17:44.380
لا تتتبع العديد من الفرق هذه التكاليف الدقيقة

00:17:44.380 --> 00:17:48.700
العمل الذي لا يؤدي إلى نتيجة لا يتم تسجيله

00:17:48.700 --> 00:17:50.240
لكنه يستهلك الطاقة رغم ذلك

00:17:50.240 --> 00:17:53.800
ومع توسع قواعد الكودي لا يزداد هذا الاحتكاك بشكل خطي فحسبه

00:17:53.800 --> 00:17:56.820
المزيد من الطبقات يعني المزيد من التبعيات التي يجب الاحتفاظ بها في الذاكرة

00:17:56.820 --> 00:17:59.820
والمزيد من الفرص لضيع الوقت في مجرد موامة الهيكل قبل المضي قدما

00:17:59.820 --> 00:18:03.180
سير عمل الوكلاء يغير هذه المعادلة من خلال استهداف هذه الهدر مباشرة

00:18:03.180 --> 00:18:05.840
إنهم لا يقومون فقط بملئ هياكل الدوال بشكل أسرع

00:18:05.840 --> 00:18:09.720
بل يقللون من حلقات البحث والتصحيح وإعادة التشغيل التي تلتهم فترات بعد الظهيرة

00:18:09.720 --> 00:18:14.140
تشير الفرق التي تستخدم سير عمل الوكلاء إلى تقليل وقت فك الحضر في كثير من الحالات

00:18:14.140 --> 00:18:18.540
في هذا الفيديو سنعرض مهمة قبل وبعد حتى تتمكن من الحكم على التأثير

00:18:18.540 --> 00:18:21.720
سأسجل الوقت المستغرق لتنفيذ نفس ميزة أشر يدويا

00:18:21.720 --> 00:18:25.540
ثم مرة أخرى باستخدام الوكيل حتى ترى مكاسب الانتاجية بشكل ملموس

00:18:25.540 --> 00:18:29.040
من منظور تجاري تظهر القيمة في سرعة إنجاز المشروع

00:18:29.040 --> 00:18:31.740
دورات العمل الأسرع لا تتعلق فقط برضى المطورين

00:18:31.740 --> 00:18:35.380
فهي تحدد ما إذا كانت الميزات ستصدر في هذا الإصدار أو ستتأخر لأرباع سنوية قادمة

00:18:35.380 --> 00:18:36.900
كما أنها تؤثر على الدين التقنيي

00:18:36.900 --> 00:18:39.800
حيث يقل الاعتماد على الخلول المؤقتة والترجعات البرمجية في قائمة المهم

00:18:39.800 --> 00:18:44.940
يتيح سير العمل الأكثر سلاسة للفرق المضية قدما بوضوح بدلا من إعادة معالجة عمل تلف من سبرينت سابق

00:18:44.940 --> 00:18:48.820
هذا الاتساق يتراكم ليقلل من العمل تحت الضغط ويحقق نتائج أقوى بمرور الوقت

00:18:48.820 --> 00:18:50.440
هناك أيضا العامل البشري

00:18:50.440 --> 00:18:53.540
يوم ضائع في مطاردة الأخطاء يترك أي مهندس منحكنا

00:18:53.540 --> 00:18:57.800
بمجرد شعورك بالتعب يصبح التصميم النظيف أصعب وتفوتك التفاصيل وتتسلل الأخطاء

00:18:57.800 --> 00:19:00.480
من خلال نقل الإصلاحات الآلية إلى وكيل ذكاء إصطناعيا

00:19:00.480 --> 00:19:02.620
يبقى المطورون في حالة تركيز لفترات أطولة

00:19:02.620 --> 00:19:05.820
هذا التركيز الإضافي يعزز كلا من الإنتاجية والجودة

00:19:05.820 --> 00:19:08.020
عندما لا تكون مثقلا باحتكاك العمل المتكرر

00:19:08.020 --> 00:19:11.040
تكون حرا في التفكير بشكل أوسع والتخطيط بفعالية أكبر

00:19:11.040 --> 00:19:13.140
الفرق في الممارسة يبدو هكذا

00:19:13.140 --> 00:19:18.640
دالة أشر جديدة مع روابط متعددة وتكامل خدمات قد تستغرق يومين كاملين دون مساعدة

00:19:18.640 --> 00:19:22.440
بين الإعداد والاختبار والرجوع عن المراجع غير المتطابقة

00:19:22.440 --> 00:19:25.400
تطول المهمة مع مساعدة الوكيل

00:19:25.400 --> 00:19:27.340
يمكن إنجاز نفس الدالة في نصف يوم

00:19:27.340 --> 00:19:28.860
ليس لأننا اختصرنا الطريقة

00:19:28.860 --> 00:19:32.520
بل لأن الإعداد والتنسيق بين الملفات يتم بشكل صحيح من المرة الأولى

00:19:32.520 --> 00:19:35.940
يتقلص الجدول الزمني بإزالة البدايات الخاطئة والجهد المتكرر

00:19:35.940 --> 00:19:38.180
يطرح بعض المطورين مخاوف مشروعة

00:19:38.180 --> 00:19:41.800
هل الاعتماد على الذكاء الاصطناعي في الصيانة يضعف مهاراتك الخاصة؟

00:19:41.800 --> 00:19:44.320
هذا المنظور غالبا ما يغفل ما يتغير حقا

00:19:44.320 --> 00:19:46.600
إسناد الإعداد المتكرر لا يضعف خبرتك

00:19:46.600 --> 00:19:50.000
بل يحفظها للتصميم والهندسة حيث يصنع حكمك الفارقة

00:19:50.000 --> 00:19:53.060
في الواقع أن تكسب مساحة لممارسة حل المشكلات المعقدة

00:19:53.060 --> 00:19:55.100
بدلا من إهدار الطاقة على التصحيحات الروتينية

00:19:55.100 --> 00:19:58.920
إذا جربت هذا شاركنا في التعليقات بعدد الساعات التي استعدتها في دورة العمل سبريم

00:19:58.920 --> 00:20:01.420
سأعرض الردود المثيرة للاهتمام في الفيديوهات القادمة

00:20:01.420 --> 00:20:05.300
سماع كيف تختبر الفرق الأخرى هذا التحول يعطي الجميع صورة أوضح للقيمة الحقيقية

00:20:05.300 --> 00:20:06.960
بعيدا عن العروض التوضيحية والأمثلة

00:20:06.960 --> 00:20:08.040
ملاحظة تحذيرية

00:20:08.040 --> 00:20:10.580
الأتمتة تساعد لكن الأمان يظل مهما

00:20:10.580 --> 00:20:14.580
قم دائما بتشغيل اختباراتك واستخدم مراجعة الكود للتحقق من التغييرات التي ينشئها الوكيل

00:20:14.580 --> 00:20:18.360
ثق بأن العمل الروتيني سينخفض ولكن حافظ على نفس معايير الأمان في مكانها

00:20:18.360 --> 00:20:21.300
فرق السرعة لا يؤتي ثماره إلا إذا ظلت الجودة ثابتة

00:20:21.300 --> 00:20:23.280
الاختبارات القوية ومراجعة طلبات السحب

00:20:23.280 --> 00:20:26.140
الذكية تحمي خط إصدار البرمجيات من الأتمتة الهشة

00:20:26.140 --> 00:20:28.920
الفائدة لا تتعلق بكتابة سطور من الكود بسرعة

00:20:28.920 --> 00:20:31.380
بل بتوفير مساحة لإنتاج حلول أقوى

00:20:31.380 --> 00:20:33.200
مع تعب أقل وقليل منه