Transcript
00:00:00تمت إعادة كتابة SQLite بلغة Rust.
00:00:02وأعلم أنه قد تم التو للتو من إعادة كتابة Bun بلغة Rust
00:00:04وقد تتساءل لماذا يقوم الجميع بإعادة كتابة
00:00:06كل شيء بلغة Rust، لكن الأمر لا يتعلق بلغة Rust.
00:00:09ولا يتعلق الأمر حتى بـ SQLite.
00:00:11أنا على علم بوجود قاعدة بيانات Turso،
00:00:15والتي هي بالفعل إعادة تطبيق محدثة
00:00:18لـ SQLite بلغة Rust.
00:00:19تلك هي التي تريد استخدامها
00:00:21إذا كنت ترغب في استخدام قاعدة بيانات
00:00:23SQLite قائمة على Rust وجاهزة للإنتاج.
00:00:26بدلاً من ذلك، هذه التجربة، mini SQLite،
00:00:29الموجود رابطها أدناه والتي يمكنك الاطلاع عليها،
00:00:32لا تتعلق بـ SQLite أو Rust.
00:00:34بل هي تجربة قام بها فريق Cursor،
00:00:37والتي تدور بالكامل حول أسراب الوكلاء وهندسة
00:00:40نظام من وكلاء الذكاء الاصطناعي واكتشاف ما ينجح
00:00:44وما لا ينجح لبناء شيء
00:00:47مثل SQLite انطلاقاً من وثائقها فقط،
00:00:51لأن هذا هو المغزى من هذه التجربة.
00:00:53هناك منشور مدونة مفصل للغاية ومثير جداً للاهتمام
00:00:56وسوف نتعمق فيه.
00:00:57هناك الكثير من الدروس المكتسبة الممتعة هناك والتي
00:00:59يتوجب علينا التحدث عنها، وتجدونها أيضاً في الرابط أدناه،
00:01:02حيث يشرحون كيفية إجرائهم لهذا الاختبار ونقطة البداية
00:01:07وكانت الفكرة الكامنة وراء تلك التجربة هي أخذ وثائق SQLite،
00:01:12والتي تبلغ في النهاية 835 صفحة لو وضعتها كلها في مستند واحد،
00:01:18وهي بالطبع مكتوبة في المقام الأول للبشر.
00:01:23أعني، ليست الوثائق الأسهل فهماً التي رأيتها في حياتي،
00:01:27ولكن بوضوح هي مخصصة للبشر لأنها أقدم بكثير من كل أدوات وكلاء الذكاء الاصطناعي.
00:01:32ومع ذلك، فهي تعمل نوعاً ما كمواصفات تفصيلية للغاية،
00:01:37مواصفات فائقة الدقة لأنها تشرح بالتفصيل كيفية استخدام SQLite
00:01:43وما هو السلوك المرجو أو ما هي الميزات المستهدفة.
00:01:48وأخذ فريق Cursor تلك الوثائق
00:01:52ثم أخذوا مجموعة اختبارات عامة، وهي SQLogic test،
00:01:57وهي عبارة عن مجموعة من الاختبارات التي تفحص سلوك SQLite
00:02:02أو تختبر الاستعلامات على وجه الخصوص.
00:02:05واستخدموا ذلك للتحقق مما إذا كان التطبيق
00:02:09الذي بناه وكلاؤهم بناءً على تلك الوثائق
00:02:13يعمل بالفعل مع حزمة الاختبارات الرسمية أو الضخمة تلك.
00:02:19والآن، بضع كلمات تحذيرية مهمة مسبقاً.
00:02:23حزمة الاختبارات هذه تدور كلها حول اختبار الاستعلامات وسلوك الاستعلام.
00:02:29فهي لا تختبر جميع الميزات وكل الإمكانيات التي تمتلكها SQLite.
00:02:35ولا تختبر الأداء بشكل عام.
00:02:38ولا تختبر التزامن.
00:02:40هناك الكثير من الأشياء في SQLite التي لا تختبرها هذه الحزمة.
00:02:44ومشروع mini SQLite هذا الناتج عن تلك التجربة، كإحدى النتائج،
00:02:49قد أعادوا بناء SQLite بالفعل عدة مرات بمجموعات مختلفة من الوكلاء.
00:02:53وسوف نتعمق في ذلك، فهو مجرد شيء للاستكشاف فقط.
00:02:57إنه ليس جاهزاً للإنتاج.
00:02:59وليس ما تريد استخدامه.
00:03:01إنه مجرد مخرجات تجربة كان الهدف منها استخدام التوثيق
00:03:06ثم إعادة بناء SQLite وجعل تلك النسخة المعاد بناؤها تجتاز كل تلك الاختبارات.
00:03:13واستخدم فريق Cursor مجموعات مختلفة من النماذج هنا.
00:03:17لماذا المجموعات؟
00:03:18لأنه كما سنتعلم، استخدموا نهجاً
00:03:21يعمل فيه وكلاء متعددون معاً، وكلاء التخطيط والتنفيذ والمراجعة.
00:03:28وقاموا بإعادة بناء قاعدة بيانات SQLite تلك بمجموعات مختلفة هنا وقاموا أيضاً بقياس الجودة المتشابهة.
00:03:37لذا حققت كل هذه المجموعات نفس الجودة، ونفس عدد الاختبارات الناجحة، لكنهم قاموا بقياس تكلفة كل مجموعة.
00:03:45على سبيل المثال، استخدام GPT 5.5 لكل شيء لوكلاء التخطيط ووكلاء التنفيذ أدى إلى تكلفة تطبيق لـ SQLite بلغة Rust استناداً إلى الوثائق تتراوح حول 10,000 دولار.
00:03:59من ناحية أخرى، الجمع بين Opus 4.8 و Composer 2.5 —و Composer 2.5 هو ذلك النموذج الفائق السرعة والرخيص جداً والفعال للغاية ولكنه ليس ذكياً جداً من Cursor— الجمع بين هذين الاثنين أدى إلى نفس نوع الجودة، ونفس عدد الاختبارات الناجحة مقارنة بتلك المجموعات الأخرى وبكسر بسيط فقط من التكلفة، بنحو 1,300 دولار فقط.
00:04:24وكانت الفكرة هنا هي استخدام Opus 4.8، وهو النموذج الأكثر قدرة بالطبع، للتخطيط وتصميم المهام، والتي يتم تسليمها بعد ذلك إلى وكلاء التنفيذ الذين يستخدمون Composer 2.5.
00:04:39وهذه بالفعل فائدة مهمة واحدة من المقال، وهي ليست جديدة تماماً بالطبع.
00:04:44يمكنك القيام بذلك بنفسك أيضاً إذا كنت تبني برمجيات.
00:04:47إنها فكرة جيدة أن تقسم عملك، اعتماداً على تعقيد العمل بالطبع، إلى مهام مختلفة يتم تنفيذها بواسطة وكلاء مختلفين، باستخدام وكلاء فرعيين إذا أردت، حيث يركز بعض الوكلاء على التخطيط،
00:05:03اعتماداً على تصميم مهمة مركزة من المهمة الإجمالية، كمهمة فردية إن صح التعبير، ثم وجود وكلاء منفذين لتطبيق تلك المهمة.
00:05:14لأنه يتضح أنه لإخراج كود جيد فقط، لا تحتاج بالضرورة إلى ذكاء من الطراز الأول إذا كان السياق جيداً.
00:05:24أي إذا كانت المهمة محددة بوضوح، وكانت جميع المعلومات المفيدة موجودة في وصف المهمة، وحينها بالطبع يمكن أن تؤثر عوامل أخرى أيضاً.
00:05:33على سبيل المثال، قد يهم شكل قاعدة البرمجيات المحيطة، وكيف تبدو الأمثلة التي تقدمها للوكيل.
00:05:39كل هذا يؤثر على المخرجات، لكن وكلاء التنفيذ الذين يكتبون الكود فقط يمكن أن يكونوا متعددين إذا كانت المهمة محددة جيداً والسياق جيداً.
00:05:49وهذا ما دارت حوله معظم التجربة.
00:05:52كيفية تصميم نظام يمكنه التعامل مع مهمة بهذا الحجم.
00:05:57لأنه بالطبع، كما ذكرت، بالنسبة لمشاريعك أيضاً، يجدر التفكير في الاعتماد على وكلاء تخطيط وتنفيذ.
00:06:07بالطبع ليس لكل المهام.
00:06:10إذا كان لديك إصلاح سريع لخطأ، أو مهمة بسيطة جداً، فمن الممكن تماماً أن تخبر وكيل البرمجة الخاص بك، سواء كان Codex أو Claude Code أو أي شيء آخر.
00:06:19مرحباً، لدي هذه المشكلة.
00:06:20أريدك أن تفعل هذا.
00:06:21أعطه بعض السياق الإضافي ودعه يقوم بعمله.
00:06:24وقد يقوم، بناءً على بيئة وكيل البرمجة، بإنشاء وكلاء فرعيين.
00:06:28ومع ذلك، قد يفعل Claude Code ذلك.
00:06:31قد لا تفعل أطر عمل أخرى مثل PI ذلك إذا لم تمنحها التوسعات المناسبة.
00:06:36ولكن حتى بدون وكلاء فرعيين، يمكن معالجة العديد من المهام بواسطة وكيل واحد فقط وستكون على ما يرام.
00:06:43ولكن بالنسبة للمشاريع الأكثر تعقيداً، والمهام الأكثر تعقيداً، يمكن أن يكون هذا التقسيم مفيداً، بما في ذلك وكلاء المراجعة.
00:06:51هذا شيء أحب شخصياً القيام به أيضاً.
00:06:54مرة أخرى، يعتمد ذلك على تعقيد المهمة.
00:06:56لكن وجود هذا التقسيم هو أمر يعمل بشكل جيد حقاً.
00:06:59وهذا بالطبع ليس بالشيء الجديد كلياً.
00:07:02الجديد هو أنه بالنسبة لشيء مثل إعادة كتابة SQLite هنا، لديك عمليات متوازية متعددة من وكلاء التخطيط والتنفيذ والمراجعة، وعمال متعددون، وأيضاً مخططون ومراجعون متعددون.
00:07:18وهم يتصادمون طوال الوقت.
00:07:19هذا ما اكتشفه فريق Cursor في النهاية هنا.
00:07:22الآن، في منشور المدونة هذا، وهو مثير للاهتمام للغاية.
00:07:26ذكروا أنه في وقت سابق من هذا العام، أجروا بالفعل تجربة مع بيئة وكلاء حيث قاموا ببناء متصفح ويب من الصفر.
00:07:33والآن استخدموا نفس تلك البيئة أو نفس نظام الوكلاء، إن صح التعبير، لإجراء إعادة كتابة SQLite تلك.
00:07:40لكنهم بنوا أيضاً نظاماً جديداً ببساطة بناءً على الدروس التي لديهم الآن كتجربة.
00:07:47ثم في هذه التجربة وفي منشور المدونة هذا، يقارنون بين هذه النهج المختلفة ويتعمقون في جميع التحديات التي واجهوها أثناء محاولة إعداد وتشغيل ذلك النظام الذي يعيد بناء SQLite.
00:07:59وأحد التحديات الأولى التي واجهوها عند العمل مع نظام يعمل فيه العشرات أو المئات أو الآلاف من العمال الميدانيين في وقت واحد هو أن إدارة الإصدارات التقليدية، Git، لم تعد تجدي نفعاً.
00:08:13كما كتبوا في منشور سابق حول السرب: نعلم أن أدوات مثل Git و Cargo تعتمد على أقفال خشنة للتحكم في التزامن، مما يعني أن نفس البيانات يتم إغلاقها حتى لا تتمكن من استقبال كتابات متعددة في وقت واحد.
00:08:30هذا جيد لمطور واحد، ولكنه غير عملي لحجم العمل الناتج عن مئات الوكلاء المتزامنين.
00:08:36وصل سرب المتصفح من وقت سابق من هذا العام إلى ذروة تقارب 1000 إيداع (commit) في الساعة.
00:08:41هذا هو السرب الذي أعاد بناء ذلك المتصفح.
00:08:45النظام الجديد، الذي صمموه لهذه التجربة، يصل إلى ذروة تبلغ حوالي 1000 إيداع في الثانية.
00:08:52لذا فإن السرب القديم، الذي شغلوه في وقت سابق من هذا العام، كان يسجل 1000 إيداع في الساعة، وهو أكثر قليلاً مما يحققه معظم البشر بالطبع، وبشكل بديهي.
00:09:02النظام الجديد، مع ذلك، كان يحتوي على حوالي 1000 إيداع في الثانية، وهو أمر مذهل للغاية ومن الواضح جلياً أنه ليس ما بُني Git من أجله.
00:09:14بشكل بديهي.
00:09:15لتسهيل هذا المعدل من النشاط، بنينا نظاماً جديداً للتحكم بالإصدارات من الصفر.
00:09:21لم يكن معدل التدفق هو السبب الوحيد لامتلاك هذه الطبقة.
00:09:25كل تغيير في النظام يمر عبر نظام التحكم بالإصدارات.
00:09:29لذا فهو المكان الذي تصبح فيه التصادمت مرئية لأول مرة.
00:09:31والعديد من آليات التنسيق في القسم التالي تم تطبيقها مباشرة داخله.
00:09:37وهذا أمر مثير للاهتمام حقاً.
00:09:39لقد بنوا نظاماً جديداً للتحكم بالإصدارات لعصر وكلاء الذكاء الاصطناعي.
00:09:43لأن النظام القديم، Git، الذي نستخدمه جميعاً بالطبع، ليس فيه أي عيب.
00:09:48فقط لأكون واضحاً جداً.
00:09:49نحن نتحدث هنا عن تجربة على نطاق ومهمة قد لا يتطرق إليها الكثير منا، على الأقل ليس في القريب العاجل.
00:09:57ولكن مع ذلك، فإن النظام القديم، Git، لم يُبنَ ليكون لديه مئات الوكلاء، مئات الكيانات التي تعمل على نفس الكود في وقت واحد.
00:10:07لذا بنوا نظاماً جديداً للتحكم بالإصدارات، يمكنه التعامل مع تزامن عالٍ بشكل خيالي، ولكن يمكنه أيضاً المساعدة في حل النزاعات عبر الوكلاء.
00:10:19لأنه من الواضح أن نظام التحكم بالإصدارات هو المكان الذي تصبح فيه النزاعات مرئية إذا أثر تغييرَان على نفس الجزء من الكود في ملف ما.
00:10:28لذا فهذا هو الشيء المهم الأول هنا.
00:10:30لقد بنوا نظاماً جديداً تماماً للتحكم بالإصدارات لهذه التجربة ليتمكنوا من تشغيلها بفعالية أو إجراء هذه التجربة.
00:10:37الآن، بطبيعة الحال، كما ذكروا هنا، واجهوا العديد من المشاكل بهذا النطاق ومعدل التغيير عند 1000 إيداع في الثانية.
00:10:48على سبيل المثال، وهذا مثير للاهتمام حقاً، كل هذه المشكلات التي واجهوها وكيف قاموا بحلها، لأنها تعطينا لمحة عن كيف قد تبدو هندسة البرمجيات في المستقبل، على الأقل في سيناريوهات معينة.
00:11:01مشكلة التصميم مزدوج العقل (split brain).
00:11:03مخططان، كل منهما لا يعلم بالآخر، يطبقان نفس المفهوم بطرق مختلفة في أجزاء مختلفة من قاعدة الكود.
00:11:10إذاً هذا تكرار، نفس المفهوم بطرق مختلفة في أجزاء مختلفة من قاعدة الكود.
00:11:16عادة ما ترغب في استخراج ذلك وإعادة استخدام منطق البرمجة، أليس كذلك؟
00:11:21قمنا بإصلاح هذا من خلال صياغة الأوامر (prompting).
00:11:24لذا لم نقم ببناء أي نظام جديد ومُعقد هنا، بل تم الأمر عبر الهندسة التلقينية.
00:11:28يتخذ المخططون القرارات التأسيسية بأنفسهم، أي وكلاء التخطيط، بدلاً من تفويضها.
00:11:34ونطلب منهم ضمان عدم وجود شجرتين فرعيتين مفوضتين تقرران في نفس المسألة.
00:11:39إذاً هي مسألة إعداد وتنظيم هنا.
00:11:40الأمر كله يتعلق بضمان أنه أثناء تقسيم ذلك النظام إلى مخططين ومنفذين وما إلى ذلك، فإنك تضمن أن المخططين المختلفين لديك—لأنه ليس مجرد عمال متوازيين، بل كل المخططين المتوازيين—لديهم مهام محددة بوضوح واستبعاد كبير جداً لحدوث تضارب أو تداخل.
00:12:02لذا، فإن ذلك يبدأ بالطبع بالتصميم من قبل البشر.
00:12:08أي كيف تقوم إعداد المهمة وكيف تصوغ الأوامر، صح؟
00:12:11قمنا بإصلاح هذا من خلال صياغة الأوامر.
00:12:13لذا فإن ذلك ينساب بالطبع أسفل شجرة الوكلاء مع كل تلك العقد المتوازية والأوراق المتوازية، حيث تريد التأكد من أنه عندما يقوم الوكلاء بتقسيم المهام إلى مهام فرعية، يتم توجيه هؤلاء الوكلاء لتقسيم المهام بنسبة تداخل منخفضة.
00:12:34لذا فإن هذا في النهاية تحدي تخطيط للبشر، ويتعلق كله بإعداد النظام بالطريقة الصحيحة من الجانب البشري.
00:12:43هكذا قاموا بحل أو معالجة هذه المشكلة.
00:12:47مشكلة أخرى واجهوها كانت التنافس بين المخططين.
00:12:51شكل أصعب من التنافس يحدث عندما يعلم مخططأن بوجود بعضهما البعض ويتصارعان من خلال تغييرات متضاربة ذهاباً وإياباً على نفس الملفات.
00:12:59المشكلة هي وجود تصورين للواقع ولا يمكن لأدوات الدمج حل هذا الخلاف.
00:13:04بدلاً من ذلك، نطلب من الوكلاء تسجيل القرارات في وثائق تصميم مشتركة.
00:13:08الكود الذي يعتمد على قرار يحمل مرجع فحص مجمع يعود إلى وثيقته.
00:13:13عندما يتناقض المخططون دون علم، يقوم وكيل الموفّق بدمج الوثائق وتنشر المراجع الحل إلى المراحل التالية.
00:13:21لذا في النهاية، وبالمرور بالنقطة السابقة، عند تقسيم العمل عبر المخططين، بطبيعة الحال في تطوير البرمجيات لا يمكنك تجنب التداخلات أو المجالات المشتركة بالكامل، أو المنطق المشترك، أو المناطق المشتركة التي تحتاج إلى تعديل من قبل المخططين والعمال في نهاية المطاف في قاعدة الكود.
00:13:43لذا عندئذ يبدأ وكلاء التخطيط في الصراع حول إحدى طرق التنفيذ، وقد قاموا بإصلاح ذلك عن طريق إدخال وكيل موفّق (reconciler)، على ما أفترض، يقوم بدمج الوثائق التي صممها هؤلاء المخططون.
00:13:59والتي صُممت لتسليمها بعد ذلك للعمال.
00:14:02كانت لديهم خطوة توفيق في المنتصف تدمج تلك الوثائق الخاصة بوكلاء التخطيط المتصارعين حتى يتحدثوا لغة متسقة ويتفقوا على طريقة تطبيق واحدة للمساعدة أيضاً في ضمان عدم إعادة تطبيق نفس الشيء بطرق مختلفة في أجزاء مختلفة من قاعدة الكود.
00:14:21لذا فإن هذين العنصرين يعملان معاً، كما أفهم.
00:14:24الآن، بطبيعة الحال، واجهوا أيضاً تعارضات الدمج (merge conflicts).
00:14:29لذا فإن التخطيط والضمان بعدم وجود تداخل هناك أو وجود أقل قدر ممكن من التداخل وأن يتحدث المخططون نفس اللغة هي الخطوة الأولى المهمة.
00:14:38ولكن مع ذلك، فإن وجود عمال متعددين، حتى لو كان عمال متعددون يعملون على خطة واحدة ونفس الخطة، فمن المرجح جداً بالطبع أن يمسوا نفس الملفات ويتعارضوا مع بعضهم البعض.
00:14:50لذلك هناك الكثير من العمال الآخرين الذين لن يحرصوا فقط على عدم العمل على نفس الملفات.
00:14:55لهذا السبب لن يعملوا على نفس الملفات.
00:14:57لهذا السبب لن يعملوا على نفس الملفات.
00:14:58من أجل حل التعارض، يتوجب عليهم التوقف، واستيعاب سياق الوكيل الآخر والدمج من حوله.
00:15:03بطبيعة الحال، إذا عمل وكيلان أو إنسانان في هذا الصدد على نفس الملف، فمن أجل حل هذا التعارض، يجب على كلاهما التوقف، بغض النظر عما إذا كانوا وكلاء أو بشراً، أو من المفترض عادةً أن يتوقفوا ليصلوا إلى قرار،
00:15:19طريقة تنفيذ تحل التعارض.
00:15:23ومع ذلك، فإن وكلاء التنفيذ سيئون في هذا، وفي الممارسة العملية إما أن يتجاوزوا التغيير الآخر أو يتخلوا عن تغييرهم الخاص.
00:15:29وربما لاحظت هذا أيضاً.
00:15:31أنا بالتأكيد لاحظت ذلك.
00:15:32إذا كنت تعمل في قاعدة كود مع وكيل ذكاء اصطناعي واحد أو أكثر وقمت بإجراء تغيير.
00:15:38حسناً، أعلم أنه أمر مخيف، ولكن لا يزال بإمكانك كتابة الكود.
00:15:40لنفترض أنك أجريت تغييراً.
00:15:42لقد غيرت شيئاً ما في الكود.
00:15:44يقوم الوكيل دائماً بالتراجع عنه واستبداله.
00:15:48إنه لا يحترم تلك التغييرات.
00:15:50لديه أجندته الخاصة.
00:15:52وإذا تقرر أنه يجب عليه تعديل هذا الملف المحدد، فسوف يفعل ذلك.
00:15:57وهو لا يهتم إذا كنت قد أجريت أي تغيير عليه في هذه الأثناء.
00:16:01يختلف الأمر قليلاً إذا قمت بإيداع (commit) ذلك التغيير لأن هؤلاء الوكلاء يتم تدريبهم وتعديلهم بدقة كي لا يتراجعوا بسهولة عن إيداعاتك وما إلى ذلك.
00:16:13ولكن إذا كان تغييراً غير مودع، فإن العمال ببساطة لا يبالون.
00:16:17الوكيل ببساطة لا يبالي.
00:16:19وهذا بالضبط ما واجهوه هنا أيضاً.
00:16:21لإصلاح هذا، أنشأنا نظاماً يتدخل فيه وكيل محايد كطرف ثالث عند تعارضات الدمج ويحلها نيابة عن جميع الأطراف.
00:16:29هدفه الوحيد هو أن يكون نزعاً وفعالاً، على غرار طريقة عمل طوابير الدمج (merge queues) في فرق الهندسة.
00:16:35وأعتقد أن هذا مثير للاهتمام أيضاً.
00:16:38إنه مرة أخرى شكل من أشكال التوفيق.
00:16:41إنه مرة أخرى، كما أفهم، يتعلق بإيقاف هؤلاء الوكلاء، تماماً كما في العالم القديم حيث كان عليك التوقف والتراجع خطوة للوراء وإيجاد
00:16:49حل للنزاع.
00:16:51ولكن ما يظهره هذا بوضوح، وهو ليس درساً جديداً أيضاً، هو أن السياق الجديد الممنوح بالسياق الصحيح، ذو أهمية فائقة للغاية.
00:17:03لذا بغض النظر عما إذا كنت تتعامل مع مهمة واسعة النطاق مثل Cursor هنا، والتي لا نفعلها جميعاً، أو إذا كنت تعمل فقط على مشروع أصغر حجماً،
00:17:12فإن الميزة الكبيرة لوجود تقسيم عبر وكلاء التخطيط والتنفيذ والمراجعة هي في المقام الأول، أو غالباً جداً على الأقل، أنك تعمل بنوافذ سياق جديدة.
00:17:24هذا لا يعني أنها نوافذ سياق فارغة.
00:17:26هذا يعني فقط أن لديك جلسات وكلاء جديدة محددة بالسياق المناسب تماماً لمهمة معينة.
00:17:33على سبيل المثال، المنفذ سيء للغاية في مراجعة عمله الخاص لأنه يمتلك كل ذلك السياق الناتج عن تنفيذ تلك الأشياء في نافذة السياق الخاصة به.
00:17:41لذا فهو منحاز، إذا أردت تسميته كذلك.
00:17:44لهذا السبب يجب أن يبدأ وكيل المراجعة في نافذة سياق جديدة، ويجب أن يحصل على المعلومات، حول ما عمل عليه المنفذ، وما كانت الخطة، وما هي الملفات التي تم تعديلها، ولا شيء غير ذلك.
00:17:55حتى يتمكن من مراجعة ذلك العمل بصدق.
00:17:59لهذا السبب فإن نوافذ السياق الجديدة المليئة بالسياق المناسب مهمة للغاية.
00:18:04وهذا بالضبط نفس الشيء هنا حيث قاموا بحل تعارضات الدمج من خلال وكيل جديد بالسياق المناسب تماماً وبدون وجود تحيز يمكنه بعد ذلك حل النزاع.
00:18:17ثم أفترض أن النظام قد تم إعداده بحيث تلقى هؤلاء الوكلاء التنفيذيون معلومات تفيد بأن هذا هو حل النزاع ويجب عليهم عدم تجاوزه أو أنه تم بدء تشغيل وكلاء تنفيذيين جديد.
00:18:30هذا ليس واضحاً لي تماماً هنا.
00:18:32مشكلة أخرى واجهوها كانت الملفات الضخمة (mega files).
00:18:35بعض الملفات تُعد أماكن شائعة بشكل خاص لعمل الوكلاء.
00:18:39قد يضيف كل وكيل قدراً صغيراً فقط من الكود ولا توجد مسؤولية على أي وكيل بمفرده للحفاظ على حجم الملف صغيراً.
00:18:45هذه الملفات الضخمة تخنق كل شيء.
00:18:49إنها مكلفة في النقل، والفحص (diff)، والدمج، وتصبح موقعاً للتصادمات المستمرة.
00:18:54مرة أخرى، هذا شيء قد تكون واجهته على نطاق أصغر بكثير أيضاً.
00:19:00أنا بالتأكيد واجهته.
00:19:01أحد الأشياء التي لدينا.
00:19:02خاصة فيما يتعلق بالاختبار.
00:19:03تجربتي هي أن الوكلاء يحبون الاستمرار في إضافة المزيد والمزيد من الاختبارات في نفس الملف.
00:19:08وبالطبع لا يقتصر الأمر على الاختبار فحسب، بل إنه مجال واحد يمكنني ملاحظة ذلك فيه باستمرار.
00:19:13خاصة إذا كان لديك عدة وكلاء يعملون، ولكل وكيل أجندته الخاصة.
00:19:18إنهم لا يبالون لأنهم ليسوا بشرًا.
00:19:21كيف يمكنهم المبالاة بأي شيء؟
00:19:23إنهم فقط ينفذون المهام، أليس كذلك؟
00:19:24لا يبالون بحجم الملف أو بالبنية الهندسية العامة للنظام.
00:19:30إذا كان لديك مجرد مجموعة من الوكلاء الذين ينفذون مهامهم، ستنزلق قاعدة البرمجيات الخاصة بك إلى الفوضى في مرحلة ما.
00:19:37لأن الوكلاء لا يبالون.
00:19:39إنهم يهتمون فقط بتنفيذ مهامهم.
00:19:42وهذه الملفات الضخمة هي بالطبع مؤشر واضح على تلك المشكلة.
00:19:48حيث تتشكل هذه المشكلة كلما عمل المزيد من الوكلاء لفترة أطول في مشروعك.
00:19:55لا يوجد وكيل مسؤول عن تقسيم هذا الملف أو الحفاظ على تنظيم قاعدة البرمجيات بشكل جيد.
00:20:02هذه ليست ضمن جدول أعمالهم ببساطة.
00:20:04لذا، لإصلاح ذلك، منحنا وكلاء العمل طريقة للإبلاغ عن الملفات المتضخمة.
00:20:09وبمجرد الإبلاغ عنها، نمنع التعديلات الجديدة ويقوم وكيل مستقل بتفكيك الملف المتضخم إلى وحدات برمجية أصغر.
00:20:16مرة أخرى، يتم الاستعانة بوكيل جديد.
00:20:19إنه نمط نراه هنا.
00:20:21بالنسبة لجميع هذه المشاكل، كان الأمر يتعلق بتحديد المشكلة ثم استخدام وكلاء أفراد بالمهام المناسبة،
00:20:28مع تزويدهم بالسياق المناسب لحل تلك المشكلة، بحيث يمكن للوكلاء الآخرين مواصلة عملهم.
00:20:35وينطبق الأمر ذاته هنا على الملفات الضخمة.
00:20:38التصلب، مشكلة أخرى واجهوها.
00:20:40تعلم الوكلاء من العمل في قواعد البرمجيات الحالية بمشاركة البشر،
00:20:44ألا يمسوا الكود الأساسي حتى عندما يحتاج إلى تغيير.
00:20:48لذا، ليس هذا ما قصدته سابقًا.
00:20:50عندما تجري تغييرًا في ملف يعمل عليه الوكيل، فيتجاهله تمامًا.
00:20:55إنما يتعلق الأمر بشكل عام.
00:20:57لدى الوكيل مهمة واضحة بناءً على خطة، وبناءً على توجيه أعطيته إياه.
00:21:03وهذا يتضمن بالطبع تغيير ملفات معينة.
00:21:07الآن، الشيء الوحيد الذي نعرفه أو نراه كل يوم عند العمل مع الوكلاء هو أنه اعتمادًا على النموذج،
00:21:16تكون بعض النماذج مترددة للغاية في التخلي عن الكود الحالي.
00:21:21فضلًا عن ذلك، تضيف 10 بدائل احتياطية و10 شروط تحقق والمزيد من الكود القديم بدلاً من حذفه وتنظيفه.
00:21:31يجب عليك توجيهه بشكل صريح للتأكد من أن الوكيل يحذف دالة حقًا أو يتخلص من ملف كود ما.
00:21:39إنهم لا يفعلون ذلك من تلقاء أنفسهم بسبب الضبط الدقيق، لأنه من الواضح أن مزودي النماذج لا يريدون بناء نماذج،
00:21:47تتحرك بحرية وتفسد جميع أنواع كود الإنتاج.
00:21:50لكن عند عدم العمل على مشروع قائم، أو على قاعدة برمجية حالية قد تكون قيد التشغيل بالفعل،
00:21:57فإن هذا الميل إلى عدم لمس الكود والاحتفاظ به للأبد يمكن أن يكون إشكاليًا ومزعجًا للغاية.
00:22:05ويمكن أن يؤدي أيضًا إلى آثار جانبية أخرى مثل تلك التي واجهوها هنا حيث لا يقوم الوكلاء بتحسين الكود المكتوب بواسطة وكلاء آخرين،
00:22:16بل يبنون فوقه مرارًا وتكرارًا، مما يؤدي في النهاية إلى تضخم قاعدة الكود بطبيعة الحال.
00:22:23ولإصلاح ذلك، سمحنا بالكسر المتعمد للكود.
00:22:27فالوكيل الذي يرى أن التغيير الجوهري يستحق العناء يمكنه إجراء تعديل مستهدف خارج نطاقه وترك تعليق يشرح سبب قيامه بذلك.
00:22:36وهذا مرة أخرى، على نطاق أصغر، ما يمكنك القيام به في مشاريعك كما أفعل أنا.
00:22:41تريد التصريح بوضوح وإخبار وكلائك: “أهلاً، نحن نبني هذا المشروع.
00:22:46نحن في مرحلة التطوير المبكر.
00:22:48هذا ليس قيد التشغيل الفعلي بعد.
00:22:49أريد تغييرات جذرية وإعادة هيكلة.
00:22:51لذا قم بتنظيف الكود بحزم.
00:22:54إعادة الهيكلة مرحب بها.
00:22:56وأمور من هذا القبيل.
00:22:58تريد تشجيع الوكلاء ونماذج الذكاء الاصطناعي هذه والتجاوز على تعليمات ضبطهم الدقيق.
00:23:04أي التخلص من معرفتهم المدمجة للتأكد من قدرتهم بالفعل على تطوير قاعدة الكود بدلاً من مجرد إضافة المزيد والمزيد من الكود إليها.
00:23:14لذا مجددًا، هذا شيء يمكننا رؤيته على نطاق أصغر هنا، وتم تطبيقه بالطبع على نطاق واسع.
00:23:19الآن بالنسبة للمراجعة، استخدموا أسلوبًا يسمى “عدسات المراجعة”.
00:23:24لدينا وكلاء التخطيط والتنفيذ، ولكن بالطبع يجب مراجعة هذا العمل لإنشاء مهام متابعة وإعادة الدورة حتى يتم إصلاح خطأ معين أو تصبح قاعدة الكود في حالة أفضل.
00:23:38في نظام يعمل لفترة طويلة ويتكون من عدة وكلاء، تتراكم الأخطاء ويحتاج السرب إلى طريقة لتصحيح نفسه قبل أن تصبح الأخطاء الصغيرة جذرية.
00:23:47مرة أخرى، هذا أمر منطقي.
00:23:48لقد رأينا جميعًا هذا على نطاق أصغر أيضًا.
00:23:50لقد جربنا أنواعًا عديدة من عدسات المراجعة، مثل إعطاء وكيل المراجعة السجل الكامل لوكيل التنفيذ، أو ناتجه فقط، أو لا شيء سوى قاعدة الكود.
00:24:00جربنا أيضًا مراجعين يعملون على نماذج مختلفة بتدريب مختلف وشخصيات مختلفة.
00:24:05لا توجد عدسة واحدة تكتشف كل شيء، لكن العدسات المتكاملة تتضافر بطريقة تجعل الأنظمة ذاتية القيادة تتفوق على الموثوقية البشرية دون وجود عنصر مثالي واحد.
00:24:16إن الجهد الحسابي المبذول في المراجعة ذو عائد عالٍ لأن المراجعة أرخص بكثير من العمل الذي تدققه.
00:24:21نرجح أن نظام المراجعة المتعدد الطبقات هذا كان مساهمًا رئيسيًا في الحفاظ على جودة عمليات التشغيل.
00:24:28إليك النتيجة الرئيسية هنا.
00:24:30من المستحيل أن يقوم وكيل مراجعة واحد أو أكثر بمراجعة قاعدة الكود بأكملها.
00:24:39هذا حجم كبير جدًا.
00:24:41بدلاً من ذلك، جربوا نهجًا مختلفة مثل إعطائه السجل الكامل أو المخرجات فقط أو قاعدة الكود فقط.
00:24:47وما اكتشفوه في النهاية هو أن ما ساعدهم هو وجود مراجعين مختلفين بشخصيات مختلفة وعدسات تركيز مختلفة حيث يركزون على جوانب مختلفة.
00:25:00إعطاؤهم قاعدة الكود، كما أفهم، وربما بعض المعلومات حول ما قام به وكيل التنفيذ.
00:25:06وكان التجميع لمخرجات مراجعين متعددين هو ما أدى في النهاية إلى نتيجة مراجعة إجمالية يمكن للمخطط استلامها مجددًا لتحويلها إلى خطة وجعل العمال يصلحون الكود.
00:25:23وعلى نطاق أصغر، أعتقد أن هذا شيء يمكنك أو يمكننا تطبيقه أيضًا.
00:25:28الآن، بالطبع، نحن لا نبني أشياء من هذا القبيل.
00:25:34ولكن ما يعمل بشكل جيد للغاية حسب تجربتي أيضًا، هو وجود عدة وكلاء مراجعة بمهام مختلفة حيث قد يركز أحدهم على: هل هذا كود Rust أصولي؟
00:25:46وقد يركز آخر على الأداء ومشكلات الأمان إذا كان ذلك ممكناً.
00:25:51وقد يركز مراجع آخر على أنماط التسمية إذا كان هذا شيئًا تريد التركيز عليه، وما إلى ذلك.
00:25:58لذا لديك عدسات مختلفة ثم تعطي هؤلاء المراجعين السياق المناسب تمامًا.
00:26:03مرة أخرى، شيء مثل: لقد عمل العمال على تلك الميزة.
00:26:07ربما تعطيهم خطة العامل وربما بعض المعلومات حول الخطوات التقريبية التي قام بها، ولكن لا شيء أكثر.
00:26:15وبعد ذلك لديك كل هذه المخرجات من المراجعين المختلفين ويمكنك دمجها مجددًا، ربما مع مراجع آخر.
00:26:22ما يعجبني أيضًا هو وجود مراجع يراجع نتائج المراجعة، بهدف تصنيف الملاحظات بناءً على ميل بعض النماذج لإيجاد أخطاء بأي ثمن.
00:26:36بغض النظر عن الكود الذي تسلمه لهم، حتى لو كان سطرًا واحدًا.
00:26:40أشعر أحيانًا أنهم قد يجدون خمس مشكلات فيه.
00:26:43لذا فإن وجود مراجع يتولى تصنيف تلك الملاحظات واستبعاد ما ليس مشكلة حقيقية يمكن أن يعمل بشكل ممتاز حسب تجربتي.
00:26:55وهذه التوليفة المتكاملة من المراجعين هي ما يساعد في إنتاج نتائج جيدة يمكن استخدامها وتنفيذها مجددًا.
00:27:06الآن، يعتمد الأمر دائمًا على حجم مهمتك أو البرمجية التي تبنيها.
00:27:11بالطبع، بالنسبة للعديد والعديد من البرمجيات، فإن هذا معقد للغاية، ولكنه يعطي لمحة رائعة عن كيف يمكن أن تبدو هندسة البرمجيات وكيف يمكن أن تبدو مثل هذه الأنظمة في المستقبل، وهو ما أجده شخصيًا مثيرًا للاهتمام للغاية.
00:27:27الآن، هناك شيء أخير قاموا به وهو السماح للوكلاء بتشكيل بيئة العمل.
00:27:32هنا كانت الفكرة هي السماح للوكلاء بكتابة دليل ميداني، وهو وثيقة أو مجموعة وثائق دون إعطائهم تعليمات سوى أن يعمل كمرجع للمهمة الشاملة، حيث يمكن للوكلاء بناء ذاكرة مشتركة تحتوي على الدروس المستفادة والمشاكل الرئيسية التي تم تحديدها.
00:28:00بحيث يكون لديهم نظام الذاكرة الإضافي هذا لتدوين الملاحظات وتوثيق القرارات.
00:28:10وبشكل عام، أجد هذه التجربة مثيرة للاهتمام للغاية، تمامًا مثل مشروع إعادة كتابة BUN بـ Rust.
00:28:16يمكن أن تكون مخيفة أيضًا.
00:28:17أنا أتفهم هذا تمامًا.
00:28:18وأعتقد أنه لا ينبغي لنا أن نستنتج أن هذه هي الطريقة التي ينبغي بها بناء جميع البرمجيات من الآن فصاعدًا.
00:28:24أعني، أولاً، هذه ليست برمجية جاهزة للإنتاج الفعلي.
00:28:28وجعلها جاهزة للإنتاج سيستغرق بالتأكيد قدرًا كبيرًا من الوقت.
00:28:33هذا أمر لا ينبغي الاستهانة به.
00:28:35الأمر ليس وكأنك تستطيع بناء شيء مثل هذا في ساعتين ثم يتطلب تجهيزه للإنتاج بضع ساعات إضافية فقط.
00:28:43تحقيق أول 80% قد يكون أسرع بكثير من إنجاز الـ 20% الأخيرة.
00:28:48نعلم جميعًا ذلك.
00:28:49لذا فهذه نتيجة مهمة يجب أخذها بعين الاعتبار.
00:28:51من المهم أيضًا إدراك أن هذه المهمة المحددة لإعادة كتابة SQLite قد تلقت تلك وثائق المواصفات واستخدمت مجموعة الاختبارات هذه.
00:29:04ولكن بالطبع، هذه مواصفات تفصيلية للغاية، وهو أمر لا تملكه في المشاريع الجديدة.
00:29:13إذا كنت تبني برمجية جديدة، فلن تكون لديك مواصفات مفصلة كالتوثيق الخاص ببرمجية عمرها أكثر من 20 عامًا.
00:29:24وحتى لو تم تقديم التوثيق فقط لهؤلاء الوكلاء، فإن الكود المصدري لـ SQLite ومشاريع مثل Turso بـ Rust كانت على الأرجح جزءًا من البيانات التدريبية لهذه النماذج.
00:29:46لذا لم يكن الأمر جديدًا كليًا بالنسبة لهذه النماذج.
00:29:51ليس الأمر نَفْسَه كبناء برمجية جديدة تمامًا حيث تكون التجربة والتكرار جزءًا أساسيًا من بنائها.
00:29:58ستواجه صعوبة كبيرة، وأود أن أقول إنه من المستحيل بناء برمجية جديدة من الصفر دون أن تتغير باستمرار.
00:30:11لأنه لا يمكنك كتابة مواصفات مثالية مسبقًا ثم الانتهاء منها.
00:30:17أنت تكتشف دائمًا أشياء جديدة أو أمورًا تريد تغييرها أثناء البناء، بغض النظر عن النطاق.
00:30:26وبالتالي، بالطبع، هذا لا يمثل كيف سيتم أو يجب بناء البرمجيات بشكل عام.
00:30:34ومع ذلك، فهي تجربة مثيرة للاهتمام للغاية.
00:30:37إنها تجربة مثيرة للاهتمام للغاية وتحتوي على دروس رئيسية تهمنا جميعًا.
00:30:43دروس رئيسية ليست جديدة كليًا، مثل تقسيم العمل، وجود نوافذ سياق جديدة بالسياق المناسب تمامًا.
00:30:50رؤى مثيرة للاهتمام مثل احتمال ظهور أنظمة جديدة للتحكم بالنسخ مطلوبة في المستقبل.
00:30:57وبالطبع، أن التنسيق بين الوكلاء المتعددين أصبح واقعًا قائمًا.
00:31:01كل هذا يثبت أهمية الدور البشري في تصميم هذه الأنظمة، وتحديد بنيتها المعمارية.
00:31:21كتابة ملفات المواصفات وتصميم البنية المعمارية للبرمجيات، ثم بناء أنظمة وكلاء لتنفيذها ومراجعتها أمر بالغ الأهمية.
00:31:33هذا هو الاتجاه الذي نتجه إليه جميعًا، وعلى الرغم من تغير كل شيء مقارنة بما كنا عليه قبل ست سنوات، إلا أنه أمر يثير حماسي.
00:31:45أعتقد أنه من المثير حقًا أننا ننتقل إلى مجال التفكير المنظومي، لبناء الأنظمة الذكية وتصميم البنية البرمجية نفسها.
00:31:59ثم نجمع بين الاثنين للعمل معًا.
00:32:01أجد تجارب مثل هذه مثيرة للاهتمام للغاية.
00:32:04الدروس المستفادة هنا قيمة للغاية.
00:32:07وبعض هذه الدروس على نطاق أصغر وأكثر تبسيطًا قد تكون مهمة لمشاريع البرمجة والتطوير اليومية أيضًا.
00:32:17ولكن كما هو الحال دائمًا، شاركوني أفكاركم ورأيكم في مثل هذه التجارب.