تجربتي مع Ponytail: وكيل برمجة يكتب أقل ويستخدم ما لديك

بقلم أحمد

طلب صغير من وكيل برمجة قد يتحول إلى مشروع أكبر مما تحتاج: طبقة جديدة، وحزمة إضافية، وملفات إعداد، وكود يعيد تنفيذ وظيفة موجودة أصلًا. تحصل على نتيجة تعمل، لكنك ترث معها شيئًا ستحتاج إلى فهمه واختباره وصيانته.

جرّبنا Ponytail، وأكثر ما لفت انتباهي أنه يميل إلى دفع وكيل البرمجة نحو ما هو متاح بالفعل: الحزم والمكوّنات داخل المشروع الذي يعمل عليه، أو حلول موجودة بدل بناء كل شيء من الصفر. بدا أحيانًا مثل مهندس برمجيات خبير وكسول: يريد إنهاء المهمة، لكنه لا يريد كتابة كود سيضطر إلى صيانته لاحقًا.

في تجربتي، لم تتغير جودة النتيجة كثيرًا في العادة، وأحيانًا حصلت على نتيجة أفضل. ولاحظت توفيرًا في التكلفة، لكنني لم أؤكد نسبة 70%، ولا أملك قياسًا منضبطًا يسمح لي بوعدك بنسبة محددة. هذه مراجعة لتجربة استخدام، وليست اختبار أداء مستقلًا بأرقام قابلة للتعميم.

إذا كنت تبرمج باستخدام Claude Code أو Codex أو Hermes، فأنا أنصحك بقوة بتجربة Ponytail. السبب الأساسي عندي هو طريقة اختيار الحل، وليس رقم توفير على غلاف مشروع.

المشكلة: الوكيل يعرف كيف يبني، لكنه قد يبني أكثر من اللازم

وكيل البرمجة يستطيع إنتاج ملفات كثيرة بسرعة. هذا مفيد عندما تحتاجها، ومزعج عندما تصبح كثرة الملفات بديلًا عن فهم المستودع.

قد تطلب حقلًا لاختيار تاريخ، فيبني تقويمًا كاملًا. وقد تطلب قراءة ملف CSV، فيضيف حزمة رغم وجود أداة مناسبة في المشروع أو في المكتبة القياسية. وقد تطلب إصلاح خطأ واحد، فيعيد تنظيم أجزاء لا علاقة لها بالمشكلة.

هذه أمثلة توضيحية للمشكلة، وليست مهامًا أدّعي أننا نفذناها في تجربتنا. لكنها تشرح سبب اهتمامي بالمشروع: أريد من الوكيل أن يقرأ ما حوله، ويفهم المطلوب، ويستفيد من الموجود قبل أن يقترح بناء شيء جديد.

إنتاج كود أكثر له تكلفة خارج جلسة النموذج. هناك وقت المراجعة، واختبارات الانحدار، وتوافق الحزم، وتحديثاتها، وطريقة اندماج الحل مع أسلوب الفريق. أحيانًا يكون الكود الجديد ضروريًا. المشكلة تبدأ عندما يضيفه الوكيل لأنه يستطيع، لا لأن المهمة تحتاجه.

ما Ponytail بالضبط؟

Ponytail مشروع يضع تعليمات لطريقة عمل وكيل البرمجة. جوهره ملف Skill، ومعه نسخة مختصرة في AGENTS.md وتكاملات لتحميل التعليمات داخل أدوات مختلفة.

لا يضيف نموذجًا جديدًا، ولا يستبدل Claude أو Codex أو النموذج الذي تشغّله عبر Hermes. ولا يضغط التوكنات تقنيًا على مستوى API. هو يوجّه قرارات الوكيل: ماذا يقرأ، وماذا يعيد استخدامه، ومتى يضيف كودًا، وكيف يشرح ما لم يتحقق منه.

المشروع يسمي هذا الأسلوب "lazy senior dev". المقصود بالكسل هنا تجنب العمل غير الضروري بعد فهم المشكلة. تعليماته تقول بوضوح إن على الوكيل إكمال كل ما تحتاجه المهمة، بما في ذلك المستدعون والاختبارات والإعدادات التي يتأثر بها التغيير.

