Ponytail AI கோடிங் ஏஜென்ட் என்றால் என்ன?

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

Ponytail என்பது AI கோடிங் ஏஜென்ட் குறைவான குறியீட்டை (code) எழுதச் செய்யும் ஒரு விதித் தொகுப்பாகும். இந்தத் திட்டம் தன்னை ஒரே வரியில் இவ்வாறு விவரிக்கிறது: "உங்கள் AI ஏஜென்ட்டை அந்த அறையில் இருக்கும் மிகவும் சோம்பேறியான சீனியர் டெவலப்பரைப் போல சிந்திக்க வைக்கிறது. நீங்கள் எழுதாத குறியீடே சிறந்த குறியீடு." இது MIT உரிமம் பெற்றது. இதற்குத் தனியாக ரன்டைம் (runtime) கிடையாது, இதில் எதுவும் இயங்குவதில்லை. இது ஏஜென்ட்டின் அறிவுறுத்தல்களில் சேர்க்கப்படும் உரை (text) ஆகும். திறன்களை (skills) ஏற்கும் ஹோஸ்ட்களுக்கு ஒரு திறனாகவும், மற்றவற்றுக்கு எளிய விதி கோப்புகளாகவும் இது தொகுக்கப்பட்டுள்ளது.

இதன் களஞ்சியம் (repository) DietrichGebert/ponytail ஆகும். இது 12 June 2026 அன்று உருவாக்கப்பட்டது மற்றும் 1 August 2026-க்குள் 90,000 நட்சத்திரங்களைக் கடந்தது. 1 August 2026 நிலவரப்படி, சமீபத்திய டேக் செய்யப்பட்ட ரிலீஸ் (tagged release) v4.8.4 ஆகும், இது 29 June 2026 அன்று வெளியிடப்பட்டது. ஜூன் 14 முதல் 29 வரை மட்டுமே பத்து டேக்குகள் ரிலீஸ்கள் பக்கத்தில் பட்டியலிடப்பட்டுள்ளன. இவ்வளவு வேகத்தில் நகரும் ஒரு திட்டம், நீங்கள் இதைப் படிக்கும் நேரத்திற்குள் மாறியிருக்கக்கூடும். எனவே, இதன் மேல் எதையும் உருவாக்கும் முன் ஒரு குறிப்பிட்ட டேக்கை (tag) பின் (pin) செய்யவும்.

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

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

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-ஐ உருவாக்கச் சொன்னால், ஏஜென்ட் அதை எழுதும், ஏனெனில் அதைச் செய்யத்தான் அதற்கு உத்தரவிடப்பட்டது. இந்த ஏணி, முதலில் 4-வது படியைச் சரிபார்க்க வைக்கிறது. 4-வது படி, browser-ல் ஏற்கனவே <input type="date"> இருப்பதாகக் கூறுகிறது. இந்தத் திட்டத்தின் benchmark-ல் இதே நிகழ்வு குறிப்பிடப்பட்டுள்ளது: இந்த விதி இல்லாமல் 404 வரிகளில் இருந்த date picker, இந்த விதியைப் பயன்படுத்தியபோது 23 வரிகளில் முடிந்தது. ஏனெனில், ஏஜென்ட் ஒரு component-ஐ உருவாக்குவதற்குப் பதிலாக native input-ஐப் பயன்படுத்தியது. இதே காரணத்தால், ஒரு colour picker 287 வரிகளிலிருந்து 23 வரிகளாகக் குறைந்தது.

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

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

• AGENTS.md, எப்போதும் இயங்கும் விதிகள் தொகுப்பு; இது ஐந்து நிமிடங்களில் வாசிக்கக்கூடிய ஒரே கோப்பில் முழு கருத்தையும் கொண்டுள்ளது.
• skills/ponytail/SKILL.md, திறன் வரையறை; இது lite, full அல்லது ultra ஆகிய ஆர்கியூமென்ட் குறிப்புகளைக் கொண்டுள்ளது.
• .cursor/rules/ மற்றும் .windsurf/rules/ போன்ற எடிட்டர் சார்ந்த கோப்பகங்களின் கீழ் உள்ள விதி கோப்புகள்; இவை விதிகளை வாசிக்கும் ஆனால் திறன்களை ஏற்றாத ஹோஸ்ட்களுக்காக உள்ளன.
• hooks/, benchmarks/, examples/ மற்றும் scripts/.

