Ponytail AI coding agent क्या है और कैसे काम करता है

Ponytail क्या है

Ponytail नियमों का एक ऐसा सेट है जो AI कोडिंग एजेंट को कम कोड लिखने के लिए प्रेरित करता है। यह प्रोजेक्ट खुद को एक पंक्ति में इस प्रकार वर्णित करता है: "यह आपके AI एजेंट को कमरे में मौजूद सबसे आलसी सीनियर डेवलपर की तरह सोचने पर मजबूर करता है। सबसे अच्छा कोड वह है जिसे आपने कभी लिखा ही नहीं।" यह MIT लाइसेंस के अंतर्गत आता है। इसका अपना कोई runtime नहीं है और इसमें कुछ भी execute नहीं होता है। यह वह टेक्स्ट है जिसे एजेंट के निर्देशों में डाला जाता है। इसे उन hosts के लिए एक skill के रूप में पैक किया गया है जो skills को load करते हैं, और उन hosts के लिए plain rule files के रूप में जो ऐसा नहीं करते हैं।

रिपॉजिटरी DietrichGebert/ponytail है। इसे 12 June 2026 को बनाया गया था और 1 August 2026 तक यह 90,000 stars के पार पहुँच गई। 1 August 2026 को नवीनतम tagged release v4.8.4 है, जिसे 29 June 2026 को प्रकाशित किया गया था। releases पेज पर केवल 14 और 29 June के बीच ही दस tags सूचीबद्ध हैं। इतनी गति से आगे बढ़ने वाला प्रोजेक्ट आपके पढ़ने तक बदल चुका होगा, इसलिए इस पर कुछ भी बनाने से पहले एक tag को pin कर लें।

टूल से पहले का विचार: उस पहले पायदान पर रुकें जो टिक सके

Ponytail का मूल एक निर्णय सीढ़ी (decision ladder) है। एजेंट कुछ भी लिखने से पहले इस पर चढ़ता है और उस पहले पायदान पर रुक जाता है जो टिक सके।

1. क्या इसका अस्तित्व में होना जरूरी है? यह YAGNI (you are not going to need it) का सिद्धांत है। यदि उत्तर नहीं है, तो इसे छोड़ दें।
2. क्या यह इस कोडबेस में पहले से मौजूद है? पहले से मौजूद हेल्पर या पैटर्न का पुन: उपयोग करें।
3. क्या स्टैंडर्ड लाइब्रेरी इसे करती है? उसका उपयोग करें।
4. क्या कोई नेटिव प्लेटफॉर्म फीचर इसे कवर करता है? उसका उपयोग करें।
5. क्या कोई पहले से इंस्टॉल की गई डिपेंडेंसी इसे हल करती है? उसका उपयोग करें।
6. क्या यह एक लाइन में हो सकता है? इसे एक लाइन में लिखें।
7. केवल तभी, वह न्यूनतम कोड लिखें जो काम करता है।

यह क्रम काम करता है, न कि कोई एक अकेला पायदान। यदि किसी एजेंट से डेट पिकर बनाने के लिए कहा जाए, तो वह डेट पिकर लिखेगा, क्योंकि उसे ऐसा करने के लिए कहा गया है। यह सीढ़ी उसे पहले पायदान 4 की जांच करने के लिए मजबूर करती है, और पायदान 4 कहता है कि ब्राउज़र में पहले से ही <input type="date"> मौजूद है। प्रोजेक्ट का अपना बेंचमार्क ठीक इसी स्थिति को दर्शाता है: एक डेट पिकर जो इस नियम के बिना 404 लाइनों का था, इसके साथ केवल 23 लाइनों का रह गया, क्योंकि एजेंट ने कंपोनेंट बनाने के बजाय नेटिव इनपुट का उपयोग किया। इसी कारण से एक कलर पिकर 287 लाइनों से घटकर 23 लाइनों का हो गया। पायदान 2 वह है जो चुपचाप विफल हो जाता है, क्योंकि एक एजेंट जो आपके पास मौजूद हेल्पर को नहीं देख सकता, वह खुशी-खुशी दूसरा हेल्पर लिख देगा, जिसे भरने के लिए आपके कोडबेस का एक क्वेरी करने योग्य मैप बनाया गया है।

