ما هو Ponytail وكيف تجعل وكيل البرمجة يكتب كوداً أقل؟

ماهيّة Ponytail

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

المستودع هو DietrichGebert/ponytail. أُنشئ في 12 June 2026، وتجاوز 90,000 نجمة بحلول 1 August 2026. وفي 1 August 2026 كان أحدث إصدار موسوم هو v4.8.4، وقد نُشر في 29 June 2026، وكانت صفحة الإصدارات تعرض عشرة وسوم بين 14 و29 June وحدهما. ولم يتباطأ المشروع: في 17 October 2026 كان أحدث إصدار هو v5.3.2، وقد نُشر في وقت متأخر من 16 October، وكان ثالث إصدار في ذلك اليوم بعد v5.3.0 وv5.3.1. وقبل ذلك جاء v5.2.0 في 13 October، بعد خمسة أيام من إصدار v5.0.0 وv5.1.0 معاً في 8 October، ويعرض المستودع أكثر من 165,000 نجمة. سيتغير مشروع يتحرك بهذه السرعة قبل أن تقرأ هذا النص، لذلك ثبّت وسمًا قبل أن تبني أي شيء فوقه.

الفكرة قبل الأداة: توقف عند أول درجة ثابتة

جوهر Ponytail هو سلم اتخاذ القرار. يصعد الوكيل هذا السلم قبل كتابة أي شيء ويتوقف عند أول درجة ثابتة.

1. هل يجب أن يوجد هذا الشيء أصلاً؟ هذا هو مبدأ YAGNI (أنت لن تحتاج إليه). إذا كانت الإجابة لا، فتخطَّه.
2. هل هو موجود بالفعل في قاعدة الأكواد هذه؟ أعد استخدام المساعد أو النمط الموجود مسبقاً.
3. هل توفره المكتبة القياسية؟ استخدمها.
4. هل تغطيه ميزة أصلية في المنصة؟ استخدمها.
5. هل تحله تبعية مثبتة بالفعل؟ استخدمها.
6. هل يمكن أن يكون في سطر واحد؟ اجعله في سطر واحد.
7. فقط بعد ذلك، اكتب الحد الأدنى من الكود الذي يعمل.

هذا هو السلم كما هو مكتوب في v4.8.4، وأرقام الدرجات في بقية هذا المقال تتبعه. يدمج الفرع الرئيسي الحالي الدرجتين 3 و4 في درجة واحدة، "المكتبة القياسية أو ميزة المنصة؟ استخدمها، ما لم يكن للمشروع ميزته الخاصة"، ويضيف أن "مكون المشروع الداخلي يتفوق على الأداة الأصلية"، لذا فهو يحتوي على ست درجات. الترتيب هو نفسه.

الترتيب هو الذي ينجز العمل، وليس أي درجة بمفردها. الوكيل الذي يُطلب منه إنشاء منتقي تاريخ سيكتب منتقي تاريخ، لأن الكتابة هي ما أُمر بفعله. السلم يجعله يتحقق مما هو موجود بالفعل قبل أن يبني أي شيء: الدرجة 2 تسأل عما إذا كان المستودع يحتوي بالفعل على مكون لذلك، والدرجة 4 تقول إن المتصفح يحتوي بالفعل على <input type="date">. تشير معايير القياس الحالية للمشروع إلى هذه الحالة بالضبط: منتقي تاريخ كان يتكون من 335 سطراً بدون القاعدة، أصبح 10 أسطر مع Ponytail 5، لأن الوكيل أعاد استخدام مكون Input الخاص بالمستودع مع type="date" وترك المتصفح يوفر التقويم. تقلص منتقي الألوان بنسبة أقل، من 135 سطراً إلى 26. الدرجة 2 هي التي تفشل بصمت، لأن الوكيل الذي لا يستطيع رؤية المساعد الذي تملكه بالفعل سيكتب بكل سرور مساعداً ثانياً، وهي الفجوة التي تهدف خريطة قابلة للاستعلام لقاعدة أكوادك إلى سدها.

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

ما الذي يوفّره المستودع فعلياً

• AGENTS.md، مجموعة القواعد المطبّقة دائماً، وهي الفكرة كاملة في ملف واحد يمكنك قراءته خلال خمس دقائق.
• skills/ponytail/SKILL.md، تعريف المهارة، مع تلميح وسيطة هو lite أو full أو ultra أو off.
• ملفات القواعد ضمن أدلة خاصة بالمحررات، مثل .cursor/rules/ و.windsurf/rules/، للمضيفين الذين يقرؤون القواعد ولا يحمّلون المهارات.
• hooks/ وbenchmarks/ وexamples/ وscripts/.

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