intensity ஆர்கியூமென்ட், விதியின் கடுமையை மாற்றியமைக்கிறது. lite நீங்கள் கேட்டதை உருவாக்குகிறது மற்றும் ஒரு வரியில் மெதுவான விருப்பத்தை குறிப்பிடுகிறது. full என்பது இயல்புநிலை அமைப்பாகும், இது படிநிலை அமைப்பை அமல்படுத்துகிறது. ultra என்பது YAGNI தீவிரவாத அமைப்பாகும்: இது சேர்ப்பதை விட நீக்குவதையே விரும்புகிறது, மேலும் இது தேவையை நோக்கியே கேள்வி எழுப்பும்.

திறன் கொண்ட ஹோஸ்ட்கள் ஸ்லாஷ் கட்டளைகளையும் (slash commands) பெறுகின்றன. /ponytail அளவை அமைக்கிறது, /ponytail-review மிகையான பொறியியல் (over-engineering) உள்ளதா என டிஃப் (diff) மூலம் சரிபார்க்கிறது, /ponytail-audit முழு களஞ்சியத்தையும் சரிபார்க்கிறது, /ponytail-debt நீங்கள் தள்ளிவைத்த குறுக்குவழிகளைச் சேகரிக்கிறது, மற்றும் /ponytail-gain பெஞ்ச்மார்க் மதிப்பெண் அட்டையை அச்சிடுகிறது. விதி கோப்புகளை மட்டும் வாசிக்கும் ஹோஸ்ட்கள் எந்த கட்டளைகளும் இன்றி விதிகள் தொகுப்பை மட்டுமே பெறும்.

நீங்கள் நம்புவதற்கு முன் மூலக் குறியீட்டை (source) வாசிக்க, பிராஞ்சிற்கு (branch) பதிலாக டேக்கை (tag) குளோன் (clone) செய்யவும்:

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

Claude Code-இல், இந்தத் திட்டம் அதற்குப் பதிலாக ஒரு பிளகின் நிறுவலை ஆவணப்படுத்துகிறது. 1 August 2026 அன்று ஆவணப்படுத்தப்பட்டபடி இந்த இரண்டு வரிகள் உள்ளன:

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

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

VPS-இல் ஒரு சோம்பேறி ஏஜென்ட் ஏன் சிக்கனமானது

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

டோக்கன்கள் உள்ளே செல்லும்போதும் வெளியே வரும்போதும் கட்டணம் வசூலிக்கப்படுகின்றன, எனவே பாதியளவு அளவுள்ள diff இருமடங்கு மலிவானது; அது எழுதப்படும்போது ஒரு முறையும், அதை மீண்டும் வாசிக்கும் ஒவ்வொரு கட்டத்திலும் ஒரு முறையும் செலவு குறைகிறது. நீங்கள் ஒரு self-hosted அமைப்பில் கட்டணத்தைக் கண்காணிப்பவர் என்றால், instruction கோப்பு என்பது செலவில்லாத ஒரு கருவியாகும். AI ஏஜென்ட்டின் செலவைக் கட்டுப்படுத்துதல் என்பது வெளியீட்டு அளவிலிருந்து தொடங்குகிறது, மேலும் கோடிங் ஏஜென்ட் தனது டோக்கன்களை எவ்வாறு செலவிடுகிறது என்பது ஏன் மீண்டும் வாசிப்பது மக்கள் எதிர்பார்ப்பதை விட முக்கியமானது என்பதை விளக்குகிறது.

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

ஒரு சர்வரில் நிலைமை மாறுகிறது, ஏனெனில் ஏஜென்ட் பெரும்பாலும் யாரும் கவனிக்காத நிலையில் இயங்குகிறது. ஒரு tmux அமர்வில் அல்லது டைமரில் இயங்கும் ஏஜென்ட், நீங்கள் அதைப் பார்ப்பதற்கு முன்பே ஒரு தவறான முடிவின் அடிப்படையில் பல மணிநேரம் செயல்படக்கூடும். இதுதான் VPS-இல் கோடிங் ஏஜென்ட்டை இயக்குவதில் உள்ள நடைமுறை அபாயம், இதனால்தான் loop engineering செய்பவர்கள் தனிப்பட்ட பிராம்ப்டுகளை விட, நிலையான அறிவுறுத்தல்களில் (standing instructions) அதிக கவனம் செலுத்துகிறார்கள். எப்போதும் இயங்கும் கோப்பில் உள்ள ஒரு விதி, 200-வது கட்டத்திற்கும் பொருந்தும். நீங்கள் சாட்டில் தட்டச்சு செய்த விதி, 3-வது கட்டத்திற்கு மட்டுமே பொருந்தும்.

