يتغيّر البرمجة الوكيلية (Agentic coding) بسرعة غير مسبوقة حتى بمقاييس عالم التقنية. معظم الدروس التعليمية والموارد المتاحة على الإنترنت تغطي ميزات فردية في سيناريوهات بسيطة تبدأ من الصفر.
خلال بناء Bob والتفاعل مع عدد كبير من الممارسين في الميدان من مختلف الصناعات، برزت مجموعة من المفاهيم التي تساعد في تحسين فاعلية وتجربة استخدام Bob.
تنطبق هذه المفاهيم أيضاً على المشاريع المعقدة التي تستخدم تقنيات غير شائعة.
المفهوم الأول: الدورة — استكشف، خطط، نفّذ، تحقق
أكثر أنماط الفشل شيوعاً في هندسة البرمجيات الوكيلية هو غياب البنية. يُموّه الترابط المحادثاتي على البنية الحقيقية، فنقع في إغراء دمج جميع خطوات التنفيذ في محادثة واحدة. تبدو الجلسات منتجة، لكن التكلفة الحقيقية لا تظهر إلا عند المراجعة.
كانت كتابة الكود يدوياً تفرض بنية من تلقاء نفسها. التنفيذ كان مكلفاً، فكان التخطيط المسبق يبدو منطقياً بديهياً. كان الفهم يتراكم أثناء الكتابة، والافتراضات الخاطئة كانت تظهر في الغالب خلال تلك العملية. الوكلاء الذكيون أزالوا هذا الاحتكاك. الكود أصبح رخيصاً الآن، وهذا أفقدنا حدسنا للبنية. البنية التي كانت نتاجاً ثانوياً للبطء باتت الآن تتطلب قصداً وتعمداً.
يمكن استخدام هذه الدورة بوعي لتوفير البنية:
- الاستكشاف ينتج الفهم
- التخطيط ينتج القرارات
- التنفيذ ينتج الكود
- التحقق ينتج الأدلة
اتباع هذه الدورة يساعدك على البقاء مركّزاً ومنظماً وتحقيق أهدافك بشكل أسرع وأكثر اتساقاً.
يمكن أن تستغرق جولة واحدة عبر الدورة عشرين دقيقة أو ثلاثة أيام. يمكن أن تحتوي الجولة على دورات فرعية، وتتباين نسبة الوقت بين المراحل تبايناً كبيراً بحسب المهمة.
يمكن العثور على شرح تفصيلي للدورة أدناه في التعمق: تشغيل الدورة.
المفهوم الثاني: نافذة السياق هي المورد النادر
التعمد في التعامل مع نافذة السياق هو العادة الأعلى عائداً.
ما هي نافذة السياق؟
النماذج عديمة الذاكرة بطبيعتها. المحادثة ليست جلسة جارية بذاكرة: كل دور يُعيد إرسال جميع الرسائل السابقة ويُلحق الإجابة الجديدة في النهاية. نافذة السياق هي الحد الأقصى للمدخلات التي يمكن للنموذج قبولها في أحد تلك الأدوار. في Bob V2 هذا يعادل 270 ألف token (إدارة نافذة السياق).
النافذة تبدأ بالامتلاء قبل إرسال الرسالة الأولى:
- محمّل مسبقاً: الموجّه النظامي لـ Bob، ووصف الوضع النشط، وملف
agents.mdالخاص بالمستودع، ووصف كل أداة من أدوات Model Context Protocol (MCP) المتصلة (MCP في Bob). - مُضاف أثناء الجلسة بشكل غير مرئي: قراءات الملفات، ونتائج الأدوات، وملفات المهارات التي يسحبها Bob، ومخرجات الوكلاء الفرعيين.
عندما تمتلئ النافذة، يضغط Bob المحادثة. يستبدل Bob المحادثة حتى الآن بملخص، ويتواصل العمل. هذا يُبقي الجلسة حيّة، وهو بطبيعته عملية تنطوي على فقدان بعض المعلومات. يقرر Bob تلقائياً أي التفاصيل تبقى، ولا شيء يُنبّه بشأن ما ضاع. الجلسة التي ضُغطت مرتين تعمل على ملخص لملخص.
استدعاء MCP واحد يمكن أن يُعيد عشرات الآلاف من الـ tokens، وتسلسل من قراءات الملفات يُخفف ما نوقش في وقت سابق من الجلسة. أوصاف الأوضاع وملفات القواعد وخوادم MCP تفعل ذلك بشكل أبطأ وأقل وضوحاً. يُفصّل Bob نافذة السياق حسب المصدر، ويستحق الأمر فتح هذا التفصيل مجدداً كلما نما الإعداد.
يُحتسب Bobcoins بشكل رئيسي على أساس لكل token. لذا تتضاعف تكلفة المحادثة تربيعياً مع ازدياد طولها. المحادثات الطويلة تكلف Bobcoins أكثر بكثير من المحادثات القصيرة! (توثيق Bobcoins)
اعمل مع نافذة السياق لا ضدها
- قسّم العمل عبر محادثات منفصلة. مهمة واحدة، جلسة واحدة. المنطق هو نفسه مبدأ المسؤولية الواحدة في الكود. يجب أن يكون للمحادثة سبب وجود واحد، مثل "ارسم مخطط بنية لمكوّن X" أو "أنشئ خطة تنفيذ للميزة Y." كل ما في نافذة السياق يؤثر على ما يأتي لاحقاً، بما في ذلك المناهج التي لم تنجح. الجلسة العالقة تميل إلى البقاء عالقة، لأن المحاولات الفاشلة لا تزال موجودة ويقرأها النموذج كدليل على ماهية هذه المهمة (تسميم السياق).
- تراجع بدلاً من الجدال مع Bob. عندما تنحرف المحادثة نحو سلوك غير مرغوب فيه، تراجع إلى آخر رسالة جيدة وغيّر الرسالة ثم تابع من هناك. هذا يتراجع أيضاً عن جميع التغييرات التي أجراها Bob محلياً، مما يُبقي نافذة السياق صغيرة ونظيفة (التراجع).
- احتفظ بكل ما يستحق الاحتفاظ في ملف لا في الدردشة. الخطط والنتائج والقرارات تنتمي إلى ملف. يمكن لزميل مراجعة مستند markdown وتسليمه لجلسة جديدة؛ سجل الدردشة لا يتيح أياً من ذلك.
- الوكلاء الفرعيون يُبعدون العمل الضخم عن نافذة السياق. يقرر Bob متى يُشغّل واحداً، وتعود فقط النتائج. طلب تشغيل واحد مباشرةً يعمل أيضاً، عندما ستنتج المهمة مخرجات لا يحتاج أحد لقراءتها (الوكلاء الفرعيون).
- كن واعياً بما يدخل نافذة السياق وما إذا كان يُضيف قيمة. راجع أدلتك ومستشعراتك بانتظام كما هو موضح في الموضوع التالي، وخصص وقتاً لتحسينها.
المفهوم الثالث: نوعان من مكونات البناء — الأدلة والمستشعرات
على مدار مشروع طويل، ما إذا كانت قاعدة الكود تتحسن أو تتراجع يتعلق أقل بـ Bob وأكثر بما يُشكّل عمله ويتحقق من مخرجاته. هناك الكثير من مكونات البناء المتاحة: القواعد والمهارات والأوضاع والخطافات والوكلاء الفرعيون والمدققون الخارجيون ووكلاء المراجعة. كل واحد منها تقريباً يؤدي أحد وظيفتين.
- الأدلة توجّه Bob قبل أو أثناء عمله (التغذية الأمامية). القواعد والمهارات والأوضاع كلها أدلة.
- المستشعرات تُفيد بعد أن يتصرف Bob (التغذية الراجعة). الاختبارات والمدققون ومدققو الأنواع وجلسات المتصفح التفاعلية ووكلاء المراجعة كلها مستشعرات.
1. الأدلة
أي شيء يُقدَّم لـ Bob لتوجيه العمل هو دليل. هناك ثلاثة مكونات بناء رئيسية تساعدك في ذلك، وتعمل بوضع نص في نافذة السياق إضافةً إلى الموجّه الذي كتبته. تختلف في متى يصل هذا النص وما الذي يُشغّله.
- القواعد نشطة دائماً.
agents.mdفي جذر المستودع هو الرئيسي، والنصيحة الأساسية بشأنه هي الإبقاء عليه قصيراً. كل سطر يتنافس على الاهتمام في كل دور واحد، لذا فإن ملف قواعد طويل يجعل Bob أسوأ في اتباع أي قاعدة فردية فيه (القواعد). - الأوضاع يُفعّلها المستخدم. الأوضاع المدمجة هي: Ask للقراءة فقط. Plan يعمل من خلال عملية تخطيط ويسلّم النتيجة إلى Agent، الذي يتخذ الإجراء. يمكن إضافة أوضاع مخصصة بسهولة (الأوضاع, إضافة وضع مخصص).
- المهارات يُفعّلها Bob عندما يرى أنها ذات صلة. وصف المهارة الصغير فقط هو النشط دائماً. يُحمَّل الجسم الرئيسي للمهارة في السياق عند الطلب فقط. هذا يجعل المهارات فعّالة جداً من حيث الـ tokens (المهارات).
كل ما في ملف القواعد يستهلك tokens في كل دور، سواء احتاج هذا الدور إليه أم لا، لذا أبقِه في حده الأدنى ودع الباقي ينتظر حتى ينطبق.
2. المستشعرات
أي شيء يُعطي Bob تغذية راجعة حول العمل المُنتج هو مستشعر. الإشارات المفيدة تعتمد على قاعدة الكود والمكدس التقني، لذا تختلف المجموعة الجديرة بالاهتمام من مشروع لآخر وتتطلب عملاً حقيقياً لتجميعها. أكثر المستشعرات قيمة هي تلك القابلة للتشغيل آلياً والتي ينفذها Bob خلال مرحلة التنفيذ. يمكن تصنيف المستشعرات في فئتين مختلفتين.
- المستشعرات الحسابية حتمية: الاختبارات والمدققون ومدققو الأنواع والمُصرِّفون. الأحكام دقيقة وقابلة للتكرار، وهي رخيصة بما يكفي لكي يشغّلها Bob بشكل متكرر. التغطية مقيّدة بالأنظمة التي بنيها الفريق ويصونها.
- المستشعرات القائمة على الذكاء الاصطناعي مرنة وغير حتمية. وكيل المراجعة يقرأ بحثاً عن النية، وعن الأشياء التي لا توجد للمدقق قاعدة لها. المخرج حكم وليس قياساً. يتفاوت بين التشغيلات والتكلفة والمدة مما يحدّ من مدى تكرار استخدامه (مراجعات الكود).
ربطها يوفر عدة خيارات، بترتيب تقريبي من الأقل احتكاكاً:
- الخطافات (Hooks) هي الخيار الحتمي الأقل احتكاكاً. يعمل الفحص في نقطة محددة، في كل مرة، بصرف النظر عما إذا كان Bob يرى أنه ذو صلة. اطلع على توثيق الخطافات.
- المهارات تُستخدم كثيراً كأدلة، لكن مهارة تُشغّل مراجعة هي مستشعر، وهي الطريقة الأقل احتكاكاً لإضافة فحص غير حتمي. اطلع على توثيق المهارات.
- التكامل المستمر (CI) يضع وكيل مراجعة في الـ pipeline، على كل pull request، للفريق بأكمله لا لمطور واحد. اطلع على وكيل مراجعة الـ PR أثناء العمل.
التعمق: تشغيل الدورة
حدود المراحل هي أيضاً حدود السياق، وهو السبب العملي للإبقاء عليها متمايزة: ثرثرة الاستكشاف لا عمل لها في المحادثة التي يُكتب فيها الكود.
1. الاستكشاف
يتباين الاستكشاف تبايناً كبيراً بحسب دورك والمهمة المطروحة. قد يعني التأهل لقاعدة كود جديدة، أو تقدير نطاق تأثير إعادة هيكلة كبرى. بعض الأمثلة:
- اطلب من Bob إنشاء مخطط بنية للنظام الموجود قبل تغيير أي جزء منه. اطلع على درس توليد مخططات البنية، أو الشيء نفسه بالفيديو.
- اطلب جولة تعريفية مخصصة من زاويتين، مرة كمستخدم يتنقل عبر المنتج ومرة كمطور يتنقل عبر الكود. تقديم معلومات عن خبرتك ومهمتك يساعد في تخصيص الوثيقة (فحص قاعدة الكود).
- في IBM Z وIBM i، استخدم الخيارات الخاصة بالمنصة. مشكلة الاستكشاف في تلك الأنظمة مختلفة وتستفيد استفادة كبيرة من الأدوات المتخصصة المتوفرة في الحزم المميزة. اطلع على الحزمة المميزة لـ Z (التوثيق) والحزمة المميزة لـ IBM i (التوثيق).
قد يشمل الاستكشاف أيضاً بناء أشياء تنوي حذفها. التنفيذ أصبح رخيصاً الآن، لذا النموذج الأولي الضيق هو أسرع طريقة لمعرفة ما إذا كان نهج ما يصمد أمام قاعدة الكود. سمّى كنت بيك هذا "تنفيذ الاستكشاف" (spike implementation) منذ خمسة وعشرين عاماً، والانضباط هو نفسه: ابنه لتتعلم شيئاً، احتفظ بالتعلّم، واتخلص من الكود.
التنفيذ الرخيص يرفع قيمة البنية وجودة الكود بدلاً من خفضها. أصبح من السهل الآن إنتاج كمية كبيرة من الكود الذي يعمل ولكنه خاطئ.
2. التخطيط
مرحلة التخطيط هي الأعلى تأثيراً. كل ما يُصيبه الخطأ أو الصواب يدفع ثمنه مرتين: مرة في التنفيذ، ومرة أخرى عندما تغادر التغييرات يد صاحبها وعلى زميل مراجعتها.
ما يحتاجه الخطة الجيدة:
- قصيرة ودقيقة، كلاهما. الخطط يجب أن تُقرأ.
- صريحة بشأن النتيجة المقصودة، بما في ذلك الأجزاء غير المؤكدة. معرفة ما هو مجهول هو معظم العمل، واكتشافه هو الباقي.
- في ملف. يجب ألا تعيش الخطط في جلسة دردشة.
هناك طرق كثيرة لإنشاء خطة، لكن وضع Plan المدمج هو أسهل مكان للبدء (كما في هذا الدرس).
وضع Plan مبني ليكون موافقاً ويميل إلى ملء الفجوات. بينما يتيح ذلك تكرارات سريعة في كثير من الحالات، أحياناً يكون الصرامة أمراً ضرورياً. قد يبني خطة ذكية حول افتراض خاطئ دون الاعتراض على الافتراض.
مهارة مخصصة تجادل مع الخطة — grill-me بقلم Matt Pocock مثلاً — هي أرخص طريقة للحصول على تدقيق قبل أن يصبح الافتراض كوداً.
عن التطوير القائم على المواصفات (SDD). يغطي المصطلح نطاقاً واسعاً ولا يزال في تطور. الناس يعاملونه كقرار نعم أو لا، لكنه أقرب إلى طيف:
- مواصفات أولاً: تأتي الخطة قبل التنفيذ. هذا شبه غير قابل للتفاوض.
- مرتكز على المواصفات: تبقى المواصفة بعد التنفيذ، كتوثيق وكمعيار يجب أن يستوفيه التنفيذ.
- المواصفة كمصدر: المواصفة هي الملف المصدر. الإنسان يُحرّر المواصفة؛ الإنسان لا يُحرّر الكود.
أي مستوى يناسب يعتمد على الفريق وأهمية/نضج قاعدة الكود والصناعة. التكاليف العامة المصاحبة للمستويات الأعلى من SDD قد تكون مؤلمة للتكرار السريع. في صناعة السيارات، حيث يسبق التطوير القائم على المواصفات الذكاء الاصطناعي بعقود، يتناسب SDD تماماً مع الممارسة القائمة.
3. التنفيذ
التنفيذ هو المرحلة المباشرة، وBob يتولى كل جزء منه تقريباً.
مراقبة Bob وهو يعمل والتدخل للتوضيح أمر اختياري ومفيد في أغلب الأحيان. عامل التكرار كإشارة: التدخل المستمر يعني أن المشكلة في الخطة، والحل هو العودة إليها لا الاستمرار في التصحيح.
لا تتردد في التخلص من تنفيذ كامل والعودة إلى وضع Plan. الكود هو الجزء الرخيص.
4. التحقق
التحقق يقع في فئتين متمايزتين: التحقق الآلي والتحقق اليدوي.
التحقق الآلي يُقاد بالمستشعرات التي يمتلكها Bob أو التي تُفرض عبر الخطافات. تُنفَّذ بشكل متكرر خلال مرحلة التنفيذ دون تدخل بشري. الفئات الرئيسية مع بعض الأمثلة الشائعة هي:
- الصلاحية: هل يُصرَّف، هل يتحقق من الأنواع، هل يُحلَّل؟
- المقياس: اجتاز/فشل، تغطية الأنواع
- الأدوات:
tsc,mypy,cargo check,javac
- السلوك: هل يفعل الشيء الصحيح؟
- المقياس: معدل الاجتياز، تغطية الفروع
- اختبارات الوحدة، اختبارات التكامل، اختبارات من طرف إلى طرف
- الأدوات:
pytest,Jest,Playwright,Stryker
- القابلية للصيانة: هل يستحق هذا الكود الاحتفاظ به؟
- المقياس: التعقيد، التكرار، انتهاكات الحدود
- الأدوات: ESLint, Ruff, Lizard, ArchUnit
- الأمان: هل هذا الكود آمن؟
- المقياس: النتائج حسب الخطورة، CVEs
- الأدوات: Semgrep, CodeQL, gitleaks,
npm audit
تمكّن Bob من اكتشاف أخطائه وتحسين الجودة خلال مرحلة التنفيذ. التغطية الجيدة بالاختبارات هي حماية أساسية من الانتكاسات: تضمن أن Bob لم يُفسد أي شيء.
في هذه الدورة، التحقق مُدرج كمرحلة منفصلة في نهاية الحلقة، وهو يشير بشكل رئيسي إلى التحقق اليدوي. التحقق اليدوي يبدأ بتشغيل التغيير ومقارنة السلوك الملحوظ بالسلوك الذي حدده الخطة. التناقض يضيق في الغالب إلى أحد سببين:
- انحرف التنفيذ عن الخطة. الإصلاح في الكود.
- الخطة لا تعكس ما نويت بناءه. الخطة تحتاج إلى تحسين. هذا أكثر شيوعاً بكثير.
التفتيش اليدوي إذاً يختبر الخطة والتنفيذ في آنٍ واحد.
يجب حدوث تحقق إضافي في مسارات CI/CD. هذه ممارسة راسخة في هندسة البرمجيات، لكن يمكن تحسينها باستخدام وكلاء الترميز بدون رأس (headless). مثال: مراجعة آلية على كل pull request، تعمل عبر Bob Shell، تُعزز المراجعين البشريين بدلاً من استبدالهم. اطلع على فيديو وكيل مراجعة الـ PR أثناء العمل والتوثيق لتشغيل Bob Shell بشكل غير تفاعلي.
العمل في فريق
كل ما في الأقسام السابقة يصف الحلقة الداخلية لمطور واحد. تبدأ الحلقة الخارجية عندما تنتقل التغييرات إلى قائمة انتظار المراجعة. كل diff يصل الآن بشكل أسرع وبقدر أقل من منطقه المرفق، بينما لدى المراجع المزيد ليقرأه وسياق أقل للقراءة فيه.
الأدلة يجب أن تسافر مع العمل. السبب أصبح أكثر أهمية مما كان، نسبةً إلى الكيف، لأن الكيف لم يعد الجزء المكلف في الإنتاج.
عملياً يعني هذا أن الخطة ترافق التغيير: الفرق تُرفقها بالـ pull request أو تُضيفها إلى الإشكالية الأصلية إلى جانب المراجعة. الآلية تعتمد على الأدوات المستخدمة.
ما تفعله الحلقة الخارجية بعملية الفريق موضوع يستحق مقاله الخاص، وسيأتي في مقال لاحق.
بعض الأفكار حول الـ prompting
في السنوات الأخيرة، كان هناك تركيز كبير على كيفية توجيه LLMs بشكل صحيح، مع ظهور فئة وظيفية كاملة بوصف "مهندس الـ prompt". في هذه المرحلة، الكثير من الـ prompting يُعالَج داخل الإطار. قلّت أهمية تقنيات الـ prompting المتخصصة لصالح المنهج المنظّم. إليك بعض الإرشادات:
- التكرار يتفوق على الـ prompting. عندما يفعل Bob شيئاً غير ما طلبته، تراجع وأعد كتابة الرسالة التي سببت ذلك. التصحيح للأمام يترك الإجابة الخاطئة، والشكوى منها، والمحاولة الجديدة، كلها في النافذة.
- المنهج يتفوق على الـ prompting. الـ prompt محدود بجلسة واحدة. ملف القواعد، أو فحص يمكن لـ Bob تشغيله بنفسه، يواصل العمل في كل جلسة بعد التي أنتجته، وهو النوع الوحيد من الاستثمار هنا الذي يتراكم.
- أعطِ Bob الملخص الذي سيحصل عليه مهندس أول. زميل كفء أُعطي مهمة غامضة سيسأل عما يُعدّ إنجازاً وما يُسمح له بالتعامل معه؛ Bob لن يسأل، لذا ضعهما في الرسالة.
- قل ما يجب فعله، لا ما لا يجب فعله. "لا تستخدم class components" يستبعد خياراً واحداً ويترك بقية المجال مفتوحاً، فيختار Bob من بين ما تبقى وهو تخمين آخر. تسمية الهدف بدلاً من ذلك — function components مع hooks — يغلقه في دور واحد.
- أي تعليمة تُعطى أكثر من مرتين تنتمي إلى ملف. هذا ما
agents.mdوالمهارات موجودة لأجله. - تعليمات prompting أكثر تفصيلاً موجودة في درس كتابة الـ prompts الفعّالة.
النقاط الرئيسية
- غياب البنية هو المشكلة الأكبر. اتباع دورة استكشف ← خطط ← نفّذ ← تحقق يساعدك على البقاء مركّزاً وتحقيق أهدافك بشكل أسرع وأكثر اتساقاً.
- السياق هو المورد النادر، والمراحل هي حدود السياق. لا تحمل ثرثرة الاستكشاف إلى التنفيذ.
- الخطة هي مادة المراجعة. مراجعة خطة تتفوق على مراجعة diff، للمؤلف وللمراجع على حدٍّ سواء.
- أي شيء يستحق الاحتفاظ يغادر الدردشة. الخطط والقرارات والنتائج تنتمي إلى ملف. يمكنك مقارنة ومراجعة وإصدار وتسليم الملف لوكيل آخر.
- التحقق يجب أن يكون قابلاً للتشغيل آلياً، مما يعني أن عليك تصميمه أثناء التخطيط لا اكتشافه لاحقاً.
المصادر وقراءة إضافية
- Simon Willison, Agentic engineering patterns
- Birgitta Böckeler, Harness engineering
توثيق ودروس IBM Bob: