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

Ponytail म्हणजे काय

Ponytail हा नियमांचा संच आहे. तो AI coding agent कडून कमी code लिहून घेतो. प्रकल्पाचे स्वतःचे वर्णन एका वाक्यात असे आहे: "तुमच्या AI agent ला खोलीतील सर्वांत आळशी senior developer सारखा विचार करायला लावतो. सर्वोत्तम code म्हणजे तुम्ही कधीही न लिहिलेला code." याचा परवाना MIT आहे. याचा स्वतःचा runtime नाही आणि यातील काहीही execute होत नाही. हे agent च्या instructions मध्ये समाविष्ट केले जाणारे text आहे. Skills load करणाऱ्या hosts साठी ते skill म्हणून आणि skills न load करणाऱ्या hosts साठी साध्या rule files म्हणून packaged आहे.

Repository DietrichGebert/ponytail आहे. ते 12 June 2026 रोजी तयार करण्यात आले आणि 1 August 2026 पर्यंत त्याला 90,000 stars मिळाले. 1 August 2026 रोजीचा नवीनतम tagged release v4.8.4 आहे. तो 29 June 2026 रोजी published झाला. Releases page वर केवळ 14 ते 29 June दरम्यानचे दहा tags सूचीबद्ध आहेत. या वेगाने बदलणारा प्रकल्प तुम्ही हे वाचता तोपर्यंत बदललेला असू शकतो. त्यामुळे त्यावर आधारित काहीही 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. आधीपासून install केलेली dependency ही गरज पूर्ण करते का? ती वापरा.
6. हे एका ओळीत करता येते का? ते एका ओळीत करा.
7. त्यानंतरच, कार्य करणारा किमान code लिहा.

काम कोणतीही एक पायरी करत नाही; पायऱ्यांचा क्रम ते काम करतो. Agent ला date picker तयार करण्यास सांगितल्यास तो date picker लिहील, कारण त्याला तेच करण्यास सांगितलेले असते. ही शिडी त्याला आधी 4th पायरी तपासण्यास भाग पाडते आणि 4th पायरी सांगते की 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 च्या प्रत्येक भागासाठी एक small runnable check ठेवण्यासही ते सांगते. हा नियम अनावश्यक निर्मिती कमी करतो. तो correctness कमी करत नाही.

प्रत्यक्षात repository मध्ये काय वितरित केले जाते

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

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

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

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

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

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

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

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

Diff माणसालाही वाचावा लागतो. 20 lines मध्ये होऊ शकणारा 400 lines चा बदल reviewer चे लक्ष खर्च करतो, आणि सर्वप्रथम संपणारे resource म्हणजे लक्ष. दिवसातील चौथा मोठा diff पाहताना कोणीही पहिल्या diff इतक्या काळजीपूर्वक review करत नाही. त्यामुळे अनावश्यकपणे मोठे implementation केवळ वेळ वाया घालत नाही. चुका शोधण्यासाठी असलेल्या review ची गुणवत्ता ते नकळत कमी करते.

Server वर परिस्थिती बदलते, कारण agent अनेकदा कोणीही पाहत नसताना चालतो. tmux session मध्ये किंवा timer वर चालणाऱ्या agent कडे तुम्ही तो पाहण्यापूर्वी चुकीच्या निर्णयावर पुढील अनेक तास काम उभारण्यास पुरेसा वेळ असतो. हा VPS वर coding agent चालवण्याचा व्यावहारिक धोका आहे. म्हणून loop engineering करणारे लोक individual prompts पेक्षा कायम लागू असलेल्या instructions वर अधिक काळजीपूर्वक काम करतात. always-on file मधील rule turn 200 ला लागू होते. Chat मध्ये तुम्ही टाइप केलेला rule turn 3 ला लागू होतो.

नवीन dependencies हा आणखी एक शांतपणे वाढणारा खर्च आहे. Rung 5 मध्ये installed असलेल्या गोष्टी वापरण्यास सांगितले आहे. Agent स्वतःहून जोडणारे प्रत्येक package तुम्हाला नंतर patch करावे लागते. तसेच त्या repository पासून तयार होणाऱ्या प्रत्येक container image मध्ये ते package समाविष्ट होते.

Ponytail चे स्वतःचे benchmark आकडे काय सांगतात