यहाँ 'आलसी' होने का अर्थ लापरवाह होना नहीं है, और नियम पुस्तिका सीधे तौर पर यह कहती है। इसकी "कभी भी आलस न करें" सूची में निर्णय लेने से पहले समस्या को समझना, ट्रस्ट बाउंड्री पर इनपुट वैलिडेशन, डेटा हानि को रोकने वाली एरर हैंडलिंग, सुरक्षा, एक्सेसिबिलिटी और आपके द्वारा नाम से मांगी गई कोई भी चीज़ शामिल है। यह गैर-सामान्य लॉजिक के प्रत्येक हिस्से के लिए एक छोटा रननेबल चेक भी मांगती है। यह नियम आविष्कार को कम करता है। यह शुद्धता (correctness) को कम नहीं करता है।

रिपॉजिटरी वास्तव में क्या प्रदान करती है

• 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 पर, प्रोजेक्ट इसके बजाय एक प्लगइन इंस्टॉलेशन का दस्तावेजीकरण करता है, और ये दो लाइनें 1 अगस्त 2026 को प्रलेखित की गई थीं:

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

प्लगइन पाथ टैग के बजाय डिफ़ॉल्ट ब्रांच का अनुसरण करता है, इसलिए आपके एजेंट को निर्देशित करने वाले निर्देश सत्रों के बीच बदल सकते हैं। यह वह समझौता है जिसे आप अपडेट कमांड की सुविधा के लिए स्वीकार करते हैं।

VPS पर lazy agent सस्ता क्यों होता है

agent द्वारा लिखा गया diff conversation से बाहर नहीं जाता है। अगले turn में यह वह context होता है जिसे model फिर से पढ़ती है, साथ ही वे सभी files भी जिन्हें उसने इसे बनाने के लिए open किया था। इसलिए, 500 lines का बदलाव session के हर बाद वाले turn पर बोझ डालता है, न कि केवल उस turn पर जिसने इसे बनाया था। यही कारण है कि एक अनियंत्रित refactor session के आगे बढ़ने पर agent को धीमा और कम बुद्धिमान बना देता है: window agent के अपने output से भर जाती है, जिससे आपके वास्तविक code के लिए जगह कम हो जाती है। इसे नियंत्रित रखना ही coding agent की context window को manage करने का मुख्य विषय है।

Tokens का billing आने और जाने, दोनों पर होता है, इसलिए आधे आकार का diff दो बार सस्ता पड़ता है: एक बार जब इसे लिखा जाता है और दूसरी बार हर उस turn पर जब इसे फिर से पढ़ा जाता है। क्या यह बचत आपके bill में दिखेगी, यह इस पर निर्भर करता है कि आप भुगतान कैसे करते हैं, क्योंकि flat Pro या Max subscription अतिरिक्त tokens को समाहित कर लेता है, जबकि per-token API billing आपसे हर एक token का शुल्क लेती है। यदि आप self-hosted setup पर bill पर नजर रख रहे हैं, तो instruction file एक ऐसा lever है जिसे इस्तेमाल करने में कोई खर्च नहीं आता। AI agent की लागत को नियंत्रित करना output volume से शुरू होता है, और coding agent अपने tokens कैसे खर्च करता है यह बताता है कि tokens का दोबारा पढ़ा जाना लोगों की अपेक्षा से अधिक महत्वपूर्ण क्यों है।