وهناك فرق بين تثبيت Skill وتحميل إضافة كاملة. المهارة توفر التعليمات عندما يحملها الوكيل. أما بعض الإضافات، ومنها تكامل Hermes الموثق في المشروع، فتدخل وضع Ponytail النشط قبل كل دور للنموذج وتضيف أوامر للتحكم فيه. لا تفترض أن جميع طرق التثبيت تمنح السلوك والأوامر نفسها.

كيف يغيّر اختيار الحل؟

تعليمات Ponytail الحالية تبدأ بقراءة المهمة والكود الذي تمسه. قبل اختيار الحل، يحدد الوكيل أين يجب أن يصل التغيير: الدوال التي تستدعيه، والاختبارات، وملفات الإعداد، والواجهات أو الصادرات المرتبطة به.

بعد ذلك يستخدم ترتيبًا لاختيار أصغر تغيير ينجز المهمة كاملة:

يفحص إن كانت الأجزاء المطلوبة ضرورية، ويستبعد الميزات والمرونة التي لم يطلبها أحد.
يبحث عن حل موجود في قاعدة الكود: دالة مساعدة، أو مكوّن، أو خدمة، أو نمط مستخدم بالفعل.
يراجع المكتبة القياسية وميزات المنصة، مع احترام مكوّنات المشروع وأسلوبه.
يستخدم اعتمادًا مثبتًا إذا كان مناسبًا، ويتجنب إضافة حزمة جديدة من أجل بضعة أسطر.
يختار تعبيرًا بسيطًا يمكن فهمه مباشرة إذا كان ينجز المطلوب.
يكتب الحد الأدنى الضروري من الكود عندما لا تكفي الخيارات السابقة.

هذا الترتيب لا يأمره بالبحث في GitHub عن حزمة لكل مهمة. إعادة استخدام مكتبة خارجية خيار يحتاج حكمًا مستقلًا. الأولوية في القواعد المنشورة هي فهم المشروع والاستفادة مما يملكه بالفعل.

الفرق مهم: تنزيل حزمة جديدة قد يخفض عدد الأسطر التي تكتبها، لكنه يضيف اعتمادًا ستحتاج إلى الوثوق به وتحديثه. حل أصغر في المستودع ليس بالضرورة حلًا أقل تكلفة في الصيانة.

مثال المشروع: حقل تاريخ بدل تقويم مخصص

يعرض المستودع مثالًا من اختباره: مهمة إضافة منتقي تاريخ إلى واجهة أمامية. حسب التقرير، كتب الوكيل دون المهارة حلًا من 335 سطرًا، بينما استخدم Ponytail 5 مكوّن Input الموجود مع type="date" في ملف من 10 أسطر.

هذه أرقام صاحب المشروع، وليست قياسًا نفذناه نحن. فائدتها أنها تجعل الفكرة ملموسة: المتصفح يملك منتقي تاريخ، والمشروع يملك مكوّن إدخال. يمكن جمعهما بدل بناء تقويم.

لكن قرار إعادة الاستخدام يتوقف على المتطلبات. لو كنت تحتاج تقويمًا هجريًا محددًا، أو اختيار نطاق معقد، أو تصميمًا وسلوكًا لا توفرهما أداة المتصفح، فلا تكفي المقارنة بين 335 و10. عليك أولًا التحقق من أن الحل الأصغر يحقق الحاجة نفسها.

أريد من الوكيل أن يقلل العمل غير المطلوب، لا أن يعيد تعريف المهمة حتى يسهل عليه تنفيذها.

ما الذي لاحظته في تجربتنا؟

لاحظنا ميلًا إلى استخدام الحزم والحلول المتاحة بدل كتابة بدائل لها. شمل ذلك ما يجده الوكيل داخل المجلد أو المستودع الذي يعمل عليه، وكذلك التوجه إلى حلول موجودة على GitHub حين يراها مناسبة.

هذا وصف للسلوك الذي رأيناه، وليس ضمانًا بأن Ponytail سيختار المكتبة الصحيحة دائمًا، أو سيبحث على الويب في كل مرة. الوكيل نفسه، وصلاحياته، وأدوات البحث المتاحة له، وسياق المشروع، كلها تؤثر في قراره.

