مرحبًا بكم في AI Code، مساق عن بناء البرمجيات باستخدام وكلاء البرمجة. تشرح هذه المقدمة ما يستطيع الوكلاء فعله، وكيف يعملون داخل المشروع، ولماذا ما زلنا بحاجة إلى التحقّق من عملهم. وسننظر أيضًا في مخاطر منحهم صلاحيات الوصول إلى أدواتنا وملفاتنا.
الذكاء الاصطناعي يغيّر طريقة العمل في علوم الحاسوب وفي مجالات أخرى.
وتطوير البرمجيات من المجالات التي تظهر فيها هذه التغييرات بوضوح. أدوات البرمجة تستطيع كتابة الكود وتعديله، ثم تشغيله للتحقّق من أجزاء من النتيجة. خلال المساق، سنرى لماذا تفيد هذه الأدوات في تطوير البرمجيات.
هذا المساق فرصة لبدء استخدام وكلاء البرمجة في مشاريع حقيقية، والتعامل مع الأسئلة التي تثيرها. نتعلّم هذه الأدوات وهي ما زالت تتغيّر بسرعة. لذا قد يتغيّر بعض ما نتعلّمه هنا خلال المساق نفسه. ما زلنا نبحث عن أفضل استخدام للذكاء الاصطناعي، وأسئلة كثيرة لم تُحسم بعد. ولذلك فإن هذا وقت مثير لتعلّم هذه المهارات ومواجهة أسئلة في طليعة هذا المجال.
على مدى عقود كثيرة، أضافت البرمجة عدة طبقات تجريد. يتيح لنا التجريد استخدام شيء ما دون أن نحدّد كل تفصيل في طريقة عمله. لنبدأ بلغة الآلة. وهي التعليمات الثنائية التي ينفّذها المعالج. والعمل على هذا المستوى يعني التعامل مع هذه التعليمات مباشرة.
لغة البرمجة تمنحنا المتغيّرات وحلقات التكرار والدوال. ويحوّلها المُصرِّف أو المفسِّر إلى ما تستطيع الآلة تنفيذه. فلا نحتاج إلى كتابة كل تعليمة من تعليمات المعالج.
المكتبات وأطر العمل تمنحنا كودًا جاهزًا يتولّى المهام الشائعة. يمكننا استخدام هذا الكود دون كتابته من جديد. لكن علينا أن نعرف ما يفعله، ومتى قد لا يناسب احتياجاتنا.
مع وكيل البرمجة، يمكننا وصف السلوك الذي نريده بلغة عادية. ثم يحاول الوكيل كتابة الكود. ونترك له بعض القرارات التي كنا سنتخذها بأنفسنا.
كل طبقة تتيح لنا التركيز أكثر على ما نريده، وأقل على طريقة بنائه. لكن تقليل التفاصيل في تعليماتنا لا يُلغي الحاجة إلى التحقّق من النتيجة.
ظهرت مؤخرًا ثلاثة أنواع من مساعدي البرمجة بالذكاء الاصطناعي، وتطوّرت قدراتها من نوع إلى آخر. الإكمال التلقائي يقترح كودًا أثناء الكتابة. فتقبلون الاقتراح، أو تعدّلونه، أو تتجاهلونه.
مساعد المحادثة يجيب عن الأسئلة ويكتب أمثلة. وأنتم تنسخون الكود إلى مشروعكم بأنفسكم.
أما وكيل البرمجة فيعمل داخل المشروع بحرية أكبر. فهو يقرأ الملفات ويعدّلها ويشغّل الأوامر، ويختار كل خطوة تالية بناءً على ما يراه. وقد تكون بعض هذه الخطوات أمورًا لم تطلبوها.
ومع الوكيل، وهو أحدث مرحلة في هذا التطوّر، يتغيّر دوركم. تحدّدون المهمة، ثم تراجعون التغييرات التي يُجريها، بينما يحصل هو على حرية أكبر بكثير للعمل وحده.
يستطيع الوكيل تنفيذ عدة خطوات دون تعليمات منفصلة لكل خطوة. تعطونه هدفًا، وصلاحيات الوصول إلى المشروع المعنيّ. ثم يختار إجراءات يتوقّع أنها ستساعد في إنجاز المهمة.
قد ينتج الوكيل كودًا أسرع مما تستطيعون مراجعته. عندما يترك الطلب أسئلة بلا إجابة، يضع الوكيل افتراضات. وقد يغيّر من المشروع أكثر مما قصدتم. لذلك قد تختلف النتيجة عمّا أردتم، حتى لو كان الكود يعمل دون أخطاء.
ابدؤوا المراجعة بمعرفة ما الذي تغيّر. اقرؤوا التغييرات وتحقّقوا مما تفعله. عليكم أن تفهموا الكود الحالي قبل أن تقرّروا ما تحتفظون به. إذا لم يطابق العمل المهمة، فاشرحوا ما الخطأ، وما الذي يجب ألّا يمسّه الوكيل. عندما تتراكم التغييرات أسرع من قدرتكم على فهمها، تتّسع فجوة بين الكود الذي لديكم والكود الذي تفهمونه.
تُسمّى هذه الفجوة أحيانًا الدَّين المعرفي. وسدّ هذه الفجوة يستغرق وقتًا. قد تحتاجون إلى قراءة تغييرات قبلتموها بسرعة زائدة، أو اختبارها، أو إعادة كتابتها. وأحيانًا ستقرّرون التراجع عنها.
ما مقدار الاستقلالية التي ينبغي منحها للوكيل؟ هذا يعتمد على خطورة المهمة، وعلى سهولة التحقّق من عمله. تركه يعمل وحده لفترة أطول يعني تعليمات أقل عددًا، وأقل دقة، وتوجيهًا أقل تكرارًا. لكن الافتراض الخاطئ من الوكيل قد يمتدّ أثره إلى تغييرات أكثر قبل أن تنتبهوا.
كي نقرّر مدى التدقيق في عمل الوكيل، علينا أن نعرف ما يُتقنه وأين يخطئ. الشكل غير المنتظم في هذا الرسم التوضيحي يمثّل تفاوت القدرة بين المهام. والمفاجئ أن الوكيل كثيرًا ما يُحسن أداء مهمة صعبة، ومع ذلك يرتكب خطأً بسيطًا جدًا في مهمة أخرى.
في بعض المهام، يستطيع الوكيل أن يكتب بسرعة برنامجًا يعمل، أو يشرح كودًا غير مألوف. هذه قدرات مفيدة، لكن النجاح في مجال البرمجة الصعب جدًا لا ينتقل دائمًا حتى إلى مجالات نعدّها أبسط.
النماذج نفسها التي تكتب كودًا يعمل خلال ثوانٍ كانت تخطئ في أسئلة أبسط بكثير. عندما سُئلت كم حرف r في كلمة strawberry، كانت تجيب: اثنان، وبثقة كبيرة. والجواب هو ثلاثة. تحسّنت النماذج الحالية في هذا السؤال تحديدًا. لكن الفكرة العامة ما زالت صحيحة، لأن القدرة متفاوتة، ونقاط الضعف ليست دائمًا حيث تتوقّعون.
يولّد النموذج النص بناءً على ما تعلّمه في التدريب، وعلى المعلومات الموجودة في الطلب. وهذا لا يضمن أن النموذج يتحقّق بدقة من كل عبارة قبل أن يجيب. فكيف نفسّر هذا الخطأ في كلمة «Strawberry»؟ تعمل النماذج على أجزاء من النص لا تطابق دائمًا الحروف المفردة. وفي مهمة العدّ، قد يكون استخدام أداة للعدّ أكثر موثوقية من الاعتماد على الإجابة المولَّدة وحدها.
والدرس الذي علينا استخلاصه هو: تحقّقوا من الوكيل في أنواع المهام المحدّدة التي تعطونه إياها. ولا تفترضوا أن مستوى كفاءته واحد في جميع المهام. المهم أن تعمل النتيجة التي ينتجها في الحالات التي نحتاجها.
وكيل البرمجة يتكوّن من نموذج لغوي وبرنامج يربطه بالمشروع. النموذج اللغوي الكبير (LLM) الظاهر هنا يعمل على خوادم بعيدة. ويرسل حاسوبكم إليه طلبات عبر الشبكة. يولّد النموذج ردًّا من المعلومات التي يتلقّاها. وقد يحتوي هذا الردّ على شرح، أو على طلب لتنفيذ إجراء. ردّ النموذج لا يغيّر أي ملف بنفسه. على برنامج يحيط بالنموذج أن يتولّى هذا الإجراء.
يُسمّى هذا البرنامج الـ harness، وهو يعمل على حاسوبكم.
يرسل الـ harness إلى النموذج الـ prompt. ويحتوي الـ prompt على المهمة ومعلومات أخرى يستطيع النموذج استخدامها ليقرّر ما يفعل.
ثم يستقبل الـ harness ردّ النموذج. الطلبات والردود تشكّل المحادثة مع النموذج. ويوفّر Claude Code و Codex برنامجًا يدير هذا التفاعل. ويربط الـ harness أيضًا طلبات النموذج بأدوات تستطيع العمل داخل المشروع.
طلب استخدام أداة يُسمّى استدعاء أداة. الأدوات تقرأ الملفات، وتعدّل الكود، وتشغّل الأوامر. ويتعامل الـ harness مع الاستدعاء وفق الصلاحيات المعمول بها.
وتستطيع الأدوات أيضًا جلب معلومات من خارج المشروع، مثلًا بالبحث في الويب.
ويستطيع الوكيل تكرار هذه العملية أثناء عمله. يرسل الـ harness طلبًا إلى النموذج، ويستقبل ردًّا، وينفّذ استدعاء أداة مسموحًا به. ثم يضمّن نتيجة الأداة في الطلب التالي إلى النموذج. كل نتيجة تساعد الوكيل على اختيار خطوته التالية. وتستمر هذه الحلقة حتى ينتهي الوكيل، أو يحتاج إلى مساعدة، أو يُوقَف.
النموذج يولّد الردود، والـ harness يتولّى الأدوات والإجراءات. سندرس الجزأين لنفهم ما يستطيع الوكيل فعله، وأين يمكن أن تقع الأخطاء.
في هذا المساق، سنستخدم الوكلاء في مهام برمجية حقيقية. وسنسأل كيف نحصل منهم على عمل مفيد مع متابعة ما يفعله البرنامج.
كلما كبر المشروع، احتاجت أجزاء أكثر من الكود إلى العمل معًا. علينا أن ندير هذه الروابط، ونُبقي الدَّين المعرفي تحت السيطرة. وهذا يعني أن نُبقي فهمنا للمشروع محدَّثًا بينما يغيّره الوكيل.
ما زلنا بحاجة إلى مبادئ تصميم البرمجيات المألوفة وإلى الفحوصات. الاختبارات تتحقّق من سلوكيات مختارة. والأنواع وأدوات التحليل الساكن الأخرى تكشف أخطاء معيّنة في الكود. والمراجعة تسأل هل تتلاءم التغييرات مع المشروع. كل نوع من الفحوصات يساعد بطريقة مختلفة. ومعًا، تُسهّل اكتشاف الأخطاء وتقييم عمل الوكيل.
تساعدنا هذه الفحوصات في مشروع متنامٍ على أن يظلّ يعمل، وأن يبقى مفهومًا. وتزداد فائدتها كلما كبرت قاعدة الكود وزاد اعتماد أجزائها بعضها على بعض.
أدوات الوكيل قد تؤثّر في الحاسوب الذي تعمل عليه. الوصول إلى الملفات والأوامر والشبكة يتيح للوكيل أداء عمل مفيد. لكنه يحدّد أيضًا حجم الضرر الذي قد يسبّبه إجراء خاطئ.
بالصلاحيات المناسبة، يستطيع الوكيل بناء ميزات، وإصلاح أخطاء برمجية، والمساعدة في صيانة حاسوبكم، وأتمتة الأعمال المتكرّرة.
قد يؤدّي خطأ إلى حذف ملفات ضرورية، أو كشف معلومة سرّية، أو تشغيل أمر مدمّر. إذا نُفّذت عدة إجراءات دون مراجعة، فقد يكبر الضرر قبل أن تنتبهوا.
وقد تأتي المشكلة أيضًا من محتوى يقرؤه الوكيل. صفحة ويب، أو ملف، أو اعتمادية، قد تحتوي على تعليمات وضعها مهاجم.
يريد المهاجم أن يتّبع الوكيل هذه التعليمات بدلًا من مهمة المستخدم. ولا يلزم أن تكون هذه التعليمات مخفية. الخطأ هو أن يُعامَل هذا المحتوى على أنه تعليمات يجب طاعتها.
يُسمّى هذا النوع من الهجمات حقن الـ prompt (prompt injection).
امنحوا الوكيل صلاحيات الوصول التي تحتاجها مهمته فقط. وفكّروا أيضًا في مصادر التعليمات التي ينبغي أن يثق بها. سندرس طرقًا للحدّ من ضرر الأخطاء والهجمات، كجزء من تعلّم العمل مع الوكلاء.
يغطّي المساق خمسة مجالات مترابطة. الأول هو إعطاء الوكلاء مهام برمجية ومراجعة عملهم. وسنتدرّب على ذلك في المختبرات.
الثاني هو إدارة السياق: أي المعلومات المتاحة للوكيل لأداء مهمته. ملفات ذاكرة المشروع تُبقي التعليمات متاحة، والـ skills تحفظ إجراءات جاهزة لإعادة الاستخدام، ولكل وكيل فرعي سياقه الخاص. تساعدنا هذه الأدوات على إعطاء الوكلاء المعلومات التي يحتاجونها، دون وضع كل جزء من مشروع كبير في محادثة واحدة.
المجال الثالث هو التحقّق من البرنامج. الاختبارات والأنواع والـ linters والتكامل المستمر (CI) تساعدنا في كشف أنواع مختلفة من الأخطاء. وما زال علينا أن نراجع ما تغطّيه هذه الفحوصات وما يفوتها.
المجال الرابع هو الأمان. سننظر في الحاويات التي تحدّ من الوصول، وفي هجمات مثل حقن الـ prompt. فالوكيل الذي يعمل داخل المشروع يحتاج أيضًا إلى حدود لما يمكنه التأثير فيه.
المجال الخامس هو تنسيق عدة وكلاء لحلّ مشكلة واحدة. تقسيم العمل ليس إلا جزءًا من المهمة. علينا أيضًا دمج النتائج والتحقّق من أنها تعمل معًا.
وطوال المساق، سنقيس ما إذا كانت النتيجة أفضل، وكم جهدًا تطلّبت. إنتاج الكود بسرعة أكبر لا يكفي وحده.
الفيديو التالي يشرح كيف يسير المساق، بما في ذلك الجدول الأسبوعي، والعلامات، وما يجب إعداده قبل المختبر الأول. تذكّروا من هذه المقدمة أن الوكيل يستطيع إنجاز جزء كبير من العمل، لكن مسؤوليتنا نحن أن نحدّد المهمة، ونتحقّق من النتيجة، ونضبط صلاحيات وصوله. وهذا بحدّ ذاته ليس سهلًا في مشروع معقّد ينمو باستمرار.