Ponytail: AI coding agent साठी आळशी senior dev नियम

Ponytail म्हणजे काय

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

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

परिणाम कोणत्याही एका पायरीमुळे नाही, तर या क्रमामुळे मिळतो. एखाद्या agent ला date picker तयार करण्यास सांगितल्यास तो 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 वर आला. पायरी 2 शांतपणे चुकते, कारण तुमच्याकडे आधीपासून असलेला helper agent ला दिसत नसेल, तर तो दुसरा helper सहज लिहील. हीच उणीव तुमच्या codebase चा queryable map भरून काढण्यासाठी आहे.

येथे 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 मध्ये आहे जी तुम्ही पाच मिनिटांत वाचू शकता.
• 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 तुम्ही मागितलेली गोष्ट तयार करते आणि एका ओळीत अधिक साधा पर्याय सांगते. 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 दाखवते. फक्त 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 रोजी या दोन ओळी दस्तऐवजात दिल्याप्रमाणे आहेत:

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

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

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

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

Tokens आत येताना आणि बाहेर जाताना दोन्ही वेळा bill केले जातात. त्यामुळे अर्ध्या आकाराचा 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 ओळींचा असायला हवा असलेला 400 ओळींचा बदल reviewer चे लक्ष खर्च करतो, आणि सर्वप्रथम संपणारे resource हेच लक्ष असते. दिवसातील चौथा मोठा diff review करताना कोणीही पहिल्या diff इतकी काळजी घेत नाही. त्यामुळे अनावश्यकपणे मोठे बांधकाम केल्याने फक्त वेळ वाया जात नाही. चुका शोधण्यासाठी असलेल्या 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 वर लागू होतो. त्याच box वर सुरू केलेल्या दुसऱ्या session वरही तो लागू होतो, कारण दुसरे session committed file वाचते; मात्र पहिल्या session मध्ये तुम्ही chat मध्ये टाइप केलेली कोणतीही गोष्ट त्याला मिळत नाही, जरी दोन्ही sessions एकमेकांना message करू शकत असतील तरी.

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

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 स्तंभात bare model ने rule शिवाय आणि rule सह छोट्या prompt संचाला दिलेल्या उत्तरांचे परिणाम आहेत. हे 13 आणि 17 June 2026 रोजी केलेल्या पुनरावृत्तीतील median म्हणून घेतले आहेत. Agentic स्तंभ headless Claude Code session मधून मिळतो. या session ने tiangolo च्या full-stack-fastapi-template या प्रत्यक्ष FastAPI आणि React repository मध्ये बदल केले. Haiku 4.5 वर प्रत्येकी चार runs सह बारा feature tickets तपासण्यात आले आणि शेवटी उरलेल्या git diff वर गुणांकन केले.

दुसरा स्तंभ पाहा. Agentic परिणामात 54 टक्के कमी code lines, 20 टक्के कमी खर्च आणि 27 टक्के कमी wall clock time आहे. त्याच मापांसाठी single shot setup मध्ये हे प्रमाण अनुक्रमे 93 टक्के आणि 74 टक्के आहे. README याचे कारण स्पष्टपणे सांगते: single shot baseline हा bare model आहे, जो "several options plus commentary" सह उत्तर देतो. अशा baseline वर मात करणे सोपे आहे. प्रत्यक्ष 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 च्या नावाने tagged केलेली comment:

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

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

हा block कुठे ठेवता, हे त्यातील मजकुराइतकेच महत्त्वाचे आहे. agent प्रत्येक run मध्ये load करत असलेली file, तुम्ही पाहत नसलेल्या run सह प्रत्येक run वर परिणाम करते. तुमचा agent प्रत्यक्षात पाळेल असा AGENTS.md लिहिणे याच फरकावर आधारित आहे. म्हणून ही पद्धत shell history मध्ये ठेवण्याऐवजी committed file मध्ये ठेवली पाहिजे. Monorepo मध्ये ती एकापेक्षा अधिक committed files मध्ये ठेवणे योग्य आहे, कारण प्रत्येक package साठी एक AGENTS.md ठेवल्यास प्रत्येक directory चे नियम लहान राहतात. त्यामुळे प्रत्येक run मध्ये agent ला संपूर्ण tree मधील conventions वाचाव्या लागत नाहीत. मात्र placement ही हमी नाही. म्हणून ladder ला अधिक स्पष्ट wording आवश्यक आहे असे ठरवण्यापूर्वी आधीच load केलेल्या नियमाकडे agent दुर्लक्ष का करतो हे समजून घेणे उपयुक्त ठरेल.

नियम योग्य ठरत नाही तो टप्पा

ही पायरीरचना आधीपासून अस्तित्वात असलेल्या codebase मध्ये feature work साठी तयार केली आहे. अशा codebase मध्ये 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 तुम्हाला एवढेच देतो की कोणीतरी ही यादी योग्य प्रकारे लिहिली, ती real repository वर तपासली आणि result च्या शेजारी ही पद्धत प्रकाशित केली.

FAQ

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

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

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

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

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

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

Unattended agent ला रात्रभर over-building करण्यापासून कसे थांबवू?

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