بالنسبة إلى النتيجة، لم أجد فرقًا كبيرًا في العادة. وأحيانًا كانت النتيجة أفضل. أرى أن تقليل إعادة الاختراع قد يساعد في ذلك، لكن هذا تفسير للملاحظة، لا إثبات لسبب التحسن.

لا أريد تحويل التجربة إلى أرقام غير موجودة. لا أعرض هنا عددًا محددًا للمهام أو إصدارًا موحدًا للنموذج أو سجل فواتير، ولذلك لا أصفها بأنها مقارنة إحصائية. ما يمكنني قوله هو أنني ارتحت أكثر لطريقة الوكيل عندما بدأ يفكر في إعادة الاستخدام وتقليل الكود الزائد.

توصيتي تأتي من هذا السلوك. المهارة جعلتني أهتم بالسؤال الذي يسبق كتابة الكود: هل نحتاج إلى بناء هذا الجزء أصلًا؟

التوفير: لاحظته، لكنني لم أؤكد 70%

أقل كود قد يعني توكنات إخراج أقل، ومراجعة أسهل، وأحيانًا جولات أقل. لكن هذه نتائج محتملة لطريقة العمل، وليست نسبة ثابتة يحققها ملف تعليمات.

في تجربتي لاحظت توفيرًا، لكنني لم أتحقق من 70%. لا أقدّم هذا الرقم باعتباره نتيجة اختباري، ولا أنسبه تلقائيًا إلى النسخة الحالية من المشروع.

عند مراجعة المستودع لإعداد المقال، يعرض تقرير Ponytail 5 المنشور في 7 أكتوبر 2026 انخفاضًا في التكلفة بنسبة 26% مقارنة بالوكيل دون المهارة، وانخفاضًا في توكنات الإخراج بنسبة 45%. كما يعرض انخفاضًا في حجم الكود وزمن التنفيذ. هذه أرقام منشورة من مطور المشروع في إعداد اختبار محدد، وليست وعدًا لنا أو لكل مستخدم.

والتكلفة ليست مرادفًا لتوكنات الإخراج. توجد مدخلات، وسياق، واستدعاءات أدوات، وتسعير يختلف بين النماذج، وتخزين مؤقت قد يغير الحساب. إذا كنت على اشتراك ثابت، فقد تلاحظ استخدامًا أقل من الحصة أو وقتًا أقل دون أن تنخفض فاتورتك الشهرية.

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

ماذا تثبت اختبارات المشروع، وماذا لا تثبت؟

التقرير المشار إليه يقارن الوكيل نفسه مع المهارة وبدونها، ويذكر 39 مهمة وخمس تشغيلات لكل مهمة ولكل مسار. ويضم مهامًا داخل مستودع FastAPI وReact، ومهامًا صغيرة لاختبار الصحة والأمان، وطلبات تطبيقات وأمثلة.

هناك حدود مهمة عند قراءة النتائج. التقرير يذكر أن Bash معطّل في جلسات الوكلاء داخل الاختبار؛ الوكلاء يكتبون الكود والاختبارات، ثم يشغّل إطار القياس الفحوصات لاحقًا. لذلك تختلف هذه البيئة عن جلسة برمجة يستطيع فيها الوكيل تشغيل الاختبار، ورؤية الخطأ، وإصلاحه بنفسه.

كما أن فحوص الصحة المخفية تخص جزءًا من المهام. لا يصح اعتبار كل انخفاض في عدد الأسطر دليلًا على جودة أعلى في كل التطبيقات. بعض تقييم الاكتمال يعتمد على حكم نموذج، وهو دليل يحتاج إلى قراءة منهجيته أيضًا.

أستخدم التقرير كدليل على أن الفكرة تستحق التجربة، لا كبديل عن اختبارها على مشروعي. وتبقى تجربة أحمد المذكورة هنا منفصلة عن هذا التقرير: ملاحظات استخدام دون نسبة توفير موثقة.

الكسل المفيد لا يحذف الاختبارات أو الأمان