புதிய டிபென்டென்சிகள் (dependencies) மற்றொரு மறைமுகச் செலவாகும். ஏற்கனவே நிறுவப்பட்டவற்றைப் பயன்படுத்துவதே சிறந்தது. ஒரு ஏஜென்ட் தனது சொந்த முயற்சியில் சேர்க்கும் ஒவ்வொரு தொகுப்பும் (package), நீங்கள் பின்னர் பேட்ச் செய்ய வேண்டிய ஒன்றாகவும், அந்த ரெபாசிட்டரியிலிருந்து நீங்கள் உருவாக்கும் ஒவ்வொரு container இமேஜிலும் இடம்பெறும் ஒன்றாகவும் மாறுகிறது.

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

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

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

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

இந்த ஏணி (ladder) உரை வடிவில் உள்ளது, எனவே இந்த யோசனையைப் பயன்படுத்த உங்களுக்கு எந்த பிளகினும் (plugin) தேவையில்லை. உங்கள் ஏஜென்ட் ஏற்கனவே வாசிக்கும் அறிவுறுத்தல் கோப்பில், அது 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) இல்லாமல், ஒரு கமிட் செய்யப்பட்ட (committed) கோப்பில் இருக்க வேண்டியதற்கான காரணமும் இதுவேயாகும்.

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

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

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

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

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

FAQ

Ponytail, Claude Code தவிர பிற ஏஜெண்டுகளுடன் வேலை செய்யுமா?

ஆம். இது ஸ்கில்களை (skills) ஏற்றி இயக்கும் ஹோஸ்ட்களுக்கான ஒரு ஸ்கிலாக வெளியிடப்படுகிறது. Claude Code, Codex, OpenCode, Gemini மற்றும் README-ல் குறிப்பிடப்பட்டுள்ள பிற ஹோஸ்ட்கள் இதில் அடங்கும். Cursor, Windsurf, Cline மற்றும் Copilot போன்ற எடிட்டர்கள் ரூல் ஃபைல்களை (rule files) வாசிக்கும், ஆனால் ஸ்கில்களை ஏற்றாது. இவை அந்தந்த ரூல்ஸ் டைரக்டரியிலிருந்து always-on ரூல்செட்டை எடுத்துக்கொள்ளும், ஆனால் slash commands வேலை செய்யாது. இரண்டு முறைகளிலும் டெக்ஸ்ட் ஒன்றாகவே இருக்கும். எனவே, ஒவ்வொரு முறையும் உங்கள் ஹோஸ்ட் அந்த டெக்ஸ்ட்டை கான்டெக்ஸ்ட்டில் வைத்திருக்கிறதா அல்லது ஸ்கில் தூண்டப்படும்போது மட்டும் பயன்படுத்துகிறதா என்பதே இதில் உள்ள முக்கிய வேறுபாடு.

ஒரு சோம்பேறி ஏஜென்ட் (lazy agent) டெஸ்ட்கள், வேலிடேஷன் அல்லது பாதுகாப்பைத் தவிர்த்துவிடுமா?

இல்லை, இதை ரூல்செட் தெளிவாகக் குறிப்பிடுகிறது. அதன் "never lazy about" பட்டியலில், டிரஸ்ட் பவுண்டரிகளில் (trust boundaries) இன்புட் வேலிடேஷன், தரவு இழப்பைத் தடுக்கும் எர்ரர் ஹேண்ட்லிங், பாதுகாப்பு மற்றும் அணுகல்தன்மை ஆகியவை உள்ளன. மேலும், சிக்கலான லாஜிக் ஒவ்வொன்றிற்கும் ஒரு சிறிய ரன்னபிள் செக் (runnable check) செய்யுமாறு அது கோருகிறது. இந்த ரூல் நீக்குவது தேவையற்ற கட்டமைப்புகளை மட்டுமே; அதாவது, யாரும் கேட்காத அப்ஸ்ட்ராக்ஷன்கள் மற்றும் தேவையில்லாத டிபென்டென்சிகளை இது நீக்குகிறது. நீங்கள் இதை இன்ஸ்டால் செய்த பிறகு உங்கள் ஏஜென்ட் டெஸ்ட்களைத் தவிர்க்கத் தொடங்கினால், அதற்கு உங்கள் சொந்த கான்ஃபிக் ஃபைலில் உள்ள மற்றொரு இன்ஸ்ட்ரக்ஷன் காரணமாக இருக்கலாம். எனவே, ஏஜென்ட் கடைசியாக லோட் செய்யும் ஃபைலைச் சரிபார்க்கவும்.

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

