Ponytail: AI coding agent குறைந்த code எழுதுவது எப்படி

Ponytail என்பது என்ன

Ponytail என்பது AI coding agent குறைந்த code எழுதும்படி வழிகாட்டும் rule set ஆகும். Project தன்னை ஒரே வரியில் இவ்வாறு விவரிக்கிறது: "அறையில் இருக்கும் மிகவும் சோம்பேறியான senior dev போல உங்கள் AI agent சிந்திக்கச் செய்கிறது. நீங்கள் எழுதாத code-தான் சிறந்த code." இது MIT license-இன் கீழ் வெளியிடப்பட்டுள்ளது. இதற்கு தனிப்பட்ட runtime இல்லை; இதன் எந்தப் பகுதியும் execute ஆகாது. இது agent-ன் instructions-ல் சேர்க்கப்படும் text ஆகும். Skills-ஐ load செய்யும் hosts-க்கு இது skill ஆகவும், skills-ஐ load செய்யாத hosts-க்கு plain rule files ஆகவும் package செய்யப்பட்டுள்ளது.

Repository DietrichGebert/ponytail ஆகும். இது 12 June 2026 அன்று உருவாக்கப்பட்டது. 1 August 2026 அன்று 90,000 stars-ஐ கடந்தது. 1 August 2026 நிலவரப்படி latest tagged release v4.8.4 ஆகும். இது 29 June 2026 அன்று publish செய்யப்பட்டது. Releases page-ல் 14 முதல் 29 June வரையிலான காலத்தில் மட்டும் பத்து tags பட்டியலிடப்பட்டுள்ளன. இத்தகைய வேகத்தில் மாறும் project-ல், நீங்கள் இதைப் படிக்கும் நேரத்தில் மாற்றங்கள் ஏற்பட்டிருக்கலாம். எனவே, இதை அடிப்படையாகக் கொண்டு எதையும் உருவாக்கும் முன் ஒரு 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. இதை ஒரே line-ல் எழுத முடியுமா? ஒரே line-ல் எழுதவும்.
7. அதன் பிறகே, செயல்படும் குறைந்தபட்ச code-ஐ எழுதவும்.

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

இங்கு lazy என்பதன் பொருள் கவனக்குறைவு அல்ல. Ruleset இதை நேரடியாகக் குறிப்பிடுகிறது. அதன் "never lazy about" பட்டியலில், முடிவு எடுப்பதற்கு முன் problem-ஐப் புரிந்துகொள்வது, trust boundaries-ல் input validation செய்வது, data loss-ஐத் தடுக்கும் error handling, security, accessibility, மேலும் பெயரிட்டு நீங்கள் கேட்ட அனைத்தும் அடங்கும். Trivial அல்லாத ஒவ்வொரு logic பகுதியுக்கும் ஒரு சிறிய runnable check இருக்க வேண்டும் என்றும் அது கோருகிறது. இந்த விதி புதிய implementation-களை உருவாக்குவதைக் குறைக்கிறது. 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. Rules-ஐ படிக்கும், ஆனால் skills-ஐ load செய்யாத hosts-க்காக இவை வழங்கப்படுகின்றன.
• hooks/, benchmarks/, examples/ மற்றும் scripts/.

Intensity argument, rule எவ்வளவு வலுவாக அமல்படுத்தப்பட வேண்டும் என்பதை மாற்றுகிறது. lite, நீங்கள் கேட்டதை உருவாக்கி, ஒரே வரியில் குறைந்த முயற்சி தேவைப்படும் ஒரு விருப்பத்தையும் குறிப்பிடும். full default ஆகும்; இது ladder-ஐ கட்டாயப்படுத்தும். ultra என்பது YAGNI-ஐ தீவிரமாகப் பின்பற்றும் setting. இது addition-ஐ விட deletion-ஐ முன்னுரிமை அளித்து, requirement-ஐயே கேள்விக்குள்ளாக்கும்.