أكثر ما لا أريد حدوثه هو أن يفسر الوكيل عبارة "اكتب أقل" على أنها إذن لحذف التحقق من المدخلات أو معالجة الأخطاء.

القواعد الحالية تمنع حذف التحقق عند حدود الثقة، ومعالجة الأخطاء التي تمنع فقد البيانات، والأمان، وإتاحة الاستخدام. وتطلب ترك اختبار صغير أو فحص ذاتي عندما يضيف الوكيل منطقًا غير بسيط، مثل فرع أو حلقة أو محلل نصوص، أو كود يتعامل مع المال أو الأمان.

هذا مهم عند دمج دوال أو نقل كود: يجب أن تنتقل معه معالجة الأخطاء والتحقق. لو استبدل الوكيل تنفيذًا أطول بآخر يتجاهل حالة خطرة، فأنت لم تحصل على تبسيط جيد.

مع ذلك، التعليمات لا تفرض صحة النتيجة تقنيًا. يمكن للنموذج أن يخالفها أو يسيء تطبيقها. راجع الفرق، وشغّل الاختبارات، وافحص مسارات الخطأ. واحتفظ بحدود واضحة لصلاحيات الوكيل، خصوصًا عندما يستطيع تعديل ملفات أو تثبيت حزم أو الاتصال بخدمات.

تثبيت Ponytail على Claude Code

الخطوات التالية من دليل المشروع الحالي. هي إرشادات للتثبيت، وليست إعلانًا بأننا أعدنا تنفيذ التثبيت على الأدوات الثلاث أثناء إعداد المقال.

داخل Claude Code، أرسل الأمر الأول كرسالة مستقلة:

/plugin marketplace add DietrichGebert/ponytail

ثم أرسل الأمر الثاني في رسالة أخرى:

/plugin install ponytail@ponytail

يشدد دليل المشروع على فصل الأمرين إلى رسالتين. الإضافة تستخدم lifecycle hooks صغيرة عبر Node.js، لذلك يجب أن يتوفر node في PATH الذي تراه الصدفة غير التفاعلية أيضًا، لا في نافذة الطرفية الحالية فقط.

بعد التثبيت، استخدم أمر المساعدة للتحقق من الأوامر، وابدأ تجربة في نسخة من مشروعك. راجع الإضافة والـhooks قبل منحها الثقة؛ تثبيت تعليمات من الإنترنت ليس قرارًا بلا أثر.

تثبيته على Codex

من الطرفية:

codex plugin marketplace add DietrichGebert/ponytail
codex plugin add ponytail@ponytail

ثم شغّل Codex، وافتح /hooks، وراجع الـlifecycle hooks الاثنين قبل الوثوق بهما. ابدأ محادثة جديدة بعد ذلك. وإذا كنت تستخدم تطبيق Codex المكتبي، يطلب دليل المشروع إعادة تشغيله بعد التثبيت.

الأوامر والمهارات في Codex تكون تحت مساحة اسم الإضافة. مثال المراجعة الموثق في README:

$ponytail:ponytail-review

قد تختلف واجهة اكتشاف المهارات بين الإصدارات. إذا لم تظهر أوامر plugin في نسختك، راجع التوثيق وإصدار أداتك بدل تكرار أمر غير مدعوم أو تحميل نسخة من مصدر آخر.

تثبيته على Hermes Agent

يوثق المشروع هذا الأمر:

hermes plugins install DietrichGebert/ponytail --enable

أعد تشغيل Hermes بالطريقة المعتادة لبيئتك بعد التثبيت. إضافة Ponytail الخاصة به تدخل الوضع النشط قبل كل دور للنموذج، وتضيف المهارات تحت أسماء مثل ponytail:<skill>، إلى جانب أوامرها.

يتوافق شكل الأمر مع واجهة تثبيت الإضافات في Hermes التي راجعناها أثناء إعداد المقال. هذا تحقق من صياغة الأمر والتوثيق، وليس اختبارًا بأن الإضافة تعمل في كل بيئة مستضافة.

