Ponytail: AI coding agent को कम code लिखवाने का तरीका

Ponytail क्या है

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

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

टूल से पहले विचार: पहली टिकाऊ सीढ़ी पर रुकें

Ponytail का मूल एक निर्णय-क्रम है। कुछ भी लिखने से पहले agent इस क्रम पर आगे बढ़ता है और जो पहली सीढ़ी लागू होती है, वहीं रुक जाता है।

1. क्या इसे वास्तव में होना आवश्यक है? यह YAGNI (you are not going to need it) है। यदि उत्तर नहीं है, तो इसे छोड़ दें।
2. क्या यह इस codebase में पहले से मौजूद है? पहले से मौजूद helper या pattern का पुनः उपयोग करें।
3. क्या standard library यह काम कर सकती है? इसका उपयोग करें।
4. क्या native platform feature इसे संभाल सकता है? इसका उपयोग करें।
5. क्या पहले से installed dependency इस समस्या को हल कर सकती है? उसका उपयोग करें।
6. क्या इसे एक line में लिखा जा सकता है? इसे एक line में लिखें।
7. इसके बाद ही, काम करने वाला न्यूनतम code लिखें।

काम किसी एक सीढ़ी से नहीं, बल्कि पूरे क्रम से होता है। यदि agent से date picker बनाने को कहा जाए, तो वह date picker लिखेगा, क्योंकि उसे यही करने के लिए कहा गया है। यह क्रम उसे पहले सीढ़ी 4 जांचने के लिए बाध्य करता है, और सीढ़ी 4 बताती है कि browser में पहले से <input type="date"> मौजूद है। Project के अपने benchmark notes में ठीक यही मामला दर्ज है: इस नियम के बिना date picker 404 lines का बना, जबकि नियम के साथ वह 23 lines का रहा, क्योंकि agent ने component बनाने के बजाय native input का उपयोग किया। इसी कारण colour picker 287 lines से घटकर 23 lines का हो गया।

यहां lazy होने का अर्थ लापरवाह होना नहीं है, और ruleset इसे सीधे स्पष्ट करता है। इसकी "never lazy about" सूची में निर्णय लेने से पहले समस्या को समझना, trust boundaries पर input validation, data loss रोकने वाला error handling, security, accessibility और नाम से मांगी गई हर चीज शामिल है। यह non-trivial logic के प्रत्येक हिस्से के लिए एक छोटी runnable check करने को भी कहता है। यह नियम अनावश्यक निर्माण को रोकता है। यह correctness को नहीं रोकता।

Repository वास्तव में क्या जारी करता है

• AGENTS.md, हमेशा सक्रिय रहने वाला ruleset, जो पूरी अवधारणा को एक ऐसी file में रखता है जिसे आप five minutes में पढ़ सकते हैं।
• skills/ponytail/SKILL.md, skill definition, जिसमें argument hint lite, full या ultra है।
• .cursor/rules/ और .windsurf/rules/ जैसी editor-specific directories के अंतर्गत rule files, उन hosts के लिए जो rules पढ़ते हैं लेकिन skills load नहीं करते।
• hooks/, benchmarks/, examples/ और scripts/।

intensity argument यह बदलता है कि rule कितनी सख्ती से लागू होता है। lite आपके अनुरोध के अनुसार बनाता है और एक line में कम मेहनत वाला विकल्प बताता है। full default है और ladder लागू करता है। ultra YAGNI का सबसे कठोर setting है: यह जोड़ने के बजाय हटाने को प्राथमिकता देता है और requirement पर भी आपत्ति करेगा।

Skill-capable hosts को slash commands भी मिलते हैं। /ponytail level सेट करता है, /ponytail-review over-engineering के लिए diff जांचता है, /ponytail-audit पूरे repository की जांच करता है, /ponytail-debt उन shortcuts को एकत्र करता है जिन्हें आपने टाल दिया था, और /ponytail-gain benchmark scorecard print करता है। जो hosts केवल rule files पढ़ते हैं, उन्हें commands के बिना ruleset मिलता है।

Source पर भरोसा करने से पहले उसे पढ़ने के लिए branch के बजाय tag clone करें:

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

Claude Code पर project इसके बजाय plugin install document करता है, और ये दो lines 1 August 2026 को documented हैं:

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

Plugin path tag के बजाय default branch का अनुसरण करता है। इसलिए आपके agent को निर्देश देने वाले नियम sessions के बीच आपके नियंत्रण के बिना बदल सकते हैं। Update command की सुविधा के लिए आपको यही trade-off स्वीकार करना होगा।

