Ponytail: AI coding agent na parang tamad na senior dev

Ano ang Ponytail

Ang Ponytail ay isang set ng rules na nagtutulak sa AI coding agent na sumulat ng mas kaunting code. Ganito inilalarawan ng proyekto ang sarili nito sa isang linya: “Ginagawa nitong mag-isip ang AI agent na parang pinakatamad na senior dev sa team. Ang pinakamagandang code ay ang code na hindi mo kailanman isinulat.” Naka-MIT license ito. Wala itong sariling runtime, at walang code rito ang ine-execute. Teksto lamang ito na inilalagay sa instructions ng agent. Naka-package ito bilang skill para sa mga host na naglo-load ng skills, at bilang plain rule files para sa mga host na hindi naglo-load ng skills.

Ang repository nito ay DietrichGebert/ponytail. Nilikha ito noong 12 June 2026 at umabot sa 90,000 stars pagsapit ng 1 August 2026. Ang pinakabagong tagged release noong 1 August 2026 ay v4.8.4, na inilabas noong 29 June 2026. Nakalista sa releases page ang sampung tag mula 14 hanggang 29 June lamang. Kung ganoon kabilis magbago ang proyekto, posibleng iba na ito kapag binasa mo ito. Kaya mag-pin ng tag bago ka bumuo ng anuman batay rito.

Ang ideya bago ang tool: huminto sa unang baitang na gumagana

Ang pangunahing konsepto ng Ponytail ay isang decision ladder. Inaakyat ito ng agent bago magsulat ng anuman, at humihinto sa unang baitang na gumagana.

1. Kailangan ba talaga itong umiral? Ito ang YAGNI (you are not going to need it). Kung hindi, laktawan ito.
2. Umiiral na ba ito sa codebase na ito? Gamitin muli ang helper o pattern na naroon na.
3. Kaya ba ito ng standard library? Gamitin ito.
4. May native platform feature bang makakasagot dito? Gamitin ito.
5. May naka-install na dependency bang makakasagot dito? Gamitin ito.
6. Maaari ba itong maging isang line? Gawin itong isang line.
7. Saka lamang isulat ang minimum na code na gumagana.

Ang pagkakasunod-sunod ang gumagawa ng trabaho, hindi ang alinmang baitang. Kapag inutusan ang agent na gumawa ng date picker, gagawa ito ng date picker dahil iyon ang ipinagawa rito. Pinagagawa ng ladder na suriin muna nito ang rung 4, at sinasabi ng rung 4 na mayroon nang <input type="date"> ang browser. Eksaktong tinatalakay ng sariling benchmark notes ng proyekto ang kasong ito: ang date picker na umabot sa 404 lines nang walang rule ay naging 23 lines nang mayroon nito, dahil ginamit ng agent ang native input sa halip na bumuo ng component. Mula 287 lines ay naging 23 lines din ang colour picker sa parehong dahilan.

Hindi ibig sabihin ng pagiging tamad dito ang pagiging pabaya, at malinaw itong sinasabi ng ruleset. Kasama sa listahan nitong "never lazy about" ang pag-unawa sa problema bago magdesisyon, input validation sa trust boundaries, error handling na pumipigil sa pagkawala ng data, security, accessibility, at anumang partikular mong hiningi. Hinihingi rin nito ang isang maliit na runnable check para sa bawat bahagi ng non-trivial logic. Nililimitahan ng rule ang pag-iimbento. Hindi nito binabawasan ang correctness.

Ano talaga ang kasama sa repository

• AGENTS.md, ang always-on ruleset, na naglalaman ng buong ideya sa isang file na mababasa mo sa loob ng limang minuto.
• skills/ponytail/SKILL.md, ang skill definition, na may argument hint na lite, full o ultra.
• Mga rule file sa mga directory na partikular sa editor gaya ng .cursor/rules/ at .windsurf/rules/, para sa mga host na nagbabasa ng rules pero hindi naglo-load ng skills.
• hooks/, benchmarks/, examples/ at scripts/.

Binabago ng intensity argument kung gaano kalakas ipinatutupad ng rule ang panuntunan. Binubuo ng lite ang hiniling mo at tinutukoy nito sa isang linya ang mas maluwag na option. Ang full ang default at ipinapatupad nito ang ladder. Ang ultra ang YAGNI extremist setting: mas pinipili nito ang mag-delete kaysa magdagdag, at kinukuwestiyon nito mismo ang requirement.