تحصل المضيفات التي تدعم المهارات أيضاً على أوامر slash. يضبط /ponytail المستوى، ويتحقق /ponytail-review من وجود هندسة زائدة في diff، ويفحص /ponytail-audit مستودعاً كاملاً، ويجمع /ponytail-debt الاختصارات التي أجّلتها، بينما يطبع /ponytail-gain بطاقة نتائج القياس. تحصل المضيفات التي لا تقرأ إلا ملفات القواعد على مجموعة القواعد من دون أوامر. منذ v5.3.0، الذي صدر في 16 October 2026، يعرض Claude Code أيضاً شريطاً أعلى prompt يوضح تكلفة المهمة، وإعادة استخدام الكود، وحالة الاختبارات. يتطلب ذلك Claude Code 2.1.290 أو إصداراً أحدث، ولا يظهر في لوحة محادثة VS Code أو الجلسات السحابية أو claude -p، ويخفيه /ponytail band off. ومنذ v5.3.2، يقرأ /ponytail band import جلسات Claude Code السابقة مرة واحدة ويضيفها إلى اللوحة مع تكلفتها ووقت agent وعدد tokens فيها، حتى تتمكن من مقارنتها بالجلسات التي شُغّلت باستخدام القاعدة.

لقراءة المصدر قبل الوثوق به، استنسخ tag بدلاً من branch. هذا هو tag الذي تأتي منه السُّلَّمة أعلاه؛ استبدله بـ v5.3.2، وهو الأحدث في 17 October 2026، لقراءة الصياغة الحالية:

git clone --depth 1 --branch v4.8.4 https://github.com/DietrichGebert/ponytail.git

في Claude Code، يوثّق المشروع تثبيت plugin بدلاً من ذلك، وهذان السطران موثّقان كما هما في 17 October 2026:

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

يتبع مسار plugin الـdefault branch بدلاً من tag، لذلك قد تتغير التعليمات التي توجّه agent من جلسة إلى أخرى من دون تدخل منك. هذه هي المقايضة التي تقبلها مقابل سهولة استخدام أمر التحديث.

لماذا يُعد الوكيل "الكسول" أقل تكلفة على خادم VPS

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

تتم محاسبتك على الرموز (tokens) عند الإدخال والإخراج، لذا فإن الفرق الذي يبلغ نصف الحجم يكون أرخص بمرتين؛ مرة عند كتابته، ومرة أخرى في كل دور يعيد قراءته. يعتمد ما إذا كان هذا التوفير سينعكس على فاتورتك على طريقة الدفع، لأن اشتراك Pro أو Max يغطي الرموز الإضافية فقط حتى حدود الاستخدام المحددة، وبعدها يتم خصم رصيد الاستخدام الاختياري بشكل منفصل، بينما تحاسبك واجهة برمجة التطبيقات (API) على أساس كل رمز على حدة. إذا كنت تراقب الفاتورة في إعدادات ذاتية الاستضافة، فإن ملف التعليمات هو أداة تحكم لا تكلف شيئاً. تبدأ عملية التحكم في تكاليف وكيل الذكاء الاصطناعي من حجم المخرجات، ويوضح موضوع كيف ينفق وكيل البرمجة رموزه سبب أهمية إعادة القراءة أكثر مما يتوقع الناس.

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

على الخادم، تتغير المخاطر لأن الوكيل يعمل غالباً دون مراقبة. الوكيل الذي يعمل داخل جلسة tmux أو عبر مؤقت لديه ساعات للبناء على قرار خاطئ قبل أن تراه. هذه هي المخاطرة العملية في تشغيل وكيل برمجة على خادم VPS، وهذا هو السبب في أن الأشخاص الذين يمارسون هندسة الحلقات (loop engineering) يولون اهتماماً كبيراً للتعليمات الدائمة بدلاً من المطالبات الفردية. القاعدة الموجودة في ملف التعليمات الدائم تطبق على الدور رقم 200. أما القاعدة التي كتبتها في الدردشة فتطبق على الدور رقم 3 فقط. كما أنها تطبق على الجلسة الثانية التي تبدأها على نفس الجهاز، والتي تقرأ الملف المعتمد ولكنها لا ترث أي شيء كتبته في الجلسة الأولى، حتى عندما تستطيع الجلستان مراسلة بعضهما البعض.

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

ما تقوله أرقام قياس أداء Ponytail الخاصة

نشر المشروع نوعين من النتائج، وهما يختلفان عن بعضهما بهامش كبير. كلاهما أرقام منشورة من قبل المشروع نفسه، ولا يُعد أي منهما اختباراً مستقلاً.

[
  {
    "label": "Lines of code",
    "v4_13_pct": 48,
    "v5_pct": 53
  },
  {
    "label": "Cost per run",
    "v4_13_pct": 16,
    "v5_pct": 26
  },
  {
    "label": "Wall clock time",
    "v4_13_pct": 38,
    "v5_pct": 41
  }
]

