Ponytail: AI coding agent साठी कमी code चा नियम

Ponytail म्हणजे काय

Ponytail हा नियमांचा संच आहे. तो AI coding agent ने कमी code लिहावा यासाठी वापरला जातो. प्रकल्पाचे स्वतःचे वर्णन एका वाक्यात असे आहे: "तुमच्या AI agent ला खोलीतील सर्वात आळशी वरिष्ठ developer प्रमाणे विचार करायला लावतो. तुम्ही कधीच न लिहिलेला code हा सर्वोत्तम code असतो." याला MIT परवान्याखाली परवाना देण्यात आला आहे. याची स्वतःची runtime प्रणाली नाही आणि यातील काहीही execute होत नाही. हा agent च्या सूचनांमध्ये समाविष्ट केला जाणारा मजकूर आहे. skills लोड करणाऱ्या hosts साठी तो skill म्हणून आणि skills लोड न करणाऱ्या hosts साठी साध्या 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 सूचीबद्ध आहेत. या वेगाने पुढे जाणाऱ्या प्रकल्पात तुम्ही हे वाचत असताना बदल झालेले असू शकतात. त्यामुळे त्यावर आधारित काहीही तयार करण्यापूर्वी tag निश्चित करा.

साधन वापरण्यापूर्वीची कल्पना: टिकणाऱ्या पहिल्या पायरीवर थांबा

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. हे एका ओळीत करता येते का? ते एका ओळीत करा.
7. त्यानंतरच, कार्य करणारा किमान code लिहा.

या क्रमामुळेच काम होते; कोणत्याही एका पायरीमुळे नाही. date picker तयार करण्यास सांगितलेल्या agent कडून date picker लिहिला जाईल, कारण त्याला तेच करण्यास सांगितले आहे. ही शिडी त्याला आधी पायरी 4 तपासण्यास भाग पाडते आणि पायरी 4 सांगते की browser मध्ये आधीपासून <input type="date"> आहे. प्रकल्पाच्या 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 कमी करत नाही.

रेपॉझिटरी प्रत्यक्षात काय वितरित करते

• AGENTS.md, नेहमी सक्रिय असलेला नियमसंच. ही संपूर्ण संकल्पना एका फाइलमध्ये आहे आणि ती पाच मिनिटांत वाचता येते.
• skills/ponytail/SKILL.md, कौशल्याची व्याख्या. यात lite, full किंवा ultra यांपैकी एक argument hint आहे.
• .cursor/rules/ आणि .windsurf/rules/ यांसारख्या editor-विशिष्ट directories अंतर्गत असलेल्या rule files. या अशा hosts साठी आहेत जे rules वाचतात, पण skills load करत नाहीत.
• hooks/, benchmarks/, examples/ आणि scripts/.

Intensity argument मुळे rule किती कडकपणे लागू होतो ते बदलते. lite तुम्ही मागितलेले तयार करते आणि एका ओळीत अधिक सैल पर्यायाचे नाव देते. full हा default आहे आणि ladder लागू करतो. ultra ही YAGNI ची अत्यंत कडक setting आहे. ती भर घालण्यापेक्षा deletion ला प्राधान्य देते आणि requirement वरही प्रश्न उपस्थित करते.

Skill-capable hosts ना slash commands देखील मिळतात. /ponytail level सेट करते, /ponytail-review over-engineering साठी diff तपासते, /ponytail-audit संपूर्ण repository तपासते, /ponytail-debt तुम्ही पुढे ढकललेल्या shortcuts एकत्र करते आणि /ponytail-gain benchmark scorecard दाखवते. जे 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 वर प्रकल्प त्याऐवजी plugin install करण्याची सूचना देतो. 1 August 2026 रोजी या दोन ओळी दस्तऐवजीकरणानुसार आहेत:

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

