جيفري هانتلي يعالج مشكلة وكلاء البرمجة بخطّاف pre-commit ويحصل على 10 من 10

وصف جيفري هانتلي أسلوبًا يقول إنه رفع التزام الوكيل بقاعدة داخلية إلى «عشرة من عشرة». لم يحاول إقناع النموذج بسطر إضافي في التعليمات، بل وضع خطّاف pre-commit في طريق الـcommit. نشر سايمون ويليسون اقتباسًا من مقاله «nobody should type code by hand anymore. here's what's left». المقياس هنا ذاتي، فالمؤلف لا يذكر منهجية القياس. لكن آلية العمل نفسها تستحق التحليل.

أين يفشل AGENTS.md

الموقف مألوف لكل من عمل مع وكلاء البرمجة. لدى المشروع مكتبة تشخيص خاصة به، وهي طبقة تغليف فوق أدوات المراقبة (observability). لكن الوكيل يستدعي وحدات observability مباشرة بدلًا منها. الحل البديهي هو إضافة قاعدة إلى AGENTS.md والأمل في أن يأخذ بها النموذج.

يشرح هانتلي لماذا لا يكفي ذلك. يمكن إجبار الوكيل على تحليل سلوكه وتحديث الملف، لكن تبقى فجوة («delta») بين التعليمات والممارسة الفعلية، وهذه الفجوة ستتحرك وتتسع. القواعد النصية احتمالية بطبيعتها: السياق يتضخم، والصياغات تتنافس فيما بينها، وقد يتغير النموذج أو إصداره. يبقى ملف التعليمات مجرد رجاء.

كيف يعمل الخطّاف

ينقل هانتلي القاعدة من النص إلى الكود. المخطط قصير:

• المحفّز: محاولة تنفيذ git commit.
• الفحص: يقرأ سكربت git diff ويبحث عن استدعاءات مباشرة لوحدات observability تتجاوز وحدة diagnostics.
• الاستجابة: عند وجود تطابق يفشل الـcommit.
• التغذية الراجعة: يُحقَن في الوكيل prompt يطالبه باستخدام diagnostics library.
• النتيجة بحسب تقدير المؤلف: عشرة من عشرة.

الحلقة الأخيرة هي الأهم. لو رُفض الـcommit دون توضيح، فقد يتجاوز الوكيل المشكلة بطريقة عشوائية. أما هنا فرسالة الخطأ تبيّن في الوقت نفسه ما الخلل وما المطلوب فعله. يتلقى الوكيل التصحيح في اللحظة التي يحتاج إليه فيها، لا في بداية الجلسة وسط مئات الأسطر من السياق.

والفحص في هذه الحالة حتمي (deterministic). فهو لا يعتمد على ما «يتذكره» النموذج من AGENTS.md، ويعمل بالطريقة نفسها مع أي نموذج وفي أي أداة وكيلية تنفّذ الـcommit عبر git.

كيف تطبّقه في مشروعك

الاستنتاج من نهج هانتلي هندسي. تنقسم قواعد الوكلاء إلى مجموعتين: قواعد يمكن التحقق منها آليًا وقواعد لا يمكن. الأولى ينبغي نقلها إلى الخطّافات (hooks) وأدوات الفحص (linters) وCI. أما الثانية، مثل الذوق المعماري ودقائق المجال المعرفي، فتبقى في AGENTS.md.

المرشحات للنقل واضحة فورًا: منع الاستدعاءات المباشرة التي تتجاوز الطبقة الداخلية، وإلزامية استخدام logger محدد، وطريقة موحدة للتعامل مع ملفات الإعداد، والتبعيات المحظورة. إذا أمكن اكتشاف المخالفة بتعبير نمطي (regex) أو بتحليل diff، فلا ينبغي أن تبقى في تعليمات نصية.

بعض التحفظات التي يجدر بك مراعاتها بنفسك (هذه اعتباراتي الشخصية وليست في الاقتباس):

• اكتب نص الخطأ على هيئة prompt: ما الذي وُجد، ولماذا لا يجوز، وبماذا يُستبدل.
• يمكن تجاوز الخطّاف المحلي بالخيار --no-verify، لذا من المعقول تكرار الفحص نفسه في CI.
• انتبه للإنذارات الكاذبة: إذا كان الخطّاف يحجب commits مشروعة، فسيبدأ الوكيل بـ«معالجة» الكود المحيط بالفحص لا جوهر المشكلة.
• احتفظ بعدّاد لمرات التفعيل. فهو يبيّن القواعد التي يخالفها الوكيل أكثر من غيرها، ويوفّر في الوقت نفسه المقياس الذي ينقص تقدير «10/10».

تصنيفا المنشور عند ويليسون، agentic-engineering وcoding-agents، يصفان الاتجاه بدقة. فالهندسة المحيطة بالوكيل، أي الخطّافات وعمليات الفحص والتغذية الراجعة، بدأت تعني بقدر ما يعنيه اختيار النموذج نفسه.