एक इंसान अभी भी diff को पढ़ता है। 400 lines का बदलाव, जो 20 lines का होना चाहिए था, reviewer का ध्यान खर्च करता है, और ध्यान ही वह संसाधन है जो सबसे पहले खत्म होता है। दिन के चौथे लंबे diff को कोई भी उतनी सावधानी से review नहीं करता जितनी सावधानी से पहले को किया था, इसलिए जरूरत से ज्यादा काम करना न केवल समय की बर्बादी है। यह चुपचाप उस review की गुणवत्ता को कम कर देता है जिसे गलतियों को पकड़ना चाहिए था।

Server पर जोखिम बदल जाते हैं, क्योंकि agent अक्सर बिना किसी की निगरानी के चलता है। tmux session में या timer पर काम करने वाला agent आपके देखने से पहले ही गलत निर्णय पर घंटों काम कर सकता है। VPS पर coding agent चलाने में यही व्यावहारिक जोखिम है, और यही कारण है कि loop engineering करने वाले लोग individual prompts के बजाय standing instructions पर इतना ध्यान देते हैं। always-on file का एक नियम turn 200 पर लागू होता है। chat में टाइप किया गया नियम turn 3 पर लागू होता है। यह उसी box पर शुरू किए गए दूसरे session पर भी लागू होता है, जो committed file को तो पढ़ता है लेकिन आपके द्वारा पहले session में टाइप की गई किसी भी बात को inherit नहीं करता, तब भी जब दोनों sessions एक-दूसरे को message भेज सकते हैं।

नई dependencies एक और छिपा हुआ खर्च हैं। Rung 5 कहता है कि जो installed है, उसी का उपयोग करें। agent अपनी पहल पर जो भी package जोड़ता है, उसे आपको बाद में patch करना पड़ता है और वह उस repository से आपके द्वारा बनाए गए हर container image में शामिल हो जाता है।

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
  }
]

Single shot कॉलम एक bare model से आता है, जो 13 और 17 June 2026 के बीच बार-बार किए गए runs के medians के आधार पर, rule के साथ और उसके बिना prompts के एक छोटे सेट का उत्तर देता है। Agentic कॉलम एक headless Claude Code session से आता है, जो tiangolo के full-stack-fastapi-template पर काम करता है। यह एक वास्तविक FastAPI और React रिपॉजिटरी है, जिसमें Haiku 4.5 पर चार runs के साथ बारह feature tickets को एडिट किया गया है, और स्कोर git diff के आधार पर दिया गया है।

दूसरा कॉलम पढ़ें। Agentic परिणाम में 54 प्रतिशत कम lines of code, 20 प्रतिशत कम लागत और 27 प्रतिशत कम wall clock time लगता है, जबकि single shot सेटअप में यही माप 93 प्रतिशत और 74 प्रतिशत हैं। README इस कारण के बारे में स्पष्ट है: single shot baseline एक bare model है जो "कई विकल्पों और टिप्पणी के साथ उत्तर देता है", जिसे हराना आसान है। वास्तविक काम करने वाले एक वास्तविक agent के मुकाबले मापें तो जीत का अंतर कम हो जाता है। यह परिणाम वास्तविक बना रहता है, जो कि अधिक उपयोगी तथ्य है।

एक चेतावनी प्रोजेक्ट की अपनी है, और यही वह बात है जो तय करती है कि क्या यह आपके काम आएगा। बचत वहां सबसे अधिक है जहां genuine over-build trap मौजूद है, और पहले से ही minimal कोड पर यह लगभग शून्य है। एक Python और TypeScript रिपॉजिटरी में बारह tickets आपकी रिपॉजिटरी के बारे में भविष्यवाणी नहीं करते हैं। यदि यह संख्या आपके लिए मायने रखती है, तो अपने स्वयं के tickets पर rule के साथ और उसके बिना तुलना चलाएं, और स्वयं lines की गिनती करें।

वह पैटर्न जिसे आप आज बिना कुछ इंस्टॉल किए कॉपी कर सकते हैं

यह ladder केवल टेक्स्ट है, इसलिए इस विचार का उपयोग करने के लिए आपको किसी प्लगइन की आवश्यकता नहीं है। इस तरह के एक ब्लॉक को उस instruction file में पेस्ट करें जिसे आपका agent पहले से ही पढ़ता है, चाहे वह AGENTS.md हो, CLAUDE.md हो या आपके एडिटर की rules file हो।