Plugin path tag ऐवजी default branch चे अनुसरण करते. त्यामुळे तुमच्या agent ला मार्गदर्शन करणाऱ्या instructions sessions दरम्यान तुमच्या नकळत बदलू शकतात. Update command च्या सुविधेसाठी तुम्ही स्वीकारलेली ही तडजोड आहे.

VPS वर आळशी agent स्वस्त का असतो

Agent ने लिहिलेला diff conversation च्या बाहेर जात नाही. पुढच्या turn मध्ये model तो पुन्हा वाचतो. तो diff तयार करण्यासाठी उघडलेल्या प्रत्येक file सोबत तो context चा भाग असतो. त्यामुळे 500 ओळींचा बदल तो तयार केलेल्या turn पुरताच खर्चिक ठरत नाही. Session मधील प्रत्येक पुढील turn वर त्याचा परिणाम होतो. म्हणूनच runaway refactor मुळे session पुढे जात असताना agent अधिक धीमा आणि कमी अचूक वाटतो. Window agent च्या स्वतःच्या output ने भरते. त्यामुळे तुमच्या वास्तविक code साठी उरलेली जागा कमी होते. हे नियंत्रणात ठेवणे म्हणजे coding agent ची context window व्यवस्थापित करणे या विषयाचा संपूर्ण भाग आहे.

Tokens आत येताना आणि बाहेर जाताना दोन्ही वेळा आकारले जातात. त्यामुळे निम्म्या आकाराचा diff दोनदा स्वस्त पडतो. तो लिहिताना एकदा आणि प्रत्येक turn मध्ये पुन्हा वाचताना प्रत्येक वेळी. Self-hosted setup मध्ये bill वर लक्ष ठेवत असल्यास, instruction file हे कोणताही खर्च न करता वापरता येणारे नियंत्रण आहे. AI agent चा खर्च नियंत्रित करणे output volume पासून सुरू होते. coding agent त्याचे tokens कसे वापरतो हे पुन्हा वाचण्याचा परिणाम अपेक्षेपेक्षा अधिक का असतो ते स्पष्ट करते.

Diff माणसालाच वाचावा लागतो. 20 ओळींचा असायला हवा असलेला 400 ओळींचा बदल reviewer चे लक्ष खर्च करतो. लक्ष हे सर्वप्रथम संपणारे resource आहे. दिवसातील चौथा मोठा 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 स्वतःहून add करणारे प्रत्येक package तुम्हाला नंतर patch करावे लागते. त्या repository पासून तयार केलेल्या प्रत्येक container image मध्येही ते package समाविष्ट होते.

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 स्तंभात, नियमासह आणि नियमाशिवाय, लहान prompt संचाला bare model ने दिलेल्या उत्तरांचे परिणाम आहेत. हे परिणाम 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 शी तुलना केल्यास फायदा कमी होतो. तो तरीही वास्तविक राहतो, आणि हीच अधिक उपयुक्त बाब आहे.

एक महत्त्वाची अट प्रकल्पाने स्वतः नमूद केली आहे. हा नियम तुमच्यासाठी उपयुक्त ठरेल की नाही, हे यावर ठरते. अनावश्यकपणे मोठे implementation करण्याचा खरा धोका असलेल्या कामात बचत सर्वाधिक असते. आधीपासूनच minimal असलेल्या code मध्ये बचत जवळजवळ शून्य असते. एका Python आणि TypeScript repository मधील बारा tickets तुमच्या repository साठी अंदाज देऊ शकत नाहीत. हा आकडा तुमच्यासाठी महत्त्वाचा असल्यास, तुमच्या स्वतःच्या tickets वर नियमासह आणि नियमाशिवाय तुलना करा आणि code च्या ओळी स्वतः मोजा.

आज काहीही स्थापित न करता तुम्ही वापरू शकता असा नमुना

ही शिडी मजकूराच्या स्वरूपात आहे. त्यामुळे ही संकल्पना वापरण्यासाठी तुम्हाला plugin ची आवश्यकता नाही. तुमचा agent आधीच वाचत असलेल्या instruction file मध्ये असा block paste करा. तो 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.