இவை திட்டத்தின் சொந்த அளவீடுகள், அவற்றின் முறைகளுடன் வெளியிடப்பட்டுள்ளன. அவற்றை அப்படியே எடுத்துக்கொள்ள வேண்டும். சிங்கிள் ஷாட் (single shot) புள்ளிவிவரங்கள், ஆப்ஷன்கள் மற்றும் கமெண்டரிகளுடன் பதிலளிக்கும் ஒரு பேயர் மாடலுடன் (bare model) ஒப்பிடப்படுகின்றன. இதை README-யே ஒரு பலவீனமான பேஸ்லைனாகக் குறிப்பிடுகிறது. ஏஜென்டிக் (agentic) புள்ளிவிவரங்கள், ஒரு FastAPI மற்றும் React ரெபாசிட்டரியில், Haiku 4.5-ல், பன்னிரண்டு டிக்கெட்டுகள் மற்றும் தலா நான்கு ரன்களில், ஹெட்லெஸ் (headless) Claude Code செஷனில் இருந்து பெறப்பட்டவை. அந்த அமைப்பிற்கு அவை உண்மையான எண்கள். இவை உங்கள் கோட்பேஸிற்கான (codebase) முன்னறிவிப்பு அல்ல, ஏனெனில் ஏற்கனவே மிகக் குறைந்த அளவில் உள்ள கோடில் சேமிப்பு கிட்டத்தட்ட பூஜ்ஜியமாக இருக்கும் என்றும் இந்தத் திட்டம் கூறுகிறது.

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

இல்லை. இந்த லேடர் (ladder) என்பது வெறும் டெக்ஸ்ட் மட்டுமே. உங்கள் ஏஜென்ட் ஏற்கனவே வாசிக்கும் இன்ஸ்ட்ரக்ஷன் ஃபைலில் இதே போன்ற ஒரு பிளாக்கை பேஸ்ட் செய்தாலே பெரும்பாலான பலன்கள் கிடைத்துவிடும். இந்த பிளகின் உங்களுக்கு மேம்படுத்தப்பட்ட வார்த்தைகள், தீவிர நிலைகள் (intensity levels), ரிவியூ கமெண்டுகள் மற்றும் அப்டேட் பாதையை வழங்குகிறது. இன்ஸ்டாலேஷன் அவசியமா என்பதை அறிய, முதலில் அந்த பிளாக்கை காப்பி செய்து முயற்சிப்பதே முதல் படியாகும்.

கவனிக்கப்படாத ஏஜென்ட் இரவு நேரத்தில் அளவுக்கு அதிகமாக பில்ட் செய்வதை எப்படித் தடுப்பது?

இந்த ரூலை சாட் மெசேஜில் வைக்காமல், always-on இன்ஸ்ட்ரக்ஷன் ஃபைலில் வைக்கவும். அப்போதுதான் நீண்ட ரன்களின் 200-வது டர்னிலும் இது செயல்படும். அதன் பிறகு சேதத்தைக் கட்டுப்படுத்தவும்: உங்கள் ஒரே காப்பியைப் பயன்படுத்தாமல், ஏஜென்ட் சிதைக்க அனுமதிக்கப்பட்ட ஒரு செக்அவுட்டை (checkout) அதற்கு வழங்கவும். எதையும் மெர்ஜ் செய்வதற்கு முன்பு மனிதர்களின் டிஃப் ரிவியூவை (diff review) கட்டாயமாக்கவும். ஒரு மினிமல் டிஃப் ரூல் (minimal diff rule) நீங்கள் படிக்க வேண்டிய அளவைக் குறைக்கும். அது எதை மெர்ஜ் செய்வது என்பதை முடிவு செய்யாது, செய்யக் கூடாது.