## 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 cycle का समय लग जाता। यह अगले पाठक को बताता है कि सरल संस्करण एक सोच-समझकर लिया गया निर्णय था, और यह उस स्थिति का नाम बताता है जिसके तहत वह निर्णय अब मान्य नहीं रहता। इसके बिना, एक reviewer यह नहीं बता सकता कि यह एक विचारपूर्ण शॉर्टकट है या कुछ ऐसा जिसे agent भूल गया है, इसलिए उन्हें पूछना पड़ता है।

आप ब्लॉक को कहाँ रखते हैं, यह उतना ही मायने रखता है जितना कि वह क्या कहता है। एक फाइल जिसे agent हर रन पर लोड करता है, वह हर रन को निर्देशित करती है, जिसमें वे रन भी शामिल हैं जिन्हें आप नहीं देख रहे हैं। वह अंतर एक ऐसा AGENTS.md लिखना जिसका आपका agent वास्तव में पालन करे का विषय है, और यही कारण है कि यह पैटर्न आपकी shell history के बजाय एक committed file में होना चाहिए। एक monorepo में यह एक से अधिक committed files में होना चाहिए, क्योंकि प्रति पैकेज एक AGENTS.md प्रत्येक डायरेक्टरी के नियमों को संक्षिप्त रखता है, बजाय इसके कि agent को हर रन पर पूरे ट्री के कन्वेंशन पढ़ने पड़ें। हालाँकि, प्लेसमेंट कोई गारंटी नहीं है, और यह जानना महत्वपूर्ण है कि एक agent उस नियम को क्यों अनदेखा कर देता है जिसे उसने पहले ही लोड कर लिया है इससे पहले कि आप यह निष्कर्ष निकालें कि ladder को अधिक सख्त शब्दों की आवश्यकता है।

जहाँ नियम सही नहीं रहता

यह ladder ऐसे codebase में feature work के लिए तैयार की गई है जो पहले से मौजूद है, जहाँ reuse आमतौर पर उपलब्ध और सही होता है। यह greenfield project के लिए उपयुक्त नहीं है, क्योंकि rung 2 में reuse करने के लिए कुछ नहीं होता और rung 5 में कुछ भी installed नहीं होता, इसलिए agent हर बार rung 7 पर गिर जाता है। यह उस समय भी ठीक से काम नहीं करता जब आप वास्तव में abstraction चाहते हैं। यदि आप एक ही copied block का चौथा caller जोड़ने वाले हैं, तो "shortest diff" आपको पाँचवीं copy दे देगा।

ultra level आपकी आवश्यकताओं को चुनौती देगा। यह level इसी काम के लिए है, और जब आप निर्णय ले चुके हों और काम पूरा करना चाहते हों, तो यह एक वास्तविक लागत है। सामान्य काम के लिए full का उपयोग करें और जब आपको संदेह हो कि समस्या feature request में है, तो ultra का सहारा लें।

कोई भी instruction block आपको समस्या की गलत समझ से नहीं बचा सकता। ruleset का पहला बिंदु निर्णय लेने से पहले code को समझना है, जो कि सबसे कठिन हिस्सा है और जिसे text आपके लिए नहीं कर सकता। गलत function में minimal diff भी एक गलत fix ही होता है, और अब यह एक छोटा गलत fix है जिसे approve करना आसान है।

ईमानदार सारांश यह है कि Ponytail एक सावधानीपूर्वक लिखा गया prompt है, जिसे अच्छी तरह से distribute किया गया है और जिसमें numbers जोड़े गए हैं। इसमें कुछ भी ऐसा नहीं है जिसके लिए plugin की आवश्यकता हो। यह project आपको यह देता है कि किसी ने इस list को सही ढंग से लिखा है, इसे एक वास्तविक repository पर test किया है, और परिणाम के साथ-साथ विधि को प्रकाशित किया है।

