تبدأ الفرق الهندسية التي تقيم وكلاء البرمجة (coding agents) عادةً بالسؤال الخاطئ. فهم يريدون معرفة مدى استقلالية الوكيل. ما هو مقدار مسار العمل (pipeline) الذي يمكنه تملكه؟ هل يمكنه كتابة المواصفات، وتعديل المستودع، والنشر في بيئة الإنتاج دون إزعاج أي شخص؟ تجعل العروض التوضيحية هذا الهوس سهلاً؛ حيث ترى سير عمل سلسًا حيث يؤدي أمر واحد (prompt) إلى سلسلة من التعديلات وعمليات النشر، وتكون الغريزة هي السعي وراء نفس القدرة داخل مؤسستك. لكن الجاذبية ليست مبدأً تصميمياً جيداً. الأسئلة الأفضل هي أقل إثارة بكثير: من منح هذا الشيء السلطة، وما هي الأنظمة التي يمكنه لمسها فعلياً، وماذا يحدث عندما يخطئ حتماً؟
فخ الاستقلالية
الاستقلالية المثيرة هي فخ. فهي تدربنا على الاحتفاء بالبوتات التي تنشئ المواصفات، وتعدل المستودعات، وتنشر الكود بينما تدعي بهدوء أن المهمة قد اكتملت. هذه ليست هندسة، بل هي "سقوط في الثقة" مع صلاحيات الوصول إلى الـ shell. يصبح العمل نفسه سهلاً للغاية لدرجة يصعب معها إنتاجه. يمكن لأي نموذج أن ينتج كوداً أو وثائق أو خططاً معمارية في ثوانٍ. لكن التكلفة الحقيقية في تطوير البرمجيات لم تكن أبداً سرعة الكتابة، بل كانت دائماً في التحقق، والمراجعة، والقرار المدروس بالقول: نعم، هذا صحيح وآمن للنشر. العمل المُنشأ رخيص، أما الموافقة فمكلفة. الشركات التي تدرك كيفية التعامل مع عملية الموافقة بسلاسة واتساق ستكون هي الشركات التي تشحن أنظمة موثوقة بالفعل.
لماذا تفشل المراجعة الذاتية
تظهر المخاطر في أنماط متوقعة. يضع النموذج مسودة لخطة ثم يقيم ما إذا كانت تلك الخطة جيدة أم لا. يقوم الوكيل بتعديل قاعدة الكود الخاصة بك ويشرح لك لماذا تعد تغييراته آمنة. تقوم أداة ما بتنفيذ أمر ما وتطلب الصفح بدلاً من طلب الإذن. يمثل كل من هذه الأمثلة نفس الفشل الجوهري. إذا أنتج الوكيل مواصفات، فيجب على شيء خارج هذا الوكيل الموافقة عليها قبل أن تصبح حقيقة. إذا قام الوكيل بتعديل الكود، فيجب على عملية منفصلة فحص الفروقات (diff). إن السماح للمُنشئ بالعمل كمُحقق لنفسه ليس طريقاً مختصراً، بل هو خلل هيكلي يتخفى في زيّ السهولة.
الأوامر (Prompts) ليست أنظمة أذونات
لا يمكنك تأمين وكيل باستخدام صياغة ذكية. فإخبار النموذج بأن يكون حذراً أو أن يسأل قبل حذف شيء ما لا يخلق حدوداً. الأوامر (Prompts) ليست أنظمة أذونات. قبل أن تسمح للوكيل بالاقتراب من بيئة الإنتاج، فأنت بحاجة إلى جرد صادق لقدراته. هل يمكنه قراءة المستودع بالكامل؟ هل يمكنه تنفيذ أوامر الـ shell؟ هل يمكنه فتح متصفح؟ هل يمكنه سحب بيانات العملاء إلى نافذة السياق (context window) الخاصة به؟ معظم الفرق لا تعرف الإجابات الكاملة؛ فهم يفترضون أن الأداة محصورة في بيئة معزولة (sandbox) بينما هي في الواقع تملك صلاحيات الكتابة في المسارات الحرجة. حدد مساحة السطح أولاً، ثم ابنِ الجدران.
ابنِ نظام تحكم متعدد المستويات
بمجرد فهم ما يمكن للوكيل فعله، صمم نظام تحكم يربط المخاطر بمستوى "الاحتكاك" (friction). الإجراءات منخفضة المخاطر، مثل تحديث الوثائق الداخلية أو تنسيق الكود بشكل متسق، يمكن أن تعمل تلقائياً. الإجراءات متوسطة المخاطر، مثل إعادة هيكلة وحدة (module) أو إضافة تبعية (dependency) جديدة، يجب أن تمر بنقطة تفتيش حيث يؤكد إنسان أو مجموعة اختبارات موثقة هذه الخطوة. أما الإجراءات عالية المخاطر، مثل النشر في بيئة الإنتاج، أو تعديل البنية التحتية، أو الوصول إلى البيانات الحساسة، فهي تتطلب موافقاً منفصلاً لم يشارك في عملية الإنشاء. يجب أن يترك كل إجراء أثراً للتدقيق (audit trail). يجب أن تكون قادراً على إعادة تشغيل العملية لمعرفة أي الملفات تمت قراءتها بالضبط، وأي الأدوات تم استدعاؤها، وأي القرارات تم اتخاذها. التطوير القائم على الوكلاء (Agentic development) ليس رخصة لتخطي المراجعات. "الاحتكاك الممل" هو ميزة. تعمل بوابة الموافقة المناسبة مثل قاطع دائرة عندما تبدأ الأمور في الانحراف.
طابق الحدود مع مستوى المخاطر
عاير حدودك لتناسب الخطر الفعلي. إن تحويل كل تعديل بسيط في تنسيق Markdown إلى طقوس امتثال سيؤدي إلى توقف فريقك تماماً. لكن التعامل مع الإجراءات عالية المخاطر على أنها غير ضارة لأن الوكيل يبدو واثقاً هو أمر أحمق بنفس القدر. الهدف هو التحكم المتناسب، وليس التقييد الاستعراضي.
حافظ على المخرجات (Artifacts) صغيرة وقابلة للملاحظة
أنظمة الوكلاء الأكثر فائدة لا تحاول إبهارك بعمليات تشغيل ذاتية ضخمة، بل تنتج مخرجات صغيرة وقابلة للمراجعة. خطة محكمة. فرق (diff) مركز. سجل (log) مقروء. إن عمليات التنفيذ الذاتية العملاقة هي كوابيس عند تصحيح الأخطاء؛ فعندما يتعطل شيء ما بعد جلسة وكيل شملت خمسين ملفاً، يتعين عليك فك تشابك النية، والتنفيذ، والآثار الجانبية دفعة واحدة. حافظ على نطاق الضرر صغيراً. أصر على معرفة الملفات التي قرأها الوكيل والأدوات التي استدعاها. الأنظمة القابلة للمراقبة هي أنظمة قابلة للصيانة. أما الاستقلالية ذات الصندوق الأسود فليست سوى ديون تقنية مغلفة بتسويق أفضل.
ستة أسئلة قبل منح صلاحية الوصول
قبل أن تمنح أي وكيل أي مسؤولية حقيقية، اختبر إعداداتك بصرامة عبر ستة أسئلة صعبة.
- ما هي القدرات التي يمتلكها النظام فعلياً؟
- ما هي الإجراءات المرفوضة افتراضياً، والمحظورة على مستوى البنية التحتية بدلاً من مجرد التثنيع عنها بجملة مهذبة في تعليمات النظام (system prompt)؟
- ما هي الإجراءات التي تتطلب موافقة صريحة؟
- ما هي المخرجات التي يتم تجميدها قبل أن يستهلكها الوكيل، حتى لا يتمكن من التلاعب بمدخلاته بصمت؟
- أي مُحقق (validator)، منفصل تماماً عن المُنشئ (generator)، هو من يحكم على المخرج النهائي؟
- أي سجل (log) يثبت، دون أي غموض، ما حدث بالفعل؟
هذه هي أساسيات النظافة الهندسية. افصل المُنشئ عن المُحقق. وحافظ على السلطة البشرية عند الحدود.
الاختبار الحقيقي
هناك