هذا الرسم البياني هو معيار الأداء الوكيل الحالي للمشروع، بتاريخ 7 أكتوبر 2026. عملت جلسات Claude Code 2.1.288 بدون واجهة (Headless) على نموذج Opus 5.5 بمستوى الجهد الافتراضي عبر 39 مهمة، مع خمس جولات لكل مهمة ولكل مسار، بإجمالي 585 جلسة عبر "بدون مهارة"، وPonytail v4.13.0، وPonytail 5. اثنتا عشرة من هذه المهام هي تذاكر ميزات في مستودع full-stack-fastapi-template الخاص بـ tiangolo، وهو مستودع حقيقي لـ FastAPI وReact، وتم تقييمها بناءً على git diff المتبقي. أما البقية فهي 18 مهمة جراحية مع فحوصات مخفية، وست طلبات لتطبيقات صغيرة، وثلاثة طلبات من نوع "أرني مثالاً". تم تعطيل Bash لكل المسارات. انخفضت رموز المخرجات (Output tokens) بنسبة 45 بالمئة مع Ponytail 5.

قارن ذلك بأرقام المحاولة الواحدة (single shot) التي نشرها المشروع في يونيو 2026. جاءت تلك الأرقام من نموذج مجرد يجيب على خمسة استعلامات يومية مع وبدون القاعدة، وتم الإبلاغ عنها كقيم وسيطة (medians) عبر جولات متكررة. أظهرت تلك الأرقام انخفاضاً في الكود بنسبة 80 إلى 94 بالمئة عبر نماذج Haiku وSonnet وOpus، ووضع التحقق من التكلفة بتاريخ 17 يونيو 2026 نموذج Haiku في مرتبة أرخص بنسبة 63 بالمئة. النتيجة الوكيلية الحالية لـ Ponytail 5 هي 53 بالمئة أسطر كود أقل، و26 بالمئة تكلفة أقل، و41 بالمئة وقت تنفيذ أقل. صحح المشروع رقم المحاولة الواحدة بسرعة. بحلول v4.8.4، في 29 يونيو 2026، تصدّر ملف README بالفعل النتيجة الوكيلية، "~54% أقل كود (تصل إلى 94%)"، مع ملاحظة أن نسبة 80 إلى 94 بالمئة السابقة كانت "السقف لكل مهمة، وليس المتوسط"، وكان قد نقل أرقام المحاولة الواحدة إلى قسم مطوي بعنوان "أرقام المحاولة الواحدة القديمة". كان ذلك القسم صادقاً بشأن سبب وجود الفجوة: خط أساس المحاولة الواحدة هو نموذج مجرد "يحشو إجابته بالنثر والخيارات"، وهو أمر يسهل التفوق عليه. قِس الأداء مقابل وكيل حقيقي يقوم بعمل حقيقي وستتقلص المكاسب. لكنها تظل حقيقية، وهي الحقيقة الأكثر فائدة. تلك الجولة الوكيلية في يونيو، التي شملت اثنتي عشرة تذكرة على Haiku 4.5 مع أربع جولات لكل منها، كانت قد وصلت إلى نتيجة قريبة من رقم اليوم بنسبة 54 بالمئة أسطر أقل، ولم يعد ملف README الحالي يحمل أرقام المحاولة الواحدة على الإطلاق.

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

النمط الذي يمكنك نسخه اليوم دون تثبيت أي شيء

السلم عبارة عن نص، لذا لا تحتاج إلى إضافة لاستخدام هذه الفكرة. انسخ كتلة مثل هذه في ملف التعليمات الذي يقرؤه وكيلك بالفعل، سواء كان ذلك AGENTS.md أو CLAUDE.md أو ملف قواعد المحرر الخاص بك.

## Before you write code

Climb this list in order. Stop at the first line that applies.

1. Does this need to exist? If not, say so and stop.
2. Does this repo already have it? Reuse the helper.
3. Does the standard library do it? Use it.
4. Does the platform do it natively? Use it.
5. Does an installed dependency do it? Use it.
6. Can it be one line? Write one line.
7. Otherwise write the minimum that works.

Never take the shortcut on: reading the code before changing it, validating
input that crosses a trust boundary, error handling that would otherwise lose
data, security, accessibility, or anything I asked for by name.

Do not add an abstraction I did not ask for. Do not add a dependency without
saying why in one line. Prefer deleting code to adding it.

Mark a deliberate simplification with a comment naming its ceiling and the
upgrade path.

تستحق القاعدة الأخيرة أن تُؤخذ بمفردها. اصطلاح Ponytail في إصداراتها الحالية هو تعليق موسوم بـ shortcut: يحدد الحد الأقصى وموعد الترقية (إصدارات يونيو، بما في ذلك v4.8.4، وسمته بـ ponytail: بدلاً من ذلك):

