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

מהו Ponytail

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

המאגר נמצא ב-DietrichGebert/ponytail. הוא נוצר ב-12 ביוני 2026 ועבר את רף 90,000 הכוכבים עד ה-1 באוגוסט 2026. ב-1 באוגוסט 2026, ה-release המתויג האחרון היה v4.8.4, שפורסם ב-29 ביוני 2026, ודף ה-releases הציג עשרה תיוגים בין ה-14 ל-29 ביוני בלבד. הקצב לא הואט: ב-17 באוקטובר 2026 ה-release האחרון הוא v5.3.2, שפורסם בשעות המאוחרות של ה-16 באוקטובר, ה-release השלישי באותו יום לאחר v5.3.0 ו-v5.3.1. לפניו הגיע v5.2.0 ב-13 באוקטובר, חמישה ימים לאחר ש-v5.0.0 ו-v5.1.0 שניהם הושקו ב-8 באוקטובר, והמאגר מציג יותר מ-165,000 כוכבים. פרויקט המתקדם בקצב כזה ישתנה עד שתקראו שורות אלו, לכן קבעו גרסה (pin) באמצעות תיוג לפני שתבנו דבר מה על בסיסו.

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

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

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

זהו הסולם כפי שנכתב ב-v4.8.4, ומספרי השלבים בשאר המאמר עוקבים אחריו. ענף ה-main הנוכחי מאחד את שלבים 3 ו-4 לשלב אחד: "ספריית תקן או תכונת פלטפורמה? השתמש בהן, אלא אם לפרויקט יש פתרון משלו", ומוסיף ש"רכיב פנימי עדיף על ווידג'ט מובנה", כך שישנם שישה שלבים. הסדר נותר זהה.

הסדר הוא שמבצע את העבודה, לא אף שלב בודד. סוכן שיתבקש ליצור בורר תאריכים יכתוב בורר תאריכים, כי כתיבת אחד כזה היא מה שנאמר לו לעשות. הסולם גורם לו לבדוק מה כבר קיים לפני שהוא בונה דבר מה: שלב 2 שואל האם במאגר כבר יש רכיב עבור זה, ושלב 4 אומר שהדפדפן כבר כולל <input type="date">. מדד הביצועים הנוכחי של הפרויקט מציין בדיוק מקרה זה: בורר תאריכים שהגיע ל-335 שורות ללא הכלל, הצטמצם ל-10 שורות עם Ponytail 5, כיוון שהסוכן עשה שימוש חוזר ברכיב ה-Input של המאגר עם type="date" ונתן לדפדפן לספק את לוח השנה. בורר צבעים הצטמצם פחות, מ-135 שורות ל-26. שלב 2 הוא זה שנכשל בשקט, כיוון שסוכן שאינו יכול לראות את ה-helper שכבר יש לך יכתוב בשמחה אחד שני, וזהו הפער ש-מיפוי ניתן לשאילתות של בסיס הקוד שלך נועד לסגור.

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

מה המאגר כולל בפועל

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

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

מארחים התומכים במיומנויות מקבלים גם פקודות slash. /ponytail קובע את הרמה, /ponytail-review בודק diff עבור הנדסת יתר, /ponytail-audit בודק מאגר שלם, /ponytail-debt אוסף את הקיצורים שדחית, ו-/ponytail-gain מדפיס את כרטיס הניקוד של ה-benchmark. מארחים שרק קוראים קובצי כללים מקבלים את ערכת הכללים ללא פקודות. מאז v5.3.0, ששוחרר ב-16 באוקטובר 2026, Claude Code מקבל גם פס מעל ה-prompt המציג את עלות המשימה, שימוש חוזר בקוד וסטטוס בדיקות. הוא דורש את Claude Code 2.1.290 ומעלה, הוא אינו מופיע בלוח הצ'אט של VS Code, בסשנים בענן או ב-claude -p, ו-/ponytail band off מסתיר אותו. מאז v5.3.2, /ponytail band import קורא את סשני ה-Claude Code הקודמים שלך פעם אחת ומוסיף אותם ללוח עם העלות, זמן הסוכן וה-tokens שלהם, כך שתוכל להשוות אותם לסשנים שהורצו תחת הכלל.

כדי לקרוא את קוד המקור לפני שאתה נותן בו אמון, בצע clone לתג (tag) ולא לענף (branch). זהו התג שממנו מגיע ה-ladder לעיל; החלף ב-v5.3.2, העדכני ביותר נכון ל-17 באוקטובר 2026, כדי לקרוא את הניסוח הנוכחי:

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

ב-Claude Code הפרויקט מתעד התקנת תוסף במקום זאת, ושתי שורות אלו מתועדות נכון ל-17 באוקטובר 2026:

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

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

מדוע סוכן "עצלן" זול יותר בשרת VPS

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

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

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

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

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

מה אומרים נתוני ה-benchmark של 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
  }
]

