Ponytail AI coding agent: कम कोड लिखने का सही तरीका

Ponytail क्या है

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

रिपॉजिटरी 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 लाइनों का हो गया।

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

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

Server पर दांव बदल जाते हैं, क्योंकि agent अक्सर बिना किसी की निगरानी के चलता है। tmux session में या timer पर काम करने वाला agent आपके देखने से पहले ही गलत निर्णय पर घंटों काम कर सकता है। VPS पर coding agent चलाने में यही व्यावहारिक जोखिम है, और यही कारण है कि loop engineering करने वाले लोग individual prompts के बजाय standing instructions पर इतना ध्यान देते हैं। Always-on file में दिया गया एक नियम turn 200 पर भी लागू होता है। Chat में आपके द्वारा टाइप किया गया नियम केवल turn 3 पर लागू होता है।

नई dependencies एक और छिपा हुआ खर्च हैं। Rung 5 कहता है कि जो installed है उसी का उपयोग करें। Agent अपनी पहल पर जो भी package जोड़ता है, वह कुछ ऐसा है जिसे आप बाद में patch करते हैं और जो उस repository से आपके द्वारा build की गई हर 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 के बीच बार-बार चलाए गए परीक्षणों के माध्य (median) के आधार पर, rule के साथ और उसके बिना, prompts के एक छोटे सेट का उत्तर देता है। 'Agentic' कॉलम एक headless Claude Code session से लिया गया है, जिसमें tiangolo के full-stack-fastapi-template (जो एक वास्तविक FastAPI और React repository है) पर बारह feature tickets को Haiku 4.5 पर चार बार run करके, git diff के आधार पर स्कोर किया गया है।

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

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

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

यह लैडर (ladder) टेक्स्ट है, इसलिए इस विचार का उपयोग करने के लिए आपको किसी प्लगइन की आवश्यकता नहीं है। इस तरह के एक ब्लॉक को उस इंस्ट्रक्शन फाइल में पेस्ट करें जिसे आपका एजेंट पहले से ही पढ़ता है, चाहे वह 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 लिखना जिसका आपका एजेंट वास्तव में पालन करे का विषय है, और यही कारण है कि यह पैटर्न आपकी शेल हिस्ट्री के बजाय एक कमिटेड फाइल में होना चाहिए।

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

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

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

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

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

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 है जो इस rule से अधिक प्रभावी है, इसलिए उस 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 को पहले आज़माना इस प्रश्न का उत्तर है कि क्या install करने की वास्तव में आवश्यकता है।

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

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