Nakakakuha rin ng slash commands ang mga host na sumusuporta sa skills. Itinatakda ng /ponytail ang level, sinusuri ng /ponytail-review ang diff para sa over-engineering, sinusuri ng /ponytail-audit ang buong repository, kinokolekta ng /ponytail-debt ang mga shortcut na ipinagpaliban mo, at ipinapakita ng /ponytail-gain ang benchmark scorecard. Nakakakuha ng ruleset pero walang commands ang mga host na rule files lamang ang binabasa.

Para basahin muna ang source bago mo ito pagkatiwalaan, i-clone ang tag sa halip na ang branch:

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

Sa Claude Code, plugin install naman ang idinodokumento ng project, at ang dalawang linyang ito ay ayon sa dokumentasyon noong 1 August 2026:

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

Ang plugin path ay sumusunod sa default branch sa halip na sa isang tag. Dahil dito, maaaring magbago ang mga instruction na gumagabay sa agent sa pagitan ng mga session. Ito ang trade-off kapalit ng kaginhawaan ng isang update command.

Bakit mas matipid sa VPS ang lazy na agent

Hindi lumalabas sa conversation ang diff na isinusulat ng agent. Sa susunod na turn, bahagi ito ng context na babasahin muli ng model, kasama ang bawat file na binuksan nito para mabuo ang diff. Kaya ang 500-line na pagbabago ay may dagdag na gastos sa bawat kasunod na turn sa session, hindi lamang sa turn kung kailan ito ginawa. Ito ang dahilan kung bakit nagiging mas mabagal at mas hindi maaasahan ang agent habang tumatagal ang session kapag may runaway refactor: napupuno ang context window ng sarili nitong output, kaya lumiit ang espasyong natitira para sa aktuwal mong code. Ito ang buong paksa ng pamamahala sa context window ng coding agent.

Sinisingil ang mga token sa input at output, kaya ang diff na kalahati ang laki ay dalawang beses na mas matipid: una kapag isinusulat ito, at muli sa bawat turn na binabasa itong muli. Kung lalabas man sa bill mo ang matitipid na ito ay nakadepende sa paraan ng pagbabayad mo, dahil sinasagot ng flat Pro o Max subscription ang dagdag na mga token, samantalang sa per-token API billing ay sinisingil ka sa bawat isa sa mga ito. Kung mino-monitor mo ang bill sa self-hosted setup, ang instruction file ay isang lever na walang gastos gamitin. Nagsisimula ang pagkontrol sa gastos ng AI agent sa dami ng output, at ipinapaliwanag ng kung paano ginagamit ng coding agent ang mga token nito kung bakit mas mahalaga kaysa inaasahan ng marami ang muling pagbasa.

Binabasa pa rin ng tao ang diff. Ang 400-line na pagbabago na dapat sana ay 20 lines lamang ay kumokonsumo sa atensyon ng reviewer, at ang atensyon ang unang nauubos. Walang nagre-review ng ikaapat na mahabang diff sa isang araw nang kasing-ingat ng pag-review sa una. Kaya ang sobrang laki ng implementation ay hindi lamang nagsasayang ng oras. Unti-unti rin nitong binabawasan ang kalidad ng review na dapat makadiskubre sa mga pagkakamali.

Sa server, nagbabago ang mga risk dahil madalas tumatakbo ang agent nang walang nagbabantay. Ang agent na gumagana sa tmux session o naka-schedule sa timer ay may ilang oras para palalimin ang maling desisyon bago mo ito makita. Ito ang praktikal na panganib sa pagpapatakbo ng coding agent sa VPS, at ito ang dahilan kung bakit mas maingat ang mga gumagawa ng loop engineering sa standing instructions kaysa sa mga indibidwal na prompt. Ang rule sa always-on file ay nalalapat sa turn 200. Ang rule na tina-type mo sa chat ay nalalapat sa turn 3.

Ang mga bagong dependency ang isa pang tahimik na gastos. Sinasabi ng Rung 5 na gamitin ang naka-install na. Ang bawat package na idinadagdag ng agent sa sarili nitong inisyatiba ay kailangan mong i-patch sa hinaharap, at mapupunta rin ito sa bawat container image na bina-build mo mula sa repository na iyon.

Ang sinasabi ng sariling benchmark numbers ng Ponytail

