Ponytail म्हणजे काय? AI कोडिंग एजंटसाठी आळशी डेव्हलपर नियम

Ponytail म्हणजे काय

Ponytail हा नियमांचा एक संच आहे जो AI कोडिंग एजंटला कमी कोड लिहिण्यास प्रवृत्त करतो. हा प्रकल्प स्वतःचे वर्णन एका ओळीत करतो: "तुमच्या AI एजंटला खोलीतील सर्वात आळशी वरिष्ठ डेव्हलपरप्रमाणे विचार करायला लावतो. सर्वोत्तम कोड तो असतो जो तुम्ही कधीच लिहिला नाही." हे MIT लायसन्स अंतर्गत उपलब्ध आहे. याचे स्वतःचे कोणतेही रनटाइम नाही आणि यात काहीही एक्झिक्युट होत नाही. हा मजकूर एजंटच्या सूचनांमध्ये समाविष्ट केला जातो, जो स्किल्स लोड करणाऱ्या होस्टसाठी स्किल म्हणून आणि तसे न करणाऱ्या होस्टसाठी साध्या नियम फाइल्सच्या स्वरूपात पॅकेज केलेला असतो.

याचे रिपॉझिटरी DietrichGebert/ponytail आहे. हे 12 जून 2026 रोजी तयार करण्यात आले आणि 1 ऑगस्ट 2026 पर्यंत याला 90,000 पेक्षा जास्त स्टार्स मिळाले. 1 ऑगस्ट 2026 रोजी, सर्वात अलीकडील टॅग केलेली रिलीज v4.8.4 होती, जी 29 जून 2026 रोजी प्रकाशित झाली होती आणि रिलीज पेजवर केवळ 14 ते 29 जून दरम्यान दहा टॅग सूचीबद्ध होते. याचा वेग मंदावलेला नाही: 17 ऑक्टोबर 2026 रोजी सर्वात अलीकडील रिलीज v5.3.2 आहे, जी 16 ऑक्टोबरच्या उशिरा प्रकाशित झाली; ही त्या दिवसातील तिसरी रिलीज होती, ज्याआधी v5.3.0 आणि v5.3.1 आल्या होत्या. त्याआधी 13 ऑक्टोबर रोजी v5.2.0 आली होती, जी 8 ऑक्टोबर रोजी आलेल्या v5.0.0 आणि v5.1.0 नंतर पाच दिवसांनी आली होती आणि रिपॉझिटरीमध्ये 165,000 पेक्षा जास्त स्टार्स दिसत आहेत. इतक्या वेगाने चालणारा प्रकल्प तुम्ही हे वाचता वाचता बदललेला असू शकतो, म्हणून त्यावर आधारित काहीही तयार करण्यापूर्वी एखादा टॅग पिन करा.

साधनापूर्वीची संकल्पना: जिथे आधार मिळेल तिथेच थांबा

Ponytail चा मुख्य गाभा म्हणजे एक निर्णय-शिडी (decision ladder). काहीही लिहिण्यापूर्वी एजंट या शिडीवर चढतो आणि जिथे त्याला भक्कम आधार मिळतो, तिथेच थांबतो.

1. हे अस्तित्वात असणे खरोखर आवश्यक आहे का? याला YAGNI (you are not going to need it) म्हणतात. जर उत्तर 'नाही' असेल, तर ते सोडून द्या.
2. हे या कोडबेसमध्ये आधीच अस्तित्वात आहे का? आधीच असलेल्या हेल्परचा किंवा पॅटर्नचा पुनर्वापर करा.
3. हे स्टँडर्ड लायब्ररीमध्ये उपलब्ध आहे का? त्याचा वापर करा.
4. हे एखाद्या नेटिव्ह प्लॅटफॉर्म फीचरद्वारे कव्हर होते का? त्याचा वापर करा.
5. हे आधीच इन्स्टॉल केलेल्या डिपेंडन्सीद्वारे सुटते का? त्याचा वापर करा.
6. हे एका ओळीत होऊ शकते का? ते एका ओळीत लिहा.
7. त्यानंतरच, काम करेल असा किमान कोड लिहा.