FAQ

क्या Ponytail, Claude Code के अलावा अन्य agents के साथ काम करता है?

हाँ। यह उन hosts के लिए एक skill के रूप में आता है जो skills load करते हैं। इस सूची में Claude Code, Codex, OpenCode, Gemini और README में उल्लिखित कई अन्य शामिल हैं। जो editors rule files को पढ़ते हैं लेकिन skills load नहीं करते, जैसे कि Cursor, Windsurf, Cline और Copilot, वे matching rules directory से always-on ruleset लेते हैं और उन्हें slash commands नहीं मिलते। दोनों ही स्थितियों में text समान रहता है, इसलिए वास्तविक अंतर यह है कि आपका host उस text को हर turn पर context में रखता है या केवल तब जब कोई skill trigger होती है।

क्या कोई lazy agent tests, validation या security को छोड़ देगा?

नहीं, और ruleset में यह स्पष्ट रूप से लिखा है। इसकी "never lazy about" सूची में trust boundaries पर input validation, data loss को रोकने वाली error handling, security और accessibility शामिल हैं। यह हर non-trivial logic के लिए एक छोटा runnable check करने के लिए कहता है। यह rule केवल उन बनावटी structures को हटाता है जिनकी किसी ने मांग नहीं की थी और उन dependencies को जिन्हें किसी ने नहीं चाहा था। यदि इसे install करने के बाद आपका agent tests छोड़ने लगे, तो इसका कारण आपकी अपनी config में मौजूद कोई अन्य instruction है जो इससे अधिक प्राथमिकता रखती है। इसलिए उस file को पढ़ें जिसे agent सबसे अंत में load करता है।

क्या प्रकाशित speed और cost के आंकड़े विश्वसनीय हैं?

ये project के स्वयं के मापन हैं, जिन्हें उनकी विधि के साथ प्रकाशित किया गया है, और इन्हें उसी रूप में पढ़ा जाना चाहिए। single shot के आंकड़े एक ऐसे bare model की तुलना में हैं जो विकल्पों और commentary के साथ उत्तर देता है, जिसे README स्वयं एक कमजोर baseline मानता है। agentic आंकड़े एक FastAPI और React repository पर headless Claude Code session से लिए गए हैं, जिसमें बारह tickets, चार runs प्रत्येक, और Haiku 4.5 का उपयोग किया गया है। उस setup के लिए ये ईमानदार आंकड़े हैं। ये आपके codebase के लिए कोई पूर्वानुमान नहीं हैं, क्योंकि project यह भी कहता है कि जो code पहले से ही minimal था, उस पर बचत लगभग शून्य हो जाती है।

क्या लाभ पाने के लिए मुझे कुछ भी install करने की आवश्यकता है?

नहीं। यह ladder केवल text है, और आपके agent द्वारा पहले से पढ़ी जाने वाली instruction file में एक समान block paste करने से आपको अधिकांश प्रभाव मिल जाता है। plugin आपको maintained wording, intensity levels, review commands और एक update path देता है। copy किए गए block को पहले आज़माना इस सवाल का rung 1 उत्तर है कि क्या install की वास्तव में आवश्यकता है।

मैं किसी unattended agent को रात भर में over-building करने से कैसे रोकूँ?

rule को chat message के बजाय always-on instruction file में रखें, ताकि यह एक लंबे run के 200वें turn पर भी लागू हो, न कि केवल 3रे turn पर। फिर नुकसान को अलग से सीमित करें: agent को अपनी एकमात्र copy के बजाय एक ऐसी checkout दें जिसे वह खराब कर सके, और कुछ भी merge होने से पहले human diff review अनिवार्य करें। एक minimal diff rule आपके द्वारा पढ़े जाने वाले content को कम करता है। यह यह तय नहीं करता कि क्या merge होगा, और इसे ऐसा करना भी नहीं चाहिए।