Ponytail: איך לגרום לסוכן AI לכתוב פחות קוד

מהו Ponytail

Ponytail הוא מערך כללים שגורם לסוכן AI לכתיבת קוד לכתוב פחות קוד. הפרויקט מתאר את עצמו במשפט אחד: "גורם לסוכן ה-AI שלך לחשוב כמו המפתח הבכיר העצלן ביותר בחדר. הקוד הטוב ביותר הוא הקוד שמעולם לא כתבת." הרישיון שלו הוא MIT. אין לו סביבת ריצה משלו, ושום דבר בתוכו אינו מבוצע. זהו טקסט שנכנס להנחיות הסוכן, ונארז כמיומנות עבור מארחים שטוענים מיומנויות, וכקובצי כללים רגילים עבור מארחים שאינם עושים זאת.

המאגר הוא DietrichGebert/ponytail. הוא נוצר ב-12 ביוני 2026 והגיע ל-90,000 כוכבים עד 1 באוגוסט 2026. הגרסה המתויגת האחרונה ב-1 באוגוסט 2026 היא v4.8.4, פורסמה ב-29 ביוני 2026, ודף הגרסאות מציג עשרה תגיות בין 14 ל-29 ביוני בלבד. פרויקט שמתקדם בקצב כזה ישתנה עד שתקראו זאת, לכן יש לנעול תגית לפני שבונים עליו דבר כלשהו.

הרעיון לפני הכלי: עוצרים בדרגה הראשונה שמתקיימת

הליבה של Ponytail היא סולם החלטות. הסוכן עובר עליו לפני שהוא כותב משהו, ועוצר בדרגה הראשונה שמתקיימת.

1. האם הדבר הזה בכלל צריך להתקיים? זהו YAGNI (לא תזדקקו לזה). אם התשובה היא לא, מדלגים עליו.
2. האם הדבר כבר קיים בבסיס הקוד הזה? משתמשים מחדש בעזר או בתבנית שכבר קיימים.
3. האם הספרייה הסטנדרטית מבצעת את הפעולה? משתמשים בה.
4. האם תכונה מובנית של הפלטפורמה נותנת מענה? משתמשים בה.
5. האם תלות שכבר מותקנת פותרת את הבעיה? משתמשים בה.
6. האם אפשר לכתוב זאת בשורה אחת? כותבים זאת בשורה אחת.
7. רק אז כותבים את כמות הקוד המזערית שעובדת.

סדר השלבים הוא שמבצע את העבודה, ולא שלב יחיד. סוכן שהתבקש ליצור בורר תאריכים יכתוב בורר תאריכים, משום שזה מה שנדרש ממנו. הסולם מאלץ אותו לבדוק תחילה את דרגה 4, ודרגה 4 מציינת שבדפדפן כבר קיימת <input type="date">. הערות ההשוואה של הפרויקט עצמו מתעדות בדיוק את המקרה הזה: בורר תאריכים שהגיע ל-404 שורות ללא הכלל הסתכם ב-23 שורות איתו, משום שהסוכן בחר בקלט המובנה במקום לבנות רכיב. בורר צבעים הצטמצם מ-287 שורות ל-23 מאותה סיבה.

עצלות כאן אינה חוסר זהירות, ומערכת הכללים מציינת זאת ישירות. הרשימה שלה של הדברים שאין לנהוג בהם בעצלות כוללת הבנת הבעיה לפני קבלת החלטה, אימות קלט בגבולות אמון, טיפול בשגיאות שמונע אובדן נתונים, אבטחה, נגישות וכל דבר שביקשתם במפורש. היא גם דורשת בדיקה קטנה וניתנת להרצה אחת לכל פיסת לוגיקה שאינה פשוטה. הכלל מצמצם המצאות. הוא אינו פוגע בנכונות.

מה המאגר מפיץ בפועל

• AGENTS.md, ערכת הכללים שפועלת תמיד. זהו כל הרעיון בקובץ אחד שאפשר לקרוא בתוך חמש דקות.
• skills/ponytail/SKILL.md, הגדרת היכולת, עם רמז ארגומנט של lite, full או ultra.
• קובצי כללים בתיקיות ייעודיות לעורכים, כגון .cursor/rules/ ו-.windsurf/rules/, עבור מארחים שקוראים כללים אך אינם טוענים יכולות.
• hooks/, benchmarks/, examples/ ו-scripts/.

ארגומנט העוצמה משנה את מידת התקיפות של הכלל. lite בונה את מה שביקשת ומציין בשורה אחת אפשרות עצלה יותר. full היא ברירת המחדל ואוכפת את הסולם. ultra היא הגדרת הקיצוניות של YAGNI: היא מעדיפה מחיקה על פני הוספה ותתווכח אפילו עם הדרישה עצמה.