התרשים מציג את ה-benchmark הסוכן (agentic) הנוכחי של הפרויקט, מתאריך 7 באוקטובר 2026. סשנים של Claude Code 2.1.288 ללא ממשק גרפי (headless) על גבי Opus 5.5 במאמץ ברירת מחדל, עבדו על 39 משימות, חמישה הרצות לכל משימה וזרוע, סך הכל 585 סשנים ללא skill, עם Ponytail v4.13.0 ועם Ponytail 5. שתים-עשרה מהמשימות הן כרטיסי תכונות (feature tickets) ב-full-stack-fastapi-template של tiangolo, מאגר FastAPI ו-React אמיתי, שנוקדו לפי ה-git diff שנותר. השאר הן 18 משימות כירורגיות עם בדיקות סמויות, שש בקשות ליישומים קטנים ושלוש בקשות מסוג "הראה לי דוגמה". Bash הושבת בכל הזרועות. כמות ה-tokens בפלט ירדה ב-45 אחוז עם Ponytail 5.

השוו זאת לנתוני ה-single shot שהפרויקט פרסם ביוני 2026. אלו הגיעו ממודל חשוף שענה על חמש הנחיות יומיומיות עם ובלי הכלל, ודווחו כחציונים על פני הרצות חוזרות. הם הראו 80 עד 94 אחוז פחות קוד ב-Haiku, Sonnet ו-Opus, ואימות העלויות מתאריך 17 ביוני 2026 הציב את Haiku כזולה ב-63 אחוז. התוצאה הסוכנת הנוכחית עבור Ponytail 5 היא 53 אחוז פחות שורות קוד, 26 אחוז עלות נמוכה יותר ו-41 אחוז פחות זמן שעון. הפרויקט תיקן את נתון ה-single shot במהירות. עד v4.8.4, ב-29 ביוני 2026, ה-README כבר הציג בכותרת את התוצאה הסוכנת, "~54% פחות קוד (עד 94%)", עם הערה שהנתון הקודם של 80 עד 94 אחוז היה "תקרת המשימה, לא הממוצע", והוא העביר את מספרי ה-single shot לסעיף מקופל שכותרתו "מספרי single-shot ישנים". אותו סעיף היה כן לגבי הסיבה לקיום הפער: בסיס ה-single shot הוא מודל חשוף ש"ממלא את תשובתו בפרוזה ובאפשרויות", דבר שקל לנצח. מדדו זאת מול סוכן אמיתי שעושה עבודה אמיתית והיתרון מצטמצם. הוא נשאר אמיתי, וזו העובדה השימושית יותר. אותה הרצה סוכנת של יוני, שתים-עשרה כרטיסים על Haiku 4.5 עם ארבע הרצות כל אחד, הגיעה קרוב לנתון של היום עם 54 אחוז פחות שורות, וה-README הנוכחי כבר לא מכיל את מספרי ה-single shot כלל.

הסתייגות אחת היא של הפרויקט עצמו, והיא זו שתקבע אם זה עוזר לכם. החיסכון הוא הגדול ביותר במקומות שבהם קיים מלכוד של בניית-יתר (over-build) וכמעט אפסי בקוד שהיה מינימלי מלכתחילה, וטבלת המשימות של אוקטובר מאששת זאת, כאשר כמה משימות כירורגיות הגיעו לאותו מספר שורות בכל שלוש הזרועות. שלושים ותשע משימות על מודל אחד ומארח אחד, עם 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

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

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

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

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

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

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

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

FAQ

האם Ponytail עובד עם סוכנים (agents) מלבד Claude Code?

כן. הוא מופץ כ־skill עבור מארחים הטוענים skills, רשימה הכוללת את Claude Code, Codex, OpenCode, Gemini ואחרים המפורטים ב־README. עורכי קוד שקוראים קובצי חוקים אך אינם טוענים skills, כגון Cursor, Windsurf, Cline ו־Copilot, משתמשים בערכת החוקים הפעילה תמיד (always-on) מתיקיית החוקים המתאימה, ללא פקודות slash. הטקסט זהה בשני המקרים; ההבדל המהותי הוא האם המארח שומר את הטקסט בהקשר (context) בכל תור, או רק כאשר ה־skill מופעל.

האם סוכן "עצלן" ידלג על בדיקות, תיקוף או אבטחה?

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

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

אלו מדידות של הפרויקט עצמו, שפורסמו יחד עם המתודולוגיה שלהם, ויש להתייחס אליהן בהתאם. נתוני ה-single shot מיוני 2026 הושוו למודל בסיסי שהוסיף לתשובותיו מלל ואפשרויות, מה שה־README באותה עת הגדיר כנקודת ייחוס (baseline) חלשה. נתוני הסוכנים הנוכחיים מגיעים מהרצות headless של Claude Code על Opus 5.5, עם 39 משימות בחמש הרצות כל אחת, מתוכן 12 כרטיסי פיצ'ר במאגר FastAPI ו-React אחד. אלו נתונים מהימנים עבור הגדרה זו. הם אינם תחזית עבור בסיס הקוד שלך, שכן תוצאות הפרויקט עצמו לכל משימה מראות שהחיסכון יורד לכמעט אפס בקוד שכבר היה מינימלי.

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

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

כיצד אוכל למנוע מסוכן ללא השגחה לבצע בנייה מוגזמת במהלך הלילה?

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