VPS पर आलसी agent सस्ता क्यों होता है

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

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

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

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

नई dependencies दूसरी छिपी हुई लागत हैं। Rung 5 कहता है कि जो install है, उसी का उपयोग करें। 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 से प्राप्त हुआ है, जिसने नियम के साथ और उसके बिना prompts के एक छोटे समूह का उत्तर दिया। ये परिणाम 13 और 17 June 2026 की बार-बार की गई runs के median हैं। Agentic कॉलम एक headless Claude Code session से प्राप्त हुआ है, जिसने tiangolo के full-stack-fastapi-template में बदलाव किए। यह एक वास्तविक FastAPI और React repository है। इसमें Haiku 4.5 पर चार-चार runs के साथ बारह feature tickets पूरे किए गए और पीछे छोड़े गए git diff के आधार पर स्कोर दिया गया।

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

एक सावधानी स्वयं प्रोजेक्ट ने बताई है, और यही तय करती है कि इससे आपको लाभ होगा या नहीं। बचत वहाँ सबसे अधिक होती है जहाँ अनावश्यक रूप से अधिक निर्माण करने का वास्तविक जोखिम हो। उस code में बचत लगभग शून्य होती है जो पहले से ही न्यूनतम था। एक Python और TypeScript repository में किए गए बारह tickets आपकी repository के परिणाम का अनुमान नहीं दे सकते। यदि यह संख्या आपके लिए महत्वपूर्ण है, तो अपने tickets पर नियम के साथ और उसके बिना तुलना चलाएँ और पंक्तियों की संख्या स्वयं गिनें।

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

यह क्रम टेक्स्ट के रूप में है, इसलिए इसका उपयोग करने के लिए आपको plugin की आवश्यकता नहीं है। इस तरह का कोई block उस instruction file में paste करें जिसे आपका agent पहले से पढ़ता है, चाहे वह AGENTS.md, CLAUDE.md या आपके editor की 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.

यह अंतिम rule अपने आप में ध्यान देने योग्य है। Ponytail का convention tool के नाम से tagged comment है:

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

यह comment दो पंक्तियों का काम करता है और उस प्रश्न को स्पष्ट कर देता है जिसके लिए अन्यथा एक review cycle लगती। यह अगले reader को बताता है कि सरल version एक निर्णय था और यह भी बताता है कि वह निर्णय किस condition में लागू नहीं रहता। इसके बिना reviewer यह नहीं बता सकता कि यह सोचा-समझा shortcut है या agent इसे भूल गया, इसलिए उसे पूछना पड़ता है।

Block को कहाँ रखना है, यह उतना ही महत्वपूर्ण है जितना कि उसमें क्या लिखा है। Agent जिस file को हर run पर load करता है, वह हर run को प्रभावित करती है, उन runs को भी जिन्हें आप monitor नहीं कर रहे हैं। यही अंतर ऐसी AGENTS.md लिखना जिसे आपका agent वास्तव में follow करे का विषय है और इसी कारण यह pattern आपकी shell history के बजाय किसी committed file में होना चाहिए।

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

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

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

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

ईमानदार सारांश यह है कि Ponytail numbers के साथ वितरित किया गया एक सावधानी से लिखा हुआ prompt है। इसमें plugin की कोई अनिवार्य आवश्यकता नहीं है। project आपको यह देता है कि किसी ने list को सही तरीके से लिखा, उसे वास्तविक repository पर test किया, और result के साथ method प्रकाशित किया।

FAQ

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

हाँ। यह उन hosts के लिए skill के रूप में उपलब्ध है जो skills लोड करते हैं। इस सूची में Claude Code, Codex, OpenCode, Gemini और README में बताए गए कई अन्य hosts शामिल हैं। ऐसे editors जो rule files पढ़ते हैं, लेकिन skills लोड नहीं करते, जैसे Cursor, Windsurf, Cline और Copilot, संबंधित 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 जिस चीज को हटाता है, वह है बिना अनुरोध की गई structure: ऐसी abstractions जिनकी किसी ने मांग नहीं की और ऐसी dependencies जिनकी किसी को आवश्यकता नहीं थी। यदि इसे install करने के बाद आपका agent tests हटाने लगे, तो इसका कारण आपके अपने config में मौजूद कोई अन्य instruction है, जिसकी प्राथमिकता इस rule से अधिक है। इसलिए वह file पढ़ें जिसे agent सबसे अंत में load करता है।

क्या प्रकाशित speed और cost numbers पर भरोसा किया जा सकता है?

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

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

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

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

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