ही शिडी v4.8.4 वर लिहिल्याप्रमाणे आहे आणि या लेखातील उर्वरित भागातील पायऱ्यांचे क्रमांक त्याचेच अनुसरण करतात. सध्याची मेन ब्रँच 3 आणि 4 या पायऱ्या एकत्र करते, "स्टँडर्ड लायब्ररी किंवा प्लॅटफॉर्म फीचर? त्याचा वापर करा, जोपर्यंत प्रकल्पाचे स्वतःचे वेगळे काही नसेल", आणि त्यात "हाऊस कंपोनंट नेटिव्ह विजेटपेक्षा सरस असतो" हे जोडते, त्यामुळे त्यात सहा पायऱ्या आहेत. त्यांचा क्रम तोच आहे.

कोणतीही एक पायरी नाही, तर हा क्रमच काम करतो. डेट पिकर (date picker) बनवण्यास सांगितलेला एजंट डेट पिकरच लिहील, कारण त्याला तेच करायला सांगितले आहे. ही शिडी त्याला काहीही बनवण्यापूर्वी काय अस्तित्वात आहे हे तपासण्यास भाग पाडते: पायरी 2 विचारते की रिपॉझिटरीमध्ये त्यासाठी आधीच एखादा कंपोनंट आहे का, आणि पायरी 4 सांगते की ब्राउझरकडे आधीच <input type="date"> आहे. प्रकल्पाचे सध्याचे बेंचमार्क नेमके हेच उदाहरण नोंदवतात: नियमाशिवाय 335 ओळींचा असलेला डेट पिकर Ponytail 5 सह 10 ओळींचा झाला, कारण एजंटने रिपॉझिटरीचा स्वतःचा Input कंपोनंट type="date" सह वापरला आणि कॅलेंडरसाठी ब्राउझरची मदत घेतली. कलर पिकर (colour picker) 135 ओळींवरून 26 ओळींपर्यंत कमी झाला. पायरी 2 शांतपणे अपयशी ठरते, कारण ज्या एजंटला तुमच्याकडील हेल्पर दिसत नाही, तो आनंदाने दुसरा हेल्पर लिहून टाकेल. ही दरी तुमच्या कोडबेसचा क्वेरी करण्यायोग्य नकाशा भरून काढण्यासाठी आहे.

येथे 'आळशी' (Lazy) असणे म्हणजे निष्काळजी असणे नव्हे आणि नियमावलीत हे स्पष्टपणे नमूद केले आहे. त्याच्या "कधीही आळस करू नका" या यादीमध्ये निर्णय घेण्यापूर्वी समस्या समजून घेणे, ट्रस्ट बाउंड्रीजवर इनपुट व्हॅलिडेशन, डेटा गमावण्यापासून वाचवणारे एरर हँडलिंग, सुरक्षा, ॲक्सेसिबिलिटी आणि तुम्ही नावाने विचारलेली कोणतीही गोष्ट यांचा समावेश होतो. हे प्रत्येक नॉन-ट्रिव्हियल लॉजिकसाठी एक लहान रन करण्यायोग्य चेक (runnable check) देखील मागते. हा नियम नवनिर्मिती कमी करतो. तो अचूकता कमी करत नाही.

रिपॉझिटरीमध्ये नक्की काय समाविष्ट आहे

• AGENTS.md, नेहमी सक्रिय असणारा नियमांचा संच (ruleset), जो संपूर्ण संकल्पना एका फाईलमध्ये मांडतो आणि तुम्ही पाच मिनिटांत वाचू शकता.
• skills/ponytail/SKILL.md, कौशल्याची व्याख्या (skill definition), ज्यामध्ये lite, full, ultra किंवा off यांसारख्या आर्ग्युमेंट हिंट्स आहेत.
• .cursor/rules/ आणि .windsurf/rules/ सारख्या एडिटर-विशिष्ट डिरेक्टरीजमधील नियम फाईल्स, अशा होस्ट्ससाठी जे नियम वाचतात पण स्किल्स लोड करत नाहीत.
• hooks/, benchmarks/, examples/ आणि scripts/.

