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

מהו Ponytail

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

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

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

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

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

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

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

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

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

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

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

כדי לקרוא את קוד המקור לפני שנותנים בו אמון, יש לשכפל את ה־tag ולא את ה־branch:

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

ב־Claude Code הפרויקט מתעד התקנת plugin במקום זאת, ושתי השורות האלה תואמות לתיעוד כפי שהיה ב־1 August 2026:

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

נתיב ה־plugin עוקב אחר ה־branch הראשי ולא אחר tag, ולכן ההנחיות שמכוונות את ה־agent עשויות להשתנות במהלך העבודה בין sessions. זו הפשרה שמקבלים תמורת הנוחות של פקודת עדכון.

מדוע agent עצלן זול יותר ב־VPS

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

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

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

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

תלויות חדשות הן העלות השקטה הנוספת. כלל 5 אומר להשתמש במה שכבר מותקן. כל חבילה ש־agent מוסיף מיוזמתו היא דבר שתצטרכו לתחזק בהמשך, והיא תיכלל בכל container image שתבנו מאותו 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 — באמצעות שנים־עשר כרטיסי פיתוח, עם ארבע הרצות לכל כרטיס ב־Haiku 4.5. התוצאות נמדדו לפי השינויים שנשארו ב־git diff.

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

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

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

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

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

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

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

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

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

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

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

FAQ

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

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

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

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

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

אלה המדידות של הפרויקט עצמו, שפורסמו יחד עם שיטת המדידה שלהן, ויש לקרוא אותן בהתאם. נתוני ההרצה הבודדת משווים למודל בסיסי שמחזיר אפשרויות והערות, וה־README עצמו מציין שזהו baseline חלש. הנתונים ה־agentic נאספו בהרצת Claude Code ללא ממשק גרפי, על repository אחד של FastAPI ו־React, עם 12 tickets ו־4 הרצות לכל ticket, באמצעות Haiku 4.5. אלה נתונים אמינים עבור התצורה הזאת. הם אינם תחזית עבור בסיס הקוד שלכם, משום שהפרויקט מציין גם שהחיסכון יורד כמעט לאפס בקוד שכבר היה מינימלי.

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

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

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

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