Ponytail AI coding agent என்றால் என்ன? முழு விளக்கம்

Ponytail என்றால் என்ன

Ponytail என்பது AI coding agent குறைவான குறியீட்டை (code) எழுதுவதை உறுதி செய்யும் ஒரு விதித் தொகுப்பு (rule set) ஆகும். இந்தத் திட்டம் தன்னை ஒரே வரியில் இவ்வாறு விவரிக்கிறது: "உங்கள் AI agent-ஐ அந்த அறையில் இருக்கும் மிகவும் சோம்பேறியான senior developer போல சிந்திக்க வைக்கிறது. நீங்கள் எழுதாத குறியீடே சிறந்த குறியீடு." இது MIT உரிமம் பெற்றது. இதற்குத் தனியாக runtime கிடையாது, இதில் எதுவும் தானாக இயங்காது. இது agent-ன் அறிவுறுத்தல்களில் சேர்க்கப்படும் உரை (text) ஆகும். திறன்களை (skills) ஏற்கும் host-களுக்கு இது ஒரு skill-ஆகவும், மற்றவற்றுக்கு எளிய விதி கோப்புகளாகவும் (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 அன்று வெளியிடப்பட்டது. ஜூன் 14 முதல் 29-க்குள் மட்டும் பத்து tags வெளியிடப்பட்டுள்ளன. இவ்வளவு வேகத்தில் வளரும் ஒரு திட்டம், நீங்கள் இதைப் படிக்கும் நேரத்திற்குள் மாறியிருக்கக்கூடும். எனவே, இதன் மேல் எதையாவது உருவாக்கும் முன் ஒரு குறிப்பிட்ட tag-ஐப் பயன்படுத்தவும் (pin).

கருவிக்கு முந்தைய சிந்தனை: உறுதியான முதல் படியில் நிறுத்துதல்

Ponytail-ன் அடிப்படை ஒரு முடிவெடுக்கும் ஏணி (decision ladder) ஆகும். எதையும் எழுதும் முன் agent இந்த ஏணியில் ஏறி, உறுதியாக இருக்கும் முதல் படியில் நின்றுவிடும்.

1. இது உண்மையில் தேவைதானா? இது YAGNI (you are not going to need it) கொள்கை. பதில் இல்லை என்றால், இதைத் தவிர்க்கவும்.
2. இது ஏற்கனவே இந்த codebase-ல் உள்ளதா? ஏற்கனவே உள்ள helper அல்லது pattern-ஐ மீண்டும் பயன்படுத்தவும்.
3. standard library-ல் இது உள்ளதா? அதைப் பயன்படுத்தவும்.
4. native platform வசதி இதைச் செய்கிறதா? அதைப் பயன்படுத்தவும்.
5. ஏற்கனவே நிறுவப்பட்ட dependency இதைத் தீர்க்கிறதா? அதைப் பயன்படுத்தவும்.
6. இதை ஒரே வரியில் செய்ய முடியுமா? ஒரே வரியில் முடிக்கவும்.
7. அதன் பிறகு மட்டும், வேலை செய்யும் குறைந்தபட்ச code-ஐ எழுதவும்.

இந்த வரிசைதான் வேலையைச் செய்கிறது, ஏணியின் எந்த ஒரு தனிப்படியும் அல்ல. ஒரு date picker-ஐ உருவாக்கச் சொன்னால், agent அதை எழுதும், ஏனெனில் அதைச் செய்யத்தான் அதற்கு உத்தரவிடப்பட்டது. ஆனால் இந்த ஏணி, முதலில் 4-வது படியைச் சரிபார்க்க வைக்கிறது. 4-வது படி, உலாவியில் ஏற்கனவே <input type="date"> இருப்பதாகக் கூறுகிறது. இந்தத் திட்டத்தின் சொந்த benchmark இந்தச் சூழலைத் துல்லியமாகக் காட்டுகிறது: இந்த விதி இல்லாமல் 404 வரிகளில் இருந்த date picker, விதியைப் பயன்படுத்தியபோது 23 வரிகளாகக் குறைந்தது. ஏனெனில், agent ஒரு புதிய component-ஐ உருவாக்குவதற்குப் பதிலாக native input-ஐப் பயன்படுத்தியது. இதே காரணத்தால், ஒரு colour picker 287 வரிகளிலிருந்து 23 வரிகளாகக் குறைந்தது. 2-வது படி அமைதியாகத் தோல்வியடையும் இடமாகும்; ஏனெனில் உங்களிடம் ஏற்கனவே உள்ள helper-ஐக் கண்டறிய முடியாத agent, மகிழ்ச்சியுடன் இரண்டாவது ஒன்றை உருவாக்கிவிடும். இந்த இடைவெளியைத்தான் உங்கள் codebase-ன் queryable map நிரப்ப முயல்கிறது.

இங்கே 'சோம்பேறித்தனம்' (lazy) என்பது கவனக்குறைவு என்று பொருளல்ல, விதிகளின் தொகுப்பு இதை நேரடியாகவே கூறுகிறது. அதன் "எப்போதும் சோம்பேறியாக இருக்கக்கூடாது" பட்டியலில், முடிவெடுக்கும் முன் சிக்கலைப் புரிந்துகொள்வது, trust boundaries-ல் input validation, தரவு இழப்பைத் தடுக்கும் error handling, பாதுகாப்பு, accessibility மற்றும் நீங்கள் பெயரிட்டுக் கேட்ட அனைத்தும் அடங்கும். மேலும், சிக்கலான logic-ன் ஒவ்வொரு பகுதிக்கும் ஒரு சிறிய runnable check-ஐயும் இது கோருகிறது. இந்த விதி கண்டுபிடிப்பைக் குறைக்கிறது, ஆனால் சரியான தன்மையைக் (correctness) குறைக்காது.

இந்த repository உண்மையில் எதை வழங்குகிறது

• AGENTS.md, எப்போதும் இயங்கும் ruleset. இதுவே முழு கருத்தாக்கமும் அடங்கிய கோப்பு; இதை ஐந்து நிமிடங்களில் படித்துவிடலாம்.
• skills/ponytail/SKILL.md, திறன் வரையறை (skill definition). இதில் lite, full அல்லது ultra ஆகிய வாதங்களுக்கான குறிப்புகள் உள்ளன.
• .cursor/rules/ மற்றும் .windsurf/rules/ போன்ற editor-சார்ந்த கோப்பகங்களில் உள்ள விதி கோப்புகள். இவை விதிகளை வாசிக்கும், ஆனால் திறன்களை ஏற்றாத (load) host-களுக்கானவை.
• hooks/, benchmarks/, examples/ மற்றும் scripts/.

Intensity வாதம், விதியின் தீவிரத்தன்மையை மாற்றுகிறது. lite நீங்கள் கேட்டதை உருவாக்கி, ஒரு வரியில் எளிமையான விருப்பத்தை பரிந்துரைக்கும். full என்பது default அமைப்பாகும், இது படிநிலையை (ladder) அமல்படுத்தும். ultra என்பது YAGNI தீவிரவாத அமைப்பாகும்: இது சேர்ப்பதை விட நீக்குவதையே விரும்பும், மேலும் தேவையின் அவசியத்தையே கேள்விக்குள்ளாக்கும்.

திறன் கொண்ட (skill-capable) host-கள் slash கட்டளைகளையும் பெறும். /ponytail நிலையை அமைக்கும், /ponytail-review அதிகப்படியான பொறியியல் (over-engineering) உள்ளதா என diff-ஐ சரிபார்க்கும், /ponytail-audit முழு repository-ஐயும் சரிபார்க்கும், /ponytail-debt நீங்கள் தள்ளிவைத்த குறுக்குவழிகளைச் சேகரிக்கும், மற்றும் /ponytail-gain benchmark scorecard-ஐ அச்சிடும். விதி கோப்புகளை மட்டும் வாசிக்கும் host-கள், எந்த கட்டளைகளும் இல்லாத 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 பாதை tag-க்கு பதிலாக default branch-ஐப் பின்தொடர்கிறது. எனவே, உங்கள் agent-ஐ வழிநடத்தும் அறிவுறுத்தல்கள், அமர்வுகளுக்கு இடையே மாறக்கூடும். update கட்டளையின் வசதிக்காக நீங்கள் ஏற்கும் சமரசம் இதுவாகும்.

VPS-ல் ஒரு lazy agent ஏன் சிக்கனமானது

ஒரு agent எழுதும் diff, உரையாடலை விட்டு வெளியேறுவதில்லை. அடுத்தடுத்த சுற்றுகளில், அது உருவாக்கிய கோப்புகளுடன் சேர்த்து, இந்த diff-ம் model-ஆல் மீண்டும் படிக்கப்படும் context-ஆக மாறுகிறது. எனவே, 500 வரிகள் கொண்ட ஒரு மாற்றம், அதை உருவாக்கிய சுற்றில் மட்டுமல்லாமல், அதற்குப் பின் வரும் ஒவ்வொரு சுற்றிலும் சுமையை ஏற்படுத்துகிறது. ஒரு runaway refactor-ஆல், உரையாடல் நீள நீள, agent மெதுவாகவும் மந்தமாகவும் செயல்படுவது இதனால்தான்: context window agent-ன் சொந்த வெளியீடுகளால் நிரம்பிவிடுகிறது, இதனால் உங்கள் உண்மையான குறியீட்டிற்கு (code) இடமில்லாமல் போகிறது. இதைக்கட்டுப்படுத்துவதுதான் coding agent-ன் context window-வை நிர்வகித்தல் என்பதன் முழு நோக்கமும்.

Tokens உள்ளே செல்லும்போது மற்றும் வெளியே வரும்போது என இருமுறை கணக்கிடப்படுகின்றன. எனவே, பாதியளவு அளவுள்ள ஒரு diff, இருமடங்கு சிக்கனமானது; அது எழுதப்படும்போது ஒருமுறை, மற்றும் அதை மீண்டும் படிக்கும் ஒவ்வொரு சுற்றிலும் ஒருமுறை எனச் சேமிப்பு கிடைக்கிறது. இந்தச் சேமிப்பு உங்கள் கட்டணத்தில் பிரதிபலிக்கிறதா என்பது நீங்கள் எவ்வாறு பணம் செலுத்துகிறீர்கள் என்பதைப் பொறுத்தது. ஏனெனில், flat Pro அல்லது Max subscription கூடுதல் tokens-ஐ ஈடுசெய்துவிடும், ஆனால் per-token API billing முறையில் ஒவ்வொரு token-க்கும் நீங்கள் பணம் செலுத்த வேண்டியிருக்கும். நீங்கள் self-hosted setup-ல் கட்டணத்தைக் கண்காணிப்பவர் என்றால், instruction file என்பது செலவில்லாத ஒரு கருவி. AI agent-ன் செலவைக் கட்டுப்படுத்துதல் என்பது output volume-ல் தொடங்குகிறது, மேலும் coding agent எவ்வாறு tokens-ஐச் செலவிடுகிறது என்பது, மீண்டும் மீண்டும் படிக்கும் செயல் ஏன் மக்கள் எதிர்பார்ப்பதை விட முக்கியமானது என்பதை விளக்குகிறது.

ஒரு மனிதர் இன்னும் அந்த diff-ஐப் படிக்கிறார். 20 வரிகளில் முடிந்திருக்க வேண்டிய 400 வரிகள் கொண்ட மாற்றம், மதிப்பாய்வு செய்பவரின் கவனத்தை வீணாக்குகிறது; கவனமே முதலில் தீர்ந்துபோகும் வளமாகும். ஒரு நாளில் நான்காவதாக வரும் நீண்ட diff-ஐ, முதல் diff-ஐப் பார்த்த அதே கவனத்துடன் யாரும் பார்ப்பதில்லை. எனவே, அளவுக்கு அதிகமாக உருவாக்குவது நேரத்தை மட்டும் வீணடிப்பதில்லை; அது பிழைகளைக் கண்டறிய வேண்டிய மதிப்பாய்வின் தரத்தையும் மெதுவாகக் குறைக்கிறது.

Server-ல் நிலைமை மாறுகிறது, ஏனெனில் பெரும்பாலும் யாரும் கவனிக்காத நிலையில் agent இயங்குகிறது. ஒரு tmux session-ல் அல்லது timer மூலம் இயங்கும் agent, நீங்கள் பார்ப்பதற்குள் ஒரு தவறான முடிவின் அடிப்படையில் பல மணிநேரம் வேலை செய்திருக்கலாம். இதுதான் VPS-ல் coding agent-ஐ இயக்குவதில் உள்ள நடைமுறை ஆபத்து. இதனால்தான் loop engineering செய்பவர்கள், தனிப்பட்ட prompts-ஐ விட, நிலையான அறிவுறுத்தல்களுக்கு (standing instructions) அதிக முக்கியத்துவம் கொடுக்கிறார்கள். always-on கோப்பில் உள்ள ஒரு விதி, 200-வது சுற்றிலும் பொருந்தும். நீங்கள் chat-ல் தட்டச்சு செய்த விதி, 3-வது சுற்றில் மட்டுமே பொருந்தும். அதே server-ல் நீங்கள் தொடங்கும் இரண்டாவது session-க்கும் இது பொருந்தும்; அது committed கோப்பைப் படிக்கும், ஆனால் முதல் session-ல் நீங்கள் தட்டச்சு செய்த எதையும் அது எடுத்துக்கொள்ளாது, இரண்டு sessions-ம் ஒன்றுடன் ஒன்று செய்தி பரிமாறிக்கொள்ள முடிந்தாலும் கூட.

புதிய dependencies என்பது மற்றொரு மறைமுகச் செலவாகும். ஏற்கனவே நிறுவப்பட்டவற்றைப் பயன்படுத்துவதே சிறந்தது. ஒரு 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 சிறிய அளவிலான prompts-க்கு அந்த விதியைப் பயன்படுத்தியும் பயன்படுத்தாமலும் அளித்த பதில்களின் median மதிப்புகளைக் கொண்டது; இவை ஜூன் 13 மற்றும் 17, 2026 தேதியிட்ட சோதனைகளிலிருந்து எடுக்கப்பட்டவை. Agentic நெடுவரிசை, tiangolo-வின் full-stack-fastapi-template-ஐ ஒரு headless Claude Code session மூலம் திருத்தியதன் அடிப்படையில் உருவானது. இது ஒரு உண்மையான FastAPI மற்றும் React repository ஆகும். இதில் பன்னிரண்டு feature tickets-கள், Haiku 4.5-ல் தலா நான்கு முறை இயக்கப்பட்டு, அதன் git diff முடிவுகள் மதிப்பிடப்பட்டன.

இரண்டாவது நெடுவரிசையைப் படிக்கவும். Agentic முடிவானது, single shot அமைப்பில் உள்ள 93 சதவீதம் மற்றும் 74 சதவீத அளவீடுகளுடன் ஒப்பிடும்போது, 54 சதவீதம் குறைவான வரிகள், 20 சதவீதம் குறைவான செலவு மற்றும் 27 சதவீதம் குறைவான wall clock நேரத்தைக் கொண்டுள்ளது. இதற்கான காரணத்தை README வெளிப்படையாகக் கூறுகிறது: single shot baseline என்பது "பல விருப்பங்கள் மற்றும் விளக்கங்களுடன் பதிலளிக்கும்" ஒரு bare model ஆகும், இதை முந்துவது எளிது. உண்மையான வேலையைச் செய்யும் ஒரு உண்மையான agent-உடன் ஒப்பிடும்போது, இந்த வெற்றி குறைகிறது. அதே சமயம், இது உண்மையானதாகவே நீடிக்கிறது, இதுவே மிகவும் பயனுள்ள தகவலாகும்.

இதில் ஒரு எச்சரிக்கை உள்ளது, இதுவே இந்தத் திட்டம் உங்களுக்குப் பயன்படுமா என்பதைத் தீர்மானிக்கும் காரணியாகும். ஏற்கனவே மிகக் குறைந்த அளவில் உள்ள குறியீட்டில் (code) இந்தச் சேமிப்பு பூஜ்ஜியத்திற்கு அருகில் இருக்கும், ஆனால் தேவையற்ற அதிகப்படியான குறியீடு (over-build) உள்ள இடங்களில் சேமிப்பு அதிகமாக இருக்கும். ஒரு Python மற்றும் TypeScript repository-ல் உள்ள பன்னிரண்டு tickets-கள் உங்கள் repository-ன் செயல்பாட்டை முன்கூட்டியே தீர்மானிக்காது. இந்த எண்கள் உங்களுக்கு முக்கியமென்றால், உங்கள் சொந்த tickets-களைக் கொண்டு, அந்த விதியைப் பயன்படுத்தியும் பயன்படுத்தாமலும் ஒப்பீடு செய்து, வரிகளை நீங்களே எண்ணிப் பாருங்கள்.

எந்தவொரு மென்பொருளையும் நிறுவத் தேவையில்லாமல் நீங்கள் இன்று நகலெடுக்கக்கூடிய முறை

இந்த ஏணி (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-ன் மரபு என்பது அந்த கருவியின் பெயரைக் கொண்ட ஒரு குறிப்பு (comment) ஆகும்:

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

இந்தக் குறிப்பு இரண்டு வரிகள் கொண்ட பணியாகும், இது இல்லையெனில் ஒரு மறுஆய்வு சுழற்சியை (review cycle) செலவழிக்க வேண்டிய ஒரு கேள்வியைத் தீர்க்கிறது. இது அடுத்த வாசகருக்கு, எளிமையான பதிப்பு ஒரு திட்டமிட்ட முடிவு என்பதையும், அந்த முடிவு எந்த நிபந்தனையின் கீழ் செல்லுபடியாகாது என்பதையும் கூறுகிறது. இது இல்லையென்றால், ஒரு மதிப்பாய்வாளரால் திட்டமிட்ட குறுக்குவழியை, ஏஜென்ட் மறந்துவிட்ட ஒன்றிலிருந்து வேறுபடுத்திப் பார்க்க முடியாது, எனவே அவர்கள் அதைக் கேட்க வேண்டியிருக்கும்.

நீங்கள் அந்தத் தொகுதியை எங்கே வைக்கிறீர்கள் என்பது அது என்ன சொல்கிறது என்பதைப் போலவே முக்கியமானது. ஏஜென்ட் ஒவ்வொரு முறையும் இயக்கும் கோப்பு, நீங்கள் கவனிக்காதவை உட்பட ஒவ்வொரு செயல்பாட்டையும் வழிநடத்துகிறது. அந்த வேறுபாடுதான் உங்கள் ஏஜென்ட் உண்மையில் பின்பற்றும் AGENTS.md-ஐ எழுதுதல் என்பதன் பொருள், மேலும் இந்த முறை உங்கள் ஷெல் வரலாற்றில் (shell history) இருப்பதை விட, ஒரு கமிட் செய்யப்பட்ட கோப்பில் இருக்க வேண்டியதற்கான காரணம் இதுதான். ஒரு monorepo-வில் இது ஒன்றுக்கும் மேற்பட்ட கமிட் செய்யப்பட்ட கோப்புகளில் இருக்க வேண்டும், ஏனெனில் ஒவ்வொரு தொகுப்பிற்கும் ஒரு AGENTS.md என்பது ஒவ்வொரு கோப்பகத்தின் விதிகளையும் சுருக்கமாக வைத்திருக்கிறது, மாறாக ஏஜென்ட் ஒவ்வொரு முறையும் முழு மரத்தின் மரபுகளையும் படிக்க வேண்டிய அவசியத்தை ஏற்படுத்துகிறது. இருப்பினும், இடமளிப்பது ஒரு உத்தரவாதம் அல்ல, எனவே ஏஜென்ட் ஏற்கனவே ஏற்றப்பட்ட விதியை ஏன் கடந்து செல்கிறது என்பதை அறிந்துகொள்வது அவசியம், ஏணிக்கு வலுவான சொற்கள் தேவை என்று முடிவு செய்வதற்கு முன்பு இதைத் தெரிந்துகொள்ளுங்கள்.

விதி எப்போது சரியாக இருப்பதில்லையோ அந்த இடம்

ஏற்கனவே இருக்கும் codebase-ல் feature வேலைகளைச் செய்வதற்கு இந்த ladder வடிவமைக்கப்பட்டுள்ளது, அங்கு code reuse பொதுவாகக் கிடைக்கும் மற்றும் அதுவே சரியான அணுகுமுறையாக இருக்கும். இது ஒரு greenfield project-க்கு சரியாகப் பொருந்தாது, ஏனெனில் rung 2-ல் reuse செய்வதற்கு எதுவுமில்லை மற்றும் rung 5-ல் எதையும் install செய்திருக்க மாட்டீர்கள், எனவே agent ஒவ்வொரு முறையும் rung 7-க்குச் சென்றுவிடும். உங்களுக்கு உண்மையிலேயே abstraction தேவைப்படும் தருணத்திலும் இது சரியாகப் பொருந்தாது. ஒரே மாதிரியான copied block-க்கு நான்காவது caller-ஐச் சேர்க்க முற்படும்போது, "shortest diff" உங்களுக்கு ஐந்தாவது நகலைத் தரும்.

ultra நிலை உங்கள் தேவைகளைச் சவாலுக்கு உட்படுத்தும். அந்த நிலை அதற்காகவே உருவாக்கப்பட்டது, ஆனால் நீங்கள் ஏற்கனவே ஒரு முடிவை எடுத்துவிட்டு வேலையை முடிக்க விரும்பும்போது இது ஒரு உண்மையான செலவாக (cost) அமையும். சாதாரண வேலைகளுக்கு full-ஐப் பயன்படுத்துங்கள், ஒரு feature request-தான் சிக்கல் என்று நீங்கள் சந்தேகப்படும்போது ultra-ஐ நாடுங்கள்.

எந்தவொரு instruction block-உம் சிக்கலைத் தவறாகப் புரிந்துகொள்வதிலிருந்து உங்களைக் காப்பாற்றாது. விதிகள் தொகுப்பின் முதல் அம்சமே முடிவெடுப்பதற்கு முன் code-ஐப் புரிந்துகொள்வதுதான்; இதுவே கடினமான பகுதி மற்றும் இதை உரை (text) உங்களுக்குச் செய்து தராது. தவறான function-ல் செய்யப்படும் ஒரு minimal diff என்பது தவறான தீர்வே, இப்போது அது எளிதாக அங்கீகரிக்கக்கூடிய ஒரு சிறிய தவறான தீர்வாக மாறிவிடுகிறது.

நேர்மையான சுருக்கம் என்னவென்றால், Ponytail என்பது கவனமாக எழுதப்பட்ட, முறையாக விநியோகிக்கப்பட்ட மற்றும் எண்களைக் கொண்ட ஒரு prompt ஆகும். இதில் எதற்கும் plugin தேவையில்லை. இந்த project உங்களுக்குத் தருவது என்னவென்றால், யாரோ ஒருவர் இந்த வரிசையைச் சரியாக எழுதி, அதை ஒரு உண்மையான repository-ல் சோதித்து, அந்த முறையை முடிவுகளுடன் சேர்த்துப் பதிப்பித்திருப்பதுதான்.

FAQ

Ponytail, Claude Code தவிர பிற agents-உடன் வேலை செய்யுமா?

ஆம். Skills-ஐ ஏற்கும் hosts-களுக்கான ஒரு skill-ஆக இது releases செய்யப்படுகிறது; Claude Code, Codex, OpenCode, Gemini மற்றும் README-ல் குறிப்பிடப்பட்டுள்ள பிற பலவும் இதில் அடங்கும். Cursor, Windsurf, Cline மற்றும் Copilot போன்ற rule files-ஐ வாசிக்கும் ஆனால் skills-ஐ ஏற்றாத editors, தொடர்புடைய rules directory-லிருந்து always-on ruleset-ஐ எடுத்துக்கொள்ளும், ஆனால் slash commands-ஐப் பெறாது. இரண்டு முறைகளிலும் உரை (text) ஒன்றாகவே இருக்கும்; எனவே, உங்கள் host அந்த உரையை ஒவ்வொரு turn-லும் context-ல் வைத்திருக்கிறதா அல்லது ஒரு skill தூண்டப்படும்போது மட்டும் வைத்திருக்கிறதா என்பதே உண்மையான வித்தியாசம்.

ஒரு lazy agent சோதனைகள் (tests), சரிபார்ப்பு (validation) அல்லது பாதுகாப்பைத் தவிர்த்துவிடுமா?

இல்லை, ruleset இதை நேரடியாகக் குறிப்பிடுகிறது. அதன் "never lazy about" பட்டியலில், trust boundaries-ல் உள்ள input validation, தரவு இழப்பைத் தடுக்கும் error handling, பாதுகாப்பு மற்றும் அணுகல்தன்மை (accessibility) ஆகியவை உள்ளன. மேலும், சிக்கலான logic-ன் ஒவ்வொரு பகுதிக்கும் ஒரு சிறிய runnable check-ஐ இது கோருகிறது. இந்த rule நீக்குவது தேவையற்ற கட்டமைப்புகளை மட்டுமே: யாரும் கோராத abstractions மற்றும் யாருக்கும் தேவைப்படாத dependencies. நீங்கள் இதை நிறுவிய பிறகு உங்கள் agent சோதனைகளைத் தவிர்க்கத் தொடங்கினால், அதற்கு உங்கள் சொந்த config-ல் உள்ள மற்றொரு instruction-தான் காரணம்; அது இந்த rule-ஐ விட முன்னுரிமை பெறுகிறது. எனவே, agent கடைசியாக ஏற்றும் கோப்பைச் சரிபார்க்கவும்.

வெளியிடப்பட்ட வேகம் மற்றும் செலவு குறித்த எண்கள் நம்பகமானவையா?

அவை திட்டத்தின் சொந்த அளவீடுகள், அவற்றின் முறைகளுடன் வெளியிடப்பட்டுள்ளன, அவற்றை அவ்வாறே புரிந்துகொள்ள வேண்டும். Single shot புள்ளிவிவரங்கள், விருப்பங்கள் மற்றும் விளக்கங்களுடன் பதிலளிக்கும் ஒரு bare model-உடன் ஒப்பிடப்படுகின்றன; இதை README-யே ஒரு பலவீனமான baseline என்று குறிப்பிடுகிறது. Agentic புள்ளிவிவரங்கள், ஒரு FastAPI மற்றும் React repository-ல், பன்னிரண்டு tickets, தலா நான்கு runs, Haiku 4.5-ல் இயக்கப்பட்ட headless Claude Code session-லிருந்து பெறப்பட்டவை. அந்த அமைப்பிற்கு அவை உண்மையான எண்கள். அவை உங்கள் codebase-க்கான முன்னறிவிப்பு அல்ல, ஏனெனில் ஏற்கனவே minimal-ஆக உள்ள code-ல் சேமிப்பு கிட்டத்தட்ட பூஜ்ஜியமாகிவிடும் என்றும் அந்தத் திட்டம் கூறுகிறது.

பலனைப் பெற நான் எதையாவது நிறுவ வேண்டுமா?

இல்லை. Ladder என்பது உரை (text) மட்டுமே, உங்கள் agent ஏற்கனவே வாசிக்கும் instruction file-ல் ஒரு சமமான தொகுதியை (block) நகலெடுத்து ஒட்டுவது உங்களுக்கு பெரும்பாலான பலனைத் தரும். இந்த plugin உங்களுக்கு பராமரிக்கப்படும் சொற்கள், தீவிர நிலைகள் (intensity levels), review commands மற்றும் update path ஆகியவற்றை வழங்குகிறது. நகலெடுக்கப்பட்ட தொகுதியை முதலில் முயற்சிப்பது, நிறுவல் அவசியமா என்ற கேள்விக்கான முதல் படியாகும் (rung 1).

கவனிக்கப்படாத ஒரு agent இரவு நேரத்தில் அளவுக்கு அதிகமாக உருவாக்குவதைத் தடுப்பது எப்படி?

Rule-ஐ chat message-ல் வைக்காமல் always-on instruction file-ல் வைக்கவும், அப்போதுதான் அது நீண்ட run-ன் 200-வது turn-லும் செயல்படும், 3-வது turn-ல் மட்டும் அல்ல. பிறகு சேதத்தைத் தனித்தனியாகக் கட்டுப்படுத்தவும்: உங்கள் ஒரே நகலுக்குப் பதிலாக, அது சிதைக்க அனுமதிக்கப்பட்ட ஒரு checkout-ஐ agent-க்கு வழங்கவும், எதையும் merge செய்வதற்கு முன் மனிதரின் diff review-ஐக் கட்டாயமாக்கவும். ஒரு minimal diff rule நீங்கள் படிக்க வேண்டிய அளவைக் குறைக்கிறது. அது எதைச் சேர்க்க வேண்டும் என்பதை முடிவு செய்யாது, செய்யவும்கூடாது.