מארחים שתומכים ביכולות מקבלים גם פקודות לוכסן. /ponytail מגדירה את הרמה, /ponytail-review בודקת diff לאיתור הנדסת-יתר, /ponytail-audit בודקת מאגר שלם, /ponytail-debt אוספת את קיצורי הדרך שדחית, ו-/ponytail-gain מציגה את דוח ציוני ההשוואה. מארחים שקוראים קובצי כללים בלבד מקבלים את ערכת הכללים ללא פקודות.

כדי לקרוא את קוד המקור לפני שנותנים בו אמון, יש לשכפל את התג ולא את הענף:

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

ב-Claude Code מתועד במקום זאת תהליך התקנה של plugin, ושתי השורות האלה תואמות לתיעוד נכון ל-1 באוגוסט 2026:

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

נתיב ה-plugin עוקב אחר ענף ברירת המחדל ולא אחר תג. לכן ההוראות שמכוונות את הסוכן עשויות להשתנות ללא הודעה בין הפעלות. זו הפשרה שמקבלים תמורת הנוחות של פקודת עדכון.

מדוע סוכן שאינו פועל ללא צורך יקר פחות ב-VPS

השינויים שסוכן כותב אינם יוצאים מהשיחה. בתור הבא הם הופכים להקשר שהמודל קורא שוב, יחד עם כל קובץ שהוא פתח כדי ליצור אותם. לכן שינוי של 500 שורות מכביד על כל תור מאוחר יותר בסשן, ולא רק על התור שבו הוא נוצר. זו הסיבה ש-refactor שיצא משליטה גורם לסוכן להרגיש איטי ופחות חכם ככל שהסשן מתקדם: החלון מתמלא בפלט של הסוכן עצמו, ולכן המקום שנותר לקוד שלכם מצטמצם. ניהול חלון ההקשר של סוכן קידוד עוסק בשליטה בכך.

על tokens מחייבים הן עבור קלט והן עבור פלט, ולכן diff שגודלו חצי מהגודל המקורי זול פי שניים: פעם אחת בעת כתיבתו, ושוב בכל תור שבו הוא נקרא מחדש. אם אתם עוקבים אחר החשבון בסביבה בניהול עצמי, קובץ ההנחיות הוא מנוף שאפשר להפעיל ללא עלות. שליטה בעלות של סוכן AI עבורכם מתחילה בהיקף הפלט, ו-האופן שבו סוכן קידוד משתמש ב-tokens שלו מסביר מדוע לקריאה מחדש יש השפעה גדולה מהצפוי.

אדם עדיין קורא את ה-diff. שינוי של 400 שורות שהיה אמור להיות בן 20 שורות גוזל את תשומת לבו של הסוקר, ותשומת הלב היא המשאב שמתכלה ראשון. איש אינו בודק את ה-diff הארוך הרביעי באותו יום באותה מידת הקפדה שהקדיש לראשון, ולכן בנייה מעבר לנדרש אינה רק בזבוז זמן. היא מפחיתה בהדרגה את איכות הבדיקה שאמורה לאתר את השגיאות.

בשרת הסיכון משתנה, משום שהסוכן פועל לעיתים קרובות ללא השגחה. סוכן שעובד בסשן tmux או באמצעות טיימר יכול להמשיך במשך שעות על בסיס החלטה שגויה לפני שתראו אותה. זהו הסיכון המעשי ב-הפעלת סוכן קידוד ב-VPS, ולכן אנשים העוסקים ב-הנדסת לולאות משקיעים תשומת לב רבה כל כך בהנחיות הקבועות, ולא רק בהנחיות בודדות. כלל בקובץ שתמיד נטען חל על תור 200. כלל שהקלדתם בצ'אט חל על תור 3.

תלויות חדשות הן העלות השקטה הנוספת. כלל 5 קובע שיש להשתמש במה שכבר מותקן. כל חבילה שסוכן מוסיף ביוזמתו היא דבר שתצטרכו לעדכן בהמשך, והיא תיכלל בכל image של container שתבנו מאותו repository.

מה אומרים נתוני ההשוואה של Ponytail עצמו

הפרויקט מפרסם שתי קבוצות תוצאות, והן שונות זו מזו בפער ניכר. שתי הקבוצות מבוססות על נתונים שהפרויקט עצמו פרסם. אף אחת מהן אינה בדיקה בלתי תלויה.