प्रकल्प दोन संचांमध्ये निकाल प्रकाशित करतो आणि त्यांच्यात मोठा फरक आहे. दोन्ही आकडे प्रकल्पाने स्वतः प्रकाशित केलेले आहेत. यापैकी एकही स्वतंत्र चाचणी नाही.

[
  {
    "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 संचाला rule शिवाय आणि rule सह 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 lines 54 percent कमी, cost 20 percent कमी आणि wall clock time 27 percent कमी आहे. त्याच मोजमापांसाठी single shot setup मध्ये हे आकडे अनुक्रमे 93 percent आणि 74 percent आहेत. याचे कारण README मध्ये स्पष्टपणे सांगितले आहे: single shot baseline हा bare model आहे, जो “अनेक पर्यायांसह commentary देतो”. त्यामुळे त्याच्यापेक्षा चांगली कामगिरी करणे सोपे आहे. प्रत्यक्ष काम करणाऱ्या agent शी तुलना केल्यावर फायदा कमी होतो. तो तरीही प्रत्यक्ष आहे, आणि हाच अधिक उपयुक्त निष्कर्ष आहे.

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

आज कोणतेही काहीही install न करता वापरता येणारी पद्धत

ही ladder मजकूराच्या स्वरूपात आहे. त्यामुळे ही संकल्पना वापरण्यासाठी 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 च्या नावाने tag केलेली comment:

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

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

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

जिथे हा नियम लागू राहत नाही

ही शिडी आधीपासून अस्तित्वात असलेल्या codebase मध्ये feature work करण्यासाठी तयार केली आहे. अशा ठिकाणी code reuse साधारणपणे उपलब्ध आणि योग्य असते. Greenfield project साठी ती योग्य ठरत नाही, कारण rung 2 वर reuse करण्यासाठी काहीच नसते आणि rung 5 वर install केलेले काहीच नसते. त्यामुळे agent प्रत्येक वेळी rung 7 पर्यंत पोहोचतो. तुम्हाला प्रत्यक्षात abstraction हवे असते, तेव्हाही हा नियम योग्य ठरत नाही. त्याच copied block चा चौथा caller जोडणार असाल, तर "shortest diff" तुम्हाला पाचवी copy तयार करून देतो.

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

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

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

FAQ

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

होय. Skills load करणाऱ्या hosts साठी ते skill म्हणून उपलब्ध होते. या यादीत Claude Code, Codex, OpenCode, Gemini आणि README मध्ये नमूद केलेले इतर अनेक hosts समाविष्ट आहेत. Cursor, Windsurf, Cline आणि Copilot सारखे rule files वाचणारे पण skills load न करणारे editors, संबंधित rules directory मधील always-on ruleset वापरतात आणि त्यांना slash commands मिळत नाहीत. दोन्ही बाबतीत मजकूर समान असतो. प्रत्यक्ष फरक एवढाच असतो की तुमचा host प्रत्येक turn मध्ये हा मजकूर context मध्ये ठेवतो की skill trigger झाल्यावरच ठेवतो.

आळशी agent tests, validation किंवा security वगळेल का?

नाही. Ruleset मध्ये हे थेट नमूद केले आहे. त्यातील "never lazy about" यादीत trust boundaries वरील input validation, data loss टाळणारे error handling, security आणि accessibility यांचा समावेश आहे. तसेच, प्रत्येक non-trivial logic घटकासाठी एक छोटी runnable तपासणी करण्यास ते सांगते. हे rule काढून टाकते ते विनाकारण तयार केलेली रचना: कोणीही मागितलेली नसलेली abstractions आणि कोणालाही आवश्यक नसलेली dependencies. ते install केल्यानंतर तुमचा agent tests वगळू लागला, तर कारण तुमच्या स्वतःच्या config मधील दुसरी instruction या rule पेक्षा वरचढ ठरत आहे. त्यामुळे agent शेवटी load करत असलेली file वाचा.

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

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

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

नाही. Ladder हा मजकूर आहे. तुमचा agent आधीच वाचत असलेल्या instruction file मध्ये समतुल्य 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 करण्यापूर्वी मानवी diff review आवश्यक करा. Minimal diff rule मुळे तुम्हाला वाचावे लागणारे प्रमाण कमी होते. कोणता बदल स्वीकारायचा हे ते ठरवत नाही आणि ठरवू नये.