Skill-ஐ ஆதரிக்கும் 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-ஐப் பின்பற்றுகிறது. ஆகவே, sessions-க்கு இடையில் உங்கள் agent-ஐ வழிநடத்தும் instructions மாற்றப்படலாம். Update command வழங்கும் வசதிக்காக நீங்கள் ஏற்றுக்கொள்ளும் trade-off இதுவாகும்.

VPS-ல் lazy agent ஏன் குறைந்த செலவாகும்

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

Tokens உள்ளீட்டுக்கும் வெளியீட்டுக்கும் கட்டணம் விதிக்கப்படுகிறது. ஆகவே பாதி அளவுள்ள diff இரண்டு முறை குறைந்த செலவாகும்: முதலில் அதை எழுதும்போது, பின்னர் அதை மீண்டும் படிக்கும் ஒவ்வொரு turn-லும். Self-hosted setup-ல் bill-ஐ கண்காணித்தால், instruction file என்பது செலவில்லாமல் பயன்படுத்தக்கூடிய முக்கிய கட்டுப்பாட்டு வழியாகும். AI agent உங்களிடம் ஏற்படுத்தும் செலவை கட்டுப்படுத்துதல் output அளவிலிருந்து தொடங்குகிறது; மேலும் coding agent தனது tokens-ஐ எவ்வாறு பயன்படுத்துகிறது என்பது, மீண்டும் படித்தல் ஏன் எதிர்பார்ப்பதைவிட முக்கியமானது என்பதை விளக்குகிறது.

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

Server-ல் நிலைமை மாறுகிறது, ஏனெனில் agent பெரும்பாலும் யாரும் கண்காணிக்காமல் இயங்கும். tmux session-ல் அல்லது timer மூலம் செயல்படும் agent, நீங்கள் கவனிப்பதற்கு முன் ஒரு தவறான முடிவை அடிப்படையாகக் கொண்டு பல மணி நேரம் தொடர்ந்து மாற்றங்களைச் செய்ய முடியும். இதுவே VPS-ல் coding agent-ஐ இயக்குதல் தொடர்பான நடைமுறை ஆபத்து. அதனால்தான் loop engineering செய்யும்வர்கள் தனிப்பட்ட prompts-ஐவிட நிலையான instructions-க்கு அதிக கவனம் செலுத்துகின்றனர். எப்போதும் ஏற்றப்படும் file-ல் உள்ள rule, turn 200-க்கும் பொருந்தும். Chat-ல் நீங்கள் type செய்த rule, turn 3-க்கு மட்டுமே பொருந்தும்.

New dependencies மற்றொரு அமைதியான செலவாகும். Rung 5, ஏற்கனவே installed நிலையில் உள்ளவற்றைப் பயன்படுத்த வேண்டும் என்று கூறுகிறது. Agent தன்னிச்சையாகச் சேர்க்கும் ஒவ்வொரு package-ஐயும் பின்னர் நீங்கள் patch செய்ய வேண்டும். அந்த repository-யிலிருந்து உருவாக்கும் ஒவ்வொரு container image-லும் அந்த package இறுதியில் இடம்பெறும்.

Ponytail வெளியிட்ட benchmark முடிவுகள் என்ன கூறுகின்றன

இந்த project இரண்டு வகையான முடிவுகளை வெளியிட்டுள்ளது. அவை ஒன்றுக்கொன்று மிகவும் வேறுபடுகின்றன. இரண்டு முடிவுகளும் project வெளியிட்ட சொந்த கணக்குகள். எதுவும் independent test அல்ல.

