00:00:00(موسيقى مبهجة)
00:00:02- مرحبًا بالجميع، كيف حالكم؟
00:00:23الأمر حماسي، أنا ديكس.
00:00:25كما ذُكر في تلك المقدمة الرائعة،
00:00:27لقد كنت أعمل على تطوير الوكلاء الذكيين لفترة من الوقت.
00:00:29حديثنا بعنوان "الوكلاء ذوو الـ 12 عاملاً" في مؤتمر مهندسي الذكاء الاصطناعي في يونيو
00:00:32كان واحداً من أفضل العروض التقديمية على الإطلاق.
00:00:34أعتقد أنه كان ضمن أفضل ثمانية عروض،
00:00:35أحد أفضل العروض في مؤتمر يونيو.
00:00:38ربما أكون قد ذكرت شيئاً حينها عن "هندسة السياق".
00:00:41لماذا أنا هنا اليوم، وعن ماذا سأتحدث؟
00:00:44أريد التحدث عن أحد عروضي المفضلة
00:00:46من مؤتمر مهندسي الذكاء الاصطناعي في يونيو،
00:00:47وأعلم أننا جميعاً تلقينا التحديث من إيغور بالأمس،
00:00:49لكنهم لم يسمحوا لي بتغيير شرائح العرض الخاصة بي،
00:00:50لذا سأركز على ما تحدث عنه إيغور في يونيو.
00:00:54باختصار، لقد أجروا استطلاعاً شمل 100,000 مطور
00:00:56من مختلف أحجام الشركات،
00:00:58ووجدوا أن معظم الوقت
00:01:00الذي تستخدم فيه الذكاء الاصطناعي في هندسة البرمجيات،
00:01:01ينتهي بك الأمر بالكثير من إعادة العمل والتخبط في الكود.
00:01:04وهو لا يعمل بشكل جيد حقاً في المهام المعقدة،
00:01:07أو في قواعد البيانات القديمة والمهملة.
00:01:08ويمكنكم رؤية ذلك في المخطط البياني؛ ففي الأساس،
00:01:10أنت تنجز وترسل كمية أكبر من البرمجيات،
00:01:11لكن جزءاً كبيراً منها هو مجرد إعادة إصلاح للنتائج السيئة
00:01:14التي أرسلتها في الأسبوع الماضي.
00:01:15ومن جانب آخر،
00:01:18إذا كنت تبدأ مشروعاً جديداً تماماً، كلوحة تحكم بسيطة في Vercel،
00:01:21أو شيئاً من هذا القبيل، فسيعمل الأمر بشكل رائع.
00:01:25لكن إذا كنت ستعمل على قاعدة بيانات Java عمرها 10 سنوات،
00:01:28فربما لن يكون الأمر كذلك.
00:01:29وهذا يطابق تجربتي الشخصية.
00:01:30من خلال ملاحظاتي ومن خلال الحديث مع الكثير من المؤسسين
00:01:32والمهندسين البارعين؛ هناك الكثير من النتائج الرديئة،
00:01:35ومصانع للديون التقنية، ولن ينجح الأمر مع قواعد بياناتنا.
00:01:37ربما ينجح يوماً ما عندما تتحسن النماذج.
00:01:40لكن هذا هو جوهر "هندسة السياق".
00:01:42كيف يمكننا استخراج أقصى استفادة من نماذج اليوم؟
00:01:44كيف ندير نافذة السياق الخاصة بنا؟
00:01:46لقد تحدثنا عن هذا في أغسطس.
00:01:48يجب أن أعترف بشيء ما.
00:01:49في المرة الأولى التي استخدمت فيها Cloud Code، لم أنبهر.
00:01:53قلت في نفسي: حسناً، إنه أفضل قليلاً،
00:01:54أفهم الفكرة، وأعجبتني تجربة المستخدم.
00:01:56لكن منذ ذلك الحين، اكتشفنا كفريق شيئاً ما
00:01:59مكننا بالفعل من تحقيق
00:02:01إنتاجية أعلى بمرتين إلى ثلاث مرات.
00:02:02وكنا ننجز الكثير لدرجة أنه لم يكن أمامنا خيار
00:02:06سوى تغيير طريقة تعاوننا.
00:02:07أعدنا صياغة كل شيء يتعلق بكيفية بناء البرمجيات.
00:02:11كنا فريقاً من ثلاثة أفراد، واستغرق الأمر ثمانية أسابيع،
00:02:12وكان الأمر صعباً للغاية حقاً.
00:02:14لكن الآن بعد أن حللنا المشكلة، لن نعود للوراء أبداً.
00:02:16هذا يتعلق بمبدأ "لا للنتائج الرديئة".
00:02:18أعتقد أننا حققنا تقدماً في هذا الصدد.
00:02:20لقد انتشر الأمر بشكل كبير على Hacker News في سبتمبر.
00:02:23ولدينا آلاف الأشخاص الذين دخلوا على GitHub
00:02:25واستخدموا نظامنا الخاص بـ "البحث والتخطيط والتنفيذ".
00:02:28الأهداف هنا، والتي توصلنا إليها تدريجياً، هي:
00:02:31نحتاج إلى ذكاء اصطناعي يعمل جيداً في قواعد البيانات القديمة.
00:02:35ويمكنه حل المشكلات المعقدة.
00:02:38بدون نتائج رديئة، تماماً، لا مزيد من العشوائية.
00:02:40وكان علينا الحفاظ على التوافق الذهني.
00:02:42سأتحدث أكثر قليلاً عما
00:02:43يعنيه ذلك بعد دقيقة.
00:02:44وبالطبع، كما هو الحال في كل شيء،
00:02:46نريد استهلاك أكبر قدر ممكن من الرموز (tokens).
00:02:47ما يمكننا إسناده بشكل فعال للذكاء الاصطناعي
00:02:50هو أمر مهم للغاية.
00:02:52إنه وسيلة قوية جداً لزيادة الإنتاجية.
00:02:53هذه هي هندسة السياق المتقدمة لوكلاء البرمجة.
00:02:56سأبدأ بوضع إطار لهذا الأمر.
00:02:58أكثر الطرق سذاجة لاستخدام وكيل البرمجة
00:03:01هي أن تطلب منه شيئاً، ثم تخبره لماذا هو مخطئ،
00:03:03وتعيد توجيهه وتكرر الطلب مراراً وتكراراً
00:03:05حتى ينفد السياق أو تستسلم أو تنفجر باكياً.
00:03:09يمكننا أن نكون أكثر ذكاءً قليلاً من ذلك.
00:03:11معظم الناس يكتشفون هذا في مرحلة مبكرة
00:03:13من استكشافهم للذكاء الاصطناعي، وهو أنه قد يكون من الأفضل
00:03:17إذا بدأت محادثة ووجدت نفسك تبتعد عن المسار الصحيح
00:03:21أن تفتح ببساطة نافذة سياق جديدة.
00:03:24تقول: حسناً، لقد سلكنا ذلك الطريق.
00:03:25لنبدأ من جديد.
00:03:26نفس الأمر، نفس المهمة.
00:03:27لكن هذه المرة، سنسلك هذا المسار المختلف.
00:03:29ولا تذهب إلى هناك لأن ذلك لا ينجح.
00:03:31إذاً، كيف تعرف متى يحين وقت البدء من جديد؟
00:03:34إذا رأيت هذا،
00:03:37(ضحك الجمهور)
00:03:39فمن المحتمل أن الوقت قد حان للبدء من جديد، أليس كذلك؟
00:03:41هذا ما يقوله نموذج Claude عندما تخبره بأنه يرتكب أخطاء فادحة.
00:03:45يمكننا أن نكون أكثر ذكاءً حتى من هذا.
00:03:47يمكننا القيام بما أسميه "الضغط المتعمد".
00:03:50وهذا يعني ببساطة، سواء كنت على المسار الصحيح أم لا،
00:03:53يمكنك أخذ نافذة السياق الحالية
00:03:56وتطلب من الوكيل ضغطها في ملف Markdown.
00:03:59يمكنك مراجعة هذا الملف وتمييزه.
00:04:00وعندما يبدأ الوكيل الجديد،
00:04:02فإنه يبدأ العمل مباشرة بدلاً من الاضطرار
00:04:04للقيام بكل عمليات البحث وفهم قاعدة الكود
00:04:05ومحاولة استيعاب ما فاته.
00:04:07ما الذي يتضمنه هذا الضغط؟
00:04:09السؤال هو: ما الذي يستهلك المساحة
00:04:11في نافذة السياق الخاصة بك؟
00:04:13إنه البحث عن الملفات، وفهم تدفق الكود،
00:04:17وتعديل الملفات، ومخرجات الاختبار والبناء.
00:04:20وإذا كان لديك أحد تلك البروتوكولات التي ترمي بملفات JSON
00:04:22والكثير من المعرفات الفريدة في نافذة السياق،
00:04:25فأعانك الله.
00:04:26إذاً، ما الذي يجب علينا ضغطه؟
00:04:28سأخوض في التفاصيل لاحقاً،
00:04:30لكن هذا مثال على ضغط جيد جداً.
00:04:31هذا هو بالضبط ما نعمل عليه،
00:04:33الملفات المحددة وأرقام الأسطر
00:04:34التي تهم المشكلة التي نحاول حلها.
00:04:37لماذا نحن مهووسون جداً بالسياق؟
00:04:39لأن نماذج اللغة الكبيرة تعرضت للانتقاد على يوتيوب بسبب هذا.
00:04:42هي ليست دوالاً نقية لأنها غير محددة النتائج،
00:04:45لكنها عديمة الحالة (stateless).
00:04:46والطريقة الوحيدة للحصول على أداء أفضل من نموذج لغوي كبير
00:04:49هي إدخال رموز (tokens) أفضل
00:04:51وبالتالي تحصل على رموز مخرجة أفضل.
00:04:52وفي كل دورة من المحادثة،
00:04:53يقوم النموذج باختيار الأداة التالية
00:04:55أو يقوم أي وكيل برمجة باختيار الخطوة التالية.
00:04:56وقد تكون هناك مئات الخطوات الصحيحة
00:04:58ومئات الخطوات الخاطئة.
00:05:00لكن الشيء الوحيد الذي يؤثر على ما سيأتي لاحقاً
00:05:03هو ما تم ذكره في المحادثة حتى الآن.
00:05:05لذا سنقوم بتحسين نافذة السياق هذه
00:05:07من حيث الصحة، والشمولية، والحجم،
00:05:10وقليلاً من "المسار التجريبي".
00:05:11وموضوع المسار هذا مثير للاهتمام
00:05:12لأن الكثير من الناس يقولون:
00:05:13"لقد طلبت من الوكيل القيام بشيء ما
00:05:16وقام به بشكل خاطئ."
00:05:17"لذا قمت بتصحيحه ووبخته"
00:05:18"ثم أخطأ مرة أخرى."
00:05:20"فوبخته مجدداً."
00:05:21والآن ينظر النموذج اللغوي إلى هذه المحادثة
00:05:23ويقول: حسناً، لقد أخطأت
00:05:24والإنسان وبخني،
00:05:25ثم أخطأت مجدداً فوبخني.
00:05:26إذاً، الرمز الأكثر احتمالاً تالياً في هذه المحادثة
00:05:29هو أن أرتكب خطأ آخر
00:05:31ليتمكن الإنسان من توبيخي مرة أخرى.
00:05:33لذا كن حذراً بشأن المسار الذي تضعه للنموذج.
00:05:35إذا أردنا عكس هذا المفهوم،
00:05:36فأسوأ ما يمكن أن يكون لديك هو معلومات خاطئة،
00:05:39ثم معلومات ناقصة، ثم مجرد ضجيج زائد.
00:05:42إذا كنتم تحبون المعادلات، فهناك معادلة بسيطة
00:05:44إذا أردتم التفكير في الأمر بهذه الطريقة.
00:05:47جيف هانتلي أجرى الكثير من الأبحاث حول وكلاء البرمجة.
00:05:51وقد لخص الأمر بشكل جيد جداً.
00:05:51كلما زاد استهلاكك لنافذة السياق،
00:05:53كلما حصلت على نتائج أسوأ.
00:05:55وهذا يقودنا إلى مفهوم،
00:05:56وهو مفهوم أكاديمي جداً يسمى "منطقة الغباء".
00:05:59لديك نافذة السياق الخاصة بك.
00:06:01لديك حوالي 168,000 رمز تقريباً.
00:06:03بعضها محجوز للمخرجات ولعملية الضغط.
00:06:05هذا يختلف حسب النموذج،
00:06:07لكننا سنستخدم Cloud Code كمثال هنا.
00:06:09عند خط الـ 40% تبدأ
00:06:10في رؤية تراجع في النتائج اعتماداً على مهمتك.
00:06:14إذا كان لديك الكثير من البروتوكولات الإضافية في وكلاء البرمجة،
00:06:17فأنت تقوم بكل عملك في "منطقة الغباء"
00:06:18ولن تحصل أبداً على نتائج جيدة.
00:06:21تحدث الناس عن هذا.
00:06:21لن أتطرق إلى هذه النقطة.
00:06:22قد تختلف النتائج من شخص لآخر.
00:06:23نسبة 40% تعتمد على مدى تعقيد المهمة،
00:06:26لكنها تعتبر مؤشراً جيداً.
00:06:28بالعودة إلى الضغط، أو كما سأسميه من الآن فصاعداً،
00:06:31تجنب "منطقة الغباء" بذكاء.
00:06:33يمكننا استخدام الوكلاء الفرعيين.
00:06:37إذا كان لديك وكيل فرعي للواجهة الأمامية وآخر للخلفية
00:06:39ووكيل للجودة وآخر لعلوم البيانات، فأرجوك توقف.
00:06:44الوكلاء الفرعيون ليسوا لتجسيد الأدوار البشرية.
00:06:47بل هم للتحكم في السياق.
00:06:49وما يمكنك فعله هو إذا كنت تريد معرفة
00:06:51كيفية عمل شيء ما في قاعدة كود ضخمة،
00:06:53يمكنك توجيه وكيل البرمجة للقيام بذلك
00:06:55إذا كان يدعم الوكلاء الفرعيين،
00:06:56أو يمكنك بناء نظام الوكلاء الفرعيين الخاص بك،
00:06:58وتقول له ببساطة: اذهب واكتشف كيف يعمل هذا.
00:07:00ويمكنه فتح نافذة سياق جديدة
00:07:03ستتولى هي كل عمليات القراءة والبحث
00:07:05والعثور على الملفات وقراءتها بالكامل
00:07:07وفهم قاعدة الكود،
00:07:09ثم تعود برسالة مختصرة جداً
00:07:13إلى الوكيل الأب، تقول فيها:
00:07:14"الملف الذي تريده موجود هنا".
00:07:17حينها يمكن للوكيل الأب قراءة ذلك الملف والبدء في العمل فوراً.
00:07:20وهذا أمر قوي جداً.
00:07:22إذا استخدمت هذه الأدوات بشكل صحيح،
00:07:23يمكنك الحصول على استجابات جيدة كهذه،
00:07:25ويمكنك إدارة السياق الخاص بك بشكل ممتاز.
00:07:29ما يعمل بشكل أفضل من الوكلاء الفرعيين
00:07:30أو طبقة فوق الوكلاء الفرعيين
00:07:32هي سير عمل أسميه "التكثيف المقصود والمتكرر".
00:07:35سنتحدث عن (البحث، التخطيط، التنفيذ) بعد قليل،
00:07:37لكن الفكرة هي أنك تقوم باستمرار
00:07:39بإبقاء نافذة السياق الخاصة بك صغيرة.
00:07:41أنت تبني سير عملك بالكامل حول إدارة السياق
00:07:45وهي تأتي في ثلاث مراحل: البحث، التخطيط، التنفيذ،
00:07:48وسنحاول البقاء في "منطقة الذكاء" طوال الوقت.
00:07:51فالبحث يتمحور حول فهم
00:07:53آلية عمل النظام، وإيجاد الملف الصحيح،
00:07:55والبقاء موضوعياً.
00:07:56إليك مطالبة يمكنك استخدامها لإجراء البحث.
00:07:58وهنا مخرجات مطالبة البحث.
00:08:00كل هذه الأدوات مفتوحة المصدر.
00:08:01يمكنكم الحصول عليها وتجربتها بأنفسكم.
00:08:04في التخطيط، ستحدد الخطوات الدقيقة.
00:08:06ستدرج أسماء الملفات ومقتطفات من الأسطر.
00:08:08ستكون صريحاً جداً بشأن كيفية اختبار الأشياء
00:08:10بعد كل تغيير.
00:08:11هذه مطالبة تخطيط جيدة.
00:08:12وهذا أحد مخططاتنا.
00:08:13إنه يحتوي على مقتطفات برمجية فعلية.
00:08:16وبعد ذلك سنقوم بالتنفيذ.
00:08:17وإذا قرأت إحدى هذه الخطط،
00:08:17يمكنك أن ترى بسهولة كيف أن أغبى نموذج في العالم
00:08:20لن يفسد الأمر على الأرجح.
00:08:23لذا نمضي قدماً وننفذ الخطة
00:08:24ونبقي السياق منخفضاً.
00:08:26أما بالنسبة لمطالبة التخطيط، كما قلت،
00:08:27فهي الجزء الأقل إثارة في العملية.
00:08:30أردت أن أضع هذا موضع التنفيذ.
00:08:31بينما كنا نعمل، أقدم بودكاست مع صديقي "فايبهاف"
00:08:34وهو الرئيس التنفيذي لشركة تدعى Boundary ML.
00:08:37وقلت له: "سأحاول إصلاح ثغرة بضغطة واحدة
00:08:39في قاعدة بيانات لغة البرمجة (Rust) الخاصة بك المكونة من 300 ألف سطر".
00:08:41والحلقة كاملة موجودة.
00:08:42مدتها حوالي ساعة ونصف.
00:08:45لن أتحدث عنها بالتفصيل الآن،
00:08:46لكننا قمنا بالكثير من الأبحاث
00:08:47ثم تخلصنا منها لأنها كانت سيئة.
00:08:48ثم وضعنا خطة بدون بحث،
00:08:49وخطة أخرى مع بحث، وقارنا جميع النتائج.
00:08:51لقد كان وقتاً ممتعاً.
00:08:53كان ذلك ليلة الاثنين.
00:08:54وبحلول صباح الثلاثاء، كنا في البرنامج
00:08:55وكان المدير التقني قد رأى طلب السحب (PR)
00:08:57ولم يدرك أنني كنت أفعل ذلك كمزحة من أجل البودكاست.
00:08:59وقال ببساطة: "نعم، هذا يبدو جيداً.
00:09:03سندمجه في الإصدار القادم".
00:09:04لقد كان مرتبكاً قليلاً.
00:09:05إليكم الخطة.
00:09:08على أي حال، نعم، تأكد الأمر.
00:09:09تعمل هذه الطريقة في قواعد البيانات القديمة وبدون أخطاء عشوائية.
00:09:12لكنني أردت معرفة ما إذا كان بإمكاننا حل مشكلات معقدة.
00:09:14كان "فايبهاف" لا يزال متشككاً بعض الشيء.
00:09:17لذا جلسنا لمدة سبع ساعات في يوم سبت
00:09:19وأرسلنا 35 ألف سطر من الكود إلى BAML.
00:09:21أحد طلبات السحب تم دمجه بعد أسبوع تقريباً.
00:09:24سأقول إن جزءاً من هذا كان توليداً آلياً للكود.
00:09:26تقوم بتحديث السلوك،
00:09:28فتتحدث جميع الملفات المرجعية وما إلى ذلك،
00:09:29لكننا شحنا الكثير من الكود في ذلك اليوم.
00:09:31وهو يقدر أننا أنجزنا عمل أسبوعين في سبع ساعات.
00:09:33وهذا رائع، يمكننا حل المشكلات المعقدة.
00:09:36لكن هناك حدود لهذا الأمر.
00:09:40جلست مع صديقي "بليك".
00:09:41وحاولنا إزالة تبعيات Hadoop من Parquet Java.
00:09:42إذا كنت تعرف ما هو Parquet Java،
00:09:46فأنا آسف لما حدث لك
00:09:47وأوصلك إلى هذه المرحلة في حياتك المهنية.
00:09:50الأمر لم يسر بشكل جيد.
00:09:53إليكم الخطط، وإليكم الأبحاث.
00:09:55عند نقطة معينة، رمينا كل شيء
00:09:57وعدنا فعلياً إلى السبورة البيضاء.
00:09:58كان علينا فعلياً، بمجرد أن عرفنا
00:10:00أماكن الأفخاخ الكامنة،
00:10:01أن نعود للتفكير: حسناً،
00:10:03كيف سيترابط هذا الأمر معاً؟
00:10:05وهذا يقودني إلى نقطة مثيرة للاهتمام حقاً
00:10:06سيتحدث عنها "جيك" لاحقاً.
00:10:09لا تستعينوا بمصادر خارجية للتفكير.
00:10:11الذكاء الاصطناعي لا يمكنه استبدال التفكير.
00:10:13يمكنه فقط تضخيم التفكير الذي قمت به
00:10:14أو تضخيم نقص التفكير الذي تعاني منه.
00:10:17لذا يسأل الناس: "يا ديكس،
00:10:19هذا تطوير مدفوع بالمواصفات، أليس كذلك؟"
00:10:21لا، التطوير المدفوع بالمواصفات معطل.
00:10:23ليس الفكرة، بل المصطلح نفسه.
00:10:27إنه غير محدد بشكل جيد.
00:10:30هذه "بريجيتا" من ThoughtWorks.
00:10:33والكثير من الناس يقولون "مواصفات"
00:10:35ويقصدون بها مجرد مطالبة أكثر تفصيلاً.
00:10:37هل يتذكر أحدكم هذه الصورة؟
00:10:39هل يعرف أحدكم من أين أتت؟
00:10:41حسناً، هذا مرجع قديم جداً.
00:10:43لن يكون هناك أبداً "عام للوكلاء"
00:10:44بسبب التشتت الدلالي.
00:10:46قال "مارتن فاولر" هذا في عام 2006.
00:10:47نحن نبتكر مصطلحاً جيداً بتعريف جيد،
00:10:49ثم يتحمس الجميع له،
00:10:52ويبدأ الجميع في إعطائه مئة معنى
00:10:53لمئة شخص مختلف، فيصبح بلا فائدة.
00:10:56كان لدينا الوكيل كشخص، والوكيل كخدمة مصغرة،
00:10:59والوكيل كبوت دردشة، والوكيل كسير عمل.
00:11:02وشكراً لك يا "سايمون".
00:11:05لقد عدنا إلى البداية.
00:11:06الوكيل هو مجرد أدوات في حلقة تكرارية.
00:11:07وهذا ما يحدث للتطوير المدفوع بالمواصفات.
00:11:09كنت أضع شريحة "شون" في بداية هذا العرض،
00:11:11لكنها جعلت الكثير من الناس
00:11:15يركزون على الأشياء الخاطئة.
00:11:15فكرته عن "نسيان الكود، فهو مثل لغة التجميع الآن"
00:11:17وأن تركز فقط على الـ (markdown).
00:11:19هي فكرة رائعة جداً، لكن الناس يقولون إن التطوير المدفوع بالمواصفات
00:11:21هو كتابة مطالبة أفضل، أو وثيقة متطلبات المنتج.
00:11:24أحياناً يكون استخدام حلقات تغذية راجعة قابلة للتحقق
00:11:26وضغط عكسي.
00:11:28ربما هو معاملة الكود مثل لغة التجميع،
00:11:30كما علمنا "شون".
00:11:32لكن بالنسبة لكثيرين، هو مجرد استخدام ملفات (markdown) كثيرة
00:11:34أثناء البرمجة.
00:11:36أو المفضل لدي، والذي اكتشفته الأسبوع الماضي فقط،
00:11:37المواصفات هي وثائق لمكتبة مفتوحة المصدر.
00:11:39لقد انتهى الأمر.
00:11:43التطوير المدفوع بالمواصفات مبالغ فيه وأصبح بلا فائدة الآن.
00:11:44لقد تشتت معناه دلالياً.
00:11:48لذا أردت التحدث عن أربعة أشياء
00:11:49تعمل بالفعل اليوم، الخطوات التكتيكية والعملية
00:11:52التي وجدناها ناجحة داخلياً ومع العديد من المستخدمين.
00:11:55نقوم بالبحث، ونكتشف كيف يعمل النظام.
00:11:59هل تتذكرون فيلم "Memento"؟
00:12:02هذا هو أفضل فيلم عن هندسة السياق،
00:12:03كما يقول "بيتر".
00:12:05هذا الرجل يستيقظ وليس لديه ذاكرة،
00:12:07وعليه قراءة وشومه ليعرف من هو
00:12:09وماذا يفعل.
00:12:11إذا لم تقم بتهيئة وكلائك، فسوف يألفون أشياءً من عندهم.
00:12:12هذا هو فريقكم، هذا تبسيط شديد
00:12:17لمعظمكم.
00:12:19فمعظمكم لديه مؤسسات أكبر بكثير من هذه.
00:12:19لكن لنفترض أنك تريد القيام ببعض العمل هنا.
00:12:21أحد الأشياء التي يمكنك فعلها هو وضع ملف تهيئة
00:12:23في كل مستودع برمجيات (repo).
00:12:26تضع فيه الكثير من السياق.
00:12:27هذا هو المستودع، وهذه آلية عمله.
00:12:28هذا ضغط لكل السياق الموجود في قاعدة الكود
00:12:29بحيث يمكن للوكيل رؤيته مسبقاً
00:12:32قبل البدء في العمل فعلياً.
00:12:34هذا يمثل تحدياً لأن الملف قد يصبح طويلاً جداً أحياناً.
00:12:36ومع تضخم قاعدة الكود الخاصة بك،
00:12:39سيتعين عليك إما جعل هذا الملف أطول
00:12:41أو استبعاد بعض المعلومات.
00:12:43لذا بينما تقرأ هذا،
00:12:45سوف تقرأ سياق
00:12:48هذا المستودع الضخم الذي يحتوي على 5 ملايين سطر
00:12:49وستستهلك كل "منطقة الذكاء"
00:12:52لمجرد تعلم كيف يعمل، ولن تكون قادراً
00:12:53على استدعاء أي أدوات بشكل جيد في "المنطقة الغبية".
00:12:55لذا، يمكنك تقسيم هذا عبر المستويات.
00:12:57يمكنك فعل ما يسمونه "الكشف التدريجي".
00:13:02يمكنك تقسيم هذا، صحيح؟
00:13:04يمكنك فقط وضع ملف في جذر كل مستودع
00:13:05ثم في كل مستوى يكون لديك سياق إضافي
00:13:08بناءً على ما إذا كنت تعمل هنا،
00:13:11فهذا هو ما تحتاج إلى معرفته.
00:13:13نحن لا نوثق الملفات نفسها
00:13:15لأنها هي مصدر الحقيقة.
00:13:17ولكن بينما يعمل وكيلك،
00:13:18فإنك تسحب السياق الرئيسي
00:13:19ثم تسحب السياق الفرعي.
00:13:21لن نتحدث عن أي أداة محددة،
00:13:22يمكنك استخدام CloudMD لهذا،
00:13:23أو استخدام Hoax، أياً كان.
00:13:24لكن سيظل لديك مساحة كبيرة في "منطقة الذكاء"
00:13:26لأنك تسحب فقط ما تحتاج لمعرفته.
00:13:28المشكلة في هذا هي أنه يصبح قديماً.
00:13:31لذا في كل مرة تشحن فيها ميزة جديدة،
00:13:33تحتاج لنوع من التحقق من ذاكرة التخزين المؤقت
00:13:35وإعادة بناء أجزاء كبيرة من هذه الوثائق الداخلية.
00:13:38ويمكنك استخدام الكثير من الذكاء الاصطناعي
00:13:42وجعله جزءاً من عمليتك لتحديث هذا.
00:13:43لماذا لا أسأل سؤالاً؟
00:13:46بين الكود الفعلي، وأسماء الدوال،
00:13:48والتعليقات والوثائق،
00:13:50هل يريد أحد تخمين ما يمثله المحور (y) في هذا المخطط؟
00:13:51أو ماذا يمثل؟
00:13:57- الهراء. - الهراء.
00:13:58إنه في الواقع كمية الأكاذيب التي يمكنك أن تجدها
00:14:01في أي جزء من قاعدة الكود الخاصة بك.
00:14:03لذا يمكنك جعل تحديث هذا جزءاً من عمليتك،
00:14:06لكنك على الأرجح لن تفعل ذلك.
00:14:08ما نفضله هو "السياق المضغوط عند الطلب".
00:14:11فإذا كنت أبني ميزة تتعلق بمزودي إدارة الكود (SCM)
00:14:14و JIRA و linear،
00:14:15سأعطي الوكيل القليل من التوجيه فقط.
00:14:17سأقول: مهلاً، نحن نتجه
00:14:18نحو هذا الجزء من قاعدة الكود هنا
00:14:21ومطالبة بحث جيدة أو أمر مباشر
00:14:24قد يستغل مهاراتك،
00:14:27ويطلق مجموعة من الوكلاء الفرعيين لأخذ هذه الشرائح الرأسية
00:14:30عبر قاعدة الكود ثم بناء مستند بحثي
00:14:33يمثل لقطة حقيقية لما هو موجود بالفعل،
00:14:35بناءً على الكود نفسه، للأجزاء المهمة في قاعدة الكود.
00:14:39نحن نقوم بضغط الحقائق.
00:14:41التخطيط هو وسيلة ضغط وقوة.
00:14:43التخطيط يدور حول تكثيف الأهداف.
00:14:45وفي الخطة، سنحدد الخطوات الدقيقة.
00:14:48لنأخذ بحثنا ووثيقة متطلبات المنتج أو تذكرة العطل
00:14:50أو أي شيء كان.
00:14:52نحن ننشئ خطة وننشئ ملفاً للخطة.
00:14:54لذا فنحن نقوم بالتكثيف مرة أخرى.
00:14:55وأريد أن أتوقف قليلاً لأتحدث عن التوافق الذهني.
00:14:58هل يعرف أحدكم ما الغرض من مراجعة الكود؟
00:15:00التوافق الذهني، التوافق الذهني.
00:15:05الأمر يتعلق بالتأكد من أن الأشياء صحيحة وما إلى ذلك.
00:15:08لكن الشيء الأهم هو كيف نحافظ على بقاء الجميع
00:15:10في الفريق على نفس النهج
00:15:11بشأن كيفية تغير قاعدة الكود ولماذا؟
00:15:14ويمكنني قراءة ألف سطر من لغة Golang كل أسبوع.
00:15:17عذراً، لا يمكنني قراءة ألف سطر.
00:15:18الأمر صعب، لكنني أستطيع فعله.
00:15:19لكنني لا أريد ذلك.
00:15:20ومع نمو فريقنا، تتم مراجعة كل الكود.
00:15:23نحن لا نترك الكود دون قراءة.
00:15:24لكنني، بصفتي قائداً تقنياً في الفريق،
00:15:27يمكنني قراءة الخطط والبقاء على اطلاع دائم.
00:15:29وهذا يكفي بالنسبة لي.
00:15:30يمكنني اكتشاف بعض المشكلات مبكراً
00:15:32وأحافظ على فهمي لكيفية تطور النظام.
00:15:35نشر ميتشل منشوراً جيداً حقاً
00:15:36حول كيفية وضعه لسلاسل AMP الخاصة به
00:15:38في طلبات السحب (PRs) الخاصة به لترى ليس فقط،
00:15:41هيا، إليك جدار من النص الأخضر على GitHub،
00:15:43بل إليك الخطوات الدقيقة، وإليك الأوامر،
00:15:44وأنني قمت بتشغيل البناء في النهاية ونجح الأمر.
00:15:46هذا يأخذ المراجع في رحلة
00:15:49بطريقة لا يمكن لطلب سحب GitHub القيام بها.
00:15:51وبينما تشحنون كميات أكبر
00:15:52بمقدار ضعفين إلى ثلاثة أضعاف من الكود،
00:15:54فإن المسؤولية تقع عليك لإيجاد طرق لإبقاء فريقك
00:15:57على نفس النهج وتوضح لهم الخطوات التي اتخذتها
00:16:00وكيف قمنا باختباره يدوياً.
00:16:01هدفك هو الاستفادة القصوى، لذا تريد ثقة عالية
00:16:04في أن النموذج سيقوم بالفعل بالشيء الصحيح.
00:16:06لا يمكنني قراءة هذه الخطة ومعرفة ما سيحدث
00:16:08بالفعل وما هي تغييرات الكود التي ستتم.
00:16:11لذا، مع مرور الوقت، قمنا بتطوير خططنا لتشمل
00:16:14مقتطفات كود فعلية لما سيتم تغييره.
00:16:17إذاً هدفك هو الاستفادة القصوى.
00:16:18أنت تريد تكثيفاً للأهداف
00:16:19وتريد تنفيذاً موثوقاً.
00:16:22ولا أعلم، فأنا خلفيتي في الفيزياء.
00:16:23نحن نحب رسم الخطوط عبر مراكز القمم والمنحنيات.
00:16:28كلما طالت خططك، زادت الموثوقية،
00:16:30وقلت سهولة القراءة.
00:16:31هناك نقطة مثالية لك ولفريقك
00:16:33ولقاعدة الكود الخاصة بك، يجب أن تحاول العثور عليها.
00:16:35لأننا عندما نراجع البحث والخطط،
00:16:37إذا كانت جيدة، فيمكننا تحقيق التوافق الذهني.
00:16:40لا تترك التفكير لجهة خارجية.
00:16:42لقد قلت هذا من قبل، هذا ليس سحراً.
00:16:44لا يوجد أمر (prompt) مثالي.
00:16:46لن ينجح الأمر إذا لم تقرأ الخطة.
00:16:50لذا بنينا عمليتنا بالكامل حولك أنت، المنفذ،
00:16:53في أخذ ورد مع العميل الآلي،
00:16:55تقرأ الخطط أثناء إنشائها.
00:16:56وبعد ذلك إذا كنت بحاجة لمراجعة الزملاء،
00:16:58يمكنك إرسالها لشخص ما وتقول،
00:16:58هيا، هل تبدو هذه الخطة صحيحة؟
00:17:00هل هذا هو النهج الصحيح؟
00:17:00هل هذا هو الترتيب الصحيح للنظر في هذه الأشياء؟
00:17:03مرة أخرى، كتب جيك تدوينة جيدة حقاً حول
00:17:05أن ما يجعل البحث والتخطيط والتنفيذ ذا قيمة
00:17:07هو وجودك أنت، الإنسان، في الحلقة للتأكد من صحة الأمر.
00:17:11لذا إذا خرجت بشيء واحد من هذا الحديث،
00:17:14فيجب أن يكون أن سطر الكود السيئ يبقى سطر كود سيئ.
00:17:17وجزء سيئ من الخطة قد يعني 100 سطر كود سيئ.
00:17:22وسطر بحث سيئ، مثل سوء فهم
00:17:25لكيفية عمل النظام ومكان وجود الأشياء،
00:17:27سيؤدي لفشل العملية برمتها.
00:17:29ستوجه النموذج في الاتجاه الخاطئ تماماً.
00:17:31لذا عندما نعمل داخلياً ومع المستخدمين،
00:17:34نحاول باستمرار نقل الجهد البشري والتركيز
00:17:36إلى الأجزاء الأكثر تأثيراً في مسار العمل هذا.
00:17:39لا تترك التفكير لجهة خارجية.
00:17:41احذر من الأدوات التي تخرج فقط
00:17:43مجموعة من ملفات markdown لمجرد شعورك بالرضا.
00:17:45لن أذكر أسماءً هنا.
00:17:47أحياناً يكون هذا مبالغاً فيه.
00:17:49والطريقة التي أحب التفكير بها في هذا هي،
00:17:51أنه نعم، لا تحتاج دائماً لعملية بحث وتخطيط وتنفيذ كاملة.
00:17:54أحياناً تحتاج أكثر، وأحياناً أقل.
00:17:56إذا كنت تغير لون زر ما،
00:17:57فقط تحدث مع العميل الآلي وأخبره بما يجب فعله.
00:18:00إذا كنت تضع خطة بسيطة لميزة صغيرة،
00:18:04أو إذا كنت تعمل على ميزات متوسطة عبر مستودعات متعددة،
00:18:07فعندها قم بإجراء بحث واحد، ثم ضع خطة.
00:18:09أساساً، أصعب مشكلة يمكنك حلها،
00:18:10يرتفع سقفها كلما زاد جهدك في هندسة السياق
00:18:13والتكثيف الذي ترغب في القيام به.
00:18:15لذا إذا كنت في الزاوية العلوية اليمنى،
00:18:18فمن المحتمل أن تضطر لبذل المزيد.
00:18:19يسألني الكثير من الناس، كيف أعرف
00:18:21مقدار هندسة السياق التي يجب استخدامها؟
00:18:23الأمر يتطلب ممارسة.
00:18:24ستخطئ، يجب أن تخطئ
00:18:26مراراً وتكراراً.
00:18:27أحياناً ستتوسع أكثر من اللازم، وأحياناً ستقصر.
00:18:29اختر أداة واحدة وتمرن عليها.
00:18:32أنا أنصح بعدم تشتيت الجهد بين Clod و Codex
00:18:35وكل هذه الأدوات المختلفة.
00:18:36لست من محبي الاختصارات.
00:18:40قلنا إن التطوير القائم على المواصفات قد انتهى.
00:18:42لا أعتقد أن البحث والتخطيط والتنفيذ ستكون هي الخطوات دائماً.
00:18:44الجزء المهم هو التكثيف وهندسة السياق
00:18:47والبقاء في منطقة الذكاء.
00:18:48لكن الناس يطلقون على هذا RPI
00:18:50وليس هناك ما يمكنني فعله حيال ذلك.
00:18:52لذا كن حذراً، لا يوجد أمر مثالي،
00:18:55ولا يوجد حل سحري.
00:18:56إذا كنت تريد حقاً مصطلحاً رناناً،
00:18:58يمكنك تسمية هذا "هندسة التسخير" (harness engineering)،
00:19:00وهي جزء من هندسة السياق
00:19:01وهي كيفية دمجك لنقاط التكامل
00:19:03في Codex أو Clod أو Cursor أو غيرها،
00:19:05وكيف تخصص قاعدة الكود الخاصة بك.
00:19:07ما التالي؟
00:19:11أعتقد أن موضوع عملاء البرمجة الآلية
00:19:12سيصبح في الواقع شيئاً عادياً ومتاحاً للجميع.
00:19:13سيتعلم الناس كيفية القيام بذلك وسيتحسنون فيه.
00:19:15والجزء الصعب سيكون في كيفية تكييف فريقك
00:19:17وسير عملك في دورة حياة تطوير البرمجيات للعمل في عالم
00:19:21يتم فيه شحن 99% من الكود الخاص بك بواسطة الذكاء الاصطناعي.
00:19:24وإذا لم تتمكن من فهم هذا، فأنت في مأزق.
00:19:26لأن هناك نوعاً من الفجوة المتزايدة
00:19:27حيث لا يتبنى المهندسون الأساسيون الذكاء الاصطناعي
00:19:29لأنه لا يجعلهم أسرع بكثير
00:19:31بينما يستخدمه المهندسون المبتدئون والمتوسطون بكثرة
00:19:33لأنه يسد الفجوات في مهاراتهم
00:19:35لكنه ينتج أيضاً بعض العمل الرديء
00:19:36مما يجعل كبار المهندسين يكرهونه أكثر فأكثر
00:19:38كل أسبوع لأنهم يقضون وقتهم في تنظيف الكود الرديء،
00:19:40الذي تم إنتاجه بواسطة Cursor في الأسبوع السابق.
00:19:42هذا ليس خطأ الذكاء الاصطناعي،
00:19:44وليس خطأ المهندس متوسط المستوى.
00:19:46التغيير الثقافي صعب حقاً
00:19:48ويجب أن يأتي من القيادة لينجح.
00:19:50لذا إذا كنت قائداً تقنياً في شركتك،
00:19:52اختر أداة واحدة وابدأ في الممارسة.
00:19:54إذا كنت ترغب في المساعدة، فنحن نوظف،
00:19:56نحن نبني بيئة تطوير (IDE) تعتمد على العملاء الآليين لمساعدة الفرق
00:19:59في تسريع الرحلة نحو كود من إنتاج الذكاء الاصطناعي بنسبة 99%.
00:20:03يسعدنا التحدث إليكم إذا كنتم ترغبون في العمل معنا.
00:20:06تفضلوا بزيارة موقعنا، أرسلوا لنا بريداً إلكترونياً،
00:20:08أو ابحثوا عني في الخارج.
00:20:09شكراً جزيلاً لكم جميعاً على طاقتكم.
00:20:11(تصفيق الجمهور)
00:20:13(موسيقى إلكترونية مبهجة)