इंटेन्सिटी (intensity) आर्ग्युमेंट नियम किती कठोरपणे लागू करायचा हे ठरवते. lite तुम्ही मागितलेली गोष्ट तयार करते आणि एका ओळीत अधिक सोपा पर्याय सुचवते. full हे डीफॉल्ट सेटिंग आहे आणि ते शिडी (ladder) लागू करते. ultra हे YAGNI (You Ain't Gonna Need It) तत्त्वाचे कट्टर सेटिंग आहे: हे नवीन कोड जोडण्यापेक्षा तो काढून टाकण्याला प्राधान्य देते आणि आवश्यकतेवरच प्रश्नचिन्ह उपस्थित करते.

स्किल-सक्षम होस्ट्सना स्लॅश कमांड्स देखील मिळतात. /ponytail लेव्हल सेट करते, /ponytail-review ओव्हर-इंजिनिअरिंगसाठी डिफ (diff) तपासते, /ponytail-audit संपूर्ण रिपॉझिटरी तपासते, /ponytail-debt तुम्ही पुढे ढकललेले शॉर्टकट्स गोळा करते आणि /ponytail-gain बेंचमार्क स्कोअरकार्ड प्रिंट करते. जे होस्ट्स फक्त नियम फाईल्स वाचतात, त्यांना कमांड्सशिवाय नियमांचा संच मिळतो. 16 ऑक्टोबर 2026 रोजी रिलीज झालेल्या v5.3.0 पासून, Claude Code ला प्रॉम्प्टच्या वर एक बँड मिळतो जो टास्कचा खर्च, कोडचा पुनर्वापर आणि चाचणीची स्थिती दर्शवतो. यासाठी Claude Code 2.1.290 किंवा त्यानंतरची आवृत्ती आवश्यक आहे; हे VS Code चॅट पॅनेल, क्लाउड सेशन्स किंवा claude -p मध्ये दिसत नाही आणि /ponytail band off ते लपवते. v5.3.2 पासून, /ponytail band import तुमची मागील Claude Code सेशन्स एकदा वाचते आणि त्यांना त्यांच्या खर्च, एजंट वेळ आणि टोकन्ससह बोर्डवर जोडते, जेणेकरून तुम्ही त्यांची तुलना नियमांतर्गत चालवलेल्या सेशन्सशी करू शकाल.

विश्वास ठेवण्यापूर्वी सोर्स कोड वाचण्यासाठी, ब्रांचऐवजी टॅग क्लोन करा. वरील शिडी ज्या टॅगवरून आली आहे तो हा आहे; सध्याची शब्दरचना वाचण्यासाठी 17 ऑक्टोबर 2026 रोजीचा सर्वात नवीन टॅग v5.3.2 वापरा:

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

Claude Code वर, हा प्रोजेक्ट प्लगइन इन्स्टॉल करण्याची पद्धत दस्तऐवजीकृत करतो आणि 17 ऑक्टोबर 2026 रोजी दस्तऐवजीकरण केल्यानुसार या दोन ओळी आहेत:

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

प्लगीन पाथ टॅगऐवजी डीफॉल्ट ब्रांचचे अनुसरण करतो, त्यामुळे तुमच्या एजंटला मार्गदर्शन करणाऱ्या सूचना सेशन्सच्या दरम्यान बदलू शकतात. अपडेट कमांडच्या सोयीसाठी तुम्हाला हा तडजोड स्वीकारावी लागते.

VPS वर 'lazy agent' स्वस्त का असतो

एजंटने लिहिलेला diff संभाषणातून बाहेर जात नाही. पुढच्या टर्नमध्ये, मॉडेलने तो पुन्हा वाचलेल्या प्रत्येक फाईलसह संदर्भाच्या (context) स्वरूपात वाचला जातो. 500 ओळींचा बदल प्रत्येक पुढील टर्नवर ताण निर्माण करतो, जोपर्यंत compaction जुन्या टर्नच्या जागी सारांश (summary) ठेवत नाही. केवळ तो टर्नच नाही ज्याने तो तयार केला, तर सर्वच टर्नवर याचा परिणाम होतो. म्हणूनच, अनियंत्रित refactor मुळे जसे सत्र पुढे जाते, तसा एजंट संथ आणि कमी हुशार वाटू लागतो: विंडो एजंटच्या स्वतःच्या आउटपुटमुळे भरून जाते, त्यामुळे तुमच्या प्रत्यक्ष कोडसाठी जागा कमी होते. हे नियंत्रणात ठेवणे म्हणजे coding agent च्या context window चे व्यवस्थापन होय.

टोकन्सचे बिल येताना आणि जाताना दोन्ही वेळी आकारले जाते, त्यामुळे अर्ध्या आकाराचा diff दुप्पट स्वस्त पडतो; एकदा तो लिहिला जातो तेव्हा आणि पुन्हा प्रत्येक टर्नमध्ये जेव्हा तो वाचला जातो. ही बचत तुमच्या बिलावर कशी परिणाम करते हे तुम्ही कसे पैसे भरता यावर अवलंबून आहे, कारण Pro किंवा Max सबस्क्रिप्शन अतिरिक्त टोकन्स फक्त त्याच्या वापर मर्यादेपर्यंतच सामावून घेते, त्यानंतर opt-in usage credits स्वतंत्रपणे आकारले जातात, तर per-token API बिलिंगमध्ये प्रत्येक टोकनसाठी शुल्क आकारले जाते. जर तुम्ही self-hosted सेटअपवर बिल तपासत असाल, तर instruction फाईल हे एक असे साधन आहे ज्याचा वापर करण्यासाठी काहीही खर्च येत नाही. AI agent चा खर्च नियंत्रित करणे हे आउटपुटच्या प्रमाणापासून सुरू होते आणि coding agent टोकन्स कसे खर्च करतो हे स्पष्ट करते की पुन्हा-वाचणे (re-reading) अपेक्षेपेक्षा जास्त महत्त्वाचे का आहे.

माणूस अजूनही diff वाचतो. 400 ओळींचा बदल जो 20 ओळींचा असायला हवा होता, तो रिव्ह्यूअरच्या एकाग्रतेवर ताण आणतो आणि एकाग्रता ही अशी गोष्ट आहे जी सर्वात आधी संपते. दिवसाच्या चौथ्या मोठ्या diff चा रिव्ह्यू कोणीही पहिल्या diff इतक्या काळजीपूर्वक करत नाही, त्यामुळे गरजेपेक्षा जास्त काम करणे केवळ वेळ वाया घालवत नाही. ते नकळतपणे त्या रिव्ह्यूची गुणवत्ता कमी करते ज्याचा उद्देश चुका शोधणे हा असतो.

सर्व्हरवर परिस्थिती बदलते, कारण एजंट अनेकदा कोणाच्याही देखरेखीशिवाय चालतो. tmux सेशनमध्ये किंवा टायमरवर काम करणारा एजंट तुम्ही पाहण्यापूर्वीच चुकीच्या निर्णयावर आधारित तासनतास काम करू शकतो. VPS वर coding agent चालवताना हा एक व्यावहारिक धोका आहे आणि म्हणूनच loop engineering करणारे लोक वैयक्तिक प्रॉम्प्ट्सपेक्षा standing instructions वर जास्त काळजी घेतात. always-on फाईल मधील नियम टर्न 200 ला लागू होतो. तुम्ही चॅटमध्ये टाईप केलेला नियम टर्न 3 ला लागू होतो. तो त्याच बॉक्सवर सुरू केलेल्या दुसऱ्या सेशनलाही लागू होतो, जे committed फाईल वाचते पण तुम्ही पहिल्या सेशनमध्ये टाईप केलेल्या गोष्टींचा वारसा घेत नाही, जरी दोन सत्रे एकमेकांना संदेश पाठवू शकत असली तरीही.

नवीन dependencies हा दुसरा छुपा खर्च आहे. पाचवी पायरी सांगते की जे इन्स्टॉल केलेले आहे तेच वापरा. एजंटने स्वतःहून जोडलेले प्रत्येक पॅकेज म्हणजे अशी गोष्ट आहे जी तुम्हाला नंतर पॅच करावी लागते आणि जी तुम्ही त्या रिपॉझिटरीमधून तयार केलेल्या प्रत्येक container image मध्ये समाविष्ट होते.

Ponytail च्या स्वतःच्या बेंचमार्क आकड्यांचे काय म्हणणे आहे

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

[
  {
    "label": "Lines of code",
    "v4_13_pct": 48,
    "v5_pct": 53
  },
  {
    "label": "Cost per run",
    "v4_13_pct": 16,
    "v5_pct": 26
  },
  {
    "label": "Wall clock time",
    "v4_13_pct": 38,
    "v5_pct": 41
  }
]

हा तक्ता प्रकल्पाचा सध्याचा एजंट-आधारित बेंचमार्क आहे, जो 7 ऑक्टोबर 2026 चा आहे. Opus 5.5 वर डिफॉल्ट एफर्टसह Headless Claude Code 2.1.288 च्या सत्रांमध्ये 39 कार्ये पूर्ण केली गेली. प्रत्येक कार्य आणि आर्मसाठी पाच वेळा रन, अशा एकूण 585 सत्रांमध्ये no skill, Ponytail v4.13.0 आणि Ponytail 5 यांची तुलना करण्यात आली. यातील 12 कार्ये ही tiangolo च्या full-stack-fastapi-template मधील फिचर तिकिटे आहेत, जे एक प्रत्यक्ष FastAPI आणि React रिपॉझिटरी आहे; याचे स्कोअरिंग मागे राहिलेल्या git diff वरून केले गेले. उर्वरित 18 सर्जिकल कार्ये लपवलेल्या तपासण्यांसह, सहा लहान ॲप विनंत्या आणि तीन "मला एक उदाहरण दाखवा" अशा विनंत्या होत्या. प्रत्येक आर्मसाठी Bash अक्षम (disabled) केले होते. Ponytail 5 मुळे आउटपुट टोकन्समध्ये 45 टक्क्यांनी घट झाली.

याची तुलना जून 2026 मध्ये प्रकल्पाने प्रकाशित केलेल्या सिंगल-शॉट आकड्यांशी करा. ते आकडे एका बेअर मॉडेलने नियमासह आणि नियमाशिवाय दिलेल्या पाच सामान्य प्रॉम्प्ट्सच्या उत्तरांवरून आले होते, जे वारंवार केलेल्या रनचे मध्यक (median) म्हणून नोंदवले गेले होते. त्यांनी Haiku, Sonnet आणि Opus वर 80 ते 94 टक्के कमी कोड दर्शवला होता आणि 17 जून 2026 च्या खर्च पडताळणीनुसार Haiku 63 टक्क्यांनी स्वस्त असल्याचे दिसून आले होते. Ponytail 5 साठी सध्याचा एजंट-आधारित निकाल 53 टक्के कमी ओळींचा कोड, 26 टक्के कमी खर्च आणि 41 टक्के कमी वेळ (wall clock time) असा आहे. प्रकल्पाने सिंगल-शॉटचा आकडा लवकर दुरुस्त केला. v4.8.4 नुसार, 29 जून 2026 पर्यंत, README मध्ये आधीच एजंट-आधारित निकाल मुख्य ठळक मजकूर म्हणून होता, "~54% less code (up to 94%)", आणि त्यासोबत एक टीप होती की आधीचे 80 ते 94 टक्के हे "प्रति-कार्य कमाल मर्यादा होती, सरासरी नाही", आणि त्यांनी सिंगल-शॉट आकडे "जुने सिंगल-शॉट आकडे" नावाच्या एका कोलॅप्स केलेल्या विभागात हलवले होते. तो विभाग हा फरक का आहे याबद्दल प्रामाणिक होता: सिंगल-शॉट बेसलाइन हे एक बेअर मॉडेल आहे जे "आपल्या उत्तरात गद्य आणि पर्यायांचा भडिमार करते", ज्याला हरवणे सोपे आहे. प्रत्यक्ष काम करणाऱ्या एजंटशी तुलना केल्यास हा फायदा कमी होतो. तो तरीही वास्तविक राहतो, जी अधिक उपयुक्त बाब आहे. जूनमधील त्या एजंट-आधारित रनमध्ये, Haiku 4.5 वर बारा तिकिटे आणि प्रत्येकी चार रनसह, 54 टक्के कमी ओळींचा निकाल आजच्या आकड्याच्या जवळ होता आणि सध्याच्या README मध्ये आता सिंगल-शॉट आकडे अजिबात नाहीत.

एक सावधगिरीची सूचना प्रकल्पाने स्वतःच दिली आहे, आणि तीच ठरवते की हे तुम्हाला उपयुक्त आहे की नाही. जिथे खरोखरच ओव्हर-बिल्डचा धोका असतो तिथे बचत सर्वाधिक होते आणि जिथे कोड आधीच किमान स्वरूपात आहे तिथे ती जवळजवळ शून्य असते. ऑक्टोबरचा प्रति-कार्य तक्ता हेच दर्शवतो, जिथे अनेक सर्जिकल कार्यांमध्ये तिन्ही आर्म्समध्ये ओळींची संख्या सारखीच होती. एका मॉडेलवर आणि एका होस्टवर, Bash बंद असताना केलेली 39 कार्ये तुमच्या रिपॉझिटरीचे भविष्य सांगू शकत नाहीत. जर हा आकडा तुमच्यासाठी महत्त्वाचा असेल, तर तुमच्या स्वतःच्या तिकिटांवर नियमासह आणि नियमाशिवाय तुलना करा आणि ओळी स्वतः मोजा.

आज तुम्ही काहीही इन्स्टॉल न करता वापरू शकता असा पॅटर्न

ही शिडी (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 च्या सध्याच्या रिलीजमधील कन्व्हेन्शननुसार, एक कमेंट shortcut: अशी टॅग केलेली असते, जी मर्यादेचे नाव आणि अपग्रेड कधी करायचे हे दर्शवते (जून रिलीजमध्ये, ज्यामध्ये v4.8.4 चा समावेश आहे, तिथे त्याऐवजी ponytail: असे टॅग केले आहे):

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

ही कमेंट दोन ओळींचे काम करते आणि असा प्रश्न निकाली काढते ज्यासाठी अन्यथा रिव्ह्यू सायकलचा वेळ खर्च झाला असता. हे पुढच्या वाचकाला सांगते की साधी आवृत्ती वापरण्याचा निर्णय जाणीवपूर्वक घेतला होता आणि ती अट स्पष्ट करते ज्या अंतर्गत तो निर्णय बदलणे आवश्यक आहे. याशिवाय, रिव्ह्यूअरला हे समजू शकत नाही की हा एक विचारपूर्वक घेतलेला शॉर्टकट आहे की एजंटकडून झालेली चूक, त्यामुळे त्यांना विचारणा करावी लागते.

तुम्ही हा ब्लॉक कुठे ठेवता हे तो काय सांगतो इतकेच महत्त्वाचे आहे. एजंट प्रत्येक रनला जी फाईल लोड करतो, ती प्रत्येक रनला दिशा देते, अगदी त्या रनला सुद्धा ज्या तुम्ही मॉनिटर करत नाही आहात. तो फरक तुमचा एजंट खरोखर फॉलो करेल अशी AGENTS.md लिहिणे या विषयाचा आहे आणि म्हणूनच हा पॅटर्न तुमच्या शेल हिस्ट्रीमध्ये ठेवण्याऐवजी कमिट केलेल्या फाईलमध्ये असणे आवश्यक आहे. मोनोरेपोमध्ये तो एकापेक्षा जास्त कमिट केलेल्या फाईल्समध्ये असणे गरजेचे आहे, कारण प्रत्येक पॅकेजसाठी एक AGENTS.md ठेवल्यामुळे प्रत्येक डिरेक्टरीचे नियम छोटे राहतात, अन्यथा एजंटला प्रत्येक रनला संपूर्ण ट्रीचे कन्व्हेन्शन्स वाचावे लागतात. मात्र, प्लेसमेंट ही खात्री देत नाही, आणि शिडीला अधिक कडक शब्दांची गरज आहे असा निष्कर्ष काढण्यापूर्वी एजंट आधीच लोड केलेला नियम का दुर्लक्षित करतो हे जाणून घेणे फायदेशीर ठरते.

नियम कोठे लागू होत नाही

हे ladder अशा कोडबेसमध्ये नवीन फीचर्स जोडण्यासाठी तयार केले आहे जिथे आधीच काम सुरू आहे, जिथे कोडचा पुनर्वापर (reuse) करणे सहसा शक्य आणि सहसा योग्य असते. हे नवीन (greenfield) प्रकल्पांसाठी तितकेसे योग्य नाही, कारण rung 2 वर पुनर्वापर करण्यासाठी काहीही नसते आणि rung 5 वर काहीही इन्स्टॉल केलेले नसते. एजंट अजूनही rung 1, standard library, platform feature किंवा one-liner वर थांबू शकतो, परंतु दोन सर्वात स्वस्त पर्याय उपलब्ध नसल्यामुळे, नवीन कोड लिहिण्याकडे अधिक कामे वळतात. जेव्हा तुम्हाला खरोखरच abstraction ची गरज असते, तेव्हाही हे ladder तितकेसे प्रभावी ठरत नाही. जर तुम्ही एकाच कॉपी केलेल्या ब्लॉकचा चौथा कॉलर जोडणार असाल, तर "shortest diff" तुम्हाला पाचवी कॉपी देईल.

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

कोणतीही सूचना प्रणाली तुम्हाला चुकीच्या समस्येच्या आकलनापासून वाचवू शकत नाही. या नियमावलीतील पहिलीच गोष्ट म्हणजे निर्णय घेण्यापूर्वी कोड समजून घेणे; हा सर्वात खर्चिक भाग आहे आणि जो मजकूर तुमच्यासाठी करू शकत नाही. चुकीच्या फंक्शनमधील minimal diff हा तरीही चुकीचाच उपाय असतो, आणि आता तो एक छोटा चुकीचा उपाय बनतो जो मंजूर करणे सोपे असते.

प्रामाणिक सारांश असा आहे की Ponytail हा एक काळजीपूर्वक लिहिलेला प्रॉम्प्ट आहे, जो चांगल्या प्रकारे वितरित केला आहे आणि त्याला क्रमांक जोडलेले आहेत. यात अशी कोणतीही गोष्ट नाही ज्यासाठी प्लगइनची आवश्यकता आहे. हा प्रकल्प तुम्हाला हे देतो की, कोणीतरी ही यादी योग्यरित्या लिहिली आहे, तिची प्रत्यक्ष रिपॉझिटरीवर चाचणी केली आहे आणि निकालासोबतच ती पद्धत प्रकाशित केली आहे.

FAQ

Ponytail हे Claude Code व्यतिरिक्त इतर एजंट्ससोबत काम करते का?

हो. हे अशा होस्टसाठी एक स्किल म्हणून उपलब्ध आहे जे स्किल लोड करतात. यामध्ये Claude Code, Codex, OpenCode, Gemini आणि README मध्ये नमूद केलेले इतर अनेक एजंट्स समाविष्ट आहेत. जे एडिटर्स फक्त rule files वाचतात पण स्किल लोड करत नाहीत, जसे की Cursor, Windsurf, Cline आणि Copilot, ते संबंधित rules directory मधून always-on ruleset घेतात, परंतु त्यांना slash commands मिळत नाहीत. दोन्ही बाबतीत मजकूर सारखाच असतो, त्यामुळे मुख्य फरक हा आहे की तुमचा होस्ट तो मजकूर प्रत्येक टर्नला संदर्भात (context) ठेवतो की फक्त स्किल ट्रिगर झाल्यावर.

एखादा लेझी (lazy) एजंट चाचण्या, पडताळणी किंवा सुरक्षा टाळेल का?

नाही, आणि ruleset मध्ये हे स्पष्टपणे नमूद केले आहे. त्याच्या "never lazy about" यादीमध्ये ट्रस्ट बाउंड्रीजवरील इनपुट व्हॅलिडेशन, डेटा लॉस टाळणारी एरर हँडलिंग, सुरक्षा आणि ॲक्सेसिबिलिटी यांचा समावेश आहे. तसेच, प्रत्येक नॉन-ट्रिव्हियल लॉजिकसाठी एक छोटी रन करण्यायोग्य चाचणी (runnable check) मागितली जाते. हा नियम अनावश्यक स्ट्रक्चर काढून टाकतो: जसे की कोणालाही नको असलेल्या ॲबस्ट्रॅक्शन्स आणि कोणालाही गरज नसलेल्या डिपेंडन्सीज. जर हे इन्स्टॉल केल्यानंतर तुमचा एजंट चाचण्या वगळत असेल, तर त्याचे कारण तुमच्या स्वतःच्या कॉन्फिगरेशनमधील एखादी दुसरी सूचना आहे जी या नियमापेक्षा वरचढ ठरत आहे. त्यामुळे एजंट जी फाईल शेवटी लोड करतो, ती तपासा.

प्रसिद्ध केलेले वेग आणि खर्चाचे आकडे विश्वासार्ह आहेत का?

हे प्रकल्पाचे स्वतःचे मोजमाप आहेत, जे त्यांच्या पद्धतीसह प्रसिद्ध केले आहेत आणि ते तसेच वाचले पाहिजेत. जून 2026 मधील सिंगल शॉट आकडे एका अशा बेअर मॉडेलशी तुलना करून काढले होते, जे आपल्या उत्तरात अनावश्यक मजकूर आणि पर्याय जोडत होते. त्यावेळच्या README मध्येच याला एक कमकुवत बेसलाईन म्हणून चिन्हांकित केले होते. सध्याचे एजंटिक आकडे Opus 5.5 वरील हेडलेस Claude Code सत्रांमधून आले आहेत. यामध्ये 39 टास्क आणि प्रत्येकी पाच रन आहेत, ज्यापैकी बारा फीचर्स एका FastAPI आणि React रिपॉझिटरीमधील आहेत. त्या सेटअपसाठी हे प्रामाणिक आकडे आहेत. हे तुमच्या कोडबेससाठीचे भाकीत नाही, कारण प्रकल्पाचे स्वतःचे प्रति-टास्क निकाल हे दर्शवतात की जो कोड आधीच किमान (minimal) आहे, तिथे बचत जवळजवळ शून्य होते.

फायदा मिळवण्यासाठी मला काही इन्स्टॉल करण्याची गरज आहे का?

नाही. ही शिडी (ladder) म्हणजे मजकूर आहे आणि तुमचा एजंट आधीच वाचत असलेल्या इन्स्ट्रक्शन फाईलमध्ये एक समतुल्य ब्लॉक पेस्ट केल्यास तुम्हाला बहुतेक परिणाम मिळतील. प्लगइन तुम्हाला अद्ययावत शब्दरचना, तीव्रतेची पातळी (intensity levels), रिव्ह्यू कमांड्स आणि अपडेटचा मार्ग देते. इन्स्टॉल खरोखर आवश्यक आहे का, हे तपासण्यासाठी कॉपी केलेला ब्लॉक आधी वापरून पाहणे हा पहिल्या पायरीवरील उपाय आहे.

अनअटेंडेड (unattended) एजंटला रात्रभर ओव्हर-बिल्डिंग करण्यापासून कसे थांबवू?

हा नियम चॅट मेसेजमध्ये टाकण्याऐवजी always-on इन्स्ट्रक्शन फाईलमध्ये टाका, जेणेकरून तो लांब रनच्या 200 व्या टर्नवरही लागू होईल, केवळ तिसऱ्या टर्नवर नाही. त्यानंतर होणारे नुकसान स्वतंत्रपणे मर्यादित करा: एजंटला तुमच्या मुख्य कॉपीऐवजी अशा चेकआउटवर काम करू द्या जे खराब झाले तरी चालेल आणि काहीही मर्ज करण्यापूर्वी मानवी diff रिव्ह्यू अनिवार्य करा. एक किमान diff नियम तुम्हाला किती वाचायचे आहे हे कमी करतो. तो काय मर्ज होईल हे ठरवत नाही आणि त्याने तसे करूही नये.