# shortcut: global lock, per-account locks if throughput matters

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

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

حيث تتوقف القاعدة عن كونها صائبة

صُمم هذا السلم للعمل على الميزات في قاعدة برمجية موجودة مسبقاً، حيث تكون إعادة الاستخدام متاحة وعادة ما تكون هي الخيار الصحيح. وهو أقل ملاءمة للمشاريع الجديدة (greenfield)، لأن الدرجة 2 لا تجد ما تعيد استخدامه، والدرجة 5 لا تجد شيئاً مثبتاً. لا يزال بإمكان الوكيل التوقف عند الدرجة 1، أو المكتبة القياسية، أو ميزة في المنصة، أو سطر برمجي واحد، لكن مخرجين من أرخص المخارج قد اختفيا، مما يؤدي إلى سقوط المزيد من المهام في فخ كتابة كود جديد. كما أنه لا يتناسب جيداً في اللحظة التي تحتاج فيها حقاً إلى التجريد (abstraction). إذا كنت على وشك إضافة المستدعي الرابع لنفس الكتلة المنسوخة، فإن "أقصر فرق" (shortest diff) سيقدم لك نسخة خامسة.

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

لا توجد كتلة تعليمات تحميك من القراءة الخاطئة للمشكلة. العنصر الأول في مجموعة القواعد نفسها هو فهم الكود قبل اتخاذ القرار، وهذا هو الجزء المكلف والجزء الذي لا يمكن للنص القيام به نيابة عنك. إن أقل فرق (minimal diff) في الوظيفة الخطأ يظل إصلاحاً خاطئاً، وهو الآن إصلاح خاطئ صغير يسهل الموافقة عليه.

الملخص الصادق هو أن Ponytail عبارة عن مطالبة (prompt) مكتوبة بعناية، وموزعة بشكل جيد، ومرفقة بأرقام. لا شيء فيها يتطلب إضافة برمجية (plugin). ما يقدمه لك المشروع هو أن شخصاً ما كتب القائمة بشكل صحيح، واختبرها مقابل مستودع حقيقي، ونشر الطريقة بجانب النتيجة.

FAQ

هل يعمل Ponytail مع وكلاء غير Claude Code؟

نعم. يتم شحن الأداة كمهارة للمضيفين الذين يدعمون تحميل المهارات، وهي قائمة تشمل Claude Code وCodex وOpenCode وGemini وعدة أسماء أخرى مذكورة في ملف README. أما المحررات التي تقرأ ملفات القواعد دون تحميل المهارات، مثل Cursor وWindsurf وCline وCopilot، فهي تأخذ مجموعة القواعد الدائمة من دليل القواعد المطابق ولا تحصل على أوامر slash. النص هو نفسه في كلتا الحالتين، لذا يكمن الفرق الحقيقي في ما إذا كان المضيف يحتفظ بهذا النص في السياق في كل دورة أم فقط عند تفعيل المهارة.

هل سيتجاهل الوكيل الكسول الاختبارات أو التحقق أو الأمان؟

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

هل أرقام السرعة والتكلفة المنشورة موثوقة؟

هي قياسات المشروع الخاصة، ومنشورة مع منهجيتها، ويجب قراءتها على هذا الأساس. أرقام المحاولة الواحدة من يونيو 2026 تمت مقارنتها بنموذج خام كان يملأ إجابته بالنثر والخيارات، وهو ما أشار إليه ملف README في ذلك الوقت كخط أساس ضعيف. أرقام الوكلاء الحالية تأتي من جلسات Claude Code بدون واجهة رسومية على Opus 5.5، عبر 39 مهمة بخمس جولات لكل منها، اثنتا عشرة منها كانت تذاكر ميزات في مستودع واحد لـFastAPI وReact. هذه أرقام صادقة لهذا الإعداد. إنها ليست توقعاً لقاعدة برمجياتك، لأن نتائج المشروع لكل مهمة تظهر انخفاض التوفير إلى ما يقرب من الصفر في الأكواد التي كانت بالفعل في حدها الأدنى.

هل أحتاج إلى تثبيت أي شيء للحصول على الفائدة؟

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

كيف أمنع الوكيل غير المراقب من الإفراط في البناء طوال الليل؟

ضع القاعدة في ملف التعليمات الدائم بدلاً من رسالة الدردشة، بحيث تُطبق في الدورة 200 من تشغيل طويل وليس فقط في الدورة 3. ثم حدد الضرر بشكل منفصل: امنح الوكيل نسخة (checkout) يُسمح له بإفسادها بدلاً من نسختك الوحيدة، واطلب مراجعة بشرية لـdiff قبل دمج أي شيء. قاعدة diff الدنيا تقلل من حجم ما يجب عليك قراءته. هي لا تقرر ما يتم اعتماده، ولا ينبغي لها ذلك.