[
  {
    "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 column, அந்த rule உடனும் இல்லாமலும் குறைந்த எண்ணிக்கையிலான prompts-க்கு bare model அளித்த பதில்களிலிருந்து பெறப்பட்டது. இவை 13 மற்றும் 17 June 2026 அன்று மேற்கொள்ளப்பட்ட repeated runs-ன் median மதிப்புகள். Agentic column, tiangolo-வின் full-stack-fastapi-template என்ற உண்மையான FastAPI மற்றும் React repository-ஐ headless Claude Code session மூலம் திருத்தியதில் இருந்து பெறப்பட்டது. Haiku 4.5-ல் நான்கு runs வீதம், மொத்தம் பன்னிரண்டு feature tickets பயன்படுத்தப்பட்டன. பின்னர் மீதமிருந்த git diff அடிப்படையில் மதிப்பெண் வழங்கப்பட்டது.

இரண்டாவது column-ஐ கவனிக்கவும். Agentic result, 54 சதவீதம் குறைவான code lines, 20 சதவீதம் குறைந்த cost, மற்றும் 27 சதவீதம் குறைந்த wall clock time ஆகியவற்றைக் காட்டுகிறது. இதே அளவுகளுக்கு single shot setup-ல் முறையே 93 சதவீதமும் 74 சதவீதமும் கிடைத்தன. இதற்கான காரணத்தை README நேரடியாகக் கூறுகிறது: single shot baseline என்பது “பல options மற்றும் commentary-யுடன் பதிலளிக்கும்” bare model ஆகும். அதை விடச் சிறப்பாக செயல்படுவது எளிது. உண்மையான வேலைகளைச் செய்யும் உண்மையான agent-உடன் ஒப்பிட்டால், இந்த முன்னிலை குறைகிறது. இருப்பினும், அந்த முடிவு நடைமுறைக்கு பொருத்தமானதாகவே உள்ளது. அதுவே அதிகம் பயனுள்ள தகவல்.

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

எதையும் நிறுவாமல் இன்று நகலெடுத்து பயன்படுத்தக்கூடிய pattern

இந்த 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.

இந்த இறுதி rule-ஐ தனியாகக் கவனிக்க வேண்டும். Ponytail-ன் convention என்பது tool-ன் பெயரைக் கொண்ட comment tag ஆகும்:

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

இந்த comment இரண்டு வரிகளில் ஒரு நடைமுறைத் தீர்வை பதிவு செய்கிறது. இல்லையெனில் ஒரு review cycle தேவைப்படும் கேள்விக்கும் இது தீர்வு அளிக்கிறது. எளிய version திட்டமிட்ட முடிவு என்பதை அடுத்த reader அறிய இது உதவுகிறது. அந்த முடிவு செல்லுபடியாகாமல் போகும் condition-ஐயும் இது குறிப்பிடுகிறது. இது இல்லையெனில், reviewer பரிசீலித்து எடுத்த shortcut-ஐ agent மறந்துவிட்டதிலிருந்து வேறுபடுத்த முடியாது. அதனால் அவர்கள் கேட்க வேண்டியிருக்கும்.

இந்த block-ஐ எங்கு வைக்கிறீர்கள் என்பதும், அது என்ன சொல்கிறது என்பதுக்கு இணையான முக்கியத்துவம் கொண்டது. ஒவ்வொரு run-லும் agent load செய்யும் file, நீங்கள் கவனிக்காத run-களையும் சேர்த்து எல்லா run-களின் நடத்தையையும் வழிநடத்தும். இந்த வேறுபாட்டைப் பற்றித்தான் உங்கள் agent உண்மையில் பின்பற்றும் AGENTS.md-ஐ எழுதுதல் என்ற பகுதி விளக்குகிறது. அதனால்தான் இந்த pattern உங்கள் shell history-ல் இருப்பதற்குப் பதிலாக commit செய்யப்பட்ட file-ல் இருக்க வேண்டும்.

இந்த விதி பொருந்தாமல் போகும் இடங்கள்

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

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

Problem-ஐத் தவறாகப் புரிந்துகொண்டால் எந்த instruction block-மும் உங்களைப் பாதுகாக்காது. முடிவு எடுப்பதற்கு முன் code-ஐப் புரிந்துகொள்ள வேண்டும் என்பதே ruleset-ன் முதல் விதி. இதுவே அதிக நேரம் எடுத்துக்கொள்ளும் பகுதி; இதை அந்த text உங்களுக்குப் பதிலாகச் செய்ய முடியாது. தவறான function-ல் செய்யப்பட்ட minimal diff, இன்னும் தவறான fix-ஆகவே இருக்கும். இப்போது அதை approve செய்வது எளிதான, சிறிய தவறான fix மட்டுமே.

நேர்மையான சுருக்கம் இதுதான்: Ponytail என்பது கவனமாக எழுதப்பட்ட prompt; அது முறையாகப் பகிரப்பட்டுள்ளது, மேலும் அதனுடன் சில numbers இணைக்கப்பட்டுள்ளன. அதற்கு plugin தேவைப்படுகிறது என்று கூறும் எதுவும் அதில் இல்லை. இந்த project வழங்குவது என்னவென்றால், ஒருவர் அந்த list-ஐ முறையாக எழுதி, உண்மையான repository-க்கு எதிராகச் சோதித்து, result-க்கு அடுத்ததாக method-ஐ வெளியிட்டுள்ளார்.

FAQ

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

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

Lazy agent tests, validation அல்லது security-ஐத் தவிர்க்குமா?

இல்லை. Ruleset இதை நேரடியாகக் குறிப்பிடுகிறது. அதன் "never lazy about" பட்டியலில் trust boundaries-ல் input validation, data loss-ஐத் தடுக்கும் error handling, security மற்றும் accessibility ஆகியவை உள்ளன. Non-trivial logic-ன் ஒவ்வொரு பகுதியுக்கும் இயக்கக்கூடிய ஒரு சிறிய check கேட்கப்படுகிறது. இந்த rule நீக்குவது, யாரும் கேட்காத invented structure-ஐ மட்டுமே: தேவையில்லாத abstractions மற்றும் யாருக்கும் தேவையில்லாத dependencies. இதை install செய்த பிறகு உங்கள் agent tests-ஐத் தவிர்க்கத் தொடங்கினால், உங்கள் சொந்த config-ல் உள்ள வேறு instruction இதைவிட அதிக priority பெற்றிருக்கலாம். எனவே agent இறுதியாக load செய்யும் file-ஐப் படிக்கவும்.

வெளியிடப்பட்ட speed மற்றும் cost numbers நம்பகமானவையா?

அவை project-ன் சொந்த measurements. அவற்றின் method-உடனே வெளியிடப்பட்டுள்ளன. எனவே அவற்றை அந்தச் சூழலிலேயே புரிந்துகொள்ள வேண்டும். Single-shot figures, options மற்றும் commentary-உடன் பதிலளிக்கும் bare model-ஐ ஒப்பீடாகக் கொண்டுள்ளன. இது பலவீனமான baseline என்று README தானே குறிப்பிடுகிறது. Agentic figures, ஒரு FastAPI மற்றும் React repository-ல் headless Claude Code session மூலம் பெறப்பட்டவை. அதில் twelve tickets மற்றும் ஒவ்வொரு ticket-க்கும் four runs பயன்படுத்தப்பட்டன; model Haiku 4.5. அந்த setup-க்கு இவை நம்பகமான numbers. ஆனால் அவை உங்கள் codebase-க்கான forecast அல்ல. ஏற்கனவே minimal-ஆக இருந்த code-ல் saving near zero ஆகக் குறையும் என்றும் project குறிப்பிடுகிறது.

இதன் பயனைப் பெற ஏதாவது install செய்ய வேண்டுமா?

இல்லை. Ladder என்பது text மட்டுமே. உங்கள் agent ஏற்கனவே வாசிக்கும் instruction file-ல் அதற்குச் சமமான block-ஐ paste செய்தால், பெரும்பாலான பயனைப் பெறலாம். Plugin, பராமரிக்கப்படும் wording, intensity levels, review commands மற்றும் update path ஆகியவற்றை வழங்குகிறது. Install உண்மையில் தேவையா என்பதைச் சோதிக்க, copied block-ஐ முதலில் பயன்படுத்துவது rung 1-ன் பதிலாகும்.

Unattended agent இரவு முழுவதும் தேவைக்கு அதிகமாக build செய்வதை எவ்வாறு நிறுத்துவது?

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