إذا كنت تعمل عبر بوابة مشتركة، فاحصر صلاحية تغيير وضع Ponytail في المستخدمين الموثوقين. دليل المشروع يذكر أن حالة الوضع في هذا التكامل محلية للعملية؛ لا تتعامل معها كإعداد مستقل مضمون لكل مستخدم.

في الخدمات المُدارة، قد لا تملك صلاحية تثبيت إضافات أو إعادة تشغيل العملية. اتبع أدوات الإدارة التي يوفرها مضيفك، ولا تعدّل ملفات الخدمة الأساسية أو تفترض أن تعليمات الطرفية تنطبق حرفيًا.

خيار أبسط: قواعد المشروع بدل إضافة كاملة

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

يمكن تنزيل نسخة من المصدر للمراجعة:

git clone https://github.com/DietrichGebert/ponytail.git ponytail-source

اقرأ ponytail-source/AGENTS.md، ثم ادمج القواعد المناسبة مع تعليمات مشروعك. لا تستبدل AGENTS.md أو CLAUDE.md موجودًا دون مراجعة، فقد يحتوي أوامر الاختبارات وحدود الصلاحيات ومتطلبات الفريق.

في Hermes، تحميل ملف قواعد المشروع يتأثر بمكان بدء الجلسة وأولوية ملفات السياق. مثلًا، وجود .hermes.md قد يجعل AGENTS.md ليس المصدر الذي يحمّله. تحقق من الملف الفعلي الذي تقرؤه أداتك بدل الاكتفاء بوجوده على القرص.

القواعد وحدها لا تضيف كل أوامر الإضافة ولا hooks تفعيل الوضع. وهناك أيضًا خيار Skills CLI الموثق:

npx skills add DietrichGebert/ponytail

هذا يثبت المهارات في الأداة التي تختارها. حسب الدليل، تحتاج إلى قواعد المشروع أو الإضافة إذا أردت التعليمات الدائمة. لا تخلط بين تثبيت ملفات المهارات والتأكد من تحميلها فعلًا.

كيف تستخدمه بعد التثبيت؟

ابدأ بالوضع الافتراضي full بدل الانتقال مباشرة إلى أقوى مستوى. في الأدوات التي تدعم أوامر Ponytail مباشرة:

/ponytail full

الوضع lite يترك الوكيل يبني المطلوب ويذكر الخيار الأصغر لتقرر أنت. أما ultra فيسمح له بمناقشة الحاجة إلى أجزاء الطلب قبل تنفيذها. وقد يكون هذا مزعجًا إذا كانت المتطلبات محسومة أو إذا أردت نموذجًا أوليًا سريعًا. استخدم المستوى الذي يناسب طريقة عملك.

من الأوامر المتاحة حسب التكامل:

/ponytail-review لمراجعة التغيير، بما في ذلك الأخطاء والأمان والمستدعون المتأثرون.
/ponytail-audit لفحص المستودع وترتيب ما يحتاج إصلاحًا.
/ponytail-debt لجمع تعليقات shortcut: التي تسجل اختصارًا مقصودًا ووقت الحاجة إلى ترقيته.
/ponytail-help لمرجع الأوامر.
/ponytail off لإيقاف الوضع حيث يدعم التكامل ذلك.

الأمر /ponytail-gain يعرض لوحة الأثر المقاس من benchmark المشروع. لا تعتبر ظهوره قياسًا لفاتورتك أو نسبة توفير خاصة بمحادثتك.

وفي Codex استخدم مساحة اسم الإضافة كما يوضح دليله. أما طرق القواعد فقط، فقد تحمل التعليمات دون توفير هذه الأوامر أصلًا.

اطلب مهمة واضحة حتى لو كان الوكيل "خبيرًا كسولًا"

يمكن أن تبدأ بطلب من هذا النوع:

أضف الميزة المطلوبة داخل البنية الحالية للمشروع.
قبل كتابة كود جديد، افحص المكوّنات والدوال والحزم الموجودة.
لا تضف اعتمادًا جديدًا دون توضيح لماذا لا يكفي الموجود.
حافظ على التحقق ومعالجة الأخطاء، وشغّل الاختبارات المرتبطة بالتغيير.
في النهاية اذكر ما لم تختبره وأي حدود معروفة للحل.