[
  {
    "label": "Lines of code",
    "single_shot_pct": 93,
    "agentic_pct": 54
  },
  {
    "label": "Cost per run",
    "single_shot_pct": 63,
    "agentic_pct": 20
  },
  {
    "label": "Wall clock time",
    "single_shot_pct": 74,
    "agentic_pct": 27
  }
]

העמודה של ירייה יחידה מבוססת על מודל בסיסי שמשיב על קבוצה קטנה של הנחיות, עם הכלל ובלעדיו, כאשר הנתונים מוצגים כחציונים של הרצות חוזרות מתאריכים 13 ו-17 ביוני 2026. העמודה הסוכנית מבוססת על הפעלה ללא ממשק גרפי של Claude Code, שערכה את full-stack-fastapi-template של tiangolo, מאגר FastAPI ו-React אמיתי, עבור 12 כרטיסי תכונות, עם 4 הרצות לכל כרטיס ב-Haiku 4.5. ההערכה נעשתה לפי השינויים שנותרו ב-git diff.

התבוננו בעמודה השנייה. התוצאה הסוכנית דורשת 54 אחוזים פחות שורות קוד, עולה 20 אחוזים פחות, ודורשת 27 אחוזים פחות זמן שעון, לעומת 93 אחוזים ו-74 אחוזים, בהתאמה, עבור אותם מדדים בתצורת הירייה היחידה. קובץ ה-README מסביר בכנות מדוע: קו הבסיס של הירייה היחידה הוא מודל בסיסי ש"משיב בכמה אפשרויות ובתוספת הסברים", ולכן קל להתעלות עליו. כאשר משווים לסוכן אמיתי שמבצע עבודה אמיתית, היתרון מצטמצם. עם זאת, הוא עדיין קיים, וזה הנתון השימושי יותר.

יש הסתייגות אחת שמגיעה מהפרויקט עצמו, והיא שקובעת אם הדבר יסייע לכם. החיסכון הגדול ביותר מתקבל במקומות שבהם קיימת מלכודת אמיתית של מימוש יתר, והוא כמעט אפסי בקוד שכבר היה מינימלי. 12 כרטיסים במאגר אחד של Python ו-TypeScript אינם מנבאים את התוצאות במאגר שלכם. אם הנתון חשוב לכם, הריצו את ההשוואה על הכרטיסים שלכם, עם הכלל ובלעדיו, וספרו את השורות בעצמכם.

התבנית שאפשר להעתיק כבר היום בלי להתקין דבר

המדרג הוא טקסט, ולכן אין צורך בתוסף כדי להשתמש ברעיון. הדביקו בלוק כזה בקובץ ההנחיות שהסוכן שלכם כבר קורא, בין אם זה 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 היא הערה המסומנת בשם הכלי:

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

ההערה מבהירה שתי נקודות עבודה ומכריעה שאלה שאחרת הייתה מחייבת סבב בדיקה. היא מציינת לקורא הבא שהגרסה הפשוטה הייתה החלטה, ומגדירה את התנאי שבו החלטה זו מפסיקה להיות תקפה. בלעדיה, בודק אינו יכול להבחין בין קיצור דרך שנבחר במכוון לבין דבר שהסוכן שכח, ולכן עליו לשאול.

למיקום הבלוק יש חשיבות זהה לתוכן שלו. קובץ שהסוכן טוען בכל הרצה משפיע על כל הרצה, כולל הרצות שאינכם עוקבים אחריהן. ההבדל הזה הוא נושא כתיבת AGENTS.md שהסוכן שלכם אכן מציית לו, והוא הסיבה לכך שהתבנית הזו צריכה להופיע בקובץ שנשמר במאגר, ולא בהיסטוריית המעטפת שלכם.

היכן הכלל מפסיק להיות נכון

הסולם מותאם לעבודה על תכונות בקוד קיים, שבו בדרך כלל אפשר לעשות שימוש חוזר ברכיבים קיימים, ובדרך כלל זו גם הבחירה הנכונה. הוא מתאים פחות לפרויקט חדש לחלוטין, משום שבשלב 2 אין דבר שאפשר לעשות בו שימוש חוזר, ובשלב 5 אין דבר מותקן. לכן הסוכן מגיע בכל פעם לשלב 7. הוא גם מתאים פחות למצב שבו אתם באמת רוצים את ההפשטה. אם אתם עומדים להוסיף את המשתמש הרביעי לאותו קטע קוד שהועתק, "הפרש הקוד הקצר ביותר" ייצור עבורכם עותק חמישי.

רמת ultra תאתגר את הדרישות שלכם. לשם כך נועדה הרמה, וזו עלות ממשית כאשר כבר קיבלתם את ההחלטה ואתם רוצים שהעבודה תתבצע. השתמשו ב-full לעבודה רגילה, ופנו ל-ultra כאשר אתם חושדים שבקשת התכונה היא הבעיה.