Dalawang set ng resulta ang inilalathala ng proyekto, at malaki ang diperensiya ng mga ito sa isa’t isa. Pareho itong sariling inilathalang figure ng proyekto. Wala sa mga ito ang 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
  }
]

Ang column na single shot ay mula sa isang bare model na sumagot sa maliit na set ng prompts, mayroon at walang rule, gamit ang median ng paulit-ulit na run na isinagawa noong 13 at 17 June 2026. Ang agentic column ay mula sa isang headless Claude Code session na nag-edit sa full-stack-fastapi-template ni tiangolo, isang aktuwal na FastAPI at React repository, para sa labindalawang feature ticket na may tig-apat na run sa Haiku 4.5. Sinuri ito batay sa git diff na naiwan.

Basahin ang ikalawang column. Ang agentic result ay may 54 porsiyentong mas kaunting linya ng code, 20 porsiyentong mas mababang cost, at 27 porsiyentong mas maikling wall clock time, kumpara sa 93 porsiyento at 74 porsiyento para sa parehong measure sa single shot setup. Tapat ang README tungkol sa dahilan: ang single shot baseline ay isang bare model na “sumasagot gamit ang ilang option at commentary,” kaya madaling lampasan iyon. Kapag inihambing sa isang tunay na agent na gumagawa ng aktuwal na trabaho, lumiliit ang pakinabang. Totoo pa rin ito, at iyon ang mas kapaki-pakinabang na impormasyon.

May isang caveat mula mismo sa proyekto, at ito ang magpapasya kung makatutulong ito sa iyo. Pinakamalaki ang natitipid kapag may tunay na panganib ng over-build, at halos zero kapag minimal na ang code. Hindi sapat na batayan para sa iyong repository ang labindalawang ticket sa isang Python at TypeScript repository. Kung mahalaga sa iyo ang number, patakbuhin ang comparison sa sarili mong mga ticket, mayroon at walang rule, at ikaw mismo ang magbilang ng mga linya.

Ang pattern na maaari mong kopyahin ngayon nang walang ini-install

Text ang ladder, kaya hindi mo kailangan ang plugin para magamit ang ideya. I-paste ang ganitong block sa instruction file na binabasa na ng iyong agent, nasa AGENTS.md man, CLAUDE.md, o sa rules file ng iyong editor.

## 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.

Mahalagang pagtuunan nang hiwalay ang huling rule na iyon. Ang convention ng Ponytail ay isang comment na may tag ng pangalan ng tool:

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

Dalawang linya ng trabaho ang natitipid ng comment na ito, at nilulutas nito ang isang tanong na kung hindi ay mangangailangan ng isang review cycle. Sinasabi nito sa susunod na reader na sinadya ang simpleng bersyon, at tinutukoy nito ang kondisyon kung kailan hindi na valid ang desisyong iyon. Kung wala ito, hindi matutukoy ng reviewer kung pinag-isipang shortcut ba ito o may nakalimutang gawin ang agent, kaya kailangan pa niyang magtanong.

Mahalaga kung saan mo ilalagay ang block, gaya ng kahalagahan ng nilalaman nito. Ang file na nilo-load ng agent sa bawat run ay gumagabay sa bawat run, kabilang ang mga run na hindi mo mino-monitor. Ang pagkakaibang ito ang paksa ng pagsulat ng AGENTS.md na aktuwal na sinusunod ng iyong agent, at ito ang dahilan kung bakit dapat nasa isang committed file ang pattern na ito sa halip na nasa shell history mo.

Kung kailan hindi na tama ang rule

Ang ladder ay inayos para sa feature work sa isang codebase na mayroon na, kung saan karaniwang available at tama ang reuse. Hindi ito akma sa greenfield project, dahil walang mare-reuse sa rung 2 at walang naka-install sa rung 5, kaya palaging nahuhulog ang agent sa rung 7. Hindi rin ito akma kapag tunay mong kailangan ang abstraction. Kung magdadagdag ka na ng ikaapat na caller para sa parehong kinopyang block, bibigyan ka ng “shortest diff” ng ikalimang kopya.

Kukuwestiyunin ng level na ultra ang iyong requirements. Iyan ang layunin ng level, at tunay itong cost kapag nakapagpasya ka na at gusto mo nang matapos ang trabaho. Gamitin ang full para sa ordinaryong work, at gamitin ang ultra kapag naghihinala kang ang feature request mismo ang problema.