هذا مثال للاستخدام، لا نتيجة اختبار نفذناه. فائدته أنه يجعل نطاق المهمة ومعيار الإنجاز واضحين. يمكن لـPonytail تقليل البناء الزائد، لكنه لا يعرف متطلباتك غير المكتوبة.

إذا كانت إعادة استخدام حزمة من GitHub جزءًا من الاقتراح، اسأل عن ترخيصها وصيانتها وتوافقها مع مشروعك، وما إذا كانت هناك حاجة حقيقية لإضافتها. لا تقبل اعتمادًا جديدًا لمجرد أنه يوفر أسطرًا.

كيف تعرف إن كان يفيد مشروعك؟

اختر مجموعة صغيرة من مهام حقيقية تستطيع تقييمها. استخدم نقطة بداية واحدة للمستودع، والنموذج والإعدادات نفسيهما، وشغّل المهام مع Ponytail وبدونه في جلسات منفصلة. كرر المقارنة لأن نتيجة الوكيل قد تختلف بين تشغيل وآخر.

سجّل ما تم تسليمه، وعدد جولات الإصلاح، والاختبارات التي نجحت، والتكلفة التي يبلغها مزودك، والوقت الذي قضيتَه في المراجعة. وافحص إن كان التغيير غطى كل المستدعين أم اكتفى بالملف الظاهر في الطلب.

هذا بروتوكول مقترح للقارئ، وليس وصفًا لاختبارنا السابق. لو وجدت كودًا أقل مع اختبارات ناقصة أو مهمة غير مكتملة، فلا تحسبه مكسبًا. ولو زادت تكلفة الجلسة قليلًا لكن اختفى عمل مراجعة وإصلاح كبير، فهذه نتيجة تستحق النظر أيضًا.

ابدأ على فرع تجريبي، وراجع Git diff قبل الدمج. لا تجعل اختبار أداة جديدة أول تجربة لها على بيانات إنتاج أو خدمات عملائك.

متى لا يكفي الحل الأصغر؟

أحيانًا يحتاج المشروع طبقة واضحة حتى لو زاد عدد الأسطر: صلاحيات دقيقة، أو معالجة معاملات مالية، أو أداء تحت حمل معروف، أو واجهة يجب أن تخدم مستخدمين ذوي احتياجات مختلفة.

في هذه الحالات، حدّد المتطلبات ومعايير القبول صراحة. لا تسمح للوكيل باستبعادها تحت عنوان تقليل التعقيد. وفي الوقت نفسه، لا تستخدمها مبررًا لبناء مرونة افتراضية لا تحتاجها الآن.

كما أن إعادة الاستخدام قد تبقيك على مكوّن قديم يحتاج إصلاحًا. وجود الكود في المستودع لا يجعله صحيحًا أو آمنًا. فحصه جزء من القرار، لا خطوة اختيارية بعد اختياره.

هل أنصح به؟

نعم. إذا كنت تعتمد على وكيل برمجة، أنصحك بتجربة Ponytail على Claude Code أو Codex أو Hermes بالطريقة المدعومة في بيئتك.

وجدت أن أثره على جودة النتيجة غالبًا ليس كبيرًا، وأحيانًا أفضل، بينما يدفع الوكيل نحو استخدام المتاح وتقليل إعادة الاختراع. ولاحظت توفيرًا، لكنني لم أؤكد 70% ولا أريد أن أبيعك هذه النسبة.

بالنسبة إلي، فائدته العملية أن الوكيل يبدأ من المشروع الذي أمامه بدل المشروع الذي يستطيع تخيله. ثبّته من المصدر الرسمي، وجرّبه على مهمة تعرفها، ثم احكم على اكتمال التغيير وسهولة صيانته معًا.

المصادر ونطاق هذه المراجعة

أقسام التجربة تعكس ملاحظاتي التي قدمتها لإعداد المقال، دون إضافة أرقام أو اختبارات لم أنفذها. وأقسام الآلية والتثبيت تستند إلى وثائق المشروع التي راجعناها في 10 أكتوبر 2026. المشروع سريع التغيير، لذلك راجع التعليمات قبل التثبيت.