שום בלוק הוראות לא יגן עליכם מפני הבנה שגויה של הבעיה. הפריט הראשון של מערכת הכללים עצמה הוא להבין את הקוד לפני שמחליטים, וזהו החלק היקר — והחלק שהטקסט אינו יכול לבצע במקומכם. הפרש קוד מזערי בפונקציה הלא נכונה הוא עדיין תיקון שגוי, וכעת זהו תיקון שגוי קטן שקל לאשר.

הסיכום הכנה הוא ש-Ponytail הוא prompt שנכתב בקפידה, מופץ היטב, ומצורפים אליו מספרים. שום דבר בו אינו מחייב את התוסף. מה שהפרויקט מספק הוא שמישהו כתב את הרשימה כראוי, בדק אותה מול מאגר קוד אמיתי ופרסם את השיטה לצד התוצאה.

FAQ

האם Ponytail עובד עם סוכנים שאינם Claude Code?

כן. הוא מופץ כ-skill עבור hosts שטוענים skills. הרשימה כוללת את Claude Code, Codex, OpenCode, Gemini ועוד כמה מוצרים המוזכרים ב-README. עורכים שקוראים קובצי כללים אך אינם טוענים skills, כגון Cursor, Windsurf, Cline ו-Copilot, מקבלים את ruleset שתמיד פעיל מתוך ספריית הכללים המתאימה, אך אינם מקבלים פקודות slash. הטקסט זהה בשני המקרים. ההבדל בפועל הוא אם ה-host משאיר את הטקסט בהקשר בכל תור, או רק כאשר skill מופעל.

האם agent עצל ידלג על בדיקות, על אימות או על אבטחה?

לא. ה-ruleset מציין זאת במפורש. הרשימה שלו, שכותרתה "never lazy about", כוללת אימות קלט בגבולות אמון, טיפול בשגיאות שמונע אובדן נתונים, אבטחה ונגישות. בנוסף, היא דורשת בדיקה קטנה אחת שניתנת להרצה עבור כל פיסת לוגיקה שאינה טריוויאלית. הכלל מסיר מבנה מומצא: הפשטות שאיש לא ביקש והתלויות שאיש לא היה צריך. אם ה-agent מתחיל להשמיט בדיקות לאחר התקנתו, הסיבה היא הוראה אחרת בתצורה שלכם שגוברת על הוראה זו. לכן יש לקרוא את הקובץ שה-agent טוען אחרון.

האם אפשר לסמוך על נתוני המהירות והעלות שפורסמו?

אלה מדידות של הפרויקט עצמו, שפורסמו יחד עם השיטה שבה בוצעו. יש לקרוא אותן בהתאם. נתוני ההרצה היחידה משווים למודל בסיסי שמחזיר אפשרויות והסברים. ה-README עצמו מציין שזהו קו בסיס חלש. נתוני ההרצות עם agent נוצרו בסשן headless של Claude Code, במאגר אחד של FastAPI ו-React, עם twelve כרטיסי עבודה וארבע הרצות לכל כרטיס, באמצעות Haiku 4.5. אלה נתונים אמינים עבור תצורה זו. הם אינם תחזית עבור בסיס הקוד שלכם, משום שהפרויקט מציין גם שהחיסכון יורד כמעט לאפס בקוד שכבר היה מינימלי.

האם עליי להתקין משהו כדי להפיק את התועלת?

לא. ה-ladder הוא טקסט, והדבקת בלוק מקביל בקובץ ההוראות שה-agent כבר קורא תספק את רוב ההשפעה. ה-plugin מספק ניסוח מתוחזק, רמות עוצמה, פקודות סקירה ונתיב לעדכונים. ניסיון עם הבלוק שהועתק הוא התשובה של rung 1 לשאלה אם ההתקנה נחוצה בכלל.

כיצד מונעים מ-agent ללא השגחה לבנות יותר מדי במהלך הלילה?

יש להוסיף את הכלל לקובץ ההוראות שתמיד נטען, ולא להסתמך על הודעת chat. כך הוא יחול בתור 200 של הרצה ארוכה, ולא רק בתור 3. לאחר מכן יש להגביל את הנזק בנפרד: יש לספק ל-agent checkout שמותר לו לפגוע בו, במקום את העותק היחיד שלכם, ולדרוש סקירת diff אנושית לפני מיזוג כלשהו. כלל diff מינימלי מצמצם את כמות החומר שעליכם לקרוא. הוא אינו קובע מה ייכנס, וגם לא אמור לקבוע זאת.