हा शेवटचा नियम स्वतंत्रपणे लक्षात घेण्यासारखा आहे. Ponytail ची पद्धत म्हणजे tool च्या नावाने चिन्हांकित केलेली comment:

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

या comment मध्ये दोन ओळींचे काम होते. त्यामुळे अन्यथा review cycle खर्ची पडणारा प्रश्न स्पष्ट होतो. साधी आवृत्ती ही जाणीवपूर्वक घेतलेला निर्णय होता, असे ती पुढील वाचकाला सांगते. तसेच हा निर्णय कोणत्या अटीखाली लागू राहणार नाही, हेही ती नमूद करते. ही comment नसल्यास, agent ने विचारपूर्वक केलेला shortcut वापरला आहे की काहीतरी विसरले आहे, हे reviewer ला समजत नाही. त्यामुळे reviewer ला विचारावे लागते.

हा block कुठे ठेवता, हे त्यात काय लिहिले आहे तितकेच महत्त्वाचे आहे. agent प्रत्येक run वेळी load करत असलेली file प्रत्येक run ला नियंत्रित करते. तुम्ही पाहत नसलेल्या run वरही तिचा परिणाम होतो. या फरकाचा विषय तुमचा agent प्रत्यक्षात पाळेल असा AGENTS.md लिहिणे हा आहे. म्हणून हा नमुना तुमच्या shell history ऐवजी committed file मध्ये ठेवणे योग्य आहे.

नियम योग्य ठरत नाहीत अशी ठिकाणे

ही श्रेणी आधीपासून अस्तित्वात असलेल्या कोडबेसमधील फीचरच्या कामासाठी तयार केलेली आहे. अशा ठिकाणी पुनर्वापराची शक्यता असते आणि तो सहसा योग्यही असतो. नवीन प्रकल्पासाठी ती योग्य बसत नाही. कारण श्रेणी 2 मध्ये पुनर्वापर करण्यासाठी काहीही नसते आणि श्रेणी 5 मध्ये काहीही स्थापित केलेले नसते. त्यामुळे एजंट प्रत्येक वेळी श्रेणी 7 पर्यंत पोहोचतो. तुम्हाला प्रत्यक्षात abstraction हवे असते त्या वेळीही ही श्रेणी योग्य बसत नाही. समान कॉपी केलेल्या कोड-ब्लॉकचा चौथा caller जोडणार असाल, तर "सर्वात छोटा diff" तुम्हाला पाचवी प्रत देतो.

ultra स्तर तुमच्या गरजांवर प्रश्न उपस्थित करेल. त्या स्तराचा उद्देशच तो आहे. परंतु तुम्ही निर्णय आधीच घेतला असेल आणि काम पूर्ण करून घ्यायचे असेल, तर ही खरी किंमत ठरते. नेहमीच्या कामासाठी full वापरा. फीचरची विनंतीच समस्या असू शकते असा संशय असल्यास ultra वापरा.

समस्येचा चुकीचा अर्थ लावल्यापासून कोणताही instruction block तुम्हाला वाचवू शकत नाही. निर्णय घेण्यापूर्वी कोड समजून घेणे हा ruleset मधील पहिला मुद्दा आहे. हाच महागडा भाग आहे आणि मजकूर तुमच्यासाठी तो करू शकत नाही. चुकीच्या function मधील minimal diff हाही चुकीचा fix असतो. आता तो मंजूर करणे सोपे असलेला छोटा चुकीचा fix असतो.

प्रामाणिक सारांश असा आहे की Ponytail हा काळजीपूर्वक लिहिलेला prompt आहे, जो योग्य प्रकारे वितरित केला आहे आणि ज्याला संख्यात्मक निकष जोडलेले आहेत. त्यासाठी plugin आवश्यक आहे असे कुठेही नमूद केलेले नाही. या प्रकल्पाचे योगदान एवढेच आहे की कोणीतरी ही यादी योग्य प्रकारे लिहिली, प्रत्यक्ष repository वर तिची चाचणी केली आणि परिणामाच्या शेजारी ही पद्धत प्रकाशित केली.