Walang instruction block na makapagliligtas sa iyo mula sa maling pag-unawa sa problema. Ang unang item mismo ng ruleset ay ang pag-unawa sa code bago magpasya, at iyon ang pinakamahalaga at pinakamahal na bahagi na hindi kayang gawin ng text para sa iyo. Ang minimal diff sa maling function ay mali pa rin na fix, at maliit na itong maling fix na madaling aprubahan.

Ang tapat na buod: ang Ponytail ay maingat na isinulat na prompt na maayos na ipinamahagi at nilagyan ng mga numero. Walang bahagi nito ang nangangailangan ng plugin. Ang ibinibigay ng project ay ang katotohanang may sumulat nang maayos sa listahan, sumubok nito sa isang totoong repository, at inilathala ang method kasama ng resulta.

FAQ

Gumagana ba ang Ponytail sa mga agent bukod sa Claude Code?

Oo. Inilalabas ito bilang skill para sa mga host na naglo-load ng skills. Kasama sa listahang ito ang Claude Code, Codex, OpenCode, Gemini, at iba pang binanggit sa README. Ang mga editor na nagbabasa ng rule files pero hindi naglo-load ng skills, gaya ng Cursor, Windsurf, Cline, at Copilot, ay kumukuha ng always-on ruleset mula sa katugmang rules directory at walang slash commands. Pareho ang text sa dalawang paraan. Ang aktuwal na kaibahan ay kung pinananatili ng host ang text na iyon sa context sa bawat turn o nilo-load lamang kapag may na-trigger na skill.

Lalaktawan ba ng lazy agent ang mga test, validation, o security check?

Hindi, at tahasang nakasaad ito sa ruleset. Kasama sa listahan nitong “never lazy about” ang input validation sa trust boundaries, error handling na pumipigil sa pagkawala ng data, security at accessibility. Hinihingi rin nito ang isang maliit na runnable check para sa bawat piraso ng non-trivial logic. Ang inaalis ng rule ay ang gawa-gawang structure: mga abstraction na walang humiling at mga dependency na walang nangangailangan. Kung nagsisimulang mag-drop ng tests ang agent mo pagkatapos mong i-install ito, malamang na may ibang instruction sa sarili mong config na mas mataas ang priority kaysa rito. Basahin ang file na huling nilo-load ng agent.

Mapagkakatiwalaan ba ang inilabas na speed at cost numbers?

Sarili itong measurements ng proyekto. Inilathala ang mga ito kasama ang ginamit na method, kaya dapat basahin ang mga ito ayon sa setup na iyon. Inihahambing ng single shot figures ang resulta sa isang bare model na sumasagot gamit ang options at commentary. Tinutukoy mismo ng README na mahina itong baseline. Ang agentic figures ay mula sa isang headless Claude Code session sa isang FastAPI at React repository, na may twelve tickets at four runs bawat ticket, gamit ang Haiku 4.5. Tapat ang mga numerong ito para sa setup na iyon. Hindi ito forecast para sa codebase mo, dahil sinasabi rin ng proyekto na halos nawawala ang matitipid sa code na minimal na bago pa ito ginamit.

May kailangan ba akong i-install para makuha ang benepisyo?

Wala. Text ang ladder, at ang katumbas na block na i-paste sa instruction file na binabasa na ng agent mo ay nagbibigay ng karamihan sa epekto. Ibinibigay ng plugin ang pinapanatiling updated na wording, mga intensity level, mga review command, at update path. Ang pagsubok muna sa kinopyang block ang sagot sa rung 1 kung kailangan nga bang may install.

Paano ko mapipigilan ang unattended agent na mag-over-build magdamag?

Ilagay ang rule sa always-on instruction file sa halip na sa chat message. Sa ganitong paraan, naa-apply ito sa turn 200 ng mahabang run, hindi lamang sa turn 3. Pagkatapos, hiwalay na limitahan ang posibleng pinsala. Bigyan ang agent ng checkout na maaari nitong sirain sa halip na ang tanging kopya mo, at mangailangan ng human diff review bago magkaroon ng merge. Binabawasan ng minimal diff rule ang dami ng kailangan mong basahin. Hindi nito pinagpapasyahan kung ano ang mapupunta sa merge, at hindi rin dapat nito gawin iyon.