FAQ

Ponytail हे Claude Code व्यतिरिक्त इतर agents सोबत कार्य करते का?

होय. Skills load करणाऱ्या hosts साठी ते skill म्हणून उपलब्ध आहे. या यादीत Claude Code, Codex, OpenCode, Gemini आणि README मध्ये नमूद केलेले इतर अनेक hosts आहेत. Rule files वाचणारे पण skills load न करणारे Editors, जसे Cursor, Windsurf, Cline आणि Copilot, संबंधित rules directory मधील नेहमी लागू असलेला ruleset वापरतात. त्यांना slash commands मिळत नाहीत. दोन्ही बाबतीत मजकूर समान असतो. वास्तविक फरक हा असतो की तुमचा host हा मजकूर प्रत्येक 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 भागासाठी एक लहान, चालवता येणारी तपासणी असावी, असे त्यात सांगितले आहे. हा rule काढून टाकतो ती अनावश्यक रचना आहे: कोणीही मागितलेले नसलेले abstractions आणि कोणालाही आवश्यक नसलेल्या dependencies. ते install केल्यानंतर तुमचा agent tests वगळू लागला, तर त्याचे कारण तुमच्या स्वतःच्या config मधील दुसरा instruction यापेक्षा अधिक प्राधान्याने लागू होत आहे. त्यामुळे agent शेवटी load करत असलेली file वाचा.

प्रकाशित speed आणि cost चे आकडे विश्वासार्ह आहेत का?

हे project ने स्वतः केलेले, त्यांच्या पद्धतीसह प्रकाशित केलेले मोजमाप आहेत. त्यामुळे ते त्याच संदर्भात वाचले पाहिजेत. Single shot आकडे options आणि commentary देणाऱ्या bare model शी तुलना करतात. README मध्येच हा weak baseline असल्याचे नमूद केले आहे. Agentic आकडे एका FastAPI आणि React repository वरील headless Claude Code session मधून मिळाले आहेत. त्यात बारा tickets, प्रत्येकासाठी चार runs आणि Haiku 4.5 वापरले गेले. त्या setup साठी हे प्रामाणिक आकडे आहेत. ते तुमच्या codebase साठी forecast नाहीत, कारण आधीच minimal असलेल्या code वर saving जवळजवळ शून्यापर्यंत कमी होते, असे project स्वतःही सांगते.

हा लाभ मिळवण्यासाठी मला काही install करावे लागेल का?

नाही. Ladder हा मजकूर आहे. तुमचा agent आधीच वाचत असलेल्या instruction file मध्ये त्याचा equivalent block paste केल्यास तुम्हाला बहुतेक परिणाम मिळतो. Plugin मुळे maintained wording, intensity levels, review commands आणि update path मिळतो. आधी copied block वापरून पाहणे हा install खरोखर आवश्यक आहे का, या प्रश्नाचे rung 1 मधील उत्तर आहे.

Unattended agent ला रात्रभर अतिरिक्त बांधकाम करण्यापासून कसे थांबवायचे?

Rule chat message ऐवजी always-on instruction file मध्ये ठेवा. त्यामुळे तो दीर्घ run मधील turn 3 पुरताच नाही, तर turn 200 वरही लागू राहतो. त्यानंतर संभाव्य नुकसान स्वतंत्रपणे मर्यादित करा. तुमची एकमेव copy देण्याऐवजी agent ला खराब करता येईल असा checkout द्या. Merge करण्यापूर्वी human diff review आवश्यक करा. Minimal diff rule मुळे तुम्हाला वाचाव्या लागणाऱ्या बदलांचे प्रमाण कमी होते. काय merge करायचे हे तो ठरवत नाही आणि तसे त्याने करू नये.